[c-nsp] Cisco Security Advisories / 12.2(31)SB and IPv6

Gert Doering gert at greenie.muc.de
Thu Feb 15 13:59:23 EST 2007


Hi,

I'm copying this back to cisco-nsp (I hope you don't mind), to share
my findings.

On Thu, Jan 25, 2007 at 10:56:08PM +0000, Ian Dickinson wrote:
> Gert Doering wrote:
> > While I can't answer this - I'm also worried about the same issue.
> > 
> > We're using 12.2(18)S with good success for IPv4+IPv6+MPLS, and are
> > fairly unwilling to restart the IOS lottery right now.
> > 
> > So is there any (25)S or (28)SB* release that people can really recommend?
> 
> No IPv6 yet, but we've been happy with 12.2(28)SB[23456] and 12.2(31)SB2
> on G1's running as full table, MPLS-TE+LNS - these previously ran 12.3(18+).

Today, we've moved an 7301 to 12.2(31)SB2, and *of course* IPv6 broke
in the process.

The setup is really, really simple and straightforward: IPv6 unicast
routing (with IPv6 CEF) between dot1q subinterfaces on GigE0/0.

And, lo and behold, the 7301 eats all IPv6 packets larger than 1482 
bytes (even though "show ipv int" claims "ipv6 MTU 1500").  Of course 
only transit packets (CEF path), so pinging from the router (CPU 
forwarding path) doesn't exhibit the problem.

It's reproduceable - set "ipv6 mtu 1490" on the interface, and watch 
the largets transmittable packet size drop to 1472 bytes.

Seems someone forgot to count the Ethernet header when implementing the
"will this packet fit into the target interface MTU?" check...  what *do*
folks at Cisco smoke these days...?


To work around this:

 - set "mtu 1530" (or whatever, as long as its larger than 1500) on the 
   GigE0/0 base interface

 - set "ip mtu 1500" on *all* IPv4 subinterfaces (hooray)

 - set "ipv6 mtu 1518" on *all* IPv6 subinterfaces

I haven't tried this on FastEthernet interfaces yet - but I'd expect this
to be fun, given that the more recent code has restrictions due to known
bugs with Digital chips and larger physical MTU...


(NB: IPv6 OSPF worked - which sounds surprising, as this is quite sensitive
to MTU issues.  But then, OSPF is done in the CPU path, and not IPv6 CEF
forwarded - and the CPU forwarding path does not have this bug.)


This *might* be related to CSCse73250, even though the description reads
quite "the other way round" - and of course, there is no fixed version,
just a very good "workaround" (turn off IPv6 CEF, watch your router die).


... I *knew* why I harrassed TAC long enough so that they are now going to
build 12.2(18)S13, with all fixes... *grumble*.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de


More information about the cisco-nsp mailing list