On Mon, Dec 08, 2003 at 03:50:21PM -0500, Robert E. Seastrom wrote:
11608 2914 1239 12064 22773 12064 11836 1221 4637 1239 12064 22773 12064 11836 [snip] In many (most?) these "loops" are intentional, and a result of playing
Jaideep Chandrashekar <jaideepc@cs.umn.edu> writes: [snip] prepending games... There's no restriction on what you can prepend to an AS path (and it can be handy to put stuff in there to keep other providers from picking up your routes as we'll see momentarily), but your peer generally wants to see the most recent as in the path as your AS.
So if I (AS3066) wanted to send routes to Sprint that were not to be picked up by UUnet, I could do as follows:
route-map to-as1239-nothanks-uu permit 10 set as-path prepend 3066 701
and apply it outbound in the advertisement to Sprint.
Then what you would see in the route reflector would be:
1239 3066 701 3066
While this is an explataion of the behavior, it should not be an endorsement. Prepending someone else's AS is a bad practive. Not only does it munge 'pure' research data, but fowls some levels of peer evaluation [in the example, and as-701 connected entity seeing your path from 1239 would have to determine why they weren't getting your paths; or a casual glance would indicate you were'nt peer-worthy because you were behind a peer]. Worse, forging AS-paths obfuscates the operational chain of responsibility. Of course that is the goal of some of theses actrivities. Obviously-bogus AS paths are a strong indicator of suspicious activity. Many providers publish specific BGP communities for customers to use to handle the redistribution at the provider's edge; some are coarse-grained and some provide real control. Many provide something but you have to ask for the information. If your provider doesn't give you this service/feature, demand it. In RS's example, a trip to http://www.sprint.net/policy/bgp.html would tell you to just tag with community 65000:701 route-map to-as1239-nothanks-uu permit 10 set community 65000:701 Attempting action at a distance generally fails at the far-end of your service contract; any implementation that *does* work *should* only spew data the same distance. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE