- NANOG - lists.nanog.org

RE: Force10 Gear
by hobbit＠avian.org 07 Sep '08

07 Sep '08

This once again quickly reduces to a question of real-life need in my mind. What proportion of useful traffic actually carries IP options these days? Who uses them other than fooling around with the occasional source-routing or RR exercise, if their local infrastructure even permits it to be sent? Many sites just firewall off all that stuff because in real life they never use it or need it. For them it's more trouble than it would be worth trying to process correctly, especially in a security context, so that's their accepted real-life practice. Clearly, those who design the routing iron are well aware of such practice because they optimized the hardware to process the far more typical no-options day to day traffic. While they still accomodate options it's evidently done as kind of an add-on bandaid way outside of the normal path. Now you have to ask yourself where the people making the iron cheaped out -- should they have designed in the ability to handle all these corner cases at their normal wire speed, or should they have dismissed such foolishness and concentrated on what they knew the industry actually requires? How much additional cost does anyone think ASICs to deal with options and other seldom- seen conditions at the same transit rates would incur? I think the most common answer would be "f'geddaboudit". The TTL=1 is an interesting one, but really, under normal conditions shouldn't happen that often. People tracerouting certainly shouldn't expect 100% reliability on getting the "expired" ICMP back, and automatically throttling the rate of errors from routing loops might have certain benefits so why try to handle *every* expired TTL that comes along? It seems like taking anything out of the fast-path should only be done if the slow path is good and ready to accept it, and if someone's trying to hammer the box with stupid stuff then most of it should simply be dropped. Handling it should be near the bottom of the main processor's priority list ... and rather than allow the fast iron to pile way too much crap in its inbox to be dealt with, process-switching should have a VERY short queue and be able to tell the lower levels "not now" and simply increment some obscure counter for "stupid packets dropped" without letting that impinge on the more important tasks at hand. Having the whole box fall over is the *least* acceptable result. _H*

1 0

Re: ingress SMTP
by matthew＠sorbs.net 07 Sep '08

07 Sep '08

----- Original Message ----- From: Michael Thomas <mike(a)mtcc.com> Date: Monday, September 8, 2008 7:31 am Subject: Re: ingress SMTP > > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. As a matter of interest, it took but a couple of person hours to sort this out at my last place of work, the largest time chunk in equation was the compiling of TLS and the various SASL modules into Postfix. The second from largest chunk of time was to get the script to get the information required from the various other back end mail servers on campus, including, but not limited to, Lotus Notes, M$ Exchange, and Sun/iPlanet messaging server and it's LDAP server. The only down side to the system was password changed took up to 15 minutes to get to the mail systems as there was no direct connection between the external gateways and the internal auth systems. Of course the above doesn't take into account the several weeks of political badgering and grandstanding that we endured to get the faculties to actually accept that that was the way it was going to be. They couldn't stand that there would only be incoming and outgoing mail via the central gateway. Such is life at Universities. Regards, M

2 1

Re: Force10 Gear
by David Newman 07 Sep '08

07 Sep '08

Paul Wall wrote: > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the > higher-end boxes can program a full routing table (and then some) > worth of prefixes in CAM. > > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a > couple of gigs of traffic at line rate is a walk in the park for any > modern product billed as a "layer 3 switch". The differentiator > between, say, a Dell and a Cisco, is in the software and profoundly > not the forwarding performance. Without disagreeing with your main point, there are still plenty of ways to bring even very large boxes to near-zero forwarding rates: 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets without options at up to 770 mpps, but when packets have options the maximum is more like 20 kpps. And that's a "high-speed" example; the options forwarding rate is more like 0 pps with some other devices. Silicon that forwards packets very fast is only good when header lengths are fixed. 2. Use weak hashing algorithms. Some switches (names removed to protect the guilty) hash on the low-order three bits of MAC address to decide which of eight ASICs will forward a packet. I have heard of, but have not tested, devices that use only three bits for making OSPF ECMP decisions. Not surprisingly either technique can lead to lots of hash collisions in routed environments. 3. Offer IP multicast. Maximum forwarding rates for multicast are rather different than IP unicast with some vendors' implementations, and may be affected by group count, mroute count and amount of replication. dn

4 4

Re: only WV FIBER now peering with Atrivo / Intercage
by Brandon Butterworth 07 Sep '08

07 Sep '08

> > Anton's post that GX is still providing them transit is a bit curious, since > > I was under the impression GX had severed all ties with Atrivo. But the > > table does not lie, a path of "174 3549 27595" is clearly transit. GX, care > > to comment? > > After poking for a bit, it's unclear what, if anything, GX is or isn't > doing here. Does it matter? The implication of this thread is the imposition of an internet death penalty on this AS. In which case people will have to hound each AS they're seen behind, whatever they're providing, and that will change as they run for cover. This seems a change of tactic from just null routing people you don't like on your own network brandon

4 3

only WV FIBER now peering with Atrivo / Intercage
by Gadi Evron 07 Sep '08

07 Sep '08

http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0#AS27595 Gadi.

6 8

BGP Clueful from Windstream/Alltel? (Resend-addendum)
by Scott Morris 07 Sep '08

07 Sep '08

Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Sorry for the resend, but if you could contact me at ccie.4713(a)gmail.com that will be much easier! Any emails to the subscribed address here won't work, which is the problem I'm attempting to solve with Windstream! :) Thanks in advance! Scott Morris swm(a)emanon.com

1 0

SMTP rate-limits [Was: Re: ingress SMTP]
by Paul Ferguson 07 Sep '08

07 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Simon Waters <simonw(a)zynet.net> wrote: >If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. > Okay, I can understand why an ISP might want to apply SMTP rate-limits, but to clarify, I'm assuming you meant that ISPs (if they do block tcp/25 outbound to anything other than their own MTAs) need to watch for excessive SMTP utilization, which might indicate a spammer-client (?). ...as opposed to arbitrary SMTP rate-limits. Yes? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIwO90q1pz9mNUZTMRAneaAJwMgmIz99bPUYJ2HgUD6Zs1MOFXgQCgmsPY eUtV2bBKymWfxNwNOgWfp5w= =bdk+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

4 3

BGP Clueful from Windstream/Alltel?
by Scott Morris 06 Sep '08

06 Sep '08

Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Thanks in advance! Scott Morris swm(a)emanon.com

1 0

Re: [Fwd:] Nvidia NICs with duplicate mac addresses
by bmanning＠vacation.karoshi.com 05 Sep '08

05 Sep '08

it was real. (I still ahve some 3c503's with the problem :) this is one reason why it is so important to be able to override the MAC. --bill On Fri, Sep 05, 2008 at 10:53:28AM -0400, Scott Berkman wrote: > This reminds me of a story I was told a while back that there was a batch > of 3com NIC's that all went out with the same MAC from the factory. I > never found out if that was a rumor/urban legend or the truth. Anyone > know firsthand or have an article about that? > > -Scott > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs@seastrom.com] > Sent: Friday, September 05, 2008 10:33 AM > To: nanog(a)nanog.org > Subject: [Fwd:] Nvidia NICs with duplicate mac addresses > > > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... > > --- > > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. > >

3 2

[Fwd:] Nvidia NICs with duplicate mac addresses
by Robert E. Seastrom 05 Sep '08

05 Sep '08

Forwarded to NANOG in the interests of wider awareness... having been there and torn out my already scarce hair, duplicate MAC addresses can really mess up your day... --- Just when you thought this couldn't happen any more... Copying from a different email list... mac address 04:4b:80:80:80:03, was showing up in multiple places across the network. I googled the mac address and discovered that other people are having the same issue with this mac address. Below are some links describing the problem: http://forums.nvidia.com/index.php?showtopic=22148 http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html I just wanted everyone to know about this problem in case you run across similar slow "connectivity" issues. I believe the network card is made by NVIDIA.

8 11