Simplest way for tunneling layer 2 traffic?

[MatthewW98]

I am looking for some ideas for the best way to tunnel layer 2 traffic. It would need to be very inexpensive and easy to setup/manage.

Background:

I work in a hospital where the network used to be completely layer 2 with about 130 VLANs. A couple of years ago, they moved to Layer 3 at the access layer (Collapsed Core design) . However, some of the hospital equipment has a static address and could not be moved to the new subnets. So, they kept a layer 2 switch in each closet to support those devices. Now, we essentially have 2 topologies. Which is okay, but now those L2 switches are getting really old and are hard to manage.

Access switches are 9300 and 3850, the core is nexus 7k

So, I am looking for a way to move those devices to the new switches, but allow them to keep their IPs. I think we are currently leaning towards nat, but there may be issues if devices are pointing statically to those addresses.

I know VXLAN is probably the best, but the 3850s don't support it.

[Flavio Miranda]

@MatthewW98 

 GRE ?

[MatthewW98]

That's what I was originally thinking, but I think I confused myself with how it would be setup, specifically what to use as tunnel IP. If the Nexus were to receive say an ARP message, how would it know which tunnels to broadcast it to?

[Ramblin Tech]

Can you provide a diagram showing the topology, switch types, and locations of VLANs that need to be transported across the L3 network?

The Cat 3850 appears to support port-mode EoMPLS, which can tunnel L2 on a point-to-point basis:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-12/configuration_guide/mpls/b_1612_mpls_3850_cg/configuring___ethernet_over_mpls__eompls__and_pseudowire_redundancy__pwr_.html

If you have multipoint requirements, the 3850 also appears to support VPLS:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-12/configuration_guide/mpls/b_1612_mpls_3850_cg/configuring_virtual___private_lan_service__vpls__and_vpls_bgp_based_autodiscovery.html

[MatthewW98]

Here is the topology:

We have roughly 20 closets connecting to the Nexus switches in this fasion, and they would all need to transport each VLAN. I said we have 130 VLANs, but I think only about 20 are actually used.

[Ramblin Tech]

[Note: the diagram does not show direct interconnectivity between Nexus core switches, but I am assuming it exists.]

The "simplest" way to span VLANs across wiring closets? Bridge those VLANs at L2 from the closet access switches all the way across the Nexus switches. That is, do not terminate those VLANs into L3 on the access switches before transporting across an L3 Nexus core, but keep them at L2 all the way. Here, simplicity of configuration is traded-off against operational aspects of a larger, flat L2 network (lack of scaling, difficulty in troubleshooting, size of failure domain, etc).

The next simplest way? Bridge those VLANs through the access switches and then terminate them as VLAN-based attachment circuits (ACs) on the Nexus switches into an L2VPN service such as EVPN/VXLAN. The L2VPN service is contained to the Nexus core, while native L2 is contained to the access switches and their uplinks to the core.

The least simple, if simplicity is measured by the extent of an L2VPN service? Extend the L2VPN down to the wiring closet where the L2 is encapsulated by VPLS in the access switches (VPLS being supported by the Cat3850 and not EVPN/VXLAN). The Nexus core becomes an IP/MPLS transport service and the uplinks from the access switches transport only IP/MPLS, no native L2. This appears to be your option of least resistance with the decision having been made previously to have only L3 in the access layer (though I am not sure that is consistent with your diagram showing HSRP in use, which implies L2 from the access to the core).

[MatthewW98]

" The "simplest" way to span VLANs across wiring closets? Bridge those VLANs at L2 from the closet access switches all the way across the Nexus switches. That is, do not terminate those VLANs into L3 on the access switches before transporting across an L3 Nexus core, but keep them at L2 all the way. Here, simplicity of configuration is traded-off against operational aspects of a larger, flat L2 network (lack of scaling, difficulty in troubleshooting, size of failure domain, etc). "

This statement describes what we currently have. The Nexus switches are connected, just didn't add them. The Red links are L2 trunks. Currently, most medical equipment is being transported over the L2 trunks to the Nexus. L3 switches were added to the closets and things like phones, APs, printers, etc, were moved to those switches. The issues you stated are why I am looking at getting rid of those trunks/L2 links.

[Ramblin Tech · Accepted solution]

Instead of getting rid of L2 links entirely, you might consider the second option: L2 backhauling traffic from the access layer to the Nexus core over a .1Q trunk. Then, on a VLAN-by-VLAN basis, you have the option to dump the traffic into a L2VPN bridge-domain/EVI for L2 multipoint transport to another closet, terminate on an L3 subinterface, or do something else depending upon new requirements as they arise. "Services", whether QoS, security, transport, etc, would then be primarily applied at the Nexus core interfaces and would not necessarily depend on the least common denominator functionality of the various closet access switches.

[MatthewW98]

I agree with you on this as the best option as it doesn't require a re-design of a lot of things. Thanks for the input!