Solved: How can I pass another complete network over my network

dajohnso · ‎04-27-2025

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)

Jens Albrecht · ‎04-27-2025

You need to take a look at Layer 2 Protocol Tunneling techniques. As the name applies the traffic between switches C and D is tunneled through your network without affecting it. This also allows switch C and D to see each other via CDP or to exchange vlan information via VTP through the tunnel as if they were directly connected.

You did not mention the hardware of your switches or the software they are running but this should serve as a good starting point:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-12/configuration_guide/lyr2/b_1612_lyr2_9300_cg/configuring_layer2_protocol_tunneling.html

HTH!

View solution in original post

Jens Albrecht · ‎04-27-2025

Yepp, now I see it. I was searching for this info but could not find it. Thanks for this hint.

So same technique, just a different starting point:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/01xo/configuration/guide/tunnel.html

View solution in original post

Joseph W. Doherty · ‎04-27-2025

Yup, also sometimes known as Q-in-Q, as I mentioned in my original reply.

I've only needed to do it once, and in this case, I would be the vendor switch.

Without additional review of material, don't know whether configuration changes would be needed on all switches, but Jens might know.

What I had done worked fine but I also recall I only had to pass one of my VLANs across a MetroE provider.

View solution in original post

Jens Albrecht · ‎05-02-2025

Just completed the swap test to see how the 3560s perform as ISP Core switches. To make things a bit easier, I left the vlans as they were and "only" reconfigured the connection between the 9200 and 3560 switches as well as setting a trunk between the 3560s.

Result:
The 3560s do a perfect job and everything is working as it should.
So the 9200 Customer side switches have full connectivity in vlans 1, 100 and 300 but no connectivity with the 3560s in vlan 1.

Config of the dot1-q tunnel interfaces:

interface GigabitEthernet0/1
 switchport access vlan 200
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel lldp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 no cdp enable

Same interface with all defaults using the "show run all" command:

interface GigabitEthernet0/1
 switchport
 switchport access vlan 200
 switchport trunk encapsulation negotiate
 switchport private-vlan trunk encapsulation dot1q
 switchport private-vlan trunk native vlan tag
 switchport mode dot1q-tunnel
 no switchport nonegotiate
 no switchport protected
 no switchport block multicast
 no switchport block unicast
 switchport port-security maximum 1
 switchport port-security violation shutdown
 no switchport port-security mac-address sticky
 switchport port-security aging time 0
 switchport port-security aging type absolute
 no switchport port-security aging static
 no switchport port-security
 no ip arp inspection trust
 ip arp inspection limit rate 15 burst interval 1
 ip arp inspection limit rate 15
 load-interval 300
 mls qos cos 0
 snmp trap mac-notification change added
 snmp trap mac-notification change removed
 snmp trap link-status
 no cdp enable
 cdp tlv server-location
 arp arpa
 arp timeout 14400
 spanning-tree port-priority 128
 spanning-tree cost 0
 hold-queue 75 in
 hold-queue 0 out
 ip igmp snooping tcn flood
 no bgp-policy accounting input
 no bgp-policy accounting output
 no bgp-policy accounting input source
 no bgp-policy accounting output source
 no bgp-policy source ip-prec-map
 no bgp-policy source ip-qos-map
 no bgp-policy destination ip-prec-map
 no bgp-policy destination ip-qos-map

So the problems seem to be platform- or IOS-version-specific and not related to the configuration.

HTH!

View solution in original post

dajohnso · ‎05-02-2025

ok, so I did the test with a single 4948E as the "core" configuring ports gi1/1 and gi1/2 as the dot1q tunnel and........ Switch C&D CAN ping each other on vlan 1. What ever the issue is, was fixed in the 4500E release and is working on IOS 15.2

so, I think I will upgrade the two core switches to 4948E just to reduce the changes of an issue and make my dish link "more transparent". to my customer "vendor network". I couldn't find what the newest release supported by the older 4948? Its only showing the 4948E (4500E) IOS version. Does anyone happen to know what the last release of the 4500 was (not the 4500e)

Thank you all, for all the help and input. I have learned so much in the last week.

View solution in original post

Jens Albrecht · ‎05-03-2025

@dajohnso ok, now I need to add another level of complexity here...I

Actually it is pretty easy to add more vendors/customers to your network. I used the following setup for further testing:

In order to test the isolation of the customer networks I configured both to use Vlan 1 as their native vlan and both also use Vlan 222 in addition to their unique Vlans.
The ISP Core switches use "switchport access vlan 10" towards customer 1 and "switchport access vlan 30" towards customer 2 on the dot1q-tunnel interfaces. Otherwise same config as previous setups.

Results:
Everything works as expected with clear separation between the networks of customer 1 and 2.
Customer 1 has connectivity between switches C and D in Vlans 1, 20, 40 and 222.
Customer 2 has connectivity between switches X and Y in Vlans 1, 50, 60 and 222.
No connectivity between customer 1 and 2 in Vlans 1 and 222 so tagged and untagged traffic is separated as expected.
No connectivity from customers 1 and 2 to the ISP Core in Vlan 1.
CDP, LLDP, STP and VTP work as expected between switches C and D as well as between switches X and Y.

In summary everything looks fine and you should be ready to go with your 4948Es.

@Joseph W. Doherty I also had a chance to test this setup in CML and results are identical to the physical setup.
For this lab I used 2 x cat9000v-q200 and 4 x IOSvL2 switches. The cat9000v are still labeled BETA but nevertheless doing a good job here.

HTH!

View solution in original post

Joseph W. Doherty · ‎05-03-2025

Perhaps your questions are better explained in Cisco's IEEE 802.1Q Tunneling , such as:

The IEEE 802.1Q Tunneling feature is not restricted to point-to-point tunnel configurations. Any tunnel port in a tunnel VLAN is a tunnel entry and exit point. An 802.1Q tunnel can have as many tunnel ports as are needed to connect customer switches.

I've harped a couple times on these .1Q tunnel ports should not be thought of as either access ports or trunk ports, although they share some characteristics of those port types.

Possibly one way to think of these tunnel interfaces they provide ports to a virtual hub that supports external VLANs.

Or, remember, internally, there's just one VLAN being passed about just like any other internal single VLAN.

However, if you want to use certain p2p L2 features, you need to insure you limit your .1Q tunnel topology usage.

View solution in original post

Jens Albrecht · ‎05-06-2025

@Joseph W. Doherty wrote: this was on actual hardware, correct?

Yes! Similar to the previous labs I used 2 x 9200 switches for the ISP Core and 3560/3750 switches for the customer network.

CML appears to reach its limits as these labs get a bit more complex. When I started configuring this setup in CML, initially things looked good. However, I could not finish testing so saved the lab and wanted to continue the next day. After restart of the lab the L2-control protocols were no longer transmitted over the trunk between switch A and B. So protocols like CDP and VTP only worked between switches C and E and between D and F but every switch only had 1 neighbor according to CDP. Network traffic was still fine so that e.g. switch C could ping all 3 switches in the customer vlans but the control traffic stopped working. So for this kind of lab hardware is the only way to go.

View solution in original post

Joseph W. Doherty · ‎04-27-2025

If I understand your network correctly, I suspect the problem is you're expecting VTP to work between switches C and D while not using the same VTP domain as switches A and B.

I suspect, excluding VLAN 1, it would be easy to logically connect the VLANs on switches C and D if you don't use VTP on them. You would also need to define those switches VLANs to VTP for switches A and B, or don't use VTP at all.

As to the conflict between VLAN 1, between your switches and the vendor's, possibility Q-in-Q, or on the vendor switches, interconnect another VLAN to VLAN 1, and trunk that VLAN like the other vendor VLANs, would work. (These suggestions might be tried in CML.)

Joseph W. Doherty · ‎04-27-2025

BTW, there might be other options, for example VXLAN (?), but would need to know more about your equipment. Don't know what your, 4948 may support (they are old, and EoL, I believe) or what your vendor is using.

My prior reply should work for old or newer Cisco equipment.

Jens Albrecht · ‎04-27-2025

You need to take a look at Layer 2 Protocol Tunneling techniques. As the name applies the traffic between switches C and D is tunneled through your network without affecting it. This also allows switch C and D to see each other via CDP or to exchange vlan information via VTP through the tunnel as if they were directly connected.

You did not mention the hardware of your switches or the software they are running but this should serve as a good starting point:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-12/configuration_guide/lyr2/b_1612_lyr2_9300_cg/configuring_layer2_protocol_tunneling.html

HTH!

Joseph W. Doherty · ‎04-27-2025

You did not mention the hardware of your switches

OP diagram had his switches as 4948s.

Jens Albrecht · ‎04-27-2025

Yepp, now I see it. I was searching for this info but could not find it. Thanks for this hint.

So same technique, just a different starting point:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/01xo/configuration/guide/tunnel.html

Joseph W. Doherty · ‎04-27-2025

Yup, also sometimes known as Q-in-Q, as I mentioned in my original reply.

I've only needed to do it once, and in this case, I would be the vendor switch.

Without additional review of material, don't know whether configuration changes would be needed on all switches, but Jens might know.

What I had done worked fine but I also recall I only had to pass one of my VLANs across a MetroE provider.

dajohnso · ‎04-27-2025

Thanks. So far I have tried to follow this and have been unsuccessful. I did manage to block the cdp now so the vendor switches do not see my switches and I don't see theirs. I setup 4 C4948's on my desk Switch C int gi1/44 is plugged into switch A int gi1/1, same on switch D and B. Switch A and B are trunked via ports 43, 44.

switch C and D have

interface GigabitEthernet1/44
description trunk to slave
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-1005
switchport mode trunk
end

and switch A&B have

vlan dot1q tag native

interface GigabitEthernet1/1
switchport access vlan 22
switchport mode dot1q-tunnel
no cdp enable

now in A&B "sho cdp nei" doesn't show switch C&D (good)

but, switch C and D "sho cdp nei" doesnt show any switches either?

C and D can no longer ping each other, vtp is not populating on switch D?

show vlan dot1q tag native
has no output

Joseph W. Doherty · ‎04-27-2025

You do allow the new carrier VLAN, 22, across your trunks between switches A and B?

Did you also read Jens' reference's section about MTU considerations on the 4500 series? Although the 4948 isn't explicitly mentioned, I recall it's a "pizza box" 4500 sup. Unsure which though, vaguely recall might be equivalent to a sup-V. (It's QoS model, is pre sup-6.)

Also, your wireless links wouldn't have any issue with the slightly larger double tagged frames?

dajohnso · ‎04-28-2025

Using the guide prided in the responses here, all trunks now pass all vlans. C&D are in a dot1q tunnel on A&B. Limited success, pretty much everything is working except vlan 1 and vtp. Not sure if anything else isn't working as I am only testing onmy bench right now and I haven't tried the config with the vendor network yet. I want to get as much working before the cutover to minimize downtime. I have a note out to the vendor to see what their native/management vlan is (really hoping its not vlan 1)

dajohnso · ‎04-28-2025

The wirleess links appear to be pretty transparent. I have had any issues with switch A and B communicating over this link. The issues described above are all between C&D switches.

dajohnso · ‎04-27-2025

Sorry, thought I had added it.

I am using Cisco WS-C4948 running cat4500-entservicesk9-mz.150-2.SG11. The vendor switches are some form of Meraki switch.

dajohnso · ‎04-28-2025

Thanks for the info. I have reread the configuration guide and have had limited success!  Switch C&D can now see each other with "sho cdp nei" and C&D can not see A&B, and A&B do not see C&D as neighbors! Switched C&D can ping each other on vlans (except 1?). VTP is still not populating? On switch C&D "trunks" I am passing all vlans now to the tunnel. Switch A&B now show the tunnel with "show dot1q-tunnel" Very promising as I did not have to make any changes to vendor switches for this config!

here is what I have currently

Switch C&D (vendor)

interface GigabitEthernet1/44
description trunk to slave
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-1005
switchport mode trunk

Switch A&B (Mine/ISP)

spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
vlan 22
name dot1q
!

interface GigabitEthernet1/1
switchport access vlan 22

switchport trunk native vlan 22
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel lldp
no cdp enable
!

dajohnso · ‎04-28-2025

I have also tried without the vlan 22, same result.

interface GigabitEthernet1/1
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel lldp
no cdp enable
end

dajohnso · ‎04-28-2025

more success! Added "l2protocol-tunnel vtp" to int gi1/1 and now VTP is updating! Still cant ping in vlan 1 though.

interface GigabitEthernet1/1
switchport access vlan 22
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel lldp
l2protocol-tunnel vtp
no cdp enable
end

Seems to work the same with and without the vlan 22 commands, and/or the vlan 22 native command.