Just a curious thought about AS_PATH. The way loop prevention works in BGP is that if I see my own AS in the AS_PATH attribute, then I discard the route.
My curiosity is this … why did my neighbor send me the route in the first place? He knows my AS number. He could see the route had my AS in the AS_PATH attribute. So why did he bother to send it to me, if he knew I would just discard it?
{ 5 comments… read them below or add one }
I had sometimes the same thought.
Probably only the first AS (peer AS) is checked not all of those that are in the path.
However, if this check was implemented the neigh allowas-in command could not be used to interconnect partitioned ASes
feel this is how BGP is implemented.
If you go through the decision process, mainly the Adj-Rib in, the local Rib and the Adj-Rib out we’ll get to know the idea how BGP process the routes and decides on the routes to be sent outbound.
It would be expensive to implement a per neighbor based Adj-Rib out, if my understanding is correct.
Its the BGP algorithm to include the loop free check in the routes it recieves and which is applicable to all BGP speakers !
Any more thoughts would be appreciated !!
Giuseppe, I had not considered the case of the partitioned AS. I’ll have to think that one through this evening, once I am out of the boiler-room. In fact, I’ll have to think through how a partitioned AS would work anyway.
I take the piont about the implementation detail, and it being costly to perform outbound filtering on a per-neighbor basis. But sometimes you are doing that anyway. Maybe they decided it would be quicker to send all the routes and let the peer sort it out. Sort of … is it more costly to send the extra redundant routes, or to spend CPU cycles pre-discarding a few of them? Of course, the peer that receives the routes would still have to (double) check them anyway.
I’ll have to do some experiments with this. I should be able to emulate it with an AS_PATH filter on the outbound neighbor, or maybe with ORF configured on the inbound neighbor (if I can remember the details of how ORF works .. maybe it would not be possible)?
If I come up with anything interesting I’ll post about it.
As RFC 4271 says, “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”. Theoretically, an external peer of the local system could see loops involving the local system, but doesn’t bother to check it on behalf of the local system at any point. We could say that’s how BGP works. Now, why things work the way they do is usually another story. I don’t personally know of a definitive answer to your question, but I am thinking of some possible reasons.
Giuseppe already mentioned a feature that would have trouble working if responsibility for the loop check of the local AS was assigned to its external peers. Had the external peers been doing loop check on behalf of the local AS, this feature (allowas-in) would need modifications to the configuration of multiple peers (instead of just changing the configuration of the local AS) in order to work, so it’s not flexible I think (I assume that the loop check could somehow also be disabled on the peers).
You are kind of asking for an automatic implicit loop check feature, probably at the beginning of an out-filter (because route must be rejected if it includes a loop) or before out-filtering starts. Outgoing update process might be delayed in routers with many peers such ISP routers. Note that out-filters from end customer AS’s towards the ISPs vary (and end customers do not send lots of routes towards the internet core), but out-filters in the opposite direction, from ISPs towards the end customer often involve specific sets (such as full, partial or default routes, typically organized in peer-groups) and are not so much dependent on the remote AS value, but more on the “type” of customer. Also, we are talking about a full scan of the AS path of all routes (with different procedure for each remote AS). A real-life filter usually causes only a partial scanning of the AS path involving the first few AS’s in the path (and out-filters can also be grouped to avoid doing the same out-filtering task many times).
It seems logical to me for every AS to check for loops of their own AS (instead of loops on behalf of everybody else they peer with) from an authority, flexibility and distribution of load accross routers/scalability perspective. Generally, in BGP context, flexibility for each AS to create their own policy is preferred over proactive work, especially when the proactive work is done for the sake of other AS’s. If the loop is a problem, then I think it is mainly a problem for the AS being involved in it, so I think this AS is the best authority to act on its resolution anyway. (BTW: If your upstream had done the loop check for you, would you feel confident and not repeat the same check on your router?)
In the end, how many such loops exist and how often do they appear? Such a check might complicate and slow down upstream routers in the common case of “no loops” for the sake of not wastefully sending some extra (potentially invalid) updates to the local AS in the less common case. As I see it, it’s not just the extra work (and a few cpu cycles), but work that might also slow down the existing outgoing update tasks (the extra cpu cycles could be viewed as a base cost to pay for sending any route to a peer, even when no other out-filtering is needed, and this cost is a full AS path check for the peer’s AS).
Kind Regards,
Maria
I think Maria has hit the nail on the head with this.
Put simply within a BGP AS you are responsible for what routes are received and propogated within your AS and what routes are advertised from your AS. If neigboring AS are filtering routes to you based on your AS PATH being present you have now relinquished some of the responsibility for your AS which goes against the whole idea of an AS in the first place.
This explains why BGP was implemented the way it was ie. it is the responsibilty of the local AS to control what enters and leaves that AS in terms of route advertisements.
You must log in to post a comment.