- NANOG - lists.nanog.org

Re: Operations: where are you going to sit?
by Hal Murray 06 Dec '00

06 Dec '00

> > 5) Lots of phone lines (including conference and analog) > that can call in and out and internationally This isn't for the NOC proper, but it might be handy if you have gear located in remote locations where a non-wizard might be pushing buttons or reading lights for you. Make sure there is a phone near the gear or a phone someplace with a long enough cord to get there.

4 3

RE: Is MPLS based VPN really feasible in real world situation?
by Cumming, James 06 Dec '00

06 Dec '00

Tiernan, You are indeed correct. Giles did indeed mention that we are running MPLS on our Juniper M160 core network and I am rolling out MPLS VPNs on a wider scale across Europe. This service is not currently available for customers of Level 3 as the Juniper equipment is not currently capable of supporting MPLS VPNs (Juniper have a release of software that should cover this functionality early next 2001). There are work-arounds to allow end-to-end MPLS VPNs but these will not be implemented for customers as they do not scale. We will be pursuing further work in this area early next year. Regards, James Cumming IP Core Network Engineer Level 3 Communications -----Original Message----- From: tiernan ray [mailto:tiernan@tiernan.net] Sent: 05 December 2000 15:24 To: Christian Kuhtz; nanog(a)merit.edu Subject: Re: Is MPLS based VPN really feasible in real world situation? I don't mean to intrude, as I'm a journalist who lurks, not a carrier representative. But I thought I'd point out that at last week's "IP Over WDM" conference in Paris, Giles Heron, of Level 3 Communications, remarked that the company has MPLS running in its Juniper M160 routers and that the firm has been running MPLS VPNs in London for six months. Heron remarked the gating factor at this point is getting the firm to price such a service for commercial deployment, and, on the technical side, the service can not be run out to the edge of the network until there is compatibility between Juniper and Cisco's respective label distribution protocol (LDP) software. Once this happens, Giles expects the company will try to run MPLS across the entire network between the Juniper switches and Cisco 7500 routers. I'm not really qualified to assess any of this information, but thought I'd offer it to the group since I came across it at the conference. Tiernan Ray Journalist SmartMoney.com tiernan(a)tiernan.net Christian Kuhtz wrote: > > Hi Nanog, > > > > We've noticed that Global one has already begin to sell its MPLS based VPN, > > but we heard the Cisco people says that MPLS can't be widely deployed. Does > > anyone know any further detail of Global one's MPLS based VPN, is it real? > > Any additional operational cost than traditional VPN ? > > Err. who from Cisco said it can't be widely deployed? > > -- > Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only."

1 0

RE: Facts, Statistics and Urban Legends from the backhoe conventi on
by Roeland Meyer 06 Dec '00

06 Dec '00

> From: Sean Donelan [mailto:sean@donelan.com] > Sent: Sunday, December 03, 2000 6:59 AM I noticed these two points, from you message, and moved them together. If this is the current business case, for excavators; > A review of 582 damage incidents caused by excavator error resulted > in an average cost to the excavator of $1,488 per incident. > It is often > less expensive for the excavator to dig through the utilities than > around them. Then what do you think would happen if the real costs were passed on for them to pay? > Sprint estimates the cost to repair a single cable cut between > $50,000 to $65,000. Loss of Use costs may be over $200,000. This sounds real accurate. Why aren't the excavators seeing these costs? I'd bet a saw-buck that their behavior would be modified if this was what they were hit with. > In one court case, the excavator's president testified that it was > his company's standard practice to ignore OSHA regulations, > ANSI standards, > and guidelines set out in Bell South brochures and to always > excavate with > mechanized equipment directly over the orange paint marks showing the > location of underground telecommunications facilities. He further > testified that his company averaged one and one-half cable > cuts a month, > and considered damging underground facilities as simple a > cost of doing > business. I'm only a businessman, but this sounds like he's a creature that has adapted adequately to his environment. > My questions: If he always dug directly over the orange paint > marks, why > was the locate so poor he only hit a cable once ever month and a half? This one made ne laugh for a solid five minutes. ROTFLMAO!

1 0

Receive a FREE Satellite T.V. System.
by Canham＠demokritos.cc.duth.gr 06 Dec '00

06 Dec '00

FREE Satellite T.V. System and FREE Installation For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation. Enjoy over 500 Channels of crystal clear digital picture and cd stereo sound on your FREE Satellite TV System. Why pay for these items in a retail store, when we're giving you the same satellite package for free. Call 888-514-6881 to be Guaranteed Your FREE Satellite Today This Innovative 20" Satellite includes a stereo receiver and an infrared remote. With this FREE offer you will have both Interactive Television Capability and an On Screen Program Guide. This limited time FREE offer is much less than the monthly cost of cable tv. All you have to do is call us to arrange delivery. If you call today, we'll throw in a second receiver for your second T.V. free. Call 888-514-6881 to Begin Surfing through 500 Channels Today! To be removed send email to elacrek(a)yahoo.com

1 0

Re: Operations: where are you going to sit?
by Dustin Clampitt 06 Dec '00

06 Dec '00

>> - Ready access to sodas, company-paid pref. (coffee is nice, but soda is >> necessary.) And a toilet in close proximity. Seriously. A shower is way up on my list of nice amenities. Incredibly refreshing when you're totally stressed out. Dustin

1 0

a privacy violation at the DC Renaissance Hotel - to all NANOG 20 conference participants
by Kai Schlichting 05 Dec '00

05 Dec '00

Hmm, Merit's mailer gives me some headaches. Maybe it's because the mail already had a "Delivered-To: header when sent (how to insert that into incoming-only mail in Sendmail has remained a mystery to me). I sent it with the wrong return address, too, so this might have been the true reason. Please be not be distracted from the content of the message itself. [...] The Postfix program <nanog(a)merit.edu>: mail forwarding loop for nanog(a)merit.edu [...] From: Kai Schlichting <kai(a)conti.nu> Subject: a privacy violation at the DC Renaissance Hotel - to all NANOG 20 conference participants Cc: postmaster(a)stsn.com, wwest(a)SUITECORP.COM, notphast(a)MSN.COM, domain.administrator(a)MARRIOTT.COM, postmaster(a)MARRIOTT.COM, postmaster(a)renaissancehotels.com This is a message to all NANOG 20 participants staying at the Renaissance Washington DC conference hotel, October 22-24th (and probably to countless other guests over time that are not affiliated with NANOG). If you have surfed accessed-restricted websites belonging to your employers while using the hotel's in-room Internet service (provided by SuiteCorp, stsn.com) you have good reason to be concerned now, as your privacy has been violated. STSN apparently uses a transparent proxy (which I have no problem with) that continually keeps a copy of what is accessed for a very long time (which I have a BIG problem with) - but it doesn't stop there: it's doing conditional re-GET's on those objects in the cache, keeping it up-to-date (and I will not allege that the STSN admins are "surfing the logs" so to speak, there is not evidence for that). This is a gross privacy violation and a damn good reason not to use secured, private, privacy-sensitive non-SSL websites when using any hotel in-room Internet service like STSN. It's also a damn good reason to sue if you feel like it (I don't, at least not right now). The last 5 accesses in the log below are such cache-refresh accesses, those leading up to it are from my accesses in the room and from the conference network gratiously provided by AOL. p3.stsn.com - - [22/Oct/2000:20:16:22 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" p3.stsn.com - - [22/Oct/2000:23:03:30 -0400] "GET /~kai/home646.html HTTP/1.0" 200 5899 "-" "Mozilla/3.01 (compatible;)" p3.stsn.com - - [22/Oct/2000:23:05:31 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" p3.stsn.com - - [23/Oct/2000:08:26:39 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" nanog-18-142.atdn.net - - [23/Oct/2000:09:02:13 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" nanog-19-66.atdn.net - - [23/Oct/2000:11:09:07 -0400] "GET /~kai/home646.html HTTP/1.0" 200 5899 "-" "Mozilla/4.75 [en] (Win98; U)" p73.stsn.com - - [23/Oct/2000:16:58:52 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" p73.stsn.com - - [23/Oct/2000:17:02:34 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" p73.stsn.com - - [23/Oct/2000:17:59:04 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" 12.23.124.37 - - [23/Oct/2000:21:33:46 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" p244.stsn.com - - [24/Oct/2000:08:57:28 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" nanog-18-140.atdn.net - - [24/Oct/2000:09:26:26 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/4.75 [en] (Win98; U)" p3.stsn.com - - [28/Oct/2000:10:07:51 -0400] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" p3.stsn.com - - [03/Nov/2000:04:04:11 -0500] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" p3.stsn.com - - [10/Nov/2000:13:31:57 -0500] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" p3.stsn.com - - [19/Nov/2000:21:40:56 -0500] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" p3.usslc14.stsn.com - - [29/Nov/2000:10:27:01 -0500] "GET /~kai/home646.html HTTP/1.0" 304 - "-" "Mozilla/3.01 (compatible;)" Thanks, bye,Kai ps: yes, that page is gone now. -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield <tm> is FREE! http://www.SpamShield.org | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath

2 2

Re: troubles in above.net and chellonetwork.com ?!@#$%
by Jeff.Hodges＠kingsmountain.com 05 Dec '00

05 Dec '00

the problem's been addressed. apparently it was Chello leaking routes that should've been going to BBN. Thanks to all who responded. JeffH

1 0

RE: troubles in above.net and chellonetwork.com ?!@#$%
by Frank Hellemink 05 Dec '00

05 Dec '00

Hi, this situation should be resolved. A config error was made on our side. apologies to everyone on this list that might have been affected by this. Frank Hellemink fhellemink(a)chello.com Design & Engineering Chello Broadband -----Original Message----- From: Marc Teichtahl [mailto:marct@versatel.net] Sent: 05 December 2000 20:36 To: Jeff Hodges Cc: noc(a)above.net; nanog(a)merit.edu Subject: Re: troubles in above.net and chellonetwork.com ?!@#$% im the netherlands we have seen intermittent table leaking from chello broadband. -- With Regards, Met vriendelijke groeten, Marc Teichtahl Manager, Data Network Design Versatel Telecom "The future will be better tomorrow" - G.W Bush NASDAQ: VRSA AEX:VRSA On Tue, 5 Dec 2000, Jeff Hodges wrote: > > Anybody know what's going on? this suddenly started sometime in the last 90 min > or so. Prior to that I was enjoying nice little 30ms latencies on this path. > > thanks, > > JeffH > ----- > Tracing from oblix.com to www.stanford.edu... > > /home/jhodges[625]> date ; traceroute www.stanford.edu > Tue Dec 5 11:14:11 PST 2000 > traceroute to www.LB-A.stanford.edu (171.64.14.235), 30 hops max, 40 byte > packets > 1 router192 (192.168.1.1) 0.834 ms 0.989 ms 0.626 ms > 2 peto (192.168.3.2) 0.789 ms * 0.750 ms > 3 router (216.200.223.224) 2.074 ms 1.745 ms 3.379 ms > 4 above (216.200.159.32) 4.593 ms 4.331 ms 4.300 ms > 5 216.200.142.main2.above.net (216.200.142.3) 3.996 ms 3.830 ms 3.928 ms > 6 sjc2-gige-core1.sjc2.above.net (208.184.102.97) 3.923 ms 3.902 ms 4.049 > ms > 7 core5-core1-oc48.sjc.above.net (216.200.0.177) 4.080 ms 3.919 ms 3.924 ms > 8 core3-core5-oc48.sjc2.above.net (208.184.102.206) 4.069 ms 4.015 ms 4.036 > ms > 9 iad-sjc2-oc48.iad.above.net (216.200.127.25) 74.717 ms 72.328 ms 71.984 > ms > 10 core3-core1-oc48.iad.above.net (209.249.203.33) 77.661 ms 78.310 ms > 72.298 ms > 11 lhr-iad-stm4.lhr.above.net (216.200.254.78) 886.943 ms 892.302 ms 899.346 > ms > 12 ams-lhr-stm4.above.net (208.184.231.14) 917.162 ms 911.795 ms 912.913 ms > 13 amsix-core1.ams-1.above.net (208.184.231.38) 920.192 ms 888.774 ms > 878.803 ms > 14 nl-ams-ri-03-gige-3-0.chello.com (193.148.15.106) 874.924 ms 867.330 ms > 867.151 ms > 15 nl-ams-rd-02-pos-6-0.chellonetwork.com (213.46.161.61) 877.168 ms 882.381 > ms 885.405 ms > 16 * * * > 17 * * * > 18 bebru203-tc-p1-0.ebone.net (195.158.225.85) 3565.005 ms * 3507.232 ms > 19 * bebru204-tc-p2-0.ebone.net (195.158.225.82) 3484.896 ms 3556.127 ms > 20 * * * > 21 usnyk105-tc-p8-3.ebone.net (195.158.229.45) 3683.897 ms 3687.444 ms > 3722.310 ms > 22 * * * > 23 * * p7-1.nycmny1-ba1.bbnplanet.net (4.24.8.89) 3703.430 ms > 24 p7-0.nycmny1-br1.bbnplanet.net (4.24.6.229) 3758.138 ms * * > 25 * p5-0.nycmny1-nbr1.bbnplanet.net (4.24.10.81) 3731.156 ms * > 26 * * * > 27 p9-0.snjpca1-br2.bbnplanet.net (4.24.9.130) 3721.144 ms * * > 28 * * * > 29 * * p4-0.paloalto-nbr2.bbnplanet.net (4.0.5.66) 3734.683 ms > 30 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) 3786.637 ms 3781.417 ms * > /home/jhodges[626]> > /home/jhodges[626]> > /home/jhodges[626]> > /home/jhodges[626]> > /home/jhodges[626]> ping www.stanford.edu > PING www.LB-A.stanford.edu (171.64.14.203): 56 data bytes > > --- www.LB-A.stanford.edu ping statistics --- > 14 packets transmitted, 0 packets received, 100% packet loss > /home/jhodges[627]> > /home/jhodges[627]> > >

1 0

troubles in above.net and chellonetwork.com ?!@#$%
by Jeff Hodges 05 Dec '00

05 Dec '00

Anybody know what's going on? this suddenly started sometime in the last 90 min or so. Prior to that I was enjoying nice little 30ms latencies on this path. thanks, JeffH ----- Tracing from oblix.com to www.stanford.edu... /home/jhodges[625]> date ; traceroute www.stanford.edu Tue Dec 5 11:14:11 PST 2000 traceroute to www.LB-A.stanford.edu (171.64.14.235), 30 hops max, 40 byte packets 1 router192 (192.168.1.1) 0.834 ms 0.989 ms 0.626 ms 2 peto (192.168.3.2) 0.789 ms * 0.750 ms 3 router (216.200.223.224) 2.074 ms 1.745 ms 3.379 ms 4 above (216.200.159.32) 4.593 ms 4.331 ms 4.300 ms 5 216.200.142.main2.above.net (216.200.142.3) 3.996 ms 3.830 ms 3.928 ms 6 sjc2-gige-core1.sjc2.above.net (208.184.102.97) 3.923 ms 3.902 ms 4.049 ms 7 core5-core1-oc48.sjc.above.net (216.200.0.177) 4.080 ms 3.919 ms 3.924 ms 8 core3-core5-oc48.sjc2.above.net (208.184.102.206) 4.069 ms 4.015 ms 4.036 ms 9 iad-sjc2-oc48.iad.above.net (216.200.127.25) 74.717 ms 72.328 ms 71.984 ms 10 core3-core1-oc48.iad.above.net (209.249.203.33) 77.661 ms 78.310 ms 72.298 ms 11 lhr-iad-stm4.lhr.above.net (216.200.254.78) 886.943 ms 892.302 ms 899.346 ms 12 ams-lhr-stm4.above.net (208.184.231.14) 917.162 ms 911.795 ms 912.913 ms 13 amsix-core1.ams-1.above.net (208.184.231.38) 920.192 ms 888.774 ms 878.803 ms 14 nl-ams-ri-03-gige-3-0.chello.com (193.148.15.106) 874.924 ms 867.330 ms 867.151 ms 15 nl-ams-rd-02-pos-6-0.chellonetwork.com (213.46.161.61) 877.168 ms 882.381 ms 885.405 ms 16 * * * 17 * * * 18 bebru203-tc-p1-0.ebone.net (195.158.225.85) 3565.005 ms * 3507.232 ms 19 * bebru204-tc-p2-0.ebone.net (195.158.225.82) 3484.896 ms 3556.127 ms 20 * * * 21 usnyk105-tc-p8-3.ebone.net (195.158.229.45) 3683.897 ms 3687.444 ms 3722.310 ms 22 * * * 23 * * p7-1.nycmny1-ba1.bbnplanet.net (4.24.8.89) 3703.430 ms 24 p7-0.nycmny1-br1.bbnplanet.net (4.24.6.229) 3758.138 ms * * 25 * p5-0.nycmny1-nbr1.bbnplanet.net (4.24.10.81) 3731.156 ms * 26 * * * 27 p9-0.snjpca1-br2.bbnplanet.net (4.24.9.130) 3721.144 ms * * 28 * * * 29 * * p4-0.paloalto-nbr2.bbnplanet.net (4.0.5.66) 3734.683 ms 30 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) 3786.637 ms 3781.417 ms * /home/jhodges[626]> /home/jhodges[626]> /home/jhodges[626]> /home/jhodges[626]> /home/jhodges[626]> ping www.stanford.edu PING www.LB-A.stanford.edu (171.64.14.203): 56 data bytes --- www.LB-A.stanford.edu ping statistics --- 14 packets transmitted, 0 packets received, 100% packet loss /home/jhodges[627]> /home/jhodges[627]>

2 1

Problems with Turner network (AS-5662)?
by James S. Smith 05 Dec '00

05 Dec '00

Is anyone from the Turner NOC on this list? I'm experiencing network problems getting to 207.25.71.0, 207.25.80.0, etc in AS 5662, but only from one network. (I can get to it from other networks fine.) -- James S. Smith Systems Administrator +1 416 408-4448 x257 james(a)mobshop.com www.mobshop.com <http://www.mobshop.com>

1 0