> The advantage gained is questionable. If my link to the provider that
> the space comes from goes down, they are still announcing and I'll only
> be able to reach where my path via the alternate provider is shorter
> than the path to the down provider itself.Ummm...why would your provider be announcing your routes if your link to
them is down? Sure, they will still be announcing the aggregate that
contains your prefix, but the most specific route always wins (barring
policy that prevents it from winning).
Statically coded route? They have a /19 (or shorter) and it is all chopped
up (and perhaps filled up) with customers using small networks (/20 or
longer prefixes). They do the announcing. What would change if I want
to do my own and I am a /20 in there?
> If the provider were to be convinced to stop announcing for my /20,
Generally a good way to convince your provider to stop announcing your
routes is to stop announcing your routes to them.
But that isn't just automatic, surely. Don't they have to remove the
statements from the configuration of the router that originates the
announcements?
> then I'm going to get filtered at Sprint and AGIS and whoever else
> is doing this and there won't be any /19 announcement that I can use
> a default path on.Providers ALWAYS announce their aggregates. If your provider is flapping
their aggregates based on the state of downstream customers, you need to
identify your provider here so they can be beat on in public.
I'm not expecting their routes to flap based on downstream. I am trying
to figure out if they will announce their /19 regardless. But I have
determined this is not an issue as long as more specific routes take
precendence over fewer hops. Next concern is making sure my more specific
route really gets through the provider that also announces the aggregate.
That could depend on provider policy.
> But the real catch here is that for the provider to stop announcing
> my /20 they have to split their /19 into two /20's. And if that was
> really a /18 that means they will be announcing a /19 and a /20 where
> before only a /18. This gets worse the larger their block was.This doesn't make any sense. I think you are forgetting that the most
specific always wins.
Someone said always. Someone else said usually. Does the RFC say always?
> This needs to be simpler.
It is not as complicated as you think. Announce the space that you have
been allocated to all of your providers. Ensure your providers let your
announcements out of their networks.
There is a list of providers (perhaps incomplete) that block longer
networks. Is there a list of providers that block from their customers
or is it safe to assume every provider has no problem with this?
I did mention before in another posting that these are extra routes that
would not have to be here were it not for some provider filtering out
long networks. Funny how trying to reduce routes on their own networks
gives them less of the advantage expected and imposes more burden on
everyone else.
The only time you may have a problem is if your link to the provider that
allocated you the space goes down. Then you have to hope that that
provider will allow more specifics of their aggregates to be announced to
them by peers. If they don't allow this, pressure them to. You also have
to hope that the path between the provider that allocated your addresses
and your other provider does not cross a provider that filters at /19.
Ideally the two are peering with each other.
Suppose my link to them is down. Suppose they do allow the more specific
routes to come in via peers. Now also suppose that some branch of their
network has to go through the origin of the block I am in, such as others
in the same locality whose links have not gone down (e.g. my circuit got
backhoed or something). Will the routes even go through the originating
router?