Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

6509s with sup720 exhibits unicast flooding behavior

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?

6 REPLIES
Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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

Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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.

Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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.

Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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.

Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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.

Community Member

Re: 6509s with sup720 exhibits unicast flooding behavior

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

711
Views
0
Helpful
6
Replies
CreatePlease to create content