[c-nsp] IPv6 BGP on 7200

[Gert Doering]

Hi,

(cc'ing cisco-nsp back, as other folks might have ideas)

On Wed, Feb 28, 2007 at 01:38:27AM -0500, Vinny Abello wrote:
> Gert Doering wrote:
> 
> <snip> 
> 
> >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"...
> 
> Just curious about your experiences with 12.2(40) on the Cat5k RSM. We've 
> been running it for a while here and hadn't seen anything out of the 
> ordinary. I'd like to know about any serious problems that we could 
> potentially run into though. Can you share (without getting too 
> infuriated)? :)

OK.  Basically it started with a new VLAN, being trunked from a cat 35XL
to a cat5k, to be routed on the RSM, which had been upgrade to 12.2(40)
about 4 weeks ago.  Connectivity on that VLAN was spurious - sometimes it
worked, sometimes it didn't.  So we swapped cabling and ports on the 35XL,
tried different machines, blaimed the customer, eventually upgraded the
IOS on the 35XL and rebooted it, moved the VLAN to a different trunk
and back, checked all possible spanning-tree things, and couldn't make it
work.

Yesterday, something caught my eye, during "I have no idea what *else*
could be the problem":

# this is from the cat5k towards the RSM in slot 9
switch> sh trunk 9/1
Port      Vlans allowed on trunk
--------  ---------------------------------------------------------------------
 9/1      1-1005

Port      Vlans allowed and active in management domain 
--------  ---------------------------------------------------------------------
 9/1      1-6,8,11,31,60,66,324,407,415,423,502,512-514,560-561,604,610,712,819,914-915,921

Port      Vlans in spanning tree forwarding state and not pruned
--------  ---------------------------------------------------------------------
 9/1      1-6,8,11,31,60,66,324,407,415,423,502,512-514,560-561,604,610,712,819,914,921


the VLAN we had troubles with is VLAN 911, which got moved to a RSFC
subsequently, but VLAN 915 seems to have the same issues - it's not 
showing up in the last row, so it's either VTP pruned or STP blocking.

STP says "it's not me":

switch> sh spantr 915
VLAN 915

Port                     Vlan Port-State    Cost  Priority Portfast   Channel_id
------------------------ ---- ------------- ----- -------- ---------- ----------
...
 9/1                     915  forwarding        5       32 disabled   0         

so it's VTP ("or something else").

Removing 911/915 from the "pruneeligible" list didn't change *anything*,
so I'm not convinced it's VTP.


On the router side, VLAN 915 looks like this:

Cisco-M-XI>sh int vlan915
Vlan915 is up, line protocol is up 
  Hardware is Cat5k Virtual Ethernet, address is 0050.0f77.cc00 (bia 0050.0f77.cc00)
  Description: VLAN zu XXXX GmbH, sw1-int.eg.jodobo:fa0/15
  Internet address is ...

- so it's definitely "up".

So if the RSM thinks the VLAN is up, why isn't it active on the switch 
side??  And why does it work for about 30 other VLANs on this RSM, some
of them going to the very same cat35xl (914, for example)?

I'm always willing to blame 3500XL or cat5k switches for VLAN mishap - but
as soon as we moved the SVI interface from the RSM in Slot 9 to the RSFC
in the same switch in Slot 15, the VLAN started working, and has worked
fine since then.


It's not *directly* related to VTP pruning, though - even if I completely
disable VTP pruning ("set vtp pruning disable") the VLAN still doesn't
show up on the 9/1 trunk.  So this must be some magic Sup<->RSM IPC 
which isn't working properly anymore...

As I have not yet find a way to recreate this "at will", or to make
it disappear, I can't tell the exact circumstances that make it happen.

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