0·
29 days agoI think I understand what you’re trying to do, but I’m having trouble parsing this sentence:
The big issue is that the interface on the bridge the virtual node is connected to is created on the fly when you connect the node to the external connector
Ok, the diagram has been very useful for me to understand.
My thinking is that for the Linux bridge (LB), you’ll have to create it with “protocol 802.1ad”. So something like this:
I presume that there is no problem with manually creating the bridge? Also, compared to the example from the link, I’ve modified it to set the default port VID (PVID) to 420. This means that if any frame comes into LB and does not have an S-tag, then an S-tag with the port VID will be applied to the frame upon ingress.
Using the standard nomenclature of 802.1ad Q-in-Q, an S-tag (S for “service provider”) is the outermost tag with TPID=0x88a8, and a C-tag (C for “customer”) is the innermost tag, which would be a standard 802.1q VLAN tag with TPID=0x8100. That said, when I say “innermost” and “outermost”, that only applies to double-tagged traffic. It is entirely possible to single-tag using an S-tag, and that’s exactly what will happen if a VN sends an untagged frame to LB, as an S-tag with VID 420 will be added. But there wouldn’t be an inner C-tag.
If VN sends an 802.1q C-tagged frame to LB, then that’s still not an S-tag and so LB will also add an S-tag upon ingress, making this frame now doubly tagged.
I also omitted “vlan_filtering 1” because that would cause all traffic with an unknown S-tag VID to be dropped. Dropping such traffic is the default for a standard switch, but it may aid your troubleshooting if LB is configured as permissively as possible. At the very least, it means that unknown S-tags can at least be inspected using tcpdump upon ingress, rather than being dropped outright.
For link 1, there’s nothing we can do, but we also shouldn’t have to do anything. If VNs are attached to the LB as a subordinate port, then they would be exchanging either untagged or single C-tagged traffic. And that’s fine because that’s exactly what LB is prepared to handle.
For LB’s port connected to link 2, this must be configured as a trunk port for VID 420. This will cause LB to pass doubly tagged frames to VS, which is what we want. For link 2 facing VS, no special configuration for 802.1ad or 802.1q is necessary, since the frames will enter VS as if standard Ethernet; the TPID takes up the same position in the header as an EtherType, and standard switch behavior is to forward any unknown Ethertypes. If VS has any configurable options, any options that are VLAN-aware ought to be disabled.
For link 3 facing VS, this isn’t anything special to configure, as described above. But for the P1 port connecting to link 3, this must be configured as a trunk port for VID 420.
Between P1 and P2, this is also a trunk for VID 420.
On P2’s port connecting to PN, this will be an untagged 802.1ad port for VID 420, with the PVID set for 420. By being an untagged port, P2 will strip the S-tag from any frame egressing to PN, thus yielding either an untagged Ethernet frame or a singly C-tagged 802.1q frame. And when PN sends untagged or C-tagged traffic that ingresses P2, the S-tag for PVID 420 will be added.
Such ingress traffic will propagate from P1 as either S+C double tags or S-only single tag, all the way back to LB. But when proceeding to the subordinate port that connects to a VN, the LB will know to strip the S-tag, thus yielding either C-tagged or untagged traffic.
In this way, the whole network can be traversed by wrapping all of VN’s traffic with an S-tag, irrespective of any C-tags that traffic already had. You may have to play around with the exact mechanics of the Linux bridge to fit your circumstance, but this should yield a working setup.
Good luck!