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