October 1997 - Test - lists.nanog.org

Problems with UUnet and Sprint peering
by Anthony Pardini 09 Oct '97

09 Oct '97

Is anyone else having problems sending taffic between UUnet and Sprint ? This has been occuring for a least a week and so far I've just gotten the Its Sprint / Its UUnet run around. The problem is that there is too much traffic 40+Mbit/s each way between these two routers. 144.232.4.13 (sprint) and 137.39.166.121 (uunet) Any suggestions on getting this resolved? or who handles the peering agreements between these two companies? --------------------------------------------------------------- Tracing route to www.uu.net [199.170.0.30] over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms cisco7505-3.cmpu.net [204.181.108.1] 2 10 ms 10 ms 10 ms 144.228.137.13 3 10 ms 10 ms 10 ms sl-fw-19-F6/0/0.sprintlink.net [144.228.30 4 40 ms 50 ms 50 ms 144.232.8.70 5 40 ms 40 ms 40 ms 144.232.4.21 6 40 ms 50 ms 50 ms 144.232.4.14 7 1712 ms 1713 ms * Hssi4-0.BR1.SFO1.ALTER.NET [137.39.166.121 8 1532 ms 1542 ms * Fddi0-0.CR2.SFO1.Alter.Net [137.39.41.38] 9 1442 ms * 1322 ms 133.Hssi-2.GW2.FFX1.Alter.Net [137.39.71.7 10 1352 ms 1402 ms 1372 ms UUNET7-GW.UU.NET [137.39.12.162] 11 1412 ms 1352 ms 1352 ms charlotte01.va.pubnix.com [199.170.0.30]

3 2

Emerging Technologies
by Patrick O'Keefe 09 Oct '97

09 Oct '97

For emerging technologies (i.e. PNNI, MPOA, IPv6, RSVP) which IGP would you use OSPF or EIGRP in a cisco enviroment on a global network ?

1 0

ATM (was Re: too many routes)
by Sean M. Doran 09 Oct '97

09 Oct '97

Richard Irving <rirving(a)onecall.net> writes: > Ok. I will bite, although I hate to open my mouth, as my shoe always > seems to bee-line for it.. ;} Hehe. > I don't think so.... how about the ability to mix > voice, MPEG, and IP on the same pipe ? Um, I do this now with IP. Admittedly with parallel circuits (virtual or hard) I could send such traffic down different pipes to partition congestion effects, however to do this right I'd really want to use MPLS/tag switching anyway. When I make the decision to use MPLS/tag switching I also have to consider that there is decent queuing available in modern IP routers (that will effectively become hybrid IP routers and MPLS/tag switches) and that I can neatly partition the traffic without using actual or virtual circuits. > Or, how about that with ABR my delay across the ATM > fabric is reduced when I have more bandwidth open. (POTS > is low on utilization, during this "theoretical moment > in time") A couple milliseconds and a few extra Mbs can > count ;) You want bounded delay on some traffic profiles that approach having hard real time requirements. (Anything that has actual hard real time requirements has no business being on a statistically multiplexed network, no matter what the multiplexing fabric is). This can be implemented in routers now, with or without MPLS/tag switching, although having the latter likely makes configuration and maintenance easier. ABR is another attempt to do statistical multiplexing over a substrate that is not well geared to anything other than TDM. It interacts poorly with any protocol that is developed to run over a statistically-multiplexed network (e.g. TCP) and there are little demons with respect to the way RMs are handled that can lead to nasty cases where you really don't get the bandwidth you ought to. The problem again is that mixing TCP and other statmux-smart protocols with ABR introduces two parallel control loops that have no means of communication other than the interaction of varying traffic load, varying delay, and lost data. This often leads to the correct design of additive increase/multiplicative decrease traffic rate response to available bandwidth leading to a stair-step or vacillation as more bandwidth becomes available to each control loop, and a rather serious backing off at the higher level when available bandwidth is decreased even fairly gently. Delay across any fabric of any decent size is largely determined by the speed of light. Therefore, unless ABR is deliberately inducing queueing delays, there is no way your delay can be decreased when you send lots of traffic unless the ATM people have found a way to accelerate photons given enough pressure in the queues. > Oh, 2 things come to mind, my variability throughout an ATM cloud is > greatly reduced versus a routing cloud, a cell requires WAY less time to > cross a switches backplane, versus a packet through a router. And > seriuosly less time to determine where to send it... Um you need to be going very slowly and have huge packets for the passage through a backplane to have any meaning compared to the centisecon propagation delays observed on long distance paths. I know of no modern router that delays packets for anything approaching a handful of microseconds on fast interfaces except in the presence of outbound queues being congested, where if you're running TCP you really want to induce delay rather anyway, so that the transmitter will slow down. > Ok. So, maybe Cisco's Flow Switching approaches VBR having a bad hair > day. (and tuned for SERIOUS tolerance, CDVT=10,000), but certainly not > traditional routing. The analogy between VBR and flow switching confuses me. Could you explain this a bit? Actually, maybe you could explain the rest of the message too, because I think we have a disconnect in terms of vocabulary. :( Sean.

25 37

(Fwd) Re: Request for your advice
by narlar＠agcs.com 09 Oct '97

09 Oct '97

HI, I don't know if this is someone's email address or a mail list. Either way, please excuse me for taking the liberty to mail this to you. BUt I have an urgent need to know general pricing information for T1 and T3 pipes from business to ISP and from ISP to the backbone. I would appreciate if you'd point me in the right direction. Thank you. Ramaiah --- Forwarded mail from Avi Freedman <freedman(a)netaxs.com> From: Avi Freedman <freedman(a)netaxs.com> Subject: Re: Request for your advice To: narlar(a)agcs.com Date: Thu, 9 Oct 1997 16:09:37 -0400 (EDT) Worldcomm IXC Qwest Sprint MCI Are all possibilities. Why not post to nanog(a)merit.edu with the question? > On Oct 9, 3:28pm, Avi Freedman wrote: > > Subject: Re: Request for your advice > > > > > > > Are you looking for raw clear-channel pipes or IP transit pipes? > > > > Avi > > I'm interested in raw clear-channel pipes. Thank you for your response, > Avi. > > Ramaiah > > > -- > AGCS Business Development, 2500 W. Utopia Rd., Phoenix AZ 85027 > Ph: (602) 581-4324 Fax: (602) 581-4495 "Expand The Power Of Your Network" > ---End of forwarded mail from Avi Freedman <freedman(a)netaxs.com> -- AGCS Business Development, 2500 W. Utopia Rd., Phoenix AZ 85027 Ph: (602) 581-4324 Fax: (602) 581-4495 "Expand The Power Of Your Network"

1 0

Re: UUNet Routing SNAFU
by Mark Milhollan 09 Oct '97

09 Oct '97

>> What about the cable providers that have chunks of 24/8? > >62/8, 63/8 and 64/8 are being assigned now. > >So you just relax the filters according to what's being assigned. AT&T has been allocating customers from 12/8.

5 5

Re: UUNet Routing SNAFU
by Danny McPherson 09 Oct '97

09 Oct '97

> You may want to check out our configuration generation tool RtConfig in > http://www.isi.edu/ra/RAToolSet. RtConfig does a good job of generating those > 46K+ lines automatically from IRR. Generating ACLs from the IRRs and deploying the configs is no problem. Booting my router afterwards is.. -danny

1 0

Re: UUNet Routing SNAFU
by Danny McPherson 09 Oct '97

09 Oct '97

> And since I helped *create* the CA*net database *and* the CA*net route > filters based on the various DBs, yes, I meant RADB. How many providers actually apply prefix-based filtering (based on IRR objects) to other providers? I like the idea of prefix-based filtering applied to customers (by everyone that claims to be tier 1 & 2 (&3), at the very least), as well as the idea of configuring static filters for /19s and such, but if I were to build 46K++ lines of ACLs to filter prefixes from all eBGP peers for all registered prefixes (from several different registries) .. my routers wouldn't be manageable. -danny

3 2

Prefix filtering traditional A space (Was Re: UUNet Routing SNAFU)
by Mark Milhollan 09 Oct '97

09 Oct '97

>> AT&T has been allocating customers from 12/8. > >And how many routes has it been split up into? None that I can see, but I have darned limited views. I thought the thread was regarding preparation, rather than actuals.

1 0

UUNet Routing SNAFU
by prue＠ISI.EDU 09 Oct '97

09 Oct '97

At this time I am receiving a ton of bogus routes originating from AS701. This AS has hijacked all the /24 subnets of 128.1 through 128.1xx. Since the more specific route prevails in the cidr world they have managed to wipe out my network 128.9.0.0 not to mention a hundred other 128.x networks. This is not good. The third hand story I got from their hotline was that a core route crashed causing other core routers to crash. This doesn't explain anything to me. Are they using Ascend Giga routers in their core? Walt Prue

13 15

Re: UUNet Routing SNAFU
by jleddy＠mediaone.net 09 Oct '97

09 Oct '97

62.108/19 is assigned to A2000 a cable company in Amsterdam. RIPE is handing out pieces of 62/8. Please don't filter :) John Leddy MediaOne >No one is currently assigned 62/8, for example, so no one should be >announcing 62/8. > Jay B.

1 0