Customer AS

Randy Bush wrote:

In my (rather extensive) practice, multihoming by itself is
usually a major source of connectivity problems.

in my meager and bottom-feeding scum-sucking practice, multi-homing
decreased unreliability delivered to our customers by a factor of ten
or more.

Right. If you know what you're doing and have resources to
manage it. PSG/TLG/RainNet is what? Probably the largest
regional in Northwest. Nobody argues about benefits of
multihoming for providers like that (and you have enough customers
to maintain significant level of aggregation, too).
The problem is that basement operators are multi-homing, too.

this very moment i am sitting at a site which is single-homed to an
anonymous NSP's major POP in a farming town in mid-Cal. i can not get
to from here. yet i can get to my home net, which is
quite multi-homed, and get to cisco from there.

so, as we say in my family, i smell cows.

See advice below.

It is _much_ better to multihome to the same provider who then
can take care of messy global routing.

just what i always wanted, two connections to a broken provider. you
must be kidding.

Pick a provider which is not broken. None of them will help you
agaist a clueless idiot injecting /24s covering your nameservers,
though (don't feed me the RA -- as long as dominant routers can't
do the massive filtering on their own it is close to useless).

AUTH_CERTIFICATE attribute anyone? :slight_smile:

It may make sense to restrict multihoming to those who can aggregate
their routes to, say, no less than /17s.


PS There is a proof by existance that reliable operation w/o
   customer multihoming is possible. It is called POTS.