Layer 2 Bridging
If you make your way into the world of networking, you’re bound to come across a decision path on how you should handle network expansion. Should your default method always be to extend or stretch your layer 2 bridge domain? The root of the answer can be found when discussing the why. Let’s take a look at some of the use cases I’ve come across within enterprise network environments:
Device Requirement Device “A” needs to communicate with device “B” and those two devices are “required” to live on the same layer 2 broadcast domain. I haven’t come across any new devices or applications that fall into that spectrum, and it’s 2018. However, some enterprise organizations may still have legacy devices or poorly manufactured devices/applications with no foreseeable updates that may fall into this category.
Customer demand A customer you service in area “A” needs network services expanded to area “B.” They want their equipment to stay on the same subnet. Cough, cough, point of sales systems. I believe that modern POS systems can talk via IP across different subnets, but this can also be a possible use case that still comes up.
Data center disaster recovery or should I say “specific” DR models. I say “specific” because not all DC DR needs to be developed with an absolute layer 2 requirement extension model. Specific apps that are short-sighted will include layer 2 extension as a requirement. Someone insists that a VM pinned to a specific IP move from region “A” to region “B” and the IP needs to stay the same. What!?! Let’s think of better ways to do this, DNS, automate IP provisioning? However, this can still be a possible use case.
Ease of use Sometimes if you’re uncomfortable with routing protocols, it may seem easier to span a VLAN across the core of the network. Less IP provisioning, less ACL’s, potentially less firewall rules, and less management of those dreaded IP routing protocols. However, this is something we are in control of, so it’s OK to take time to research and learn what routing protocol would work best for your environment. Don’t let the lack of information drive your operation.
I can confirm that extending 100’s of VLAN’s through your core along with multiple instances of STP with a sprinkle of HSRP is NOT scalable. You will run into issues at some point. Others would say, “but my superior wants things done yesterday.” That’s another topic which may be worth blogging about in the future but hang in there.
You’re getting the point. There are some better ways to accomplish the listed use cases, but I understand that sometimes you may not be able to work with vendor X, customer Y, or technician Z to remove the necessity of layer 2 extension. Maybe your options are limited, but you’re a Rockstar network admin/engineer, so can we design around the “end user requirements”? If you must, you have quite a few options to extend layer 2 through the use of overlays. There will be some added complexity, but overlays may be worth considering instead of spanning layer 2 segments across the core.
Ok, so what’s this overlay stuff? Say you designed your network with proper layer 2 segmentation along with a layer 3 routing protocol. Everything is working great. Your layer 2 fault domains are isolated through the use of routing protocols, you don’t have STP running across your core, and you’re taking advantage of multipath layer 3 routing. All is wonderful in the world. You then have a “hard” requirement, maybe one listed above to extend layer 2. Do you go back and span a VLAN through your core? No, overlays to the rescue! Overlays have been around for quite some time, think GRE, Pseudo-wires, etc. Some of the latest overlays you may have heard of are VXLAN or EVPN. Basically you’re encapsulating information from one segment of your network and forwarding it across an existing layer. The information de-encapsulates at an endpoint and voila you’ve extended layer 2 across your layer 3 network. I know, easier said than done. There’s plenty of resources out there on how to setup overlay protocols, so I won’t go into the details.
Now let’s say you want to build your network from the ground up with extension services in mind. This would allow you to have a robust layer 2 transport natively built into your network. Extreme Networks has something called Fabric Connect which was an acquired technology from their Avaya network acquisition. Fabric connect is designed around shortest path bridging MAC (SPBM) as the forwarding plane and IS-IS as a control plane. You forward traffic not by IP routes, but by using an I-SID or Individual Service Identifier. You can create a layer 2 virtual service network (VSN) that’s more “circuit” based. The core of your network becomes a fabric connect mesh, and from an operational perspective, you configure services at the edge. You no longer have to segment devices to only certain parts of your network. Extreme Networks claim is that you get something like MPLS (however different) without the complexity.
Fabric connect makes me start thinking about locator/ID Separation Protocol or LISP which focuses on separating location (think IP address) from a device ID (think IP address again). If you separate location and device apart, you can now create two namespaces. In LISP, that’s the endpoint identifier (EID) and the routing locator (RLOC). What you then create is a mapping architecture similar to DNS mapping an IP to a name for determining forwarding. In fact, Cisco Campus Fabric uses LISP and VXLAN that creates another overlay solution that allows client mobility across a network.
The next time you have the opportunity to design or redesign a network, take time to study the why before you implement the how. And most importantly have fun!
Fabric connect – Extreme networks