BGP routing loop caused by outbound route-map

Hi all,

I managed to trip over a routing loop in BGP just by changing the local preference in an outbound route-map between two routers running IBGP.

I was using the following topology:

                         +-+-+-+-+    
                         |   R2  |    
          +-+-+-EBGP-+-+-+  AS 2 |    
          |              +-+-+-+-+    
          |                  |        
      +-+-+-+-+              |        
      |   R1  |            IBGP       
      |  AS 1 |              |        
      +-+-+-+-+              |        
          |              +-+-+-+-+    
          |              |   R3  |    
          +-+-+-EBGP-+-+-+  AS 2 |    
                         +-+-+-+-+    

 

R1 was in AS 1

R2 and R3 were in AS 2

R1 was advertising 1.1.1.1/32 to R2 and R3 via EBGP

R2 and R3 were connected via IBGP

 

During testing I used an outbound route-map between R2 and R3 to set the local preference of 1.1.1.1/32 to 1000.

This caused R2 and R3 to both consider each other the best path to 1.1.1.1/32 which resulted in a loop.

 

It was my naive belief that routing loops are only caused by bad redistribution or misconfigured static routes. It was a surprise to me that a simple outbound BGP policy could cause this.

The fix in this case was to change to an inbound route-map on R2 and R3 to set local preference on the EBGP sessions from R1.

 

So have I missed something fundamental with BGP route-maps? Are BGP outbound policies vulnerable to loops in general?

I can’t be the only person to run into this type of issue. Would love to see some references to documents/case studies.

 

Thanks,

Bob

Comments

  • In many respects BGP can act as a routing policy application (on top of distributing prefix and next-hop information).  You apply policy (via a route-map usually) to whatever prefixes you wish (as set in the policy).

    What you did was say on both R2 and R3 (I think you did it on both although I'm not quite sure from your post above if this is the case) was to set the policy of  prefix 1.1.1.1/32 to be preferred by all other routers in AS 2.  However you did it outbound, so it did not take effect before being entered into the routing table of the local router on which you applied.  So the higher local preference was not making it into the local BGP table, and therefore not into the routing table of the local router.

    You can do this a number of ways in BGP.  You could set the weight inbound between R2 and R3 so that each router preferred the others route - this would also result in a loop.  You could do the something similar with metric.  This is why BGP is so fun, and also why occasionally a network engineer without enough caffeine can cause major glitches in the global internet with some finger fumbling... ;)

  • Thanks for that jdcook.

     

    Yes I had the outbound route-map on both R2 and R3 so they were both telling each other their copy of 1.1.1.1/32 was local preference 1000 even though in the local RIBs both routers considered their route to be local preference 100.

     

    So like you say, there was a mismatch between what was being sent to neighbors and what was happening locally. It sounds like this could be a common pitfall with outbound policy!

  • Hello Bobby1 and jdcook,

    I have a question about this situation, and that is if this problem is only present at a particular time, when R2 and R3 start receiving advertisements from R1 at the same time.

    I am asking this because I can think in a situation in which happens that one router of AS 2 receives the route advertisement and then the other one, for example,

    First, R2 receives the EBGP route of 1.1.1.1/32 from its peer R1 in the AS 1. Because R2 detects this route as the current best, R2 installs the route in its routing table with LP 100.

    Next, R2 alters the local preference to 1000 and advertises this route to its IBGP peer R3 with this local-preference value. At this point, R3 receives the 1.1.1.1/32 route through IBGP.

    Next, R3 then also receives the EBGP route for 1.1.1.1/32 from the AS 1. At this point, R1 determines that it already has a route to 1.1.1.1/32 from R2, with a local preference of 1000. The presence of this route to R2 overrides the EBGP-received route that will have a local-preference value of 100.

    Because the current version of the route on R3 is from R2, and because IBGP implements split horizon, the routing loop never forms. R3 just sends traffic for 1.1.1.1/32 to R2. And because only active BGP routes are advertised, no confusion develops on R3 with regard to the best path to reach 1.1.1.1/32—R2 is the choice.

     

    What do you think?

    regards  

Sign In or Register to comment.