- Test - lists.nanog.org

RE: Help with bad announcement from UUnet
by James Smith 29 Mar '02

29 Mar '02

I would generally agree that non-paying customers should not get top-shelf service, but when it is someone with clue calling (your people should be able to tell, they should be clueful to a degree) about an issue that is being sourced from your network, or transits your network, is it not an issue that you should be involved in anyway? Why wait for the call from your upstream when you can get a jump on the problem? James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation Yeah, I know, top-posting is frowned upon. I have other bad habits... -----Original Message----- From: fingers [mailto:fingers@fingers.co.za] Sent: Friday, March 29, 2002 11:51 AM To: Leo Bicknell Cc: nanog(a)merit.edu Subject: Re: Help with bad announcement from UUnet Hi > Note that in both cases, b0rken-noc takes a single call, so their > load is unchanged. The second case adds a call to both my-upstream-noc, > and b0rken-noc-upstream-noc. > > It would seem going direct would put a lower load on NOC's in general, > which presumably would let them spend more time on problems and provide > better service. surely a noc's first responsability is to direct customers? even if the other network experiencing the problem may affect said customer, the service is not just about connectivity, but also about trying to deal with calls in the best possible manner. if more time were spent on non-customers, a paying customer would end up losing out on that warm fuzzy feeling when his call is answered promptly, the person he speaks to actually listens, and his general experience interacting with the noc is something he doesn't walk away from feeling cheated. Regards --Rob

1 0

Call for Presentations
by Susan Harris 29 Mar '02

29 Mar '02

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 25 * * June 9 -12, 2002 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 25th meeting June 9-11, 2002, in Richmond Hill, Ontario, Canada (just outside Toronto). The meeting will be hosted by Group Telecom. Registration begins April 22. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 500 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. <p> The meeting will be held at the the Sheraton Parkway Toronto North. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - Inter-domain traffic engineering: principles, applications, and case studies - BGP multihoming guide - ISP security: real world techniques - IP multicast technologies ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is April 29, 2002. While the majority of speaking slots will be filled by April 29, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by May 13, 2002. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ---------------------------------------------------------------------------

1 0

Not sure what I'm seeing... (Looking Glass Query)
by Aaron Mahler 29 Mar '02

29 Mar '02

Hello! Hope nobody minds a quick question from a small, non-transit but BGP aware AS... Since the day we started using multiple circuits and BGP I've always seen multiple paths through each of our providers to our network (AS 19138). At least a few C&W (3561) and at least a few Network Virginia (7066) via Sprint... For weeks or more now, every single looking glass save one shows - for the most part - a single advertised path through C&W. No sign of Sprint & Network Virginia. Even the Sprint looking glass shows no sign of a Sprint path to us. The one exception is route-views.oregon-ix.net which shows about 50... almost all of which are C&W. If I pull down the C&W circuit, things shift and Sprint starts showing up with multiple paths in all the looking glasses but will remain that way after the C&W circuit comes back online until I bring down the Sprint circuit. It seems to be one or the other... but never both. Is this not a big deal and I'm misreading the situation, or has something changed for the worse somewhere in our advertising and relationship with our providers? I can't seem to track down a cause. I've certainly made no changes to my BGP tables and announcements upstream. For anyone interested in glancing at their routes for me, check 198.28.32.0/19 and AS 19138. Thanks! - Aaron Mahler Sweet Briar College P.S. Feel free to yell at me if this post shouldn't be here. I've been lurking for ages and enjoy following the discussions of the very knowledgeable crew out there. Not sure what other forum to ask such a question at this point...

2 1

Route filters, IRRs, and route objects
by Przemyslaw Karwasiecki 29 Mar '02

29 Mar '02

Hello, I would like to ask you for an advice in regards to "proxy registering" of customer route objects in IRR. What is the best current practice in a situation, when your customers want to advertise to you several /18 or /19 but they also have a requirement to be able to advertise some deaggregated routes on top of aggregates. It is very common that they are unable to predict exactly which deaggregated routes they will need to advertise, as they use those to achieve some traffic engineering objectives which change over time. And "over time" does NOT occur once per 30 minutes or so, so they DON'T generate any major BGP fluctuations. Forgive my ignorance, but is my understanding of RPSL correct, that it should be possible to specify routes in a way which will allow cover aggregate plus whole set of possible more specific routes upto certain netmask length. Something like: 10.0.0.0/18^18-24 So why this is uncommon to use such notation to describe routing policy, and use it to generate filters? Why it is required by some providers to generate explicit, exact route objects, in order to allow routes through their filters? Is it really necessary to "explode" route-sets like those 10.0.0.0/m^m-n into 2^(n-m+1) separate route objects to meet requirements of some providers? I believe that this is very common problem, so if there are any places on the web with some "best practice" documents, please point me to them. Thank you, Przemek

4 4

RE: Let's talk about Distance Sniffing/Remote Visibility
by Gironda, Andre 29 Mar '02

29 Mar '02

On Thu, Mar 28, 2002 at 9:20AM -0700, Richard A Steenbergen wrote: > > I'm imagining that even with a relatively speedy box, if you were > > trying to do analysis from multiple interfaces you'd at least choke > > the disk I/O. There's always stringent filters, I guess. > > Disk I/O on a sniffer box? Sounds like you've been sniffing something > other than packets my friend. :) Why do you say that? In the 10/100 range, yes, no problems. But at the Gigabit range (say with two GbE cards or a single OC-48 card) on an x86 box with IDE disks (or even SCSI RAID0), doesn't disk I/O become a severe problem? Under Solaris or Linux, scaling disk seems relatively easy with Veritas Foundation Suite on Solaris or GFS under Linux http://www.sistina.com/products_gfs.htm However, I don't think Linux or Solaris can handle the packet capture capabilities like FreeBSD and BPF can. I've heard things about the new LPF capabilities and turbopacket, but it's just hard to believe coming from such a joke/toy operating system. Whether you are passively tapping a gigabit ethernet or SONET fiber, or even spanning an entire VLAN or mirroring a gigabit ethernet or SONET port on a router/switch -- you've got a lot of packets/frames to deal with, especially if you want to keep all of them for analyzing later. Sounds like a disk I/O problem to me. Are you doing packet capture at these rates and ran into no disk problems? How did you deal with that? We are doing so right now, but only with the IP headers and some "top N" information. Getting full packets and keeping them for awhile (a day or two even) is going to take a lot of I/O and disk space. I don't think it's worth it, really. > You can build your own box like that easily enough. If you're going > for FastE sniffing I highly recommend the Adaptec Quartet 4-port > cards. If you're going for GigE sniffing, I STILL highly recommend > anything Alteon Tigon 2 based (NetGear GA620's were the cheapest > if you can still find them, not the 621/622). You can accomplish almost anything with the Tigon2's and FreeBSD, agreed. Another vendor I'm sort of looking at now is Endance (DAG cards): http://www.endace.com/ http://www.endace.com/products/dag42ge.html This only does IP headers, but that's the fun stuff anyways ;> > You don't even have to do anything fancy with the card firmware, > there is a native command for receiving only part of the frame. > Check out the programming manuals at > http://people.freebsd.org/~wpaul/Alteon/, and I recommend you use > FreeBSD for this of course. Just add in a PARTIAL_RX_CNT command, > and the card will only DMA part of the packet (say 64 bytes for > full headers) across the PCI bus. Combined with interrupt coalescing > (or luigi's device polling and tuning the card to allocate all > memory to RX and remove the TX functionality completely), you can > sniff quite a few "gigabits" of traffic on a single cheap PC server. > You can dump it through the BPF mechanism and still maintain support > for all your favorite sniffer programs. Or if you're comfortable > writing kernel code, I recommend you make a character device for > sniffer device control, and use it to pass page-aligned malloc'd > memory pointers from userland into the nic driver, which you then > pass to the card as the RX ring buffers. This will let you DMA your > packets directly into userland. If not, at least unhook ether_input(). > :) Can you post more details or catch up with me offline about this? I'm really very interested in your implementations and results. > Or you can buy these things commercially. My favorite was from a > company called Tekelec, who sold a VERY expensive box which turned > out to be a pentium 200ish box running solaris x86 and completely > useless sniffing software, with a bunch of ISA ethernet cards hooked > up by proprietary (and VERY expensive) cables, all in a box made > out of what I swear was some kind of lead/neutron star material > alloy. Of course that was a couple years ago, maybe they've upgraded > to the current market's $50 processor. > :) We've been looking at NetVCR from Niksun which sounds similar except that is actually is FreeBSD-based. Somebody needs to put together a list of all these companies and do some comparisons of the product offerings. Like you, I'd rather just build my own box and run with it ;> -dre > -- > Richard A Steenbergen <ras(a)e-gerbil.net> > http://www.e-gerbil.net/ras > PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 > 14 36 FE B6) >

2 1

Re: BGP without an IGP
by Jake Khuon 28 Mar '02

28 Mar '02

### On Thu, 28 Mar 2002 13:40:51 -0500, "Abarbanel, Benjamin" ### <Benjamin.Abarbanel(a)Marconi.com> casually decided to expound upon ### "'Randy Bush'" <randy(a)psg.com>, Russ White <ruwhite(a)cisco.com> the ### following thoughts about "RE: BGP without an IGP": BA> into the AS as IBGP routes. But from what I understood Ken original topology BA> he was only talking about reachability within the AS. Reachability between IBGP BA> peers that are more than 1 hop away. Unless memory and past email messages serve me wrong, I believe Ken's topology called for full-mesh. BTW, we ran iBGP full mesh without an IGP quite fine. Okay.. so there's a twist... We did it for IPv6 (before Cisco had IPv6 IS-IS) but I see no reason why it wouldn't also work for IPv4. -- /*===================[ Jake Khuon <khuon(a)NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/

1 1

Let's talk about Distance Sniffing/Remote Visibility
by CARL.P.HIRSCH＠sargentlundy.com 28 Mar '02

28 Mar '02

I'd like to hear from the list as to what your preferred means of determining what the hell is going on at a packet level at the other side of a WAN/MAN/frame/etc link. It seems to me that the means available are A) a very expensive distributed NAI Sniffer installation B) standard RMON probes and the NMS of your choice and C) A linux box with a ton of interfaces running Ethereal accessed via Xwindows/VNC/whatever. Personally, I'm inclined to explore option C. The bells & whistles of a commercial package like NAI's Distributed Sniffer are not really a compelling value added to me. It's a shame there's no Open Source RMON agent available. I'm asking NANOG because I figure this is something pretty much every network engineer bumps into at one time or another. thanks, -carl

7 6

Change Control
by Heath_Dieckert＠Dell.com 28 Mar '02

28 Mar '02

<delurk> Hey all, I am interested in your thoughts on best practices in network engineering/implementation change control for the large business organization. Specifically what have you found that works best and why? Interested in your thoughts on business partner notification, management involvement, peer review, scheduling, coordination, and approval? If this discussion is innapropriate for this forum feel free to notify me offline. Otherwise, I look forward to your feedback. Sincerely Heath Dieckert </delurk>

1 0

Re: Let's talk about Distance Sniffing/Remote Visibility
by CARL.P.HIRSCH＠sargentlundy.com 28 Mar '02

28 Mar '02

Yeah, the device I've got in my head is a 1U server with 4 (or more?) interfaces... not so much to simultaneously pull 400Mbps of bandwidth for analysis but rather to just have a interface going to each switch I might want to monitor and then span traffic to the Ethereal box. Given that I'm trying to attain remote visibility, it might be nice not to need remote hands to be swapping patch cords back and forth. I'm imagining that even with a relatively speedy box, if you were trying to do analysis from multiple interfaces you'd at least choke the disk I/O. There's always stringent filters, I guess. thanks for the input, -carl "E.B. Dreger" <eddy+public+spam(a)noc.ever To: CARL.P.HIRSCH(a)sargentlundy.com quick.net> cc: nanog(a)merit.edu Sent by: Subject: Re: Let's talk about Distance Sniffing/Remote owner-nanog(a)merit.edu Visibility 03/28/02 09:02 AM "C" is close. Not sure what you mean by "a ton of interfaces". Most (all?) good managed switches have a "monitor port" or "mirror port" where they can blind copy traffic from other ports to the one that's set aside for snooping. Four-port ethernet cards are readily available. How many switches do you wish to monitor simultaneously? Even with only four ports (more in one box is certainly possible), you can have a fair amount of traffic to digest. -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence -- 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.

3 4

RE: Exodus/C&W Depeering
by smd＠clock.org 28 Mar '02

28 Mar '02

the Invisible Hand said you should talk to the face instead. Go figure. A monk I met on the street, however, said: "Even stupid companies can make smart decisions sometimes, the trouble is that you can only tell in hindsight whether the choices made were the right ones". I was also given a copy of a book by Lao Tze before the monk was chased off by aggressive chanters and bongo-drummers from a rival sect. Central London is weird. Sean. | AS3561 (InternetMCI) was once the number 1 ISP, by almost every | measure that existed. The marketplace has not been kind to C&W | since they bought AS3561. Why isn't Adam Smith's Invisible Hand | rewarding C&W? Is C&W number 5 or 6 these days?

6 5