BGP Loop Prevention

[maosa7578]

I have always understood that a BGP speaker will check the AS_PATH of the incoming update. If it detects its own AS number in the Update, it detects a possible loop and does not accept that update.

I am reading today the " CCIE Routing and Switching Official Exam Certification Guide, Second Edition" by Wendell Odom et all and it said in this book that a BGP speaker will actually not send the update if it detects that the intended recepients AS number is in the AS_PATH of the update it would be sending.

This to me seems to suggest that the loop prevention is done on the sender, and not on the receiver. Could someone shed more light on this ? If it happens in the way that Mr Odom explains, would we need AS-Override ? AllowAS-in ?

Thanks in advance.

Herbert.

[mheusinger]

Hello Herbert,

I think Mr. Odom is not correct about this. As you already pointed out - refering to "as-override" and "allowas-in" - several features especially in a MPLS VPN environment would not work.

I myself have seen (debug ip bgp updates) BGP speakers announcing the best pathes - regardless of AS number of their neighbor.

"allowas-in" would be completely useless, if a BGP speaker (standard complying CE) would suppress updates containing the neighbor AS in the AS path.

Hope this helps! Please rate all posts.

Regards, Martin

[gauravprakash]

By default , the nature of BGP is that it will not accept prefix if it has its own AS number in AS_Path. You can change this , by using allow AS-in in the neighbour XXXX command.

AS-Override is feature used by eBGP neighbour to remove present AS numbers and put its own AS number, so that the receiver can accept it.

Hope that helps. Plz rate the post if useful.

regards,

Gaurav

[maosa7578]

Gaurav,

Thanks for your response. But I do understand the use of AS-Override and AllowAS-in. But my query was that we would not need these commands if a BGP speaker already filters updates and never sends them to neighbors whose AS number already appears in the AS_PATH. If this were the case, a bgp speaker should never have to see its own AS number in received updates, and hence no need to worry about loops on the receiving side. The text in Wendell Odom's book suggests that a BGP peer checks the AS number of the intended speaker and if it is in the AS_PATH of the update it would be sending, it would not send that particular update to that neighbor. He suggests the same happens in confederations. This is the bit that has put me off track regarding everything I know about BGP operation.

[pkhatri]

Hi Herbert,

I just quickly verified this in my copy of Wendell's book and you are indeed correct that this is what he is stating.

Unless every implementation that is currently around has been recently changed, I must disagree with that statement. Here's a quote from RFC4271:

"If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document."

Also, there is absolutely no mention in the RFC of a sender filtering out updates that contain its peers AS number in the AS Path.

So your understanding of BGP operation is correct .. it just appears that Wendell has made a mistake.

Pls do remember to rate posts.

Paresh