Gateway of Last Resort
In Figure 5-1, if RouterC did not have an explicit route to subnet 168.72.6.0 or the major network 168.72.0.0, it would need a gateway of last resort to send packets to this subnet.
Figure 5-1. The link between RouterA and RouterB has a different major network than all other networks.
In the following routing table from RouterC, you can see that RouterC has installed a gateway of last resort network 10.0.0.0 with a next hop of 168.71.9.1. You can also see that there is no route to 168.72.6.0 or 168.72.0.0.
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:01:06, 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.5.0 [100/10002001] via 168.71.9.1, 00:01:07, Serial1
RouterC#
The gateway of last resort is being advertised by RouterA as a candidate default route. It is up to the router receiving a candidate default route to determine whether it should install it as the gateway of last resort. In this scenario, having RouterA advertise 10.0.0.0 as the candidate default route also caused RouterB to send a route to RouterC for 10.0.0.0 that RouterB flagged as a candidate default route.
Figure 5-1 shows that as far as RouterC is concerned, the link between RouterC and RouterA is the best path for reaching 10.0.0.0 because RouterB increases the metric for 10.0.0.0 when advertising it to RouterC. RouterA's metric is smaller than RouterB's. Interestingly enough, as far as reaching 168.71.6.0 is concerned, both of RouterC's physical paths—via RouterA or RouterB—could be of equal cost if all links in the network were the same delay and bandwidth. However, because this scenario relies on using the gateway of last resort to 10.0.0.0 to reach 168.71.6.0, only one path is used even if they are equal cost in theory.
The following configuration from RouterA shows how to enable this function:
RouterA
!
interface ethernet0
ip address 168.71.5.1 255.255.255.0
ip address 171.68.207.164 255.255.128 secondary
!
interface serial0
ip address 168.72.6.1 255.255.255.0
bandwidth 128
!
interface serial1
ip address 168.71.9.1 255.255.255.0
bandwidth 128
!
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 10.0.0.0 255.0.0.0 171.68.207.129
!
The following is a step-by-step explanation of enabling a router to advertise a gateway of last resort. The steps do not have to be performed in this exact order, but all steps must be completed.
Enter the appropriate ip default-network command. In this case, network 10.0.0.0 is used.
Interestingly, this network does not have to actually exist anywhere in the network. Because IP packets are forwarded on a hop-by-hop basis, it is necessary only to convince a router to send a packet to the next hop to ensure that the packet is making forward progress to its destination. What this command is doing is telling other routers that somewhere there is a router advertising 10.0.0.0 and that the router knows how to reach every other network in the world. Therefore, a packet forwarded in the general direction of this router is on its way to reaching its ultimate destination. This concept was introduced in Chapter 3, "Discontiguous Networks, Summarization, and Subnet 0," in the section on using summarization as a tool.
Configure a next hop address to reach the default network. In this case, a host in the secondary address space on Ethernet0 (171.68.207.129) is used. This is a static (manually configured) route.
Configure a default metric. If you fail to do so, the router uses the unreachable metric (infinity) when advertising this route, which prevents the route from being accepted by other routers.
The default metric command takes the following form: bandwidth, delay, reliability, load, and MTU. Review the section on metrics in Chapter 2, "Routing Metrics and Distances," for more information. Remember that by default only bandwidth and delay are used by IGRP. The delay in a route is cumulative, and the minimum bandwidth is used for all links in the path.
Gateway of Last Resort for a Non-Local Domain
The following scenario shows that RouterC uses the gateway of last resort to reach a subnet it has no explicit knowledge of. Remember that a non-local domain is a major network address space that the router has no physical connection to. Refer to Figure 5-1 for the network topology used in this scenario.
In the following output of the show ip route command from RouterC, you can see that RouterC does not have a subnet route to 168.72.6.0 or a summarized route to the major net 168.72.0.0:
RouterC#show ip route 168.72.6.0
% Network not in table
RouterC#show ip route 168.72.0.0
% Network not in table
RouterC#
In the following output from RouterC, you can see that RouterC can ping 168.72.6.1:
RouterC#ping 168.72.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.72.6.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms
RouterC#
Gateway of Last Resort Fails for a Local Domain
In the scenario shown in Figure 5-2, the link between RouterA and RouterB is now part of the 168.71.0.0 domain that all other networks are using. However, the mask has been changed to 255.255.255.252. This was done to prevent RouterA and RouterB from advertising the 168.71.6.0 subnet. See Chapter 4, "Using IP Unnumbered and VLSM," for more information on VLSM.
Figure 5-2. The link between RouterA and RouterB has the same major network but a different mask.
In the following routing table from RouterC, you can see that RouterC does not have a route to 168.71.6.0 or a summarized route to 168.71.0.0:
RouterC#show ip route 168.71.6.0
% Subnet not in table
RouterC#show ip route 168.71.0.0
Routing entry for 168.71.0.0 255.255.255.0, 4 known subnets
Attached (3 connections)
Redistributing via igrp 109
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.5.0 [100/10002001] via 168.71.9.1, 00:00:36, Serial1
Note
An access list has been applied to the end of this debug command, which limits the output of the command to packets that match the access list. Adding the access list affects only the actual debug messages. It is a good idea to add an access list whenever a router with lots of IP traffic is being used to debug a problem related to the forwarding of IP packets. Remember that debug commands work only for IP packets that are being process switched. Ping packets generated by a router are always process switched, so adding the access list to the debug command will always work in situations similar to this one.
To determine whether access list debugging is available for a certain debug command, type a question mark (?) at the end of the command. If access list debugging is available, the prompt indicates that you can enter an access list number.
In the following output of the debug ip packet command from RouterC, you can see that RouterC doesn't have a route to use for packets destined to 168.71.6.1:
RouterC#debug ip packet 103
IP packet debugging is on for access list 103
RouterC#ping 168.71.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.6.1, timeout is 2 seconds:
Oct 8 21:30:32: IP: s=168.71.7.1 (local), d=168.71.6.1, len 100, unroutable.
Oct 8 21:30:34: IP: s=168.71.7.1 (local), d=168.71.6.1, len 100, unroutable.
Oct 8 21:30:36: IP: s=168.71.7.1 (local), d=168.71.6.1, len 100, unroutable.
Oct 8 21:30:38: IP: s=168.71.7.1 (local), d=168.71.6.1, len 100, unroutable.
Oct 8 21:30:40: IP: s=168.71.7.1 (local), d=168.71.6.1, len 100, unroutable.
Success rate is 0 percent (0/5)
RouterC#
The following is the content of access list 103:
RouterC#show access-lists 103
Extended IP access list 103
permit ip any 168.71.6.0 0.0.0.255 (5 matches)
RouterC#
In the following routing table from RouterC, you can see that RouterC has a gateway of last resort installed. It was ignored because routers do not use a gateway of last resort for addresses that are part of its local domain—a major network it has connections to.
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:29, Serial1
168.71.0.0 255.255.255.0 is subnetted, 4 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.5.0 [100/10002001] via 168.71.9.1, 00:00:29, Serial1
RouterC#
The solution to this problem is to enter a static route for the summarized major net that points to the gateway of last resort. In this case, the fact that 10.0.0.0 is tagged as a gateway of last resort is not relevant. This scenario would still work if RouterA advertised 10.0.0.0 without also flagging it as a candidate default route (capable of being used as a gateway of last resort). The following configuration from RouterC shows how to add the static route that will point to the gateway of last resort:
RouterC
!
interface tokenring0
ip address 168.71.8.1 255.255.255.0
!
interface serial0
ip address 168.71.7.1 255.255.255.0
bandwidth 64
!
interface serial1
ip address 168.71.9.2 255.255.255.0
bandwidth 128
!
router igrp 109
network 168.71.0.0
!
ip route 168.71.0.0 255.255.0.0 10.0.0.0
!
The following routing table from RouterC shows that RouterC has installed the static route for 168.71.0.0 via 10.0.0.0:
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:05, Serial1
168.71.0.0 is variably subnetted, 5 subnets, 2 masks
C 168.71.9.0 255.255.255.0 is directly connected, Serial1
C 168.71.8.0 255.255.255.0 is directly connected, TokenRing0
C 168.71.7.0 255.255.255.0 is directly connected, Serial0
I 168.71.5.0 255.255.255.0
[100/10002001] via 168.71.9.1, 00:00:05, Serial1
S 168.71.0.0 255.255.0.0 [1/0] via 10.0.0.0
RouterC#
The following output from the show ip route command on RouterC shows that RouterC now has a route it can use to the subnet 168.71.6.0. When queried about its knowledge of a route, it does a longest match lookup in its routing table. In this case, the longest match is to the major net itself.
RouterC#show ip route 168.71.6.1
Routing entry for 168.71.0.0 255.255.0.0
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.0
Route metric is 0, traffic share count is 1
RouterC#
Note
To ensure that you receive the output for the full destination subnet, use the full IP address of a host on the destination subnet when using the show ip route command. You might find that a subnet exists in the routing table that you did not know existed. It is not uncommon to have a routing table with thousands of entries in it. It can be easy to miss a subnet when doing a visual scan. Using the show ip route xxx.xxx.xxx.xxx command to scan the table is much easier and less prone to failure.
In the following output from RouterC, you can see that RouterC can now ping 168.71.6.1:
RouterC#ping 168.71.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.6.1,
timeout
is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
RouterC#
Gateway of Last Resort Still Works When Links Fail
In this scenario (shown in Figure 5-3 and the output that follows), the link between RouterA and RouterC has failed. RouterC has converged on the path via RouterB for its route to the gateway of last resort network (10.0.0.0). 10.0.0.0 is now known via the next hop address of 168.71.7.2 (RouterB's serial 1). Because RouterC's local domain default route (168.71.0.0) is a static route to network 10.0.0.0, it works on the new path for 10.0.0.0 via RouterB as well.
Figure 5-3. The link between RouterA and RouterC has gone down.
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.7.2 to network 10.0.0.0
I* 10.0.0.0 [100/84125] via 168.71.7.2, 00:01:07, Serial0
I 171.68.0.0 [100/10004001] via 168.71.7.2, 00:01:07, Serial0
168.71.0.0 is variably subnetted, 3 subnets, 2 masks
C 168.71.8.0 255.255.255.0 is directly connected, TokenRing0
C 168.71.7.0 255.255.255.0 is directly connected, Serial0
S 168.71.0.0 255.255.0.0 [1/0] via 10.0.0.0
RouterC#
Using IP Classless
A simpler method for forcing a router to use a gateway of last resort for remote subnets that are part of the local domain is to configure the ip classless command. This command causes the router to ignore all aspects of address classes when making routing decisions. The following excerpt from RouterC's configuration shows how ip classless has been configured.
!
ip classless
!
Note
ip classless is a global command. It affects all routing protocols in the router. It should be used with caution. A thorough discussion of all of the implications of using this command is beyond the scope of this book. Please refer to your Cisco IOS documentation for more information.
The ip classless command will be on by default in Cisco IOS Version 11.3. See bug number CSCdj21662 on CCO (http://www.cisco.com) for more information.
In the following output of the show ip route command on RouterC, you can see that, once again, RouterC has no knowledge of how it should route packets for 168.71.6.0:
RouterC#show ip route 168.71.6.0
% Subnet not in table
RouterC#
In the following output from RouterC pinging 168.71.6.1, you can see that the ping is successful:
RouterC#ping 168.71.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.6.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
RouterC#
As you can see, RouterC can ping a local domain subnet that it has no knowledge of even though the local domain default route pointing to 10.0.0.0 (ip route 168.71.0.0 255.255.0.0 10.0.0.0) has not been configured. Remember that this was a required configuration parameter before the ip classless command was configured.
In Review
This section provides a quick review of the material just presented. The following section presents a scenario in which an improper use of static routes and gateways of last resort can cause connectivity failures. Figure 5-4 shows the network diagram that will be used for this scenario.
Figure 5-4. A more complicated network configuration is required to make this scenario work properly.
Two types of IP network addresses are under consideration in this section. They are as follows:
Non-local domain addresses (a major network address that the router does not have a physical connection to)—In Figure 5-4, RouterB does not have an explicit route to 168.72.5.0. However, it does have a gateway of last resort of 10.0.0.0. This gateway of last resort is created with a static route to 10.0.0.0 that points at 168.71.6.1 and configures the ip de fault-network 10.0.0.0 command. This route is sufficient for RouterB to forward packets to 167.72.5.0 because RouterB has no local context for 168.72.0.0 (it is not a local domain).
Local domain addresses(a major network address that the router does have a physical connection to)— RouterA must have either an explicit route back to 168.71.8.0 or a static route pointing to 168.71.8.0 with a next hop of 168.71.6.3. A gateway of last resort will not allow RouterA to reach 168.71.8.0 because RouterA is connected to the major net 168.71.0.0. This connection makes 168.71.8.0 part of RouterA's local domain. Routers expect to have explicit routes for all subnets in their local domains. It is possible to get around this by installing a static route to the major network alone. However, this can lead to problems when configured improperly.