Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header

Vinny_Abello at Dell.com Vinny_Abello at Dell.com
Fri Sep 30 10:53:19 CDT 2011


Path MTU discovery would also break... oh wait, that's usually broken anyway.

-Vinny

-----Original Message-----
From: Saku Ytti [mailto:saku at ytti.fi] 
Sent: Friday, September 30, 2011 10:27 AM
To: nanog at nanog.org
Subject: Re: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header

On (2011-09-30 10:09 -0400), Christopher Morrow wrote:

> a switch to be used that stops processing this sort of thing, in an
> internet core (and honestly most enterprise core) routers, all I want
> is packet-in/packet-out. there's no need for anything else, stop
> trying to send line-rate packets to the cpu.

This would break e.g. RSVP. For some instances dropping all of them in hardware
is an option, for other instances ignoring and forwarding without understanding
is ok but some situation you simply must punt.

> no. all you need is a default 'do not process these, just fwd them'
> switch. (or, a switch at any rate that the operator can select one way
> or the other, they SHOULD know what is the best for their deployment).

It would also break L4 ACL under certain situations, as well as RSVP as already
explained. And probably issues I'm not aware of. Unsure if blind forwarding is
best option. But I'm all for giving operator options, but calling it stupid
that vendors punt something is misguided.

> I really think zero limit is the right limit... (for a large number of
> deployments)

Traceroute would also break. Unpoliced punting certainly is extremely unwise,
but punting to a level that does not introduce significant CPU load, should be
safest default.


-- 
  ++ytti




More information about the NANOG mailing list