On a Layer 2 switch what is the purpose of configuring a default gateway

This article discusses the difference between layer 2 and layer 3 switches and the appropriate use cases for each.

Traditional switching operates at layer 2 of the OSI model, where packets are sent to a specific switch port based on destination MAC addresses. Routing operates at layer 3, where packets are sent to a specific next-hop IP address, based on destination IP address. Devices in the same layer 2 segment do not need routing to reach local peers. What is needed however is the destination MAC address which can be resolved through the Address Resolution Protocol (ARP) as illustrated below:

Here, PC A wants to send traffic to PC B at IP address 192.168.1.6.  It does not know the unique MAC address however, until it discovers it through an ARP, which is broadcasted throughout the layer 2 segment:

It then sends the packet to the appropriate destination MAC address which the switch will then forward out the correct port based on its MAC-Address-Table.

Within a layer 2 switch environment exists a broadcast domain.  Any broadcast traffic on a switch will be forwarded out all ports with the exception of the port the broadcast packet arrived on.  Broadcasts are contained in the same layer 2 segment, as they do not traverse past a layer 3 boundary.

Large layer 2 broadcast domains can be susceptible to certain unintended problems, such as broadcast storms, which have the ability to cause network outages.  Also, it may be preferable to separate certain clients into different broadcast domains for security and policy reasons.  This is when it becomes useful to configure VLANs.  A layer 2 switch can assign VLANs to specific switch ports, which in turn are in different layer 3 subnets, and therefore in different broadcast domains.  VLANs allow for greater flexibility by allowing different layer 3 networks to be sharing the same layer 2 infrastructure.  The image below shows an example of a multi-VLAN environment on a layer 2 switch:

Since VLANs exist in their own layer 3 subnet, routing will need to occur for traffic to flow in between VLANs.  This is where a layer 3 switch can be utilized.  A Layer 3 switch is basically a switch that can perform routing functions in addition to switching.  A client computer requires a default gateway for layer 3 connectivity to remote subnets.  When the computer sends traffic to another subnet, the destination MAC address in the packet will be that of the default gateway, which will then accept the packet at layer 2, and proceed to route the traffic to the appropriate destination based on its routing table.

The diagram below shows an example of a layer 3 switching routing between VLANs through its two VLAN interfaces. As before, the layer 3 device will still need to resolve the MAC address of PC B through an ARP request broadcasted out to VLAN 20.  It then rewrites the appropriate destination MAC address and forwards the packet back out the layer 2 segment:

• Just for clarity L2 switches don't know anything about TCPIP. I suspect what you are setting on the L2 switch is the management interfaces gateway for the 2960. L3 (or ISO Layer 3) is where the TCPIP protocol is communicated. L2 switches communicate on the data link layer.

  I'm a bit surprised at your ping times too. Have you tried on-switch pings with two laptop, and then start moving away from the base switch to see where the delay is introduced. Also be aware if you are pinging the switch's management interface you may get abnormally long responses. Remember the switch take data forwarding as a priority over management interface requests (i.e. pings). 

  
  Spice (1) flagReport
  Was this post helpful? thumb_up thumb_down

• Thanks for your reply George. Yes, I am setting the default gateway for the mgmt vlan SVI on the core switch.  

  Sometimes when I ping from core to one of the access switches, it misses the first 2 pings, but the others are quick.  If I keep repeating the test, the subsequent ones are fine.   Is this normal if it hasn't been pinged in a while?

• I guess my question is are you pinging the management interfaces or devices attached to each switch? The device test is what you need to compare, ignore the slow responses from the management interfaces, this is somewhat normal. 

• On an L2 switch, the default gateway performs the same function as it does on a printer or any other networked device - it tells the device where, on its own local subnet, to send frames that are destined for a different subnet. So, if you were trying to manage a switch on 192.168.1.5/24 from 10.10.10.5/20, the switch would need a gateway in the 192.168.1.0/24 range.

  The IP DEFAULT-GATEWAY statement does not "define" or "create" an IP address - it only references it. On the L3 switch, you assign that IP to the switch and it enables the switch to receive frames on that address and route them to other subnets.

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• Overclocked wrote:

  Thanks for your reply George. Yes, I am setting the default gateway for the mgmt vlan SVI on the core switch.  

  Sometimes when I ping from core to one of the access switches, it misses the first 2 pings, but the others are quick.  If I keep repeating the test, the subsequent ones are fine.   Is this normal if it hasn't been pinged in a while?

  Yes, this is normal.

  The core switch has a table of MAC addresses that tells it how to forward traffic. These addresses are cached for a fixed time (or until the table fills up), then they expire. If no traffic passes through the switch destined for a specific MAC, the switch will forget how to get there. Faced with this, the switch floods an ARP broadcast out each port and listens for a return. When the target device answers, it has re-discovered the route.

  One or two pings is typical for a switch that might be 1 or 2 hops away. Sometimes, I'll have to use ping -t for 10 or 15 seconds when accessing a device the first time in a complex network. To speed things up, for example, I'll sometimes ping my workstation from a new VM instead of the other way around. The network knows where my workstation is and can route traffic there right away. Once that's done, the switches instantly know the reverse route.

• Yes, I'm pinging the mgmt IP's.   Once I get a chance I'll do the device test and report back to close this topic up.  

  thanks!

  O.C

• This is straight forward.

  Layer 3 'Core' switch: All the SVIs (Switch Virtual Interfaces) for all the VLANs are configured on here.  These addresses become the default gateway from any device hosts in the relevant VLAN.

  Layer 2 'Access' switches:  The only layer 3 configuration they require is the management IP address (I would use loopback interfaces or a management VLAN) and the default gateway for that IP address range (which is on the Core switch).

  As for you ping times, the most important and often forgotten fact is ICMP acts like UDP, it is a connection-less based protocol, but unlike UDP will provide responses in the way of error messages (destination unreachable, fragmentation required etc.) using a ICMP types and Codes.

  As such, ICMP should never be considered as an accurate measurement of availability, ACLs could be blocking ICMP but allowing through UDP/TCP traffic, or reliability, devices such as routers and switches will drop ICMP over other more important stuff if busy (as one example).  ICMP should only be used as an indicator or availability and reliability because of this.

  The response 3/5/14 ms indicates Minimum, Average and Maximum.  If the IP address being pings is on a different subnet, packet forward occurs, this means a routing decision is made by something, this clearly has a effect upon time.  Indeed, even from a windows PCs, pings 127.0.0.1 and it's assigned network IP address can in some circumstances yield different times!

  If ping something on the same VLAN, no routing takes place, indeed, in a switched environment traffic from one device to another on the same VLAN uses MAC addresses to forward the traffic, this is why MITM ARP address spoofing attacks are so easy to do.  Personally I like the install the command 'switchport protected' on each access interface, this forces the traffic to use IP instead of MAC addresses (although limited to only that switch).

  A few things to try and improve you ping responses:

  Don't assume as your pings are 'slow', that other traffic will be.  Try using Solarwinds Response Time Viewer, this tests the response between a piece of remote hardware and software on it the same box.  It can tell you whether the software of the hardware is causing the delay.

  Check your cabling, make sure it is servicable state!

  Try setting the interfaces between devices to have fixed duplex and speed settings, every piece of traffic will need to be negotiating the speed and duplex as well as all the other things its trying to do.

  Here's a good guide fro Pings on Cisco equipment. http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/1277...

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• 2960X's with anything other than LAN-Lite IOS have Layer 3 capability. Why not use it? Enable IP routing, have an SVI for each VLAN and the rest is easy.

• Hi Mark,  I opted to go with two 3850-12XS-S all +SFP core  routers for all my routing, and 2 x 10g uplinks from my 2960x's to the core, with 2 meter twinax.   This is why I went L2 on the 2960X's.   Also keeps costs down.   

  Out of curiosity, how would SVI's on the access layer switches jive with the SVI's on the core?    I imagine the architecture would need to be completely different, but would it be better in some way?   For example, I'm thinking traffic could be routed closer to the user resulting in less latency?

  O.C

• You would need to have some routing protocol to distribute the VLANs around the environment and unless you had a specific reason for putting the SVIs on the access switches I wouldn't. The overhead of management would increase, the risk of a network failure would increase due to increased complexity of the network. Centrally managing the SVIs on one switch, and therefore all the ACLs etc. is a much better and elegant solution.

• Good - sounds like my current setup is fine then.  SVI's on the 3850's.  So, to close out this thread, I have setup a default gateway on each access switch which is the ip of the SVI on my core.  

  All looks good.

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• Multiple SVI's on the 2960X's don't really add complexity and they definitely do not need routing protocols to distribute the networks. That said if you have many dozens of networks then this might be easier although then there are things like route summarisation to think about. Or you can keep the 2960X's as just layer 2 and use the 3850's for core and distribution. My point was that there are options to consider as the 2960's have more features than perhaps many folk realise.