AS Path Loops in practice ?

Mailman List Mirror (Read Only)
1

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:

2

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

3

Jaideep Chandrashekar <jaideepc@cs.umn.edu> writes:

[snip]

> 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
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 Sprint Portal
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.

4

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 Sprint Portal
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.

5

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

6

* 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.

7

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.

8

* 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.

9

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

10

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.

11

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

12

--- "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.

13

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

14

--- "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.