- Test - lists.nanog.org

Fiber Cut in Jax AREA - Affecting UUnet...others?
by Scott Averbach 15 Jul '98

15 Jul '98

Just got off the phone with UUnet and appearently there is a fiber cut there.... Ticket UU895684 - Their blanket ticket number for this incident... just an FYI Scott Averbach Network Analyst Hiway Technologies

1 0

UUnet broken `?
by Winfried Haug 15 Jul '98

15 Jul '98

Hi, we see very high TTL to many US destinations. Beside asymetric routing it seems to be a uunet problem... can anybody confirm this ? TO nitrous.digex.net: 3 Stuttgart.seicom.NET (194.97.216.22) 29.801 ms 21.646 ms 20.728 ms 4 Frankfurt-s0.seicom.NET (194.97.193.10) 31.776 ms Frankfurt-s1.seicom.NET (194.97.193.14) 20.876 ms Frankfurt-s0.seicom.NET (194.97.193.10) 21.808 ms 5 us-gate.Frankfurt.seicom.NET (195.254.80.41) 47.943 ms 45.519 ms 25.216 ms 6 195.219.64.209 (195.219.64.209) 36.325 ms 30.744 ms 29.361 ms 7 195.219.64.209 (195.219.64.209) 59.212 ms 41.559 ms 32.213 ms 8 195.219.64.238 (195.219.64.238) 105.072 ms Teleglobe.net (207.45.215.2) 115.584 ms 104.231 ms 9 gin-nyy-ac1.Teleglobe.net (207.45.199.233) 170.581 ms 160.385 ms 124.512 ms 10 sl-gw16-pen-2-0.sprintlink.net (144.228.164.61) 135.087 ms 152.616 ms 142.091 ms 11 sl-bb10-pen-3-1.sprintlink.net (144.232.5.93) 1029.545 ms 929.967 ms 907.473 ms 12 144.232.5.62 (144.232.5.62) 957.565 ms 886.067 ms 925.234 ms 13 sprint-nap.digex.net (192.157.69.42) 348.060 ms 1306.569 ms * 14 phl1-core1-h1-0.atlas.digex.net (165.117.50.77) 209.121 ms sprint-nap.digex.net (192.157.69.42) 229.315 ms phl1-core1-h1-0.atlas.digex.net (165.117.50.77) 367.977 ms 15 dca3-core1-h1-0.atlas.digex.net (165.117.50.69) 523.725 ms 1728.589 ms 1486.675 ms 16 dca1-core4-h1-0.atlas.digex.net (165.117.50.65) 562.890 ms 1606.708 ms 1327.118 ms 17 dca1-core3-fa6-0-0.atlas.digex.net (165.117.16.3) 1214.027 ms * 1175.428 ms 18 * * * 19 * nitrous.digex.net (205.197.249.3) 1201.812 ms * FROM nitrous.digex.net: 1 iad1-core2-fa5-0-0.atlas.digex.net (165.117.129.2) 0 msec 0 msec 0 msec 2 dca5-core2-h8-0-0.atlas.digex.net (165.117.53.41) 0 msec 4 msec 4 msec 3 dca5-core1-fa1-0-0.atlas.digex.net (165.117.54.1) 4 msec 4 msec 4 msec 4 Hssi3-1-0.BR1.DCA1.ALTER.NET (209.116.159.98) 0 msec 4 msec 4 msec 5 101.ATM2-0.XR2.DCA1.ALTER.NET (146.188.160.238) [AS 701] 0 msec 0 msec 0 msec 6 294.ATM2-0.TR2.DCA1.ALTER.NET (146.188.161.154) [AS 701] 4 msec 0 msec 4 msec 7 101.ATM6-0.TR2.NYC1.ALTER.NET (146.188.136.218) [AS 701] 28 msec 32 msec 28 msec 8 * 298.ATM6-0.XR2.NYC1.ALTER.NET (146.188.178.201) [AS 701] 28 msec 36 msec 9 194.ATM8-0-0.GW2.NYC2.ALTER.NET (146.188.178.149) [AS 701] 32 msec 32 msec 32 msec 10 teleglobe.ny2-gw.customer.ALTER.NET (157.130.4.166) [AS 701] 588 msec 596 msec 604 msec 11 gin-nyy-ac1.Teleglobe.net (207.45.201.37) [AS 6453] 644 msec 588 msec 668 msec 12 gin-ppt-bb1.Teleglobe.net (207.45.199.234) [AS 6453] 600 msec 552 msec 672 msec 13 Teleglobe.net (207.45.215.1) [AS 6453] 700 msec 668 msec 672 msec 14 195.219.64.237 [AS 8297] 916 msec * 888 msec 15 * * 195.219.64.210 [AS 8297] 824 msec 16 * de-gate.Frankfurt.seicom.NET (195.254.80.11) [AS 5549] 1032 msec 928 msec 17 Stuttgart-s6.seicom.NET (194.97.193.13) [AS 5549] 908 msec de-gate.Frankfurt.seicom.NET (195.254.80.11) [AS 5549] 860 msec Stuttgart-s5.seicom.NET (194.97.193.9) [AS 5549] 1280 msec Winfried -- Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7433 1449-X haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug(a)seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X 34 Mbit Teleglobe * 100 MBit DE-CIX * 2 MBit INXS * 2 Mbit Belwue * 34 Mbit WIN

6 6

Re: NOC communications
by Sean Donelan 14 Jul '98

14 Jul '98

>OK, but large providers don't want to talk to small providers. It's >a stated policy of many networks to refer a smaller customer/provider >to their upstream. I only want to talk to someone who's competent Heck, I only want to talk to someone who is competent too. However, I would not say there is a direct relationship between the size of a provider and the competency of its engineers. It has been my experience you are much more likely you get a clueless person with no authority to fix anything when you call a larger provider about a problem than when you call a smaller provider. Could a reason they get a lot of calls, is they are the root cause of a lot of problems? Even chaos has its reasons. The actual policy of many major networks seems to be to direct everyone to call someone else. The reason I call other providers is because the major providers/upstreams DO NOT do a good job of refering their customer's tickets between themselves even when I pay them money. I've been told by various major providers I should directly call another provider's NOC about a problem. In some cases both providers have been owned by the same corporation, but they refused to refer a trouble-ticket between their two NOCs. I don't have a way of knowing the types of quantity of inappropriate calls a typical larger ISP's NOC receives. I also don't know how many calls a typical larger ISP's NOC inappropriately blows off. If it takes me five phone calls to finally reach someone who understands the problem, AND has the authority to fix it, how do the NOC engineers count the previous four phone calls they ignored? If the upstream providers didn't tell their customers to call the other providers, and had better inter-NOC communications, perhaps fewer people would call other providers directly because they would know their own provider's NOC has better inter-NOC communication and could resolve the problem faster? If you have question about your electric bill, you call the electric company. If there are wires down and sparking in your front yard, you call 9-1-1 because they have better access to the electric company's emergency lines than you do. >My point is only that there is always a pecking order and by making >network ops egalitarian you end up with a high signal/noise ratio, >or worse yet, all the people who actually are relevant leave. >(Witness NANOG: half the people from MCI etc. don't read any more) I thought half the people from MCI left to join small startup companies :-) I wonder if they are now finding out just how difficult their former employer is to deal with now that they are on the outside looking in. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

EU-IBMnet? IPaddr 32.xxx
by Rob M VanHooren 14 Jul '98

14 Jul '98

Is it just me or is IBM GlobalNet leaking this into their F/R cloud on purpose? Supposedly a private VPN (albeit transiting PSDN) and here I've got 32.74.50.217 leaking all over the place? Anybody know what's up? --Rob. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 Network Engineering Services 171 Queens Avenue, Suite 320 Linkdata Communications Inc. ASN:10856 London, CANADA Good things come to those who wait. Patience is a virtue. Yadda Yadda Yadda

1 0

Re: EU-IBMnet? IPaddr 32.xxx
by Sean Butler 14 Jul '98

14 Jul '98

>Is it just me or is IBM GlobalNet leaking this into their F/R cloud on >purpose? Supposedly a private VPN (albeit transiting PSDN) and here I've >got 32.74.50.217 leaking all over the place? > >Anybody know what's up? > --Rob. Please contact me off-line directly and we can discuss further... Thanks, Sean ___________________________________ Sean Butler IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler(a)us.ibm.com

1 0

Network Engineer salaries?
by David L. Wasley 14 Jul '98

14 Jul '98

While this is not an operational issue directly, it certainly is indirectly! We are discussing and trying various ways to get a good perspective on Network Engineer salaries: what do you have to pay staff to be competitive in today's job market? I realize this varies from locale to locale but people do move a lot these days. If you are willing, please email to me directly (please don't bother the list) what you think the salary range (low/average/high not including benefits) for the following general job classifications is today: 1) Network Technicians: The staff who watch the monitors, answer the phones, maintain status quo, and generally resolve first level problems; 2) Network Engineers: The staff who resolve difficult problems, design network extensions and enhancements, and manage new installations; 3) Network Designers: The highest level of 'cluefulness' who design new networks and may also manage the rest of the staff (in their spare time :-). Please try to be as realistic as possible. Please indicate the locale in which your figures would apply. Thanks in advance, David Wasley University of California ________________________________________ Information Resources & Communications 510-987-0445 UC Office of the President FAX 510-451-4340

1 0

RA.NET zone stripped down?
by Jonathan Hartford 14 Jul '98

14 Jul '98

Either I need more caffeine in the morning, or... Both MX(s) and CNAME(s) appear to be missing from the RA.NET zonefile on dns{|2|3}.merit.net. Needless to say, a bit frustrating for those trying to mail in modifications... % dig axfr ra.net @dns.merit.net ; <<>> DiG 8.1 <<>> axfr ra.net @dns.merit.net ; (1 server found) $ORIGIN ra.net. @ 2D IN SOA dns.merit.net. dns.merit.net. ( 199807140 ; serial Fresh serial. Perhaps some kind of human error? -- Jon Hartford

2 1

RE: NOC communications
by Derek Elder 14 Jul '98

14 Jul '98

The thing that needs to be understood is that if we as an industry don't fix this problem, the government will fix it for us. The government won't care if there is a distinction between a "Big" or "Small" guy amongst ISP's anymore than they will between SBC or BellSouth and some Mom&Pop local Telco. I think that this attitude is -precisely- what the legislators will decide to fix. $.02 Derek Elder US Web / Gray Peak Technologies Network Engineering 212-548-7468 Pager - 888-232-5028 delder(a)graypeak.com http://www.usweb.com A Strategic Partner for the Information Age. -----Original Message----- From: Hui-Hui Hu [mailto:hhui@arcfour.com] Sent: Tuesday, July 14, 1998 12:44 AM To: delder(a)graypeak.com Subject: Re: NOC communications OK, but large providers don't want to talk to small providers. It's a stated policy of many networks to refer a smaller customer/provider to their upstream. I only want to talk to someone who's competent (I get really sick of kids who have just discovered traceroute and send me e-mail, or worse yet call me, because they don't understand what "administratively denied" means) . My point is only that there is always a pecking order and by making network ops egalitarian you end up with a high signal/noise ratio, or worse yet, all the people who actually are relevant leave. (Witness NANOG: half the people from MCI etc. don't read any more) I don't have a solution, unfortunately. Sigh. -h : Shouldn't be that hard to verify that someone is actually a network : provider. Criteria is, run a public network, you qualify. Pretty simple.

1 0

Re: T3 to E3 conversions
by Sean M. Doran 14 Jul '98

14 Jul '98

| We buy our transatlantic stuff with T3 ports either end, all our domestic | private circuits as T3s, and everything else internationally is carried | on circuits which use SDH and the "T" hierarchy. May be I'm unusual in | this respect, but I know people who have bought from BT and got T3s too. In places like 60 Hudson St or 111 8th Av, or anywhere at all in Europe that Colt or MFS (as examples) go, you should push for a full VC3 rather than just a T3 or E3, assuming you have a way of using it. Elsewhere you will more likely be stuck with T3 or E3. | No, I don't know why at the E1/T1 level E1 is the preferred way of doing it. It's historical. Terminating E1s in D.C. (or anywhere else in the US beyond the switches talking to the cables) was a mess involving special gear. Terminating T1s in Europe "couldn't be done". These days, since there are the VT1.5 and VT2 in SONET land and the TU-11 and TU-12 in SDH land, the "standards gap" is fixed by digital cross-connection; the choice of T1 vs E1 payload is mostly down to who has the right trib cards, and who has the most PDH cruft in the way, or (cynically) down to E1s likely bringing in more revenue. Sean.

1 0

Re: T3 to E3 conversions
by Sean M. Doran 14 Jul '98

14 Jul '98

| How do carriers handle E3 to T3 conversions? They don't. That is, they don't convert. It is possible to carry an E3 inside a PDH T3, but it's very ugly. These days an E3 or a T3 is carried inside an SDH VC3, which is then carried in a VC4, which is then carried inside an STM-1 or an OC3, and broken out of the final SDH or SONET ADM by using an appropriate trib card. (At the "final" SDH or SONET ADM, a T3 payload may be digitally cross-connected to a T3 that will be carried in a disjoint SONET network. This avoids dedicating an OC3 to carry the VC4/VC3 structure). If you are fortunate and have an end-to-end SDH/SONET path, then you can use a VC3 in any way you want. Typically, however, for transatlantic traffic, you have to choose one or the other, or an ugly hybrid that uses an E3-in-T3 scheme, because someone will be using PDH gear in the end-to-end path. Usually, the reason you can't do an entire VC3 is because the US carrier doesn't want to waste bandwidth (as above). The commoner case is that you can't do a T3 end-to-end because a non-US carrier has PDH gear in the path that can only do E3s, as SDH has a formally specified and widely implemented means of carrying around T3s. | What equipment is used? The ICM E3 path formerly used by NORDUNET was an E3 from Stockholm to London, connecting to a Cisco router ("speed converter"), and a DS3 from London to Pennsauken, connected to another port on the "speed converter". The "speed converter" ended up being a "TDM" of sorts, since an 8Mbps circuit was eventually stuck to yet another port. This was not an SDH/SONET issue, however; SDH-using or SONET-using cables are quite new. | have heard that trans-Atlantic carriers sell E3s to Europeans when in fact | it is a T3 with T3 costs passed on the customer and merely convert the line | from T3 to E3 - thereby causing 11Mb/sec of b/w to be wasted. Any truth to | that? The T3 and E3 tarriffs are probably the same, but nobody in their right mind would waste even more of a VC3 deliberately by forcing you to take an E3 instead, not even (most) PNOs, since they'd have to coordinate PDH encapsulation. But not all cables and land paths are SDH or SONET yet... Sean.

1 0