Re: Let's talk about Distance Sniffing/Remote Visibility
Date: Thu, 28 Mar 2002 12:19:55 -0500 From: Richard A Steenbergen [EMAIL PROTECTED] (snipping throughout) Disk I/O on a sniffer box? Sounds like you've been sniffing something other than packets my friend. :) I like to log interesting packets; I agree with Carl. 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 D-Link DFE-570TX are _very_ cheap if you're happy with 32-bit / 33 MHz PCI. [ snip FreeBSD + Alteon ] I did not know about the partial-packet DMA transfers. M 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(). :) Never done this. About how much capacity does the zero-copy approach add? -- 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 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED], or you are likely to be blocked.
Re: Let's talk about Distance Sniffing/Remote Visibility
On Thu, Mar 28, 2002 at 05:59:20PM +, E.B. Dreger wrote: I like to log interesting packets; I agree with Carl. Logging interesting packets is easy enough, its logging ALL packets that would be a problem. At any rate, you'd run out of harddrive space pretty quick if you were pushing max performance at any length of time. I can write a linerate FastE's worth of data to a $100 IDE disk on a $100 processor easily enough, so as long as you're buffering it intelligently it shouldn't be an issue. 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(). :) Never done this. About how much capacity does the zero-copy approach add? Eliminating the bulk data being DMA's across the PCI bus is what adds most of your capacity. Doing zero copy just lets you spend all your CPU time doing actual analysis instead of copying stuff around unnecessarily. I never did get the opportunity to benchmark it at 1.4million packets/sec, (I spent more time trying to get the 20ft of fiber to reach the lab at the previous employeer than I did writing the code to do this in the first place) but I don't see any reason it shouldn't work, with proper interrupt coalescing of course. -- Richard A Steenbergen [EMAIL PROTECTED] 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)
Re: Let's talk about Distance Sniffing/Remote Visibility
Date: Thu, 28 Mar 2002 13:14:17 -0500 From: Richard A Steenbergen [EMAIL PROTECTED] Logging interesting packets is easy enough, its logging ALL packets that would be a problem. At any rate, you'd run out of harddrive space pretty quick if you were pushing max performance at any length of time. I can write a linerate FastE's worth of data to a $100 IDE disk on a $100 processor easily enough, so as long as you're buffering it intelligently it shouldn't be an issue. This is true. Logging interesting packets, efficient buffering, and selective parsing make the big difference. I guess it also depends on log format: Raw packet( fragment)s work great. Human-readable -- a la, say, Linux kernel verbose IP logs -- make things get ugly in a hurry. With fixed-size packet captures, it would be trivial to use a disk slice as one big scratchpad, much like a swap partition. No real need for fs overhead, and one could reserve blocks for indices or other conveniences. Eliminating the bulk data being DMA's across the PCI bus is what adds most of your capacity. Doing zero copy just lets you spend all your CPU time doing actual analysis instead of copying stuff around unnecessarily. H. Looking back at Agner Fog's Pentium optimization guide, it does appear that the memblk cp would be less of an issue than the DMA transfers. I never did get the opportunity to benchmark it at 1.4million packets/sec, (I spent more time trying to get the 20ft of fiber to reach the lab at the previous employeer than I did writing the code to do this in the first place) but I don't see any reason it shouldn't work, with proper interrupt coalescing of course. It would be an interesting test. But ~100 MB/sec of traffic would choke most any single spool drive... and, assuming that all the data were of interest, it would probably take people awhile to review all the data. -- 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 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED], or you are likely to be blocked.
Re: BGP without an IGP
### On Thu, 28 Mar 2002 13:40:51 -0500, Abarbanel, Benjamin ### [EMAIL PROTECTED] casually decided to expound upon ### 'Randy Bush' [EMAIL PROTECTED], Russ White [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Change Control
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
