An Example of Static Versus Dynamic Routing: Mobile Networks

It is common in the military for units to be mobile; this creates a problem for assigning IP addresses. Usually these mobile units would like to deploy their subnets and IP addresses wherever they go and operate as if they had never moved. If these networks are part of a global network and advertised via BGP, announcing them statically will not work easily. The static commands would have to be removed from the border router of one AS in one location and installed in the border router of another AS in the new location every time the unit moves.

To avoid such complications, injecting these networks dynamically into BGP becomes mandatory. One solution is to inject the IGP into BGP in all locations. This way, whenever the IP addresses are moved from one location to the other, the announcements will disappear from one location and reappear in the new one. In some cases, network administrators are not comfortable with this solution for reasons discussed earlier, such as mutual redistribution problems and the mandate for extensive filtering.

Another possibility is to define these networks in all the border routers of all the locations via the network command. Because BGP checks for the existence of these routes in the IP routing table before announcing them, BGP will only announce the routes in the location of the mobile unit. All other locations will automatically cease from announcing the routes because they are not part of the IGP of that particular AS.

Overlapping Protocols: Backdoors

With different IGPs and EGPs working together to achieve routing, networks can be learned via different protocols. Choosing one protocol over the other affects how the traffic flows. If, for example, traffic follows a RIP route, it might end up on one link; whereas if it follows an external BGP route, it might end up on another link. Backdoor links offer an alternate IGP path that can be used instead of the external BGP path. IGP routes reachable over the backdoor link are called backdoor routes. With the existence of such alternate routes, a mechanism that gives one protocol preference over other protocols is needed. Cisco Systems offers a preference parameter called the distance of a protocol. The lower a protocol's distance, the higher the preference for the protocol. Table 5-1 lists distances according to the Cisco implementation.

---

Troubleshooting:  
Example: Ch. 10, pp. 324-326. Overlapping Protocols: (Backdoors)

---

Table 5-1 indicates that a directly connected route is generally preferred over a static route, which in turn is preferred over an EBGP route, and so on. Note that EBGP routes with a distance of 20 are preferred over all the other IGP routes.

Figure 5-7 illustrates the use of backdoor routes. In the figure, AS1 is receiving updates about NetA from two different sources. AS1 is receiving routes via EBGP on the link to AS3 and via the backdoor link running RIP between AS1 and AS2. According to the distance table, the router will give a distance of 20 to the EBGP route and a distance of 120 to the RIP route. In AS1, the EBGP route with the lower distance will be installed in the routing table. Hence, traffic toward NetA will follow the BGP route via AS3 and then AS2, rather than the direct RIP route via AS2.

Figure 5-7  Backdoor routing conflicts.

Cisco provides a way to force IGP routes to take precedence over the EBGP routes. The concept is simple. EBGP routes can be tagged as backdoor routes. This would set the distance of these routes to be the same as the "BGP Local" route's distance (default is 200). According to table 5-1, this distance is higher than any IGP learned route, and the backdoor IGP route will be preferred.

The Routing Process Simplified

Up until now, this chapter has examined discrete aspects of routing, specifically peer negotiation and static versus dynamic routing. Before diving into details of routing configuration, it makes sense to pause here and briefly overview the BGP routing process in its entirety.

BGP is a fairly simple protocol, which is why it is so flexible. Routes are exchanged between BGP peers via UPDATE messages. BGP routers receive the UPDATE messages, run some policies or filters over the updates, and then pass on the routes to other BGP peers. Cisco's implementation of BGP keeps track of all BGP updates in a BGP routing table separate from the IP routing table. In case multiple routes to the same destination exist, BGP does not flood its peers with all those routes; rather, it picks the best route and sends it. In addition to passing along routes from peers, a BGP router may originate routing updates to advertise networks that belong to its own autonomous system. Valid local routes originated in the system, and the best routes learned from BGP peers are then installed in the IP routing table. The IP routing table is used for the final routing decision.

To model the BGP process, imagine each BGP speaker having different pools of routes and different policy engines applied to the routes. The model would involve the following components:

•  A pool of routes that the router receives from its peers

•  An Input Policy Engine that can filter the routes or manipulate their attributes

•  A decision process that decides which routes the router itself will use

•  A pool of routes that the router itself uses

•  An Output Policy Engine that can filter the routes or manipulate their attributes

•  A pool of routes that the router advertises to other peers

Figure 5-8 illustrates this model. The subsequent discussion provides more details about each component.

Figure 5-8  Routing process overview.