- Test - lists.nanog.org

Re: BGP announcements and small providers
by Justin W. Newton 26 Feb '97

26 Feb '97

At 06:17 PM 2/25/97 -0700, Chris Phillips wrote: >We service hundreds of dedicated customers and some customers don't mind >renumbering (if they are small) but most of our larger customers who have >more than 100-200 hosts on their network have expressed GREAT opposition to >any such notion of renumbering. Its not that they don't want to do it >because they are lazy, on the contrary, many companies cannot the afford the >downtime or cost asociated with renumbering their LAN/WAN. Interesting, I have been able to renumber my networks with NO downtime, and I am relatively certain that they could as well with proper planning. The caveat being that there may be problems with software packages which are depndant on the IP address of the machine they are run on (which is possibly the stupidest copy protection I have ever heard of). >I agree that >renumbering is an important aspect of address grooming for better agregation >but there are some real $$$ costs to some end-user networks to do so. There are some very real costs to end user networks, as there are to provider networks, I don't question that, and understand it all to well. >Also, >how many times can you ask a customer to renumber before they bail and go >elsewhere? I don't plan to ask mine to do it more than once (and yes, I am going to ask a large portion of my customers to renumber once). I was in my upstreams space, and am now renumbering out of it. I will likely lose a few customers over this, but its a price I am willing to pay to have less dependance on my upstream, and also bring my number of announcements from around 11 to 2. Justin Newton Network Architect Erol's Internet Services ISP/C Director at Large

1 0

Re: BGP announcements and small providers
by Paul Ferguson 26 Feb '97

26 Feb '97

This is not a practical expectation. If done on a wide-scale basis, the whole concept of route aggregation is for naught. I would suggest tyhat you read: RFC2008, "Implications of Various Address Allocation Policies for Internet Routing", http://www.internic.net/rfc/rfc2008.txt - paul At 12:08 PM 2/26/97 +0000, Sean Rolinson wrote: >Agreed. > >And it is my opinion that upstream providers should allow (or be >required) portability of assigned IP addresses. Naturally, there are >some logistics that need to be dealt with, but if someone is BGP >peering, it pretty much boils down to an announcement change, >correct? > >We, as a provider, would not mind paying some nominal fee (cheap!) >to our upstream provider for continued use of IP addresses after we >have terminated our service. We have even considered getting the >smallest possible connection to that particular provider just to be >able to continually use their IP addresses. This does not seem like >a very effective alternative for us or our upstream provider. > >I am wondering what impact, if any, would requiring portability of >IP addresses under certain criteria (BGP peering, etc) have on the >Internet? >

1 0

Re: optimal web service (Re: BGP announcements and small providers )
by Joseph C. Pistritto 26 Feb '97

26 Feb '97

> >Defining "better" when all you have to work with is BGP, is pretty hard. It >turns out that, as in DNS, round robin is better than any definable static >ordering. > You can say that again! Actually, one of the critical performance criteria for our network is how fast we can get rid of packets going to end users, so path "goodness" is pretty serious issue for us. I sure wish there were some way (better than BGP I mean) for routing packets in a multi-homed environment. However the technique we use is twofold: 1) we've built into our product the ability to load balance on a failure (or a really bad delay situation), away from a serious problem either in a server, or conceivably in the path. This happens under the covers and we're only dimly aware of it, unless there's a big problem somewhere. The usual reason this occurs is a reachability problem through one ISP or another, or running out of bandwidth into an ISP. 2) we observe the gross characteristics of our ISPs as seen from our end, and "push" more traffic towards networks with better delay and reliability characteristics. Unfortunately, this is a somewhat manual process. We are looking for "more automatic" ways of doing this, if people know of pointers to good "network quality measurement" stuff, point me at 'em. Our ISPs seem to do a fair to reasonable job of preventing their networks from cracking up, however we often can take load off an ISP while they fix a problem that crops up in their network (and usually do to improve quality of service to our end users, if we have the bandwidth to spare). I'd love to know if there are other multihomed sites out there that have successfully gotten full BGP information from multiple providers and used it to balance outgoing load, and had positive experiences as a result. Given all the problems of using BGP for this purpose (for which it really wasn't designed), we've wondered how hard we should push our providers to do this. (Some will, some won't, although I suspect we could get them all to if we really wanted). Best regards, -jcp-

3 2

Cisco and LA Times
by Hank Nussbacher 26 Feb '97

26 Feb '97

Cisco's Shift in Focus May Well Have Cost It Its Vision http://www.latimes.com/HOME/NEWS/CUTTING/t000017227.html Hi Tony! :-) Hank Nussbacher

1 0

Re: Thanks for your help
by Sean Donelan 26 Feb '97

26 Feb '97

>Several of you responded earlier today with information that was helpful in >resolving the problem of a bad route to one of our networks being propagated. > >So, collected gurus of the net, how do we keep this from happening again? Its called MAD, Mutual Assured Destruction. Even if we discount deliberate sabotoge, mistakes happen. By their nature, mistakes by large providers are more spectacular. But the reality is providers of all sizes are one typo away from the dreaded routing blackhole. People can use things like route registeries to match and filter routes against the registered information. It doesn't really solve the problem, just moves it to a different place. People can still register annoying route objects, i.e. the universal default route, and trash connectivity for hours. Its tough to tie particular networks back to valid AS origins since they are allocated/assigned independently. Worse, if a provider doesn't tell the rest of us what the valid network/AS combinations are, how will we ever know when someone announces an invalid network/AS combination. He who lives by the ANY will one day die by the ANY. I guess that is what the telephone is for. But when someone blackholes 198.41.0, I hope you have the phone numbers memorized. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: demon.co.uk spam policies? [sorry if off-topic]
by Ehud Gavron 26 Feb '97

26 Feb '97

From: Scott Call <scall(a)ccnet.com> >Subject: demon.co.uk spam policies? [sorry if off-topic] >... >In light of the recent spam/nospam discussions on the list, I thought >I'd share something one of my customers got with the rest of you: > > >>From info(a)senora.demon.co.uk Fri Feb 21 17:29:07 1997 >Received: from home.glasscity.net (home.glasscity.net [208.13.0.1]) by 208.13.0.0/24 is on Vixie's Blackhole list. I know my customers aren't going to be receiving this sort of harassment. Ehud ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id RAA05294; Fri, 21 Feb 1997 17:29:06 -0800 (PST) From: info(a)senora.demon.co.uk Received: from home.glasscity.net (194.72.198.24) by home.glasscity.net (EMWAC SMTPRS 0.81) with SMTP id <B0000772250(a)home.glasscity.net>; Fri, 21 Feb 1997 20:28:01 -0500 Date: Fri, 21 Feb 1997 20:28:01 -0500 Message-ID: <B0000772250(a)home.glasscity.net> Subject: Dear spam hater. X-UIDL: 23485792837498720384760912734067 Priority: normal X-Flags: PXU2-4R65-2264:R Apparently-To: <anon(a)anon.net> X-Status: Status: RO HA HA HA HA You are on a published list of peolple who hate commercial mail! How STUPID can you get! Commercial email is just taking off - and I'm going to distribute this list everywhere I can to shut you whining people with nothing better to do than complain up! It's BASTARDS like you who got me shut down last time - but demon won't touch me! HA HA HA! I can go thru DIFFERENT servers! ANYTIME........... Alan -- Alan K Baker (MailWurliTzer Willy) www.senora.demon.co.uk alan(a)senora.demon.co.uk -- ___ / ~-. Scott Call | \ TCP/IP Network Administrator/Holder of Past Knowledge \\j`j; / , CCnet, Inc http://www.ccnet.com/ (^, )bxr~ Walnut Creek, CA ---' http://www.devolution.com/ 46. Outrageous vehicles only make the hero cooler. 101. Mallets can be stored anywhere on anybody. -All I Need to Know I Learned From Anime --Boundary_[ID_yl2sh+mR3ABtx3znZG6+4g]--

1 0

Re: BGP announcements and small providers
by sob＠academ.com 26 Feb '97

26 Feb '97

I would expect this to be on the NANOG notes page when I get that part done. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: BGP announcements and small providers
by Chris Phillips 26 Feb '97

26 Feb '97

At 02:51 PM 2/25/97 -0500, you wrote: >At 10:50 AM 2/25/97 -0500, Paul Ferguson wrote: >>Well, without naming names, the prefix-length based filtering is >>done on non-customer routes. A byproduct of this is it grudgingly >>encourages aggregation. > >Well, yes, but now that multiple providers are doing this the fact that >they are non-customer filters affects anyone who is not a customer of BOTH >providers, thus further encouraging people to aggregate. I would not mind >seeing these filters become more prevalent, making it unreasonable for >people to become customers of everyone who filters to get around the >filters. Renumbering is NOT that hard folks, and it DOES help. > We service hundreds of dedicated customers and some customers don't mind renumbering (if they are small) but most of our larger customers who have more than 100-200 hosts on their network have expressed GREAT opposition to any such notion of renumbering. Its not that they don't want to do it because they are lazy, on the contrary, many companies cannot the afford the downtime or cost asociated with renumbering their LAN/WAN. I agree that renumbering is an important aspect of address grooming for better agregation but there are some real $$$ costs to some end-user networks to do so. Also, how many times can you ask a customer to renumber before they bail and go elsewhere? -- Christopher K. Phillips Chief Technical Officer Rocky Mountain Internet, Inc ckp(a)rmi.net 303.672.0799 http://www.rmi.net

1 0

Thanks for your help
by Joseph C. Pistritto 26 Feb '97

26 Feb '97

Several of you responded earlier today with information that was helpful in resolving the problem of a bad route to one of our networks being propagated. So, collected gurus of the net, how do we keep this from happening again? We can wire down the route at the ISPs we take service from (and do), but what keeps some random person from propagating bad routes into the system and blowing away your network by accident? Surely there has been some thought given to this problem. I'm convinced today's incident wasn't malicious (at least until proven otherwise), but you can see the potential here. -jcp-

2 1

Re: Finding out where a bogus route is coming from?
by Dave Curado 25 Feb '97

25 Feb '97

> Any hints on how to do this? > > We have a situation where some person has broadcast a route which is > mapping one of our subnets to the wrong place. > I'm trying to track this at the Mae's to find out what's going on, but I'm > really interested in figuring out how > one can prevent this sort of thing or find out the original source of the > bad route. Resolving the issue should be straight forward: - traceroute to something on that subnet from a few places (see http://www.boardwatch.com/isp/trace.htm amongst others) - get a phone number for the noc or whatever of the org that announcing your routes, (try whois, or possibly their web page... (whatever, get creative)) - give them a call and explain the situation, open a ticket if they have a ticketing system, and move forward from there You may have to convince them that the problem exists, by forwarding on traceroute info or whatever. Hopefully their noc staff will be helpful, reasonable, and clueful. I have no suggestions for how to prevent this problem from occurring. Hope this helps, davec

1 0