[c-nsp] 65k SXH2a + internal VLAN brokenness?

David Freedman david.freedman at uk.clara.net
Sat Jun 27 10:09:53 EDT 2009


Hey,

 Have an odd problem with a 65K (SXH2a) where a particular VRF appears to be "broken" (not passing IP traffic) despite it being deleted and recreated, all other (and new) VRFs work fine, I suspect it is down to the internal VLAN it is getting assigned (it keeps getting the same int-vlan each time)

Looking at the CEF adj counters from the aggregate labelled traffic as it comes in (and gets recirculated) I can see traffic passing through the adjacency and into the internal vlan (so it is not dropping the aggregate label traffic)

I decided to do an ELAM capture at this point and found the following differences
(note, in both cases, the destination IP on this box I'm pinging is a loopback)

Working VRF:
< SEQ_NUM                          [5] = 0x17
< CCC                              [3] = b100 [L3_RW]

Broken VRF:

> SEQ_NUM                          [5] = 0x9
> CCC                              [3] = b101 [L2_POLICE]

Working VRF:

< DEST_INDEX                       [19] = 0x380
< VLAN                             [12] = 1022
< RBH                              [3] = b110
< RDT                              [1] = 0

Broken VRF:

> DEST_INDEX                       [19] = 0x7E00
> VLAN                             [12] = 1184 (this is the broken int-vlan)
> RBH                              [3] = b101
> RDT                              [1] = 1

Working VRF:

< L2                               [1] = 1

Broken VRF:

> L2                               [1] = 0


Not quite sure what to make of that, there is a valid cef receive adjacency
for the loopbacks in the VRF so it should punt from internal VLAN to CPU
(but the counters on the loopback of the broken VRF are 0/0 so obviously not)

My current theory is based on reading the contents of CSCsm84073 which suggest
that under some circumstances there is a default deny acl in place on the int-vlan
and it is not programmed with a permit acl on creation, however I can't directly
verify this because I can't use the "show tcam int" command since the internal
vlan doesn't have a real named port, despite appearing as an SWIDB :( 

If anybody has seen this before and could comment I would be most appreciative 
before taking this to TAC.

Regards,

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



More information about the cisco-nsp mailing list