Verio Decides what parts of the internet to drop

Fri Dec 3 07:30:20 UTC 1999

> Alex Rubenstein
> Sent: Thursday, December 02, 1999 3:03 PM
>
> Normally I agree with Randy (cough) but:
>
> On Thu, 2 Dec 1999, Randy Bush wrote:
>
> > > Apparently for their convenience Verio has decided what
> parts of the
> > > Internet I can get to.
> >
> > verio does not accept from peers announcements of prefixes
> in classic b
> > space longer than the allocations of the regional registries.
>
> Simply put, thats dumb. I can't imagine a technical reason
> for this (CPU
> and/or memory), so it must be politcal.

Nah, it's tradition.

> > we believe our customers and the internet as a whole will be less
> > inconvenienced by our not listening to sub-allocation
> prefixes than to have
> > major portions of the network down as has happened in the
> past.  some here
> > may remember the 129/8 disaster which took significant
> portions of the net
> > down for up to two days.
>
> I believe that if I have a customer who is multihomed between me and
> another provider, his punch-throughs to the
> non-address-space-providing
> provider should be heard. It's called 'global routability.'

I actually have this situation right now. MHSC Colorado offices are in
Colorado Springs, USWorst territory. Our CA offices are in the East SF Bay
Area (down the street from LLNL). Our own IP block is a /24, from our
upstream provider. Technically, we are multi-homed and have an ASN. However,
no one listens to it. This is not slam against Verio, since Sprint doesn't
listen to it either. They are only two of many that have such policies (as
we found out later). What we wound up doing is establish a SSH VPN between
our offices and the CO office uses our CA assigned IP numbers as NAT'd IP
behind a USWorst IP, using a USWorst connection. Outbound packets, to the
general Internet, go directly via the USWorst IP, but return packets come in
over the VPN from CA. Yeah, it sux.

It's a PITA and not the cleanest of methods, but until all the backbones
quit filtering /24s it's what we have to do. The other alternative (and
we've considered it) is to obtain a much larger space directly from ARIN and
burn the unused space. Then we could remove the last bit of static routing
and use BGP4 as we should.