- NANOG - lists.nanog.org

Re: The Cidr Report
by John M. Brown 14 Sep '98

14 Sep '98

Why should they, there is no reason for them to. Personally I wonder what would happen if we (the rest of us) started filtering on /19's or /20's :) But then you take UUNET (Alternet) and for example 207.170.32.0 /19 is advertised as a /19 AND a stack of /24's all with the same AS path and from what I can tell no special routes, at least not via nitrous.digex.net But what do I know, I am a lonely little guy... :) At 01:19 PM 9/11/98 -0700, Tim Wolfe wrote: >Anyone care to comment on the fact that the top non-compliant companies never really seem >to make any significant changes? > >> --- 11Sep98 --- >> ASnum NetsNow NetsCIDR NetGain % Gain Description >> >> AS701 1185 956 229 19.3% Alternet >> AS271 349 152 197 56.4% BCnet Backbone >> AS4293 445 258 187 42.0% IMCI >> AS174 789 611 178 22.6% Performance Systems International >> AS3749 225 68 157 69.8% TECNET >> AS2493 373 217 156 41.8% iSTAR Internet, Inc. >> AS4200 192 100 92 47.9% AGIS (Apex Global Information Ser >> AS5668 128 41 87 68.0% Century Telephone Inc. >> AS2685 229 151 78 34.1% IBM Global Network - US >> AS4755 125 49 76 60.8% Videsh Sanchar Nigam Ltd. India >> AS3221 117 44 73 62.4% EENet Autonomous System >> AS4740 404 336 68 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) >> AS3493 251 183 68 27.1% INTERLINK >> AS7046 239 172 67 28.0% UUNET-CUSTOMER >> AS3804 215 157 58 27.0% Bell Solutions >> AS10928 101 46 55 54.5% UNKNOWN >> AS549 204 151 53 26.0% ONet Backbone >> AS8517 123 71 52 42.3% ULAKNET-ASN >> AS6335 69 20 49 71.0% NTRNET >> AS72 87 39 48 55.2% Schlumberger Information Network >> AS1239 548 501 47 8.6% SprintLink Backbone >> AS803 78 34 44 56.4% SaskNet Backbone >> AS6181 66 26 40 60.6% FUSE-NET >> AS4539 67 27 40 59.7% NETROPOLIS >> AS852 159 120 39 24.5% AGT Advance Communication >> AS3403 159 120 39 24.5% TIAC >> AS7122 118 80 38 32.2% MTS ADVANCED Network Policy >> AS10459 45 10 35 77.8% WANSASN >> AS2707 64 31 33 51.6% WEC >> AS6332 89 58 31 34.8% TELNOR > >--------------------------------------------------- > Tim Wolfe, Network Administrator > ClipperNet Internet Access Services >tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax > ...Across the Desktop and around the World... >--------------------------------------------------- >

3 3

Re: Routing, Forwarding, and the Legacy Internet
by Jim Fleming 13 Sep '98

13 Sep '98

-----Original Message----- From: Chrisy Luke <chrisy(a)flix.net> <snip> > >Even in your simplistic view, you would have to transfer 16meg of data Please note, I did not suggest that people implement the simplistic view. I suggested that people focus on routing and not forwarding. Also, if one did implement a brut-force approach 16meg would not be transferred. You could transfer exactly what you transfer now and the table would be built inside the device where the 16 meg is stored. For example, if information was obtained that all traffic for a /8 needed to be sent via a certain interface then 65,636 entries in the brut-force table would be filled in with that small amount of information from an external device. Keep in mind the premise was that we would look at the entire address space as /24s and have an entry for each. That does not mean that the forwarding device needs to be told about each of the /24s. It can be told about large groups of them. That does not require 16meg of data to be transferred. Again, this discussion started with someone claiming that /24s could be added to the routing tables. My point was that current technology does not encourage this and the Internet governance of the industry has been developed to support what the hardware vendors have to sell. In other words, we can not start with a clean sheet and ignore the way current devices work (or do not work). My other point is that I do not think that vendors will worry that much about fixing the forwarding technology because "routing" is going to become very key to the hardware vendor's survival. I do not think that many Internet operators have begun to address what is going to happen when they have to deal with the world of routing vs. forwarding. Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+@---<IPv8>---C+@---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm

1 0

Routing, Forwarding, and the Legacy Internet
by Jim Fleming 13 Sep '98

13 Sep '98

-----Original Message----- From: John M. Brown <jmbrown(a)ihighway.net> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Sunday, September 13, 1998 4:34 AM Subject: Clean up your annoucements! Re: The Cidr Report >Yup! (I agree with both of your points! :) ) > >We should allow /24's into the route system and it wouldn't be as big of >a deal if folks like AS701 and others cleaned up there routes. > >Many rural providers are going to be multi-homing and thus we are going >to see an increase of /24 - /20 blocks. > >jmbrown(a)ihighway.net > You mention the "route" system. Many people feel that the Internet does routing, when it really mostly does forwarding. Imagine yourself standing inside of a busy back-bone router. Packets arrive with a source and destination address which are not likely local. Your task is to forward the packet on the proper interface. You do not add anything to the front of the packet to "route it", you just forward it to the next best place where the process happens again, and again, etc. It is very unfortunate that routers from behind-the-times companies are not designed to handle the large tables required to do forwarding. Since you have suggested that more /24s be allowed, you might want to consider a different type of software design to handle a worst case scenario. Let's imagine that ALL possible /24s needed to be supported. Let's also imagine that your forwarder (not router) could have up to 256 interfaces. With 24 bits and a 1 byte wide table, you would need 16,777,216 bytes to describe all possible /24s and the interface a packet should be forwarded on. That is not a lot of memory in this day and age. Also, once the table was filled in, the lookup would be very fast. A packet would arrive, you would look at the most significant 24 bits of the destination, pull out the 8 bit interface id and place it on the queue for that interface to be forwarded as soon as the link was available. Unfortunately, router companies do not build devices that forward very well, and they also do not build devices that do routing very well. Before we look at routing, we should observe that most of the current routing companies organize their route tables based on assumptions about a sparse number of entries. Because of that the algorithms can not be fast and the processing required to make adjustments to their data structures can be much greater than simple changes to our hypothetical, brut-force, table above. Because, of poor engineering and design assumptions from the 80's when memory and processing was not cheap, Internet network operators are stuck living in a world where the rules are biased toward the ancient legacy systems. Those rules not only help to keep people in the mind-set where they buy the legacy equipment, the rules also make it such that large, legacy-laden, network providers are favored over the small, more leading-edge ISPs. In my opinion, this will all soon come to a point where people realize that the Internet needs more routing and less emphasis on forwarding. Sure, people could try to get companies to build systems that forward better, but that may not have as large a payoff as the move to routing. Routing will likely work best at the edges of the net and not in the core. Routing will require more intelligence than forwarding. Routing will be more involved in QoS and optimizing the balance in ATM circuit switching and IP forwarding. When the two are combined with processing power and more sophisticated protocols, true routing can occur. In the meantime, you are stuck with forwarding and with machines that do not support the notion that a huge number of /24s can be advertised. Some day, this may not be the case. Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+@---<IPv8>---C+@---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm

2 1

Re: Starr report - as seen from MAE East
by Robert Szarka 13 Sep '98

13 Sep '98

At 01:45 AM 9/12/98 , scott w wrote: > >Maybe folks are not as interested as the press thinks. Or maybe a lot of us mirrored it locally. I had the report and the President's response(s) up here around 2200 EDT the day it came out and so far something like 10-15% of our subscriber base has hit our local copy. Then add to that the increased use of caching these days (we run a small caching proxy server). Seems plausible to me that the traffic increased initially but fell off as the report got cached and mirrored locally. The servers had to have been a bottleneck, too. The LOC and CNN servers seemed to be doing reasonably well, but for a while the report was unavailable at LOC while they fixed errors in the footnotes. The Whitehouse servers/connections, which have never been stellar, seemed to have been hammered pretty badly at one point... -- Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000

1 0

Flash crowds and network management
by Sean Donelan 13 Sep '98

13 Sep '98

>It was small as most web pages are today. I don't think the government >servers were hit even close as hard as some of the big news sites. I bet >CNN has 10 x the hits the LOC site had. NetRail hosted the servers for US >Treasury and USDA. We gave them a 100 BaseT ethernet connection into a >core router, but it never was a big deal because their servers would die >way before the like utilization ever got high. I have found many >government sites are like that. I would not be surprised if LOCs servers >died before the links maxed out. I tend to have a more holistic approach to customer service. The customer's servers dying due to the network load is concerns me as a network manager even if though link utilization never got high. I wouldn't jump to the conclusion that the government servers were not hit even as close as hard as some of the big news sites, depending on your definition of 'hit.' Hits for traffic management purposes are different than hits for advertising purposes. Your servers stop counting 'hits' when they are down, but that doesn't mean the requests stop. Outbound traffic goes down when the servers die, but inbound traffic doesn't stop. I'd like to chat someday with the webserver managers at some of the large media web farms someday, not necessarily with a reporter listening in, about what they were seeing. But at the moment there isn't a real good way for us to communicate in real-time about what is going on. Think of the worst SYN or SMURF attack you've ever seen and then combine them. The Internet doesn't have the equivalent of "choke" exchanges found in local telephone exchanges. And if you think the phone network is any more reliable, remember what happened when Garth Brooks tickets went on sale in the Capital a few years ago. A useful addition to CAR would be a clear way to limit SYN packets per second, but letting other traffic through so once the person gets connected they clear out as fast as possible. Using the 'established' keyword in a access list and guessing at the size of SYN packets gets part of this. For traffic management purposes, you want to distribute the choke points around the entire backbone rather than just at the one hot interface. The queue discipline gets a bit weird because of "duplicate" SYN packets and essentially zero packet inter-arrival spacing. I have a gut feeling that robots were a problem, but editing access-lists in the middle of storm wasn't a good solution. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

ny times
by dgraves 13 Sep '98

13 Sep '98

It was a true hack attack -- with a different home page -- apparently, some hackers were angry at some of the nytimes reporters.

1 0

ny times
by dgraves 13 Sep '98

13 Sep '98

DNS seems polluted for nytimes.com.

1 0

Re: The Cidr Report
by mark＠vielle.datasys.net 13 Sep '98

13 Sep '98

Quoth Tim Wolfe: : Anyone care to comment on the fact that the top non-compliant companies : never really seem to make any significant changes? : : > --- 11Sep98 --- : > ASnum NetsNow NetsCIDR NetGain % Gain Description : > : > AS701 1185 956 229 19.3% Alternet Date: Mon, 10 Aug 1998 22:36:06 -0400 (EDT) From: help(a)UU.NET (UUNET Customer Liaison) To: mark(a)vielle.datasys.net (Mark R. Lindsey) Subject: Re: Please aggregate more! (UU0946165) Hello Mark R. Lindsey: Thanks for your E-mail! Yes we do have plans to aggregate more in the very near future. If you have any questions, please contact me at 1-800-900-0241 opt 2,1 Thanks John Jackson Sr. Network Support Engineer

1 0

Re: Inter-CO signaling?
by William Allen Simpson 13 Sep '98

13 Sep '98

> From: James Carlson <carlson(a)ironbridgenetworks.com> > - If they're using channel banks between you and the > customer's switch (like if they dropped you cheap T1s by > putting them line-side on your switch, rather than trunk- > side), then you lose. 24Kbps will be about the maximum. > Yes, BellSouth did something like that to us at our main dial-in bank over last weekend. They've been running out of dialtone on the switch, since we have so many lines (much more than they ever expected in a rural area). Now, they claim that they only promise that we will receive 9.6Kbps per line! We've been told this by several persons. We are getting 28.8Kbps. This problem has taken a lot of my time all week. > - Some misconfigurations will merely cause lots of errors and > poor performance rather than abject failure. Check AMI > versus B8ZS (look for coding violations), and check for > clocking problems (extremely frequent slips noted by FDL). > We had that problem on T1s, until we switched to PRIs. More expensive per line, but at least they work better. ILEC equipment is in a terrible state. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 1

Re: NOTICE: mass-media event expected Sep 11, 1998
by Sean Donelan 12 Sep '98

12 Sep '98

>It might be nice if Sean could post a small after-action report. > >What did he do in advance? >Lessons learned? >How big a bump WAS it? >etc... > >...after he catches up on his sleep, of course... Sleep? What's that? The post-mortum will be submitted to the customer. I'd like to see the reports MCI submits to the House and GTEI submits to GPO, or even PSI submits to the White house. But I guess that will be up to those customers what is done with the reports. On the other hand, several of my other users (DRA has several hundred other libraries on net besides LOC) reported it was a wonderful day to use the network. They were able to reach non-news sites with ease all day. I can't do the typical backbone thing and say we had zero packet loss, but it was remarkably low (< 1%). As you moved away from 'ground-zero' the effects dropped off very quickly. Essentially people one or two hops away didn't notice a thing, except when trying to get the Starr report. I would like to thank everyone who either offered, or provided assistance. For those that offered, and didn't receive a response, your offers were seen. The Rules those involved were operating under and time pressure meant some offers couldn't be accepted at the time. Government webmasters can't do some things a commercial company could do. It was amazing though, the Internet providers I was paying money gave the least amount of assistance. They didn't even respond to mail messages sent to their NOCs. One severly clueless salesperson paged in the middle of this to offer me Rams football tickets. Not even the reporters calling were stupid enough to have me paged yesterday. Hint, if you are giving away tickets in St. Louis, try Cardinals baseball tickets, left field. WorldCom and AOL receive special thanks for assistance above and beyond. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0