The Longest Match Routing Rule

Routing to all destinations is always done on a longest match basis: a router that has to decide between two different length prefixes of the same network will always follow the longer mask. Suppose, for example, that a router has the following two entries in its routing table:

-198.32.1.0/24 via path 1

-198.32.0.0/16 via path 2

When trying to deliver traffic to host 198.32.1.1, the router tries to match the destination with the longest prefix and would deliver the traffic via path 1. This is illustrated in figure 3-12 where Domain C is receiving the two updates 198.32.1.0/24 and 198.32.0.0/16; traffic toward 198.32.1.1 is following path 1. In case path 1 goes down for some reason, traffic will take path 2. In cases where Domain C is receiving identical routing updates with masks of equal length coming from Domain A and Domain B, Domain C would pick one path or the other or both depending on the load balancing techniques offered by the specific routing implemetation defined for that domain.

Figure 3-12  Following the longest match.

The longest match rule implies that destinations connected to multiple domains must always be explicitly announced—that is, announced in their most specific, not aggregate, forms—by these domains. In figure 3-12, because Domain B does not explicitly advertise route 198.32.1.0/24, traffic from the customer to the host must always go via the longest prefix match, through Domain A. Such a routing configuration might put an unacceptable burden on Domain A.

Less Specific Routes of a Network's Own Aggregate

A specific rule of routing states that, for the sake of preventing routing loops, a network must not follow a less specific route for a destination that matches one of its own aggregated routes. A routing loop occurs when traffic circles back and forth between domains, never reaching its final destination. Default routes 0.0.0.0/0.0.0.0 are a special case of this rule. A network should not follow the default to destinations that are part of one of its aggregated advertisements. This is why routing protocols that handle aggregation of routes should always keep a Pit Bucket (Null0 route in Cisco's terminology) to the aggregate route itself. Traffic sent to the pit bucket will be dropped, which would stop the loop situation.

---

Troubleshooting:  
Avoiding loops in default routing by use of pit buckets.

---

Figure 3-13 illustrates ISP1 aggregating its domain into a single route 198.32.0.0/13. Assume that the link between ISP1 and its customer Samnet (where network 198.32.1.0/24 exists) broke. Suppose also that ISP1 has a default route 0.0.0.0/0.0.0.0 that points to ISP2 for addresses not known within ISP1. Traffic toward 198.32.1.1 will follow the aggregate route to ISP1, will not find the destination, and will follow the default route back to ISP2. The traffic will bounce back and forth between ISP2 and ISP1. To prevent such a loop, a null0 entry to the aggregate route, installed in ISP1's border router will drop all packets destined to an unreachable destination less specific than the aggregate route.

Figure 3-13  Following less specific routes of a network's own aggregate causes loops.

Aggregation, if not properly applied, could result in routing loops and black holes. A black hole occurs when traffic reaches and stops at a destination that is not its intended destination, but from which it cannot be forwarded. These and other routing challenges will become more apparent as you learn about multiple IP address allocation schemes and how they interact with aggregation.

Single-Homing Scenario: Addresses Taken from Outside the Provider's Address Space

In this scenario, the customer is connected to a single provider and has an IP address space totally different from the provider's. This could have happened because the customer changed providers and kept the addresses of the previous provider. Usually in this situation, customers are encouraged or forced to renumber. But if renumbering does not take place, the new provider cannot aggregate the customer addresses. Moreover, the old provider cannot aggregate as efficiently as it once did, because a hole has been punched in its address space. The overall effect of using addresses from outside the provider's address space is that more routes must be installed in the global routing tables.