Difference between revisions of "IPv6: Konfigurasi Routing Statik"
Onnowpurbo (talk | contribs) (Created page with "Configuring Static Routes The route table acquires information in one of three ways: The information can be entered based on what the router knows about its directly connected...") |
Onnowpurbo (talk | contribs) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Configuring Static Routes | Configuring Static Routes | ||
− | + | ||
− | + | Tabel rute memperoleh informasi dalam salah satu dari tiga cara: | |
− | + | ||
− | + | # Informasi dapat dimasukkan berdasarkan apa yang diketahui router tentang subnet yang terhubung langsung. | |
− | + | # Informasi dapat dimasukkan secara manual, melalui entri rute statis. | |
− | + | # Informasi dapat dimasukkan secara otomatis oleh salah satu dari beberapa sistem penemuan dan pembagian informasi otomatis yang dikenal sebagai protokol routing dinamis. | |
− | + | ||
− | + | Sebagian besar materi yang menarik untuk dibahas adalah dynamic IP routing protocol, tetapi pembahasan konfigurasi rute statik akan mempersiapkan anda untuk memahami bagian-bagian selanjutnya. | |
− | + | ||
− | + | Lebih tepatnya, routing statik lebih disukai daripada routing dinamik dalam keadaan tertentu. Seperti halnya proses apa pun, semakin otomatis, semakin sedikit kontrol yang kita miliki. Meskipun perutean dinamis (otomatis) memerlukan lebih sedikit intervensi manusia, perutean statik memungkinkan kontrol yang sangat tepat atas perilaku perutean jaringan. Harga yang harus dibayar untuk ketepatan ini adalah perlunya konfigurasi ulang manual setiap kali topologi jaringan berubah. | |
− | + | ||
− | + | ||
− | + | ==Studi Kasus: Routing Statik Sederhana== | |
− | + | ||
− | + | Figure 3-2 shows a network with four routers and six data links. Notice that the subnets of network 10.0.0.0 are discontiguous there is a different major network subnet (192.168.1.192, in the Tigger-to-Piglet link) separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of 10.0.0.0 are also variably subnetted the subnet masks are not consistent throughout the network: Subnet 10.1.0.0 has a 16-bit mask, while 10.4.0.0 has a 24-bit mask. Finally, the subnet address of Pooh's Ethernet link is an all-zero subnet. Later chapters demonstrate that an addressing scheme with these characteristics causes problems for simpler, classful routing protocols such as RIP and IGRP; but static routes work fine here. | |
− | + | ||
− | + | Gambar 3-2. Protokol-protokol routing seperti RIP dan IGRP tidak dapat dengan mudah me-routing jaringan yang tidak jelas dan berbeda-beda ini, tetapi routing statik akan bekerja. | |
− | + | ||
− | |||
− | Figure 3-2 shows a network with four routers and six data links. Notice | ||
− | that the subnets of network 10.0.0.0 are | ||
− | major network subnet (192.168.1.192, in the Tigger-to-Piglet link) | ||
− | separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of | ||
− | 10.0.0.0 are also variably | ||
− | 10.4.0.0 has a 24-bit mask. Finally, the subnet address of Pooh's | ||
− | Ethernet link is an all-zero subnet. Later chapters demonstrate that an | ||
− | addressing scheme with these characteristics causes problems for | ||
− | simpler, classful routing protocols such as RIP and IGRP; but static | ||
− | routes work fine here. | ||
− | |||
− | |||
− | |||
[View full size image] | [View full size image] | ||
− | + | ||
− | + | Prosedur untuk me-routing jaringan secara statik memiliki tiga langkah: | |
− | + | ||
− | + | # Untuk setiap data link dalam jaringan, identifikasi semua alamat subnet atau jaringan. | |
− | router. | + | # Untuk setiap router, identifikasi semua data link yang tidak terhubung langsung ke router itu. |
− | + | # Untuk setiap router, tulis perinta route untuk setiap alamat yang tidak terhubung langsung ke situ. TIdak perlu menulis perintah route untuk data link yang terhubung langsung dengan router, karena alamat dan mask yang dikonfigurasi pada interface router menyebabkan jaringan tersebut dicatat dalam tabel route-nya. . | |
− | + | ||
− | |||
− | router | ||
For example, the network in Figure 3-2 has six subnets: | For example, the network in Figure 3-2 has six subnets: | ||
− | 10.1.0.0/16 | + | 10.1.0.0/16 |
− | 10.4.6.0/24 | + | 10.4.6.0/24 |
− | 10.4.7.0/24 | + | 10.4.7.0/24 |
− | 192.168.1.192/27 | + | 192.168.1.192/27 |
− | 192.168.1.64/27 | + | 192.168.1.64/27 |
− | 192.168.1.0/27 | + | 192.168.1.0/27 |
+ | |||
To configure static routes for Piglet, the subnets that are not directly | To configure static routes for Piglet, the subnets that are not directly | ||
connected are identified as follows: | connected are identified as follows: | ||
− | 10.4.6.0/24 | + | 10.4.6.0/24 |
− | 10.4.7.0/24 | + | 10.4.7.0/24 |
− | 192.168.1.64/27 | + | 192.168.1.64/27 |
− | 192.168.1.0/27 | + | 192.168.1.0/27 |
− | These are the subnets for which static routes must be written. Example | + | |
− | 3-2 shows the commands for entering Piglet's static routes. [3] | + | These are the subnets for which static routes must be written. Example 3-2 shows the commands for entering Piglet's static routes. [3] |
[3] | [3] | ||
− | For the static routes in this example and the subsequent examples in this chapter towork properly, two global commands must be added to the routers: ip classless and ip | + | |
− | subnet-zero. In IOS 11.3 and later, ip classless is enabled by default. These commands | + | For the static routes in this example and the subsequent examples in this chapter towork properly, two global commands must be added to the routers: ip classless and ip subnet-zero. In IOS 11.3 and later, ip classless is enabled by default. These commands are introduced in Chapter 6 and are mentioned here for readers who wish to try the configuration examples in a lab. |
− | are introduced in Chapter 6 and are mentioned here for readers who wish to try the | + | |
− | configuration examples in a lab. | ||
Example 3-2. Configuring Piglet's static routes. | Example 3-2. Configuring Piglet's static routes. | ||
− | Piglet(config)# | + | |
− | Piglet(config)# | + | Piglet(config)# |
− | Piglet(config)# | + | Piglet(config)# |
− | Piglet(config)# | + | Piglet(config)# |
− | ip | + | Piglet(config)# |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | route | + | ip |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | 192.168.1.0 255.255.255.224 192.168.1. | + | route |
− | 192.168.1.64 255.255.255.224 192.168.1 | + | 192.168.1.0 255.255.255.224 192.168.1. |
− | 10.4.6.0 255.255.255.0 192.168.1.193 | + | 192.168.1.64 255.255.255.224 192.168.1 |
− | 10.4.7.0 255.255.255.0 192.168.1.193 | + | 10.4.6.0 255.255.255.0 192.168.1.193 |
− | Following the same steps, Example 3-3 shows the route entries for the | + | 10.4.7.0 255.255.255.0 192.168.1.193 |
− | other three routers. | + | |
− | Example 3-3. Route entries for Routers Pooh, Tigger, and | + | Following the same steps, Example 3-3 shows the route entries for the other three routers. |
− | Eeyore. | + | Example 3-3. Route entries for Routers Pooh, Tigger, and Eeyore. |
− | Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1. | + | |
− | Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66 | + | Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1. |
− | Pooh(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.66 | + | Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66 |
− | Pooh(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.66 | + | Pooh(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.66 |
− | _______________________________________________________________ | + | Pooh(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.66 |
− | Tigger(config)# ip route 192.168.1.0 255.255.255.224 192.168.1. | + | _______________________________________________________________ |
− | Tigger(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.194 | + | Tigger(config)# ip route 192.168.1.0 255.255.255.224 192.168.1. |
− | Tigger(config)# ip route 10.4.7.0 255.255.255.0 10.4.6.2 | + | Tigger(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.194 |
− | _______________________________________________________________ | + | Tigger(config)# ip route 10.4.7.0 255.255.255.0 10.4.6.2 |
− | Eeyore(config)# ip route 192.168.1.0 255.255.255.224 10.4.6.1 | + | _______________________________________________________________ |
− | Eeyore(config)# ip route 192.168.1.64 255.255.255.224 10.4.6.1 | + | Eeyore(config)# ip route 192.168.1.0 255.255.255.224 10.4.6.1 |
− | Eeyore(config)# ip route 192.168.1.192 255.255.255.224 10.4.6.The routing commands themselves are easily read if the reader | + | Eeyore(config)# ip route 192.168.1.64 255.255.255.224 10.4.6.1 |
− | remembers that each command describes a route table entry. The | + | Eeyore(config)# ip route 192.168.1.192 255.255.255.224 10.4.6 |
− | command for IPv4 is ip route, followed by the address to be entered into | + | |
− | the table, a mask for determining the network portion of the address, and | + | |
− | the address of the directly connected interface of the next-hop router. | + | .The routing commands themselves are easily read if the reader remembers that each command describes a route table entry. The command for IPv4 is ip route, followed by the address to be entered into the table, a mask for determining the network portion of the address, and the address of the directly connected interface of the next-hop router. |
− | An alternative configuration command for IPv4 static routes specifies the | + | |
− | interface out of which an address is reached instead of the interface | + | An alternative configuration command for IPv4 static routes specifies the interface out of which an address is reached instead of the interface address of the next-hop router. For example, Example 3-4 shows the possible route entries for Tigger. |
− | address of the next-hop router. For example, Example 3-4 shows the | + | |
− | possible route entries for Tigger. | ||
Example 3-4. Alternative route entries for Tigger. | Example 3-4. Alternative route entries for Tigger. | ||
− | ip route 192.168.1.0 255.255.255.224 S0 | + | |
− | ip route 10.1.0.0 255.255.0.0 E0 | + | ip route 192.168.1.0 255.255.255.224 S0 |
− | ip route 10.4.7.0 255.255.255.0 S1 | + | ip route 10.1.0.0 255.255.0.0 E0 |
+ | ip route 10.4.7.0 255.255.255.0 S1 | ||
+ | |||
Certain conditions must be met before a static route is written into the | Certain conditions must be met before a static route is written into the | ||
route table. IP routing must be enabled, the next-hop address, if used, | route table. IP routing must be enabled, the next-hop address, if used, | ||
must be reachable, the exit interface must have an IP address configured | must be reachable, the exit interface must have an IP address configured | ||
on it, and the exit interface must be up. | on it, and the exit interface must be up. | ||
+ | |||
Example 3-5 compares the route table resulting from this configuration | Example 3-5 compares the route table resulting from this configuration | ||
with the route table resulting from entries pointing to a next-hop router. | with the route table resulting from entries pointing to a next-hop router. | ||
Line 117: | Line 103: | ||
as if they are directly connected to that interface. The implications for | as if they are directly connected to that interface. The implications for | ||
route redistribution are discussed in Chapter 11. | route redistribution are discussed in Chapter 11. | ||
+ | |||
A point of interest in Example 3-5 is that the header for the 10.0.0.0 | A point of interest in Example 3-5 is that the header for the 10.0.0.0 | ||
subnets indicates the variable subnet masks used in the network. | subnets indicates the variable subnet masks used in the network. | ||
Line 124: | Line 111: | ||
table is the result of static routes that point to the interface | table is the result of static routes that point to the interface | ||
a packet must exit to reach the destination network. [4] | a packet must exit to reach the destination network. [4] | ||
− | Tigger#show ip route | + | |
− | Gateway of last resort is not set | + | Tigger#show ip route |
− | 10.0.0.0 is variably subnetted, 3 subnets, 2 masks | + | Gateway of last resort is not set |
− | C | + | 10.0.0.0 is variably subnetted, 3 subnets, 2 masks |
− | 10.4.6.0 255.255.255.0 is directly connected, Serial1 | + | C |
− | S | + | 10.4.6.0 255.255.255.0 is directly connected, Serial1 |
− | 10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2 | + | S |
− | S | + | 10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2 |
− | 10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194 | + | S |
− | 192.168.1.0 255.255.255.224 is subnetted, 3 subnets | + | 10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194 |
− | C | + | 192.168.1.0 255.255.255.224 is subnetted, 3 subnets |
− | 192.168.1.64 is directly connected, Serial0 | + | C |
− | S | + | 192.168.1.64 is directly connected, Serial0 |
− | 192.168.1.0 [1/0] via 192.168.1.65 | + | S |
− | C | + | 192.168.1.0 [1/0] via 192.168.1.65 |
− | 192.168.1.192 is directly connected, Ethernet0 | + | C |
− | Tigger# | + | 192.168.1.192 is directly connected, Ethernet0 |
− | Tigger#show ip route | + | Tigger# |
− | Gateway of last resort is not set | + | Tigger#show ip route |
− | 10.0.0.0 is variably subnetted, 3 subnets, 2 masks | + | Gateway of last resort is not set |
− | C | + | 10.0.0.0 is variably subnetted, 3 subnets, 2 masks |
− | 10.4.6.0 255.255.255.0 is directly connected, Serial1 | + | C |
− | S | + | 10.4.6.0 255.255.255.0 is directly connected, Serial1 |
− | 10.4.7.0 255.255.255.0 is directly connected, Serial1 | + | S |
− | S | + | 10.4.7.0 255.255.255.0 is directly connected, Serial1 |
− | 10.1.0.0 255.255.0.0 is directly connected, Ethernet0 | + | S |
− | 192.168.1.0 255.255.255.224 is subnetted, 3 subnets | + | 10.1.0.0 255.255.0.0 is directly connected, Ethernet0 |
− | C | + | 192.168.1.0 255.255.255.224 is subnetted, 3 subnets |
− | 192.168.1.64 is directly connected, Serial0 | + | C |
− | S | + | 192.168.1.64 is directly connected, Serial0 |
− | 192.168.1.0 is directly connected, Serial0 | + | S |
− | C | + | 192.168.1.0 is directly connected, Serial0 |
− | 192.168.1.192 is directly connected, Ethernet0 | + | C |
− | Tigger# | + | 192.168.1.192 is directly connected, Ethernet0 |
− | [4] | + | Tigger# |
− | The key normally seen at the top of the route table (as in Figure 3-2) has been | + | [4] |
− | removed for clarity. | + | |
− | A third option for static routes is to use a combination of the outgoing | + | The key normally seen at the top of the route table (as in Figure 3-2) has been removed for clarity. |
− | interface and the next-hop address. The next-hop address is coupled | + | |
− | with the specified exit interface. If the exit interface goes down, the routewith the specified exit interface. If the exit interface goes down, the route | + | A third option for static routes is to use a combination of the outgoing interface and the next-hop address. The next-hop address is coupled with the specified exit interface. If the exit interface goes down, the routewith the specified exit interface. If the exit interface goes down, the route is removed from the route table, even if the next-hop address is recursively reachable via an alternate route. This minimizes table lookups associated with finding the outgoing interface associated with a next-hop address and the entry in the table appears as a route with a distance of 1, not a directly connected network. |
− | is removed from the route table, even if the next-hop address is | + | |
− | recursively reachable via an alternate route. This minimizes table lookups | + | Directing a static route to an exit broadcast interface without specifying the next-hop address can cause an excessive amount of traffic on the broadcast network, and also might eat up the router's memory. For example, look at Tigger's ip route 10.1.0.0 255.255.0.0 E0 command. The router assumes 10.1.0.0 is directly connected, as we have seen from the route table. Therefore, when attempting to route to any address on the 10.1.0.0/16 subnet, the router sends an ARP request to find the MAC address to which to forward the packet. Each attempt to reach an address on the 10.1.0.0 network, whether the destination is valid or not, will result in an ARP request, an ARP response if a router on the broadcast network is responding on behalf of the 10.1.0.0 network (proxy ARP), and a potentially large ARP cache on the router. By appending the next-hop address to the static route entry, ip route 10.1.0.0 255.255.0.0 E0 192.168.1.194, the router no longer assumes that the destination is directly connected. The only ARP traffic is for the next-hop address, which only occurs for the first packet destined to a host on network 10.1.0.0, rather than for every packet destined to a new host on network |
− | associated with finding the outgoing interface associated with a next-hop | ||
− | address and the entry in the table appears as a route with a distance of | ||
− | 1, not a directly connected network. | ||
− | Directing a static route to an exit broadcast interface without specifying | ||
− | the next-hop address can cause an excessive amount of traffic on the | ||
− | broadcast network, and also might eat up the router's memory. For | ||
− | example, look at Tigger's ip route 10.1.0.0 255.255.0.0 E0 command. | ||
− | The router assumes 10.1.0.0 is directly connected, as we have seen from | ||
− | the route table. Therefore, when attempting to route to any address on | ||
− | the 10.1.0.0/16 subnet, the router sends an ARP request to find the MAC | ||
− | address to which to forward the packet. Each attempt to reach an | ||
− | address on the 10.1.0.0 network, whether the destination is valid or not, | ||
− | will result in an ARP request, an ARP response if a router on the | ||
− | broadcast network is responding on behalf of the 10.1.0.0 network (proxy | ||
− | ARP), and a potentially large ARP cache on the router. By appending the | ||
− | next-hop address to the static route entry, ip route 10.1.0.0 255.255.0.0 | ||
− | E0 192.168.1.194, the router no longer assumes that the destination is | ||
− | directly connected. The only ARP traffic is for the next-hop address, | ||
− | which only occurs for the first packet destined to a host on network | ||
− | 10.1.0.0, rather than for every packet destined to a new host on network | ||
10.1.0.0. | 10.1.0.0. | ||
+ | |||
Specify the exit interface and the next-hop address to minimize table | Specify the exit interface and the next-hop address to minimize table | ||
lookups associated with finding the exit interface for a specified next-hop | lookups associated with finding the exit interface for a specified next-hop | ||
Line 198: | Line 166: | ||
S | S | ||
10.1.0.0 is directly connected, Ethernet0 | 10.1.0.0 is directly connected, Ethernet0 | ||
− | Tigger#show arp | + | |
− | Protocol | + | Tigger#show arp |
− | Address | + | Protocol |
− | Internet | + | Address |
− | 192.168.1.193 | + | Internet |
− | Internet | + | 192.168.1.193 |
− | 10.1.8.1 | + | Internet |
− | Internet | + | 10.1.8.1 |
− | 192.168.1.194 | + | Internet |
− | Internet | + | 192.168.1.194 |
− | 10.1.5.5 | + | Internet |
− | Internet | + | 10.1.5.5 |
− | 10.1.1.1 | + | Internet |
− | Tigger# | + | 10.1.1.1 |
− | Age (min) | + | Tigger# |
− | - | + | Age (min) |
− | 0 | + | - |
− | 24 | + | 0 |
− | 0 | + | 24 |
− | 0 | + | 0 |
− | Hardware Addr | + | 0 |
− | 0004.c150.f1c0 | + | Hardware Addr |
− | 0010.7b38.37d5 | + | 0004.c150.f1c0 |
− | 0010.7b38.37d5 | + | 0010.7b38.37d5 |
− | 0010.7b38.37d5 | + | 0010.7b38.37d5 |
− | 0010.7b38.37d5 | + | 0010.7b38.37d5 |
− | Type | + | 0010.7b38.37d5 |
− | ARPA | + | Type |
− | ARPA | + | ARPA |
− | ARPA | + | ARPA |
− | ARPA | + | ARPA |
− | ARPA | + | ARPA |
− | Int | + | ARPA |
− | Eth | + | Int |
− | Eth | + | Eth |
− | Eth | + | Eth |
− | Eth | + | Eth |
− | Eth | + | Eth |
− | Tigger#show ip route static | + | Eth |
− | 10.0.0.0/16 is subnetted, 1 subnets | + | Tigger#show ip route static |
− | S | + | 10.0.0.0/16 is subnetted, 1 subnets |
− | 10.1.0.0 [1/0] via 192.168.1.194, Ethernet0 | + | S |
− | Tigger#show arp | + | 10.1.0.0 [1/0] via 192.168.1.194, Ethernet0 |
− | Protocol Address | + | Tigger#show arp |
− | Internet 192.168.1.193 | + | Protocol Address |
− | Internet 192.168.1.194 | + | Internet 192.168.1.193 |
− | Age (min) | + | Internet 192.168.1.194 |
− | - | + | Age (min) |
− | 22 | + | - |
− | Hardware Addr Type | + | 22 |
− | 0004.c150.f1c0 ARPA | + | Hardware Addr Type |
− | 0010.7b38.37d5 ARPA | + | 0004.c150.f1c0 ARPA |
− | The first route table and ARP cache show that the static route entry was | + | 0010.7b38.37d5 ARPA |
− | created with an exit interface and no next-hop address. The route is | + | |
− | directly connected and there are multiple ARP cache entries for | + | The first route table and ARP cache show that the static route entry was created with an exit interface and no next-hop address. The route is directly connected and there are multiple ARP cache entries for |
− | destinations on the 10.1.0.0 network. The MAC address for each entry is | + | destinations on the 10.1.0.0 network. The MAC address for each entry is the same. It is the hardware address of the router with IP address 192.168.1.194. The router is sending ARP replies for all hosts on the 10.1.0.0 network. As discussed in Chapter 1, this proxy ARP is enabled |
− | the same. It is the hardware address of the router with IP address | ||
− | 192.168.1.194. The router is sending ARP replies for all hosts on the | ||
− | 10.1.0.0 network. As discussed in Chapter 1, this proxy ARP is enabled | ||
by default in IOS. | by default in IOS. | ||
− | The second set of tables shows the route table and ARP cache when the | + | |
− | next-hop address is specified in addition to the exit interface. Notice the | + | The second set of tables shows the route table and ARP cache when the next-hop address is specified in addition to the exit interface. Notice the route is no longer directly connected. It is known via 192.168.1.194 and the exit interface is Ethernet 0. The ARP cache has no entries for thethe exit interface is Ethernet 0. The ARP cache has no entries for the 10.1.0.0 network, only for the addresses that actually exist on the directly connected network, including 192.168.1.194. |
− | route is no longer directly connected. It is known via 192.168.1.194 and | + | |
− | the exit interface is Ethernet 0. The ARP cache has no entries for thethe exit interface is Ethernet 0. The ARP cache has no entries for the | + | ==Case Study: Simple IPv6 Static Routes== |
− | 10.1.0.0 network, only for the addresses that actually exist on the directly | + | |
− | connected network, including 192.168.1.194. | + | IPv6 static routes are configured the same way as IPv4 static routes. The only difference is that the IPv6 prefix length of the destination network is entered rather than the dotted decimal form of the IPv4 network mask. |
− | Case Study: Simple IPv6 Static Routes | + | |
− | IPv6 static routes are configured the same way as IPv4 static routes. The | + | Unlike IPv4, however, IPv6 routing is not enabled by default. Before entering a static route, IPv6 must be enabled using the ipv6 unicast-routing command. As with IPv4, an IPv6 address must be configured on the exit interface and the interface must be up before the static entry will be added to the route table. The command used to create a static route is ipv6 route followed by the network to be entered into the route table, the length, in bits of the prefix, and the address of the next-hop router, or the |
− | only difference is that the IPv6 prefix length of the destination network is | ||
− | entered rather than the dotted decimal form of the IPv4 network mask. | ||
− | Unlike IPv4, however, IPv6 routing is not enabled by default. Before | ||
− | entering a static route, IPv6 must be enabled using the ipv6 unicast- | ||
− | routing command. As with IPv4, an IPv6 address must be configured on | ||
− | the exit interface and the interface must be up before the static entry will | ||
− | be added to the route table. The command used to create a static route is | ||
− | ipv6 route followed by the network to be entered into the route table, the | ||
− | length, in bits of the prefix, and the address of the next-hop router, or the | ||
exit interface to be used to reach this destination. | exit interface to be used to reach this destination. | ||
− | To specify the next-hop address in the static route entry, you need to | + | |
− | know what that address is. A detailed network drawing will help, but it | + | To specify the next-hop address in the static route entry, you need to know what that address is. A detailed network drawing will help, but it may be out of date because of the dynamic nature of the Interface ID portion of the addresses. When addressing the IPv6 network, if you specify interface IDs manually rather than using the automatically constructed EUI-64 format addresses, the next-hop address will be predictable. However, if the interfaces on the data link are configured to use EUI-64 interface IDs, you only specify the first 64 bits of the address. |
− | may be out of date because of the dynamic nature of the Interface ID | + | |
− | portion of the addresses. When addressing the IPv6 network, if you | + | The router determines the final 64 bits based on a MAC address. If a router is replaced, the new router will have different IPv6 addresses. (The first 64 bits will remain the same, but the final 64 bits will be different.) One way to identify the full 128-bit IPv6 address of a neighbor router is to use the Cisco Discovery Protocol (CDP) statistics. CDP displays information about neighboring routers, such as the router's hostname, router type, IOS, and the IP addresses configured on the remote end of the link. Example 3-7 displays one form of the show cdp command. |
− | specify interface IDs manually rather than using the automatically | + | |
− | constructed EUI-64 format addresses, the next-hop address will be | + | Example 3-7. Cisco Discovery Protocol can tell you a lot of information about a device's neighbors.information about a device's neighbors. |
− | predictable. However, if the interfaces on the data link are configured to | + | |
− | use EUI-64 interface IDs, you only specify the first 64 bits of the address. | + | Honeybee#show cdp neighbor detail |
− | The router determines the final 64 bits based on a MAC address. If a | + | ------------------------- |
− | router is replaced, the new router will have different IPv6 addresses. (The | + | Device ID: Honeytree |
− | first 64 bits will remain the same, but the final 64 bits will be different.) | + | Entry address(es): |
− | One way to identify the full 128-bit IPv6 address of a neighbor router is to | + | IP address: 10.4.6.2 |
− | use the Cisco Discovery Protocol (CDP) statistics. CDP displays | + | IPv6 address: FE80::2B0:64FF:FE30:1DE0 (link-local) |
− | information about neighboring routers, such as the router's hostname, | + | IPv6 address: FEC0::1:2B0:64FF:FE30:1DE0 (site-local) |
− | router type, IOS, and the IP addresses configured on the remote end of | + | Platform: cisco 2610, Capabilities: Router |
− | the link. Example 3-7 displays one form of the show cdp command. | + | Interface: Serial0/0.2, Port ID (outgoing port): Serial0/0.2 |
− | Example 3-7. Cisco Discovery Protocol can tell you a lot of | + | Holdtime : 146 sec |
− | information about a device's neighbors.information about a device's neighbors. | + | Version : |
− | Honeybee#show cdp neighbor detail | + | Cisco Internetwork Operating System Software |
− | ------------------------- | + | IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEAS |
− | Device ID: Honeytree | + | Copyright (c) 1986-2004 by cisco Systems, Inc. |
− | Entry address(es): | + | Compiled Wed 11-Feb-04 19:24 by kellythw |
− | IP address: 10.4.6.2 | + | advertisement version: 2 |
− | IPv6 address: FE80::2B0:64FF:FE30:1DE0 (link-local) | + | |
− | IPv6 address: FEC0::1:2B0:64FF:FE30:1DE0 (site-local) | + | Example 3-7 displays a lot of information about the neighbor router, including the router type, IOS, host name and IP addresses. The detail keyword is required to obtain all the information that is displayed. |
− | Platform: cisco 2610, Capabilities: Router | + | |
− | Interface: Serial0/0.2, Port ID (outgoing port): Serial0/0.2 | + | Another way to determine the IPv6 address of a link is to issue the show ipv6 interface command. This command displays the IPv6 information relevant to an interface. Example 3-8 shows the output from the |
− | Holdtime : 146 sec | ||
− | Version : | ||
− | Cisco Internetwork Operating System Software | ||
− | IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEAS | ||
− | Copyright (c) 1986-2004 by cisco Systems, Inc. | ||
− | Compiled Wed 11-Feb-04 19:24 by kellythw | ||
− | advertisement version: 2 | ||
− | Example 3-7 displays a lot of information about the neighbor router, | ||
− | including the router type, IOS, host name and IP addresses. The detail | ||
− | keyword is required to obtain all the information that is displayed. | ||
− | Another way to determine the IPv6 address of a link is to issue the show | ||
− | ipv6 interface command. This command displays the IPv6 information | ||
− | relevant to an interface. Example 3-8 shows the output from the | ||
command issued on Honeybee. | command issued on Honeybee. | ||
− | Example 3-8. show ipv6 interface displays IPv6 information | + | |
− | relevant to an interface, including the IPv6 EUI-64 | + | Example 3-8. show ipv6 interface displays IPv6 information relevant to an interface, including the IPv6 EUI-64 formatted addresses. |
− | formatted addresses.Honeybee#show ipv6 interface serial0/0.1 | + | |
− | Serial0/0.1 is up, line protocol is up | + | Honeybee#show ipv6 interface serial0/0.1 |
− | IPv6 is enabled, link-local address is FE80::204:C1FF:FE50:F1 | + | Serial0/0.1 is up, line protocol is up |
− | Description: Link to Piglet | + | IPv6 is enabled, link-local address is FE80::204:C1FF:FE50:F1 |
− | Global unicast address(es): | + | Description: Link to Piglet |
− | FEC0::3:204:C1FF:FE50:F1C0, subnet is FEC0:0:0:3::/64 | + | Global unicast address(es): |
− | Joined group address(es): | + | FEC0::3:204:C1FF:FE50:F1C0, subnet is FEC0:0:0:3::/64 |
− | FF02::1 | + | Joined group address(es): |
− | FF02::2 | + | FF02::1 |
− | FF02::1:FF30:1DE0 | + | FF02::2 |
+ | FF02::1:FF30:1DE0 | ||
+ | |||
Figure 3-3 shows a simple network with IPv6 addresses. [5] | Figure 3-3 shows a simple network with IPv6 addresses. [5] | ||
[5] | [5] | ||
− | The interface addresses are configured with EUI-64 addresses. The addresses, | + | |
− | therefore, are unique to each router based on MAC address. To reproduce the | + | The interface addresses are configured with EUI-64 addresses. The addresses, therefore, are unique to each router based on MAC address. To reproduce the configuration, you'd have to determine your router's interface addresses to use as the next hop. |
− | configuration, you'd have to determine your router's interface addresses to use as the | + | |
− | next hop. | ||
Figure 3-3. Static routing also works with IPv6. | Figure 3-3. Static routing also works with IPv6. | ||
− | [View full size image]Example 3-9 shows the commands for entering Honeypot's IPv6 static | + | |
− | routes. | + | [View full size image] |
+ | |||
+ | Example 3-9 shows the commands for entering Honeypot's IPv6 static routes. | ||
Example 3-9. Configuring Honeypot's IPv6 static routes. | Example 3-9. Configuring Honeypot's IPv6 static routes. | ||
− | ipv6 unicast-routing | + | |
− | interface serial 0/0.2 point-to-point | + | ipv6 unicast-routing |
− | ipv6 address fec0:0:0:3::/64 eui-64 | + | interface serial 0/0.2 point-to-point |
− | ipv6 route fec0::1:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 | + | ipv6 address fec0:0:0:3::/64 eui-64 |
− | ipv6 route fec0::a:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 | + | ipv6 route fec0::1:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 |
− | ipv6 route fec0::8:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 | + | ipv6 route fec0::a:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 |
+ | ipv6 route fec0::8:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 | ||
+ | |||
Example 3-10 and Example 3-11 show the route entries for the other two | Example 3-10 and Example 3-11 show the route entries for the other two | ||
routers, Honeytree and Honeybee, respectively. | routers, Honeytree and Honeybee, respectively. | ||
Example 3-10. Configuring IPv6 static routes for Honeytree. | Example 3-10. Configuring IPv6 static routes for Honeytree. | ||
− | ipv6 route fec0::8:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 | + | |
− | ipv6 route fec0::3:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 | + | ipv6 route fec0::8:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 |
− | ipv6 route fec0::5:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 | + | ipv6 route fec0::3:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 |
+ | ipv6 route fec0::5:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 | ||
+ | |||
Example 3-11. Configuring IPv6 static routes for Honeybee. | Example 3-11. Configuring IPv6 static routes for Honeybee. | ||
− | ipv6 route fec0::a:0:0:0:0/64 fec0::1:2b0:64ff:fe30:1de0 | + | |
− | ipv6 route fec0::5:0:0:0:0/64 fec0::3:230:94ff:fe24:b780 | + | ipv6 route fec0::a:0:0:0:0/64 fec0::1:2b0:64ff:fe30:1de0 |
− | Look at the next-hop address used for Honeypot's routes, and the next- | + | ipv6 route fec0::5:0:0:0:0/64 fec0::3:230:94ff:fe24:b780 |
− | hop address used for Honeytree's routes. Honeypot's next-hop addresshop address used for Honeytree's routes. Honeypot's next-hop address | + | |
− | for each route is fec0::3:204:c1ff:fe50:f1c0. The next-hop address used | + | Look at the next-hop address used for Honeypot's routes, and the next-hop address used for Honeytree's routes. Honeypot's next-hop addresshop address used for Honeytree's routes. Honeypot's next-hop address |
− | for Honeytree's routes is fec0::1:204:c1ff:fe50:f1c0. These addresses are | + | for each route is fec0::3:204:c1ff:fe50:f1c0. The next-hop address used for Honeytree's routes is fec0::1:204:c1ff:fe50:f1c0. These addresses are those of Honeybee's interfaces to Honeypot and Honeytree, respectively. Notice that the last 64 bits of each of Honeybee's interface addresses are the same. The router uses its first encountered MAC address to form the last 64 bits of the EUI-64 formatted IPv6 addresses on each of its serial interfaces. |
− | those of Honeybee's interfaces to Honeypot and Honeytree, respectively. | + | |
− | Notice that the last 64 bits of each of Honeybee's interface addresses are | + | As with IPv4, IPv6 static routes can use the outbound interface rather than next-hop address. There is an option to enter an address after the interface as there is with IPv4. You can put either the link-local address here or a configured address. This next-hop address should be used when the exit interface is a broadcast interface, such as Ethernet. |
− | the same. The router uses its first encountered MAC address to form the | + | |
− | last 64 bits of the EUI-64 formatted IPv6 addresses on each of its serial | + | Example 3-12 displays Honeypot's IPv6 route table with only the next-hop address specified in the ipv6 route statement. The command show ipv6 route displays the IPv6 route table. Prefixes, prefix lengths, and the next-hop address or outgoing interface are displayed, as are the administrative distance and route metric. |
− | interfaces. | + | |
− | As with IPv4, IPv6 static routes can use the outbound interface rather | + | Example 3-12. As with IPv4, the IPv6 static route table displays the destination network and the next-hop address used to reach the destination. |
− | than next-hop address. There is an option to enter an address after the | + | |
− | interface as there is with IPv4. You can put either the link-local address | + | Honeypot#show ipv6 route |
− | here or a configured address. This next-hop address should be used | + | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP |
− | when the exit interface is a broadcast interface, such as Ethernet. | + | U - Per-user Static route |
− | Example 3-12 displays Honeypot's IPv6 route table with only the next- | + | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS |
− | hop address specified in the ipv6 route statement. The command show | + | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - |
− | ipv6 route displays the IPv6 route table. Prefixes, prefix lengths, and the | + | ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 |
− | next-hop address or outgoing interface are displayed, as are the | + | L |
− | administrative distance and route metric. | + | C |
− | Example 3-12. As with IPv4, the IPv6 static route table | + | FE80::/10 [0/0] |
− | displays the destination network and the next-hop address | + | via ::, Null0 |
− | used to reach the destination. | + | FEC0:0:0:3::/64 [0/0] |
− | Honeypot#show ipv6 route | + | via ::, Serial0/0.2L |
− | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP | + | S |
− | U - Per-user Static route | + | S |
− | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS | + | S |
− | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - | + | C |
− | ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 | + | L |
− | L | + | L |
− | C | + | FEC0::3:230:94FF:FE24:B780/128 [0/0] |
− | FE80::/10 [0/0] | + | via ::, Serial0/0.2 |
− | via ::, Null0 | + | FEC0:0:0:A::/64 [1/0] |
− | FEC0:0:0:3::/64 [0/0] | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | via ::, Serial0/0.2L | + | FEC0:0:0:8::/64 [1/0] |
− | S | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | S | + | FEC0:0:0:1::/64 [1/0] |
− | S | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | C | + | FEC0:0:0:5::/64 [0/0] |
− | L | + | via ::, Ethernet0/0 |
− | L | + | FEC0::5:230:94FF:FE24:B780/128 [0/0] |
− | FEC0::3:230:94FF:FE24:B780/128 [0/0] | + | via ::, Ethernet0/0 |
− | via ::, Serial0/0.2 | + | FF00::/8 [0/0] |
− | FEC0:0:0:A::/64 [1/0] | + | via ::, Null0 |
− | via FEC0::3:204:C1FF:FE50:F1C0 | + | |
− | FEC0:0:0:8::/64 [1/0] | + | The static routes displayed in Example 3-12 were entered using an IPv6 next-hop address. The router must determine the exit interface associated with this IPv6 address recursively, as it does with IPv4. The entry for FEC0:0:0:A::/64 has a next-hop address of FEC0::3:204:C1FF:FE50:F1C0. Looking further into the route table, FEC0:0:0:3::/64 is connected on Serial0/0.2. Notice that the administrative distance of the static routes entered with the next-hop IPv6 address is 1 and the route metric is 0, the same as IPv4 static route entered in this way. |
− | via FEC0::3:204:C1FF:FE50:F1C0 | + | |
− | FEC0:0:0:1::/64 [1/0] | + | Routes can also be entered with the outgoing interface toward the destination network. The outgoing interface and the next-hop address can be entered together, too. Example 3-13 shows what Honeypot's static route configuration could be changed to. Example 3-13. Alternative static route configuration for |
− | via FEC0::3:204:C1FF:FE50:F1C0 | ||
− | FEC0:0:0:5::/64 [0/0] | ||
− | via ::, Ethernet0/0 | ||
− | FEC0::5:230:94FF:FE24:B780/128 [0/0] | ||
− | via ::, Ethernet0/0 | ||
− | FF00::/8 [0/0] | ||
− | via ::, Null0 | ||
− | The static routes displayed in Example 3-12 were entered using an IPv6 | ||
− | next-hop address. The router must determine the exit interface | ||
− | associated with this IPv6 address recursively, as it does with IPv4. The | ||
− | entry for FEC0:0:0:A::/64 has a next-hop address of | ||
− | FEC0::3:204:C1FF:FE50:F1C0. Looking further into the route table, | ||
− | FEC0:0:0:3::/64 is connected on Serial0/0.2. Notice that the | ||
− | administrative distance of the static routes entered with the next-hop IPv6 | ||
− | address is 1 and the route metric is 0, the same as IPv4 static route | ||
− | entered in this way. | ||
− | Routes can also be entered with the outgoing interface toward the | ||
− | destination network. The outgoing interface and the next-hop address | ||
− | can be entered together, too. Example 3-13 shows what Honeypot's | ||
− | static route configuration could be changed to. | ||
− | Example 3-13. Alternative static route configuration for | ||
Honeypot. | Honeypot. | ||
− | ipv6 route fec0::a:0:0:0:0/64 serial 0/0.2ipv6 route fec0::8:0:0:0:0/64 serial 0/0.2 | + | |
− | ipv6 route fec0::1:0:0:0:0/64 serial 0/0.2 | + | ipv6 route fec0::a:0:0:0:0/64 serial 0/0.2ipv6 route fec0::8:0:0:0:0/64 serial 0/0.2 |
− | ipv6 route fec0::20:0:0:0:0/62 Ethernet0/0 FE80::2B0:64FF:FE30: | + | ipv6 route fec0::1:0:0:0:0/64 serial 0/0.2 |
− | The last entry, using the exit interface and the next-hop address will help | + | ipv6 route fec0::20:0:0:0:0/62 Ethernet0/0 FE80::2B0:64FF:FE30: |
− | to illustrate the difference in the route table between the two forms of the | + | |
− | command. Example 3-14 displays Honeypot's new route table. | + | The last entry, using the exit interface and the next-hop address will help to illustrate the difference in the route table between the two forms of the command. Example 3-14 displays Honeypot's new route table. |
− | Example 3-14. Honeypot route table after changing the next | + | |
− | hop to the exit interface. | + | Example 3-14. Honeypot route table after changing the next hop to the exit interface. |
− | Honeypot#show ipv6 route static | + | |
− | S | + | Honeypot#show ipv6 route static |
− | S | + | S |
− | S | + | S |
− | S | + | S |
− | FEC0:0:0:A::/64 [1/0] | + | S |
− | via ::, Serial0/0.2 | + | FEC0:0:0:A::/64 [1/0] |
− | FEC0:0:0:8::/64 [1/0] | + | via ::, Serial0/0.2 |
− | via ::, Serial0/0.2 | + | FEC0:0:0:8::/64 [1/0] |
− | FEC0:0:0:1::/64 [1/0] | + | via ::, Serial0/0.2 |
− | via ::, Serial0/0.2 | + | FEC0:0:0:1::/64 [1/0] |
− | FEC0:0:0:20::/62 [1/0] | + | via ::, Serial0/0.2 |
− | via FE80::2B0:64FF:FE30:1DE0, Ethernet0/0 | + | FEC0:0:0:20::/62 [1/0] |
− | One thing to notice in the route table is the administrative distance of the | + | via FE80::2B0:64FF:FE30:1DE0, Ethernet0/0 |
− | static route configured with an exit interface. The distance is 1, unlike | + | |
− | IPv4 static routes configured the same way. The route does not appear to | + | One thing to notice in the route table is the administrative distance of the static route configured with an exit interface. The distance is 1, unlike IPv4 static routes configured the same way. The route does not appear to be directly connected as it does with IPv4. |
− | be directly connected as it does with IPv4. | + | |
− | The next-hop address is undetermined when you enter the outbound | + | The next-hop address is undetermined when you enter the outbound interface unless you specify the exit interface and the next-hop address. You can see this in the route table shown in Example 3-14. The first |
− | interface unless you specify the exit interface and the next-hop address. | + | statement, for instance, says that FEC0:0:0:A::/64 is known via ::, Serial 0/0.2. The "::" means that the next hop is unspecified, but the outgoinginterface is Serial 0/0.2. On a point-to-point serial interface, an unspecified next-hop address is not a problem. There is only one other device on that point-to-point network, and all packets are forwarded out the interface and reach the other device. |
− | You can see this in the route table shown in Example 3-14. The first | + | |
− | statement, for instance, says that FEC0:0:0:A::/64 is known via ::, Serial | + | |
− | 0/0.2. The "::" means that the next hop is unspecified, but the outgoinginterface is Serial 0/0.2. On a point-to-point serial interface, an | + | On a broadcast interface, the router must find a neighbor to which to send the packet. The router multicasts a neighbor solicitation message on the Ethernet and waits for a neighbor advertisement from the next-hop device. There is no defined proxy address resolution mechanism with IPv6, other than for mobile IPv6 nodes. A router on the Ethernet that has a route to the destination will not respond to a neighbor solicitation on behalf of another device. |
− | unspecified next-hop address is not a problem. There is only one other | + | |
− | device on that point-to-point network, and all packets are forwarded out | + | For this reason, when using an exit interface to configure a static route on a broadcast network, a next-hop address must also be specified. The recommended address to use as the next-hop address is the link-local address of the next-hop router. One reason to use the link-local address is that it is not likely to change. A link-local address will only change if the interface card, or the entire router, is replaced. Even if the site is renumbered with a different IPv6 global prefix, the link-local address on the interface does not change. Another reason to use the link-local address as the next hop is to remain consistent with the addresses routers advertise in the router advertisement messages and so that processes using those addresses, such as ICMPv6 Redirect, will operate as expected. |
− | the interface and reach the other device. | + | |
− | On a broadcast interface, the router must find a neighbor to which to | + | Routers advertise their presence, along with their link-local addresses, to all IPv6 devices on broadcast networks. Hosts use the router list created from the router advertisement to determine how to forward packets off the network. If a host forwards a packet to a router, and that router knows that a second router on the network is a better choice for the host to use, the first router will send a redirect to the host. The redirect includes the link-local IPv6 address of the better choice router. When the host processes the redirect, if the better router is in its router list, the host will begin to forward packets to the better router. If the better router is not in the list (or it is listed by a different IPv6 address), the host will discard the redirect. |
− | send the packet. The router multicasts a neighbor solicitation message | + | |
− | on the Ethernet and waits for a neighbor advertisement from the next-hop | + | |
− | device. There is no defined proxy address resolution mechanism with | + | ==Case Study: Summary Routes== |
− | IPv6, other than for mobile IPv6 nodes. A router on the Ethernet that has | + | |
− | a route to the destination will not respond to a neighbor solicitation on | + | |
− | behalf of another device. | + | A summary route is an address that encompasses several more specific addresses in a route table. It is the address mask used with a route entry that makes static routes as flexible as they are; by using an appropriate address mask, it is sometimes possible to create a single summary route for several destination addresses. |
− | For this reason, when using an exit interface to configure a static route on | + | |
− | a broadcast network, a next-hop address must also be specified. The | + | For example, the preceding two case studies use a separate entry for each data link. The mask of each entry corresponds to the address mask used on the device interfaces connected to that data link. Looking again at Figure 3-2, you can see that subnets 10.4.6.0/24 and 10.4.7.0/24 could be specified to Piglet with a single entry of 10.4.0.0/16, reachable via Tigger. Likewise, subnets 192.168.1.0/27 and 192.168.1.64/27 could be accounted for in its route table with a single entry pointing to 192.168.1.0/24, also reachable via Tigger. These two route entries, 10.4.0.0/16 and 192.16.1.0/24, are summary routes. |
− | recommended address to use as the next-hop address is the link-local | + | |
− | address of the next-hop router. One reason to use the link-local address | + | Using summary routes, Piglet's static route entries are displayed in Example 3-15. |
− | is that it is not likely to change. A link-local address will only change if the | + | |
− | interface card, or the entire router, is replaced. Even if the site is | + | Example 3-15. Piglet's static route entries are summarized into only two entries. |
− | renumbered with a different IPv6 global prefix, the link-local address on | + | |
− | the interface does not change. Another reason to use the link-local | + | ip route 192.168.1.0 255.255.255.0 192.168.1.193 |
− | address as the next hop is to remain consistent with the addresses | + | ip route 10.4.0.0 255.255.0.0 192.168.1.193 |
− | routers advertise in the router advertisement messages and so that | + | |
− | processes using those addresses, such as ICMPv6 Redirect, will operate | + | All subnets of network 10.0.0.0 are reachable from Pooh via Tigger, so a single entry to that major network address and a corresponding mask are all that is needed (see Example 3-16). |
− | as expected. | + | |
− | Routers advertise their presence, along with their link-local addresses, to | + | Example 3-16. Pooh's static route entries for all of network 10.0.0.0 subnets are summarized into a single entry.10.0.0.0 subnets are summarized into a single entry. |
− | all IPv6 devices on broadcast networks. Hosts use the router list created | + | |
− | from the router advertisement to determine how to forward packets off | + | ip route 192.168.1.192 255.255.255.224 192.168.1.66 |
− | the network. If a host forwards a packet to a router, and that router knows | + | ip route 10.0.0.0 255.0.0.0 192.168.1.66 |
− | that a second router on the network is a better choice for the host to use, | + | |
− | the first router will send a redirect to the host. The redirect includes the | + | From Eeyore, all destination addresses beginning with 192 are reachable via Tigger. The single route entry does not even have to specify all of the Class C address bits [6] , as displayed in Example 3-17. |
− | link-local IPv6 address of the better choice router. When the host | ||
− | processes the redirect, if the better router is in its router list, the host will | ||
− | begin to forward packets to the better router. If the better router is not in | ||
− | the list (or it is listed by a different IPv6 address), the host will discard the | ||
− | redirect.Case Study: Summary Routes | ||
− | A summary route is an address that encompasses several more specific | ||
− | addresses in a route table. It is the address mask used with a route entry | ||
− | that makes static routes as flexible as they are; by using an appropriate | ||
− | address mask, it is sometimes possible to create a single summary route | ||
− | for several destination addresses. | ||
− | For example, the preceding two case studies use a separate entry for | ||
− | each data link. The mask of each entry corresponds to the address mask | ||
− | used on the device interfaces connected to that data link. Looking again | ||
− | at Figure 3-2, you can see that subnets 10.4.6.0/24 and 10.4.7.0/24 could | ||
− | be specified to Piglet with a single entry of 10.4.0.0/16, reachable via | ||
− | Tigger. Likewise, subnets 192.168.1.0/27 and 192.168.1.64/27 could be | ||
− | accounted for in its route table with a single entry pointing to | ||
− | 192.168.1.0/24, also reachable via Tigger. These two route entries, | ||
− | 10.4.0.0/16 and 192.16.1.0/24, are summary routes. | ||
− | Using summary routes, Piglet's static route entries are displayed in | ||
− | Example 3-15. | ||
− | Example 3-15. Piglet's static route entries are summarized | ||
− | into only two entries. | ||
− | ip route 192.168.1.0 255.255.255.0 192.168.1.193 | ||
− | ip route 10.4.0.0 255.255.0.0 192.168.1.193 | ||
− | All subnets of network 10.0.0.0 are reachable from Pooh via Tigger, so a | ||
− | single entry to that major network address and a corresponding mask are | ||
− | all that is needed (see Example 3-16). | ||
− | Example 3-16. Pooh's static route entries for all of network | ||
− | 10.0.0.0 subnets are summarized into a single entry.10.0.0.0 subnets are summarized into a single entry. | ||
− | ip route 192.168.1.192 255.255.255.224 192.168.1.66 | ||
− | ip route 10.0.0.0 255.0.0.0 192.168.1.66 | ||
− | From Eeyore, all destination addresses beginning with 192 are reachable | ||
− | via Tigger. The single route entry does not even have to specify all of the | ||
− | Class C address bits [6] , as displayed in Example 3-17. | ||
[6] | [6] | ||
− | This method of summarizing a group of major network addresses with a mask shorter | + | |
− | than the default address mask for that class is known as supernetting. This is introduced | + | This method of summarizing a group of major network addresses with a mask shorter than the default address mask for that class is known as supernetting. This is introduced in Chapter 6. |
− | in Chapter 6. | + | |
− | Example 3-17. Eeyore summarizes all routes beginning | + | Example 3-17. Eeyore summarizes all routes beginning with 192 into a single entry. |
− | with 192 into a single entry. | + | |
− | ip route 192.0.0.0 255.0.0.0 10.4.6.1 | + | ip route 192.0.0.0 255.0.0.0 10.4.6.1 |
− | ip route 10.1.0.0 255.255.0.0 10.4.6.1 | + | ip route 10.1.0.0 255.255.0.0 10.4.6.1 |
− | Summary routes can also be applied to the IPv6 destination addresses in | + | |
− | Figure 3-3. | + | Summary routes can also be applied to the IPv6 destination addresses in Figure 3-3. |
− | Honeypot's two static routes can be summarized into a group consisting | + | |
− | of fec0:0:0:8:: through fec0:0:0:b:: by changing the prefix length from 64 | + | Honeypot's two static routes can be summarized into a group consisting of fec0:0:0:8:: through fec0:0:0:b:: by changing the prefix length from 64 to 62, as in Example 3-18. |
− | to 62, as in Example 3-18. | + | |
Example 3-18. Honeypot summarizes IPv6 static routes. | Example 3-18. Honeypot summarizes IPv6 static routes. | ||
− | ipv6 route fec0::8:0:0:0:0/62 fec0::3:204:c1ff:fe50: | + | |
− | of static route entries may be reduced drasticallyin this example, by more | + | ipv6 route fec0::8:0:0:0:0/62 fec0::3:204:c1ff:fe50:f1c0 |
− | than one-third. However, caution must be used when summarizing | + | |
− | addresses; when done incorrectly, unexpected routing behavior may | + | By summarizing a group of subnets or even major networks, the number of static route entries may be reduced drasticallyin this example, by more than one-third. However, caution must be used when summarizing addresses; when done incorrectly, unexpected routing behavior may |
occur (see "Case Study: Tracing a Failed Route," later in this chapter). | occur (see "Case Study: Tracing a Failed Route," later in this chapter). | ||
− | Summarization and the problems that can develop from incorrect | + | |
− | summarization are examined in more depth in Chapters 7, "Enhanced | + | Summarization and the problems that can develop from incorrect summarization are examined in more depth in Chapters 7, "Enhanced Interior Gateway Routing Protocol (EIGRP)," and 8, "OSPFv2." |
− | Interior Gateway Routing Protocol (EIGRP)," and 8, "OSPFv2." | + | |
− | Case Study: Alternative Routes | + | ==Case Study: Alternative Routes== |
− | In Figure 3-4, a new link has been added between Pooh and Eeyore. All | + | |
− | packets from Pooh to the 10.0.0.0 networks will take this new path with | + | In Figure 3-4, a new link has been added between Pooh and Eeyore. All packets from Pooh to the 10.0.0.0 networks will take this new path with the exception of packets destined for the host 10.4.7.25; a policy is in place stating that traffic to this host must go through Tigger. The static route commands at Pooh will be as displayed in Example 3-19. |
− | the exception of packets destined for the host 10.4.7.25; a policy is in | + | |
− | place stating that traffic to this host must go through Tigger. The static | + | Figure 3-4. A more direct path from Pooh to the 10.4.0.0 subnets is added to the network. |
− | route commands at Pooh will be as displayed in Example 3-19. | + | |
− | Figure 3-4. A more direct path from Pooh to the 10.4.0.0 | + | [View full size image] |
− | subnets is added to the network. | + | |
− | [View full size image]Example 3-19. Pooh's static route commands help | + | Example 3-19. Pooh's static route commands help implement a policy directing traffic through specific |
− | implement a policy directing traffic through specific | ||
routers. | routers. | ||
− | ip route 192.168.1.192 255.255.255.224 192.168.1.66 | + | |
− | ip route 10.0.0.0 255.0.0.0 192.168.1.34 | + | ip route 192.168.1.192 255.255.255.224 192.168.1.66 |
− | ip route 10.4.7.25 255.255.255.255 192.168.1.66 | + | ip route 10.0.0.0 255.0.0.0 192.168.1.34 |
− | The first two route entries are the same as before except that the second | + | ip route 10.4.7.25 255.255.255.255 192.168.1.66 |
− | path now points to the new interface 192.168.1.34 at Eeyore. The third | + | |
− | entry is a host route, pointing to the single host 10.4.7.25 and made | + | The first two route entries are the same as before except that the second path now points to the new interface 192.168.1.34 at Eeyore. The third entry is a host route, pointing to the single host 10.4.7.25 and made possible by setting the address mask to all ones. Notice that unlike the entry for the other 10.0.0.0 subnets, this host route points to Tigger's interface 192.168.1.66. |
− | possible by setting the address mask to all ones. Notice that unlike the | + | |
− | entry for the other 10.0.0.0 subnets, this host route points to Tigger's | + | The debugging function debug ip packet is turned on in Pooh (see Example 3-20) to observe the paths packets take from the router as a result of the new route entries. A packet is sent from a host 192.168.1.15 to host 10.4.7.25. The first two debug trap messages show that the packet is routed from interface E0 to the next-hop router 192.168.1.66 (Tigger) out interface S0, as required, and that the reply packet was received on S0 and routed to the host 192.168.1.15 out E0. |
− | interface 192.168.1.66. | + | |
− | The debugging function debug ip packet is turned on in Pooh (see | + | Example 3-20. Debugging verifies that the new route entries at Pooh are working correctly. |
− | Example 3-20) to observe the paths packets take from the router as a | + | |
− | result of the new route entries. A packet is sent from a host 192.168.1.15 | + | Pooh#debug ip packet |
− | to host 10.4.7.25. The first two debug trap messages show that the | + | |
− | packet is routed from interface E0 to the next-hop router 192.168.1.66 | ||
− | (Tigger) out interface S0, as required, and that the reply packet was | ||
− | received on S0 and routed to the host 192.168.1.15 out E0. | ||
− | Example 3-20. Debugging verifies that the new route | ||
− | entries at Pooh are working correctly. | ||
− | Pooh#debug ip packet | ||
IP packet debugging is on | IP packet debugging is on | ||
− | Pooh# | + | |
− | IP: s=192.168.1.15 (Ethernet0), d=10.4.7.25 (Serial0), g=192.16 | + | Pooh# |
− | IP: s=10.4.7.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.16 | + | IP: s=192.168.1.15 (Ethernet0), d=10.4.7.25 (Serial0), g=192.16 |
− | Pooh# | + | IP: s=10.4.7.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.16 |
− | IP: s=192.168.1.15 (Ethernet0), d=10.4.7.100 (Serial1), g=192.1IP: s=10.4.7.100 (Serial0), d=192.168.1.15 (Ethernet0), g=192.1 | + | Pooh# |
− | Pooh# | + | IP: s=192.168.1.15 (Ethernet0), d=10.4.7.100 (Serial1), g=192.1IP: s=10.4.7.100 (Serial0), d=192.168.1.15 (Ethernet0), g=192.1 |
− | Next, a packet is sent from host 192.168.1.15 to host 10.4.7.100. Packets | + | Pooh# |
− | destined for any host on 10.0.0.0 subnets, other than host 10.4.7.25, | + | |
− | should be routed across the new link to Eeyore's interface 192.186.1.34. | + | Next, a packet is sent from host 192.168.1.15 to host 10.4.7.100. Packets destined for any host on 10.0.0.0 subnets, other than host 10.4.7.25, should be routed across the new link to Eeyore's interface 192.186.1.34. |
− | The third debug message verifies that this is indeed happening. | + | |
− | However, the fourth message shows something that at first might be | + | The third debug message verifies that this is indeed happening. However, the fourth message shows something that at first might be surprising. The response from 10.4.7.100 to 192.168.1.15 arrived on |
− | surprising. The response from 10.4.7.100 to 192.168.1.15 arrived on | ||
Pooh's interface S0 from Tigger. | Pooh's interface S0 from Tigger. | ||
− | Remember that the route entries in the other routers have not changed | + | |
− | from the original example. This result might or might not be desired, but it | + | Remember that the route entries in the other routers have not changed from the original example. This result might or might not be desired, but it does illustrate two characteristics of static routes: |
− | does illustrate two characteristics of static routes: | + | |
− | First, if the network topology changes, the routers that are required | + | First, if the network topology changes, the routers that are required to know about those changes must be reconfigured. |
− | to know about those changes must be reconfigured. | + | Second, static routes can be used to create very specific routing behavior. In this example, perhaps it is desirable to have traffic taking one path in one direction and another path in the opposite |
− | Second, static routes can be used to create very specific routing | ||
− | behavior. In this example, perhaps it is desirable to have traffic | ||
− | taking one path in one direction and another path in the opposite | ||
direction. | direction. | ||
− | A final observation about this example is that packets routed from Pooh | + | |
− | to subnet 10.1.5.0 take a less-than-optimal route, from Pooh to Eeyore to | + | A final observation about this example is that packets routed from Pooh to subnet 10.1.5.0 take a less-than-optimal route, from Pooh to Eeyore to Tigger instead of directly from Pooh to Tigger. Example 3-21 shows a more efficient configuration for Router Pooh. |
− | Tigger instead of directly from Pooh to Tigger. Example 3-21 shows a | + | |
− | more efficient configuration for Router Pooh. | + | Example 3-21. Configuring a more efficient static route on Router Pooh. |
− | Example 3-21. Configuring a more efficient static route on | + | |
− | Router Pooh. | + | ip route 192.168.1.192 255.255.255.224 192.168.1.66 |
− | ip route 192.168.1.192 255.255.255.224 192.168.1.66 | + | ip route 10.0.0.0 255.0.0.0 192.168.1.34ip route 10.1.0.0 255.255.0.0 192.168.1.66 |
− | ip route 10.0.0.0 255.0.0.0 192.168.1.34ip route 10.1.0.0 255.255.0.0 192.168.1.66 | + | ip route 10.4.7.25 255.255.255.255 192.168.1.66 |
− | ip route 10.4.7.25 255.255.255.255 192.168.1.66 | + | |
− | The third entry will now send all packets for subnet 10.1.5.0 directly to | + | The third entry will now send all packets for subnet 10.1.5.0 directly to Tigger. |
− | Tigger. | + | |
− | Case Study: Floating Static Routes | + | ==Case Study: Floating Static Routes== |
− | Unlike other static routes, a floating static route is less preferred than | + | |
− | other routes in the route table. It appears in the table only under the | + | Unlike other static routes, a floating static route is less preferred than other routes in the route table. It appears in the table only under the special circumstance of the failure of a more-preferred route. |
− | special circumstance of the failure of a more-preferred route. | + | |
− | In Figure 3-5, a new router (Rabbit) is connected to Piglet with two | + | In Figure 3-5, a new router (Rabbit) is connected to Piglet with two parallel links. One link connects their respective Serial 0 interfaces, and the second connection has been added between the two Serial 1 |
− | parallel links. One link connects their respective Serial 0 interfaces, and | + | interfaces. This second link has been added for redundancy: If the primary link 10.1.10.0 fails, floating static routes will direct traffic across the backup link 10.1.20.0. |
− | the second connection has been added between the two Serial 1 | + | |
− | interfaces. This second link has been added for redundancy: If the | + | Figure 3-5. A new router has been connected to Piglet. Two serial links are used: one for the primary link and one for the backup link. |
− | primary link 10.1.10.0 fails, floating static routes will direct traffic across | + | |
− | the backup link 10.1.20.0. | + | [View full size image] |
− | Figure 3-5. A new router has been connected to Piglet. Two | + | |
− | serial links are used: one for the primary link and one for | + | Additionally, the mask on Piglet's Ethernet interface has changed from 10.1.5.1/16 to 10.1.5.1/24. This change allows the single route entry at Tigger |
− | the backup link. | + | |
− | [View full size image]Additionally, the mask on Piglet's Ethernet interface has changed from | + | ip route 10.1.0.0 255.255.0.0 192.168.1.194 |
− | 10.1.5.1/16 to 10.1.5.1/24. This change allows the single route entry at | + | |
− | + | to point not only to 10.1.5.0 but also to all of the new subnets used in association with the new router. | |
− | ip route 10.1.0.0 255.255.0.0 192.168.1.194 | + | |
− | to point not only to 10.1.5.0 but also to all of the new subnets used in | + | To create the floating static route, Example 3-22 and Example 3-23 show the route entries for both Piglet and Rabbit, respectively. Example 3-22. Route entries for Piglet to create a floating |
− | association with the new router. | ||
− | To create the floating static route, Example 3-22 and Example 3-23 show | ||
− | the route entries for both Piglet and Rabbit, respectively. | ||
− | Example 3-22. Route entries for Piglet to create a floating | ||
static route. | static route. | ||
− | ip | + | |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | route | + | ip |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | 192.168.1.0 255.255.255.0 192.168.1.193 | + | route |
− | 10.4.0.0 255.255.0.0 192.168.1.193 | + | 192.168.1.0 255.255.255.0 192.168.1.193 |
− | 10.1.30.0 255.255.255.0 10.1.10.2 | + | 10.4.0.0 255.255.0.0 192.168.1.193 |
− | 10.1.30.0 255.255.255.0 10.1.20.2 50 | + | 10.1.30.0 255.255.255.0 10.1.10.2 |
− | Example 3-23. Route entries for Rabbit to create a floatingExample 3-23. Route entries for Rabbit to create a floating | + | 10.1.30.0 255.255.255.0 10.1.20.2 50 |
− | static route. | + | |
− | ip | + | Example 3-23. Route entries for Rabbit to create a floatingExample 3-23. Route entries for Rabbit to create a floating static route. |
− | ip | + | |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | route | + | ip |
− | route | + | ip |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | 10.4.0.0 255.255.0.0 10.1.10.1 | + | route |
− | 10.4.0.0 255.255.0.0 10.1.20.1 50 | + | route |
− | 10.1.5.0 255.255.255.0 10.1.10.1 | + | 10.4.0.0 255.255.0.0 10.1.10.1 |
− | 10.1.5.0 255.255.255.0 10.1.20.1 50 | + | 10.4.0.0 255.255.0.0 10.1.20.1 50 |
− | 192.168.0.0 255.255.0.0 10.1.10.1 | + | 10.1.5.0 255.255.255.0 10.1.10.1 |
− | 192.168.0.0 255.255.0.0 10.1.20.1 50 | + | 10.1.5.0 255.255.255.0 10.1.20.1 50 |
− | Two entries at Piglet point to Rabbit's network 10.1.30.0; one specifies a | + | 192.168.0.0 255.255.0.0 10.1.10.1 |
− | next-hop address of Rabbit's S0 interface, and the other specifies a next- | + | 192.168.0.0 255.255.0.0 10.1.20.1 50 |
− | hop address of Rabbit's S1 interface. Rabbit has similar double entries | + | |
− | for every route. | + | Two entries at Piglet point to Rabbit's network 10.1.30.0; one specifies a next-hop address of Rabbit's S0 interface, and the other specifies a next-hop address of Rabbit's S1 interface. Rabbit has similar double entries for every route. |
− | Notice that all static routes using subnet 10.1.20.0 are followed by a 50. | + | |
− | This number specifies an administrative distance, which is a measure of | + | Notice that all static routes using subnet 10.1.20.0 are followed by a 50. This number specifies an administrative distance, which is a measure of preferability; when duplicate paths to the same network are known, the router will prefer the path with the lower administrative distance. At first this idea sounds like a metric; however, a metric specifies the preferability of a route, whereas an administrative distance specifies the preferability of the means by which the route was discovered. |
− | preferability; when duplicate paths to the same network are known, the | + | |
− | router will prefer the path with the lower administrative distance. At first | + | For example, IPv4 static routes pointing to a next-hop address have an administrative distance of 1, and static routes referencing an exit interface have an administrative distance of 0. If two static routes point to the same destination, but one references a next-hop address and one references an exit interface, the latterwith the lower administrative distance will be preferred. |
− | this idea sounds like a metric; however, a metric specifies the | + | |
− | preferability of a route, whereas an administrative distance specifies the | + | By increasing the administrative distances of the static routes traversing subnet 10.1.20.0 to 50, they become less preferred than the routes traversing subnet 10.1.10.0. Example 3-24 shows three iterations of Rabbit's route table. In the first table, all routes to non connected networks use a next-hop address of 10.1.10.1. The bracketed numbers associated with each route indicate an administrative distance of 1 and a metric of 0 (because no metrics are associated with static routes). |
− | preferability of the means by which the route was discovered. | + | |
− | For example, IPv4 static routes pointing to a next-hop address have an | + | Example 3-24. When the primary link 10.1.10.0 fails, the backup link 10.1.20.0 is used. When the primary link is restored, it is again the preferred path. |
− | administrative distance of 1, and static routes referencing an exit | + | |
− | interface have an administrative distance of 0. If two static routes point to | + | Rabbit#show ip route |
− | the same destination, but one references a next-hop address and one | + | 10.0.0.0 is variably subnetted, 5 subnets, 2 masks |
− | references an exit interface, the latterwith the lower administrative | + | C 10.1.10.0 255.255.255.0 is directly connected, Serial0 |
− | + | S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 | |
− | By increasing the administrative distances of the static routes traversing | + | S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 |
− | subnet 10.1.20.0 to 50, they become less preferred than the routes | + | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 |
− | traversing subnet 10.1.10.0. Example 3-24 shows three iterations of | + | C 10.1.20.0 255.255.255.0 is directly connected, Serial1 |
− | Rabbit's route table. In the first table, all routes to | + | S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 |
− | networks use a next-hop address of 10.1.10.1. The bracketed | + | Rabbit# |
− | metric of 0 (because no metrics are associated with static routes). | + | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change |
− | Example 3-24. When the primary link 10.1.10.0 fails, the | + | %LINK-3-UPDOWN: Interface Serial0, changed state to down |
− | backup link 10.1.20.0 is used. When the primary link is | + | Rabbit#show ip route |
− | restored, it is again the preferred path. | + | 10.0.0.0 is variably subnetted, 4 subnets, 2 masks |
− | Rabbit#show ip route | + | S 10.4.0.0 255.255.0.0 [50/0] via 10.1.20.0 |
− | 10.0.0.0 is variably subnetted, 5 subnets, 2 masks | + | S 10.1.5.0 255.255.255.0 [50/0] via 10.1.20.1 |
− | C 10.1.10.0 255.255.255.0 is directly connected, Serial0 | + | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 |
− | S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 | + | C 10.1.20.0 255.255.255.0 is directly connected, Serial1 |
− | S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 | + | S 192.168.0.0 255.255.0.0 [50/0] via 10.1.20.1 |
− | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 | + | Rabbit# |
− | C 10.1.20.0 255.255.255.0 is directly connected, Serial1 | + | %LINK-3-UPDOWN: Interface Serial0, changed state to up |
− | S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 | + | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change |
− | Rabbit# | + | Rabbit#show ip route |
− | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change | + | 10.0.0.0 is variably subnetted, 5 subnets, 2 masks |
− | %LINK-3-UPDOWN: Interface Serial0, changed state to down | + | C 10.1.10.0 255.255.255.0 is directly connected, Serial0 |
− | Rabbit#show ip route | + | S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 |
− | 10.0.0.0 is variably subnetted, 4 subnets, 2 masks | + | S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 |
− | S 10.4.0.0 255.255.0.0 [50/0] via 10.1.20.0 | + | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 |
− | S 10.1.5.0 255.255.255.0 [50/0] via 10.1.20.1 | + | Rabbit# |
− | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 | + | |
− | C 10.1.20.0 255.255.255.0 is directly connected, Serial1 | + | Next, trap messages announce that the state of the primary link connected to Serial 0 has changed to "down," indicating a failure. A look at the second iteration of the route table shows that all nonconnected routes now point to a next-hop address of 10.1.20.1. Because the more-preferred entry is no longer available, the router has switched to the less-preferred backup link, with the administrative distance of 50 indicated in the brackets. And because subnet 10.1.10.0 has failed, it no longer |
− | S 192.168.0.0 255.255.0.0 [50/0] via 10.1.20.1 | ||
− | Rabbit# | ||
− | %LINK-3-UPDOWN: Interface Serial0, changed state to up | ||
− | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change | ||
− | Rabbit#show ip route | ||
− | 10.0.0.0 is variably subnetted, 5 subnets, 2 masks | ||
− | C 10.1.10.0 255.255.255.0 is directly connected, Serial0 | ||
− | S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 | ||
− | S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 | ||
− | C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 | ||
− | Rabbit# | ||
− | Next, trap messages announce that the state of the primary link | ||
− | connected to Serial 0 has changed to "down," indicating a failure. A look | ||
− | at the second iteration of the route table shows that all nonconnected | ||
− | routes now point to a next-hop address of 10.1.20.1. Because the more- | ||
− | preferred entry is no longer available, the router has switched to the less- | ||
− | preferred backup link, with the administrative distance of 50 indicated in | ||
− | the brackets. And because subnet 10.1.10.0 has failed, it no longer | ||
shows up in the route table as a directly connected network. | shows up in the route table as a directly connected network. | ||
− | Before the third iteration of the route table, trap messages indicate that | + | |
− | the state of the primary link has changed to "up." The route table then | + | Before the third iteration of the route table, trap messages indicate that the state of the primary link has changed to "up." The route table then shows that subnet 10.1.10.0 is again in the table, and the router is again using the next-hop address of 10.1.10.1. |
− | shows that subnet 10.1.10.0 is again in the table, and the router is again | + | |
− | using the next-hop address of 10.1.10.1. | + | Chapter 11 discusses the administrative distances associated with the various dynamic routing protocols, but it can be said here that the administrative distances of all dynamic routing protocols are substantially higher than 1. Therefore, by default, a static route to a network will always be preferred over a dynamically discovered route to the same network. |
− | Chapter 11 discusses the administrative distances associated with the | + | |
− | various dynamic routing protocols, but it can be said here that the | + | ==Case Study: IPv6 Floating Static Routes== |
− | administrative distances of all dynamic routing protocols are substantially | + | |
− | higher than 1. Therefore, by default, a static route to a network will | + | IPv6 floating static route statements work the same way as IPv4. A second link has been added to the IPv6 network of Figure 3-3 between Honeypot and Honeybee, to route IPv6 traffic if the primary link fails (see Figure 3-6). |
− | always be preferred over a dynamically discovered route to the same | + | |
− | network. | + | Figure 3-6. Backup link added between two IPv6 routers can be used to recover from a primary link failure with floating static routes.floating static routes. |
− | Case Study: IPv6 Floating Static Routes | + | |
− | IPv6 floating static route statements work the same way as IPv4. A | ||
− | second link has been added to the IPv6 network of Figure 3-3 between | ||
− | Honeypot and Honeybee, to route IPv6 traffic if the primary link fails (see | ||
− | Figure 3-6). | ||
− | Figure 3-6. Backup link added between two IPv6 routers | ||
− | can be used to recover from a primary link failure with | ||
− | floating static routes.floating static routes. | ||
[View full size image] | [View full size image] | ||
− | Example 3-25 shows Honeypot's configuration with new static route | + | |
− | entries, which have an administrative distance greater than 1. Similar | + | Example 3-25 shows Honeypot's configuration with new static route entries, which have an administrative distance greater than 1. Similar static routes are entered on Honeybee, as shown in Example 3-26. Example 3-25. Honeypot is configured with floating static routes to be used over the new redundant parallel link to Honeybee. |
− | static routes are entered on Honeybee, as shown in Example 3-26. | + | |
− | Example 3-25. Honeypot is configured with floating static | + | ipv6 |
− | routes to be used over the new redundant parallel link to | + | ipv6 |
− | Honeybee. | + | ipv6 |
− | ipv6 | + | ipv6 |
− | ipv6 | + | route |
− | ipv6 | + | route |
− | ipv6 | + | route |
− | route | + | route |
− | route | + | FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 |
− | route | + | FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 50 |
− | route | + | FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0 |
− | FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 | + | FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 50 |
− | FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 50 | + | |
− | FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0 | + | Example 3-26. Honeybee is configured with floating static routes to be used over the new redundant parallel link to Honeypot.Honeypot. |
− | FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 50 | + | |
− | Example 3-26. Honeybee is configured with floating static | + | ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780 |
− | routes to be used over the new redundant parallel link to | + | ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 50 |
− | Honeypot.Honeypot. | + | ipv6 route FEC0:0:0:A::/64 FEC0::1:2B0:64FF:FE30:1DE0 |
− | ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780 | + | |
− | ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 50 | + | IPv6 traffic from Honeypot will continue to be forwarded out Serial0/0.2, unless this link goes down. |
− | ipv6 route FEC0:0:0:A::/64 FEC0::1:2B0:64FF:FE30:1DE0 | + | |
− | IPv6 traffic from Honeypot will continue to be forwarded out Serial0/0.2, | + | Example 3-27 shows Honeypot's route table with the routes known via the fec0::3:0:0:0:0/64 subnet installed. Both routes have an administrative distance of 1. Then, interface S0/0.2 goes down. The backup routes, with administrative distance of 50, get installed in the route table. After the interface S0/0.2 comes back up, the routing process learns of better routes to the destinations and installs the routes with an administrative distance of 1 back into the table. |
− | unless this link goes down. | + | |
− | Example 3-27 shows Honeypot's route table with the routes known via | + | Example 3-27. Static routes with high administrative distances are installed in the IPv6 route table only when the lower administrative distance routes are deleted. |
− | the fec0::3:0:0:0:0/64 subnet installed. Both routes have an | + | |
− | administrative distance of 1. Then, interface S0/0.2 goes down. The | + | Honeypot#show ipv6 route static |
− | backup routes, with administrative distance of 50, get installed in the | + | S |
− | route table. After the interface S0/0.2 comes back up, the routing process | + | FEC0::/62 [1/0] |
− | learns of better routes to the destinations and installs the routes with an | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | administrative distance of 1 back into the table. | + | S |
− | Example 3-27. Static routes with high administrative | + | FEC0:0:0:8::/62 [1/0] |
− | distances are installed in the IPv6 route table only when | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | the lower administrative distance routes are deleted. | + | Honeypot# |
− | Honeypot#show ipv6 route static | + | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan |
− | S | + | %LINK-3-UPDOWN: Interface Serial0/2, changed state to down |
− | FEC0::/62 [1/0] | + | Honeypot#show ipv6 route static |
− | via FEC0::3:204:C1FF:FE50:F1C0 | + | S |
− | S | + | FEC0::/62 [50/0] |
− | FEC0:0:0:8::/62 [1/0] | + | via FEC0::2:204:C1FF:FE50:F1C0 |
− | via FEC0::3:204:C1FF:FE50:F1C0 | + | S |
− | Honeypot# | + | FEC0:0:0:8::/62 [50/0]via FEC0::2:204:C1FF:FE50:F1C0 |
− | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan | + | Honeypot# |
− | %LINK-3-UPDOWN: Interface Serial0/2, changed state to down | + | %LINK-3-UPDOWN: Interface Serial0/2, changed state to up |
− | Honeypot#show ipv6 route static | + | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan |
− | S | + | |
− | FEC0::/62 [50/0] | + | The default administrative distance of IPv6 static routes, whether specified with an exit interface or a next-hop address, is 1. When static routes to a destination are specified both ways, the routes are considered equal, and load sharing (described in the next case study) occurs. |
− | via FEC0::2:204:C1FF:FE50:F1C0 | + | |
− | S | + | ==Case Study: Load Sharing== |
− | FEC0:0:0:8::/62 [50/0]via FEC0::2:204:C1FF:FE50:F1C0 | + | |
− | Honeypot# | + | The problem with the configuration used in the previous section is that under normal circumstances the second link is never utilized. The bandwidth available on the link is wasted. Load sharing allows routers to take advantage of multiple paths to the same destination by sending packets over all the available routes. |
− | %LINK-3-UPDOWN: Interface Serial0/2, changed state to up | + | |
− | %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan | + | Load sharing can be equal cost or unequal cost, where cost is a generic term referring to whatever metric (if any) is associated with the route: |
− | The default administrative distance of IPv6 static routes, whether | + | |
− | specified with an exit interface or a next-hop address, is 1. When static | + | * Equal-cost load sharing distributes traffic equally among multiple paths with equal metrics. In this case, load sharing can also be called load balancing. |
− | routes to a destination are specified both ways, the routes are considered | + | * Unequal-cost load sharing distributes packets among multiple paths with different metrics. The traffic is distributed in inverse proportion to the cost of the routes. That is, paths with lower costs are assigned more traffic, and paths with higher costs are assigned less traffic. |
− | equal, and load sharing (described in the next case study) occurs. | + | |
− | Case Study: Load Sharing | + | Some routing protocols support both equal-cost and unequal-cost load sharing, whereas others support only equal cost. Static routes, which have no metric, support only equal-cost load sharing.To configure the parallel links in Figure 3-5 for load sharing using static routes, Example 3-28 shows the route entries for Piglet and Example 3-29 shows the route entries for Rabbit. |
− | The problem with the configuration used in the previous section is that | + | |
− | under normal circumstances the second link is never utilized. The | + | Example 3-28. Configuring parallel links for load sharing using static routes: route entries for Piglet. |
− | bandwidth available on the link is wasted. Load sharing allows routers to | + | |
− | take advantage of multiple paths to the same destination by sending | + | ip |
− | packets over all the available routes. | + | ip |
− | Load sharing can be equal cost or unequal cost, where cost is a generic | + | ip |
− | term referring to whatever metric (if any) is associated with the route: | + | ip |
− | Equal-cost load sharing distributes traffic equally among multiple | + | route |
− | paths with equal metrics. In this case, load sharing can also be | + | route |
− | called load balancing. | + | route |
− | Unequal-cost load sharing distributes packets among multiple paths | + | route |
− | with different metrics. The traffic is distributed in inverse proportion to | + | 192.168.1.0 255.255.255.0 192.168.1.193 |
− | the cost of the routes. That is, paths with lower costs are assigned | + | 10.4.0.0 255.255.0.0 192.168.1.193 |
− | more traffic, and paths with higher costs are assigned less traffic. | + | 10.1.30.0 255.255.255.0 10.1.10.2 |
− | Some routing protocols support both equal-cost and unequal-cost load | + | 10.1.30.0 255.255.255.0 10.1.20.2 |
− | sharing, whereas others support only equal cost. Static routes, which | + | |
− | have no metric, support only equal-cost load sharing.To configure the parallel links in Figure 3-5 for load sharing using static | + | Example 3-29. Configuring parallel links for load sharing using static routes: route entries for Rabbit. |
− | routes, Example 3-28 shows the route entries for Piglet and Example 3- | + | |
− | 29 shows the route entries for Rabbit. | + | ip |
− | Example 3-28. Configuring parallel links for load sharing | + | ip |
− | using static routes: route entries for Piglet. | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | ip |
− | ip | + | route |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | route | + | route |
− | 192.168.1.0 255.255.255.0 192.168.1.193 | + | route |
− | 10.4.0.0 255.255.0.0 192.168.1.193 | + | 10.4.0.0 255.255.0.0 10.1.10.1 |
− | 10.1.30.0 255.255.255.0 10.1.10.2 | + | 10.4.0.0 255.255.0.0 10.1.20.1 |
− | 10.1.30.0 255.255.255.0 10.1.20.2 | + | 10.1.5.0 255.255.255.0 10.1.10.1 |
− | Example 3-29. Configuring parallel links for load sharing | + | 10.1.5.0 255.255.255.0 10.1.20.1 |
− | using static routes: route entries for Rabbit. | + | 192.168.0.0 255.255.0.0 10.1.10.1 |
− | ip | + | 192.168.0.0 255.255.0.0 10.1.20.1 |
− | ip | + | |
− | ip | + | These entries were also used in the previous section for floating static routes, except both links now use the default administrative distance of 1. Rabbit's route table, shown in Example 3-30, now has two routes to each destination. |
− | ip | + | |
− | ip | + | Example 3-30. This route table indicates that there are two paths to the same destination networks. The router will balance the load across these multiple paths.balance the load across these multiple paths. |
− | ip | + | |
− | route | + | Rabbit#show ip route |
− | route | + | Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile |
− | route | + | D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte |
− | route | + | E1 - OSPF external type 1, E2 - OSPF external type 2, E |
− | route | + | i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c |
− | route | + | U - per-user static route |
− | 10.4.0.0 255.255.0.0 10.1.10.1 | + | Gateway of last resort is not set |
− | 10.4.0.0 255.255.0.0 10.1.20.1 | + | 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks |
− | 10.1.5.0 255.255.255.0 10.1.10.1 | + | C |
− | 10.1.5.0 255.255.255.0 10.1.20.1 | + | 10.1.10.0/24 is directly connected, Serial0 |
− | 192.168.0.0 255.255.0.0 10.1.10.1 | + | S |
− | 192.168.0.0 255.255.0.0 10.1.20.1 | + | 10.1.5.0/24 [1/0] via 10.1.10.1 |
− | These entries were also used in the previous section for floating static | + | [1/0] via 10.1.20.1 |
− | routes, except both links now use the default administrative distance of 1. | + | S |
− | Rabbit's route table, shown in Example 3-30, now has two routes to each | + | 10.4.0.0/16 [1/0] via 10.1.10.1 |
− | destination. | + | [1/0] via 10.1.20.1 |
− | Example 3-30. This route table indicates that there are two | + | C |
− | paths to the same destination networks. The router will | + | 10.1.20.0/24 is directly connected, Serial1 |
− | balance the load across these multiple paths.balance the load across these multiple paths. | + | S |
− | Rabbit#show ip route | + | 192.168.0.0/16 [1/0] via 10.1.10.1 |
− | Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile | + | [1/0] via 10.1.20.1 |
− | D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte | + | Rabbit# |
− | E1 - OSPF external type 1, E2 - OSPF external type 2, E | + | |
− | i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c | + | IPv6 works the same way as IPv4. The static routes in Honeypot's route table, shown in Example 3-31, will yield the route table shown in Example 3-32. |
− | U - per-user static route | + | |
− | Gateway of last resort is not set | + | Example 3-31. Honeypot's IPv6 static routes are configured for load-balancing, with each destination prefix using two different next-hop addresses. |
− | 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks | + | |
− | C | + | ipv6 |
− | 10.1.10.0/24 is directly connected, Serial0 | + | ipv6 |
− | S | + | ipv6 |
− | 10.1.5.0/24 [1/0] via 10.1.10.1 | + | ipv6 |
− | [1/0] via 10.1.20.1 | + | route |
− | S | + | route |
− | 10.4.0.0/16 [1/0] via 10.1.10.1 | + | route |
− | [1/0] via 10.1.20.1 | + | route |
− | C | + | FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 |
− | 10.1.20.0/24 is directly connected, Serial1 | + | FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 |
− | S | + | FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 |
− | 192.168.0.0/16 [1/0] via 10.1.10.1 | + | FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0 |
− | [1/0] via 10.1.20.1 | + | |
− | Rabbit# | + | Example 3-32. The router will load balance over these two IPv6 paths to the same destination networks. |
− | IPv6 works the same way as IPv4. The static routes in Honeypot's route | + | |
− | table, shown in Example 3-31, will yield the route table shown in Example | + | Honeypot#show ipv6 route static |
− | 3-32. | + | S |
− | Example 3-31. Honeypot's IPv6 static routes are configured | + | FEC0::/62 [1/0] |
− | for load-balancing, with each destination prefix using two | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | different next-hop addresses. | + | via FEC0::2:204:C1FF:FE50:F1C0 |
− | ipv6 | + | S |
− | ipv6 | + | FEC0:0:0:8::/62 [1/0] |
− | ipv6 | + | via FEC0::3:204:C1FF:FE50:F1C0 |
− | ipv6 | + | via FEC0::2:204:C1FF:FE50:F1C0 |
− | route | + | |
− | route | ||
− | route | ||
− | route | ||
− | FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 | ||
− | FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 | ||
− | FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 | ||
− | FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50: | ||
− | IPv6 paths to the same destination networks. | ||
− | Honeypot#show ipv6 route static | ||
− | S | ||
− | FEC0::/62 [1/0] | ||
− | via FEC0::3:204:C1FF:FE50:F1C0 | ||
− | via FEC0::2:204:C1FF:FE50:F1C0 | ||
− | S | ||
− | FEC0:0:0:8::/62 [1/0] | ||
− | via FEC0::3:204:C1FF:FE50:F1C0 | ||
− | via FEC0::2:204:C1FF:FE50:F1C0 | ||
Load sharing is also either per destination or per packet. | Load sharing is also either per destination or per packet. | ||
+ | |||
Load Sharing and Cisco Express Forwarding | Load Sharing and Cisco Express Forwarding | ||
− | Per destination load sharing distributes the load according to destination | + | |
− | address. Given two paths to the same network, all packets for one | + | Per destination load sharing distributes the load according to destination address. Given two paths to the same network, all packets for one destination may travel over the first path, all packets for a second destination on the same network may travel over the second path, all packets for a third destination may again be sent over the first path, and so on. This is the default type of load sharing used by Cisco Express Forwarding (CEF). On most platforms, CEF is the default switching mode |
− | destination may travel over the first path, all packets for a second | ||
− | destination on the same network may travel over the second path, all | ||
− | packets for a third destination may again be sent over the first path, and | ||
− | so on. This is the default type of load sharing used by Cisco Express | ||
− | Forwarding (CEF). On most platforms, CEF is the default switching mode | ||
for IPv4, but not IPv6. | for IPv4, but not IPv6. | ||
− | CEF is a very efficient switching process. Its forwarding information is | + | |
− | obtained and stored in tables before any packet needs to use the | + | CEF is a very efficient switching process. Its forwarding information is obtained and stored in tables before any packet needs to use the information. CEF builds a forwarding information base (FIB) with information obtained from the route table. All the destination networks entered in the route table are entered into the CEF FIB. If the route table is stable and not changing, the FIB will not change. CEF uses a separate table, the adjacency table, to maintain Layer 2 forwarding information for each entry in the FIB. The adjacency table is created as Layer 2 information is learned, through IP ARP or IPv6 Neighbor Discovery, for instance. Both the FIB and adjacency table are created before packets need to be forwarded. Not even the first packet to a destination is process switched, as is the case with other switching schemes. |
− | information. CEF builds a forwarding information base (FIB) with | + | |
− | information obtained from the route table. All the destination networks | + | CEF performs per-destination load sharing by default. This is actually per source-destination pair load sharing. All traffic that has a particular source address and is destined to a specific destination address will exit the same interface. Traffic with a different source/destination address pair |
− | entered in the route table are entered into the CEF FIB. If the route table | ||
− | is stable and not changing, the FIB will not change. CEF uses a | ||
− | each entry in the FIB. The adjacency table is created as Layer 2 | ||
− | information is learned, through IP ARP or IPv6 Neighbor Discovery, for | ||
− | instance. Both the FIB and adjacency table are created before packets | ||
− | need to be forwarded. Not even the first packet to a destination is | ||
− | process switched, as is the case with other switching schemes. | ||
− | CEF performs per-destination load sharing by default. This is actually per | ||
− | source-destination pair load sharing. All traffic that has a particular | ||
− | source address and is destined to a specific destination address will exit | ||
− | the same interface. Traffic with a different source/destination address pair | ||
may exit the next interface. | may exit the next interface. | ||
− | Per packet load sharing is another method available to CEF switched | + | |
− | IPv4 packets. IPv6 CEF only supports per destination load sharing. Per | + | Per packet load sharing is another method available to CEF switched IPv4 packets. IPv6 CEF only supports per destination load sharing. Per packet load sharing means that one packet is sent over one link, the next packet is sent over the next link, even if this next packet is to the same destination as the first, and so on, given equal-cost paths. If the paths are unequal cost, the load sharing may be one packet over the higher-cost link for every three packets over the lower-cost link, or some other proportion depending upon the ratio of costs. Per packet load sharing may distribute the load more evenly than per destination load sharing, depending upon the number of different source-destination pairs, but because the packets to a given destination will be taking different paths, the packets are likely to arrive out of order, which is unacceptable for some applications, such as Voice over IP. |
− | packet load sharing means that one packet is sent over one link, the next | + | |
− | packet is sent over the next link, even if this next packet is to the same | + | To determine if CEF is enabled globally on a router, use the commands show ip cef and show ipv6 cef. If it is not enabled by default, you can turn it on globally using the command ip cef for IPv4. To enable CEF for IPv6, first enable CEF for IPv4, then use the command ipv6 cef. Per packet load sharing is enabled for IPv4 using the interface command ip load-sharing per-packet. The command ip load-sharing per-destination re-enables per destination load sharing. You can see which type of load sharing is enabled using the show cef interface command. |
− | destination as the first, and so on, given equal-cost paths. If the paths are | + | |
− | unequal cost, the load sharing may be one packet over the higher-cost | + | This displays the CEF information that is configured on the interface.The router determines whether to use CEF switching based on the ingress interface and the type of source and destination address. The ingress interface must be configured with CEF switching for the router to even consider using CEF. If CEF is configured on the ingress interface, CEF will attempt to switch the packet. If for some reason the packet cannot be CEF switched, CEF punts the packet down to the next-best and available switching method. For IPv4, this would be fast switching, if it is enabled on the interface. For IPv6, this would be process switching. |
− | link for every three packets over the lower-cost link, or some other | + | |
− | proportion depending upon the ratio of costs. Per packet load sharing | + | You can verify that CEF is enabled on an interface using the commands show cef interface {interface} and show ipv6 cef {interface} detail. Per Destination Load Sharing and Fast Switching IOS performs per destination load sharing on exit interfaces configured with fast switching. Fast switching is the default IOS switching mode in some routers. |
− | may distribute the load more evenly than per destination load sharing, | + | |
− | depending upon the number of different source-destination pairs, but | ||
− | because the packets to a given destination will be taking different paths, | ||
− | the packets are likely to arrive out of order, which is unacceptable for | ||
− | some applications, such as Voice over IP. | ||
− | To determine if CEF is enabled globally on a router, use the commands | ||
− | show ip cef and show ipv6 cef. If it is not enabled by default, you can | ||
− | turn it on globally using the command ip cef for IPv4. To enable CEF for | ||
− | IPv6, first enable CEF for IPv4, then use the command ipv6 cef. | ||
− | Per packet load sharing is enabled for IPv4 using the interface command | ||
− | ip load-sharing per-packet. The command ip load-sharing per- | ||
− | destination re-enables per destination load sharing. You can see which | ||
− | type of load sharing is enabled using the show cef interface command. | ||
− | This displays the CEF information that is configured on the interface.The router determines whether to use CEF switching based on the | ||
− | ingress interface and the type of source and destination address. The | ||
− | ingress interface must be configured with CEF switching for the router to | ||
− | even consider using CEF. If CEF is configured on the ingress interface, | ||
− | CEF will attempt to switch the packet. If for some reason the packet | ||
− | cannot be CEF switched, CEF punts the packet down to the next-best | ||
− | and available switching method. For IPv4, this would be fast switching, if | ||
− | it is enabled on the interface. For IPv6, this would be process switching. | ||
− | You can verify that CEF is enabled on an interface using the commands | ||
− | show cef interface {interface} and show ipv6 cef {interface} detail. | ||
− | Per Destination Load Sharing and Fast Switching | ||
− | IOS performs per destination load sharing on exit interfaces configured | ||
− | with fast switching. Fast switching is the default IOS switching mode in | ||
− | some routers. | ||
Fast switching works as follows: | Fast switching works as follows: | ||
− | + | ||
− | route table lookup is performed and an exit interface is selected. | + | # When a router switches the first packet to a particular destination, a route table lookup is performed and an exit interface is selected. |
− | + | # The necessary data-link information to frame the packet for the selected interface is then retrieved (from the ARP cache, for instance), and the packet is encapsulated and transmitted. | |
− | selected interface is then retrieved (from the ARP cache, for | + | # The retrieved route and data-link information is then entered into a fast switching cache. |
− | instance), and the packet is encapsulated and transmitted. | + | # As subsequent packets to the same destination enter the router, the information in the fast cache allows the router to immediately switch the packet without performing another route table and ARP cache lookup. |
− | + | ||
− | fast switching cache. | + | While switching time and processor utilization are decreased, fast-switching means that all packets to a specific destination, not source-destination pair, are routed out the same interface. When packets destination pair, are routed out the same interface. When packets addressed to a different host on the same network enter the router and an alternate route exists, the router may send all packets for that destination on the alternate route. Therefore, the best the router can do is balance traffic on a per destination basis. |
− | + | ||
− | information in the fast cache allows the router to immediately switch | ||
− | the packet without performing another route table and ARP cache | ||
− | lookup. | ||
− | While switching time and processor utilization are decreased, fast | ||
− | switching means that all packets to a specific destination, not source- | ||
− | destination pair, are routed out the same interface. When | ||
− | addressed to a different host on the same network enter the router and | ||
− | an alternate route exists, the router may send all packets for that | ||
− | destination on the alternate route. Therefore, the best the router can do is | ||
− | balance traffic on a per destination basis. | ||
Per Packet Load Sharing and Process Switching | Per Packet Load Sharing and Process Switching | ||
− | Process switching simply means that for every packet, the router | + | Process switching simply means that for every packet, the router performs a route table lookup, selects an interface, and then looks up the data link information. Because each routing decision is independent for each packet, all packets to the same destination are not forced to use the same interface. To enable process switching on an interface, use the command no ip route-cache for IPv4. You don't have to do anything to enable process switching for IPv6. It is enabled by default. |
− | performs a route table lookup, selects an interface, and then looks up the | + | |
− | data link information. Because each routing decision is independent for | + | In Example 3-33, host 192.168.1.15 has sent six pings to host 10.1.30.25. Using debug ip packet, the ICMP echo request and echo reply packets are observed at Piglet. Looking at the exit interfaces and the forwarding addresses, it can be observed that both Piglet and Rabbit are using S0 and S1 alternately. Note that the command debug ip packet allows only process switched packets to be observed. Fast |
− | each packet, all packets to the same destination are not forced to use the | ||
− | same interface. To enable process switching on an interface, use the | ||
− | command no ip route-cache for IPv4. You don't have to do anything to | ||
− | enable process switching for IPv6. It is enabled by default. | ||
− | In Example 3-33, host 192.168.1.15 has sent six pings to host | ||
− | 10.1.30.25. Using debug ip packet, the ICMP echo request and echo | ||
− | reply packets are observed at Piglet. Looking at the exit interfaces and | ||
− | the forwarding addresses, it can be observed that both Piglet and Rabbit | ||
− | are using S0 and S1 alternately. Note that the command debug ip | ||
− | packet allows only process switched packets to be observed. Fast | ||
switched packets are not displayed. | switched packets are not displayed. | ||
+ | |||
Note | Note | ||
− | The debug ip packet command displays only process | + | The debug ip packet command displays only process switched packets. |
− | switched packets. | + | |
− | Example 3-33. This router is alternating between S0 and S1 | + | Example 3-33. This router is alternating between S0 and S1 to send packets to the same destination. Notice that the router on the other end of the two links is doing the same thing with the reply packets.thing with the reply packets. |
− | to send packets to the same destination. Notice that the | + | |
− | router on the other end of the two links is doing the same | + | Piglet#debug ip packet |
− | thing with the reply packets.thing with the reply packets. | + | |
− | Piglet#debug ip packet | ||
IP packet debugging is on | IP packet debugging is on | ||
− | Piglet# | + | |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), | + | Piglet# |
− | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), | + | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), |
− | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), | + | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), |
− | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), | + | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), |
− | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), | + | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), |
− | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), |
− | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), | + | IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), |
− | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), | + | IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), |
− | Piglet# | + | IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), |
− | Like many design choices, per packet load balancing has a price. The | + | Piglet# |
− | traffic may be distributed more evenly among the various links than with | + | |
− | per destination load balancing, but the lower switching time and | + | Like many design choices, per packet load balancing has a price. The traffic may be distributed more evenly among the various links than with per destination load balancing, but the lower switching time and processor utilization of fast switching are lost. |
− | processor utilization of fast switching are lost. | + | |
Which Switching Method Will Be Used? | Which Switching Method Will Be Used? | ||
− | IOS makes switching decisions based on the configuration of the inbound | + | |
− | interface first. If CEF is configured on an inbound interface, the packet | + | IOS makes switching decisions based on the configuration of the inbound interface first. If CEF is configured on an inbound interface, the packet will be CEF switched regardless of the configuration on the outbound interface. |
− | will be CEF switched regardless of the configuration on the outbound | + | |
− | interface. | + | If CEF is not enabled on the inbound interface, then IOS processes and forwards the packet, and based on the configuration of the outbound |
− | If CEF is not enabled on the inbound interface, then IOS processes and | + | |
− | forwards the packet, and based on the configuration of the outbound | + | g=10.1. |
− | g=10.1. | + | g=192.1 |
− | g=192.1 | + | g=10.1. |
− | g=10.1. | + | g=192.1 |
− | g=192.1 | + | g=10.1. |
− | g=10.1. | + | g=192.1 |
− | g=192.1 | + | g=10.1. |
− | g=10.1. | + | g=192.1 |
− | g=192.1 | + | g=10.1. |
− | g=10.1. | + | g=192.1 |
− | g=192.1 | + | g=10.1. |
− | g=10.1. | + | g=192.1interface, subsequent packets will be fast-switched or process switched. |
− | g=192.1interface, subsequent packets will be fast-switched or process switched. | + | |
− | Table 3-1 shows which switching method will be used based on | + | Table 3-1 shows which switching method will be used based on configuration of inbound and outbound interfaces. |
− | configuration of inbound and outbound interfaces. | + | |
− | Table 3-1. IOS switching determination is based on configuration of | + | Table 3-1. IOS switching determination is based on configuration of inbound and outbound interfaces. |
− | inbound and outbound interfaces. | ||
Inbound Configuration Outbound Configuration Switching Method Used | Inbound Configuration Outbound Configuration Switching Method Used | ||
− | CEF Process | + | |
− | CEF | + | CEF Process |
− | CEF Fast | + | CEF |
− | CEF | + | CEF Fast |
− | Process CEF | + | CEF |
− | Fast (or process if IPv6) | + | Process CEF |
− | Process Fast | + | Fast (or process if IPv6) |
− | Fast | + | Process Fast |
− | Fast CEF | + | Fast |
− | Fast (or process if IPv6) | + | Fast CEF |
− | Fast Process | + | Fast (or process if IPv6) |
+ | Fast Process | ||
+ | |||
Process | Process | ||
− | IOS will switch a packet using CEF only if CEF is enabled on the inbound | + | |
− | interface. If CEF is not configured on the inbound interface, the | + | IOS will switch a packet using CEF only if CEF is enabled on the inbound interface. If CEF is not configured on the inbound interface, the configuration of the exit interface determines the switching method. |
− | configuration of the exit interface determines the switching method. | + | |
− | Notice that when process or fast-switching is configured inbound and | + | Notice that when process or fast-switching is configured inbound and CEF is configured on the outbound interface, fast-switching is used. CEF is only used if it is configured on the ingress interface. For IPv4, fast-switching is enabled outbound, even if CEF is enabled on the interface. There are times when a packet will not be switched using CEF even if it is enabled (for example, if access-list logging is enabled and a packet will be logged). Packets will be punted down to the next fastest switching method. For IPv4, the next fastest switching method is fast-switching. For IPv6, this is process switching.IPv6, this is process switching. |
− | CEF is configured on the outbound interface, fast-switching is used. CEF | + | |
− | is only used if it is configured on the ingress interface. For IPv4, fast- | + | ==Case Study: Recursive Table Lookups== |
− | switching is enabled outbound, even if CEF is enabled on the interface. | + | |
− | There are times when a packet will not be switched using CEF even if it | + | All route entries do not necessarily need to point to the next-hop router. Figure 3-7 shows a simplified version of the network of Figure 3-5. In this network, Pooh is configured as displayed in Example 3-34. |
− | is enabled (for example, if access-list logging is enabled and a packet will | + | Figure 3-7. To reach network 10.1.30.0, Pooh must perform three route table lookups. |
− | be logged). Packets will be punted down to the next fastest switching | + | |
− | method. For IPv4, the next fastest switching method is fast-switching. For | + | [View full size image] |
− | IPv6, this is process switching.IPv6, this is process switching. | + | |
− | Case Study: Recursive Table Lookups | + | Example 3-34. Pooh's static route entries use various addresses as the next-hop parameter. The addresses are not necessarily the actual next-hop router interface. |
− | All route entries do not necessarily need to point to the next-hop router. | + | |
− | Figure 3-7 shows a simplified version of the network of Figure 3-5. In this | + | ip route 10.1.30.0 255.255.255.0 10.1.10.2 |
− | network, Pooh is configured as displayed in Example 3-34. | + | ip route 10.1.10.0 255.255.255.0 192.168.1.194 |
− | Figure 3-7. To reach network 10.1.30.0, Pooh must perform | + | ip route 192.168.1.192 255.255.255.224 192.168.1.66 |
− | + | ||
+ | If Pooh needs to send a packet to host 10.1.30.25, it will look into its route table and find that the subnet is reachable via 10.1.10.2. Because that address is not on a directly connected network, Pooh must again consult the table to find that network 10.1.10.0 is reachable via 192.168.1.194. That subnet is also not directly connected, so a third table lookup is called for. Pooh will find that 192.168.1.192 is reachable via 192.168.1.66, which is on a directly connected subnet. The packet can now be forwarded. | ||
+ | |||
+ | Because each table lookup costs processor time, under normal circumstances forcing a router to perform multiple lookups is a poor design decision. Fast switching significantly reduces these adverse effects by limiting the recursive lookups to the first packet to each destination, but a justification should still be identified before using such a design. | ||
+ | |||
+ | Figure 3-8 shows an example of an instance in which recursive lookups might be useful. Here, Sanderz reaches all networks via Heffalump. However, the network administrator plans to eliminate Heffalump and repoint all of Sanderz's routes through Woozle. The first 12 entries point not to Heffalump, but to the appropriate router attached to the 10.87.14.0 subnet. The last entry specifies that the 10.87.14.0 subnet is reached via Heffalump. | ||
+ | |||
+ | Figure 3-8. Configuring Sanderz for recursive lookups enables the network administrator to redirect all of that router's exit traffic from Heffalump to Woozle by changing one route entry. | ||
+ | |||
[View full size image] | [View full size image] | ||
− | + | ||
− | + | With this configuration, all of Sanderz's entries can be repointed through Woozle simply by changing the last static entry as in Example 3-35. Example 3-35. Sanderz's routing can easily be modified to | |
− | + | forward all routes through a different next-hop router simply by changing one static route entry. | |
− | + | ||
− | + | Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95 | |
− | + | Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.2 | |
− | + | ||
− | + | Had all the static routes referenced 10.23.5.20 as the next-hop address, it would have been necessary to delete all 13 lines and type 13 new lines. Nevertheless, the effort saved in retyping static routes must be weighed carefully against | |
− | + | ||
− | + | ==Pranala Menarik== | |
− | + | ||
− | + | * [[IPv6: Advanced Routing]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Woozle simply by changing the last static entry as in Example 3-35. | ||
− | Example 3-35. Sanderz's routing can easily be modified to | ||
− | forward all routes through a different next-hop router | ||
− | simply by changing one static route entry. | ||
− | Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95 | ||
− | Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.2 | ||
− | Had all the static routes referenced 10.23.5.20 as the next-hop address, | ||
− | it would have been necessary to delete all 13 lines and type 13 new lines. | ||
− | Nevertheless, the effort saved in retyping static routes must be weighed | ||
− | carefully against |
Latest revision as of 10:15, 20 March 2019
Configuring Static Routes
Tabel rute memperoleh informasi dalam salah satu dari tiga cara:
- Informasi dapat dimasukkan berdasarkan apa yang diketahui router tentang subnet yang terhubung langsung.
- Informasi dapat dimasukkan secara manual, melalui entri rute statis.
- Informasi dapat dimasukkan secara otomatis oleh salah satu dari beberapa sistem penemuan dan pembagian informasi otomatis yang dikenal sebagai protokol routing dinamis.
Sebagian besar materi yang menarik untuk dibahas adalah dynamic IP routing protocol, tetapi pembahasan konfigurasi rute statik akan mempersiapkan anda untuk memahami bagian-bagian selanjutnya.
Lebih tepatnya, routing statik lebih disukai daripada routing dinamik dalam keadaan tertentu. Seperti halnya proses apa pun, semakin otomatis, semakin sedikit kontrol yang kita miliki. Meskipun perutean dinamis (otomatis) memerlukan lebih sedikit intervensi manusia, perutean statik memungkinkan kontrol yang sangat tepat atas perilaku perutean jaringan. Harga yang harus dibayar untuk ketepatan ini adalah perlunya konfigurasi ulang manual setiap kali topologi jaringan berubah.
Studi Kasus: Routing Statik Sederhana
Figure 3-2 shows a network with four routers and six data links. Notice that the subnets of network 10.0.0.0 are discontiguous there is a different major network subnet (192.168.1.192, in the Tigger-to-Piglet link) separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of 10.0.0.0 are also variably subnetted the subnet masks are not consistent throughout the network: Subnet 10.1.0.0 has a 16-bit mask, while 10.4.0.0 has a 24-bit mask. Finally, the subnet address of Pooh's Ethernet link is an all-zero subnet. Later chapters demonstrate that an addressing scheme with these characteristics causes problems for simpler, classful routing protocols such as RIP and IGRP; but static routes work fine here.
Gambar 3-2. Protokol-protokol routing seperti RIP dan IGRP tidak dapat dengan mudah me-routing jaringan yang tidak jelas dan berbeda-beda ini, tetapi routing statik akan bekerja.
[View full size image]
Prosedur untuk me-routing jaringan secara statik memiliki tiga langkah:
- Untuk setiap data link dalam jaringan, identifikasi semua alamat subnet atau jaringan.
- Untuk setiap router, identifikasi semua data link yang tidak terhubung langsung ke router itu.
- Untuk setiap router, tulis perinta route untuk setiap alamat yang tidak terhubung langsung ke situ. TIdak perlu menulis perintah route untuk data link yang terhubung langsung dengan router, karena alamat dan mask yang dikonfigurasi pada interface router menyebabkan jaringan tersebut dicatat dalam tabel route-nya. .
For example, the network in Figure 3-2 has six subnets:
10.1.0.0/16 10.4.6.0/24 10.4.7.0/24 192.168.1.192/27 192.168.1.64/27 192.168.1.0/27
To configure static routes for Piglet, the subnets that are not directly connected are identified as follows:
10.4.6.0/24 10.4.7.0/24 192.168.1.64/27 192.168.1.0/27
These are the subnets for which static routes must be written. Example 3-2 shows the commands for entering Piglet's static routes. [3] [3]
For the static routes in this example and the subsequent examples in this chapter towork properly, two global commands must be added to the routers: ip classless and ip subnet-zero. In IOS 11.3 and later, ip classless is enabled by default. These commands are introduced in Chapter 6 and are mentioned here for readers who wish to try the configuration examples in a lab.
Example 3-2. Configuring Piglet's static routes.
Piglet(config)# Piglet(config)# Piglet(config)# Piglet(config)# ip ip ip ip route route route route 192.168.1.0 255.255.255.224 192.168.1. 192.168.1.64 255.255.255.224 192.168.1 10.4.6.0 255.255.255.0 192.168.1.193 10.4.7.0 255.255.255.0 192.168.1.193
Following the same steps, Example 3-3 shows the route entries for the other three routers. Example 3-3. Route entries for Routers Pooh, Tigger, and Eeyore.
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1. Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66 Pooh(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.66 Pooh(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.66 _______________________________________________________________ Tigger(config)# ip route 192.168.1.0 255.255.255.224 192.168.1. Tigger(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.194 Tigger(config)# ip route 10.4.7.0 255.255.255.0 10.4.6.2 _______________________________________________________________ Eeyore(config)# ip route 192.168.1.0 255.255.255.224 10.4.6.1 Eeyore(config)# ip route 192.168.1.64 255.255.255.224 10.4.6.1 Eeyore(config)# ip route 192.168.1.192 255.255.255.224 10.4.6
.The routing commands themselves are easily read if the reader remembers that each command describes a route table entry. The command for IPv4 is ip route, followed by the address to be entered into the table, a mask for determining the network portion of the address, and the address of the directly connected interface of the next-hop router.
An alternative configuration command for IPv4 static routes specifies the interface out of which an address is reached instead of the interface address of the next-hop router. For example, Example 3-4 shows the possible route entries for Tigger.
Example 3-4. Alternative route entries for Tigger.
ip route 192.168.1.0 255.255.255.224 S0 ip route 10.1.0.0 255.255.0.0 E0 ip route 10.4.7.0 255.255.255.0 S1
Certain conditions must be met before a static route is written into the route table. IP routing must be enabled, the next-hop address, if used, must be reachable, the exit interface must have an IP address configured on it, and the exit interface must be up.
Example 3-5 compares the route table resulting from this configuration with the route table resulting from entries pointing to a next-hop router. Notice that a certain inaccuracy is introduced: All addresses specified with a static route referring to an exit interface are entered into the table as if they are directly connected to that interface. The implications for route redistribution are discussed in Chapter 11.
A point of interest in Example 3-5 is that the header for the 10.0.0.0 subnets indicates the variable subnet masks used in the network. Variable-length subnet masking (VLSM) can be a useful tool and is discussed at length in Chapter 6.Example 3-5. The top route table is the result of static route entries pointing to the next-hop router. The bottom route table is the result of static routes that point to the interface a packet must exit to reach the destination network. [4]
Tigger#show ip route Gateway of last resort is not set 10.0.0.0 is variably subnetted, 3 subnets, 2 masks C 10.4.6.0 255.255.255.0 is directly connected, Serial1 S 10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2 S 10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194 192.168.1.0 255.255.255.224 is subnetted, 3 subnets C 192.168.1.64 is directly connected, Serial0 S 192.168.1.0 [1/0] via 192.168.1.65 C 192.168.1.192 is directly connected, Ethernet0 Tigger# Tigger#show ip route Gateway of last resort is not set 10.0.0.0 is variably subnetted, 3 subnets, 2 masks C 10.4.6.0 255.255.255.0 is directly connected, Serial1 S 10.4.7.0 255.255.255.0 is directly connected, Serial1 S 10.1.0.0 255.255.0.0 is directly connected, Ethernet0 192.168.1.0 255.255.255.224 is subnetted, 3 subnets C 192.168.1.64 is directly connected, Serial0 S 192.168.1.0 is directly connected, Serial0 C 192.168.1.192 is directly connected, Ethernet0 Tigger# [4]
The key normally seen at the top of the route table (as in Figure 3-2) has been removed for clarity.
A third option for static routes is to use a combination of the outgoing interface and the next-hop address. The next-hop address is coupled with the specified exit interface. If the exit interface goes down, the routewith the specified exit interface. If the exit interface goes down, the route is removed from the route table, even if the next-hop address is recursively reachable via an alternate route. This minimizes table lookups associated with finding the outgoing interface associated with a next-hop address and the entry in the table appears as a route with a distance of 1, not a directly connected network.
Directing a static route to an exit broadcast interface without specifying the next-hop address can cause an excessive amount of traffic on the broadcast network, and also might eat up the router's memory. For example, look at Tigger's ip route 10.1.0.0 255.255.0.0 E0 command. The router assumes 10.1.0.0 is directly connected, as we have seen from the route table. Therefore, when attempting to route to any address on the 10.1.0.0/16 subnet, the router sends an ARP request to find the MAC address to which to forward the packet. Each attempt to reach an address on the 10.1.0.0 network, whether the destination is valid or not, will result in an ARP request, an ARP response if a router on the broadcast network is responding on behalf of the 10.1.0.0 network (proxy ARP), and a potentially large ARP cache on the router. By appending the next-hop address to the static route entry, ip route 10.1.0.0 255.255.0.0 E0 192.168.1.194, the router no longer assumes that the destination is directly connected. The only ARP traffic is for the next-hop address, which only occurs for the first packet destined to a host on network 10.1.0.0, rather than for every packet destined to a new host on network 10.1.0.0.
Specify the exit interface and the next-hop address to minimize table lookups associated with finding the exit interface for a specified next-hop address, and to minimize traffic on the broadcast network. Example 3-6 shows the difference in the static route entries in the route tables when the next-hop address is used with the exit interface. Example 3-6. Specifying an exit interface rather than the next-hop router address with static routing could generate excessive traffic on a broadcast network.Tigger#show ip route static 10.0.0.0/16 is subnetted, 1 subnets S 10.1.0.0 is directly connected, Ethernet0
Tigger#show arp Protocol Address Internet 192.168.1.193 Internet 10.1.8.1 Internet 192.168.1.194 Internet 10.1.5.5 Internet 10.1.1.1 Tigger# Age (min) - 0 24 0 0 Hardware Addr 0004.c150.f1c0 0010.7b38.37d5 0010.7b38.37d5 0010.7b38.37d5 0010.7b38.37d5 Type ARPA ARPA ARPA ARPA ARPA Int Eth Eth Eth Eth Eth Tigger#show ip route static 10.0.0.0/16 is subnetted, 1 subnets S 10.1.0.0 [1/0] via 192.168.1.194, Ethernet0 Tigger#show arp Protocol Address Internet 192.168.1.193 Internet 192.168.1.194 Age (min) - 22 Hardware Addr Type 0004.c150.f1c0 ARPA 0010.7b38.37d5 ARPA
The first route table and ARP cache show that the static route entry was created with an exit interface and no next-hop address. The route is directly connected and there are multiple ARP cache entries for destinations on the 10.1.0.0 network. The MAC address for each entry is the same. It is the hardware address of the router with IP address 192.168.1.194. The router is sending ARP replies for all hosts on the 10.1.0.0 network. As discussed in Chapter 1, this proxy ARP is enabled by default in IOS.
The second set of tables shows the route table and ARP cache when the next-hop address is specified in addition to the exit interface. Notice the route is no longer directly connected. It is known via 192.168.1.194 and the exit interface is Ethernet 0. The ARP cache has no entries for thethe exit interface is Ethernet 0. The ARP cache has no entries for the 10.1.0.0 network, only for the addresses that actually exist on the directly connected network, including 192.168.1.194.
Case Study: Simple IPv6 Static Routes
IPv6 static routes are configured the same way as IPv4 static routes. The only difference is that the IPv6 prefix length of the destination network is entered rather than the dotted decimal form of the IPv4 network mask.
Unlike IPv4, however, IPv6 routing is not enabled by default. Before entering a static route, IPv6 must be enabled using the ipv6 unicast-routing command. As with IPv4, an IPv6 address must be configured on the exit interface and the interface must be up before the static entry will be added to the route table. The command used to create a static route is ipv6 route followed by the network to be entered into the route table, the length, in bits of the prefix, and the address of the next-hop router, or the exit interface to be used to reach this destination.
To specify the next-hop address in the static route entry, you need to know what that address is. A detailed network drawing will help, but it may be out of date because of the dynamic nature of the Interface ID portion of the addresses. When addressing the IPv6 network, if you specify interface IDs manually rather than using the automatically constructed EUI-64 format addresses, the next-hop address will be predictable. However, if the interfaces on the data link are configured to use EUI-64 interface IDs, you only specify the first 64 bits of the address.
The router determines the final 64 bits based on a MAC address. If a router is replaced, the new router will have different IPv6 addresses. (The first 64 bits will remain the same, but the final 64 bits will be different.) One way to identify the full 128-bit IPv6 address of a neighbor router is to use the Cisco Discovery Protocol (CDP) statistics. CDP displays information about neighboring routers, such as the router's hostname, router type, IOS, and the IP addresses configured on the remote end of the link. Example 3-7 displays one form of the show cdp command.
Example 3-7. Cisco Discovery Protocol can tell you a lot of information about a device's neighbors.information about a device's neighbors.
Honeybee#show cdp neighbor detail ------------------------- Device ID: Honeytree Entry address(es): IP address: 10.4.6.2 IPv6 address: FE80::2B0:64FF:FE30:1DE0 (link-local) IPv6 address: FEC0::1:2B0:64FF:FE30:1DE0 (site-local) Platform: cisco 2610, Capabilities: Router Interface: Serial0/0.2, Port ID (outgoing port): Serial0/0.2 Holdtime : 146 sec Version : Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEAS Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Wed 11-Feb-04 19:24 by kellythw advertisement version: 2
Example 3-7 displays a lot of information about the neighbor router, including the router type, IOS, host name and IP addresses. The detail keyword is required to obtain all the information that is displayed.
Another way to determine the IPv6 address of a link is to issue the show ipv6 interface command. This command displays the IPv6 information relevant to an interface. Example 3-8 shows the output from the command issued on Honeybee.
Example 3-8. show ipv6 interface displays IPv6 information relevant to an interface, including the IPv6 EUI-64 formatted addresses.
Honeybee#show ipv6 interface serial0/0.1 Serial0/0.1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::204:C1FF:FE50:F1 Description: Link to Piglet Global unicast address(es): FEC0::3:204:C1FF:FE50:F1C0, subnet is FEC0:0:0:3::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF30:1DE0
Figure 3-3 shows a simple network with IPv6 addresses. [5] [5]
The interface addresses are configured with EUI-64 addresses. The addresses, therefore, are unique to each router based on MAC address. To reproduce the configuration, you'd have to determine your router's interface addresses to use as the next hop.
Figure 3-3. Static routing also works with IPv6.
[View full size image]
Example 3-9 shows the commands for entering Honeypot's IPv6 static routes. Example 3-9. Configuring Honeypot's IPv6 static routes.
ipv6 unicast-routing interface serial 0/0.2 point-to-point ipv6 address fec0:0:0:3::/64 eui-64 ipv6 route fec0::1:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 ipv6 route fec0::a:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 ipv6 route fec0::8:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0
Example 3-10 and Example 3-11 show the route entries for the other two routers, Honeytree and Honeybee, respectively. Example 3-10. Configuring IPv6 static routes for Honeytree.
ipv6 route fec0::8:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 ipv6 route fec0::3:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 ipv6 route fec0::5:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0
Example 3-11. Configuring IPv6 static routes for Honeybee.
ipv6 route fec0::a:0:0:0:0/64 fec0::1:2b0:64ff:fe30:1de0 ipv6 route fec0::5:0:0:0:0/64 fec0::3:230:94ff:fe24:b780
Look at the next-hop address used for Honeypot's routes, and the next-hop address used for Honeytree's routes. Honeypot's next-hop addresshop address used for Honeytree's routes. Honeypot's next-hop address for each route is fec0::3:204:c1ff:fe50:f1c0. The next-hop address used for Honeytree's routes is fec0::1:204:c1ff:fe50:f1c0. These addresses are those of Honeybee's interfaces to Honeypot and Honeytree, respectively. Notice that the last 64 bits of each of Honeybee's interface addresses are the same. The router uses its first encountered MAC address to form the last 64 bits of the EUI-64 formatted IPv6 addresses on each of its serial interfaces.
As with IPv4, IPv6 static routes can use the outbound interface rather than next-hop address. There is an option to enter an address after the interface as there is with IPv4. You can put either the link-local address here or a configured address. This next-hop address should be used when the exit interface is a broadcast interface, such as Ethernet.
Example 3-12 displays Honeypot's IPv6 route table with only the next-hop address specified in the ipv6 route statement. The command show ipv6 route displays the IPv6 route table. Prefixes, prefix lengths, and the next-hop address or outgoing interface are displayed, as are the administrative distance and route metric.
Example 3-12. As with IPv4, the IPv6 static route table displays the destination network and the next-hop address used to reach the destination.
Honeypot#show ipv6 route Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 L C FE80::/10 [0/0] via ::, Null0 FEC0:0:0:3::/64 [0/0] via ::, Serial0/0.2L S S S C L L FEC0::3:230:94FF:FE24:B780/128 [0/0] via ::, Serial0/0.2 FEC0:0:0:A::/64 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 FEC0:0:0:8::/64 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 FEC0:0:0:1::/64 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 FEC0:0:0:5::/64 [0/0] via ::, Ethernet0/0 FEC0::5:230:94FF:FE24:B780/128 [0/0] via ::, Ethernet0/0 FF00::/8 [0/0] via ::, Null0
The static routes displayed in Example 3-12 were entered using an IPv6 next-hop address. The router must determine the exit interface associated with this IPv6 address recursively, as it does with IPv4. The entry for FEC0:0:0:A::/64 has a next-hop address of FEC0::3:204:C1FF:FE50:F1C0. Looking further into the route table, FEC0:0:0:3::/64 is connected on Serial0/0.2. Notice that the administrative distance of the static routes entered with the next-hop IPv6 address is 1 and the route metric is 0, the same as IPv4 static route entered in this way.
Routes can also be entered with the outgoing interface toward the destination network. The outgoing interface and the next-hop address can be entered together, too. Example 3-13 shows what Honeypot's static route configuration could be changed to. Example 3-13. Alternative static route configuration for Honeypot.
ipv6 route fec0::a:0:0:0:0/64 serial 0/0.2ipv6 route fec0::8:0:0:0:0/64 serial 0/0.2 ipv6 route fec0::1:0:0:0:0/64 serial 0/0.2 ipv6 route fec0::20:0:0:0:0/62 Ethernet0/0 FE80::2B0:64FF:FE30:
The last entry, using the exit interface and the next-hop address will help to illustrate the difference in the route table between the two forms of the command. Example 3-14 displays Honeypot's new route table.
Example 3-14. Honeypot route table after changing the next hop to the exit interface.
Honeypot#show ipv6 route static S S S S FEC0:0:0:A::/64 [1/0] via ::, Serial0/0.2 FEC0:0:0:8::/64 [1/0] via ::, Serial0/0.2 FEC0:0:0:1::/64 [1/0] via ::, Serial0/0.2 FEC0:0:0:20::/62 [1/0] via FE80::2B0:64FF:FE30:1DE0, Ethernet0/0
One thing to notice in the route table is the administrative distance of the static route configured with an exit interface. The distance is 1, unlike IPv4 static routes configured the same way. The route does not appear to be directly connected as it does with IPv4.
The next-hop address is undetermined when you enter the outbound interface unless you specify the exit interface and the next-hop address. You can see this in the route table shown in Example 3-14. The first statement, for instance, says that FEC0:0:0:A::/64 is known via ::, Serial 0/0.2. The "::" means that the next hop is unspecified, but the outgoinginterface is Serial 0/0.2. On a point-to-point serial interface, an unspecified next-hop address is not a problem. There is only one other device on that point-to-point network, and all packets are forwarded out the interface and reach the other device.
On a broadcast interface, the router must find a neighbor to which to send the packet. The router multicasts a neighbor solicitation message on the Ethernet and waits for a neighbor advertisement from the next-hop device. There is no defined proxy address resolution mechanism with IPv6, other than for mobile IPv6 nodes. A router on the Ethernet that has a route to the destination will not respond to a neighbor solicitation on behalf of another device.
For this reason, when using an exit interface to configure a static route on a broadcast network, a next-hop address must also be specified. The recommended address to use as the next-hop address is the link-local address of the next-hop router. One reason to use the link-local address is that it is not likely to change. A link-local address will only change if the interface card, or the entire router, is replaced. Even if the site is renumbered with a different IPv6 global prefix, the link-local address on the interface does not change. Another reason to use the link-local address as the next hop is to remain consistent with the addresses routers advertise in the router advertisement messages and so that processes using those addresses, such as ICMPv6 Redirect, will operate as expected.
Routers advertise their presence, along with their link-local addresses, to all IPv6 devices on broadcast networks. Hosts use the router list created from the router advertisement to determine how to forward packets off the network. If a host forwards a packet to a router, and that router knows that a second router on the network is a better choice for the host to use, the first router will send a redirect to the host. The redirect includes the link-local IPv6 address of the better choice router. When the host processes the redirect, if the better router is in its router list, the host will begin to forward packets to the better router. If the better router is not in the list (or it is listed by a different IPv6 address), the host will discard the redirect.
Case Study: Summary Routes
A summary route is an address that encompasses several more specific addresses in a route table. It is the address mask used with a route entry that makes static routes as flexible as they are; by using an appropriate address mask, it is sometimes possible to create a single summary route for several destination addresses.
For example, the preceding two case studies use a separate entry for each data link. The mask of each entry corresponds to the address mask used on the device interfaces connected to that data link. Looking again at Figure 3-2, you can see that subnets 10.4.6.0/24 and 10.4.7.0/24 could be specified to Piglet with a single entry of 10.4.0.0/16, reachable via Tigger. Likewise, subnets 192.168.1.0/27 and 192.168.1.64/27 could be accounted for in its route table with a single entry pointing to 192.168.1.0/24, also reachable via Tigger. These two route entries, 10.4.0.0/16 and 192.16.1.0/24, are summary routes.
Using summary routes, Piglet's static route entries are displayed in Example 3-15.
Example 3-15. Piglet's static route entries are summarized into only two entries.
ip route 192.168.1.0 255.255.255.0 192.168.1.193 ip route 10.4.0.0 255.255.0.0 192.168.1.193
All subnets of network 10.0.0.0 are reachable from Pooh via Tigger, so a single entry to that major network address and a corresponding mask are all that is needed (see Example 3-16).
Example 3-16. Pooh's static route entries for all of network 10.0.0.0 subnets are summarized into a single entry.10.0.0.0 subnets are summarized into a single entry.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.66
From Eeyore, all destination addresses beginning with 192 are reachable via Tigger. The single route entry does not even have to specify all of the Class C address bits [6] , as displayed in Example 3-17. [6]
This method of summarizing a group of major network addresses with a mask shorter than the default address mask for that class is known as supernetting. This is introduced in Chapter 6.
Example 3-17. Eeyore summarizes all routes beginning with 192 into a single entry.
ip route 192.0.0.0 255.0.0.0 10.4.6.1 ip route 10.1.0.0 255.255.0.0 10.4.6.1
Summary routes can also be applied to the IPv6 destination addresses in Figure 3-3.
Honeypot's two static routes can be summarized into a group consisting of fec0:0:0:8:: through fec0:0:0:b:: by changing the prefix length from 64 to 62, as in Example 3-18.
Example 3-18. Honeypot summarizes IPv6 static routes.
ipv6 route fec0::8:0:0:0:0/62 fec0::3:204:c1ff:fe50:f1c0
By summarizing a group of subnets or even major networks, the number of static route entries may be reduced drasticallyin this example, by more than one-third. However, caution must be used when summarizing addresses; when done incorrectly, unexpected routing behavior may occur (see "Case Study: Tracing a Failed Route," later in this chapter).
Summarization and the problems that can develop from incorrect summarization are examined in more depth in Chapters 7, "Enhanced Interior Gateway Routing Protocol (EIGRP)," and 8, "OSPFv2."
Case Study: Alternative Routes
In Figure 3-4, a new link has been added between Pooh and Eeyore. All packets from Pooh to the 10.0.0.0 networks will take this new path with the exception of packets destined for the host 10.4.7.25; a policy is in place stating that traffic to this host must go through Tigger. The static route commands at Pooh will be as displayed in Example 3-19.
Figure 3-4. A more direct path from Pooh to the 10.4.0.0 subnets is added to the network.
[View full size image]
Example 3-19. Pooh's static route commands help implement a policy directing traffic through specific routers.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.34 ip route 10.4.7.25 255.255.255.255 192.168.1.66
The first two route entries are the same as before except that the second path now points to the new interface 192.168.1.34 at Eeyore. The third entry is a host route, pointing to the single host 10.4.7.25 and made possible by setting the address mask to all ones. Notice that unlike the entry for the other 10.0.0.0 subnets, this host route points to Tigger's interface 192.168.1.66.
The debugging function debug ip packet is turned on in Pooh (see Example 3-20) to observe the paths packets take from the router as a result of the new route entries. A packet is sent from a host 192.168.1.15 to host 10.4.7.25. The first two debug trap messages show that the packet is routed from interface E0 to the next-hop router 192.168.1.66 (Tigger) out interface S0, as required, and that the reply packet was received on S0 and routed to the host 192.168.1.15 out E0.
Example 3-20. Debugging verifies that the new route entries at Pooh are working correctly.
Pooh#debug ip packet
IP packet debugging is on
Pooh# IP: s=192.168.1.15 (Ethernet0), d=10.4.7.25 (Serial0), g=192.16 IP: s=10.4.7.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.16 Pooh# IP: s=192.168.1.15 (Ethernet0), d=10.4.7.100 (Serial1), g=192.1IP: s=10.4.7.100 (Serial0), d=192.168.1.15 (Ethernet0), g=192.1 Pooh#
Next, a packet is sent from host 192.168.1.15 to host 10.4.7.100. Packets destined for any host on 10.0.0.0 subnets, other than host 10.4.7.25, should be routed across the new link to Eeyore's interface 192.186.1.34.
The third debug message verifies that this is indeed happening. However, the fourth message shows something that at first might be surprising. The response from 10.4.7.100 to 192.168.1.15 arrived on Pooh's interface S0 from Tigger.
Remember that the route entries in the other routers have not changed from the original example. This result might or might not be desired, but it does illustrate two characteristics of static routes:
First, if the network topology changes, the routers that are required to know about those changes must be reconfigured. Second, static routes can be used to create very specific routing behavior. In this example, perhaps it is desirable to have traffic taking one path in one direction and another path in the opposite direction.
A final observation about this example is that packets routed from Pooh to subnet 10.1.5.0 take a less-than-optimal route, from Pooh to Eeyore to Tigger instead of directly from Pooh to Tigger. Example 3-21 shows a more efficient configuration for Router Pooh.
Example 3-21. Configuring a more efficient static route on Router Pooh.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.34ip route 10.1.0.0 255.255.0.0 192.168.1.66 ip route 10.4.7.25 255.255.255.255 192.168.1.66
The third entry will now send all packets for subnet 10.1.5.0 directly to Tigger.
Case Study: Floating Static Routes
Unlike other static routes, a floating static route is less preferred than other routes in the route table. It appears in the table only under the special circumstance of the failure of a more-preferred route.
In Figure 3-5, a new router (Rabbit) is connected to Piglet with two parallel links. One link connects their respective Serial 0 interfaces, and the second connection has been added between the two Serial 1 interfaces. This second link has been added for redundancy: If the primary link 10.1.10.0 fails, floating static routes will direct traffic across the backup link 10.1.20.0.
Figure 3-5. A new router has been connected to Piglet. Two serial links are used: one for the primary link and one for the backup link.
[View full size image]
Additionally, the mask on Piglet's Ethernet interface has changed from 10.1.5.1/16 to 10.1.5.1/24. This change allows the single route entry at Tigger
ip route 10.1.0.0 255.255.0.0 192.168.1.194
to point not only to 10.1.5.0 but also to all of the new subnets used in association with the new router.
To create the floating static route, Example 3-22 and Example 3-23 show the route entries for both Piglet and Rabbit, respectively. Example 3-22. Route entries for Piglet to create a floating static route.
ip ip ip ip route route route route 192.168.1.0 255.255.255.0 192.168.1.193 10.4.0.0 255.255.0.0 192.168.1.193 10.1.30.0 255.255.255.0 10.1.10.2 10.1.30.0 255.255.255.0 10.1.20.2 50
Example 3-23. Route entries for Rabbit to create a floatingExample 3-23. Route entries for Rabbit to create a floating static route.
ip ip ip ip ip ip route route route route route route 10.4.0.0 255.255.0.0 10.1.10.1 10.4.0.0 255.255.0.0 10.1.20.1 50 10.1.5.0 255.255.255.0 10.1.10.1 10.1.5.0 255.255.255.0 10.1.20.1 50 192.168.0.0 255.255.0.0 10.1.10.1 192.168.0.0 255.255.0.0 10.1.20.1 50
Two entries at Piglet point to Rabbit's network 10.1.30.0; one specifies a next-hop address of Rabbit's S0 interface, and the other specifies a next-hop address of Rabbit's S1 interface. Rabbit has similar double entries for every route.
Notice that all static routes using subnet 10.1.20.0 are followed by a 50. This number specifies an administrative distance, which is a measure of preferability; when duplicate paths to the same network are known, the router will prefer the path with the lower administrative distance. At first this idea sounds like a metric; however, a metric specifies the preferability of a route, whereas an administrative distance specifies the preferability of the means by which the route was discovered.
For example, IPv4 static routes pointing to a next-hop address have an administrative distance of 1, and static routes referencing an exit interface have an administrative distance of 0. If two static routes point to the same destination, but one references a next-hop address and one references an exit interface, the latterwith the lower administrative distance will be preferred.
By increasing the administrative distances of the static routes traversing subnet 10.1.20.0 to 50, they become less preferred than the routes traversing subnet 10.1.10.0. Example 3-24 shows three iterations of Rabbit's route table. In the first table, all routes to non connected networks use a next-hop address of 10.1.10.1. The bracketed numbers associated with each route indicate an administrative distance of 1 and a metric of 0 (because no metrics are associated with static routes).
Example 3-24. When the primary link 10.1.10.0 fails, the backup link 10.1.20.0 is used. When the primary link is restored, it is again the preferred path.
Rabbit#show ip route 10.0.0.0 is variably subnetted, 5 subnets, 2 masks C 10.1.10.0 255.255.255.0 is directly connected, Serial0 S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 C 10.1.20.0 255.255.255.0 is directly connected, Serial1 S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 Rabbit# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change %LINK-3-UPDOWN: Interface Serial0, changed state to down Rabbit#show ip route 10.0.0.0 is variably subnetted, 4 subnets, 2 masks S 10.4.0.0 255.255.0.0 [50/0] via 10.1.20.0 S 10.1.5.0 255.255.255.0 [50/0] via 10.1.20.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 C 10.1.20.0 255.255.255.0 is directly connected, Serial1 S 192.168.0.0 255.255.0.0 [50/0] via 10.1.20.1 Rabbit# %LINK-3-UPDOWN: Interface Serial0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, change Rabbit#show ip route 10.0.0.0 is variably subnetted, 5 subnets, 2 masks C 10.1.10.0 255.255.255.0 is directly connected, Serial0 S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 Rabbit#
Next, trap messages announce that the state of the primary link connected to Serial 0 has changed to "down," indicating a failure. A look at the second iteration of the route table shows that all nonconnected routes now point to a next-hop address of 10.1.20.1. Because the more-preferred entry is no longer available, the router has switched to the less-preferred backup link, with the administrative distance of 50 indicated in the brackets. And because subnet 10.1.10.0 has failed, it no longer shows up in the route table as a directly connected network.
Before the third iteration of the route table, trap messages indicate that the state of the primary link has changed to "up." The route table then shows that subnet 10.1.10.0 is again in the table, and the router is again using the next-hop address of 10.1.10.1.
Chapter 11 discusses the administrative distances associated with the various dynamic routing protocols, but it can be said here that the administrative distances of all dynamic routing protocols are substantially higher than 1. Therefore, by default, a static route to a network will always be preferred over a dynamically discovered route to the same network.
Case Study: IPv6 Floating Static Routes
IPv6 floating static route statements work the same way as IPv4. A second link has been added to the IPv6 network of Figure 3-3 between Honeypot and Honeybee, to route IPv6 traffic if the primary link fails (see Figure 3-6).
Figure 3-6. Backup link added between two IPv6 routers can be used to recover from a primary link failure with floating static routes.floating static routes.
[View full size image]
Example 3-25 shows Honeypot's configuration with new static route entries, which have an administrative distance greater than 1. Similar static routes are entered on Honeybee, as shown in Example 3-26. Example 3-25. Honeypot is configured with floating static routes to be used over the new redundant parallel link to Honeybee.
ipv6 ipv6 ipv6 ipv6 route route route route FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 50 FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0 FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 50
Example 3-26. Honeybee is configured with floating static routes to be used over the new redundant parallel link to Honeypot.Honeypot.
ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780 ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 50 ipv6 route FEC0:0:0:A::/64 FEC0::1:2B0:64FF:FE30:1DE0
IPv6 traffic from Honeypot will continue to be forwarded out Serial0/0.2, unless this link goes down.
Example 3-27 shows Honeypot's route table with the routes known via the fec0::3:0:0:0:0/64 subnet installed. Both routes have an administrative distance of 1. Then, interface S0/0.2 goes down. The backup routes, with administrative distance of 50, get installed in the route table. After the interface S0/0.2 comes back up, the routing process learns of better routes to the destinations and installs the routes with an administrative distance of 1 back into the table.
Example 3-27. Static routes with high administrative distances are installed in the IPv6 route table only when the lower administrative distance routes are deleted.
Honeypot#show ipv6 route static S FEC0::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 S FEC0:0:0:8::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 Honeypot# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan %LINK-3-UPDOWN: Interface Serial0/2, changed state to down Honeypot#show ipv6 route static S FEC0::/62 [50/0] via FEC0::2:204:C1FF:FE50:F1C0 S FEC0:0:0:8::/62 [50/0]via FEC0::2:204:C1FF:FE50:F1C0 Honeypot# %LINK-3-UPDOWN: Interface Serial0/2, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, chan
The default administrative distance of IPv6 static routes, whether specified with an exit interface or a next-hop address, is 1. When static routes to a destination are specified both ways, the routes are considered equal, and load sharing (described in the next case study) occurs.
Case Study: Load Sharing
The problem with the configuration used in the previous section is that under normal circumstances the second link is never utilized. The bandwidth available on the link is wasted. Load sharing allows routers to take advantage of multiple paths to the same destination by sending packets over all the available routes.
Load sharing can be equal cost or unequal cost, where cost is a generic term referring to whatever metric (if any) is associated with the route:
- Equal-cost load sharing distributes traffic equally among multiple paths with equal metrics. In this case, load sharing can also be called load balancing.
- Unequal-cost load sharing distributes packets among multiple paths with different metrics. The traffic is distributed in inverse proportion to the cost of the routes. That is, paths with lower costs are assigned more traffic, and paths with higher costs are assigned less traffic.
Some routing protocols support both equal-cost and unequal-cost load sharing, whereas others support only equal cost. Static routes, which have no metric, support only equal-cost load sharing.To configure the parallel links in Figure 3-5 for load sharing using static routes, Example 3-28 shows the route entries for Piglet and Example 3-29 shows the route entries for Rabbit.
Example 3-28. Configuring parallel links for load sharing using static routes: route entries for Piglet.
ip ip ip ip route route route route 192.168.1.0 255.255.255.0 192.168.1.193 10.4.0.0 255.255.0.0 192.168.1.193 10.1.30.0 255.255.255.0 10.1.10.2 10.1.30.0 255.255.255.0 10.1.20.2
Example 3-29. Configuring parallel links for load sharing using static routes: route entries for Rabbit.
ip ip ip ip ip ip route route route route route route 10.4.0.0 255.255.0.0 10.1.10.1 10.4.0.0 255.255.0.0 10.1.20.1 10.1.5.0 255.255.255.0 10.1.10.1 10.1.5.0 255.255.255.0 10.1.20.1 192.168.0.0 255.255.0.0 10.1.10.1 192.168.0.0 255.255.0.0 10.1.20.1
These entries were also used in the previous section for floating static routes, except both links now use the default administrative distance of 1. Rabbit's route table, shown in Example 3-30, now has two routes to each destination.
Example 3-30. This route table indicates that there are two paths to the same destination networks. The router will balance the load across these multiple paths.balance the load across these multiple paths.
Rabbit#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte E1 - OSPF external type 1, E2 - OSPF external type 2, E i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - c U - per-user static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.1.10.0/24 is directly connected, Serial0 S 10.1.5.0/24 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 S 10.4.0.0/16 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 C 10.1.20.0/24 is directly connected, Serial1 S 192.168.0.0/16 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 Rabbit#
IPv6 works the same way as IPv4. The static routes in Honeypot's route table, shown in Example 3-31, will yield the route table shown in Example 3-32.
Example 3-31. Honeypot's IPv6 static routes are configured for load-balancing, with each destination prefix using two different next-hop addresses.
ipv6 ipv6 ipv6 ipv6 route route route route FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
Example 3-32. The router will load balance over these two IPv6 paths to the same destination networks.
Honeypot#show ipv6 route static S FEC0::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 via FEC0::2:204:C1FF:FE50:F1C0 S FEC0:0:0:8::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 via FEC0::2:204:C1FF:FE50:F1C0
Load sharing is also either per destination or per packet.
Load Sharing and Cisco Express Forwarding
Per destination load sharing distributes the load according to destination address. Given two paths to the same network, all packets for one destination may travel over the first path, all packets for a second destination on the same network may travel over the second path, all packets for a third destination may again be sent over the first path, and so on. This is the default type of load sharing used by Cisco Express Forwarding (CEF). On most platforms, CEF is the default switching mode for IPv4, but not IPv6.
CEF is a very efficient switching process. Its forwarding information is obtained and stored in tables before any packet needs to use the information. CEF builds a forwarding information base (FIB) with information obtained from the route table. All the destination networks entered in the route table are entered into the CEF FIB. If the route table is stable and not changing, the FIB will not change. CEF uses a separate table, the adjacency table, to maintain Layer 2 forwarding information for each entry in the FIB. The adjacency table is created as Layer 2 information is learned, through IP ARP or IPv6 Neighbor Discovery, for instance. Both the FIB and adjacency table are created before packets need to be forwarded. Not even the first packet to a destination is process switched, as is the case with other switching schemes.
CEF performs per-destination load sharing by default. This is actually per source-destination pair load sharing. All traffic that has a particular source address and is destined to a specific destination address will exit the same interface. Traffic with a different source/destination address pair may exit the next interface.
Per packet load sharing is another method available to CEF switched IPv4 packets. IPv6 CEF only supports per destination load sharing. Per packet load sharing means that one packet is sent over one link, the next packet is sent over the next link, even if this next packet is to the same destination as the first, and so on, given equal-cost paths. If the paths are unequal cost, the load sharing may be one packet over the higher-cost link for every three packets over the lower-cost link, or some other proportion depending upon the ratio of costs. Per packet load sharing may distribute the load more evenly than per destination load sharing, depending upon the number of different source-destination pairs, but because the packets to a given destination will be taking different paths, the packets are likely to arrive out of order, which is unacceptable for some applications, such as Voice over IP.
To determine if CEF is enabled globally on a router, use the commands show ip cef and show ipv6 cef. If it is not enabled by default, you can turn it on globally using the command ip cef for IPv4. To enable CEF for IPv6, first enable CEF for IPv4, then use the command ipv6 cef. Per packet load sharing is enabled for IPv4 using the interface command ip load-sharing per-packet. The command ip load-sharing per-destination re-enables per destination load sharing. You can see which type of load sharing is enabled using the show cef interface command.
This displays the CEF information that is configured on the interface.The router determines whether to use CEF switching based on the ingress interface and the type of source and destination address. The ingress interface must be configured with CEF switching for the router to even consider using CEF. If CEF is configured on the ingress interface, CEF will attempt to switch the packet. If for some reason the packet cannot be CEF switched, CEF punts the packet down to the next-best and available switching method. For IPv4, this would be fast switching, if it is enabled on the interface. For IPv6, this would be process switching.
You can verify that CEF is enabled on an interface using the commands show cef interface {interface} and show ipv6 cef {interface} detail. Per Destination Load Sharing and Fast Switching IOS performs per destination load sharing on exit interfaces configured with fast switching. Fast switching is the default IOS switching mode in some routers.
Fast switching works as follows:
- When a router switches the first packet to a particular destination, a route table lookup is performed and an exit interface is selected.
- The necessary data-link information to frame the packet for the selected interface is then retrieved (from the ARP cache, for instance), and the packet is encapsulated and transmitted.
- The retrieved route and data-link information is then entered into a fast switching cache.
- As subsequent packets to the same destination enter the router, the information in the fast cache allows the router to immediately switch the packet without performing another route table and ARP cache lookup.
While switching time and processor utilization are decreased, fast-switching means that all packets to a specific destination, not source-destination pair, are routed out the same interface. When packets destination pair, are routed out the same interface. When packets addressed to a different host on the same network enter the router and an alternate route exists, the router may send all packets for that destination on the alternate route. Therefore, the best the router can do is balance traffic on a per destination basis.
Per Packet Load Sharing and Process Switching Process switching simply means that for every packet, the router performs a route table lookup, selects an interface, and then looks up the data link information. Because each routing decision is independent for each packet, all packets to the same destination are not forced to use the same interface. To enable process switching on an interface, use the command no ip route-cache for IPv4. You don't have to do anything to enable process switching for IPv6. It is enabled by default.
In Example 3-33, host 192.168.1.15 has sent six pings to host 10.1.30.25. Using debug ip packet, the ICMP echo request and echo reply packets are observed at Piglet. Looking at the exit interfaces and the forwarding addresses, it can be observed that both Piglet and Rabbit are using S0 and S1 alternately. Note that the command debug ip packet allows only process switched packets to be observed. Fast switched packets are not displayed.
Note The debug ip packet command displays only process switched packets.
Example 3-33. This router is alternating between S0 and S1 to send packets to the same destination. Notice that the router on the other end of the two links is doing the same thing with the reply packets.thing with the reply packets.
Piglet#debug ip packet
IP packet debugging is on
Piglet# IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), Piglet#
Like many design choices, per packet load balancing has a price. The traffic may be distributed more evenly among the various links than with per destination load balancing, but the lower switching time and processor utilization of fast switching are lost.
Which Switching Method Will Be Used?
IOS makes switching decisions based on the configuration of the inbound interface first. If CEF is configured on an inbound interface, the packet will be CEF switched regardless of the configuration on the outbound interface.
If CEF is not enabled on the inbound interface, then IOS processes and forwards the packet, and based on the configuration of the outbound
g=10.1. g=192.1 g=10.1. g=192.1 g=10.1. g=192.1 g=10.1. g=192.1 g=10.1. g=192.1 g=10.1. g=192.1interface, subsequent packets will be fast-switched or process switched.
Table 3-1 shows which switching method will be used based on configuration of inbound and outbound interfaces.
Table 3-1. IOS switching determination is based on configuration of inbound and outbound interfaces. Inbound Configuration Outbound Configuration Switching Method Used
CEF Process CEF CEF Fast CEF Process CEF Fast (or process if IPv6) Process Fast Fast Fast CEF Fast (or process if IPv6) Fast Process
Process
IOS will switch a packet using CEF only if CEF is enabled on the inbound interface. If CEF is not configured on the inbound interface, the configuration of the exit interface determines the switching method.
Notice that when process or fast-switching is configured inbound and CEF is configured on the outbound interface, fast-switching is used. CEF is only used if it is configured on the ingress interface. For IPv4, fast-switching is enabled outbound, even if CEF is enabled on the interface. There are times when a packet will not be switched using CEF even if it is enabled (for example, if access-list logging is enabled and a packet will be logged). Packets will be punted down to the next fastest switching method. For IPv4, the next fastest switching method is fast-switching. For IPv6, this is process switching.IPv6, this is process switching.
Case Study: Recursive Table Lookups
All route entries do not necessarily need to point to the next-hop router. Figure 3-7 shows a simplified version of the network of Figure 3-5. In this network, Pooh is configured as displayed in Example 3-34. Figure 3-7. To reach network 10.1.30.0, Pooh must perform three route table lookups.
[View full size image]
Example 3-34. Pooh's static route entries use various addresses as the next-hop parameter. The addresses are not necessarily the actual next-hop router interface.
ip route 10.1.30.0 255.255.255.0 10.1.10.2 ip route 10.1.10.0 255.255.255.0 192.168.1.194 ip route 192.168.1.192 255.255.255.224 192.168.1.66
If Pooh needs to send a packet to host 10.1.30.25, it will look into its route table and find that the subnet is reachable via 10.1.10.2. Because that address is not on a directly connected network, Pooh must again consult the table to find that network 10.1.10.0 is reachable via 192.168.1.194. That subnet is also not directly connected, so a third table lookup is called for. Pooh will find that 192.168.1.192 is reachable via 192.168.1.66, which is on a directly connected subnet. The packet can now be forwarded.
Because each table lookup costs processor time, under normal circumstances forcing a router to perform multiple lookups is a poor design decision. Fast switching significantly reduces these adverse effects by limiting the recursive lookups to the first packet to each destination, but a justification should still be identified before using such a design.
Figure 3-8 shows an example of an instance in which recursive lookups might be useful. Here, Sanderz reaches all networks via Heffalump. However, the network administrator plans to eliminate Heffalump and repoint all of Sanderz's routes through Woozle. The first 12 entries point not to Heffalump, but to the appropriate router attached to the 10.87.14.0 subnet. The last entry specifies that the 10.87.14.0 subnet is reached via Heffalump.
Figure 3-8. Configuring Sanderz for recursive lookups enables the network administrator to redirect all of that router's exit traffic from Heffalump to Woozle by changing one route entry.
[View full size image]
With this configuration, all of Sanderz's entries can be repointed through Woozle simply by changing the last static entry as in Example 3-35. Example 3-35. Sanderz's routing can easily be modified to forward all routes through a different next-hop router simply by changing one static route entry.
Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95 Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.2
Had all the static routes referenced 10.23.5.20 as the next-hop address, it would have been necessary to delete all 13 lines and type 13 new lines. Nevertheless, the effort saved in retyping static routes must be weighed carefully against