Using Default and Static Routes in Complicated Networks
In this section, several scenarios are presented using static routes and gateways of last resort. These concepts are some of the most difficult for those new to the nuances of IP routing to understand. To truly understand routing, you must have a solid grasp on the fundamentals of local domains versus non-local domains, gateways of last resort, summarized routes, and redistribution of static routes and default metrics.
People who are fully conversant in IP routing can analyze any routing table and determine what will happen when a packet to any possible destination is encountered.
Using Static Routes
In the scenario shown in Figure 5-5, you can see what happens when an improper static route has been entered to fix a routing problem.
Figure 5-5. RouterA has an improper static route.
In Figure 5-5, RouterA's routing table has been edited to show what happens when an improper static route is added to a router. RouterA has a static route to the major network of 168.71.0.0 via 168.71.6.3. Although this will enable RouterA to forward packets to 168.71.8.0, RouterA cannot reach 168.71.9.0. In fact, if RouterA received a packet for 168.71.9.1 on its Ethernet interface, it would forward it to RouterB. The proper way of doing this is shown in Figure 5-6.
Figure 5-6. RouterA has working static routes.
In Figure 5-6, the routing table has been fixed to allow full connectivity to the subnets shown. RouterA now has access to all local subnets of 168.71.0.0. It also has access to a gateway of last resort and a pointer via the summarized route that extends from 168.71.0.0 via 179.12.9.2 to other unknown subnets of 168.71.0.0 that can be found somewhere in the rest of the world.
In Figure 5-7, the routing table has been changed to show what would happen if IGRP were used in the local domain to allow full connectivity to the subnets shown and to allow static routes to all other subnets of 168.71.0.0 and other non-local domains. It is easier to use a dynamic protocol than static routes because they are easier to maintain.
Figure 5-7. IGRP has been used for some routes.
RouterA now has access to all local subnets of 168.71.0.0. RouterA also has a gateway of last resort and a pointer via the summarized route that extends from 168.71.0.0 via 179.12.9.2 to other unknown subnets of 168.71.0.0.
Dealing with Too Much Default Routing Information
One of the problems designers of IP networks face is too much default information. By using a route—in this scenario, 10.0.0.0—as both a gateway of last resort for non-local domain routes and a route for unknown subnets of the local domain, packets for networks that do not exist will end up at the router that is advertising this route.
This router can forward the packets to its own gateway of last resort—assuming it has one—or drop the packet as unroutable. The problem with dropping the packet is that the router may want to send an ICMP host or network unreachable message for each unroutable packet. This can cause significant overhead if several network users are creating packets for routes that do not exist. That is why Cisco routers send only one ICMP host unreachable message back to the original host for each group of packets that arrive within a short time period.
The following problems can lead to packets arriving for unreachable destinations:
Incorrectly typed IP addresses in connection attempts for applications, such as Telnet and FTP. Routers forward these via their default routes until their Time to Live (TTL) expires or a router drops them as unroutable.
Bookmarks in Web browsers for sites that no longer exist.
Traffic to domain name servers (DNS) that no longer exist. DNS servers are specified by an IP address, not a name. Any change in their IP address can affect the many users who have been using this address to resolve names.
In networks with thousands of users, these kinds of packets happen all of the time. One solution is to configure a route to the null0 interface. This is like /dev/null in UNIX. It is a legitimate interface that accepts the packets and then throws them away. No ICMP host or network unreachable messages are sent for packets forwarded to null0.
In the scenario shown in Figure 5-8, the routing policy for the network containing RouterA, RouterB, RouterC, and RouterD states that no other routers can advertise dynamic routes into this network. This creates a problem because 168.71.29.0 exists outside of this network, even though it is from the local domain address space of this network.
The situation shown in Figure 5-8 can happen when a branch of a company has been moved to another region and has to use a third-party network, such as the Internet, to reach the original corporate site. Ideally, the hosts on this network would have been readdressed, but sometimes connectivity must be provided because there is not enough time to readdress. This situation is resolved by configuring a redistributed static route to 168.71.29.0 in RouterD.
In Figure 5-8, RouterD has a redistributed static route to 168.71.29.0 pointing at 179.12.8.2. RouterA, RouterB, and RouterC will use this route, which they learned via IGRP, to forward packets for hosts on 168.71.29.0 in RouterD's direction.
RouterD has a redistributed static route to 10.0.0.0 that points at 179.12.8.2. This route is also tagged as a candidate default. RouterA, RouterB, and RouterC use this route, which they learned via IGRP, to forward packets for hosts on subnets in other major network domains in RouterD's direction. All packets arriving at RouterD for subnets of 168.71.0.0 that RouterD doesn't know about are sent to null0. This is due to the static route of 168.71.0.0 255.255.0.0 null0 that RouterD has configured.
Figure 5-8. Using static routes and null0.
One consequence of using static routes is that routers forward packets toward the next hop router even when the physical network that the static route points to is not operational. In Figure 5-8, RouterD forwards packets for hosts on 168.71.29.0 to the next hop of 179.12.8.2 even if the physical network that 168.71.29.0 is assigned to is down. As long as they have a route, these packets continue to be forwarded from router to router until they reach a router that has learned via a dynamic routing protocol (not a static route) that subnet 168.71.29.0 is no longer reachable.
If all of the WAN links between RouterD and the router with 168.71.29.0 attached to it in Figure 5-8 were high-speed connections, there would be little or no point in attempting to prevent these packets from being forwarded.
On the other hand, if the link between RouterD and the rest of the world were only 56Kbit and usually running at 95–99 percent, it would be useful to prevent these unnecessary packets from flowing across the link. That way, other packets could use the extra bandwidth. However, as previously stated, the policy in this network indicates that no dynamic routes are allowed in from the rest of the world; therefore, nothing can be done. This is a common tradeoff network administrators have to face every day.
This scenario brings up an interesting issue. If a router receives a packet for a subnet it has a connection to and that connection is inactive, the router could forward the packet to a gateway of last resort or a local domain static route. In order for the router to use the gateway of last resort, the subnet on the inactive interface must not be part of the router's local domain. If the subnet in question were part of the local domain, the router would forward the packet only if it had a valid local domain default route configured.
Consider what would happen if the router with the inactive interface had the only connection to the LAN that 168.71.29.0 was assigned to. The packets to hosts on 168.71.29.0 (which the router would be forwarding to its gateway of last resort or local domain default route) would still be forwarded by every other router that they encountered with the same default routes until their TTL values expired.
In other words, packets with no chance of reaching their destinations travel aimlessly around the network until they die. To make matters worse, if the inactive LAN happens to have a lot of popular Web servers or other IP hosts on it, thousands of packets could be roaming around the network wasting bandwidth.
A solution to this issue is to configure a static route to null0 for every subnet a router has an attachment to. This static route must have an administrative distance greater than the distance value associated with any dynamic IP routing protocol that might provide a viable alternative route. In this scenario, the following command would fix the problem: ip route 168.71.29.0 255.255.255.0 null0 200.
Fixing a Default Gateway Loop
In the scenario shown in Figure 5-9, a situation has been created in which two routers have installed a gateway of last resort that points to the other router.
Figure 5-9. Broken gateway of last resort.
The network administrator placed the static route for the gateway of last resort in RouterA instead of RouterB, where it belongs.
RouterA has the redistribute static command configured, as well as a default metric. This causes RouterA to advertise the route for 10.0.0.0 to RouterB. This is not a violation of split horizon because RouterA did not actually learn about 10.0.0.0 from RouterB. Having a static route pointing to another router and having a route learned from another router are not the same thing.
In other words, if RouterB had dynamically advertised a route for 10.0.0.0 to RouterA and RouterA had advertised it back to RouterB, that would be a violation of split horizon. In this case, RouterA is telling RouterB about a route that RouterA actually uses RouterB to reach.
Because RouterB doesn't have t he static route to 10.0.0.0 statically configured as it should have had, it installs the dynamic route learned from RouterA with the next hop of 168.71.6.1 and tags it as the gateway of last resort.
Packets to unknown destinations that should go to the rest of the world now bounce between the two routers. The following routing table from RouterA shows that its gateway of last resort is pointing to RouterB:
RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 168.71.6.2 to network 10.0.0.0
S* 10.0.0.0 [1/0] via 168.71.6.2
168.71.0.0 255.255.255.0 is subnetted, 3 subnets
C 168.71.6.0 is directly connected, Serial0
C 168.71.5.0 is directly connected, Ethernet0
RouterA#
The following routing table from RouterB shows that its gateway of last resort is pointing to RouterA:
RouterB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 168.71.6.1 to network 10.0.0.0
I* 10.0.0.0 [100/82125] via 168.71.6.1, 00:01:21, Serial0
168.71.0.0 255.255.255.0 is subnetted, 3 subnets
C 168.71.6.0 is directly connected, Serial0
I 168.71.5.0 [100/10002001] via 168.71.6.1, 00:01:09, Serial0
RouterB#
In the following output of the debug ip packet command from RouterB, you can see the packets entering RouterB on Serial0 and being forwarded back out the same interface. This continues until the TTL expires:
RouterB#debug ip packet
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
IP: s=171.68.207.222 (Serial0), d=168.72.1.1 (Serial0), g=168.71.6.1, len 64, forward
Clearly, the use of gateways of last resort must be carefully planned. Misuse can lead to loss of connectivity and routing loops. If a sufficient number of packets start looping the routers, the links can be overwhelmed and a routing loop storm can be created. A quick fix is a temporary static route pointing to null0 in one of the routers, which vacuums up all of the looping packets. The problem can then be fixed by placing the default routes where they belong.
The 0.0.0.0 Default Route
The 0.0.0.0 default route has special meaning to RIP and IGRP. This section explains what this meaning is and how RIP and IGRP treat it slightly differently.
RIP and 0.0.0.0
For RIP, the 0.0.0.0 route is automatically installed as the local gateway of last resort. No ip default-network 0.0.0.0 command is required. RIP automatically advertises the route to 0.0.0.0, even when redistribute static and a default metric are not configured (see Figure 5-10).
Figure 5-10. Network topology for the RIP and 0.0.0.0 scenario.
The following routing table from RouterC in Figure 5-10 shows that RouterA is advertising a route to 0.0.0.0. It appears that RouterA is the origin of this route, as well as RouterC's next hop, because it has a metric of 1.
RouterC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 168.71.9.1 to network 0.0.0.0
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
C 168.71.8.0 is directly connected, TokenRing0
C 168.71.7.0 is directly connected, Serial0
R 168.71.6.0 [120/1] via 168.71.9.1, 00:00:10, Serial1
[120/1] via 168.71.7.2, 00:00:04, Serial0
R 168.71.5.0 [120/1] via 168.71.9.1, 00:00:10, Serial1
R* 0.0.0.0 0.0.0.0 [120/1] via 168.71.9.1, 00:00:10, Serial1
RouterC#
The following partial configuration from RouterA shows how the route to 0.0.0.0 was created. In this case, null0 was used as the ultimate destination. RouterB and RouterC used 0.0.0.0 as their gateway of last resort and sent all packets for unknown non-local domain networks to RouterA.
Any packets for non-local domain networks arriving at RouterA that RouterA doesn't have a route for are sent to null0:
!
hostname RouterA
!
router igrp rip
passive-interface Ethernet0
network 168.71.0.0
!
ip route 0.0.0.0 0.0.0.0 null0
!
Notice that it was not necessary to configure redistribute static or a default metric. The metric is assumed to be that of a connected route.
In the following output of the debug ip rip command from RouterA, you can see RouterA advertising 0.0.0.0 with a metric of 1:
RouterA#debug ip rip
RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
subnet 168.71.9.0, metric 1
subnet 168.71.8.0, metric 2
subnet 168.71.5.0, metric 1
default 0.0.0.0, metric 1
RIP: sending update to 255.255.255.255 via Serial1 (168.71.9.1)
subnet 168.71.6.0, metric 1
subnet 168.71.5.0, metric 1
default 0.0.0.0, metric 1
RouterA#
In the following scenario, assume that corporate policy dictates that users connected to RouterB have access only to the corporate network. One way to prevent them from accessing the rest of the world is for RouterB to install a gateway of last resort to 0.0.0.0 pointing to null0. Every packet that RouterB receives for networks and subnetworks that it has no explicit knowledge of would be routed to null0.
The following partial configuration from RouterB shows how this is done:
hostname RouterB
!
router igrp rip
network 168.71.0.0
!
ip route 0.0.0.0 0.0.0.0 null0
!
However, RouterB would advertise that it had a route to the preferred RIP gateway of last resort to RouterA and RouterC (see Figure 5-11).
Figure 5-11. RouterB advertises 0.0.0.0 to RouterA and RouterC.
In Figure 5-12, RouterD has the "real" connectivity to the rest of the world and should be the only router advertising the route to 0.0.0.0. However, you now have a problem because both RouterD and RouterB are telling RouterA and RouterC that they have valid routes to all unknown networks.
Figure 5-12. RouterD has the real gateway of last resort.
The following partial configuration from RouterD shows its usage of 0.0.0.0:
hostname RouterD
!
router igrp rip
network 168.71.0.0
!
ip route 0.0.0.0 0.0.0.0 serial0
!
In the following routing table from RouterA, you can see that RouterA has installed two routes to 0.0.0.0:
RouterA#show ip route 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "rip", distance 120, metric 1, candidate default path
Redistributing via rip
Last update from 168.71.6.3 on Serial0, 00:00:01 ago
Routing Descriptor Blocks:
* 168.71.6.3, from 168.71.6.3, 00:00:10 ago, via Serial0
Route metric is 1, traffic share count is 1
179.12.9.2, from 179.12.9.2 , 00:00:01 ago, via Serial1
Route metric is 1, traffic share count is 1
RouterA#
Figure 5-13 shows how the routes map onto the network topology.
Figure 5-13. RouterA has two routes to 0.0.0.0.
Both routes have the same metric, so they are treated as parallel equal-cost paths. Figure 5-14 shows RouterA load sharing pings over the two links.
In the following output from RouterA pinging 132.10.10.1—an address that lives in the rest of the world— you can see that 40 percent of the pings are lost. These are the ones sent to RouterB:
RouterA#ping 132.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.10.10.1, timeout is 2 seconds:
!.!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 16/16/16 ms
RouterA#
This is a classic case of a misconfigured default route. You can prove this by configuring a static route in RouterA to 0.0.0.0 via one path and testing it with pings. Then do the same with the other path. The static route overrides the dynamic route to 0.0.0.0. The one that works for 100 percent of the pings is the correct path, and the one that fails completely is the broken path.
Figure 5-14. RouterA will load share pings over the two routes to 0.0.0.0.
In Figure 5-15, you can see the path that RouterC has installed for 0.0.0.0:
The following routing table from RouterC shows the single route to 0.0.0.0 via RouterB:
RouterC#show ip route 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "rip", distance 120, metric 1, candidate default path
Redistributing via rip
Last update from 168.71.6.3 on Serial0, 00:00:01 ago
Routing Descriptor Blocks:
* 168.71.6.3, from 168.71.6.3, 00:00:10 ago, via Serial0
Route metric is 1, traffic share count is 1
RouterC#
Figure 5-15. RouterC has the wrong path
Note that the metric is 1. The other route via RouterD would have a metric of 2. In Figure 5-16, you can see the path pings take for 132.10.10.1 from RouterC.
Figure 5-16. RouterC can't ping 132.10.10.1.
In the following output of RouterC pinging 132.10.10.1, you can see that 100 percent of the pings fail:
RouterC#ping 132.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.10.10.1, timeout is 2 seconds:
…
Success rate is 0 percent (0/5)
RouterC#
This proves that RouterC is attempting to use the incorrect route to the gateway of last resort via RouterB because it has a lower metric than the path advertised from RouterD via RouterA.
Having discovered that, in this case, RouterB is causing the problem, your fix is to stop RouterB from advertising the route for 0.0.0.0 to any other routers. Figure 5-17 shows the places the advertisements for 0.0.0.0 need to be blocked.
Figure 5-17. RouterB's advertisements for 0.0.0.0 must be blocked.
The following partial configuration from RouterB shows how to do this:
!
router rip
network 168.71.0.0
distribute-list 1 out
!
ip route 0.0.0.0 0.0.0.0 null0
!
access-list 1 deny 0.0.0.0 0.0.0.0
access-list 1 permit 0.0.0.0 255.255.255.255
!
access-list 1 denies the default route of 0.0.0.0 with the mask of 0.0.0.0, while allowing all other routes with the permit all statement of 0.0.0.0 255.255.255.255.
Remember that all access lists have an implicit deny all at the end. If the goal is to permit some traffic that doesn't meet the test cases earlier in the access list, the final visible line of the access list must permit the traffic to flow. The implicit deny all remains as the last line. Some people add an explicit deny all of 255.255.255.255 0.0.0.0 at the end of access lists to remind themselves of the final deny all issue.
The following output of debug ip rip was captured before the configuration to block 0.0.0.0 was added:
RouterB#debug ip rip
Oct 15 17:50:39: RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
Oct 15 17:50:39: subnet 168.71.8.0, metric 1
Oct 15 17:50:39: subnet 171.68.0.0, metric 1
Oct 15 17:50:39: default 0.0.0.0, metric 1
Oct 15 17:50:39: RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.2)
Oct 15 17:50:39: subnet 168.71.8.0, metric 1
Oct 15 17:50:39: subnet 171.68.0.0, metric 1
Oct 15 17:50:39: default 0.0.0.0, metric 1
RouterB#
The following output of debug ip rip was captured after the configuration to block 0.0.0.0 was added:
RouterB#debug ip rip
Oct 15 17:51:07: RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
Oct 15 17:50:39: subnet 168.71.8.0, metric 1
Oct 15 17:50:39: subnet 171.68.0.0, metric 1
Oct 15 17:51:07: RIP: sending update to 255.255.255.255 via Serial1 (168.71.6.2)
Oct 15 17:50:39: subnet 168.71.8.0, metric 1
Oct 15 17:50:39: subnet 171.68.0.0, metric 1
RouterB
As you can see, the access list worked. In the following output from RouterA pinging 132.10.10.1, you can see that they are now 100 percent successful:
RouterA#ping 132.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
RouterA#
In the following output from RouterC pinging 132.10.10.1, you can see that they are now 100 percent successful:
RouterC#ping 132.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/37/40 ms
RouterC#
Remember that the goal of this scenario was to create an IP network routing plan that prevented the hosts on 168.71.8.0 and 168.71.97.0 from reaching any hosts on networks that RouterB did not have explicit routes for.
The original problem was that RouterB was installing the dynamic route for 0.0.0.0 from RouterD and then advertising it to the rest of the network. To fix this problem, a static route to 0.0.0.0 pointing at null0 was configured in RouterB. This fixed the original problem but created a new problem.
The new problem was that RouterB started advertising its static route for 0.0.0.0 to the rest of the network. This caused some hosts to install this route instead of, or in conjunction with, their original route to 0.0.0.0, which was being advertised by RouterD. The routers using only RouterB's route to 0.0.0.0, therefore, lost all connectivity to the outside world. Routers that installed RouterB's route to 0.0.0.0 in conjunction with RouterD's lost 50 percent of their connectivity to the rest of the world.
Using 0.0.0.0 with IGRP
The only difference between the way IGRP uses 0.0.0.0 and the way RIP uses it is that IGRP does not advertise it, even if a redistribute static command and a default metric are configured. The solution for creating a local domain default route for IGRP is given in this scenario. The 0.0.0.0 route might be installed as a gateway of last resort by a router running IGRP, even though IGRP—unlike RIP—doesn't treat 0.0.0.0 any differently than any other route. This is because the IP functionality of the Cisco IOS itself installs the route, not IGRP.
A router that has not yet been configured with a dynamic routing protocol still must be able to handle some basic IP functions. In fact, some routers use only static routes and connected routes to maintain the IP connectivity they require. These functions are built into the Cisco IOS to ensure that they are available.
What to Do Instead of Using 0.0.0.0 with IGRP
This section illustrates a previous point about IGRP's behavior when a route to 0.0.0.0 is available. As previously mentioned, the 0.0.0.0 route is automatically installed as the local gateway of last resort for the router by the Cisco IOS. No ip default- network 0.0.0.0 command is required. Also, as previously mentioned, IGRP does not advertise 0.0.0.0 to other routers, even if redistribute static and a default metric are configured. Figure 5-18 shows the network topology used in this scenario.
In the following routing table from RouterA, you can see that the static route to null0 for 0.0.0.0 is entered as the gateway of last resort:
RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
I 168.71.8.0 [100/80188] via 168.71.9.2, 00:00:30, Serial1
I 168.71.7.0 [100/82125] via 168.71.9.2, 00:00:31, Serial1
[100/82125] via 168.71.6.2, 00:01:23, Serial0
C 168.71.6.0 is directly connected, Serial0
C 168.71.5.0 is directly connected, Ethernet0
S* 0.0.0.0 0.0.0.0 is directly connected, Null0
RouterA#
Figure 5-18. The three-router topology.
The following partial configuration from RouterA shows how this is done:
hostname RouterA
!
router igrp 109
network 168.71.0.0
!
ip route 0.0.0.0 0.0.0.0 null0
!
In the following output of the debug ip igrp transactions command from RouterA, you can see that RouterA is not advertising 0.0.0.0:
RouterA#debug ip igrp transactions
Oct 15 00:42:43: IGRP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
Oct 15 00:42:43: subnet 168.71.9.0, metric=80125
Oct 15 00:42:43: subnet 168.71.8.0, metric=80188
Oct 15 00:42:43: subnet 168.71.5.0, metric=10000001
Oct 15 00:42:43: IGRP: sending update to 255.255.255.255 via Serial1 (168.71.9.1)
Oct 15 00:42:43: subnet 168.71.6.0, metric=80125
Oct 15 00:42:43: subnet 168.71.5.0, metric=10000001
RouterA#
Remember that RIP advertised 0.0.0.0 automatically. The following partial configuration from RouterA shows that a default metric has been configured, as well as redistribute static. RouterA still does not advertise 0.0.0.0.
hostname RouterA
!
router igrp 109
redistribute static
passive-interface Ethernet0
network 168.71.0.0
default-metric 128 2000 255 1 1500
!
ip route 0.0.0.0 0.0.0.0 null0
!
In the following output of the debug ip igrp transactions command from RouterA, you can see that RouterA is still not advertising 0.0.0.0:
RouterA#debug ip igrp transactions
Oct 15 00:44:20: IGRP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
Oct 15 00:44:20: subnet 168.71.9.0, metric=80125
Oct 15 00:44:20: subnet 168.71.8.0, metric=80188
Oct 15 00:44:20: subnet 168.71.5.0, metric=10000001
Oct 15 00:44:20: IGRP: sending update to 255.255.255.255 via Serial1 (168.71.9.1)
Oct 15 00:44:20: subnet 168.71.6.0, metric=80125
Oct 15 00:44:20: subnet 168.71.5.0, metric=10000001
RouterA#
The following partial configuration from RouterA shows how to get RouterA to use 0.0.0.0 as the local default route. It also shows how to advertise a different candidate default route— 10.0.0.0—that other routers can consider as a possible gateway of last resort. The ip default network command is used to tag a route as a candidate default:
hostname RouterA
!
router igrp 109
redistribute static
network 168.71.0.0
default-metric 128 2000 255 1 1500
!
ip default-network 10.0.0.0
ip route 0.0.0.0 0.0.0.0 null0
ip route 10.0.0.0 255.0.0.0 null0
!
A router can have multiple default networks configured; however, 0.0.0.0 is the preferred route when it is in the router's routing table with an equal or better metric than any other candidate default route. Because both routes in RouterA are static, they have identical metrics.
The following routing table from RouterA shows both static routes. Note that the asterisk (*) indicates a candidate default route.
RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 10.0.0.0 is directly connected, Null0
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
I 168.71.8.0 [100/80188] via 168.71.9.2, 00:00:49, Serial1
I 168.71.7.0 [100/82125] via 168.71.6.2, 00:01:11, Serial0
[100/82125] via 168.71.9.2, 00:00:49, Serial1
C 168.71.6.0 is directly connected, Serial0
C 168.71.5.0 is directly connected, Ethernet0
S* 0.0.0.0 0.0.0.0 is directly connected, Null0
RouterA#
The following routing table from RouterC shows that RouterC has received RouterA's advertisement for 10.0.0.0 and installed it as a gateway of last resort:
RouterC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 168.71.9.1 to network 10.0.0.0
I* 10.0.0.0 [100/82125] via 168.71.9.1, 00:00:31, Serial1
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
C 168.71.8.0 is directly connected, TokenRing0
C 168.71.7.0 is directly connected, Serial0
I 168.71.6.0 [100/82125] via 168.71.9.1, 00:00:32, Serial1
[100/82125] via 168.71.7.2, 00:00:27, Serial0
I 168.71.5.0 [100/10002001] via 168.71.9.1, 00:00:32, Serial1
RouterC#
The 0.0.0.0 route is not as useful for IGRP as it is for RIP. However, it is safer to use with IGRP for the same reasons that it is not as useful.
The simplest way to achieve the same effect for IGRP is to create and redistribute a static route for a fictitious network and flag it as the IP default network. You don't want to use a real network because you may not be able to control where the route for the real network is learned from. It may not always be learned via the path on which you want your traffic to travel.
If you have multiple routers with exit points to other networks that you want to use as redundant links to the outside world, you can configure the same redistributed static route in each of them. If you want one to always be preferred over the others, give it a much better metric. Make certain that, for any router in the network, the metric for the preferred route is better than the metric it receives from another router's candidate default.