×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

6509s with sup720 exhibits unicast flooding behavior

Unanswered Question
Dec 12th, 2006
User Badges:

We have two 6509s, each with 2 sup720s and PFC3Bs, and each with 4 line modules cards that have DFC3Bs on them. We have an L2 distributed etherchannel between the two 6509s, the etherchannel is made up of the 4 gig ports on the two supervisor modules - gi5/1, gi5/2, gi6/1 and gi6/2. We have observed lots of unicast flooding on our vlans. We have brought the arp timeout for the vlans down to 300 seconds to match the mac timeout, but the flooding persists. We are now going to set the mac timeout to 14400 to match the default arp timeout to see if this has any effect. While troubleshooting this problem, we ran across the command "mac-address-table synchronize [activity-time,auto]". There is very little documentation on what this command is for and when you should consider using it. We're wondering if we are experiencing the mac address problem because the mac-address-tables on the PFCs and DFCs might not be getting synchronized??? But, we don't want to use a command without knowing what effects it may have. Does anyone know when this command should be used?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
webnetwiz Tue, 12/12/2006 - 09:39
User Badges:

We're experiencing the same problem. What version of IOS are you running on your 6500s?

CHRISTINE BERNS Tue, 12/12/2006 - 12:00
User Badges:

We're running 12.2(18)SXF5. The interesting thing is that we just replaced two older 6509's running hybrid mode and on those systems bringing the arp timeout value down to 300 seconds resolved the unicast flooding problem. After we installed the new native mode 6509's, we started seeing the unicast flooding again.

webnetwiz Tue, 12/12/2006 - 16:27
User Badges:

I'm running 12.2.18.SXD4, and it's the same behavior. I actually had an SR open with Cisco in regards to this, and was told that this is standard behavior (which it is, to some extent), but had no time to pursue this issue at the moment. Wonder if anyone else is experiencing this with native code on Sup720.

CHRISTINE BERNS Wed, 12/13/2006 - 06:17
User Badges:

I also have a ticket open with Cisco to troubleshoot the problem and hopefully find a solution. I've also looked at many bug reports related to distributed etherchannel and unicast flooding, but all of the bugs that seem to apply are reported as fixed for the IOS version we are running.

webnetwiz Wed, 12/13/2006 - 11:26
User Badges:

If you can do me a favor and keep this thread going with updates as far as what solution Cisco comes back with to you. I'd really appreciate it.

CHRISTINE BERNS Thu, 12/14/2006 - 07:35
User Badges:

Below is the latest from Cisco for my case. I have eliminated bug no. CSCin78242 as being the cause in our network. I am now trying out the fix described in bug no. CSCef72013. I set the router-mac aging time to 14400 to match my current arp timeout and mac aging time. This seems to have halted the unicast floods. I want to do some further investigation though to determine whether the flooding has stopped completely or has just been significantly reduced, so we'll be watching traffic closely for the next couple of days.



"Thanks for the update. I have been reviewing your issue and the behavior you're describing so far sounds like a bug as that MAC entry should not be aging out of the table that fast. Did you change the MAC aging time on all the vlans that are affected or just 1. Also, even though the code that you're running is not listed per say in the following bugids, I would like for you to take a look at them especially with regards to the etherchannel being on 2 different blades which I see that you have configured on your switches. You could try placing all the ports within the channel on 1 blade on each side of the channel to see if that clears the issue. Also check out the bug on the SPAN session being the root cause as I see that you are currently running a SPAN session on modules that have DFCs which could be the root cause. Try disabling the SPAN session to see if the issue clears.


http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeh53682&Submit=Search


http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef72013&Submit=Search


http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin78242&Submit=Search


If you could do some testing to eliminate these bugs as being the root cause of your issue that would be great."



Actions

This Discussion