[c-nsp] Unicast flooding?

[Frank Bulk - iName.com]

Good news is that with the mac-address-table synchronize command things have
been stable for 2 hours, a new record.  More below.

Frank

> -----Original Message-----
> From: Phil Mayers [mailto:p.mayers at imperial.ac.uk]
> Sent: Wednesday, January 13, 2010 10:19 AM
> To: frnkblk at iname.com
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Unicast flooding?
> 
> 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

The output under SRB is a bit different:

Mutual_7609#sh mac-address-table
Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
   280  0007.e96b.06fb   dynamic  Yes        295   Gi1/32
   150  0030.d700.1afe   dynamic  Yes        295   Gi3/35
   293  001e.e573.ee2e   dynamic  Yes          5   Gi1/39
   293  0023.69c4.d0a7   dynamic  Yes        295   Gi1/39
   572  0021.29d9.2dbb   dynamic  Yes        295   Gi3/47
   280  001e.e573.edda   dynamic  Yes        295   Gi1/32


> ...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? 

Perhaps.

> As the example shows, the module
> and even FE tables within a module can differ.

There's times where I've seen nothing for "sh mac-address-table", but when I
specify a port, I do see it listed (notice that it mentions "Line card 3"):

Mutual_7609#sh mac-address-table int gi3/45
Displaying entries from Line card 3:

Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+----------------
*   10  0023.69c4.d0da   dynamic  Yes          5   Gi3/45
Etc.

> 
> 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!)

Those remote commands work for me here, but as you said, who knows what
those flags mean.
 
> >
> > 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...