July 2002 - Test - lists.nanog.org

earthlink and dsbl
by Sameer R. Manek 17 Jul '02

17 Jul '02

If anyone from earthlink's networking is around, I'd appreciate it if you guys could get this problem resolved. http://www.dsbl.org/listing.php?ip=207.217.120.62&submit=Retrieve+Informatio n One of the sites I send email to, uses this database for their filtering, and unfortunately, it's getting rejected Sameer ------------------------------------------------------------------------- Sameer R. Manek Email: manek(a)ghur.net "What one has not experienced, one will never understand in print." --Isadora Duncan -------------------------------------------------------------------------

1 0

RE: problems with 701
by Alan Sato 17 Jul '02

17 Jul '02

Actually its that Verio wont accept networks longer than /21. I have a /22 there. Thats from Dorian according to this http://info.us.bb.verio.net/routing.html#PeerFilter That connection is not down. Alan -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Tuesday, July 16, 2002 7:46 PM To: Alan Sato; nanog(a)merit.edu; E.B. Dreger Subject: Re: problems with 701 On Tue, 16 Jul 2002 19:02:22 -0700 "Alan Sato" <asato(a)altrio.net> wrote: > > Im having the same problem. I was told Verio was not accepting connections > from UUnet. > C:\>tracert www.webshots.com > > Tracing route to www.webshots.com [128.242.104.137] > over a maximum of 30 hops: >From me to focaldata through alternet seems normal multicasttech-1>trace 66.243.100.1 Type escape sequence to abort. Tracing the route to 66-243-100-1.focaldata.net (66.243.100.1) 1 216.177.55.5 0 msec 0 msec 4 msec 2 500.Serial1-4.GW3.TCO1.ALTER.NET (157.130.48.237) [AS 701] 4 msec 0 msec 4 msec 3 117.at-0-0-0.XR2.TCO1.ALTER.NET (146.188.161.118) [AS 701] 4 msec 4 msec 12 msec 4 192.at-7-1-0.XL2.DCA8.ALTER.NET (146.188.162.241) [AS 701] 4 msec 4 msec 4 msec 5 0.so-3-0-0.TL2.DCA8.ALTER.NET (152.63.144.29) [AS 701] 4 msec 0 msec 4 msec 6 0.so-3-0-0.TL2.LAX2.ALTER.NET (152.63.29.109) [AS 701] 72 msec 72 msec 72 msec 7 0.so-6-0-0.CL2.LAX4.ALTER.NET (146.188.136.150) [AS 701] 76 msec 72 msec 72 msec 8 192.ATM6-0.GW8.LAX4.ALTER.NET (152.63.114.101) [AS 701] 72 msec 72 msec 72 msec 9 focal-lax4-gw.customer.alter.net (157.130.224.122) [AS 701] 76 msec 72 msec 76 msec 10 216-127-232-33.focaldata.net (216.127.232.33) [AS 19655] 72 msec 72 msec 72 msec 11 altrio-36.focaldata.net (216.127.233.36) [AS 19655] 76 msec 76 msec 76 msec 12 216-127-233-53.focaldata.net (216.127.233.53) [AS 19655] 76 msec 76 msec 72 msec Regards Marshall Eubanks > > 1 16 ms 16 ms 15 ms 66-243-100-1.focaldata.net [66.243.100.1] > 2 16 ms <10 ms 15 ms altrio-52.focaldata.net [216.127.233.52] > 3 16 ms 15 ms 16 ms 216-127-233-35.focaldata.net [216.127.233.35] > 4 16 ms 15 ms 16 ms 500.POS5-2.GW8.LAX4.ALTER.NET > [157.130.224.121] > > 5 16 ms 15 ms 16 ms 106.at-0-1-0.CL2.LAX4.ALTER.NET > [152.63.114.102 > > 6 16 ms 16 ms 15 ms 0.so-0-0-0.TL2.LAX2.ALTER.NET [152.63.2.74] > 7 16 ms 31 ms 31 ms 0.so-0-3-0.TL2.SAC1.ALTER.NET [152.63.116.33] > 8 15 ms 32 ms 31 ms 0.so-7-0-0.XL2.SAC1.ALTER.NET [152.63.54.9] > 9 16 ms 31 ms 31 ms POS7-0.BR6.SAC1.ALTER.NET [152.63.53.5] > 10 * * ^C > C:\> > Alan > > > -----Original Message----- > From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: Tuesday, July 16, 2002 1:36 PM > To: nanog(a)merit.edu > Subject: Re: problems with 701 > > > > BH> anyone know what is going on over at uu? > BH> > BH> seeing problems all over... > BH> > BH> > 3 <10 ms <10 ms <10 ms 216.79.187.254 > BH> > 4 <10 ms 10 ms <10 ms 172.25.57.5 > BH> > 5 <10 ms 10 ms <10 ms 205.152.37.184 > BH> > 6 <10 ms 10 ms 10 ms 500.POS2-0.GW11.ATL5.ALTER.NET > BH> > [157.130.76.97] > BH> > 7 10 ms 10 ms <10 ms 0.so-2-1-0.XL2.ATL5.ALTER.NET > BH> > [152.63.85.38] > BH> > 8 <10 ms 10 ms 10 ms POS7-0.BR2.ATL5.ALTER.NET > [152.63.82.193] > BH> > 9 * * * Request timed out. > BH> > 10 * * * Request timed out. > > Knowing source and destination would help. It appears that a > traceroute from some Bellsouth node dies out somewhere... what's > the destination? > > > Eddy > -- > Brotsman & Dreger, Inc. - EverQuick Internet Division > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 (785) 865-5885 Lawrence and [inter]national > Phone: +1 (316) 794-8922 Wichita > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) > From: A Trap <blacklist(a)brics.com> > To: blacklist(a)brics.com > Subject: Please ignore this portion of my mail signature. > > These last few lines are a trap for address-harvesting spambots. > Do NOT send mail to <blacklist(a)brics.com>, or you are likely to > be blocked. >

1 0

RE: problems with 701
by Alan Sato 16 Jul '02

16 Jul '02

Im having the same problem. I was told Verio was not accepting connections from UUnet. C:\>tracert www.webshots.com Tracing route to www.webshots.com [128.242.104.137] over a maximum of 30 hops: 1 16 ms 16 ms 15 ms 66-243-100-1.focaldata.net [66.243.100.1] 2 16 ms <10 ms 15 ms altrio-52.focaldata.net [216.127.233.52] 3 16 ms 15 ms 16 ms 216-127-233-35.focaldata.net [216.127.233.35] 4 16 ms 15 ms 16 ms 500.POS5-2.GW8.LAX4.ALTER.NET [157.130.224.121] 5 16 ms 15 ms 16 ms 106.at-0-1-0.CL2.LAX4.ALTER.NET [152.63.114.102 6 16 ms 16 ms 15 ms 0.so-0-0-0.TL2.LAX2.ALTER.NET [152.63.2.74] 7 16 ms 31 ms 31 ms 0.so-0-3-0.TL2.SAC1.ALTER.NET [152.63.116.33] 8 15 ms 32 ms 31 ms 0.so-7-0-0.XL2.SAC1.ALTER.NET [152.63.54.9] 9 16 ms 31 ms 31 ms POS7-0.BR6.SAC1.ALTER.NET [152.63.53.5] 10 * * ^C C:\> Alan -----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: Tuesday, July 16, 2002 1:36 PM To: nanog(a)merit.edu Subject: Re: problems with 701 BH> anyone know what is going on over at uu? BH> BH> seeing problems all over... BH> BH> > 3 <10 ms <10 ms <10 ms 216.79.187.254 BH> > 4 <10 ms 10 ms <10 ms 172.25.57.5 BH> > 5 <10 ms 10 ms <10 ms 205.152.37.184 BH> > 6 <10 ms 10 ms 10 ms 500.POS2-0.GW11.ATL5.ALTER.NET BH> > [157.130.76.97] BH> > 7 10 ms 10 ms <10 ms 0.so-2-1-0.XL2.ATL5.ALTER.NET BH> > [152.63.85.38] BH> > 8 <10 ms 10 ms 10 ms POS7-0.BR2.ATL5.ALTER.NET [152.63.82.193] BH> > 9 * * * Request timed out. BH> > 10 * * * Request timed out. Knowing source and destination would help. It appears that a traceroute from some Bellsouth node dies out somewhere... what's the destination? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

2 1

RE: No one behind the wheel at WorldCom
by Frank Scalzo 16 Jul '02

16 Jul '02

Maybe you don't have the router do the authorization of the prefix. Maybe it asks another box that says yes, or no. If that box disappears you have a fallback mechanism (prefix-limit and as-path filter). Of course you still need vendor buy-in. I don't think this is realistic, so hold the tomatoes. I'm just trying to think outside the box. Certainly you have a problem when you have a catastrophic event and have hundreds of routers asking for authorization of thousands of updates. More realistically, it would be spiffy if there was a tool that would listen to your BGP and tell you about routes that don't jive with the IRR. This gives you some idea of what is going around your network that might not belong. Today not only is there the potential for abuse of peering with big providers, but there is very little that can be done in terms of identifying it. If there was a tool that tracked routes outside of the IRR you would at least know what was showing up that looked funny. Could also be a good stick to beat people in to conformance by showing who is not registering routes. Given good information on how all the IRR stuff works, I think I could write a tool like that. Is there any interest? -----Original Message----- From: Vadim Antonov [mailto:avg@exigengroup.com] Sent: Tuesday, July 16, 2002 7:56 AM To: Pedro R Marques Cc: nanog(a)merit.edu Subject: Re: No one behind the wheel at WorldCom > I would still contend that the number 1 issue is how you do express > the policy to the routing code. One could potentially attempt to > recognise the primary key is a route-map/policy-statement and compile > it as you suggest. It is an idea that ends up being tossed up in the > air frequently, but would that solve anything ? Actually, expressing RP on per-router basis is kind of silly, and an artifact of enterprise-box mentality. A useful design would allow formulation of RP for the entire network with subsequent synchronization of routers with the policy repository. > Is there the ability in the backend systems to manage that effectivly > and if so is text interface via the CLI the most apropriate API ? Cisco-style CLI is extremely annoying and silly. There's no useful way to perform a switch-over to a new config, and there's no good way to compare two config and produce applicable difference. That said, I think a well-designed CLI is a powerful thing, and can be used to integrate routers with provider-specific NMSes. --vadim

1 0

Re: No one behind the wheel at WorldCom
by Pedro R Marques 16 Jul '02

16 Jul '02

msa(a)samurai.sfo.dead-dog.com (Majdi S. Abbas) writes: > Actually, I think you'll find that bad data is only a small part > of the problem; even with good data, there isn't enough support from > various router vendors to make it worthwhile; it's effectively impossible > to prefix filter a large peer due to router software restrictions. We > need support for very large (256k+ to be safe) prefix filters, and the > routing process performance to actually handle a prefix list this large, > and not just one list, but many. > > IRR support for automagically building these prefix lists would > be a real plus too. Building and then pushing out filters on another > machine can be quite time consuming, especially for a large network. > From a point of view of routing software the major challenge of handling a 256k prefix list is not actually applying it to the received prefixes. The most popular BGP implementations all, to my knowledge, have prefix filtering algorithms that are O(log2(N)) and which probably scale ok... while it would be not very hard to make this a O(4) algorithm that is probably not the issue. Implementations do always have to do a O(log2(N)) lookup on the routing table with a received prefix, and to afaik that is not a performance problem for anyone. What all implementations that i'm familiar with do have a problem with is to actually accept the configuration of 256k lines of text to use as a filter. Configuration parsing is typically not designed for such numbers... it tends to work with major vendors albeith a bit slowly. If the above disagrees with your experience please let me know. Assuming that the bottleneck is in fact being able to parse configuration, it begs the question what to do about it... I'm sure all vendors will be able to, given enought incentive, optimize their text parsing code in order to do this faster... but it begs the question, would you actually fix anything by doing that ? My inclination would be to think that you would just tend to move the bottleneck to the backend systems managing the configuration of such lists, if it isn't there already, presently. Of course i'm completly ignorant of the backends that most of you use to manage your systems and the above is just uneducated guessing, although i would apreciate further education. I would be inclined to agree with your statement that the major blame should lie on "router vendors" if you see your router vendor as someone that sells you the network elements + the NMS to manage it. But in my guestimate the focal point of our search for a culprit should be the NMS or the NMS -> router management mechanism. Idealy the latter should be more computer friendly than text parsing. Just an attempt to equally and democratically distribute blame around :-) regards, Pedro.

4 5

QoS/CoS in the real world?
by Stephen J. Wilcox 16 Jul '02

16 Jul '02

Hi all, I've been looking through the various qos/cos options available, my particular area was in how IP (MPLS perhaps) compares and can be a substitute for ATM. Well, theres lots of talk and hype out there, from simple IP queuing eg cisco priority queuing, rsvp, diffserv, mpls traffic engineering etc But two things are bugging me.. 1. To what extent have providers implemented QoS for their customers 2. Hype aside, to what extent do customers actually want this (and by this I dont just mean that they want the latest QoS because its the 'latest thing', there has to be a genuine reason for them to want it). And this takes me back to my ATM reference where there is a clear major market still out there of ATM users and what would it take to migrate them to an IP solution? Also, how are people implementing bandwidth on demand (dynamic allocation controlled by the customer) solutions to customers Cheers Steve -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008

8 10

Colocation Enclosures
by Christopher J. Wolff 16 Jul '02

16 Jul '02

Greetings, I'm trying to find alternative sources for a 2 or 3 section locked colocation cabinet cosmetically similar to the following: http://www.budind.com/images/big/DC-8125bg.jpg It appears that Encoreusa is no longer in business so I would appreciate any pointers as to where I may locate such an enclosure. Thank you! Chris

4 3

AS4006
by Andre Chapuis 15 Jul '02

15 Jul '02

Hi, Anybody has a contact for AS4006 ? (peering issue) Thanks André --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

4 3

Train Derailment near Milwaukee (Washingon County)
by Matt Levine 15 Jul '02

15 Jul '02

Anybody know if there's any fiber runs affected? Regards, Matt -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX

4 3

Re: Kudos to Qwest
by Kyle C. Bacon 15 Jul '02

15 Jul '02

Maybe some of the telco's are finally learning that the quicker you can install, the sooner you can bill. :) K "Vincent J. Bono" To: <nanog(a)merit.edu> <vbono@vinny. cc: org> Subject: Kudos to Qwest Sent by: owner-nanog@m erit.edu 07/09/2002 04:00 PM We always hear the worst but I just thought I would plug Qwest in that they just installed an OC-12 point to point cross country for me in 27 hours from time of order. This included cross connects at Level3.

18 29