December 1996 - Test - lists.nanog.org

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

21 Dec '96

William Allen Simpson <wsimpson(a)greendragon.com> wrote: >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? Because Morning Star is not cisco? (I'm well aware of PPP features, btw, having written one implementation myself :) --vadim

1 0

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

21 Dec '96

Tony Li <tli(a)jnx.com> wrote: > 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. >If you have strict priority of keepalives over routing (and we should >distinguish between hellos and updates for those protocols where you can >tell the difference), you can (theoretically) starve the routing updates. >Thus, equal priority makes sense. Well, keepalives cannot starve routing protocols, simply because they're pretty much rate-limited. A scenario when routing protocol starves keepalives is clearly disastrous -- you get spurious line flaps, which produce even more routing updates, and the network collapses. On the other hand, insufficient capacity to handle routing updates is ok, as it does not have that kind of positive feedback. The routing-level hellos are useful only to find out if the routing process is still running and/or resynchronize protocols. They are certainly too slow to handle regular link failures. (So there's a need to have a gateway-to-gateway keepalive protocol over shared media like Ethernet or another trendy madness). > 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. >Do you really want that? Given your comments in b, I would think that you >would want to ride a 1 second outage. I also wouldn't be thrilled about >the overhead involved given much more precision. Note that what you said >originally was about ping, which is slightly different. Well, a packet per line per, say, 200 msec is not much. OTOH, you want to avoid connectivity losses longer than 0.5-1 sec. To provide a reasonable redundancy you may want to wait for 2 missing keepalives in a row or so to decide that the link's down. I.e. hold-down interval determines maximal rate of link-status updates as seen from routing protocols; the keepalive intervals determine maximal delay between link failure and the reaction of the routing system. If sub-1sec recovery is the goal, and IGP convergence is on the order of 500 msec; that leaves only 500 msec for the keepalives, or 250 msec keepalive interval. It would also be a good idea to wait for, say, 20 consequtive good keepalives to decide that the link is up. Cisco is getting the line up at the very first good keepalive (at least it appears so). --vadim

1 0

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 20 Dec '96

20 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 20 Dec '96

20 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 20 Dec '96

20 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