North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: Verio Decides what parts of the internet to drop
> 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.