- Test - lists.nanog.org

routes have been withdrawn, it looks like sprint has the issue under control
by steve＠altrina.exodus.net 26 Oct '98

26 Oct '98

It looks like Sprint has the issue under control (or possibly eu.net/supernet has resolved it). This will be my final update/mail. Thanks for your patience. -Steve -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Work:408.346.2333 -- All my love to the Canadian Mooing Frog.

1 0

heads up: major route brokenness
by hhui＠arcfour.com 26 Oct '98

26 Oct '98

about half an hour old news (8 30 EST) lots of routes are getting sent through sprint. EUnet leaking routes. anyone have a more detailed postmortem? --- Tung-Hui Hu (HH26) alchemist http://arcfour.com

1 0

anyone else seeing 286 (EU.NET) annoucing the world to sprint through supernet (209)
by steve＠altrina.exodus.net 26 Oct '98

26 Oct '98

It looks like anyone on sprint going to a non-sprint site is going out to eu.net.. I've confirmed this with a few people.. anyone know whats going on? not getting a response from the sprint noc.. -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Work:408.346.2333 -- All my love to the Canadian Mooing Frog.

1 0

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