04-27-2025 09:11 AM - edited 04-27-2025 11:37 AM
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)
Solved! Go to Solution.
04-28-2025 07:34 AM
My understanding is "l2protocol-tunnel" without a named protocol enables all it supports, so you might replace your 3 statements with the version that supports all it supports.
So to confirm, you cannot ping between C and D switch hosts that both reside in VLAN 1?
BTW, I didn't push Q-in-Q initially, because, at least back when a 4948 switch was current, many low end switches didn't support this feature, but a 4948 wasn't considered low end. I only mentioned this because when and if you replace your 4948s, don't know whether this feature might not be supported on all current gen switches. (I suspect this limitation, then, might have been limited by lower end switch port NIC's MTU capabilities.)
04-28-2025 07:46 AM
I have a huge supply of 4948's which is why we still use them. We find the 4948 to be a better fit as an ISP because of the policing command support as we sell internet services with varying speeds to customers and police them at the customer interface. If we replace anything, as an ISP, it will likely be to switch to GPON (i.e. Nokia ISAM) which also would have used Q-in-Q.
To answer your question, yes the issue is switch C can not ping switch D on vlan 1 (but can on other vlans). CDP and VTP are working so I am happy. Would like to know why vlan 1 doesn't work, waiting on Vendor to let me know what their management vlan is. If its not vlan1 I think I will be done.
04-28-2025 02:40 PM - edited 04-28-2025 02:40 PM
I suspect if the switch model first digit is a 3 or higher it will be supported.
04-29-2025 03:21 AM
I suspect if the switch model first digit is a 3 or higher it will be supported.
Maybe, maybe not, at that time.
LAN marketed switches, like 3560/3750, possibly not.
Metro Ethernet marketed switches like the Catalyst 45xx/49xx and maybe the ME-C3750, possibly yes.
Of course the 4948 had a considerable forwarding performance edge until the 3750-E, and even then, its IOS was generally considered more stable.
04-29-2025 06:06 AM
yeah, I have a few 4948-E as well that we started using along the way. They have 10G SFP which helps a lot. I guess it also really depends on what IOS package you have installed.
04-28-2025 09:02 PM
Did a lot of testing the last few days. Pretty happy with how everything is working except for the inability for switches C&D to ping or pass traffic on vlan 1. It has to be something on the settings for the tunnel since switch's A&B have no limitations and switch C&D just will not pass VLAN 1 IP info. I can add any other vlan, set an IP and everything works fine. Not sure if anything else vlan 1 is impacted for cdp and vtp are working great. Still looking for suggestions?
04-29-2025 03:27 AM
Still looking for suggestions
Did you try just using a just single
l2protocol-tunnel
i.e., no named protocol option?
Also, have to ask, the two VLAN 1 IPs you're trying to ping between, you're sure the IPs/masks are in the same subnet?
04-29-2025 05:56 AM
YES. On my switch when I use l2protocol-tunnel by itself its creates all 3 entries.
Yes. If I plug the trunk from D into C (skipping A&B) I can ping between D&C on vlan 1 over the same trunk. When I move it to the A&B pair to the tunnel I cant..
04-29-2025 06:33 AM - edited 04-29-2025 07:11 AM
If I correctly understand your reply, that's expected/correct behavior. I.e. you should have two distinct/separate VLAN 1s. One for A&B and one for C&D.
Oops, I did misread your reply. So, ignore above.
04-29-2025 01:23 PM - edited 04-29-2025 01:24 PM
ok, if thats what its supposed to do, but I don't understand why if C&D is being passed in a tunnel why it doesn't include VLAN 1? Your implication that there is a separate vlan 1 on C&D and A&B but if I have a vlan 300 on C&D and one on A&B they are separate now. I have tested and all vlans on C&D (except vlan 1) are passed over the tunnel completely transparent and NOT visible in A&B so why not vlan 1 too?
04-29-2025 02:27 PM
I misread your earlier reply describing it (ping) works correctly when you directly interconnect C&D. Possibly you didn't see my edited version.
As to why VLAN 1 doesn't work like the other VLANs, across Q-in-Q, at the moment, have no idea.
Possibly I'll try similar in CML and see its results. If I do, I'll provide the results.
04-29-2025 03:30 PM
On you A&B trunks, do you have the interface command switchport trunk native vlan tag ?
04-29-2025 06:28 PM
On which trunks (A&B have trunks between them and with C&D)
My switch IOS, the default on each trunk is "switchport trunk native vlan tag" when I added the command there was no change but when I added "no switchport native vlan tag" I could see that command on each int I add it to. When I did this on both ends of C<->A and D<->B trunks vlan 1 would work but then NONE of the other vlans would work! It really messed up something internally because even after removing the command I could not get any vlan to work until I rebooted the switches?
04-30-2025 05:14 AM
On which trunks (A&B have trunks between them and with C&D)
I was only suggesting that for A:B trunks, because believe you need both the global and interface enabled, but didn't know what your default was (from my readings, it seems interface default might vary by platform).
When I did this on both ends of C<->A and D<->B trunks vlan 1 would work but then NONE of the other vlans would work!
Including pinging between C & D?
BTW, I spun up my CML, but my PC doesn't have the resources to spin up its virtual 9Ks.
04-30-2025 06:06 AM - edited 04-30-2025 06:07 AM
Yes, it did not impact anything on A&B, On C&D VLAN 1 could ping but no other vlan could ping anymore but I beleive CDP and VTP continued to work (not 100% sure on that, since all other vlans didn't work I reset and rebooted within a few minutes)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide