Creative routing (was Re: Policy Statement ...)
smd at icp.net
Sat Jan 27 17:12:53 UTC 1996
Well, there's an alternate tactic for a tiny tiny company.
1/ Pick a provider from whom to acquire a tiny amount
of aggregatable address space.
2/ Choose a community attribute which you tag on your
prefixes. The easiest would probably be "no-export".
The ideal would be one meaning "export only to my
set of providers".
3/ router bgp X
neighbor ProviderX route-map set-community out
neighbor ProviderX send-community
neighbor ProviderX filter-list 1 out
ip as-path access-list 1 permit ^$
ip as-path access-list 1 deny .*
route-map set-community permit 10
set community <value>
4/ each provider, at each interchange
router bgp Y
neighbor PeerA route-map policy out
neighbor PeerA send-community
neighbor PeerB route-map policy out
neighbor PeerB send-community
neighbor AnotherPeer route-map other-policy out
route-map policy permit X
match community <value>
set community no-export
route-map other-policy deny X
match community <value>
5/ on ONLY the provider supplying addresses, configure at
(or very near) *each* interchange point this:
ip route CIDR-SUPERBLOCK MASK null0
router bgp M
network CIDR-SUPERBLOCK mask MASK
It's important that the route for CIDR-SUPERBLOCK never
fully vanish, or you lose connectivity to your non-providers.
Hence the provider you choose address-space from should have
a good record of knowing what it's doing and always having
at least one path by which to announce the CIDR-SUPERBLOCK
to the world. That's about the only big qualification.
There. Now you have fully redundant connectivity among all
your providers. Your address space is aggregated everywhere
except in your set of providers. Each of your providers
will carry at least two prefixes: the CIDR superblock
and the much longer end-site prefix.
Each provider advertises reachability for your prefix to
each of your other providers; however, the rest of the world
sees only the CIDR-SUPERBLOCK.
If a packet hits the router announcing the superblock and
that router has no route to the long prefix, it probably
will be hearing the more-specific announcements from at
least one of your other peers, and will hand traffic to them.
You can even play games with AS-path lengths on the
more-specific prefix in order to select which provider will
handle the bulk of traffic from the set of people at
interexchange points who are not your providers and
therefore not receiving the most-specific prefix.
And all sorts of other nifty hacks.
I bet it's even fairly easy for most providers to attach a
cost on all the activities needed to support this, so you
could end up proving Yakov's thoughts about the Push operation.
It won't be cheap. This is very-brain-and-slightly-CPU-intensive.
Dear small company needing a /28 and comparing itself to
Netscape: please forward my standard consulting fee (a pound
of good European chocolate) to my office address when you
have a moment.
More information about the NANOG