Interesting BGP/IGP interaction problem

I’ve stumbled across a really interesting BGP/IGP problem described by Jeremy Filliben that nicely illustrates the dangers of using more than one IGP in your network. You should read the original post for details, here’s a short summary:

  • The same IP prefix is received by two BGP border routers (A and D) and sent to a third IBGP-only router (E).
  • E can reach A via OSPF. It can reach D via EIGRP.
  • E receives two BGP paths to the target IP prefix from A and D. They are identical, so the IGP metric (taken from the IP routing table) is used as the tie-breaker.
  • EIGRP and OSPF metrics are totally incomparable and thus A (reachable via OSPF) is always preferred over D (reachable via EIGRP).

Lesson learned: use a single IGP in your AS (or at least in its BGP core).

8 comments:

  1. Petr Lapukhov04 July, 2010 08:10

    Duh, BGP has been troubled from the very beginning :) Just recall BGP Wedgies, MED oscillations and RR/Confederation routing loops due to topology incongruency. However, the problem you described here has been known in BGP design from the very beginning - you should use a single IGP for entire AS, OR implement BGP confederation to scale your IGP. Taking a look into the original (old) RFC 1771 you will notice that AS definition clearly states

    "Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS"

    However, I doubt everyone pays attention to this defintion until he sees the effect of incomparable metrics in practice :)

    ReplyDelete
  2. Ivan Pepelnjak04 July, 2010 08:22

    RFC? Is that the thing someone reads to you after everything else fails? :-P

    ReplyDelete
  3. Ivan Pepelnjak04 July, 2010 21:51

    I usually go even a bit further - access IGP (if you have one) and core IGP should not be linked. Flaps in access network have no business disrupting your core; they should end up in BGP.

    ReplyDelete
  4. Benson Schliesser04 July, 2010 21:59

    The phrase "at least in its BGP core" is a good way to end the post. Multiple IGPs aren't bad, in and of themselves. In fact, one can use different protocols to do creative traffic engineering, create interesting regional topologies, etc. As you know, the key is the "administrative" weight of each protocol, which defines their relative priority. Under most circumstances this is all it takes. That said, in a typical network it's almost certainly desirable to have a uniform IGP topology covering the core. Additional IGP protocols should probably be limited to internal networks with well defined borders, data center networks, or specific regional / aggregation networks.

    ReplyDelete
  5. Sometimes you need to use 2 IGP and BGP on the same router. Think about a router which is facing the internet. That router uses BGP to speak with the ISP´s routers. Also uses EIGRP instead of static routes to create a peer neighboring with them. And eventually, it uses OSPF into the private network.
    This router has 1 interface into OSPF routing protocol, another one into BGP mixed up with EIGRP. It would be a RIB-Failure because of the double-use of 2 IGP + BGP. But it is necesary.
    I set up this lab on my GNS3 and it works though It shows a rib failure.

    ReplyDelete
  6. And yet according to the Cisco approved design practice and covered in the Interconnecting Data Centers Using VPLS using two IGPs is acceptable. 1 for the IP/BGP to MPLS/LDP process and the other for all internal core non MPLS related traffic. Fun times

    ReplyDelete
  7. Hi,

    Was just reading the scenerio that u described above ....Have a little confusion ...You said "E" would learn that route from "A" via OSPF and "D" via EIGRP and to choose the best path it would use the METRIC ....Would it not user AD value prior to that ???? *DONT_KNOW*

    ReplyDelete
  8. hi,
    i second Vandana's comments. Can someone clear on this one since EIGRP Route summary/Internal EIGRP AD is superior than OSPF.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.