Problem solve Get help with specific problems with your technologies, process and projects.

Troubleshooting multi-protocol gotchas

A network containing more than one routing protocol can experience routing loops or black-holed traffic when similar routes collide. Tom Lancaster provides advice for troubleshooting your multi-protocol network in this tip.

For a variety of reasons, many networks use multiple routing protocols. Frequently, it's due to merger and acquisition activity, or is a temporary condition during a migration. There may be a smorgasbord of router hardware vendors using a mix of proprietary protocols bridged together with standards-based protocols. In any case, some routers will be running more than one protocol and will inevitably receive similar routes from both protocols and have to make a decision between them in the process of forwarding packets.

The potential problem here is that the protocols might have different "next-hops" and that can easily result in routing loops or black-holed traffic. This sort of issue is particularly troublesome when you make a change and everything works, but later make a change in another area of the network that has a cascading effect on one of the protocols, changing its next hop. This is difficult to troubleshoot because the "problem" occurs potentially hundreds of miles away from where you were making a change, and that area wasn't included in the test plan for your change.

Regular SearchNetworking.com readers are no doubt aware that on Cisco routers, this decision is made with the Administrative Distance, where protocols are assigned an 8-bit value and the lower the number, the more "believable" the protocol is. For instance, A route received via External Border Gateway Protocol (E-BGP) (AD = 20) will be chosen over a route received by OSPF (AD = 110).

However, what is often forgotten when designing and troubleshooting multi-protocol routing environments and especially when planning the exact migration steps is that Administrative Distance is not the first decision in the process.

If you're planning to migrate your network from one routing protocol to another, as an example, it's critical for you to realize that the length of the prefix is still more important than administrative distance. For example, consider the following routes:

192.168.1.0 /24 via RIP (AD = 120)
192.168.1.0 /20 via BGP (AD = 20)

In this example, your router will send the packet to the next hop identified in the RIP route, not to the next hop identified in the BGP route, even though BGP has an AD of 20. This is because longer prefixes are always preferred. AD only comes into play when the routes are identical in length.

More on this topic

Info center: Tried and true networking protocols

Crash Course: Routers

Browse more tips on Routing & Switching

Why is this so critical to remember? The most common pitfall here is when you're converting between a classful and a classless protocol on a subnetted network. It's easy to get routes of differing lengths. This is OK, of course, as long as you realize what's going on and plan for it.

One strategy you can take to solve related problems is to make the routes the same length by summarizing the smaller one. Obviously, it won't work in every situation, and is kind of a kludgey thing to do, but it is an option. Another strategy would be to make a more distinct border between your routing domains, where you don't permit all the routers in the network to run both protocols -- only the ones that bridge the domains. Be sure to filter advertisements carefully between the domains.


Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.
This was last published in November 2005

Dig Deeper on Network protocols and standards

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close