Symptom
A second dot1q tag is rejected by the cEdge device.
Conditions
When both vManage and cEdge are running 20.6.2 / 17.6.2
Workaround
Create a CLI-AddON-Template and push the second.dot1q.tag.
Below is an example of CLI-AddON-Template:
!
interface GigabitEthernet3.{{interface-tag}}
encapsulation dot1Q {{dot1Q-tag}} second-dot1q {{second-dot1q-tag}}
ip address {{ip-address-subinterface}}
vrf forwarding 1
ip mtu 1496
!
If the interface is associated it via feature template, pushing it via CLI-AddON-Template with second-dot1q, will fail.
In the above example, if GigabitEthernet3.100 (example) is created / exists via vManage feature template, pushing {{second-dot1q-tag}}, via CLI-AddON-Template, will fail.
Further Problem Description
Seems like, if the interface is associated / created with feature template and if we push the second-dot1q tag via CLI-AddOn template, it is failing.
But when we create an interface, in its entirety from CLI-AddOn, and push it via vManage, it works.
Given CLI-AddOn acts like autonomous mode, config. is blindly pushed / consumed by the edge device.
If it is associated via SDWAN mode, aka controller-mode, we fail as SDWAN does not have the native CLI support for "second-dot1q" feature.
Conclusion: Q-in-Q is not supported in SDWAN (controller) mode across all releases.
