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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

dot1q-tunnel mac table convergence delay

I've configured two switches (A and B) todo dot1q-tunneling (Q-in-Q) for the normal dot1Q trunk between switch C and D. In addition I have a direct link between C and D. Everything works as expected and at normal operation Gi0/24 on switch D becomes blocking by RSTP, and traffic flowing fine between my PingPC 1 and 2.

If I then disconnect the direct link between C and D, RSTP converges instantly and Gi0/24 on both C and D goes into forwarding state.

The problem however is that during normal operation when all links are up, switch A learns PC2's mac address on Gi0/24, and when the direct link between C and D goes down switch A don't know anything about that. None of its interfaces has flapped and he doesn't participate in C and D's STP conversations, so A maintains its MAC table which sais that PC2 is still available on Gi0/24.

So when I try to ping PC2 from PC1 the packets arrive at Sw A but are just bounced back out on Gi0/24, until like 20-30 seconds later when PC2 has broadcasted something or the MAC table on Sw A has expired so it re-learns that PC2 is now available on Te1/2 and traffic is resumed.

If I manually clear the mac-table on Sw A, it obviously starts working instantly.

So, what can I do to improve this situation to get as fast convergence as possible?

dot1q-tunnel.png

Everyone's tags (3)
1 REPLY
New Member

dot1q-tunnel mac table convergence delay

I just found out that I could disable mac address learning completely on the Q-in-Q switches (A and B) with

no mac address-table learning vlan XXX

which seems to solve the problem. Now I only drop packets for 1 sec before traffic is resumed again. Wonderful

Is there any draw-backs of doing that in the topology descibed above? I basically just want the A and B switches to "light" a fiber and transparently pass all traffic between switch C and D, so it would seem okay to me to disable mac learning in such a topology.

Does it cause any more CPU overhead or something to forward frames not using a mac table?

Googling around, I can't seem to find anyone else recommending disabling mac learning which makes me a bit worried. I can't be the first one having this problem...

305
Views
0
Helpful
1
Replies