Monday, February 11, 2013

BGP - Neighbor Allowas-in

My apologies -- It's been a while since I have posted, although I been pondering upon a few topics. I have been extremely busy with work, family, studies... -- Yes that's right I am going for my M.S in C.S :). In any case, enough about my boring personal life and excuses lets get into this action packed blogtorial. Here is a simple problem that I ran into the other night. I get a call from my colleague asking me if I would take a look and see why the routes from an eBGP neighbor are not being put into the routing table. After a couple of minutes of troubleshooting I pin-pointed the issue to a BGP loop prevention mechanism "called AS_Path: If you see your own AS in an update, drop it". Fortunately, there is a way to get around this in case we need to.

RFC 1771 

Section 9.3 states "If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route.  If such a route were ever used, a routing loop    would result."


To illustrate this in action, let's follow this simple topology.

Complete configurations can be found here.


  • Get R1 configured with IP ADDRESS and a loopback. 
  • Get simple BGP configured.


  • Get R2 configured with IP ADDRESS. 
  • Get simple BGP configured between R1 and R3.


  • Get R3 configured with IP ADDRESS. 
  • Get simple BGP configured.
  • Notice 1.1.1.1/32 is not in the BGP table. Why?? Well because, it sees its own ASN (65111)  in the AS_PATH so it drops it. 



  • Now once we add the allowas-in, we are good to go. Note that even though the AS_PATH contains 65111 which is R3 ASN it still allows the route in. 
  • Also notice that there is an optional parameter that you can put in to limit the number of occurrences.  
Conclusion: 

So simple ... however if you do not know the rudimentary facts about BGP then you would be spending a lot of time troubleshooting simple issues. 

Many more articles to come so stay tuned. I promise!!!

Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.





Posted by
Labels: , ,

2 comments:

  1. socpuppetsFebruary 22, 2013 at 8:34 AM

    Good job

    The allowas-in is almost always needed in a MPLS provider between CEs sites if they don't define unique AS number per site within their customer VRFs.

    As an alternative;

    We also use neighbor as-override as an alternative to allowing AS to be over-written by the SP ASN. It's 50/50 on what's best practice or more acceptable.

    ReplyDelete
  2. Arwin ReprakashFebruary 22, 2013 at 9:39 AM

    You are absolutely correct about the MPLS situation. I have used the as-override when I used to work for an ISP and it worked flawlessly. Thank you for the comment.

    ReplyDelete

Subscribe to: Post Comments (Atom)