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?
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...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where the spok...
On 24th August 2021, Cisco announced the latest IOS XE release - Cisco IOS XE Bengaluru 17.6.1a
IOS XE 17.6.1a unlocks various routing features and enhancements comprehensively covering different technology segments such as voice, security,...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where th...
SummaryRequirementsConfiguration StepsVerificationFAQTroubleshootingReferences & Tools
In the past when IOS 12.x was hot stuff we used MD5 to authenticate OSPF neighbors. This worked great on ethernet networks because OSPF is a m...
Chapter 1 – Pre-requisite
You have Root or Super Users access privileges of Cisco Prime Infrastructure.
You have access credentials of Cisco DNA Center.
You use Cisco Prime Infrastructure version 3.5 and above which is compatible with Cisco DNA Center v...