- Test - lists.nanog.org

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 16 Jul '02

16 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

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

15 Jul '02

The problem with doing that is you do not get fine grained control. You can only say only send me 50k routes, and things not from other peers. The really nifty part about prefix-limiting your peers is when they deaggregate toward you, you drop all your bgp sessions to them at once, completely depeering. You still cannot prevent announcement of weird routes like 63/8. Do not be fooled into believing that just because a network is big they know what they are doing. Some of the 63/8 announcements I have seen came by way of sprint. Let's step back and think about this on a security front, anyone with access to a tier 1 ISPs router can dos anyone in the internet, just by throwing in a null route for the block that is more specific then the one they have advertised. Granted not easily done, but just the same I like to be the only one who can break my network. Unfortunately Majdi is correct, we do not have sufficient functionality in today's routing software to fix the problem. Oh well I guess it has worked for this long. -----Original Message----- From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] Sent: Monday, July 15, 2002 8:39 AM To: Majdi S. Abbas Cc: Frank Scalzo; nanog(a)merit.edu Subject: Re: No one behind the wheel at WorldCom There are different types of filter tho and I'd suggest they are suitable in different circumstances. eg small peer < 100 prefixes - build prefix filter list, as path list middle peer - either depending on requirement (eg cust, peer) large peer > 1000 prefixes - as path filter plus max prefix I'm not implementing the above so the numbers and suggestions are a little arbitrary but I'm making the point that you can filter smaller peers who are less experienced and more likely to give an error and for larger peers you have to be less granular but can still impose failsafes without increasing CPU. Steve On Mon, 15 Jul 2002, Majdi S. Abbas wrote: > > On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote: > > See now we are back to the catch 22 that is IRR. No one will use it because > > the data isnt there, and no one will put the data into it because no one > > uses it. > > [CC: list trimmed] > > 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. > > > I think the way to get IRR into the real world production realm, is > > to really drive home the issue w/IPV6. > > This still doesn't solve the scaling issue. This is no different > than running your own RR, which many ISPs already do -- and they still > have to exempt many of their peers. Typically, RR derived prefix filtering > is something reserved for only their transit customers. > > If it were that easy, everyone (well, some people) would be > doing it. > > --msa >

2 1

ATT
by Bryan Heitman 15 Jul '02

15 Jul '02

Anyone seeing any problems with ATT in LAX? I have ATT colo in Mesa, AZ with some routing problems... Best regards, Bryan Heitman Interland, Inc.

2 2

Re: Evil PGP sigs thread must die. was Re: Stop it with putting your e-mail body in my MUA OT
by Andy Dills 15 Jul '02

15 Jul '02

On Wed, 10 Jul 2002, Jordyn A. Buchanan wrote: > Your facts are correct, but you're missing one so your conclusion is wrong. > > You need to verify the signature in order to be able to rely on it. > However, if one usually does not consistently sign their messages, then it > becomes entirely plausible that a spoofed message lacks a signature not > because the forger does not have the capability to generate the signature, > but simply because the sender simply neglected to attach a signature (yet > again). In this case, unsigned data is accorded roughly the same level of > authenticity as signed data. Yes, but once again you must consider content, given that most mail clients don't automatically verify signatures. Most of us will have to make a judgement call as to whether or not to bother to check the signature. The higher the degree of "importance" of the content, the more likely I am to check the signature, and the more likely I am to take verification steps if not signed. If the content is not "important", I won't bother checking the signature. Lest anybody confuse my argument, I think PGP signatures are a good thing. I just don't think people need to sign everything they send. And I'm talking about posts to Nanog here, not private communication. In private communication, it's reasonable to sign most everything sent with official business purpose. If the majority of mail clients automatically verified pgp signatures, I would be totally in favor of signing every single email. But the simple fact is that not only do most mail clients not support that, many mail clients can't even display the signed text inline! Surely a compromise is needed for now. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

6 5