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 -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
On Nov 10, 2010, at 3:22 PM, Greg Whynott wrote:
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 … .. .
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
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Wednesday, November 10, 2010 3:31 PM To: Greg Whynott Cc: nanog@nanog.org list Subject: Re: AS path question.
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
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
Stefan Fouant wrote:
-----Original Message-----
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
So how far from you can you propagate community tags to influence the route decision process to your second transit upstream peer? Joe
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 On Nov 10, 2010, at 4:12 PM, Joe Maimon <jmaimon@ttec.com> wrote:
Stefan Fouant wrote:
-----Original Message-----
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
So how far from you can you propagate community tags to influence the route decision process to your second transit upstream peer?
Joe
On 11/10/2010 2:44 PM, Stefan Fouant wrote:
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
On Wed, 10 Nov 2010 15:31:25 EST, Jared Mauch said:
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.
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.
On Wed, 10 Nov 2010, Greg Whynott wrote:
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
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
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. -----Original Message----- From: Greg Whynott [mailto:Greg.Whynott@oicr.on.ca] Sent: Wednesday, November 10, 2010 12:22 PM To: nanog@nanog.org list Subject: AS path question. 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 -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
participants (8)
-
Greg Whynott -
Holmes,David A -
Jack Bates -
Jared Mauch -
Joe Maimon -
Justin M. Streiner -
Stefan Fouant -
Valdis.Kletnieks＠vt.edu