In this chapter, you see how IOS implements default IP routing and the options you have for transporting default routes in EIGRP. The chapter concludes with a case study illustrating how the extensive use of default routes can introduce query boundaries in a network with no hierarchical addressing scheme.
Chapter 6, "EIGRP Route Summarization," and Chapter 7, "Route Filters," gave you powerful EIGRP scalability tools that have a single common drawback; they can usually be applied only in networks with a good, carefully thought-out IP addressing scheme. In networks that historically have had no hierarchical IP address structure, a different approach to network layering can be used:
Central (core) routers know every possible route in the network.
Remote (access) routes know only the routes in their neighborhood and a route toward the core of the network (default route).
The same layering approach can be applied recursively resulting in a multilayer hierarchy where the following rules apply:
Routers in layer 1 (access layer) know only their local routes and the default route toward the next layer.
Routers in layer N know all routes from layer-N-1 routers and the layer-N routers connected to them as well as the default route toward layer N+1.
When this approach is put to use in an enterprise network connected to the Internet, the structure looks similar to the one in Figure 8-1.
As you can see in Figure 8-1, the multilayer hierarchical structure is also used within the Internet and extends all the way down from the core Internet routers that carry all the known routes in the Internet to the enterprise access router, which carries only its own subnet routes and a default route toward the enterprise distribution layer.
Every modern IP router follows the classless IP routing model that can be described using a simple set of rules:
For every packet, find the longest matching prefix for the destination address in the routing table.
Drop packets where you cannot find any matching prefixes.
Using this model, it's easy to understand why the route 0.0.0.0/0 is also called a default route:
Whenever another route matching the destination address in the routed IP packet exists in the routing table, the other route is used because no route has a shorter prefix than the default route.
If there is no other matching route, the default route is always used because it matches every destination IP address.
Note
Based on these findings, you'd assume that IP default routing is a straightforward mechanism—and you'd be wrong. To complicate matters, IOS contains several features that interfere with this model: classful versus classless routing, default candidates, and the gateway of lastresort.
IOS has routed IP packets following the longest prefix match rule since IOS version 9.1. The difference between truly classless and classful routing in IOS lies in the way supernet routes (including the default route) are used for subnets of known networks:
In the classless mode, the IOS strictly follows the classless routing model outlined in "IP Default Routing and IOS Specifics" in this chapter.
In the classful mode, IOS does not use the supernet routes for unknown subnets of known networks; whenever a single subnet of a major IP network appears in the IP routing table, the supernet routes (including the default route) are not used for other subnets of the same network.
You could also simulate the classful behavior of IOS by assuming that IOS installs a hidden summary route pointing to Null 0 for every major network as soon as the first subnet of that network appears in the routing table. The hidden summary route prevents the supernet routes from being used because it is always the best matching prefix for all unknown subnets in that network.
The classful versus classless behavior is configured using the ip classless command as shown in Table 8-1.
Table 8-1. The ip classless Command
|
Command |
Results |
|---|---|
|
ip classless |
Configures true classless routing. Default in IOS 11.3 and above. |
|
no ip classless |
Partial classless routing is enabled. Supernet routes are not used for unknown subnets of networks where some subnets are known in the routing table. Default for all IOS versions up to 11.2. |
Further deviations from the standard IP classless routing model are the default candidate routes and associated gateways of last resort. Several routes in the IP routing table can be marked as the default candidates, meaning that they mark the exit from the local routing environment toward another layer that has more routing information. The default candidates are not used as default routes themselves; IOS evaluates all default candidates and chooses the one with minimum administrative distance and minimum routing metric as the best default candidate. The next hop router of the best default candidate becomes the gateway of last resort.
Note
The default route is considered to be just another default candidate in IOS. Whenever a better default candidate is found in the routing table, the default route is ignored (deviating from the classless routing model) and another gateway of last resort is used to forward packets to unknown destinations, as shown in Example 8-1.
Example 8-1. Example 8-1 Sample show ip route Printout
DR-1#show ip route Gateway of last resort is 10.100.4.100 to network 10.0.0.0 * 10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks D 10.1.1.0/24 [90/40537600] via 10.1.100.1, Serial0 D* 10.0.0.0/8 [90/11535872] via 10.100.4.100, Serial0.2 D 10.1.0.0/16 is a summary, Null0 C 10.1.0.0/24 is directly connected, Ethernet0 C 10.100.4.0/24 is directly connected, Serial0.2 C 10.100.1.0/24 is directly connected, Serial0.1 C 10.1.100.0/24 is directly connected, Serial0 D 10.210.0.0/16 [90/41024000] via 10.1.100.1, Serial0 D*EX 0.0.0.0/0 [170/166656000] via 10.1.100.1, Serial0
The default candidates can be configured locally on the router using the ip default-network command or learned via a routing protocol that supports default candidates—currently, the only two routing protocols that support them are IGRP and EIGRP.
The ip default-network command works in several different ways, as documented in Table 8-2.
Table 8-2. The ip default-network Command
|
Command |
Results |
|---|---|
|
ip default-network <major-network> for connected networks |
Marks the network as default candidate in the IP routing table. Starts redistributing the network in all IGRP and EIGRP processes. Marks the network in the EIGRP topology database with default candidate flag. |
|
ip default-network <major-network> for nonconnected networks |
Marks the network as default candidate in the IP routing table. If the network is already in EIGRP topology database, marks the network with default candidate flag. Takes no further actions to insert the network into EIGRP topology database. |
|
ip default-network <subnet> |
Equivalent toip route <major-network> <mask> <subnet>. Inserts the summary route for the major network into which the subnet belongs in the routing table. |
The routes that are default candidates are marked with an asterisk in the main routing table (as seen in Example 8-2). They also carry an exterior flag that can be observed in the EIGRP topology database by using the show ip eigrp topology <network> <mask> command (see Example 8-3).
Note
The asterisk in the routing table printout has a double meaning because it is also used for marking the currently used process switched path when a router has multiple equal-cost paths to the same destination.
Example 8-2. Listing 8-2 IP Routing Table with Several Default Candidates
RO-11#show ip route
Codes: C - connected, S – static, D - EIGRP,
EX - EIGRP external, * - candidate default
Gateway of last resort is 10.1.100.100 to network 10.0.0.0
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
D* 10.0.0.0/8 [90/42048000] via 10.1.100.100, 00:00:58, Serial0.1
C 10.1.1.0/24 is directly connected, Ethernet0
D 10.1.0.0/16 [90/40537600] via 10.1.100.100, 00:07:56, Serial0.1
D 10.100.4.0/24 [90/41536000] via 10.1.100.100, 00:07:56, Serial0.1
D 10.100.1.0/24 [90/41024000] via 10.1.100.100, 00:07:56, Serial0.1
C 10.1.100.0/24 is directly connected, Serial0.1
C 10.210.0.0/16 is directly connected, Serial2.22
D*EX 0.0.0.0/0 [170/166144000] via 10.210.0.2, 00:00:58, Serial2.22
Example 8-3. Listing 8-3 EIGRP Topology Database Entry with Default Candidate Marker Set
RO-11#show ip eigrp topology 10.0.0.0
IP-EIGRP topology entry for 10.0.0.0/8
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 42048000
Routing Descriptor Blocks:
10.1.100.100 (Serial0.1), from 10.1.100.100, Send flag is 0x0
Composite metric is (42048000/11535872), Route is Internal
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 80000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Exterior flag is set
EIGRP supports the IP default route (0.0.0.0/0) as well as candidate default routes (default candidates). There are, however, several differences between EIGRP and other routing protocols, such as RIP, OSPF, or IS-IS:
EIGRP is the only classless routing protocol that supports default candidates.
Although EIGRP can carry the default route (0.0.0.0/0) as a regular IP route, it never generates it in the topology database. Contrary to that, RIP always generates the default route as soon as the router itself has gateway of last resort set. OSPF generates the default route in a stub or NSSA area and IS-IS generates the default route pointing toward the nearest level-2 router on any level-1 router.
To insert the default route into the EIGRP topology database, you have to manually configure redistribution of the default route. Contrary to that, you can configure the default route announcement in OSPF routing process using the default-information originate command.
Whenever the default route is redistributed into the EIGRP topology database, the default candidate marker is set automatically on the entry in the topology database.
EIGRP automatically redistributes connected network (or subnets) marked as ip default-network into the EIGRP process. No other classless routing protocol performs redistribution behind the scenes; you always have to configure it.
EIGRP enables you to further fine-tune default information. You can selectively erase the default candidate flag from incoming or outgoing routing updates using the commands from Table 8-3.
Table 8-3. Default Information Propagation Control in EIGRP
|
EIGRP Router Configuration Command |
Result |
|---|---|
|
default-information in <ACL> |
Erases the default candidate marker from all received routes not matched by the IP access list <ACL> |
|
default-information out <ACL> |
Erases the default candidate marker from all routes not matched by <ACL> when they are advertised to EIGRP neighbors |
|
no default-information in |
Does not accept any default candidate markers |
|
no default-information out |
Does not mark any routes as default candidates in outgoing updates. The router itself still uses the default candidate markers on the routes in the EIGRP topology database to select its own gateway of last resort. |
The variety of EIGRP tools you can use to implement IP default routing in the EIGRP environment makes your life easier, but also more interesting because you have more options from which to choose. In this section, you'll see a few simple designs and their alternate implementations using a variety of EIGRP tools. A more complex design with default route hierarchy is detailed in the case study later in this chapter.
In the first example, we'll focus on a simple, yet very common scenario: An enterprise network is connected to the Internet in a single point, similar to the setup shown in Figure 8-2.
Warning
Your connection to the Internet should always be implemented in a secure way. The least you should do is use the firewall feature set on the router connecting your enterprise network to the Internet. Better yet, you should deploy a full-scale firewall.
There are two possible ways of configuring the GW router. The first is to declare the external subnet connecting the GW router and the Internet service provider as the default network (see the configuration in Example 8-4). The external subnet is automatically redistributed into EIGRP with the vector metric of the interface connecting the GW router to the ISP. It is also flagged as the default candidate, making all the other routers aware that they should use the next-hop router toward GW as the gateway of last resort.
Example 8-4. Example 8-4 Default Routing toward the Internet Implemented with the default-network Command
hostname GW ! interface serial 0 ip address 192.77.3.6 255.255.255.252 bandwidth 64 ! interface ethernet 0 ip address 131.7.13.5 255.255.255.0 ! router eigrp 42 network 131.7.0.0 ! ip default-network 192.77.3.0
The second method is to configure the static default route pointing to the external subnet or to the physical interface itself and manually redistribute the default route into EIGRP (see the configuration in Example 8-5). The redistributed route would normally inherit interface parameters, but you could also overwrite the interface metrics by specifying metrics directly in the redistribute command.
Example 8-5. Example 8-5 Default Routing toward the Internet Implemented with the Static Default Route
hostname GW ! interface serial 0 ip address 192.77.3.6 255.255.255.252 ! interface ethernet 0 ip address 131.7.13.5 255.255.255.0 ! router eigrp 42 network 131.7.0.0 redistribute static metric 64 20000 255 1 1500 ! ip route 0.0.0.0 0.0.0.0 192.77.3.5
Warning
Static routes pointing to an interface were considered to be static in old IOS versions; then the IOS was changed to consider them connected (recent IOS versions up to and including IOS 11.2). The latest IOS versions again treat the static routes pointing to an interface as static (IOS 11.3 and 12.0). Configurations relying on static routes pointing toward physical interfaces could break when you upgrade your router from IOS 11.2 (or any prior version) to 11.3 or 12.0.
Both alternatives are almost identical, with a few minor differences:
The EIGRP vector metric of the default route can be better controlled in the second setup because you can control the redistribution of the default route into the EIGRP process. (In the first setup, the redistribution is automatic and you cannot configure or tune it.)
The second setup works even when the IP subnet on the link between the GW router and the ISP belongs to the customer's address space.
A multihomed customer connection to the Internet does not represent any additional burden on the EIGRP side; two gateway routers (see Figure 8-3) are configured in exactly the same way as the gateway router in "Enterprise Network with a Single Connection to the Internet" earlier in this chapter.
It's important, however, to fine-tune the EIGRP metrics of the default candidates. If they are implemented correctly, all the routers in the network choose the better exit point. The exit point might always be the same if the links to the Internet have different link speeds (for example, primary and backup links to the Internet). If the links to the Internet have approximately the same speed, routers closer to one of the interconnection points use that interconnection point resulting in proper load sharing between the interconnection points.
For more information on this case study, please visit http://www.ciscopress.com/eigrp.
GreatCoals mining corporation (see also "Case Study—Connectivity Loss Following Private IP Address Deployment" in Chapter 6 for more information on the company) has evolved into a multinational corporation with operations in the United States and several foreign countries with sales offices throughout the world. Its network grew as the company expanded, but no real network design was ever put in place. It's already introduced some hierarchy in the network, mainly to reduce WAN costs. Typical parts of the current network are schematically represented in Figure 8-4.
Although GreatCoals never did a real network design, it nonetheless followed a set of loose rules:
The core of the network is implemented with a 7576 fully redundant router. Corporate-wide servers connect directly the LAN interfaces of this router, and all international links terminate on it. All links toward the regional concentration sites also terminate on the same router.
Sales offices in countries where GreatCoals has only a sales presence link to the central 7576 with low-speed Frame Relay connections, with the typical Committed Information Rate (CIR) being 32 kbps.
Central sites in countries where GreatCoals has mining operations link to the central 7576 with high-speed Frame Relay or ATM connections, the typical CIR being over 1 Mbps. All other sites in the country link to the in-country central site, and the international traffic is concentrated there.
Regional concentration sites in the U.S. serve the same purpose as the foreign in-country central sites. All minor sites in the U.S. connect to the regional concentration sites.
Major U.S. sites connect directly to the core router with high-speed ATM PVCs.
GreatCoals never had a structured IP addressing scheme. Initially, the company got a class-B address (131.7.0.0/16) that was subnetted using 8-bit subnet masks. Additional public class-C addresses were introduced when the company ran out of address space, and finally, the private IP addresses were used for WAN links and loopback addresses on the routers. In short, the routing tables were a total mess. They used no scalability tools; so all the routers had to carry all the routes of the whole GreatCoals global network. No wonder they started to experience Stuck-in-Active events.
When the GreatCoals' engineers tried to improve the scalability of their network, they faced a huge obstacle. Because they had no hierarchical IP addressing scheme, they couldn't use any traditional scalability tools, such as route summarization. The only tool they could use was IP default routing in combination with route filters. They proposed the following design:
The core router (7576) would have a static default route pointing toward the Internet firewall. This default route would be redistributed into EIGRP.
The core router would announce only the default route to all the other routers. Route filters would be used to implement the necessary filtering mechanism.
All the concentration routers would announce only the default route to the remote offices. A floating static route would be installed in the concentration routers to guarantee default route presence even if the WAN link to the core router failed.
All routers in the network would announce all their routes to their upstream neighbors.
The relevant portions of the core router configuration are shown in Example 8-6. Relevant portions of concentration router configuration are shown in Example 8-7.
Example 8-6. Example 8-6 GreatCoals Network—Core Router Configuration
hostname Core-7576 ! router eigrp 131 network 131.7.0.0 network 10.0.0.0 redistribute static metric 64 20000 255 1 1500 distribute-list DefaultOnly out ! ! Default route toward the firewall ip route 0.0.0.0 0.0.0.0 131.7.10.2 ! ! Backup default route in case the firewall subnet is gone ip route 0.0.0.0 0.0.0.0 Null0 250 ! ip access-list standard DefaultOnly permit 0.0.0.0
Example 8-7. Example 8-7 GreatCoals Network—Concentration Router Configuration
hostname Houston ! router eigrp 131 network 131.7.0.0 network 10.0.0.0 redistribute static metric 64 20000 255 1 1500 ! ! distribute-list applies only to FR links toward remote offices ! distribute-list DefaultOnly out Serial 0 ! ! Backup default route in case the core default route is gone ip route 0.0.0.0 0.0.0.0 Null0 250 ! ip access-list standard DefaultOnly permit 0.0.0.0
In the end, GreatCoals implemented additional scalability measures proposed by an external consultant. (You could do it yourself after completing Exercises 8-2 and 8-3.) The network worked optimally, until the users got the upper hand again. The international sales offices decided to install their own Internet connections to accelerate the information exchange with local business partners and claimed that they should not receive a default route from the core router because their default route pointed to the Internet.
Default routes by themselves are not scalability tools; deployment of default routes can never result in reduction of the routing table size. They are, however, an excellent complement to route filters:
Route filters cannot be used by themselves because their usage would probably result in lost connectivity. Default routes can be deployed to replace the lost information.
Default routes cannot be used by themselves because they don't reduce the size of the IP routing table. Route filters can be configured to eliminate the routing information made redundant by the default route.
The traditional classless IP routing model supports only a single default route (0.0.0.0/0). IOS implementation gives you the ability to include several default candidates in the network. The next-hop router of the best default candidate becomes the gateway of last resort.
EIGRP support of the default routes (and default candidates) differs slightly from the way all other routing protocols support default routes; the default route is never generated by the routing protocol but has to be configured manually and redistributed into EIGRP. On the other hand, EIGRP gives you better control over default information exchange than any other interior routing protocol.