Curtis,
Not sure what you mean here concerning 'unroutable' prefixes, but the
issue with obtaining an allocation for one of the upstream provider's
CIDR block when multihomed *does* have its drawbacks, at least from
the end-user perspective. If said prefix (let's say a /24) is announced
in the 'allocating' provider's aggregate, and the more specific is
announced via the 'other' provider, the more specific will always be
preferred.
Of course, you can play a few tricks (AS_PATH prepend, etc.), but this
situation introduces unique problems.
In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates
that this is one of the few acceptable instances when allocation can be
done by one of the various registries and not by (one of) the upstream
service provider(s). I think this is a contributing factor to the overall
growth of the global routing table(s), but this is an issue we need to
deal with. From an operational perspective, I'd opt for using a prefix
which was not allocated from either/any upstream provider. From a global
perspective, this contributes to route bloat. :-/
- paul
Not sure what you mean here concerning 'unroutable' prefixes, but the
issue with obtaining an allocation for one of the upstream provider's
CIDR block when multihomed *does* have its drawbacks, at least from
the end-user perspective. If said prefix (let's say a /24) is announced
in the 'allocating' provider's aggregate, and the more specific is
announced via the 'other' provider, the more specific will always be
preferred.
This is brain damaged. Given
AS1 ----- Sprint
>
>
>
>
AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note
the 'extra' AS hop) because Sprint aggregates your announcement and the
longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have
discovered suppress-map.
randy
Randy Bush writes:
Not sure what you mean here concerning 'unroutable' prefixes, but the
issue with obtaining an allocation for one of the upstream provider's
CIDR block when multihomed *does* have its drawbacks, at least from
the end-user perspective. If said prefix (let's say a /24) is announced
in the 'allocating' provider's aggregate, and the more specific is
announced via the 'other' provider, the more specific will always be
preferred.
This is brain damaged. Given
AS1 ----- Sprint
>
>
>
>
AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note
the 'extra' AS hop) because Sprint aggregates your announcement and the
longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have
discovered suppress-map.
This is mainly due to the fact that Sprint does not listen to any
announcements from its peers for anything within its "non-portable"
blocks. Multihoming and expecting fallback to work are two different
things I guess. Let's not even mention the AS path length stuff.
BTW, Sprint also does not listen to any of its peers ASes through
other peers so peering with Sprint and still paying someone for
transit services do not help you get more redundancy with Sprint's
network.
-Hank
Hi Hank,
Not sure what you mean here concerning 'unroutable' prefixes, but the
issue with obtaining an allocation for one of the upstream provider's
CIDR block when multihomed *does* have its drawbacks, at least from
the end-user perspective. If said prefix (let's say a /24) is announced
in the 'allocating' provider's aggregate, and the more specific is
announced via the 'other' provider, the more specific will always be
preferred.
This is brain damaged. Given
AS1 ----- Sprint
>
>
>
>
AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback
(note the 'extra' AS hop) because Sprint aggregates your announcement
and the longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers
have discovered suppress-map.
This is mainly due to the fact that Sprint does not listen to any
announcements from its peers for anything within its "non-portable"
blocks.
What?!? I.e. if a Sprint customer C is multi-homed and their Sprint line
goes down, traffic to C from other Sprint customers will not be able to
reach C?
BTW, Sprint also does not listen to any of its peers ASes through
other peers so peering with Sprint and still paying someone for
transit services do not help you get more redundancy with Sprint's
network.
And this is considered good networking architecture? Jeezus!
randy