Curtis Villamizar <curtis@ans.net> writes:
A /24 in the so called "provider independent" space will be blocked by Sprint. That is what I mean be "unroutable".
Um, forgive me for being obtuse, but what's the so-called "provider independent" space, and where is the document that outlines its boundaries? Also, as noted before, the bulk of the long prefixes blocked by inbound filtering have been obvious mistakes, such as subnets in the presence of an aggregate, people forgetting to aggregate at all, and so forth. In each case the addresses were from what appears to be PA space, in that the blocks in question were allocated to providers, rather than end users, and were non-portable. The addresses may well have been "backbone-independent", however, as far as I understand things, that is not the same thing as "provider-independent". Other than that, I completely agree with you. Sean.
In message <xoilofdadid.fsf@chops.icp.net>, Sean Doran writes:
Curtis Villamizar <curtis@ans.net> writes:
A /24 in the so called "provider independent" space will be blocked by Sprint. That is what I mean be "unroutable".
Um, forgive me for being obtuse, but what's the so-called "provider independent" space, and where is the document that outlines its boundaries?
I think that's what RIPE calls a small allocation that goes directly to the regional registry rather than through the provider. I don't know offhand where it is first formally defined. The term is used in draft-hubbard-registry-guidelines-01.txt. For example page 11: 5. Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, major transit providers may need to impose certain restrictions to reduce the number of globally advertised routes. This may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from regional registry (provider-independent, also known as portable) are not guaranteed routable on the Internet. So I guess the term does have some precedent.
Also, as noted before, the bulk of the long prefixes blocked by inbound filtering have been obvious mistakes, such as subnets in the presence of an aggregate, people forgetting to aggregate at all, and so forth. In each case the addresses were from what appears to be PA space, in that the blocks in question were allocated to providers, rather than end users, and were non-portable.
We advertise a two intentional subnets in the presence of a large 207.24/14 aggregate. These are dual homed. One is a /24, the other a /22. Both are accepted by other providers but not Sprint. This is OK since we are primary and Sprint traffic will hit ANS due to the aggregate and get sent to the other provider if ANS doesn't have the more specific route, since we take the more specific from the other provider. There is just a suboptimal backup, but still backup.
The addresses may well have been "backbone-independent", however, as far as I understand things, that is not the same thing as "provider-independent".
And where is this defined?
Other than that, I completely agree with you.
Sean.
I agree that the majority of more specifics are mistakes. We use the IRR to separate out the inintentional mistakes (the redundancy in that statement was intentional:). This does protect us against the all too common case of too ignorant of CIDR to know better and registering the more specific in the IRR anyway (the intentional mistakes). Again, different approaches will yield different results. Curtis
Curtis,
I agree that the majority of more specifics are mistakes. We use the IRR to separate out the inintentional mistakes (the redundancy in that statement was intentional:). This does protect us against the all too common case of too ignorant of CIDR to know better and registering the more specific in the IRR anyway (the intentional mistakes).
Really? I would agree that the majority of more specifics are not in the IRR. This doesn't necessarilly mean they are mistakes. For instance we announce a pile of more specifics from other provider aggregates (intentionally, and with permission) where a customer is renumbering. These get filtered by Sprint (because they are too long prefixes), and by ANS (as they aren't in the IRR), but the idea is we propogate these more specifics as close as possible to the major networks as possible, so that as far as possible we aren't using the old providers transit to transit these routes (for several obvious reasons). We don't put advisories or more specifics in the IRR for several reasons, not least of which because this is a temporary arrangement, and sorting out changing guardianship of the RIPE objects etc. etc. with the old provider who is often slow to cooperate is simply not worth the hassle. So I have no problem with either ANS or Sprint's filters, just don't think *all* non-IRR entered more specifics are mistakes. Alex Bligh Xara Networks
In message <199608191828.TAA07038@diamond.xara.net>, "Alex.Bligh" writes:
Curtis,
I agree that the majority of more specifics are mistakes. We use the IRR to separate out the inintentional mistakes (the redundancy in that statement was intentional:). This does protect us against the all too common case of too ignorant of CIDR to know better and registering the more specific in the IRR anyway (the intentional mistakes).
Really? I would agree that the majority of more specifics are not in the IRR. This doesn't necessarilly mean they are mistakes. For instance we announce a pile of more specifics from other provider aggregates (intentionally, and with permission) where a customer is renumbering. These get filtered by Sprint (because they are too long prefixes), and by ANS (as they aren't in the IRR), but the idea is we propogate these more specifics as close as possible to the major networks as possible, so that as far as possible we aren't using the old providers transit to transit these routes (for several obvious reasons). We don't put advisories or more specifics in the IRR for several reasons, not least of which because this is a temporary arrangement, and sorting out changing guardianship of the RIPE objects etc. etc. with the old provider who is often slow to cooperate is simply not worth the hassle.
The mistakes that I was referring to is the more specifics that *are* in the IRR and are announced even though there is no good reason to announce them. If I look throught the routes we accept, there are quite a few long lists of contiguous /24s with identical ASpaths. Some of them have aggregates but perhaps the aggregator hasn't discovered "summary-only". BTW- wrt you second point. It's OK to keep the /24s in the IRR if you want a record for contact reference, but they should be marked withdrawn. Advisories are no longer used by ANS as of October 1995.
So I have no problem with either ANS or Sprint's filters, just don't think *all* non-IRR entered more specifics are mistakes.
Entering the aggregate an not the more specifics is OK. Sorry for not being clear. If you announce the more specifics we'll just accept the aggregate, which is also OK with us if the more specifics would not improve our connectivity at all.
Alex Bligh Xara Networks
Regards, Curtis
Curtis,
The mistakes that I was referring to is the more specifics that *are* in the IRR and are announced even though there is no good reason to announce them. If I look throught the routes we accept, there are quite a few long lists of contiguous /24s with identical ASpaths. Some of them have aggregates but perhaps the aggregator hasn't discovered "summary-only".
Ah. So this was the automation Sean was referring to - not accepting more specifics of routes with identical AS paths. telehouse1#conf t Enter configuration commands, one per line. End with CNTL/Z. telehouse1(config)#router bgp 5413 telehouse1(config-router)# neighbor x.x.x.x filter-list 199 in summary-only ... Pipedream? I think it would actually be implementatable. I see Paul F has managed to get himself on the CC list :-) Alex Bligh Xara Networks
Ah. So this was the automation Sean was referring to - not accepting more specifics of routes with identical AS paths.
telehouse1#conf t Enter configuration commands, one per line. End with CNTL/Z. telehouse1(config)#router bgp 5413 telehouse1(config-router)# neighbor x.x.x.x filter-list 199 in summary-only
... Pipedream? I think it would actually be implementatable. I see Paul F has managed to get himself on the CC list :-)
Alex Bligh Xara Networks
I thought of building configs to do that (assuming a filter-list xx in summ) but it's difficult to tell which sets of contiguous BGP announcements are being announced un-aggregated in an attempt to direct traffic one way or another... Without trying to start any religious fights, I would point out that a database of what things 'should' look like would be one way to store such information (about desired/required specificity). I'll update it this week, but look at http://routes.netaxs.com for a route-aggregation-suggestion tool that I built last year to see "how bad" the problem was - or, more specifically, how much space could be saved by taking compressing contiguous routes with the same next-hop (or head of the AS-Path list, pick which you prefer - they're 95% the same) at an exchange point. The page currently has data from April. Stuff in
= 207/8 is particularly ugly.
Avi
participants (4)
-
Alex.Bligh -
Avi Freedman -
Curtis Villamizar -
Sean Doran