- Test - lists.nanog.org

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 22 Sep '98

22 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

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

22 Sep '98

1 0

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

21 Sep '98

>A has not been the authoritative source for .GOV for a while. >Check G.ROOT-SERVERS.NET. Check WHOIS, it lists a.root-servers.net as a name server. Registrant: Government (US Federal) top-level domain (GOV-DOM) General Services Administration Center for Electronic Messaging Technologies 1800 F Street, NW Washington, DC 20405 Domain Name: GOV Administrative Contact, Technical Contact, Zone Contact: Borgoyne, Gary (GB260) gary.borgoyne(a)FED.GOV 202-501-6824 202-501-1337 Record last updated on 02-Oct-97. Record created on 01-Jan-85. Database last updated on 21-Sep-98 04:08:47 EDT. Domain servers in listed order: A.ROOT-SERVERS.NET 198.41.0.4 H.ROOT-SERVERS.NET 128.63.2.53 B.ROOT-SERVERS.NET 128.9.0.107 C.ROOT-SERVERS.NET 192.33.4.12 D.ROOT-SERVERS.NET 128.8.10.90 E.ROOT-SERVERS.NET 192.203.230.10 I.ROOT-SERVERS.NET 192.36.148.17 F.ROOT-SERVERS.NET 192.5.5.241 G.ROOT-SERVERS.NET 192.112.36.4 whois: whois.nic.gov web: www.nic.gov email: registrar(a)nic.gov To see this host record with registered users, repeat the command with a star ('*') before the name; or, use '%' to show JUST the registered users. The InterNIC Registration Services database contains ONLY non-military and non-US Government Domains and contacts. Other associated whois servers: American Registry for Internet Numbers - whois.arin.net European IP Address Allocations - whois.ripe.net Asia Pacific IP Address Allocations - whois.apnic.net US Military - whois.nic.mil US Government - whois.nic.gov Besides even if it wasn't also server the domain, the root-servers should still return the NS records of the servers that are servering top-level domains. See for example the DIG for the SG top level domain. # dig @198.41.0.4 sg. ns ; <<>> DiG 2.2 <<>> @198.41.0.4 sg. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 5, Auth: 0, Addit: 5 ;; QUESTIONS: ;; sg, type = NS, class = IN ;; ANSWERS: sg. 172800 NS DNSSEC1.SINGNET.COM.sg. sg. 172800 NS AUTH02.NS.UU.NET. sg. 172800 NS NS.RIPE.NET. sg. 172800 NS DS.NIC.NET.sg. sg. 172800 NS NS1.PACIFIC.NET.sg. ;; ADDITIONAL RECORDS: DNSSEC1.SINGNET.COM.sg. 172800 A 165.21.83.11 AUTH02.NS.UU.NET. 172800 A 198.6.1.82 NS.RIPE.NET. 172800 A 193.0.0.193 DS.NIC.NET.sg. 172800 A 202.42.194.205 NS1.PACIFIC.NET.sg. 172800 A 192.169.33.3 ;; Total query time: 253 msec ;; FROM: drgate.dra.com to SERVER: 198.41.0.4 ;; WHEN: Mon Sep 21 18:58:24 1998 ;; MSG SIZE sent: 20 rcvd: 237 -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

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-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

3 2