- NANOG - lists.nanog.org

ANNOUNCEMENT: NANOG Registration
by William B. Norton 24 Dec '96

24 Dec '96

Hi all - The NANOG 9 (Feb 97) Registration form is on-line today (www.nanog.org) More information about the hotel, local logistics, and initial agenda will be put up on the web in January. Merry Christmas! Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

cisco-nsp mailing list
by dave o'leary 23 Dec '96

23 Dec '96

Dorian Kim and his associates at CICnet have been gracious enough to create and host a list for discussion of cisco equipment, services, etc. as we relate to the service provider market. This list is intended to be much like the cisco(a)spot.colorado.edu list, except focused on service providers. This should help remove some of the cisco-specific chatter from the NANOG list (at least it provides a convenient place to redirect it which is potentially more appropriate). Here is the charter that we (actually Paul Ferguson) came up with: The cisco-nsp mailing list provides a forum for Internet Service Providers to discuss issues specific to cisco Systems product line implementations, both hardware and software related. While this list is not an official support vehicle of cisco Systems, Inc., both general and specific discussions are encouraged. Support issues should be directed at the usual support channels (cisco Technical Assistance Center, etc.) Subscriptions are via majordomo to cic.net, i.e. send mail to <Majordomo(a)cic.net> with the following command in the body of your email message: subscribe cisco-nsp <your email address> Alternatively, you can send to <cisco-nsp-request(a)cic.net>: with the command "subscribe" in the body of the message. thanks, dave

2 1

APRICOT '97
by David R. Conrad 23 Dec '96

23 Dec '96

Hi, Apologies if inappropriate and if you've seen this before (but quite a few NANOG people indicated they wanted to attend, so...) -- The Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT, http://www.apricot.net) is a conference and series of tutorials targetted primarily at people who run (or want to run) large networks, particularly Internet Service Providers. This year, there are 13 tutorials ranging from DNS to Perl Programming and a 3 track conference consisting of 2 two day tracks on network operations and services & applications, and 2 one day tracks, one on legal and policy issues in cooperation with the Asia Pacific Policy and Legal (APPLe) Forum and the other, the Business of the Internet, in cooperation with the Asia Pacific Internet Association (APIA). For more information on the conference program and the tutorials, see http://www.apricot.net/program.html. To register for the conference, see the APRICOT registration page at http://www.apricot.net/registration.html (note that the web page uses SSL for secure transfers so you can safely send your credit card numbers over the Internet). If you do not have access to the web, please contact me and I'll send or fax an email form. Dates: APRICOT Tutorials: Jan 27 - 28 APRICOT Conference: Jan 29 - 30 APNIC Meeting: Jan 31 Fees: Conference Registration: US $275 Tutorials: US $275/tutorial If you have any questions, feel free to contact me or the organizing committee (apricot-oc(a)apricot.net) Note that space is quite limited... Regards, -drc

1 0

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

23 Dec '96

> From: Vadim Antonov <avg(a)pluris.com> > 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 :) > I do not understand this rationale. Could you please elaborate? Are you saying that the reason we are not using ubiquitous LQM is because Cisco decided as a company policy not to interoperate with other vendors? BTW, I have never worked for Morning Star in any paid capacity; or I'd be a millionare today :-). I just have an email address there, as I do at several other sites, both commercial and non-commercial. 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

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

22 Dec '96

Craig Nordin <cnordin(a)vni.net> wrote: >Interesting. An ICMP packet dropped when busy. Well, it seems as >if there is only a hair's difference between when an ICMP packet is >dropped and when an IP packet is dropped. Well, cisco (and all other known fast routers, for that matter) handles ICMP in software, unlike vanilla IP packets, which are routed with significant hardware assistance. I.e. a lot of ICMPs will overload CPU. It won't interfere with routing of IP packets (though it can wreck havoc with of routing and network management protocols). So cisco limits the rate at which ICMPs are processed. >If you are busy, you are busy, right? Not. Different pieces of hardware are busy in those cases. >I know that I was getting zero packet loss for many many basic routes >this time last year that are now losing packets. I think that a network >is in great shape when the packet loss is at a sheer minimum. Even one >percent packet loss can be felt as substantially more degraded than >perfect transport. Er. There's no such thing as perfect transport as long as TCP is concerned. If end-hosts support large windows, even a single TCP session will load the network to the point where it'll lose packets. >Just like ra.net, I use pings to monitor one aspect of overall performance. >Me and ra.net are not alone. Pings are ok, as long as you realize what exactly is being measured. If you're pinging ciscos, you aren't measuring IP packet loss. --vadim

20 32

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Brett D. Watson 22 Dec '96

22 Dec '96

> > On Fri, 20 Dec 1996, Tony Li wrote: > > > You should be more specific about _why_ you want a MUCH bigger CPU. IMHO, > > the box needs more packet switching capacity (and more backplane > > bandwidth), but there's enough CPU there for the OS. > > Recomputing larger route tables, especially OSPF. Tunneling. > Encryption. Acess list filtering. Finer grain accounting (I'd love to see > usage stats for each interface over a day or so right from the router). > And most important to me, not becoming unusuable during a major routing > change. well, there is netflow. not quite the granularity you're probably looking for but it helps. and since frontier has signed an exclusive deal with cisco i suspect they might start moving more of the "probe" functionality into the routers and switches. the cat5k now supports a mini-rmon in the box. -brett

1 0

Re: HOW DO I GET IP'S?
by Marcos Della 21 Dec '96

21 Dec '96

> > Can anyone suggest a good way to get a CIDR block from the > > internic? We are two separate isps with separate ASNs, merged under one > > corporation, > > with one of them currently getting addresses from an upstream provider > > (/20). The problem is that in that location we are out of addresses, are > > multi-homed, and > > dissatisfied with our current provider. We need addresses before we can > > switch over, but the internic refuses to release any to us until we have > > used another /20 from our current provider. Thus, the internic has > > forced us to use one carrier with poor service. Legally, is this a > > monopoly? Has anyone started a class action suit? Can anyone help us? > > > > Get new IP's from your new provider. Renumber fast. Change your DNS TTL > very low. Maybe have your new provider hold primary DNS in the meantime. This is a pretty funny response. I'm still locked into an original T1 from one of my original providers who is charging me almost half of the cost for one of my typical DS3 lines for connectivity. Trying to renumber is impossible. Once you get to a certain number of customers, the game is over. As far as getting more addresses. I still have the same problem as others, however I can get by a little longer while trying to prove need. I know that unfortunately I cannot help too many smaller providers below me since the InterNic has restricted my site so much that I can't "slow start" another ISP under my network. Definately biased towards the big 6 providers. But then again, thats been the way business goes in every market. Someone holds 90% of the cards and the rest scramble to stay alive... Marcos

1 0

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