[c-nsp] IPv6 BGP on 7200

[Gert Doering]

Hi,

On Tue, Feb 27, 2007 at 12:22:08PM +0000, Paul Cairney wrote:
> I mentioned this a couple of time on-list earlier this month
> following the release of 12.2(25)S12 but nobody else indicated they
> were also having this problem.

We haven't tried it (partly because of other folks' warnings)

> Sadly ipv6 is one of the main reasons we are using this train,
> I have left this image running on a quite router in a pop with no
> v6 customers attached however it makes this release unsuitable for
> the rest of the network :|

Stay *away* from 12.2(31)SB2 for IPv6.

When we upgraded from 12.2(18)S, we had the problem (already sent to 
cisco-nsp) that the router wouldn't *pass* full sized IPv6 packets - but
happily pinging with full-sized packets.  Something in the CEF path is
broken, and doesn't take the 18 byte Ethernet header into account when
deciding "this packet is too big to send out" - transit of up to 1482
byte packets worked fine.

Setting "mtu 1518, ip mtu 1500, ipv6 mtu 1518" on the interfaces (GigE,
fortunately) made IPv6 transit work.

*BUT* - yesterday this router had to reboot (power outage), and 
subsequently, all OSPF adjacencies refused to come up.  Guess what, 
IPv6 MTU mismatch - IPv6 OSPF looks at the configured MTU (1518) and
sends out packets with that MTU - and all other routers on that LAN
had 1500 (of course), thus failing to establish neighbourships.

So we have a router that either does IPv6 OSPF, or forwards IPv6 packets,
but noth both at the same time - unless you fiddle with interface options
after every reboot (ipv6 ospf mtu-ignore fixed *some* of the adjacencies,
but for some reason, the remaining two only came up after configuring
"ipv6 mtu 1500" until adjacencies had formed, and then increasing the
mtu value again)


This is a damn shame - and I really wonder how software development at
Cisco is testing this.  This is *so* obvious, anybody ever checking 
"typical problem sources" (will it forward a packet of protocol X, Y, Z
at the minimum and maximum packet sizes?) should notice it.


And at the same time, TAC is giving me the runaround "we don't want to do 
a 12.2(18)S rebuild, please go to 12.2SB!!!" (after argueing for some
number of e-mails, the agreed to do a 12.2(18)S13, and do it not "some
time in June" but "quickly").


> Security fixes Vs having stable IPv6 BGP.... guess your best bet
> for now is to stick the workarrounds from last month back into your
> config and downgrade, thankfully the previous 12.2(25)S releases
> have been relativly issue free until this.

The current round of "we only did bug fixes" IOS versions is really really
crappy.  Don't get me started on 12.2(40) on Cat5k RSM...

"I've seen better IOS versions"...

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