- Test - lists.nanog.org

Re: Keepalives, WAS: NAP/ISP Saturation
by Vadim Antonov 21 Dec '96

21 Dec '96

Tony Li <tli(a)jnx.com> wrote: > No flap dampening, no > hold-down "blackholing" after a failure (so as not to generate > route withdrawals for transient link outages), silly priority > and no sub-second ping intervals, and forget about LQM). >None of these have anything to do with the link keepalive protocol and >everything to do with internal link implementation. Let's not confuse the >issue. Well, let us see: a) dampening -- it makes a lot of sense to flap-dampen at circuit level, where it is cheap and efficient; and not pass the flap to routing protocols where it is a lot more expensive to process. I.e. if a DS3 CSU lost its marbles, there's no reason to recompute some 20K routes dependent on that particular circuit every 60 or so seconds. b) blackholing -- if a circuit went down it makes sense to wait for some time (0.1 sec or so) and just drop traffic on the floor, in hope that the outage is transient. There's a lot of momentary carrier losses or other glitches in the telco transmission networks. Only when outage is prolonged does it make sense to notify the routing level. c) priority -- the link keepalive processes must have priorities _higher_ than that of routing protocols. I.e. no amount of routing updates should cause false link flapping due to delayed keepalive messages. The same is true for keepalive messages vs routing updates on a link. d) sub-second keepalive intervals -- this is probably the only method to discover _fast_ that remote end is dead. The way it is now it takes 30 sec or so for a local router to find out that the remote one is wedged, and take appropriate action. e) Link Quality Monitoring -- the usefulness is obvious. For most link-level failures there are sufficient advance warnings (corrupted checksums, etc). Also, there's a lot of things (like "stealth" rerouting by transmission fabric) which in some cases make circuit worse than a disconnected one. One particluar case i have in mind suddenly increased link latency by some 400 ms (Satellites-R-Us, that's it), so manual intervention was required to move traffic off the link. In any case, some automatic LQM shut-offs (on conditions like "latency is more than N ms" or "error frequency is higher than 1:10e6") are clearly in order. So i think the things i noted are rather relevant, and are necessary if we're going to build a real production network. I'm sorry if the link keepalive protocol digression confused the original discussion of security of the routing system. --vadim

2 1

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Vadim Antonov 21 Dec '96

21 Dec '96

Tony Li wrote: >So what's the $0.02 fix for eliminating the fate-sharing between routing >and payload that GGP got wrong? Did i say anything about eliminating fate-sharing? What i said is that routing updates should not be _routable_. That means that only parties directily connected to the physical medium can be originators of updates received from that medium. It is like ARP -- you can't do anything about it until you've broken into a directly connected machine, or evaded physical security. I.e. to produce DOS attack with ARP you need to mount a lot more destructive attack first. Actually, given the simple fact that a properly implemented link keepalive protocol provides adequate discovery of link and gateway failures, it is not clear that sending routing updates over the same physical medium as data has any intrinsic value. Similarly, there's no reason why medium cannot be shared between network control and user traffic, as long as network control is given unconditional priority. (And, no, practially all link keepalive protocol implementations are insane; cisco's a notorious example. No flap dampening, no hold-down "blackholing" after a failure (so as not to generate route withdrawals for transient link outages), silly priority and no sub-second ping intervals, and forget about LQM). --vadim

2 1

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 21 Dec '96

21 Dec '96

> Date: Fri, 20 Dec 1996 18:04:31 -0800 (PST) > From: Michael Dillon <michael(a)memra.com> > Subject: Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... > > ... You will win in court because it is > trivial to show that the packets came into your network from MCI ... I rather suspect that showing a court much of anything about packets is non-trivial. -tjs

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Vadim Antonov 21 Dec '96

21 Dec '96

Alex Bligh> Hmmm.. fragile world we live in. Paul Ferguson> That's what BGP peer authentication is for. :-) Ah. It's all one huge silliness. There is a $0.02 fix for the "routing security" problem -- use a logically separate network for exchanging routing and network monitoring information. That solution will be 100 years old next afternoon. Routing updates must _not_ be encapsulated in routable datagrams. That much, people who did GGP got right. (That breaks iBGP hack, of course, but that hack is a horrible kludge anyway, brought to us by silly IGPs which have no provisions for preserving exterior route information. Somehow no meaningful IGP work is done to fix that. Instead everybody is playing EiTeeEem and ReeSeeVeePeee and other kinds of cluelessness.) It does not make any sense to use any other authentication but the fact that there's a physical connection between boxes. If somebody can hack _that_, he can do so many other nasty things that routing security is hardly relevant. Internet is in a desperate need of sanity. The latest IETF convinced me there's not going to be any any time soon. It's a scary world we live in. --vadim

2 1

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Sanjay Dani 21 Dec '96

21 Dec '96

> The fact remains that a ping packet stream a Linux 386SX would barely > notice maxes out a 7010 (far more powerful CPU) > > Bzzzt. That's a 30Mhz 68040 you're talking about. You're 386SX is on par > if not ahead. And you might recall that it's handled at process level, > whereas Linux does it at kernel level (or at least other Unixen do). Considering the general trend in other markets towards cheaper, faster CPU's, I hope Cisco is working on router rev's with far more CPU and memory capacity at marginal price increase. I don't know how deeply the proprietary hardware is embedded in IOS. Of course, there may not be enough competitive pressure on Cisco to rev up their product line so quickly. While I'm at stating the obvious in armchair router design, how about the next 2500 series with a modest 100 MHz CPU and 32MB and so on for the 4xxx and 7xxx series? Sanjay.

6 13

Re: [Announce] traceroute sites
by ed＠tnix.net 20 Dec '96

20 Dec '96

"Bill Blue" <bblue(a)cts.com> wrote: >} Greetings, >} >} While we're on the subject, we've also recently added a traceroute page, >} this one includes some other goodies too. >} >} http://www.atmnet.net/Support/troubleshooting.html >} >} -Jay- > >And our bgp page is at nitrous.cts.com. While everybody is shamelessly promoting it's own traceroute page, I'll plug ours too.. http://www.cistron.nl/cistron/trace This page includes both traceroute and prtraceroute (includes AS numbers). -Ed -- Edvard Tuinder Cistron Internet Services Finger ed(a)cistron.nl for PGP key ``old unix hackers don't die, they just turn into zombie processes.''

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Paul Ferguson 20 Dec '96

20 Dec '96

At 10:07 PM 12/20/96 +0000, Alex.Bligh wrote: > >> > Indeed. For instance SYN-flood the BGP port. >> >> Won't work easily. >> On Criscos, the queue is per peer, not per port.. > >Spoof the source address to that of a peer. In fact I'd have thought >anything out of sequence would generate an RST and clear the session. > >Hmmm.. fragile world we live in. > That's what BGP peer authentication is for. :-) - paul

1 0

Re: [Announce] traceroute sites
by Bill Blue 20 Dec '96

20 Dec '96

} Greetings, } } While we're on the subject, we've also recently added a traceroute page, } this one includes some other goodies too. } } http://www.atmnet.net/Support/troubleshooting.html } } -Jay- And our bgp page is at nitrous.cts.com. --Bill Blue, CTSNET

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by William Allen Simpson 20 Dec '96

20 Dec '96

> From: Jim Van Baalen <vansax(a)atmnet.net> > I have a question that fits this topic. Why does everybody seem to be so > sold on Gigaswitch based Xchange points? A pretty good reason: it worked a lot better than everything else tried! As a bit of history, the only NAP that worked was with ethernet, which seemed a lot faster to most folks than the T1 links coming into the NAPs. But, the implementation was terribly flaky as a MAN technology. Then, ethernet got too congested, and folks moved to FDDI. Then, FDDI got congested and GigaSwitches were put in. They were the only thing available, and they made everything work better. My guess is that the next step will toss the LAN/MAN model for exchange GigaRouters directly connected by OC-3c/STM-1 and OC-12c/STM-4 WAN links -- but that's only a guess. It seems to be working. We are driven by things that actually work. > Based on membership and traffic it > appears that there is still a stigma associated with Xchanges (PBnap and AADS > for example) that have chosen different architectures. It was also my > impression that people were much more critical of these "other" NAPS at the > recent NANOG than SprintNAP and the MAEs. > That's because the ATM NAPs were started at the same time as MAE-East, but didn't work! They all took more than an extra year to get working. Oh, yeah, they cost a lot of money for some projects that really couldn't afford it, and it all went down the drain. Folks have a tendency to be critical of stuff with a history of failure. > In addition, > with new line cards due out early next year, the BPXs will support ABR and, > relatively speaking, huge buffers at high density OC3 and 2 port OC12. > Well, since they don't exist, why would anyone bank on deploying them? Let us know how well they work in a year or two. Meanwhile, PPP/SONET has been deployed for over 6 months at these speeds, and we are already getting experience with it. Yep, needs bigger buffers on those Ciscos, and PMC-Sierra didn't follow the SONET spec exactly, but ... experience is a much better teacher than promises. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 5

RE: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Chris A. Icide 20 Dec '96

20 Dec '96

>> And you don't find the 7500 a big jump over the 7000? >> What are you trying to do, IP tunnel your data through another backbone? > >Ok, yes they added some memory and it is faster, but they needed to put a >MUCH bigger CPU in that box. It was a jump, but not as big as the one we >all needed. The 7500 was not any new technology, just adding more of the >current. And no we are not tunneling through another backbone, we run our >backbone over Cascade 9000 with clear channel DS3s. Definitely, the 75XX is a jump over the 70XX router platform. However, it is very simple to collapse a 7513. The RSP2 does not have enough processing capability to allow economical use of the 11 available slots. We've been able to collapse several 7513's with less than half of the slots filled and heavy tuning by Cisco Engineers. Now, I am in no way, form, or manner an authoritative Cisco information source, however, I have heard some rumors which I place fairly strong reliability. 1. Cisco will be releasing a new RSP card soon (RSP4) which doubles the performance of the RSP2 2. You all know about the VIP cards along with 11.2 when all of the bugs are removed (especially those nasty memory leaks) 3. There has been a rumor that some level of load sharing between two RSP's will be available some time 2Q or 3Q '97 Again, these are but rumors I've heard. We've been spending a lot of our time lately playing with the Bay (Wellfleet) stuff, and they have some pretty neat stuff coming out (thanks to ANS, any comments, Curt?) 1. They are working on a 64M version of the ARE card (dual Power PC chips working in a full load share environment) 2. a 256M FRE3 card (dual Power PC's again) that they estimate would be completely able to support as many as 300 BGP peers with 45K route tables. 3. Channelized T3 interface, native IP over non-traditional IP media, etc. Again, mainly all rumors. Chris A. Icide Nap.Net, L.L.C.

2 1