Mailing List Archive

Well, there's an alternate tactic for a tiny tiny company.

MCI Sprint
| /
The Site-----BBN
/ \
Alternet ANS

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.

Sean.

>Well, there's an alternate tactic for a tiny tiny company.

I was thinking of a slightly simplier example. Nevertheless,
Mr. Doran's example confirms NSP engineers are capable of all
sorts of routing hacks when it is in their self-interest to do so.
Even if it means introducing a /32 into their network.

--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Affiliation given for identification not representation

......... Sean Donelan is rumored to have said:
] >Well, there's an alternate tactic for a tiny tiny company.
]
] I was thinking of a slightly simplier example. Nevertheless,
] Mr. Doran's example confirms NSP engineers are capable of all
] sorts of routing hacks when it is in their self-interest to do so.

Exactly. So let's forget there ever was such a thing as A/B/C
networks and enforce classlessness. Couple this w/ responsibility
originating from the big NSP players on enforcing prefix lengths,
and *whoah* look what the world can figure out to do.

"Golly, thar Martha, once them folks up in Reston said I had to
renumber, well shucks, it warnt quite as hard as I thunk."

-alan