May 1999 - Test - lists.nanog.org

Re: Routing loop between Qwest and Sprint?
by Sean Donelan 18 May '99

18 May '99

>That'd lead me to believe that it's likely an issue internal to Sprint's >network, perhaps your query would be best directed to their NOC, versus NANOG. > I'd guess the greater majority of the NANOG distribution doesn't have access >to Sprint routers, so it's unlikely that they'll be able to correct the >problem. > >Directing your query to the Sprint NOC, or even Qwest NOC, is definitely much >more appropriate, assuming your concern is wrt regaining connectivity this >destination.. I tried opening a ticket by phone with Qwest's NOC. Guess what, I'm not a Qwest customer, so they couldn't find my account. I did send a message to Sprint. I haven't received a response from Sprint yet. I think if you check around, you'll find for those providers I have agreements with, I usually work out hairy problems with their senior network engineers pretty quickly, in private. For those providers who ditch me at their first-level support, I don't see an issue with bringing up the problem in other forum because I've found it helps get the problem fixed. However, like many things with routing, it is a bit simplistic to just say it is an issue internal to Sprint's network. It usually takes two providers to screw up inter-provider routing. This particular type of routing problem isn't that unusual, but it always seems to take a day for the two providers to stop saying call the other provider, and to actually clean everything up. It appears that Qwest announced a large set of more specific routes at one point in time for the CIDR block 205.169.0.0/16. Qwest tried to correct this at a later point, but it appears the problem in the software on some Sprint routers lost some of the route withdraws. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *> 205.169.17.0 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *> 205.169.21.0 144.232.129.97 90 0 1239 209 i *> 205.169.22.0 144.232.129.97 90 0 1239 209 i *> 205.169.23.0 144.232.129.97 90 0 1239 209 i *> 205.169.24.0 144.232.129.97 90 0 1239 209 i *> 205.169.25.0 144.232.129.97 90 0 1239 209 i *> 205.169.26.0 144.232.129.97 90 0 1239 209 i *> 205.169.27.0 144.232.129.97 90 0 1239 209 i *> 205.169.28.0 144.232.129.97 90 0 1239 209 i *> 205.169.29.0 144.232.129.97 90 0 1239 209 i *> 205.169.30.0 144.232.129.97 90 0 1239 209 i *> 205.169.37.0 144.232.129.97 90 0 1239 209 i *> 205.169.39.0 144.232.129.97 90 0 1239 209 i *> 205.169.40.0 144.232.129.97 90 0 1239 209 i *> 205.169.41.0 144.232.129.97 90 0 1239 209 i *> 205.169.42.0 144.232.129.97 90 0 1239 209 i *> 205.169.43.0 144.232.129.97 90 0 1239 209 i *> 205.169.45.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.55.0 144.232.129.97 90 0 1239 209 i *> 205.169.63.0 144.232.129.97 90 0 1239 209 i *> 205.169.68.0 144.232.129.97 90 0 1239 209 i *> 205.169.97.0 144.232.129.97 90 0 1239 209 i *> 205.169.101.0 144.232.129.97 90 0 1239 209 i *> 205.169.102.0 144.232.129.97 90 0 1239 209 i *> 205.169.105.0 144.232.129.97 90 0 1239 209 i *> 205.169.106.0 144.232.129.97 90 0 1239 209 i *> 205.169.107.0 144.232.129.97 90 0 1239 209 i *> 205.169.108.0 144.232.129.97 90 0 1239 209 i *> 205.169.112.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.122.0 144.232.129.97 90 0 1239 209 i *> 205.169.123.0 144.232.129.97 90 0 1239 209 i *> 205.169.124.0 144.232.129.97 90 0 1239 209 i *> 205.169.127.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.136.0 144.232.129.97 90 0 1239 209 i *> 205.169.137.0 144.232.129.97 90 0 1239 209 i *> 205.169.149.0 144.232.129.97 90 0 1239 209 i *> 205.169.153.0 144.232.129.97 90 0 1239 209 i *> 205.169.155.0 144.232.129.97 90 0 1239 209 i *> 205.169.158.0 144.232.129.97 90 0 1239 209 i *> 205.169.160.0 144.232.129.97 90 0 1239 209 i *> 205.169.163.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.165.0 144.232.129.97 90 0 1239 209 i *> 205.169.166.0 144.232.129.97 90 0 1239 209 i *> 205.169.170.0 144.232.129.97 90 0 1239 209 i *> 205.169.171.0 144.232.129.97 90 0 1239 209 i *> 205.169.174.0 144.232.129.97 90 0 1239 209 i *> 205.169.175.0 144.232.129.97 90 0 1239 209 i *> 205.169.177.0 144.232.129.97 90 0 1239 209 i *> 205.169.179.0 144.232.129.97 90 0 1239 209 i *> 205.169.180.0 144.232.129.97 90 0 1239 209 i *> 205.169.185.0 144.232.129.97 90 0 1239 209 i *> 205.169.188.0 144.232.129.97 90 0 1239 209 i *> 205.169.192.0 144.232.129.97 90 0 1239 209 i *> 205.169.198.0 144.232.129.97 90 0 1239 209 i *> 205.169.199.0 144.232.129.97 90 0 1239 209 i *> 205.169.200.0 144.232.129.97 90 0 1239 209 i *> 205.169.201.0 144.232.129.97 90 0 1239 209 i *> 205.169.203.0 144.232.129.97 90 0 1239 209 i *> 205.169.204.0 144.232.129.97 90 0 1239 209 i *> 205.169.205.0 144.232.129.97 90 0 1239 209 i *> 205.169.206.0 144.232.129.97 90 0 1239 209 i *> 205.169.207.0 144.232.129.97 90 0 1239 209 i *> 205.169.208.0 144.232.129.97 90 0 1239 209 i *> 205.169.210.0 144.232.129.97 90 0 1239 209 i *> 205.169.219.0 144.232.129.97 90 0 1239 209 i *> 205.169.222.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.226.0 144.232.129.97 90 0 1239 209 i *> 205.169.227.0 144.232.129.97 90 0 1239 209 i *> 205.169.228.0 144.232.129.97 90 0 1239 209 i *> 205.169.231.0 144.232.129.97 90 0 1239 209 i *> 205.169.232.0 144.232.129.97 90 0 1239 209 i *> 205.169.233.0 144.232.129.97 90 0 1239 209 i *> 205.169.234.0 144.232.129.97 90 0 1239 209 i *> 205.169.235.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i *> 205.169.245.0 144.232.129.97 90 0 1239 209 i *> 205.169.247.0 144.232.129.97 90 0 1239 209 i *> 205.169.251.0 144.232.129.97 90 0 1239 209 i *> 205.169.252.0 144.232.129.97 90 0 1239 209 i *> 205.169.254.0 144.232.129.97 90 0 1239 209 i odra-22> q later in the day, after my nanog message, it appears someone cleaned up that particular route. Notice the difference in the table below, 205.269.153.0 is no longer listed as a more specific. However, the other more specifics continued to be announced by Sprint. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *> 205.169.17.0 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *> 205.169.21.0 144.232.129.97 90 0 1239 209 i *> 205.169.22.0 144.232.129.97 90 0 1239 209 i *> 205.169.23.0 144.232.129.97 90 0 1239 209 i *> 205.169.24.0 144.232.129.97 90 0 1239 209 i *> 205.169.25.0 144.232.129.97 90 0 1239 209 i *> 205.169.26.0 144.232.129.97 90 0 1239 209 i *> 205.169.27.0 144.232.129.97 90 0 1239 209 i *> 205.169.28.0 144.232.129.97 90 0 1239 209 i *> 205.169.29.0 144.232.129.97 90 0 1239 209 i *> 205.169.30.0 144.232.129.97 90 0 1239 209 i *> 205.169.37.0 144.232.129.97 90 0 1239 209 i *> 205.169.39.0 144.232.129.97 90 0 1239 209 i *> 205.169.40.0 144.232.129.97 90 0 1239 209 i *> 205.169.41.0 144.232.129.97 90 0 1239 209 i *> 205.169.42.0 144.232.129.97 90 0 1239 209 i *> 205.169.43.0 144.232.129.97 90 0 1239 209 i *> 205.169.45.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.55.0 144.232.129.97 90 0 1239 209 i *> 205.169.63.0 144.232.129.97 90 0 1239 209 i *> 205.169.68.0 144.232.129.97 90 0 1239 209 i *> 205.169.97.0 144.232.129.97 90 0 1239 209 i *> 205.169.101.0 144.232.129.97 90 0 1239 209 i *> 205.169.102.0 144.232.129.97 90 0 1239 209 i *> 205.169.105.0 144.232.129.97 90 0 1239 209 i *> 205.169.106.0 144.232.129.97 90 0 1239 209 i *> 205.169.107.0 144.232.129.97 90 0 1239 209 i *> 205.169.108.0 144.232.129.97 90 0 1239 209 i *> 205.169.112.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.122.0 144.232.129.97 90 0 1239 209 i *> 205.169.123.0 144.232.129.97 90 0 1239 209 i *> 205.169.124.0 144.232.129.97 90 0 1239 209 i *> 205.169.127.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.136.0 144.232.129.97 90 0 1239 209 i *> 205.169.137.0 144.232.129.97 90 0 1239 209 i *> 205.169.149.0 144.232.129.97 90 0 1239 209 i *> 205.169.153.0 144.232.129.97 90 0 1239 209 i *> 205.169.155.0 144.232.129.97 90 0 1239 209 i *> 205.169.158.0 144.232.129.97 90 0 1239 209 i *> 205.169.160.0 144.232.129.97 90 0 1239 209 i *> 205.169.163.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.165.0 144.232.129.97 90 0 1239 209 i *> 205.169.166.0 144.232.129.97 90 0 1239 209 i *> 205.169.170.0 144.232.129.97 90 0 1239 209 i *> 205.169.171.0 144.232.129.97 90 0 1239 209 i *> 205.169.174.0 144.232.129.97 90 0 1239 209 i *> 205.169.175.0 144.232.129.97 90 0 1239 209 i *> 205.169.177.0 144.232.129.97 90 0 1239 209 i *> 205.169.179.0 144.232.129.97 90 0 1239 209 i *> 205.169.180.0 144.232.129.97 90 0 1239 209 i *> 205.169.185.0 144.232.129.97 90 0 1239 209 i *> 205.169.188.0 144.232.129.97 90 0 1239 209 i *> 205.169.192.0 144.232.129.97 90 0 1239 209 i *> 205.169.198.0 144.232.129.97 90 0 1239 209 i *> 205.169.199.0 144.232.129.97 90 0 1239 209 i *> 205.169.200.0 144.232.129.97 90 0 1239 209 i *> 205.169.201.0 144.232.129.97 90 0 1239 209 i *> 205.169.203.0 144.232.129.97 90 0 1239 209 i *> 205.169.204.0 144.232.129.97 90 0 1239 209 i *> 205.169.205.0 144.232.129.97 90 0 1239 209 i *> 205.169.206.0 144.232.129.97 90 0 1239 209 i *> 205.169.207.0 144.232.129.97 90 0 1239 209 i *> 205.169.208.0 144.232.129.97 90 0 1239 209 i *> 205.169.210.0 144.232.129.97 90 0 1239 209 i *> 205.169.219.0 144.232.129.97 90 0 1239 209 i *> 205.169.222.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.226.0 144.232.129.97 90 0 1239 209 i *> 205.169.227.0 144.232.129.97 90 0 1239 209 i *> 205.169.228.0 144.232.129.97 90 0 1239 209 i *> 205.169.231.0 144.232.129.97 90 0 1239 209 i *> 205.169.232.0 144.232.129.97 90 0 1239 209 i *> 205.169.233.0 144.232.129.97 90 0 1239 209 i *> 205.169.234.0 144.232.129.97 90 0 1239 209 i *> 205.169.235.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i *> 205.169.245.0 144.232.129.97 90 0 1239 209 i *> 205.169.247.0 144.232.129.97 90 0 1239 209 i *> 205.169.251.0 144.232.129.97 90 0 1239 209 i *> 205.169.252.0 144.232.129.97 90 0 1239 209 i *> 205.169.254.0 144.232.129.97 90 0 1239 209 i odra-22> q This afternoon, it appears someone has done some more cleanup. But hasn't gotten all of the more specifics yet. odra-22>show ip bgp 205.169.153.240 255.255.0.0 longer [...] Network Next Hop Metric LocPrf Weight Path *>i205.169.0.0/16 192.41.177.120 100 0 286 209 i * 204.70.27.9 90 0 3561 209 i * 144.232.129.97 90 0 1239 209 i *>i205.169.19.0 192.41.177.120 100 0 286 209 104 i * 204.70.27.9 90 0 3561 209 104 i * 144.232.129.97 90 0 1239 209 104 i *> 205.169.20.0 144.232.129.97 90 0 1239 209 i *>i205.169.47.0 192.41.177.120 100 0 286 209 i * 144.232.129.97 90 0 1239 209 i * 204.70.27.9 90 0 3561 209 i *> 205.169.48.0 144.232.129.97 90 0 1239 209 i *> 205.169.49.0 144.232.129.97 90 0 1239 209 i *> 205.169.50.0 144.232.129.97 90 0 1239 209 i *> 205.169.51.0 144.232.129.97 90 0 1239 209 i *> 205.169.54.0 144.232.129.97 90 0 1239 209 i *> 205.169.121.0 144.232.129.97 90 0 1239 209 i *> 205.169.134.0 144.232.129.97 90 0 1239 209 i *> 205.169.164.0 144.232.129.97 90 0 1239 209 i *> 205.169.223.0 144.232.129.97 90 0 1239 209 i *> 205.169.237.0 144.232.129.97 90 0 1239 209 i *> 205.169.239.0 144.232.129.97 90 0 1239 209 i odra-22>q -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Oleg Tabarovsky <olg(a)amt.ru> wrote: >Current state of IP multicast technology development looks more and more >similar to ATM stuff, both in development speed and complexity. >The same end ? :-) Yep. Simply people try to patch fundamental problems with hacks. That never worked, but then, that fact never discouraged from trying. Particularly when there's a significant population of marks who believe everything written in the trade rags. >Proper inter-domain multicast implementation will make state >volume manageable. Handwaving. How is it going to make it manageable, exactly? >> In any case, L3 mcasting seems to be pretty much dead. Replicating >> canned content is better done with caches, and conferencing requiries >> real MCUs which do things like speaker selection and noise suppression. >What about broadcasting ? Caches will not help. They particularly help in case of broadcasting, because content reuse rate is high. You can think of multicasting as of caching where each cache has zero retention time. (Caches do not have to delay delivery until the entire file/stream is loaded). >And, IMHO, any real life conferencing can pretty well live without multicast at all. Yep. I would say it is hard to implement a useful multiparty conferencing _with_ multicasting. (Yes, i'm fed up with H.323, H.225, H.245, Q.931, RTP, G.711, G.729, CSTA, TAPI, Megaco/MGCP, and the rest of the crap). --vadim

2 1

RE: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Alex Rudnev wrote: >On the other hand, why don't provide QoS in the non-overbooked network. >It's not difficult to install PRECEDENCE queue-control, just as negotiate >about some classes of service, to prevent short network bursts from >disturbing multimedia streams. Actually, it makes sense to do per-packet drop priority as opposed to precedence priority; in this case edge routers can arbitrarily tweak packet priorities w/o worrying about packet reordering in the network. >I'd like to ask one more question. Multicast, >Then someone else send second request. Why (WHY) can't RV server add >second DST address into the packet? Why can't you use the same, unicast, >address space for multicast services. Because IP multicasts are broken as designed? Actually, there are two multicasting approaches which use unicast address space to identify the multicasting channel: the Express multicast by David Cheriton & Co (Stanford U) and my earlier TRAP proposal. Both are significantly more scalable than the existing IP mcast; and the TRAP one has a property of not keeping any state in gateways which do not perform any packet replication. In any case, L3 mcasting seems to be pretty much dead. Replicating canned content is better done with caches, and conferencing requiries real MCUs which do things like speaker selection and noise suppression. Injection of end user-supplied routing information (JOIN/LEAVE requests) into the core backbones is not going to work in a real life, period. --vadim

2 1

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

"John A. Tamplin" <jat(a)LiveOnTheNet.COM> wrote: >This is assumes that the number of hosts attached are constant. If the >number of hosts grow exponentially, then the bandwidth required of the >network will grow faster than exponentially. I didn't notice any exponential growth of hosts in my home (although my bandwidth grew from 14.4 to a T-1 meanwhile). The exponential growth of _connected_ hosts was mostly fueled by connecting existing machines and by new computer users. Unless you have a recipe for getting people to breed much faster the end of that trend is pretty much in sight (witness PC makers killing themselves in scramble to the way-less-than-affluent market). --vadim PS. If you do know that secret recipe please keep it secret :)

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Pete Kruckenberg <pete(a)kruckenberg.com> wrote: >I think it is naive to assume that just because there is an >over-supply of bandwidth today that it will be that way >forever. Some assume, some do something to make sure it's going to be like that :) >Who knows when this will happen. With every dial-up customer >moving to DSL, cable and wireless, and stuff like voice and >video moving to IP-based networks, seems like it'll happen >sooner rather than later. I know at least one company which is going to be in field trials this year with the technology which can actually handle traffic in case if every household in US gets a T-1. >At 1000% annual growth rates >(according to Lord Sidgemore) in bandwidth usage, 1000%/yr sounds like BS. 200-400% is more like it. Reality check - see how backbones grow, not what marketing people say. >it'll be only a matter of a few years, even with >yet-to-be-deployed and yet-to-be-developed DWDM >enhancements. Never underestimate bandwidth of 1 sq ft. bundle of fibers. Even if no advances are made in WDM or femtosecond optical valve technology the petabit-per-second networks can still be built for cost comparable to the cost of POTS. --vadim PS Trend-wise speaking, backbones are catching up with host performance. Before long, hosts will become the bottleneck, not the network. After that, network growth will follow the same trend line as hosts: i.e. Moore's law performance increases with pretty much fixed cost.

1 0

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 18 May '99

18 May '99

Prabhu Kavi <prabhu_kavi(a)tenornetworks.com> wrote: > It's amazing that people continue to spout this "bandwidth is free" notion over > and over again. Based upon economics, could someone please explain to me how > service providers can run a business by giving away bandwidth? Well, free bandwidth and QoS-free networks are different notions. Absolutely, bandwidth is always going to cost something. This does not mean its rationing is desirable or economically (and technically!) feasible. And, yes, providers can have a business model of giving bandwidth away as long as they get to maintain stable customer relationships and perform services such as collection or advertising on behalf of some third parties. --vadim

2 1

Re: Routing loop between Qwest and Sprint?
by Danny McPherson 18 May '99

18 May '99

> Anyone know what is up between Qwest and Sprint? Hrmm..., at first glance it would appear to be a routing loop. > Trying to reach mapquest.com results in a loop between these routers when > it passes through Sprint. It works through other providers. That'd lead me to believe that it's likely an issue internal to Sprint's network, perhaps your query would be best directed to their NOC, versus NANOG. I'd guess the greater majority of the NANOG distribution doesn't have access to Sprint routers, so it's unlikely that they'll be able to correct the problem. Directing your query to the Sprint NOC, or even Qwest NOC, is definitely much more appropriate, assuming your concern is wrt regaining connectivity this destination.. Let me know if you have any problems contacting these folks.. -danny

1 0

Re: Is anyone actually USING IP QoS?
by jprovo＠ma.ultranet.com 18 May '99

18 May '99

pk>How the heck are people able to deploy native-IP networks pk>with these kinds of limitations/problems with QoS? Or did I pk>miss something about QoS recently? va>Yep. The biggest QoS secret is that nobody actually needs va>it. Bandwidth is cheap and is growing cheaper. The va>manpower needed to deploy and maintain QoS is getting va>more and more expensive. Overbuild strategies are the most common from what I've seen, but are also fragile. Technological history is replete with "overbuilds" that either ran into their end of life too soon, or were pressed into service far longer than the designers intended. [insert obligatory mickeysoft memory management flame-by-example] I'll agree that rather than concentrating on the latest and greatest QoS "if everyone adopted <foo> we'd be fine" strategies (that sound identical to the Promise of an ATM World), we should be concentrating on things that have been demonstrated to improve quality (CoS-based queueing, modern queue management, intra-domain CoS-tags, replacement of UDP by TCP wherever possible, content replication/caching, etc). The issue of adapting your CoS-queues -across the domain- to demand seems to me the sharp edge of real VoIP deployment. Cheers, Joe -- Disclaimer: "I'm the only one foolish enough to claim these opinions." Joe Provo, Manager 508.229.8400 x 3006 Interconnections and Technology Evaluation Fax 508.229.2375 Technology & Network Development, RCN <joe.provo(a)rcn.com>

2 1

Routing loop between Qwest and Sprint?
by Sean Donelan 18 May '99

18 May '99

Anyone know what is up between Qwest and Sprint? Trying to reach mapquest.com results in a loop between these routers when it passes through Sprint. It works through other providers. traceroute to 205.169.153.240 (205.169.153.240), 30 hops max, 38 byte packets 1 StLouis22-e3.dra.net (192.65.218.2) 0 ms 0 ms 0 ms 2 sl-gw2-kc-3-7.sprintlink.net (144.232.129.97) 10 ms 10 ms 10 ms 3 sl-bb2-kc-12-0.sprintlink.net (144.224.20.2) 10 ms 10 ms 10 ms 4 sl-bb11-kc-1-1.sprintlink.net (144.232.2.25) 10 ms 10 ms 10 ms 5 sl-bb11-chi-4-0.sprintlink.net (144.232.9.118) 20 ms 20 ms 20 ms 6 sl-bb10-chi-8-0.sprintlink.net (144.232.10.1) 20 ms 20 ms 20 ms 7 sl-bb11-chi-9-0.sprintlink.net (144.232.0.178) 20 ms 20 ms 20 ms 8 sl-bb10-nyc-0-0.sprintlink.net (144.232.8.201) 50 ms 40 ms 40 ms 9 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 40 ms 40 ms 40 ms 10 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 40 ms 40 ms 40 ms 11 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 40 ms 50 ms 50 ms 12 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 50 ms 40 ms 50 ms 13 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 50 ms 50 ms 50 ms 14 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 50 ms 40 ms 50 ms 15 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 50 ms 50 ms 50 ms 16 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 50 ms 50 ms 50 ms 17 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 80 ms 50 ms 50 ms 18 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 50 ms 50 ms 50 ms 19 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 50 ms 50 ms 50 ms 20 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 50 ms 50 ms 50 ms 21 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 60 ms 50 ms 60 ms 22 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 60 ms 60 ms 60 ms 23 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 50 ms 50 ms 50 ms 24 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 60 ms 60 ms 60 ms 25 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 50 ms 60 ms 50 ms 26 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 60 ms 60 ms 60 ms 27 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 60 ms 60 ms 50 ms 28 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 60 ms 60 ms 60 ms 29 sl-bb12-pen-8-0-622M.sprintlink.net (144.232.9.102) 60 ms 60 ms 60 ms 30 sl-bb10-nyc-6-0-622M.sprintlink.net (144.232.9.101) 70 ms 70 ms 60 ms -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

FIBER: last night Indiana, Kentucky
by Sean Donelan 18 May '99

18 May '99

A bit of catch up. A report that MCI/Worldcom is still working a fiber outage between Connorsville, IN and Liberty, IN, estimated 300 DS3s affecting services in Kentucky and Indiana. It occured about 9:30pm, but severe storm damage is hampering repair efforts. Apparently a lot of trees and live power lines are down in the area. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0