In the referenced message, Roy said:
Two bad experiences for me:
1) Their BGP polices are not as good as others. They force you to register
each route you want to advertise rather than allowing you to advertise any
reasonable route for your prefixes. According to one of their top people,
prefix-lists were unreliable new technology. We gave up and canceled the
circuit.
How is registering the routes you are going to announce a bad thing?
Registering is not "bad", its just not beneficial. Given that the routes I want
to announce are within my assigned range, why is it a good thing to register
them? If the transit provider always add entries when I ask for them, it seems
to be very little benefit..
This is the case of transit so I am a customer paying money for a service. I
started this subthread because I felt others would want to know about this. I
made the mistake of buying transit service without asking about their BGP
policies. I was hoping to help by sharing my experience.
Stephen Griffin wrote:
have you asked them to add entries for prefixes that don't "belong" to you?
Adi
The simple reasons is some people (or their buggy router) deaggregated
multiple Class B's or A's and broke some upstream providers. You can
blame whomever you want, but registration gives the user a chance to
notice a typo resulted in 65,535 routes before actually announcing all
those routes. No, it doesn't stop a malcious router engineering. But
it is a nice "defense in depth" or "speed bumb" for dumb mistake(tm)
prevention.
There are certainly reasonable and unreasonable cases one can imagine.
Someone with a single /20 who wants to be able to advertise /24s or larger
from within his block is (probably) a reasonable request. Someone with a /16
who wants to be able to advertise down to /32s within his block is
unreasonable, especially if he expects his provider to advertise these routes
to its peers/providers.
One common need for advertising small routes within large blocks is dealing
with dos attacks. If you have, say, 4 100Mbps circuits, and 1.2.3.4 is being
DOSed, you can advertise nothing but 1.2.3.4/32 on one of the circuits and
the DOS is now clamped at 100Mbps and everything else will be fine. However,
it's hard to work out in advance how not to propogate the route outside the
appropriate scope and how to do this without special arrangements for that
particular IP while still not allowing every customer you have to advertise
/32s for every IP they own.
The moral is, negotiate a reasonable BGP policy before you pay/sign. Make
sure what seems reasonable to you also seems reasonable to your (prospective)
provider.
DS
On the leaking more specific routes topic (ip prefix lists):
I've verified that Above.Net lets me do this and Genuity does not.
But Genuity has said, today, that they are working on doing it.
To address Sean's point about mistakes turning one /16 into a zillion
entries, is there any way to allow only some specified maximum number
of routes from a bgp neighbor? I know that I'ld be happy if my
upstreams gave me a buffer of, say, 10 entries above my typical number
of aggregates.
-mark
In a message written on Fri, Apr 12, 2002 at 05:27:50PM -0700, Mark Kent wrote:
To address Sean's point about mistakes turning one /16 into a zillion
entries, is there any way to allow only some specified maximum number
of routes from a bgp neighbor? I know that I'ld be happy if my
upstreams gave me a buffer of, say, 10 entries above my typical number
of aggregates.
I'll bite, as I have this conversation with people from time to
time. There are two things you can (easily) do with transit
customers (wrt prefixes):
1) Limit them to specific prefixes up to a limited length.
2) Limit the number of prefixes.
My take on the "right" thing to do is:
1) Allow any netblock the customer "owns"*, up to /24.
2) Use a default prefix limit of 50, or 2 times the number of
prefixes the customer owns, whichever is greater.
As a service provider, you don't want to spend a lot of cycles
updating prefix lists. The providers that do exact match only I
think are doing a lot of work for nothing, as they are doing a lot
of updates for very little gain. On the other hand, you can't let
customers have unfiltered access. The absolute limits are similar.
You don't want to reconfigure your device hourly, but updating it
every 10 years isn't good either.
So, I think customers should be allowed to go up to a /24 by default.
50 extra routes is no big deal for any transit free provider, even
from a few customers. For larger customers, that's not enough
headroom, but if the customer is that large some clue is assumed,
and so a limit of 2x the registered (eg supernet) prefixes is
probably fine. I would allow a customer a higher limit if they
can demonstrate a good reason.
What do you find reasonable, and more importantly, why do you find
it reasonable?
Mark Kent wrote:
On the leaking more specific routes topic (ip prefix lists):
I've verified that Above.Net lets me do this and Genuity does not.
But Genuity has said, today, that they are working on doing it.To address Sean's point about mistakes turning one /16 into a zillion
entries, is there any way to allow only some specified maximum number
of routes from a bgp neighbor? I know that I'ld be happy if my
upstreams gave me a buffer of, say, 10 entries above my typical number
of aggregates.
Yes there is - neighbor <x> maximum-prefix <number> <warn-pct>
We use it in conjuntion with exact filters, "just in case" someone makes
a mistake on a filter. As well as using it on peers who we know should
be advertising, say, 4000 routes - we'd limit them to 5000, because if
they grow any more than that we want to know anyway :-))
The annoyance is there's no way to block on your side a known upstream
or peer limit, and if you exceed the limit your upstream or peer needs
to do a manual reset.
What many desire is a matching (presumably configured slightly lower)
neighbor <x> maximum-prefix-sent <number> <warn-pct> [limit|shutdown]
to be able to prevent exceeding the limit and reset or restrict prefixes
on your side, so you can fix the problem without having to contact all
your peers and upstreams if something does go majorly wrong.
David.
One common need for advertising small routes within large blocks
is dealing with dos attacks. If you have, say, 4 100Mbps circuits, and
1.2.3.4 is being DOSed, you can advertise nothing but 1.2.3.4/32 on one
of the circuits and the DOS is now clamped at 100Mbps and everything
else will be fine. However, it's hard to work out in advance how not to
propogate the route outside the appropriate scope and how to do this
without special arrangements for that particular IP while still not
allowing every customer you have to advertise /32s for every IP they
own.
Most providers have a community tag structure of some kind, where you can
influence things like localpref and where your route is exported to. One
of the ones people are finally starting to add is the blackhole community.
If a customer sends you a route with a certain community tag, set next-hop
to some specific IP which you route to null0 on all routers, and of
course set no-export.
You could even link this into an automated backscatter analysis system, so
that if a customer is under attack from random source IPs and they
announce a blackhole route for the IP(s) being attacked, you can have an
automated system open a ticket with the attacking interfaces without
having to spend XX minutes getting a qualified engineer on the phone.
The moral is, negotiate a reasonable BGP policy before you
pay/sign. Make sure what seems reasonable to you also seems reasonable
to your (prospective) provider.
I think "most" providers have very ill defined BGP policies. Some
providers use routing registries and tell you you're lucky if you get
network change done within 24 hours. Some providers make you email them,
and have a warm body "engineer" who knows just enough to type in the
prefix lists, usually with typos. Some providers can support "/16 le 24"
and some can't (and some can but neglected to tell their NOC). And then
there is some definition of "big enough" at which most providers get tired
of maintaining your filters (and assume you have enough clue to not mess
up), and just remove them. Most make no guarantees of when they'll get
around to taking care of filter changes, and if that's a problem well
that's your fault because you should have planned your network changes
better. If you have time on your hands and want to see the full range of
policies in action from all the different transit providers, try becoming
an InterNAP customer. 
Lets face it, most providers don't want their customers running BGP at
all. It's more work for them, and more chances for you to break something.
Infact in all statistical likelihood you probably read about it in a book
and thought it was cool, and are in no way qualified to be using it
anyways. When was the last time you saw a good document on how to setup
routing registry stuff being distributed from an ISP to it's customers,
that didn't contain "go read these RFC's and don't bother us"? Personally
I find it distasteful that in order to be a "good net-citizen" every ISP
needs to have a bunch of warm bodies or a perl monkey writing scripts to
muck with router configs, just to keep a "dynamic" routing protocol from
being "too dynamic". But I guess life isn't perfect.
## On 2002-04-12 17:27 -0700 Mark Kent typed:
To address Sean's point about mistakes turning one /16 into a zillion
entries, is there any way to allow only some specified maximum number
of routes from a bgp neighbor? I know that I'ld be happy if my
upstreams gave me a buffer of, say, 10 entries above my typical number
of aggregates.-mark
For Cisco IOS just add this under the "router bgp" section
For Cisco IOS just add this under the "router bgp" section
Here is the way that you use to do the same in JunOS.
http://www.juniper.net/techpubs/software/junos51/swconfig51-routing/html/bgp-summary33.html
They introduced a cool feature (idle-timeout).
"If you include the idle-timeout statement, the session is torn down for a specified amount of time,
or forever. If you specify a period of time, the session is allowed to reestablish after this timeout
period. If you specify forever, the session will be reestablished only after you
intervene with a clear bgp neighbor command"
German