- NANOG - lists.nanog.org

Re: Keepalives, WAS: NAP/ISP Saturation
by William Allen Simpson 21 Dec '96

21 Dec '96

I think this is a great idea. Of course, almost everything listed here is already done with PPP LQM.... > From: Vadim Antonov <avg(a)pluris.com> > a) dampening > PPP LQM does not specify any particular dampening algorithm, but gives a simple N of M example. > b) blackholing > PPP LQM allows you to send LQRs at some periodicity, and the interval for two (2) round trips of these packets determines your blackholing time. Of course, there is the issue of how you handle Loss of Signal, and other such hardware indications that the link is down. Probably should follow the 2 RTT rule. That's what my dialer code (in a fair number of low end boxes) does for modem links.... > c) priority > At least in _my_ implementation, _all_ PPP control packets are sent at the highest priority. > d) sub-second keepalive intervals > Yes, Craig Fox, then at Network Systems (now at Cisco) wanted very high rates for their T3 LQRs, even 4 years ago, thinking ahead. You might want to thank him. We settled on hundredths of seconds, matching the only thing supported by SNMP at the time. Good enough? > e) Link Quality Monitoring -- the usefulness is obvious. Yes. > 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. Now this is a good idea that we didn't think of. There is no time field for measure of link latency. But, it could be accomplished, by configuring _only_ one end to send the LQRs. In that mode, sending an LQR will cause one to echo, and you could measure the interval. So, since we designed PPP LQM for the 56K, T1 and (new) T3s of 5-6 years ago (at least a generation in Internet lifetimes), why isn't everyone already running it? 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

1 0

International carriers
by Sang Kim 21 Dec '96

21 Dec '96

I am not sure if this is the right place to post a question. My question is the following: Is there a legal implication for foreign carriers to become a facility based ISP in the U.S.? If FCC allows them to do so, is there a list of these carriers and ISP names along with URLs in the Internet? Your input is appreciated, SK

1 0

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