- Test - lists.nanog.org

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

Starr report - as seen from MAE East
by Steve Feldman 12 Sep '98

12 Sep '98

For grins (well actually in response to pressure from our press relations folk) I made a quick graph of MAE East utilization for today. The result is at: http:/www.mae.net/starr There was a jump of about 100 Mbps at 4pm Eastern time. There was no sigificant change in traffic at MAE West. Steve

6 6

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

12 Sep '98

>> It is expected the Library's web server(s) will be the primary distribution >> point for the Office of Independent Counsel report to the House of >> Representatives. The exact time and and place has not been announced. >> > >http://thomas.loc.gov/ICreport/ If anyone still cares, after a lot of hard work from some very under-appreciated US government employees, the final place is http://icreport.loc.gov/icreport. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2