- Test - lists.nanog.org

Reference
by Tim Wolfe 24 Oct '98

24 Oct '98

Anyone know of a good place to check on the historical data about how many times a route has flapped in the last X amount of time? TIA, Tim ---------------------------------------------------- Timothy M. Wolfe | Why surf when you can Sail? tim(a)clipper.net | Join Oregon's Premier Sr. Network Engineer | Wireless Internet Provider! ClipperNet Corporation | http://www.clipper.net/ ----------------------------------------------------

2 1

Re: Actions to quiet the Smurf amplifiers?
by Phil Howard 24 Oct '98

24 Oct '98

It doesn't seem to be working for me. What version of IOS does this new feature show up in? Why hasn't it been mentioned before? Or is this not similar enough to be usable to block smurf and other forgery? Danny McPherson writes... > Cisoc already has a feature similar to this, "ip verify unicast reverse-path". > > -danny > > > Danny McPherson writes... > > > > > ingress filtering .. that's a novel idea :-) > > > > "smart" ingress filtering, as opposed to hard coded filtering, which > > is already done a lot. It would come at some costs, as every packet > > would have to have 2 routing lookups done for it, one of which must > > return or compare against all routes, not just the best route. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --

5 5

Wireless LAN access in Atlanta
by Kevin Oberman 23 Oct '98

23 Oct '98

The NANOG 14 web pages says that 802.11 wireless LANs will be available in the hotel. A review of 802.11 PCMCIA cards in Communications News found that only the BreezeCom and Raylink products would inter-operate. There is no indication of the manufacturer(s) of the units so that we can bring compatible cards. It does say that additional information will be posted the week before the show, but I'll already be on the road setting up the networking for SC98 in Orlando, so it will be too late to make sure I have an appropriate card. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

2 1

Packetshaper Replacement
by Jonathan A. Zdziarski 23 Oct '98

23 Oct '98

Hello, I'm curious if anyone knows of any good alternatives to shape bandwidth logically other than the packeteer. We're having persistent problems with slow bandwidth, including bandwidth outside any policy limitations, and for some reason it keeps kicking into safe mode as well. Ironically they were having the same problems on the interop demos =). I'm going to be taking a look at Foundry's Server-Iron which is a L4 switch, but it may not do what we need it to do. Bay networks makes some nice switches that are capable of bandwidth shaping, but only per physical port. Our basic needs are a unit that will shape logically, keep statistics, and all the general bells and whistles that one would need to maintain a shaped, shared-colo network. Thank you, Jonathan A. Zdziarski Senior Systems Administrator Netrail, inc. 888.NET.RAIL x240

4 4

The Cidr Report
by Tony Bates 23 Oct '98

23 Oct '98

This is an auto-generated mail on Fri Oct 23 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 23Oct98 0) General Status Table History ------------- Date Prefixes 161098 53167 171098 53211 181098 53097 191098 53201 201098 54125 211098 53433 221098 53407 231098 53585 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4133 Number of ASes announcing only one prefix: 2007 (1066 cidr, 941 classful) Largest number of cidr routes: 344 announced by AS3561 Largest number of classful routes: 944 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Oct98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1785 654 397 257 39.3% NYSERNet Backbone AS271 355 153 202 56.9% BCnet Backbone AS4293 413 240 173 41.9% IMCI AS3749 232 72 160 69.0% TECNET AS2493 349 197 152 43.6% iSTAR Internet, Inc. AS3857 332 184 148 44.6% Internet Connect, Inc. AS701 944 815 129 13.7% Alternet AS174 690 561 129 18.7% Performance Systems International AS4200 191 98 93 48.7% AGIS (Apex Global Information Ser AS5668 128 41 87 68.0% Century Telephone Inc. AS7046 268 188 80 29.9% UUNET-CUSTOMER AS3221 118 44 74 62.7% EENet Autonomous System AS3804 229 156 73 31.9% Bell Solutions AS4755 120 55 65 54.2% Videsh Sanchar Nigam Ltd. India AS4740 395 331 64 16.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS8517 125 72 53 42.4% ULAKNET-ASN AS7545 116 64 52 44.8% TPG Internet Pty Ltd AS6335 71 19 52 73.2% NTRNET AS549 195 146 49 25.1% ONet Backbone AS72 87 39 48 55.2% Schlumberger Information Network AS1239 538 491 47 8.7% SprintLink Backbone AS1221 361 315 46 12.7% AARNET-AS AS803 77 33 44 57.1% SaskNet Backbone AS3790 61 17 44 72.1% RACSANET AS7122 130 87 43 33.1% MTS ADVANCED Network Policy AS852 167 126 41 24.6% AGT Advance Communication AS4539 68 28 40 58.8% NETROPOLIS AS10928 88 49 39 44.3% UNKNOWN AS6181 64 30 34 53.1% FUSE-NET AS2707 64 31 33 51.6% WEC For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Frame Relay encap vis-a-vis point-to-point at UUNET (fwd)
by chris.whittenburg＠wcom.com 23 Oct '98

23 Oct '98

> On Fri, Oct 23, 1998 at 11:48:00AM -0400, Eric Dean wrote: > > You could also order a larger circuit with the same FR paramters. > > The circuit in question is from UUNet. We're not terribly interested > in paying them more money when they are 3x more expensive than anyone > else we get bandwidth from. > > FWIW, Savvis does _not_ have this problem. > > -- > Jeffrey Haas "He that breaks a thing to find out what it is has What version of IOS are you running? It could be this cisco bug: CSCdj91667: frame relay/serial: LMI or keepalives sent out of order/not sent. regards, chris

1 0

Frame Relay encap vis-a-vis point-to-point at UUNET
by Barry L James 23 Oct '98

23 Oct '98

Hey all, We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't exactly true since our MCI and AT&T (just recently transitioned from the BBN backbone to the AT&T network) does not use this configuration. He insisted that it was still a point to point and that the frame relay encapsulation was used to enhance the connection. Well, I had him grab an engineer (he was an SE) that could possibly explain it better to me (since the SE said F/R was used to decrease RIP broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap. Now, I guess my question is: am I getting sold the brooklyn bridge here? I mean, not that I wouldn't like to *own* the brooklyn bridge (well, I'd rather have the triboro or the washington, but anyway...). Is this f/r encap going have any adverse affect on the quality of this connection (assuming that this is *NOT* a point-to-point into a frame cloud) or am I getting shoveled a load of copralite? Thanks! Barry Barry L James | Mikrotec Internet Services, Inc (AS3801) Director R & D | 1001 Winchester Rd bjames(a)mis.net | Lexington KY 40505 http://www.mis.net/ | 606/266.5925 800/875.5095 Member AAAI, IEEE # 40277528 --- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. -- Winston Churchill

11 12

Slightly off topic: anyone using Software.com Intermail?
by Michael L. Barrow 23 Oct '98

23 Oct '98

Sorry for the off-topicness of this message, but this is the right audience that I want to answer my question. Is anyone out there using Intermail from software.com? Please reply to mlbarrow(a)eni.net. Thanks! -- Michael L. Barrow <mlbarrow(a)eni.net> Principal Security Engineer, Epoch Internet T:949.399.8413, F:949.474.8127 PGP Fingerprint = 6E56 4590 F1AF 0CCA 2563 07C2 26EF B164 F5C4 BE8C

1 0

New report from ATIS on Internet/Telephone reliability
by Sean Donelan 23 Oct '98

23 Oct '98

The ATIS T1 committee has issued a new technical report on the reliability and availability aspects of the interactions between the Internet and the public telecommunications network. ftp://ftp.t1.org/pub/techrpts/tr.0/tr_55.pdf Abstract This Technical Report addresses the reliability and survivability aspects of the interactions between the Internet and the Public Telecommunications Network (PTN). It examines the general architectures of both networks and the interfaces between them. This document offers suggestions for meeting reliability challenges posed by changing network traffic characteristics. Two major categories of solutions are introduced: network engineering and network architecture. Within these categories, alternatives may be selected depending on the operator's local circumstances. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Source for availability numbers (Re: SONET ring questions)
by Sean Donelan 23 Oct '98

23 Oct '98

alan(a)globalcenter.NET (Alan Hannan) writes: >> For total system uptime >> 90.0% (one nine or less) Desktop systems. >> 99.0% (two nines) Intermediate business systems >> 99.9% (three nines) Most business data systems and workgroup servers >> 99.99% (four nines) High-end business systems and your friendly >> neighborhood telco >> 99.999% (five nines) Bank Data Centers and Telco Data Centers, some ISPs >> 99.9999% (six nines) Only God and Norad live here. >> 99.99999% (seven nines) Even God doesn't have pockets this deep. > > What's your source for this data? Here are some availability parameters I understand are used for US Government Communication Service acquisitions by the FAA and DOD. I don't know what, if any, study or research went into these definitions. There seems to be a lot of exageration in both the stated requirement and deliverability of many availability numbers. However, the table below are some of the sanest ones I've seen. The most extreme availibility number I give even the slightest credence was for the AT&T Master Clock in Hillsboro, Missouri at 9 nines. I've never confirmed it with AT&T though, and wouldn't be surprised if it was less. Service Service Expected Expected Type Scope Availability Restoration Time Critical Functions or Services 0.9999987 <6 seconds which, if lost, would prevent the network/ system from exercising safe operation and control for the end users Essential Functions or services 0.999 approximately which, if lost, would 10 minutes reduce the capability of the network/system to exercise safe operation and control for the end users Routine Functions or services 0.99 approximately which, if lost, would 2 hours not significantly degrade the capability of the network/system to exercise safe operation and control for the end users I took this table from another publication, which gave the reference as U.S. Federal Standard 1037B, Telecommunications Glossary. A note was included "The expected availability values require information as to the population and interval over which they have been calculated." -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0