- Test - lists.nanog.org

Re: Impressive multi-hop routing loop
by Dan Bustillos - Datalink Computer Services 21 May '99

21 May '99

Hey, It looks more like the Ethernet port on the foothill.net router is turned off. Had this happen to me before--dan Thank you, Dan Bustillos Datalink Computer Services (530) 897-6400 (888) 328-4638 ******************* "Error, No Keyboard - Press F1 to continue" Only on a PC would you see this error. Never on my mac.

1 0

Impressive multi-hop routing loop
by J.D. Falk 20 May '99

20 May '99

Script started on Thu May 20 15:07:47 1999 jdfalk@unagi [Thu 15:07] 5 /usr/home/jdfalk>traceroute -m 255 www.monkeys.com traceroute to www.monkeys.com (207.212.142.41), 255 hops max, 40 byte packets 1 thermal-detonator.explosive.net (209.133.38.1) 3.428 ms 2.032 ms 2.915 ms 2 explosive-gate.bungi.com (207.126.96.81) 14.158 ms 6.082 ms 6.239 ms 3 above-gw1.above.net (207.126.96.249) 18.889 ms 23.423 ms 13.275 ms 4 core2-main.sjc.above.net (207.126.96.133) 20.749 ms 22.295 ms 26.260 ms 5 pbnap.ibm.net (198.32.128.49) 31.658 ms 21.513 ms 10.753 ms 6 sfra1sr1-4-0-0.ca.us.ibm.net (165.87.13.5) 22.046 ms 46.370 ms 11.730 ms 7 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 14.978 ms 31.752 ms 15.835 ms 8 ded1-fa0-1-0.pbi.net (216.102.176.229) 16.619 ms 26.949 ms 14.992 ms 9 pbi.scrm01.foothill.net (206.13.15.82) 47.453 ms 41.492 ms 55.562 ms 10 inyo.E0.foothill.net (206.170.175.12) 25.009 ms 42.198 ms 46.245 ms 11 fhaub.foothill.net (207.212.142.2) 26.434 ms 26.344 ms 28.052 ms 12 aub2-aub.foothill.net (207.212.142.18) 124.096 ms 101.107 ms 116.097 ms 13 yellowstone.foothill.net (209.77.125.7) 60.986 ms 65.366 ms 62.531 ms 14 black.foothill.net (209.77.125.5) 54.999 ms 54.907 ms 75.083 ms 15 den-edge-03.inet.qwest.net (205.171.2.81) 60.018 ms 65.658 ms 70.363 ms 16 den-core-01.inet.qwest.net (205.171.16.101) 74.909 ms 65.983 ms 53.476 ms 17 kcm-core-01.inet.qwest.net (205.171.5.49) 122.825 ms 122.386 ms 109.227 ms 18 chi-core-03.inet.qwest.net (205.171.5.209) 105.897 ms 124.867 ms * 19 chi-brdr-01.inet.qwest.net (205.171.20.66) 157.154 ms 135.603 ms 112.038 ms 20 ameritech-nap.ibm.net (198.32.130.48) 97.206 ms 287.921 ms 118.020 ms 21 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 127.120 ms 94.150 ms 108.502 ms 22 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 121.666 ms 106.453 ms 137.678 ms 23 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 134.660 ms 121.347 ms 134.990 ms 24 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 110.007 ms 118.412 ms 113.585 ms 25 ded1-fa0-1-0.pbi.net (216.102.176.229) 110.922 ms 121.757 ms 120.744 ms 26 pbi.scrm01.foothill.net (206.13.15.82) 168.531 ms 120.297 ms 126.005 ms 27 inyo.E0.foothill.net (206.170.175.12) 139.673 ms 132.929 ms 127.300 ms 28 fhaub.foothill.net (207.212.142.2) 141.649 ms 122.945 ms 129.213 ms 29 aub2-aub.foothill.net (207.212.142.18) 166.993 ms 167.198 ms 150.826 ms 30 yellowstone.foothill.net (209.77.125.7) 196.249 ms 175.024 ms 176.773 ms 31 black.foothill.net (209.77.125.5) 168.758 ms 198.408 ms 184.525 ms 32 den-edge-03.inet.qwest.net (205.171.2.81) 272.653 ms 159.779 ms 155.101 ms 33 den-core-01.inet.qwest.net (205.171.16.101) 189.017 ms 149.512 ms 187.653 ms 34 kcm-core-01.inet.qwest.net (205.171.5.49) 306.126 ms 289.999 ms 299.566 ms 35 chi-core-03.inet.qwest.net (205.171.5.209) 267.799 ms 255.187 ms 227.433 ms 36 chi-brdr-01.inet.qwest.net (205.171.20.66) 206.557 ms 205.909 ms 219.783 ms 37 ameritech-nap.ibm.net (198.32.130.48) 223.576 ms 209.612 ms 245.735 ms 38 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 213.514 ms 192.737 ms 198.519 ms 39 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 422.787 ms 226.321 ms 201.231 ms 40 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 213.628 ms 215.660 ms 204.454 ms 41 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 211.223 ms 220.463 ms 210.478 ms 42 ded1-fa0-1-0.pbi.net (216.102.176.229) 215.415 ms 222.699 ms 224.125 ms 43 pbi.scrm01.foothill.net (206.13.15.82) 238.908 ms 257.101 ms 243.417 ms 44 inyo.E0.foothill.net (206.170.175.12) 242.373 ms 247.035 ms 235.268 ms 45 fhaub.foothill.net (207.212.142.2) 226.575 ms 283.316 ms 236.287 ms 46 aub2-aub.foothill.net (207.212.142.18) 280.279 ms 239.211 ms 258.270 ms 47 yellowstone.foothill.net (209.77.125.7) 306.427 ms 265.694 ms 269.407 ms 48 black.foothill.net (209.77.125.5) 247.035 ms 266.847 ms 273.547 ms 49 den-edge-03.inet.qwest.net (205.171.2.81) 270.400 ms 288.867 ms 240.651 ms 50 den-core-01.inet.qwest.net (205.171.16.101) 265.766 ms 255.630 ms 290.420 ms 51 kcm-core-01.inet.qwest.net (205.171.5.49) 336.500 ms 328.301 ms 310.882 ms 52 chi-core-03.inet.qwest.net (205.171.5.209) 299.759 ms 311.397 ms 332.053 ms 53 chi-brdr-01.inet.qwest.net (205.171.20.66) 292.071 ms 351.483 ms 304.168 ms 54 ameritech-nap.ibm.net (198.32.130.48) 318.543 ms 305.746 ms 283.969 ms 55 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 290.354 ms 303.127 ms 350.644 ms 56 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 314.396 ms 302.272 ms 339.481 ms 57 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 306.697 ms 324.430 ms 330.712 ms 58 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 326.742 ms 319.407 ms 315.054 ms 59 ded1-fa0-1-0.pbi.net (216.102.176.229) 438.522 ms 309.319 ms 354.142 ms 60 pbi.scrm01.foothill.net (206.13.15.82) 365.851 ms 336.370 ms 334.734 ms 61 inyo.E0.foothill.net (206.170.175.12) 349.970 ms 341.467 ms 344.949 ms 62 fhaub.foothill.net (207.212.142.2) 338.453 ms 358.412 ms 419.968 ms 63 * aub2-aub.foothill.net (207.212.142.18) 362.770 ms 361.278 ms 64 yellowstone.foothill.net (209.77.125.7) 371.051 ms 402.973 ms 368.847 ms 65 black.foothill.net (209.77.125.5) 390.108 ms 363.387 ms 376.422 ms 66 den-edge-03.inet.qwest.net (205.171.2.81) 346.283 ms 341.602 ms 375.215 ms 67 den-core-01.inet.qwest.net (205.171.16.101) 435.122 ms 374.796 ms 391.623 ms 68 * kcm-core-01.inet.qwest.net (205.171.5.49) 415.836 ms 418.338 ms 69 chi-core-03.inet.qwest.net (205.171.5.209) 434.679 ms 406.738 ms 437.156 ms 70 chi-brdr-01.inet.qwest.net (205.171.20.66) 413.029 ms 410.438 ms 434.965 ms 71 ameritech-nap.ibm.net (198.32.130.48) 434.064 ms 420.168 ms 423.529 ms 72 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 425.842 ms 426.489 ms 416.321 ms 73 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 422.823 ms 414.828 ms 393.431 ms 74 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 445.196 ms 429.619 ms 406.854 ms 75 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 412.484 ms 394.146 ms 432.452 ms 76 ded1-fa0-1-0.pbi.net (216.102.176.229) 419.056 ms 442.811 ms 541.351 ms 77 pbi.scrm01.foothill.net (206.13.15.82) 428.628 ms 427.485 ms 428.896 ms 78 inyo.E0.foothill.net (206.170.175.12) 496.987 ms 405.326 ms 458.880 ms 79 fhaub.foothill.net (207.212.142.2) 477.900 ms 824.250 ms 427.663 ms 80 aub2-aub.foothill.net (207.212.142.18) 457.283 ms 443.268 ms 473.782 ms 81 yellowstone.foothill.net (209.77.125.7) 482.899 ms 471.563 ms 483.963 ms 82 black.foothill.net (209.77.125.5) 477.026 ms 495.320 ms 451.694 ms 83 den-edge-03.inet.qwest.net (205.171.2.81) 469.582 ms 485.003 ms 440.083 ms 84 den-core-01.inet.qwest.net (205.171.16.101) 448.832 ms 450.490 ms 448.815 ms 85 kcm-core-01.inet.qwest.net (205.171.5.49) 515.683 ms 563.008 ms 546.895 ms 86 chi-core-03.inet.qwest.net (205.171.5.209) 531.464 ms 547.059 ms 574.588 ms 87 chi-brdr-01.inet.qwest.net (205.171.20.66) 519.100 ms 530.236 ms 514.015 ms 88 * ameritech-nap.ibm.net (198.32.130.48) 528.777 ms * 89 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 574.757 ms * 488.779 ms 90 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 558.664 ms * 500.934 ms 91 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 517.281 ms 488.950 ms 481.345 ms 92 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 530.915 ms 522.904 ms 543.949 ms 93 ded1-fa0-1-0.pbi.net (216.102.176.229) 495.627 ms 513.428 ms 526.980 ms 94 pbi.scrm01.foothill.net (206.13.15.82) 551.456 ms 518.603 ms * 95 inyo.E0.foothill.net (206.170.175.12) 510.303 ms 546.476 ms 591.256 ms 96 fhaub.foothill.net (207.212.142.2) 562.139 ms 534.934 ms 532.466 ms 97 aub2-aub.foothill.net (207.212.142.18) 523.782 ms 538.941 ms 543.933 ms 98 yellowstone.foothill.net (209.77.125.7) 587.493 ms 566.024 ms * 99 black.foothill.net (209.77.125.5) 610.018 ms 540.703 ms 562.170 ms 100 den-edge-03.inet.qwest.net (205.171.2.81) 538.785 ms 561.552 ms 555.907 ms 101 den-core-01.inet.qwest.net (205.171.16.101) 536.613 ms 522.250 ms 601.697 ms 102 kcm-core-01.inet.qwest.net (205.171.5.49) 611.405 ms 630.121 ms 599.730 ms 103 chi-core-03.inet.qwest.net (205.171.5.209) 606.679 ms 591.726 ms 603.139 ms 104 chi-brdr-01.inet.qwest.net (205.171.20.66) 603.014 ms 603.699 ms 616.839 ms 105 ameritech-nap.ibm.net (198.32.130.48) 600.603 ms 656.261 ms 587.816 ms 106 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 692.574 ms 595.282 ms 628.877 ms 107 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 714.470 ms 586.947 ms 656.114 ms 108 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 637.584 ms 612.485 ms 587.341 ms 109 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 579.016 ms 596.248 ms 673.300 ms 110 ded1-fa0-1-0.pbi.net (216.102.176.229) 606.238 ms 600.822 ms 624.883 ms 111 pbi.scrm01.foothill.net (206.13.15.82) 609.944 ms 640.184 ms^C jdfalk@unagi [Thu 15:10] 6 /usr/home/jdfalk>exit Script done on Thu May 20 15:10:23 1999 ---------========== J.D. Falk <jdfalk(a)cybernothing.org> =========--------- | "INIT_THOUGHT caused a general protection fault in module CORTEX.DLL | | The offending module has been shutdown and removed." | | -- Ted Coady <ecoady(a)morgan.ucs.mun.ca> | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----

2 1

Re: NYC FIBER CUT
by Sean Donelan 20 May '99

20 May '99

patrick(a)ianai.NET (I Am Not An Isp) writes: >I can't believe I beat Sean.... :) I was at Star Wars and turned my beeper off :-) We moved all of our equipment and circuits out of NYC after the WTC incident, too expensive, too high-profile, too risky. So I don't get much telemetry for outages in that area unless someone sends me an e-mail. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

FIBER CUT - NYC
by Reid Fishler 20 May '99

20 May '99

AT&T Local Services (TCG) is reporting "144 Strands of fiber" cut in NYC, affecting many customers. Lines have been down since about 8:30AM, and ETA is about 7PM EDT. Reid Fishler Lightning.net

1 0

NYC FIBER CUT 5/19/99 (v2.0)
by I Am Not An Isp 20 May '99

20 May '99

I have some more info on the fiber cut in NYC. It is right outside the 111 8th Ave. building and *appears* to only affect people in that building. (Prolly hit the conduit going into the building, not the main fiber loop - but I can't confirm that.) The ETR has been changed. It was 8 hours as of ~9:30 AM PDT. (*Much* longer than the original estimate.) I'll try to keep you updated as I get more info. TTFN, patrick I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable.)

2 1

NYC FIBER CUT
by I Am Not An Isp 20 May '99

20 May '99

There is a fiber cut in NYC affecting AT&T/TCG and MFS DS3s, possibly more. This is a confirmed cut as it is affecting my voice traffic right now, not sure if it affecting any Internet traffic but I wouldn't be surprised. The ETR was 5 to 6 hours @ ~7:30 AM EDT, 5/20/99, which means it should be fixed by now, but I have not gotten the "all clear" yet. (I know you are all amazed that a fiber cut takes longer to repair than the original estimate.) I can't believe I beat Sean.... :) TTFN, patrick I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable.)

1 0

[NON-Operational] Shakespeare's Othello
by owen＠dixon.DeLong.SJ.CA.US 20 May '99

20 May '99

I promise this is the last non-operational post from me before NANOG Eugene. Apologies to anyone who may be offended. FWIW, it is an issue "requiring coordination" :-) I have one seat left for the Eugene-Ashland-Eugene flight we have planned for Sunday evening. This would include a ticket to the Oregon Shakespeare Festival production of Othello at the Agnes Bowmer theatre in Ashland, OR at 8:00 PM. Plan is fly down, see play, fly back. For those not familiar with the Oregon Shakespeare festival, you can find more information at www.orshakes.org. Play ticket is approx. $27, flight would be approximately 1 hour each way, cost share would work out around $50. If you need more information or are interested in going, please call me at +1.408.346.1526. Thanks, Owen

1 0

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

19 May '99

Clark Gaylord <cgaylord(a)cns.vt.edu> wrote: > I doubt that evan Vadim is ignorant enough to be saying ATM never > worked ... not the usual statement one would make of the default > campus core technology. The last time i checked the default campus core technology was Ethernet. Anyway, there's a saying at NASA (thanks, Milo :) that given enough thrust even pigs can fly. What i said is not that ATM cannot be made to work in some limited environments, but rather that it is going to the junkyard of overhyped technologies which tured out to be more expensive and less reliable than simpler and dumber rivals. --vadim

2 1

Re: Is anyone actually USING IP QoS?
by Alex P. Rudnev 19 May '99

19 May '99

Sorry, but Windows-XXXX can realise not more than client's part of RSVP. RSVP's troubles are not the protocol itself (through it's TERRIBLE); it's not the problem for the router to realise some kind oc custom queuering with some garanteed bandwidth and latency for the selected stream; the problem is _how to make decision about such reservation_. And other problem - I can easily use RSVP over the client's link, but i's easy and more understandable to use some precedence with the static stream list, to allow customer run VOIP or/and RV applications over the well loaded link (note - RSVP is to complex for this case, 99% of such tasks can be solved by the precedense or static access lists); I don't need RSVP on the internal links because they can't be saturated (they are cheap); I can't use RSVP on the inter-ISP links because there is nothing about policy in RSVP standard and CISCO. This means - Win-2000 can send RSVP requests, no doubt; but who is ready to proceed such requests? > > (RSVP). > > RSVP isn't dead. It'll be released in the next Windows 200x, which > isn't to say that the implementation is good or bad, just that RAPI > will finally be available to your average codesmith. The problem > that this brings up is overuse of a good thing. For example, your > Oracle application can signal a particular reservation but what > happens when you have lots (10K) of users making that same reservation > at once? It's a difficult problem because they're not all using that The question is - how I prefere one user against another. While some external (tac_plus daemon or radius daemon) process can't be used for developing such requests, they are useless; and RSVP does not help to solve this problem at all. May be, in future. It's dead because no one use it now. May be, it'll be not dead in future. _USE_ - I mean provider, not client's program. Again - poit us ANYONE who does use QoS management other then CAR or filtering or custom queuering. I could not found anyone; may be, someone is lucky? > > Anyway, no one answer to the initial question. I guess no one here use > > complex QoS features, except primitive (CAR, RED, WFQ) ones. > > Actually, that's not particularly true. But I can't really speak on > that subject other than to say that the people I work for are > starting to see the light about ATM's weaknesses when "native" ATM > applications are built. Unfortunately, I've yet to see an implementation > of ISSLL adaptations. > > > -scooter > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: Is anyone actually USING IP QoS?
by Alex P. Rudnev 19 May '99

19 May '99

I meant circuits, not Internet. On Wed, 19 May 1999, Jon Zeeff wrote: > Date: Wed, 19 May 1999 09:23:00 -0400 (EDT) > From: Jon Zeeff <jon(a)zeeff.com> > To: "Alex P. Rudnev" <alex(a)Relcom.EU.net> > Cc: steriley(a)microsoft.com, nanog(a)merit.edu > Subject: Re: Is anyone actually USING IP QoS? > > > > When I order bandwidth, I got BANDWIDTH. Just what I asked. > > You are lucky. Every end user I know who has ordered "Internet" bandwidth, > has, on occasion, gotten packet loss and poor latency to some end points. > Ie, non bandwidth. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0