3 Reasons Your Layer 2 Design Will Fail

September 26, 2015 Jim Schrader

Would you think it strange if your co-worker started walking around with a pager attached to his belt and a palm pilot in his hand? If thoughts of DeLorean and time travel crosses your mind, you are not alone. Those items are so obsolete they deserve a spot next to your collection of VHS tapes.

Layer 2 Design falls in the same category of the items mentioned above. But surprisingly, it’s one of the most widely deployed designs despite the fact that it’s also responsible for a high volume of network outages.

So what compels engineers to deploy this design in the campus design? The explanation I hear most often from newly certified engineers is that they are very adept at configuring and tuning spanning tree and all other features needed for his design.

But here are the reasons why that doesn’t matter:

1. Layer 2 design is two decades old and it was built for a different era.

The switching was fast and routing was slow twenty years ago. Back then, logical designs leveraged Layer 2 to “switch first” and route only when you had to.  This is no longer true as wire-speed routing is now the norm and has been for quite some time.

2. Layer 2 Design not as simple to deploy as you were led to believe.

Let’s consider a typical core, distribution, and access deployment with two core switches aggregating multiple distribution switches that then aggregate multiple access switches.  This is a standard hierarchical physical design.

In order to configure basic connectivity for a classic layer 2 deployment, here’s a quick overview of what needs to be done.  Note, we are only showing the bare minimum required for deployment.  An optimized design would require far more configuration of each protocol or feature.  So let’s see if we still think this is simple at the end of this exercise.

Classic_Layer2_looped

I. Configure each switch to run Rapid Per-Vlan Spanning Tree Plus (Rapid PVST+).  This will greatly improve the time it takes spanning tree to converge around a failure.

  • Core1(config)#spanning-tree mode rapid-pvst

II. Configure each of the links that connect the switches as a trunk.  This will allow us to span the VLANs across all of the switches.

  • Core1(config)#interface fastEthernet 0/1
  • Core1(config-if)#switchport trunk encapsulation dot1q
  • Core1(config-if)#switchport mode trunk

III. Configure a Switch Virtual Interface (SVI) and IP address for each VLAN on each core switch.  This will allow us to route between the individual VLANs.

  • Core1(config)#interface vlan 10
  • Core1(config-if)#ip address 10.1.1.1 255.255.255.0
  • Core1(config)#interface vlan 20
  • Core1(config-if)#ip address 20.1.1.1 255.255.255.0
  • Core2(config)#interface vlan 10
  • Core2(config-if)#ip address 10.1.1.2 255.255.255.0
  • Core1(config)#interface vlan 20
  • Core1(config-if)#ip address 20.1.1.2 255.255.255.0

IV. Configure VTP Password on each device

  • Core1(config)#vtp password cisco

V. Configure the two core switches as VTP servers in a single domain.  This will allow us to configure VLAN’s on the core switches only.

  • Core1(config)#vtp domain cisco
  • Core1(config)#vtp mode server

VI. Configure all of the distribution and access switches as VTP clients

  • Dist1(config)#vtp domain cisco
  • Dist1(config)#vtp mode client

VII. We will need to configure a First Hop Redundancy Protocol (FHRP), on each of the core switches and for each VLAN.  Here’s a basic HSRP example.

  • Core1(config)#interface vlan 10
  • Core1(config-if)#standby ip 10.1.1.3
  • Core1(config-if)#interface vlan 20
  • Core1(config-if)#standby ip 20.1.1.3
  • Core2(config)#interface vlan 10
  • Core2(config-if)#standby ip 10.1.1.3
  • Core2(config-if)#interface vlan 20
  • Core2(config-if)#standby ip 20.1.1.3

VIII. On each access switch, add the switch ports to the VLAN.

  • Access1(config)#interface range fastEthernet 0/4-24
  • Access1(config-if-range)#switchport mode access
  • Access1(config-if-range)#switchport access vlan 10
  • Access1(config)#interface range fastEthernet 0/25-48
  • Access1(config-if-range)#switchport mode access
  • Access1(config-if-range)#switchport access vlan 20

IX. We will need to configure routing on each core switch to route between the VLANs.

  • Core1(config)#ip routing
  • Core1(config)#router eigrp 1
  • Core1(config-router)#network 10.0.0.0
  • Core1(config-router)#network 20.0.0.0
  • Core2(config)#ip routing
  • Core2(config)#router eigrp 1
  • Core2(config-router)#network 10.0.0.0
  • Core2(config-router)#network 20.0.0.0

X. Finally, we will need to configure an ip helper-address for DHCP in order for packets to reach the DHCP servers.

  • Core1(config)#interface vlan 10
  • Core1(config-if)#ip helper-address 192.168.100.0
  • Core1(config)#interface vlan 20
  • Core1(config-if)#ip helper-address 192.168.100.0
  • Core2(config)#interface vlan 10
  • Core2(config-if)#ip helper-address 192.168.100.0
  • Core2(config)#interface vlan 20
  • Core2(config-if)#ip helper-address 192.168.100.0

Once we have configured all of the switches, we will be able to create VLANs on Core1 and Core2.  These VLANs will be propagated via the distributions switches to each of the access switches.

So how is this beneficial?  It allows a workstation, server and printer to be plugged into different access switches, in different corners of the campus and be able to have direct connectivity to each other.  No router hops required.  Moves, adds and changes simply require setting the proper VLAN, on the access switch port, where the end device is plugged in.

Classic_Layer2_looped VLAN

Back in the day, these were called workgroup VLANs.  For example, we could put all of the Accounting people, their servers and printers on VLAN 10.  By doing this, they will instantly see all of the resources available to them such as servers, printers and even people sharing files on their workstation.  Carry this forward for each functional group and their resources.

The problem is that all of the servers providing files or applications now reside in a data center or the cloud.  So the usefulness of this design died right along with distributed computing.

Going back to the configuration, it’s difficult to see how this design could EVER be considered to be simple.  There’s a lot of moving parts in just this basic configuration and that translates into a lot of opportunities for problems.

Notice I keep saying “basic” configuration.  That’s because this has not been tuned for the fastest convergence around failures – it’s going to take seconds to converge around a failure and in today’s world of voice and video, that’s not going to cut it.  Nor has it been tuned to optimize bandwidth utilization as only one redundant link will forward, the other will be shut down by spanning tree to prevent loops – that’s half or our bandwidth gone.

We can improve the performance of this configuration BUT… it’s going to require additional configurations which adds complexity to the deployment and more importantly, the ongoing administrative overhead of keeping these configurations in sync.  I have seen literally hundreds of customers’ networks and NOT ONE, regardless of staffing, has been able to keep this configuration optimized.  Even optimized, this configuration can’t achieve the simplicity and more importantly, the speed of convergence of other designs.

3. Layer 2 is built on top of a spanning tree, another artifact from the 90s!

This is the final nail in the coffin. When this protocol fails, it fails in what we call an “open” state.  This means that it will continue to forward traffic even if a loop develops.  This is why it fails catastrophically.

If you haven’t experienced VTP losing its database and deleting all VLANs on all switches…. you just haven’t lived.  There’s a reason why Cisco’s own guidance is to configure VTP transparent mode, which essentially disables VTP.

Clearly, using a Layer 2 Design makes no business sense. It’s that simple. Actually is the only simple thing about it. More moving parts mean more opportunities for failure. So why would you put in so much time and resources only to achieve lower performance and availability compared to alternative modern designs?

Interested to know what type of campus design is better for your business? Download our FREE ebook – Campus Design Guide.

Campus Design Guide Free Ebook Download

 

The post 3 Reasons Your Layer 2 Design Will Fail appeared first on Vology Blog.

Previous Article
5 steps to earn credit toward network upgrades
5 steps to earn credit toward network upgrades

Need to upgrade your network but don’t have the budget? Vology’s Buy Back Program might be the s...

Next Article
3 Reasons Your Layer 2 Design Will Fail
3 Reasons Your Layer 2 Design Will Fail

  Would you think it's strange if your co-worker started walking around with a pager attached t...