Customer AS

Mon Aug 19 22:31:31 UTC 1996

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 www.cisco.com 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? :)

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

--vadim

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