Hi. Apologies if this posting is off topic. I'd observed some loops in the AS Paths as seen by the Route-Views routeserver. In one particular snapshot -- about 2% of the paths involved such loops. Here are some examples.....(taken from route-views). 11608 2914 1239 12064 22773 12064 11836 1221 4637 1239 12064 22773 12064 11836 1224 38 7228 1239 12064 22773 12064 11836 1239 12064 22773 12064 1239 12064 22773 12064 11836 19092 3356 1299 766 288 766 3356 1299 766 288 766 4181 3356 1299 766 288 766 6079 3356 1299 766 288 766 8220 1 3356 701 668 5058 48 3356 RFC 1771 has the following to say: ----------------------------- 9.3 Route Selection Criteria Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop would result. ------------------------------ So it seems to me that these paths violate the BGP spec. Can anybody comment about whether these paths are in fact valid. Are these used in specific settings by ISP's. Most of these loops are of length < 3, but there are also some that are really long (5-6). Looking closely at the shorter paths, I get the feeling that these loops are intentional, perhaps to acheive some traffic engineering goal. Note that we tried to traceroute along some of these loops, and in almost all the cases, there was no forwarding loop (so probably not a flaky route). What sort of situations would warrant these AS Path loops. From my understanding of the BGP decision process - routes that contain the current AS in the path are automatically excluded from the path selection process. Is this correct ? Any comments would be helpful. thanks. -jaideep
Jaideep Chandrashekar <jaideepc@cs.umn.edu> writes:
Hi. Apologies if this posting is off topic.
I'd observed some loops in the AS Paths as seen by the Route-Views routeserver. In one particular snapshot -- about 2% of the paths involved such loops.
Here are some examples.....(taken from route-views).
11608 2914 1239 12064 22773 12064 11836 1221 4637 1239 12064 22773 12064 11836 1224 38 7228 1239 12064 22773 12064 11836 1239 12064 22773 12064 1239 12064 22773 12064 11836 19092 3356 1299 766 288 766 3356 1299 766 288 766 4181 3356 1299 766 288 766 6079 3356 1299 766 288 766 8220 1 3356 701 668 5058 48 3356
RFC 1771 has the following to say:
----------------------------- 9.3 Route Selection Criteria
Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop would result. ------------------------------
So it seems to me that these paths violate the BGP spec.
Can anybody comment about whether these paths are in fact valid. Are these used in specific settings by ISP's. Most of these loops are of length < 3, but there are also some that are really long (5-6).
Looking closely at the shorter paths, I get the feeling that these loops are intentional, perhaps to acheive some traffic engineering goal. Note that we tried to traceroute along some of these loops, and in almost all the cases, there was no forwarding loop (so probably not a flaky route).
What sort of situations would warrant these AS Path loops.
From my understanding of the BGP decision process - routes that contain the current AS in the path are automatically excluded from the path selection process. Is this correct ?
Any comments would be helpful.
In many (most?) these "loops" are intentional, and a result of playing 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 for routes that I originated internally. Hope this helps, ---Rob
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
Joe Provo <nanog-post@rsuc.gweep.net> writes:
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].
Agreed on all counts. Note that I didn't suggest that it was a good idea, just pointed out that this has certainly been done in the past (I seem to recall more than one organization doing this to keep certain routes out of AS690).
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.
I'm not sure I agree with that assessment. Strong indicator of a nasty hack, much much less strong indicator of anything unseemly afoot. Or perhaps this was a use of the term "suspicious" to which I'm heretofore unaccustomed.
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.
Yes, and vote with your feet when your contract is up if they don't deliver.
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.
Well, yes. Attempt this trick at home at your own peril, &c &c &c... ---Rob PS: I am sure that we both are going to hell for having the unmitigated gall to post stuff to NANOG that actually has something to do with running a backbone.
The "J" vendor expects to see these this when receiving BGP routes, there is a switch in their software to allow this to put the routes into the forwarding table. Their explanation was that the RFC actually said that it was the receiving hosts job to decide what to do with this not that it was forbidden in the RFC to advertise them to anybody (And as Mr Rekhter worked/works for them I kinda thought they would be right). In our case a customer using BGP to our network from the same AS in two locations but not running an IGP between them (our's is not to reason why and all that) so they wanted us to advertise their own routes to them which we accomplished by putting them into a peer group on the "C" router they where connected to (which circumvents the as-path checks (as well as those checking if it is advertising routes back to the originator) ,or at least did at the time). Couple o links showing what J are talking about. http://www.juniper.net/techpubs/software/junos/junos60/swconfig60- routing/html/bgp-summary4.html http://www.juniper.net/techpubs/software/junos/junos60/swconfig60- routing/html/bgp-config48.html On Dec 8, 2003, at 7:31 PM, Jaideep Chandrashekar wrote:
Hi. Apologies if this posting is off topic.
I'd observed some loops in the AS Paths as seen by the Route-Views routeserver. In one particular snapshot -- about 2% of the paths involved such loops.
Here are some examples.....(taken from route-views).
11608 2914 1239 12064 22773 12064 11836 1221 4637 1239 12064 22773 12064 11836 1224 38 7228 1239 12064 22773 12064 11836 1239 12064 22773 12064 1239 12064 22773 12064 11836 19092 3356 1299 766 288 766 3356 1299 766 288 766 4181 3356 1299 766 288 766 6079 3356 1299 766 288 766 8220 1 3356 701 668 5058 48 3356
RFC 1771 has the following to say:
----------------------------- 9.3 Route Selection Criteria
Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop would result. ------------------------------
So it seems to me that these paths violate the BGP spec.
Can anybody comment about whether these paths are in fact valid. Are these used in specific settings by ISP's. Most of these loops are of length < 3, but there are also some that are really long (5-6).
Looking closely at the shorter paths, I get the feeling that these loops are intentional, perhaps to acheive some traffic engineering goal. Note that we tried to traceroute along some of these loops, and in almost all the cases, there was no forwarding loop (so probably not a flaky route).
What sort of situations would warrant these AS Path loops.
From my understanding of the BGP decision process - routes that contain the current AS in the path are automatically excluded from the path selection process. Is this correct ?
Any comments would be helpful.
thanks.
-jaideep
* bcrocker@hamsterjam.net (Ben Crocker) [Tue 09 Dec 2003, 10:44 CET]: [..]
In our case a customer using BGP to our network from the same AS in two locations but not running an IGP between them (our's is not to reason why and all that)
A commonly accepted definition of AS is as follows:- | An Autonomous System (AS) is a connected group of one or more IP | prefixes run by one or more network operators under a *single* and | clearly defined routing policy. [emphasis mine] One cannot have discontiguous networks in the same ASN. It's pretty simple: two routing policies, two ASes, two ASNs. Unfortunately you weren't able to convince your customer of this. As you showed, it can be configured. More power to Vendor J for giving us all the choice to do so, but that still rarely makes it a good idea. -- Niels. -- the generation that used acid to escape reality is now using antacid to deal with reality
In a message written on Tue, Dec 09, 2003 at 03:13:12PM +0100, Niels Bakker wrote:
One cannot have discontiguous networks in the same ASN. It's pretty simple: two routing policies, two ASes, two ASNs. Unfortunately you weren't able to convince your customer of this.
This is simply not true, and trying to push it as an absolute elimintes a very good way of configuring customers and conserving resources. Most (all) large ISP's have a "customer ASN". This allows a customer to connect in multiple places, run BGP, and get something approximating real redundancy to that carrier. However, rather than allocate one ASN to each customer, all customers use the same "customer ASN". Yes, that means they must default to the provider (and/or have the provider provide a default route) to reach the other customers using this technique. I believe there are a number of providers with hundreds, or perhaps even thousands of customers using this feature, saving lots of ASN's and causing no problems. Externally this looks fairly neat, there is a single ASN behind the backbone AS with all the customers in it. To make this work you do need to enforce some restrictions. First, the customer ASN must never be connected to another network (this is for multiple connections to a single provider only) to prevent the wonky AS path issues, and second the customer must have a default via some mechanism. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
* bicknell@ufp.org (Leo Bicknell) [Tue 09 Dec 2003, 16:00 CET]:
In a message written on Tue, Dec 09, 2003 at 03:13:12PM +0100, Niels Bakker wrote:
One cannot have discontiguous networks in the same ASN. It's pretty simple: two routing policies, two ASes, two ASNs. Unfortunately you weren't able to convince your customer of this.
This is simply not true, and trying to push it as an absolute eliminates a very good way of configuring customers and conserving resources.
Why don't we hand out duplicate IP addresses too, while we're at it? Let RIPE, ARIN and everybody all assign from 67/8 and force all HTTP traffic through a proxy in globally unique address space run by each ISP that receives such an allocation. Right now, every ISP that uses the trick described earlier has to configure dangerous stuff anyway. [stretching analogies way beyond their breaking points for fun and profit!]
Most (all) large ISP's have a "customer ASN". This allows a customer to connect in multiple places, run BGP, and get something approximating real redundancy to that carrier. However, rather than allocate one ASN to each customer, all customers use the same "customer ASN". Yes, that means they must default to the provider (and/or have the provider provide a default route) to reach the other customers using this technique.
*shrug* then they're all using that "customer ASN" against the letter and the spirit of what an AS used to stand for. Private ASNs were invented for this application, and you can strip them from your announcements too. For the outside world your "customer ASN" has exactly one routing policy: Send it to the owner. Traffic for those prefixes has no other way of reaching its destination, so it doesn't break the system too badly. Of course, it's a different story when those customers start to multihome with the "customer ASN..." Anycast is another example (thanks, Joe Abley - I stupidly deleted your CC'd mail before checking whether it had come in over NANOG as well) of a situation that falls outside the original definition of an AS - is it the same network existing in multiple places at the same time? - so one possibility could be to amend the various standards to current practices. -- Niels. -- the generation that used acid to escape reality is now using antacid to deal with reality
Most (all) large ISP's have a "customer ASN". This allows a customer to connect in multiple places, run BGP, and get something approximating real redundancy to that carrier. However, rather than allocate one ASN to each customer, all customers use the same "customer ASN". Yes, that means they must default to the provider (and/or have the provider provide a default route) to reach the other customers using this technique.
Perhaps I'm missing something having not done this myself but why arent the customers just using private ASNs? That would also remove the 'must default' clause. Steve
In a message written on Thu, Dec 11, 2003 at 11:07:03PM +0000, Stephen J. Wilcox wrote:
Perhaps I'm missing something having not done this myself but why arent the customers just using private ASNs? That would also remove the 'must default' clause.
Not enough, customers already use them internally, other things use them (eg, route servers), easier to talk customers through configs on the phone, allows customers who have IP space but not an ASN to announce to the Internet without the provider having to announce directly. I'll bet there are more I can't remember. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Thu, Dec 11, 2003 at 11:07:03PM +0000, Stephen J. Wilcox wrote:
Perhaps I'm missing something having not done this myself but why arent the customers just using private ASNs? That would also remove the 'must default' clause.
What if you have more customers than there are private ASNs? Think about things like 2547-style VPNs, etc. What if you want to propogate those customers' BGP announcements to the world? Which hardware vendors support a "strip-private-ASN" feature? Did they always do so? If every such customer uses a private ASN, every other default-free customer must accept routes from the ISP that contain private ASNs in the as-path. Which of your default-free customers might be filtering those prefixes? It makes it a little more difficult for the ISP to filter prefixes with private ASNs in the path; those from some customers must be honored; those from other customers and from peers should be dropped. The ones that were supposed to be honored should be passed along to other BGP-speaking customers but not to peers. This is obviously not an insurmountable problem, but it does add a lot of config complexity. Private-ASN collisions (i.e., when one customer uses one ASN to talk to the ISP and another ASN internally which the provider assigns to a different customer) will cause problems. You WILL hear this from a customer: "I want to use ASN X for this purpose because that's what my consultant said." Repeat, but s/a customer/another customer/. Etc. --Jeff
--- "Stephen J. Wilcox" <steve@telecomplete.co.uk> wrote:
Most (all) large ISP's have a "customer ASN". This allows a customer to connect in multiple places, run BGP, and get something approximating real redundancy to that carrier. However, rather than allocate one ASN to each customer, all customers use the same "customer ASN". Yes, that means they must default to the provider (and/or have the provider provide a default route) to reach the other customers using this technique.
Perhaps I'm missing something having not done this myself but why arent the customers just using private ASNs? That would also remove the 'must default' clause.
Steve
1) It would only remove the "must default" clause if the provider either stripped (or overrode) the local-as, or if all of the private ASNs were unique. That is a big headache. 2) Private ASNs are not, per RFC1918, supposed to be connected to the Internet, in much the same way that private IP space is not supposed to be connected to the Internet. This can also be solved by stripping/overriding. 3) One advantage of using a public, albeit common, customer ASN is that if a customer has RIR-allocated space, those IPs will make it onto the global table, and will not suffer the filtering which may be present for the provider's own routes. ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Ok I've had a few responses on and off list on this but arent really getting this idea, as I said tho I've not done this so perhaps thats where I'm missing the crucial points..
1) It would only remove the "must default" clause if the provider either stripped (or overrode) the local-as, or if all of the private ASNs were unique. That is a big headache.
You must strip the local-as, this is one command that can sit in a peer group on my ciscos so not a big deal.
2) Private ASNs are not, per RFC1918, supposed to be connected to the Internet, in much the same way that private IP space is not supposed to be connected to the Internet. This can also be solved by stripping/overriding.
yes
3) One advantage of using a public, albeit common, customer ASN is that if a customer has RIR-allocated space, those IPs will make it onto the global table, and will not suffer the filtering which may be present for the provider's own routes.
Ok this seems to be a difference, altho not sure why the custs IPs should need to do anything different from the providers IPs as presumably both need to be reachable from everywhere? Steve
--- "Stephen J. Wilcox" <steve@telecomplete.co.uk> wrote:
3) One advantage of using a public, albeit common, customer ASN is that if a customer has RIR-allocated space, those IPs will make it onto the global table, and will not suffer the filtering which may be present for the provider's own routes.
Ok this seems to be a difference, altho not sure why the custs IPs should need to do anything different from the providers IPs as presumably both need to be reachable from everywhere?
There are providers out there who treat $PEER differently from $CUSTOMER_OF_PEER, with regard to aggregation etc. Also, I believe that there used to be providers who would dampen routes on a per-AS basis, rather than on a per-route basis. I am not sure whether anyone still does this. ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
participants (9)
-
Ben Crocker -
David Barak -
Jaideep Chandrashekar -
Jeff Aitken -
Joe Provo -
Leo Bicknell -
Niels Bakker -
Robert E. Seastrom -
Stephen J. Wilcox