September 1998 - Test - lists.nanog.org

Re: long delay between circuits..
by jhyang 23 Sep '98

23 Sep '98

I got several replies,, and I investigated it more. We are using tiered T3 service from uu.net, and I suspect that uu.net use ATM QoS scheme between hop 4 and hop 5. (We are using 30 Mbps from uu.net) (But, I knew that the way of tiered bandwidth was using control of CSU -LARSCOM-.) Is it true that uu.net use ATM QoS scheme (i.e. rate control by leaky bucket algorithm) for shaping bandwidth ? When the link has avaible bandwidth, the response time of PING is much faster. But the RTT of PING is slow when the link goes to peak rate. --But there are no *packet loss*-- I think it is similar to *rate control*. Is there any comments ? ---Jaeho Yang. Harold Willison wrote: > > At 03:49 PM 9/16/98 +0900, you wrote: > >Hello, > > > >I want to hear advices from gurus,, > > > > Our network use transit service from UU.NET in PaloAlto IX. > > > > ## the result of traceroute from our network to www.sun.com > > traceroute to Sun.COM (192.9.49.33), 30 hops max, 40 byte packets > > --<snip>-- > > 4 INET-PA-GW.nuri.net (203.235.119.253) 147 ms 145 ms 143 ms > > 5 911.Hssi5-0.GW1.PAO1.ALTER.NET (157.130.192.145) 170 ms 169 ms > >173 ms <-----@@@@ > > 6 119.ATM3-0.XR1.SCL1.ALTER.NET (146.188.144.78) 486 ms 434 ms 441 > >ms <-----@@@@ > > 7 146.188.145.157 (146.188.145.157) 432 ms 440 ms 443 ms > > 8 core7-hssi5-0.SanFrancisco.mci.net (206.157.77.73) 408 ms 457 ms > >425 ms > > --<snip>-- > > I would suggest getting UUnet to do perform 2 traceroutes back to your originating address. > > The problem could be that when your traffic hits hop 6 it has a different return route which > has poorer performance. > If UUnet performs the traceroutes from the hop 5 and hop 6 routers towards you you will see the path both > takes. If they are both the same path then it would definately appear to be a problem on their > link. If the route back from hop 5 is different than from hop 4 I would suggest checking for the problem spot > in that traceroute. > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > | Harold Willison AGIS Network Engineering | > * Senior Network Engineer 313-730-5151 * > | noc(a)agis.net 313-730-1130 x-5649 | > | harold(a)agis.net 24 hours a day, 7 days a week | > | http://www.agis.net | > \*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

1 0

Re: Sat phones
by Sean Donelan 23 Sep '98

23 Sep '98

ryan Wann <bwann(a)cwis.net> writes: >Maybe we should have these one-call utility line/main marking services >cross-reference who's fiber they're tagging, and give the respective >carriers a heads-up warning before actual excavating begins... :) The story told by the sales people is each carrier has people which check their fiber routes every day. The underground utility marking services are supposed to complete their marking at least 24 hours before the excavation work is scheduled to begin. Thus giving time for the carrier people who supposedly check their rights of way every day fair notice. They say this with a straight face, so I guess they believe themselves. In practice, I would expect excavators careful enough to have all the underground utilities marked ahead of time, are also careful during their digging. The problems seem to come from diggers which don't bother to get things marked before digging. Not to mention trains, gophers, floods, sharks, and even lightning strikes which will never call before chewing up a right of way. In other words, fiber cuts may be reduced, but never eliminated. Network designers (and managers) must decide what frequency of outages and mean time to repair are acceptable, and plan accordingly. Is N:N, N:1 or N:0 redundancy ok? I know the answer for my network, I don't know the answer for your network. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Frame Relay encap vis-a-vis point-to-point at UUNET
by Jerry Scharf 22 Sep '98

22 Sep '98

the engineer gave it to you straight. They use cascades reduce the per port costs on the cisco. Cisco recently added channellized T3s, but this is years after UUNET made their design decisions. I know htis because I heard it from the person who did hte design at UUNET. jerry

7 6

Re: Frame Relay encap vis-a-vis point-to-point at UUNET
by Dean Anderson 22 Sep '98

22 Sep '98

At 06:17 PM 9/22/98 -0400, Jeff Mcadams wrote: >Incidentally, we're straight into the router port and still using f/r >encap. I'm not really sure of the reasoning behind this, but >apparently, the edict came down from on high that all new turn-ups would >use frame-relay encap...even if straight into a router port. *shrug* I would speculate that the reason is that PVC's are easier to move around within a FR cloud, allowing one to reconfigure with less headache. Your T1 is moved to a new router or location with "just a PVC rebuild". --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Frame Relay encap vis-a-vis point-to-point at UUNET
by Dan Jones 22 Sep '98

22 Sep '98

You've hit the proverbial nail on the head. But there is a customer-perception story to be told here. I think most customers realize that any provider's backbone is overbooked at some level. Most backbone links are probably not as large as the sum of all customer connections coming in. That's packet switching for you. But I think most T1 customers think that they are getting a full T1 from their location to the edge of the provider's backbone. What the model at hand (and emerging connectivity models like cable modems & xDSL) are doing is pushing the definition of 'edge' closer to the customer. In addition to general backbone congestion, now the customer has to contend with congestion in their neighborhood (cable head-end or xDSL DSLAM). That's fine for Frame Relay customers since they presumably understand what FR is all about & can choose their CIR/port speed wisely. But I tend to think that a customer who purchases a pt-pt T1 to reach their provider's network wants the full T1 all the way to the router on the other end. It'll be intersting to see if xDSL etc manages to change that expectation. Dan At 02:32 PM 9/22/98 -0400, Vijay Gill wrote: >On Mon, 21 Sep 1998, Dan Jones wrote: > >> However, the statement 'would not suffer any bandwidth loss from >> using f/r encap' is largely dependent on the overbooking of those >> aggregation ports. If it were me, I would a) make sure that 'full CIR' >> meant line speed & b) want an assurance that the aggregation ports were >> >= the sum of all line speeds mapped to them. Otherwise, one could very >> well argue that those connections are not pt-pt at all but FR clouds >> collapsed onto an on-site FR switch. >> >> If there is any overbooking going on on those aggregation >> connections, you are not getting your T1's worth and might as well have >> bought a FR connection in the first place. > > The point where the congestion and overbooking takes place might be >anywhere along the source/destination pair. Assuming provider A was >aggregating customers directly onto CT3 cards instead of frame relay >switches. > >The customer is now happy with his "point to point link." Now, further >assuming the uplink from the customer aggregation equipment, to the >backbone transist system is worth X Mbps, then directly terminating a >number of connections onto the gateway with an aggregate _peak_ bandwidth >of greater than X Mbps just moves the choke point up further, to the >transist <--> Customer aggregation equipment link. This can be moved up to >any point in the network. > >This is where aggresive monitoring and proactive retermination and/or >addition of more resources come in. > >-- >Vijay Gill |The (paying) customer is always right. >wrath(a)cs.umbc.edu, vijay(a)umbc.edu | - Piercarlo Grandi >http://www.gl.umbc.edu/~vijay | Eagles may soar, but weasels don't get >These are my opinions only. | sucked into jet engines. > >

1 0

GTEILEC cable cut in Beaverton, OR
by Michael Schrimshaw 22 Sep '98

22 Sep '98

Somebody boring holes in the ground didn't get a locate, so we have this (straight from the horses mouth): ***Note #27 09-22-1998 17:22:56 GMT Cable Cut Glen/GTE reports that the GTEILEC has suffered a cable cut, and adds that multiple reports are being generated due to the trouble. Glen explains that the source of the cable trouble has not been found yet, and can offer no ETR. ======================== Most impacted are Beaverton, Aloha, and Hillsboro OR. Mike Mike Schrimshaw | "Whatever their future, at the dawn of their BOFH, System Engineer | lives, men seek a noble vision of man's nature Aracnet Internet Services | and of life's potential." -- Ayn Rand -------------------------------------------------------------------

1 0

Re: the GOV top-level domain
by Mathias Koerber 22 Sep '98

22 Sep '98

You're right, I'm seeing the same from here: $ dig @a.root-servers.net gov. any ; <<>> DiG 8.1 <<>> @a.root-servers.net gov. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; gov, type = ANY, class = IN ;; AUTHORITY SECTION: . 1D IN SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1998092000 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ;; Total query time: 603 msec ;; FROM: matjes to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Tue Sep 22 07:39:13 1998 ;; MSG SIZE sent: 21 rcvd: 94 -----Original Message----- From: Sean Donelan <SEAN(a)SDG.DRA.COM> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Tuesday, September 22, 1998 7:36 AM Subject: the GOV top-level domain |Is it just me, or are other people having trouble with the GOV |domain today. | |The a.root-server.net doesn't seem to be returning the NS records |for the GOV domain. I'm not a 'dig' expert, so what am I doing |wrong? | |Here is a normal DIG response for the COM top-level domain | |# dig @198.41.0.4 com. ns |; <<>> DiG 2.2 <<>> @198.41.0.4 com. ns |; (1 server found) |;; res options: init recurs defnam dnsrch |;; got answer: |;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 |;; flags: qr aa rd; Ques: 1, Ans: 11, Auth: 0, Addit: 11 |;; QUESTIONS: |;; com, type = NS, class = IN | |;; ANSWERS: |com. 518400 NS C.ROOT-SERVERS.NET. |com. 518400 NS D.ROOT-SERVERS.NET. |com. 518400 NS E.ROOT-SERVERS.NET. |com. 518400 NS I.ROOT-SERVERS.NET. |com. 518400 NS F.ROOT-SERVERS.NET. |com. 518400 NS G.ROOT-SERVERS.NET. |com. 518400 NS J.GTLD-SERVERS.NET. |com. 518400 NS K.GTLD-SERVERS.NET. |com. 518400 NS A.ROOT-SERVERS.NET. |com. 518400 NS H.ROOT-SERVERS.NET. |com. 518400 NS B.ROOT-SERVERS.NET. | |;; ADDITIONAL RECORDS: |C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 |D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 |E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 |I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 |F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 |G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 |J.GTLD-SERVERS.NET. 518400 A 198.41.0.21 |K.GTLD-SERVERS.NET. 518400 A 195.8.99.11 |A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 |H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 |B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 | |;; Total query time: 261 msec |;; FROM: drgate.dra.com to SERVER: 198.41.0.4 |;; WHEN: Mon Sep 21 18:19:02 1998 |;; MSG SIZE sent: 21 rcvd: 402 | | |Here is a DIG response for the GOV top-level domain, notice |it just returns an SOA record for the a.root-servers.net, no |NS records. | | |# dig @198.41.0.4 gov. ns |; <<>> DiG 2.2 <<>> @198.41.0.4 gov. ns |; (1 server found) |;; res options: init recurs defnam dnsrch |;; got answer: |;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 |;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0 |;; QUESTIONS: |;; gov, type = NS, class = IN | |;; AUTHORITY RECORDS: |. 86400 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( | 1998092000 ; serial | 1800 ; refresh (30 mins) | 900 ; retry (15 mins) | 604800 ; expire (7 days) | 86400 ) ; minimum (1 day) | |;; Total query time: 269 msec |;; FROM: drgate.dra.com to SERVER: 198.41.0.4 |;; WHEN: Mon Sep 21 18:18:50 1998 |;; MSG SIZE sent: 21 rcvd: 94 | | | |Here is a DIG response for a non-existant top-level domain, |same type of response as for the GOV domain. | |# dig @198.41.0.4 kasdgkasdgk. ns |; <<>> DiG 2.2 <<>> @198.41.0.4 kasdgkasdgk. ns |; (1 server found) |;; res options: init recurs defnam dnsrch |;; got answer: |;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 |;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0 |;; QUESTIONS: |;; kasdgkasdgk, type = NS, class = IN | |;; AUTHORITY RECORDS: |. 86400 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( | 1998092000 ; serial | 1800 ; refresh (30 mins) | 900 ; retry (15 mins) | 604800 ; expire (7 days) | 86400 ) ; minimum (1 day) | |;; Total query time: 273 msec |;; FROM: drgate.dra.com to SERVER: 198.41.0.4 |;; WHEN: Mon Sep 21 18:23:23 1998 |;; MSG SIZE sent: 29 rcvd: 102 | | |-- |Sean Donelan, Data Research Associates, Inc, St. Louis, MO | Affiliation given for identification not representation |

2 1

MTBF for power supplies
by Joseph Thomas 22 Sep '98

22 Sep '98

Hope this isn't too far off topic... We're looking to beef up some of the equipment in our data center's core backbone and one of the topics we're looking at is redundant power supplies (specifically for Cisco 7000/7500 chasis's). Cisco claims that the "observed" (vs. design - which I don't know) MTBF is 2,000,000 hours for these supplies. Without much to back this up, this number seems awfully high. Does anyone have any pointers to MTBF numbers for network equipment (not necessarily Cisco related) and/or any of their own experiences to relate? We have had one power supply fail already (I don't know the MTBF but certainly an order or two less than the number Cisco gave) and at that time, we pulled a supply from another box. At the moment, we don't have enough of whatever (spare ports, extra supplies, etc.) to do that anymore. Any info appreciated. Thanks. -- Joseph Thomas E/Mail: jpt(a)networkcs.com Network Computing Services, Inc. jpt(a)magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 An elephant is a mouse with an operating system.

1 0

Re: IXC Fibre cut IL,OH
by Dean Anderson 22 Sep '98

22 Sep '98

So, the requirement should not only be 24 hour NOC, but GSM phone with other provider? --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: the GOV top-level domain
by Sean Donelan 21 Sep '98

21 Sep '98

>Is it just me, or are other people having trouble with the GOV >domain today. The a.root-servers.net has gotten reloaded with a new GOV zone file serial number 1998092100. Things seem a lot better now. Yes, I did call NSI before posting on NANOG. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0