I have a network that connects two buildings with switch A and switch B. These two switches are connected with a pair of trunks using 1G dishes. I have about 10 vlans configures in my environment and everything works fine for my equipment and networks. I have a need to connect a 3rd parties network (switch C and D) over my network but I dont want to intermix the two networks. I have verified they have cisco switches as well and none of the vlans overlap (except we both have native vlan 1, I know, I'm already considering changing to a different native vlan). How can I bridge their switches using my link? I tried turning off lldp and connecting their trunk to my switch on an unused VLAN and that didnt work. I changes my ports to trunks and only allowed vlans 1,400,600,1002-1005 and I was able to ping from C to D (over A & B) with different IP blocks then I use in my network but when I added a vlan to switch C it did not show up on switch D vtp but they do when they are directly connected? So in short how can I connect C & D over my A & B so that C&D do not show up as cdp nei in my environment and C&D do not show my switches in cdp nei and so that all traffic and admin of C can reach D? I don't need to (or want to) be able to access anything on C or D and I certainly do not want C&D to see anything in my network. I can make any changes to my environment needed but I can only make suggestions for changes on the vendor network. Would it help if I moved everything in vlan 1 to vlan 2 and made it my native/management vlan? I want the connection between C&D to be as transparent as possible almost like they are directly connected. (I would rather NOT put them on one set of dishes and me on the other, I like having the redundant pair of dishes even though I do not need 2Gbps throughput, they are on a port channel group for load balance and redundancy)
Let's add another lab setup with a few more switches for Customer 1:
The configuration is same as before. The ISP Core switches A and B use the same dot1q-tunnel config with Vlan 10 as native vlan for all connections to Customer 1. Switches C, D, E and F at the customer site use a simple trunk with native vlan 1.
The logical topology for Customer 1 looks as if all his switches were connected to an unmanaged switch that transparently passes all traffic including the L2-control traffic for CDP, LLDP, STP and VTP.
So when you do a "show cdp neighbor" e.g. on switch C, it will show switches D, E and F as neighbors.
Of course, you also have full IP connectivity in the vlans 1, 20, 40 with isolation from the ISP Core and any other customer even in case of overlapping vlans.
Note: Things do change if you want/need to use the protocols LACP, PAGP or UDLD as those require a point-to-point design.
As the official documentation states:
To avoid a network failure, make sure that the network is a point-to-point topology before you enable tunneling for PAgP, LACP, or UDLD packets.
Hope I made my point clear, otherwise please let me know.
You have! Had to pondered what was happening, to realize my mistake. Which was, since we're hiding original VLANs, I had a L3 mindset, that the original MACs would be encapsulated too. Of course, that's not the case.
You description treating the internal tunnel as a switch is very apt. Unfortunately, believe this internal switch is "missing" a couple of features.
Consider a "normal" set of VLAN switches, SW1<>SW2<>SW3. The interconnection are all trunks. SW1 has VLANs 11 and 12, SW3 has VLANs 31 and 32, and SW2 has VLANs 11, 12, 21, 22, 31 and 32. So, what happens, if a SW2 host, in VLAN 21, ARPs for another host in VLAN 21? That broadcast (by default) is sent down the trunks to both SW1 and SW3, and then ignored by those switches. To make that more efficient, we can prune VLANs off the trunks, but I suspect we have a somewhat similar issue with .1Q ports, that cannot be pruned. I suspect, any frames injected into a tunnel port, that we don't have a specific tunnel egress port for, will be flooded to all tunnel egress ports.
Given:
Where switch0 is the tunneling switch, switch1 has VLANs 20 and 30, switch2 just has VLAN 20 and switch3 just has VLAN 30, I suspect a broadcast on switch1, made on VLAN 20, will be transmitted to both switch2 and switch3 just as if all the interfaces were all trunk ports. But, on real trunk ports, we could, on switch0, limit its egress to switch2 to only allow VLAN 20 and also limit its egress to switch3 to VLAN 30.
Probably not usually a significant problem, but there is a reason for pruning VLANs off trunk ports.
Another interesting case, which is very highly unlikely to be encountered, say on switch2 and switch3 each have hosts, that have the same MAC (via LAA). Normally, this is a non issues, because the MAC is unique to per VLAN. However, switch0 will (?) have that MAC in the tunnel VLAN, but known on two separate egress ports. So, switch1 sending to that MAC on VLAN 10, will switch 0 send it out to both switches 2 and 3? If it does, each switch will determine whether the incoming frame was intended for VLAN 10, so only switch 2 will forward the traffic to its (correct) host, but all the replicated traffic is consuming bandwidth to switch 3.
Since this L2 tunneling isn't limited to p2p, it can have issues that wouldn't normally be issues.
The point is that dotq-tunnel interfaces are no trunk ports!
Agreed! In fact, I'm emphasized that point a couple times in my prior replies.
However these QinQ tunnel interface ports, do accept multi VLAN traffic, from trunk ports, and also transmit multi VLAN tagged traffic, to trunk ports. So as I also wrote earlier, they are not classical trunk ports but do share some attributes of trunk ports.
Let's say you configured "switchport access vlan 100" on port Gi1/0/1. Then the backplane of the ISP Core switch will only send traffic for vlan 100 to this port. It will not send any traffic for any other vlan to this port so there is no need to think about pruning or consuming bandwidth by unnecessary replicated traffic. This simply does not happen.
I'm not so sure that's always the case.
Let's again consider this topology:
Let's initially assume, switches 1, 2 and 3 have VLANs, and all are using a trunk port to switch 0. Switch 0 uses VLAN 100, as its tunnel VLAN, internally, to interconnect the 3 switches.
Switch 1 ARPs (a broadcast) for a VLAN 10 host. Where does the ARP broadcast go? Would it also be transmitted to switches 2 and 3, tagged as VLAN 10, to each?
If yes, suppose switch 3 has no VLAN 10 ports. Does this preclude switch 0 from still transmitting the ARP tagged with VLAN 10 to both switches 2 and 3?
Isn't this the same issue, if instead of QinQ, switch 0 was using "normal" trunk ports?
The difference, though, with "normal" trunk ports, I can prune (block) VLAN 10 traffic to switch 3. I would do this because I know VLAN 10 isn't being used on that switch, and I don't want to send needless VLAN 10 traffic to switch 3. (With non QinQ, pruning done by VTP would also be an option.)
But, how do we prune VLAN 10, to switch 3, on a QinQ tunnel port?
For something like ARPs, this is unlikely to be a major problem, but it applies to all broadcast traffic. Multicast traffic, might have a similar issue.
Lastly, there's the remote chance we could see the issue with unicast flooding. (Which is why, some design guides recommend, when using L3 distro connecting to L2 access, don't extend/allow L2 access VLANs to span across multiple distro<>access links.)
If effect, I believe, from the view point of switches 1, 2 and 3, they are logically trunk connected to a shared (virtual) switch, and will obtain similar behavior, but unlike a physical shared switch, we cannot (can we?) block VLANs leaving a particular QinQ tunnel port.
In typical practice, I doubt the forgoing would be a practical issue, for one reason, we'll likely limit traffic being sent to a QinQ tunnel port to specific VLANs. I.e. switches 1, 2 and 3 all use VLAN 10 or VLAN 20, not switch 1 connects to a QinQ tunnel port, using VLANs 10 and 20, but switch 2 only connects with VLAN 10 while switch 3 only connects with VLAN 20.
So again, I would need further explanation, why "This simply does not happen.", assuming it also means it can never happen.
You mention LACP, but I recall QinQ mentions you need to use it carefully, like restricting overall QinQ topology, for it to work correctly. I recall, one example of using LACP with QinQ, would be in a physical topology like (which I'm not endorsing as being recommended):
Where switches 1 and 2 provide the QinQ tunnel ports.
Where one LACP link is SW0<>SW1<>SW2<>SW3 using, say VLAN 100 on switches 1 and 2.
Where another LACP link SW0<>SW2<>SW1<>SW3 using, say VLAN 101 on switches 1 and 2.
Where switches 0 and 3 see their two links as "normal" Etherchannel, optionally carrying multiple VLANs.
