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:[email protected]] > Sent: Wednesday, January 13, 2010 10:19 AM > To: [email protected] > Cc: [email protected] > 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... _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
