- Test - lists.nanog.org

FW: Another UUNET Explanation
by jan.novak＠aliatel.cz 02 Jul '97

02 Jul '97

We provided Internet access over FR also. You have to look on FR like level 2 transport for IP - you are doing IP routing not above leased line but above FR. The customer do not take care, what he has inside, for provider it is great profit - we had one Cisco 4700 for at least 30 customers on one serial port without problems. When the customers have some more complicated. meshed netowork, it is profit even for them - the save money on ports and several leased lines or expensive multiplexed E1/T1 interfaces. ---------- Od: Joe McGuckin[SMTP:joe@via.net] Odesláno: 2. července 1997 1:34 Komu: nanog(a)merit.edu Předmět: Re: Another UUNET Explanation I've noticed that several of the larger networks use frame-relay. Why? Our experience with frame-relay with the local telco has had mixed results. What technical advantages does a frame-relay network have over an IP routed network? Thanks! Joe

1 0

Routing vs Switching (was Re: Another UUNET Explanation)
by smd＠clock.org 02 Jul '97

02 Jul '97

"Chris A. Icide" <chris(a)nap.net> writes: smd> A clumsy tech or a backhoe takes out a physical path smd> between two POPs, each of which contains several routers smd> that form part of this flat network. smd> What happens now? > Layer 2 heals itself, without the knowledge of layer 3. Layer 3 > experiences a latency increase between certain paths. > > Sorry, had to do it. > > *duck* Well, this is certainly the obvious approach, and is certainly in line with the generally reasonable philosophy of "degraded performance rather than no performance" response to partitions, assuming the routers don't notice a topology change. There are some interesting issues with respect to convergence at the L2 layer (rerouting VCs takes time too), and I've seen problems where the fast-packet layer converged slowly enough that IS-IS adjacencies were lost, causing really neat routing slosh as the VC went and came back. (To augment one of my own questions, when you have two routers in a full mesh (FR, ATM, whatever using VCs) and the VC between N-1 and N-2 goes out of service, how do N-1 and N-2 decide what path(s) to use to talk to each other? Feel free to consider a network using any commonly available IGP and the iBGP hack.) I also have some anecdotes about VCs improperly travelling along the same path for long periods of time because of configuration errors or unnoticed physical disconnectivities between switches. There have also been neat tales of VCs going simplex from time to time. Monitoring two networks simultaneously, fun fun fun... :) I'm sure there are people here with practical experiences who might be willing to share what they've learned. > however, in this fast paced industry, will we > ever have the "perfect" protocol (okay, ever is a big > word). IPv6 over ATM/LANE with RSVP will someday change the world. Sean. - -- Sean Doran <smd(a)ab.use.net> "Boy, you obviously don't have a clue!" -- Chad Skidmore, Data Source L.L.C.

2 1

Re: Topological significance of transport technologies
by smd＠clock.org 02 Jul '97

02 Jul '97

Paul Ferguson <pferguso(a)cisco.com> writes: > Its not really Layer 2 vs. Layer 3, its how to integrate the > two layers and make it work. Mike O'Dell is fond of saying, > "Pure Layer 3 routed networks are dead," So does this mean that Falternet is dead? Hmmm. Wait, it's not a pure layer 3 network. Go figure. > and I can understand his point, although I don't > necessarily agree with it. The point is not so much to use one or the other or to integrate the two as much as it is to duplicate some of the handy functionality in PVC-using L2 protocols. This is something cisco has been doing (bravo), what with generic rate-limiting, better flow diagnostics and monitoring, and the like. In current and newer products from cisco and others, I expect to see some buffer management strategies that will eliminate the need for the fancy stuff one finds in FR and ATM and the like. If one has decent IP routers, one can essentially build on an L2 structure no more complicated than point-to-point PPP or HDLC talking circuits, modulo what one does wrt stuffing an add/drop MUX of some nature into the router itself. This tends to avoid the need to do horribly botched and sometimes proprietary redesigns of L3 routing protocols such as IS-IS, and lessens the need to do particularly ugly things with BGP, as one sees in L3 networks layered on top of NBMA L2 protocols. In turn, one should expect better stability from such networks over time. Trying to integrate "foreign" internetworking technologies in the manner done by UUNET (whether or not this is Mike O'Dell's grand design or merely a step in that direction I honestly don't know) leads to all sorts of interesting trouble. > Yes, they both get you there, but the pertinent summary to be > drawn from this comparison is that 'you' are the IP packet, > and you really don't care what the mode of transport is (e.g. > frame-relay, leased point-to-point lines, ATM). Actually you do care when you're carrying TCP segments; for instance, if your L2 network is too clever and messes up TCP's expectation that you see packets delayed and dropped when you send too quickly, like say with ABR when you end up seeing a VS dropping cells (or cell trains or whatever interesting stuff the ATM people have come up with to try to un-break ATM's anti-TCP behaviours) because it hasn't seen an RM come back across an uncongested network -- similar ugly things happen with FR congestion management schemes -- you can get really abysmal TCP performance. Moreover, management of disconnectivity under separate control loops is suboptimal; if you heal partitions at the L2 level you get ugly congestion invisible to traditional L3 routing protocols, and if you heal at the L3 level, then there seems to be alot of wasted effort in nailing up lots of VCs in the first place. > Some have more intrinsic flexibility than others (e.g. > virtual circuits) and therefore represent a significant reason > to employ a specific technology over another, given pricing, and > geographic availability. I will buy the pricing issue. If it werent that Telco N is offering ATM at OC-3-ish rates for about a fifth the price of a 155Mbps SONET tributary, and a notorious equipment vendor making it expensive in terms of equipment to build a point-to-point network with adequate buffering, I would expect ATM would be much less popular in several ATM-using internetworks. > Again, IP packets don't really care if it's a motorcycle, an > airplane, or an automobile (unless its a Harley :-). IP doesn't like it when SAR messes up or when cells get dropped in the middle of frames. TCP doesn't like it when IP gets confused and it also doesn't like it when non-ATM-forum workarounds for that set of problems allows one to confront the problems of conflicting congestion-control vs. congestion-avoidance systems. Admittedly none of those are inherent in VC-using L2 fabrics, however, most of the deployment rationalizations I've run into wrt that kind of thing involve congestion management, QoS, better monitoring and various other unfulfilled promises that could well find their way into IP routers Real Soon Now, assuming they aren't there already. I will, however, buy the argument that equipment-unavailable or equipment-unworkable exigencies drove the deployment of things like ATM and FR, and that the deployment was useful to push various equipment vendors into building what would have made the ATM and FR deployments unnecessary in the first place. In other words, hey, vendor, I have a gun to my forehead. It seems less painful right now than what will happen if we don't get the things we need from you. Give me what I want or I'll shoot. *Bang*. > It should also be noted that some technologies, such as > frame-relay are used only in *topologically significant* > places, ie. customer aggregation, for precisely these > reasons. In some networks, frame-relay is used for > customer aggregation, fast-ethernet is used in the PoP, > and ATM is used in the wide-area (just an example). And in some networks DS3s carry aggregated clear-channel DS1s and fractional DS1s into customer aggregation boxes, the DS3s for those and for the customers come right out of SONET ADMs, and 155Mbps POSIP (soon to be faster) is used essentially everywhere else. Or so goes the plans... Which networks are having the problems today? :-) Sean. (who thinks self-inflicted gunshot wounds can be self-healed, too, when there is no longer any economic need to wander around bleeding...)

3 2

Re: Another UUNET Explanation
by smd＠clock.org 02 Jul '97

02 Jul '97

Alex Rubenstein <alex(a)nac.net> writes: > Frame Relay allows yout he ability to psuedo-directly connection various > pop's together, and gives that clean appearance of a 'no-hop' back bone. > Why route when you can switch? Please explain this last line to me. Consider a flat network, where each router has a connection (virtual or otherwise) to every other router in the network. An IP datagram arrives at one of the routers. What happens now? A clumsy tech or a backhoe takes out a physical path between two POPs, each of which contains several routers that form part of this flat network. What happens now? A bug partitions the FR fabric, making a few VCs go away. What happens now? A new route is announced to one of the routers in the flat network. What happens now? (You may wish to consider it both as a route carried in some sort of IGP and a route learned from eBGP) Now unflatten the network so there is a maximally hierarchical network (the opposite of a flat network), in which only routers topologically adjacent to each other have any form of circuit-like connectivity. Go back and walk through my list of questions, paying particular attention to the issues involved in changes in IP reachability. Now, for even more fun, consider variances in delay thanks to the speed of light in copper & fibre. Consider what happens when IP reachability changes as traffic is being sent towards the changing destination(s). Finally, pretend you work for a large network that combines FR switches and routers and which is taking it in the shorts for some reason, and fix the problem so that I can get from home to cesium.clock.org without frequent long pauses. Sean. (hi Noel)

2 1

RE: Another UUNET Explanation
by Chris A. Icide 02 Jul '97

02 Jul '97

---------- From: Sean M. Doran[SMTP:smd@clock.org] Sent: Tuesday, July 01, 1997 10:21 PM To: nanog(a)merit.edu Subject: Re: Another UUNET Explanation A clumsy tech or a backhoe takes out a physical path between two POPs, each of which contains several routers that form part of this flat network. What happens now? Layer 2 heals itself, without the knowledge of layer 3. Layer 3 experiences a latency increase between certain paths. Sorry, had to do it. *duck* However, I agree wholeheartedly. If I had a Layer 2 protocol designed solely for the transport of a protocol to end all protocols, perhaps I would choose to use it, however, in this fast paced industry, will we ever have the "perfect" protocol (okay, ever is a big word). I suspect that as long as there is some value in making the "network" do something it wasn't originally designed to do, someone will hack a way to do it, and rake in some money. That money will draw other people to into either parroting the pioneer, or hacking thier own way, or perhaps denouncing the hack as un-pure. It's a never-ending circle, hacker, parrot, purist? Rwaaah, Cracker wants a Polly! (polly always gets the cracker) Chris A. Icide Nap.Net, L.L.C.

1 0

RE: Another UUNET Explanation
by Chad Skidmore 02 Jul '97

02 Jul '97

The difference is that they own the Frame Relay network and can control provisioning etc. Your experience with Frame Relay has been colored by the fact that your Telco is in control of the Frame Relay "Cloud". As several others have stated in the list here UUNET is using it to aggregate users into POP routers and to switch packets across the backbone as much as possible and route only when necessary. The problems they seem to be having now are due (possibly) to some problems with the software in the BSTDX switches and probably their own success. It is pretty tough to grow a network like theirs quickly enough to keep up with the overall growth of the Internet without some problems. That said I hope they get it fixed soon. They were, at one time, our best provider and they have slipped to our worst. ------------------------------------------ Chad Skidmore VP Operations & Engineering Data Source, L.L.C. http://www.dsource.com cskidmore(a)dsource.com > -----Original Message----- > From: Joe McGuckin [SMTP:joe@via.net] > Sent: Tuesday, July 01, 1997 4:34 PM > To: nanog(a)merit.edu > Subject: Re: Another UUNET Explanation > > > I've noticed that several of the larger networks use frame-relay. > > Why? Our experience with frame-relay with the local telco has had > mixed results. > > What technical advantages does a frame-relay network have over an > IP routed network? > > Thanks! > > Joe

1 0

Re: Another UUNET Explanation
by jprovo＠ma.ultranet.com 02 Jul '97

02 Jul '97

>Here is a message that we received from UUNET today. It seems that they >are full of various explanations. [snip] That answer is consistant with previous experiences in the Boston area. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: Plethora of UUnet outages and instabilities
by Alex Rubenstein 02 Jul '97

02 Jul '97

All I know is they suck moose nipples, and I disconnected from them last week. They have been having problems in/around cr1.nyc1 for MONTHS now, and they are doing nothing (that I can see) to fix it. Thier first-level support is horrendous. One guy once said to me, "Routers have processors?!". Another hung up when I told him to put "CUSTOMER IS IRATE" on the trouble ticket. There are some GOOD guys over there, but them seem to be disappearing? (are you there, Mr. Hannan?) HELLO, GENUITY (anyone who is looking for a new provider, Genuity is DAMN good. and a DAMN good NOC. Sales guys are a little whacky, tho). At 02:12 PM 6/30/97 -0700, Josh Beck wrote: >Has everyone else been seeing the almost daily UUnet outages recently, >does anyone know what the true causes of these have been? --- "Don't go with a spineless ISP; we have more backbone." Alex Rubenstein -- alex(a)nac.net -- KC2BUO -- www.nac.net net @ccess corporation, 201-983-0725 -- 201-983-0725

15 21

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by Jack Rickard 01 Jul '97

01 Jul '97

This assumes that you consider web server location and web server performance to NOT be a part of overall network performance. Our view steps back a bit from that. The majority of traffic would appear to be webcentric. From an end users perspective, what does a web site on a specific network look like and how does that compare to a web site on another network? There are ENDLESS variables contributing to that including intercity links, hub architecture, host hardware, host software, peering, connectivity points with other networks, transit agreements, type of routers, ATM switching (or not). All contribute. We think most people notice Internet performance (or lack thereof) while viewing world wide web pages. If we measure such page transits, the results are indicative of the accumulation of ALL of those factors. The web sites chosen were on the network under study, operated by the network, and under their control. They have total control over the hardware and software used, how it is connected to their network, just as they have control over all other aspects of their networks. Does web server performance affect the results? I would hope so. Can we break it down into what is purely web server hardware performance, what is web server software performance, what is NIC card on the web server, what is the impact of the first router the web server is connected to, what is the impact of hub design and the interface between IP routing and ATM switching, what part is the impact of interconnections with other networks, what part is peering, what part is just goofy router games? Uh,,, NO we can't. I would posit that it is only the network engineers at the heart of this that would or should care. I don't know at this point what portion of the equation can be levied on web servers and I don't think anyone else can either. I have held for several years that the performance breakdown is in the "last inch" of the Internet between the drive controller and the disk surface. But in working with Keynote, I generated the broad theory that if that view held true, then by massively averaging measurements across time and geography, we should flatline the Internet. In other words, all results should factor to zero relatively. They didn't. They didn't to a shocking degree. And at this point I am under the broad assumption that server performance doesn't account for all of it, perhaps little of it. But I could be widely wrong on the entire initial assumption. In any event, the networks have total control and responsibility for their own web servers, much as they do for their own network if you define that as something separate from their networks. We measured web page downloads from an end user perspective, and those are the results in aggregate. If it leads to a flurry of web server upgrades, and that moves the numbers, we'll know more than we did. If it leads to a flurry of web server upgrades, and it FAILS to move the numbers, that will tell us something as well. Our broad theory is that nothing is going to improve as long as anything you do doesn't count and is not detectable by anyone anywhere. If a particular network can move their results in any fashion, that is an improvement in the end user experience, however achieved. Warmest Regards; Jack Rickard =================================================================== Jack Rickard Boardwatch Magazine Editor/Publisher 8500 West Bowles Ave., Ste. 210 jack.rickard(a)boardwatch.com Littleton, CO 80123 www.boardwatch.com Voice: (303)973-6038 =================================================================== ---------- > From: Craig A. Huegen <c-huegen(a)quadrunner.com> > To: Jack Rickard <jack.rickard(a)boardwatch.com> > Cc: Peter Cole <Peter.Cole(a)telescan.com>; nanog(a)merit.edu; marketing(a)keynote.com > Subject: Re: Keynote/Boardwatch Internet Backbone Index A better test!!! > Date: Friday, June 27, 1997 2:08 PM > > On Fri, 27 Jun 1997, Jack Rickard wrote: > > ==>Not an entirely whacky concept actually. The way hot potato routing works, > ==>this could actually be a "purer" test I suspect of the network internally > ==>and a purer test of connectivity of any network to all others cum Internet. > > The article says that you're measuring backbone provider performance, yet > you're including: > > * carrier's web server location > * carrier's web server performance > > ==>Keynote does a "Top 40" study of 40 popular web sites and I believe they > ==>make the results available on their web site. It is interesting to observe > ==>performance variations of the network as a whole over time. Other than > ==>that, we don't have much interest in it. It is indicative of no specific > ==>network, but of the Internet in general. > > /cah

7 6

Another UUNET Explanation
by Chad Skidmore 01 Jul '97

01 Jul '97

Here is a message that we received from UUNET today. It seems that they are full of various explanations. July 01, 1997 Dear UUNET Customer, Please accept our apologies if you have experienced any service interruptions over the past 24 hours. The cause of these problems has been traced to a software defect within our Cascade Frame Relay network. UUNET is working closely with Cascade to fully understand the cause and effects of these problems and is in the process of identifying a permanent fix. This may include rapidly deploying new software into the network. We will provide periodic updates throughout the day as further information becomes available. Routing instabilities may continue at a diminished capacity over the next 24-48 hours as switches receive updates. Thank you for your patience during this period. Again, we apologize for any inconvenience which these outages may have caused you or your customers. Sincerely, UUNET Technologies, Inc. ------------------------------------------ Chad Skidmore VP Operations & Engineering Data Source, L.L.C. http://www.dsource.com cskidmore(a)dsource.com

1 0