[c-nsp] Unicast flooding?

[Phil Mayers]

Frank Bulk - iName.com wrote:
>> Have you looked at:
>>
>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not
>> e09186a00807347ab.shtml#dfc
>>
>> ...specifically the 1st item "Loss of Dynamic MAC Addresses with
>> Distributed Switching" which could possibly be related, though that is
>> a
>> wild guess.
> 
> Thanks for reminding me about this article.  When I do a "sh
> mac-address-table", am I looking at what's on the Supervisor or line card's
> DFC?

Well, on a 6500 under SXI, it shows me things like:

Module 1:
* 1740  0000.0c07.ac00   dynamic  Yes        160   Po1
* 1740  001e.2a6f.5c37   dynamic  Yes        220   Po1
* 1740  0015.c706.8c00   dynamic  Yes        170   Po1
Module 2[FE 1]:
* 1740  0000.0c07.ac00   dynamic  Yes          0   Po1
* 1740  0015.c706.8c00   dynamic  Yes        170   Po1
Module 2[FE 2]:
* 1740  0015.c706.8c00   dynamic  Yes        170   Po1

...leading me to believe it's querying all the forwarding engines on all 
the modules but NOT the PFC on the sup (module 5 in our case) - possibly 
because we've got DFCs in all slots? As the example shows, the module 
and even FE tables within a module can differ.

You can get the raw module local tables (and the PFC one) using:

remote command module N sh mac-address-table [dynamic] [vlan N]

If the active sup is in slot 5, these are equivalent:

remote command module 5
remote command switch

...and on the sup I see, using the above example:

Displaying entries from SP:
RM  PI_E RMA  Vlan   Destination Address   Address Type XTag LTL Index
---+----+---+------+---------------------+-------------+----+-------------
No  Yes  No   1740   3333.0000.0016        static          0   0x802 

No  Yes  No   1740   3333.0000.0001        static          0   0x802 

No  Yes  No   1740   3333.0000.000d        static          0   0x7FF8 

No   No  No   1740   0000.0c07.ac00        dynamic         0   0x340 

No  Yes  No   1740   0015.c70b.9000        static          1   0x380 

No   No  No   1740   001e.2a6f.5c37        dynamic         0   0x340 

No   No  No   1740   0015.c706.8c00        dynamic         0   0x340 


...which looks like an amalgam of the module MAC tables. We're not 
running mac sync or anything odd.

You can "remote command [switch|module N]" (or "attach N") and run

sh mac-address-table detail

...but based on the deafening silence in response to a query the other 
week, no-one knows what those flags mean - maybe you can see a pattern 
in your problematic entries though (yay I just love reverse engineering 
the 6500 forwarding architecture - thanks cisco!)

> 
> When I turn it on, I get this message:
> 
> 	Mutual_7609(config)#mac-address-table synchronize
> 	 % Current activity time is [160] seconds
> 	 % Recommended aging time for all vlans is at least three times the
> activity interval
> 
> The aging time of the CAM?  By default it's 300 seconds, so working
> backwards, I would want a "Current activity time" of 100 seconds, but that
> doesn't appear to be an option.  So I've now increased the mac address-table
> aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also
> to 480 seconds.

Interestingly, at some point when I was testing either SXH or SXI, I 
recall this very time (480 seconds) magically popped into the nvgen 
without any input from me. I can't remember when, and it seems to not be 
there now. I've seen hints that VSS systems use the mac sync / move 
notify stuff behind the scenes to sync up MAC tables across chassis - of 
course since you're on a 7600 that should not be relevant.

sh mac- sync stat

...might be illuminating now that you've got it running, but I'm afraid 
the output baffles me...