Recently I adjusted the maxas-limit option on our router, logs started reporting routes being refused because the AS path is to long. seems to work as expected.
when I looked at the logs I was a bit confused at what i was looking at... why is it there are multiple AS's in the path that appear to be the same AS? I expected an AS path comprised of mostly unique ASs.
instead of this:
476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 43022 43022 43022 43022 47359 47359 47359 47359 47359 47359 47359 47359 received from isp router: More than configured MAXAS-LIMIT
i expected it would look more like:
476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 47359 received from … .. .
thanks for your time again,
greg
People prepend, and think 'more is better' vs using communities and other 'complex' methods of managing their traffic.
It's also the easy tool from the shed. 'set as-path prepend blah' is easier than
match blah, set community blah, match something else, set community blah2, match something3, set something3
in the typical cisco parlance. It's perhaps better (or worse) depending on your vendor and how the policies are actually interpreted and how granular you need to be.
The best question is:
Do you know what prefix you just lost reachability to, or do you just point default as a last resort anyways, so don't know.
- Jared
The originator of this route, and to a lesser extent, their upstream provider are prepending the hell out it, and that's why your router doesn't like it. AS path prepending has its uses, but prepending the origin AS 7x is not likely to make much of an impact from a traffic engineering perspective, and only serve to make the AS path unnecessarily long.
jms
In this day and age, I'm still surprised at how many people think AS Path
prepending is the preferred way to influence inbound traffic paths. As many
providers have default local-pref policies in place which prefer routes
learned from the customer over routes learned from another peer, it is often
the case that a supposed secondary path is actual the preferred path from
the view of that upstream provider.
IMO, a combination of both community tagging to influence localpref coupled
with AS Path prepending on the secondary link is the best approach, and
seems to accommodate both steady state as well as failure scenarios
properly.
Stefan Fouant
BGP community attributes are optional transitive attributes, so in theory they could be used by secondary or tertiary providers for policy processing. However, that is under the assumption that those providers have the proper policies in place and understand those communities. Alsi, in some cases a given provider will strip the communities out before advertisement to upstreams or upon receipt from a downstream, so there is no guarantee that the communities will remain intact.
Typically however, the community tagging is used to influence the direct upstream providers, and the AS Path prepending is used to influence the secondary providers.
Stefan Fouant
My apologies for the top post. Sent from my iPad
Some use AS prepends, not for traffic engineering, as ISPs often
override AS prepends with private peering (communities/local pref
settings), but for the simple purpose of making advertised prefixes
stand out amongst a welter of BGP routes.
In this day and age, I'm still surprised at how many people think AS Path
prepending is the preferred way to influence inbound traffic paths. As many
providers have default local-pref policies in place which prefer routes
learned from the customer over routes learned from another peer, it is often
the case that a supposed secondary path is actual the preferred path from
the view of that upstream provider.
It depends on what you want. In many cases, route preference only extends one AS. It is rare that those AS also give you options for influencing preferences at their next peer. Given that, a prepend often is used to force people to generally chose one path over another, while still allowing traffic in on the secondary peer for any traffic that had to hit it anyways. This has the bonus of also making sure you don't send traffic the long way around when it does hit the neighbor AS. I generally don't prepend more than 3-4 times, though.
IMO, a combination of both community tagging to influence localpref coupled
with AS Path prepending on the secondary link is the best approach, and
seems to accommodate both steady state as well as failure scenarios
properly.
There is no proof in this case that all of these things weren't done. We only have the evidence of the Path prepend. Of course, the default localpref for most of my transits is to prefer me over other peerings, so I rarely adjust that unless I don't want any traffic what so ever.
Jack
One has to wonder how many places are using the prepend-me-harder
commands to do traffic engineering, and have absolutely no clue that
their prepends are having the opposite effect because the prefix is
being dropped entirely by some AS's.
I suppose the exact same issue applies for those places that deaggregate
in an attempt to to TE, and the de-aggregated prefixes get munched by
somebody's prefix-length filter.