- NANOG - lists.nanog.org

Re: optimal web service (Re: BGP announcements and small providers )
by Paul A Vixie 26 Feb '97

26 Feb '97

> > My approach avoids the use of BGP, but not for the above stated reasons. As > > I said at the SF NANOG, it is hard to get transit providers to send a full > > BGP table, it is hard to accept it, and it would take a modified GateD that > > randomized destinations in order to keep BGP's path selection from leading > > 90% of your routes down 1/Nth of your transit providers. BGP was the wrong > > answer. > > Were the majority of your paths going down one single provider because > of a silly tie-breaker like the numeric value of the IP address of the > peer, Mostly. > or was it because that provider had a shorter AS path? If its > the latter, where's the problem? AS path elements are not indicators of path badness. a!b!c!d might be better than x!y!d depending on whether (a!b + b!c + c!d) < (x!y + y!d). Some of the links could be subrate T3s or SMDS or ATM whereas others could be FDDI or private multi-DS3 interconnects. BGP wasn't intended to be used this way, that's why it doesn't have an end to end connection quality / linkstate model. > If one provider has a better path > and you aren't out of bandwidth on the connection to that provider, > why would you want to take a different path? 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.

1 0

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

26 Feb '97

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. Justin Newton Network Architect Erol's Internet Services ISP/C Director at Large

11 14

Re: BGP announcements and small providers
by Lyndon Levesley 26 Feb '97

26 Feb '97

Stephen Sprunk wrote : |-> What about application protocols like ftp that specify network addresses in |-> the protocol session? Do you propose the NAT gateway alter FTP packets in |-> transit? |-> Yes, that is exactly what NAT does - it has a pool (or a static list, or both) of "Externally facing" IP addresses, and it alters the IP packets in realtime (in both directions, obviously) between "Externally facing" IP and "Internally facing" IP address, on a per-conversation basis. It then keeps a "cache" of what addresses have been dynamically mapped to what. The aggro used to be that for things like DNS/Mail/News etc. (almost any service machine) you have to keep the IP address the same and not dynamically change it. However, NAT boxes allow you to use dynamic mapping for your users and static for your other services. They also provide extremely good security - check out Cisco's PIX at : http://www.cisco.com/warp/public/751/pix/index.html which is basically a low spec PC in a rack-mountable box, that can happily perform NAT at 100Mb/sec. CPU-wise, NAT is not a hard thing to do, although you might end up needing a fair whack of memory on a box with *lots* of flows per second. The security features of the PIX are not a feature of NAT - they are a feature of the PIX, so you don't (I presume ;) get them on standard NAT boxes. |-> Also, I don't believe it will be possible to use host or user-based AH/ESP |-> with NAT, since they protect the source address. |-> Good point - TBH, I don't know how NATs deal/don't deal with ESP. Although the last time I looked, ESP had only been implemented with DES, and was therefore fatally flawed (there was a draft by Bellovin about this somewhere...) This is not an insurmountable problem - it can be solved either at the initial key exchange, or by the NAT in realtime, and will hopefully be / have been solved by one of the ipsec groups - I'll go and check out ESP again and see if NAT breaks it or not - I don't know much about it at the mo' |-> Stephen Sprunk |-> Cheers, Lyndon Levesley Xara Networks |-> At 17:34 26 02 97 +0000, Lyndon Levesley wrote: |-> > There's always the nice 'n' easy system of using 10/8 and NAT as a |-> >provider, making renumbering about 5 minutes work. |-> > |-> > Even taken to the extreme, it wouldn't take long to change your BGP |-> >announcements / have your provider change their BGP announcements / |-> >whatever. |-> > |-> > Nameservers are a bit harder to renumber, but that's not too bad. |-> > |-> > Wonder how long it'll be before ISPs rather than corporates start to |-> >use NAT for most of their network. |-> I've had a wonderful time... ...but this wasn't it.

1 0

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