Default Routes and the ip classless Command

When a router needs to route a packet and there is no route matching that packet's destination in the routing table, the router discards the packet. Default routing lets the router forward the packet to some default next-hop router. Default routing is that simple! However, two configuration options for default routing make it a little tricky. Also one other option changes the algorithm of how the router decides whether there is a routing table match, which affects when the default route is used.

First, default routes work best when there is one path to a part of the network. In Figure 6-40, R1, R2, and R3 are connected to the rest of this network only through R1's Token Ring interface. All three routers can forward packets to the rest of the network, as long as the packets get to R1, which forwards them to Dist1.

Figure 6-40 Example Network Using a Default Route

168.13.200.1

Figure 6-40 Example Network Using a Default Route

168.13.200.1

By coding a default route on R1 that points to router Distl in Figure 6-40 and having R1 advertise the default to R2 and R3, default routing can be accomplished. Examples 6-15 and 6-16, along with Figure 6-40, show an example of a default route on Rl.

Example 6-15 R1 Static Default Route Configuration and Routing Table

R1#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 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 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, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 168.13.1.101 to network 0.0.0.0

168.13.0.0/24 is subnetted, 4 subnets

C 168.13.1.0 is directly connected, TokenRing0

R 168.13.3.0 [120/1] via 168.13.100.3, 00:00:05, Serial0.1

R 168.13.2.0 [120/1] via 168.13.100.2, 00:00:21, Serial0.1

C 168.13.100.0 is directly connected, Serial0.1

Example 6-16 R3—Nuances with Successful Use of Static Route on R1 R3#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 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 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, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 168.13.100.1 to network 0.0.0.0

168.13.0.0/24 is subnetted, 4 subnets R 168.13.1.0 [120/1] via 168.13.100.1, 00:00:13, Serial0.1

C 168.13.3.0 is directly connected, Ethernet0

R 168.13.2.0 [120/1] via 168.13.100.2, 00:00:06, Serial0.1

C 168.13.100.0 is directly connected, Serial0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 84/89/114 ms R3#

R3#ping 168.13.200.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 168.13.200.1, timeout is 2 seconds:

Success rate is 0 percent (0/5) R3#

R3#conf t

Enter configuration commands, one per line. End with CNTL/Z. R3(config)#ip classless R3(config)#'Z R3#ping 168.13.200.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 168.13.200.1, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 80/88/112 ms R3#

The default route is defined with a static ip route command on R1, with destination 0.0.0.0, mask 0.0.0.0. This route matches all destinations, by convention. R1 advertises to R2 and R3, as seen in the output of the show ip route command on R3 in Example 6-16. So the ping 10.1.1.1 command on R3 works, just like it should. However, the ping 168.13.200.1 command does not work—why?

The key to knowing why one ping worked and one did not is based on what Cisco IOS Software thinks is a "match" of the routing table. If the router first matches the Class A, B, or C network number that a destination resides in and then looks for the specific subnet, the router is considered to be classful. If the router simply looks for the best subnet match, ignoring Class A, B, and C rules, the router is classless. What you need in this case is a router with no class! Seriously, here's R3's logic when the ping failed:

1 I need to send a packet to 168.13.200.1.

2 I match Class B network 168.13.0.0, so there is a match.

3 I do not match a specific subnet that contains 168.13.200.1.

4 I use the default route only if there is no match, and there was a match, so I discard the packet.

If you make R3 act in a classless manner, the ping will work, as in the second ping 168.13.200.1 command in Example 6-16. The logic works something like this:

1 I need to send a packet to 168.13.200.1.

2 I do not match a specific subnet that contains 168.13.200.1.

3 I use the default route only if there is no match, and there was no match, so I use the default route.

The no ip classless command makes the router behave as a classful router. The ip classless command makes it act as a classless router, which would be preferred in this case. It seems like classless would always be better, but it is not. What if the networks on the other side of Dist1 were on the Internet and 168.13.0.0 was your registered Class B network? Well, there should not be any part of 168.13.0.0 to the right of Dist1, so it would be pointless to send packets for unknown subnets of 168.13.0.0 to Dist1 because they will be discarded at some point anyway. There are uses for both modes—just be aware of how each works.

The gateway of last resort, highlighted in the show ip route command output, sounds like a pretty desperate feature. There are worse things than having to discard a packet in a router, and "gateway of last resort" simply references the current default route. It is possible that several default routes have been configured and then distributed with a routing protocol; the gateway of last resort is the currently used default on a particular router. Be careful—multiple defaults can cause a routing loop.

Another style of configuration for the default route uses the ip default-network command. This command is used most typically when you want to reach other Class A, B, or C networks by default, but all the subnets of your own network are expected to be in your own routing tables. For example, imagine that the cloud next to Dist1 in Figure 6-40 has subnets of network 10.0.0.0 in it as well as other networks. (Dist1 could be an ISP router.) The network in Figure 6-40 is still in use, but instead of using the ip route 0.0.0.0 0.0.0.0 168.13.1.101 command, the ip default-network 10.0.0.0 command is used on R1. R1 uses its route to network 10.0.0.0 as its default and advertises this route as a default route to other routers. Examples 6-17 and 6-18 show several details on R1 and R3.

Example 6-17 R1's Use of the ip default-network Command

R1#configure terminal

R1(config)#ip default-network 10.0.0.0

R1(config)#exit R1#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 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 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, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 168.13.1.101 to network 10.0.0.0

168.13.0.0/24 is subnetted, 5 subnets

R 168.13.200.0 [120/1] via 168.13.1.101, 00:00:12, TokenRing0

C 168.13.1.0 is directly connected, TokenRing0

R 168.13.3.0 [120/1] via 168.13.100.3, 00:00:00, Serial0.1

R 168.13.2.0 [120/1] via 168.13.100.2, 00:00:00, Serial0.1

C 168.13.100.0 is directly connected, Serial0.1

R* 10.0.0.0/8 [120/1] via 168.13.1.101, 00:00:12, TokenRing0 R1#

Example 6-18 R3 Routing Table and trace Command Samples

R3#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 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 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, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 168.13.100.1 to network 0.0.0.0

168.13.0.0/24 is subnetted, 5 subnets

R 168.13.200.0 [120/2] via 168.13.100.1, 00:00:26, Serial0.1

R 168.13.1.0 [120/1] via 168.13.100.1, 00:00:26, Serial0.1

C 168.13.3.0 is directly connected, Ethernet0

R 168.13.2.0 [120/1] via 168.13.100.2, 00:00:18, Serial0.1

C 168.13.100.0 is directly connected, Serial0.1

R 10.0.0.0/8 [120/2] via 168.13.100.1, 00:00:26, Serial0.1

R* 0.0.0.0/0 [120/2] via 168.13.100.1, 00:00:26, Serial0.1

R3#trace 168.13.222.2

Type escape sequence to abort. Tracing the route to 168.13.222.2

1 168.13.100.1 68 msec 56 msec 52 msec

2 168.13.1.101 52 msec 56 msec 52 msec R3#trace 10.1.1.1

Example 6-18 R3 Routing Table and trace Command Samples (Continued)

Type escape sequence to abort. Tracing the route to 10.1.1.1

1 168.13.100.1 68 msec 56 msec 52 msec

2 168.13.1.101 48 msec 56 msec 52 msec R3#

Both R1 and R3 have default routes, but they are shown differently in their respective routing tables. R1 shows a route to network 10.0.0.0 with an *, meaning that it is a candidate to be the default route. In R3, 0.0.0.0 shows up in the routing table as the candidate default route. The reason that R3 shows this information differently is that RIP advertises default routes using network number 0.0.0.0. If IGRP or EIGRP were in use, there would be no route to 0.0.0.0 on R3, and network 10.0.0.0 would be the candidate default route. That's because IGRP and EIGRP would flag 10.0.0.0 as a candidate default route in their routing updates rather than advertise the special case of 0.0.0.0.

The default route on R3 is used for destinations in network 168.13.0.0, 10.0.0.0, or any other network because ip classless is still configured. The trace commands in Example 6-18, which show destinations in two different networks, both succeed. The trace commands each show that the first router in the route was R1, then comes Dist1, and then the command finished. If n other routers had been present in the network of Figure 6-40, these routers could have shown up in the trace output as well. (In each case, the destination address was the address of some loopback interface in Dist1, so there were no routers beyond Dist1.) ip classless still was configured; it is recommended that you configure ip classless if using any form of default routes.

Was this article helpful?

0 0

Post a comment