Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

Switching and Routing - Part 3. L2 (Ethernet) Switching by L3 Switch
July 11, 2014 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (3)
18
 

 

 

The previous post was about IP routing by router. This and next posts are about Ethernet switching (L2 bridging) and IP routing (IP forwarding) by L3 switch. Before we start, please take a look at the following terms:

  • IP Router: Delivers packets based on their destination IP addresses, and generally has not only Ethernet, but also various interface (port) types like SONET/SDH (POS), ATM, Serial, etc. Commonly known as L3 device (L3 = IP).
  • Ethernet Switch: Delivers Ethernet packets based on their destination MAC addresses, and has only one type of port, Ethernet. Commonly known as L2 device (L2 = Ethernet).
  • L3 Switch: Performs (1) IP forwarding (delivering packets based on destination IP address) or (2) Ethernet switching (delivering based on destination MAC address) according to the destination MAC address of a received packet. It has only one type of port, Ethernet. Commonly known as L2/L3 device or multi-layer switch (L2 = Ethernet, L3 = IP).
  • To simply put it, an L3 switch is a combination of an Ethernet switch and IP router.

 

Network Topology

 

Below is a network topology, similar to the one in the previous post, but with different configurations.

  • SVR1, SVR2 and SVR3 are connected to R1 through ge1/1, ge1/2 and ge2/1 ports, respectively. In R1's perspective, ge1/1, ge1/2 and ge2/1 ports belong to VLAN 10 (same bridge domain), and this VLAN has been assigned an IP address of 1.1.1.1/24 and MAC address of a1.
  • SVR4, SVR5 and SVR6 are connected to R1 through ge1/3, ge2/2 and ge2/3 ports, respectively. In R1's perspective, ge1/3, ge2/2 and ge2/3 ports belong to VLAN 20, and this VLAN 20 has been assigned an IP address of 2.1.1.1/24 and MAC address of a2.
  • So, SVR1 and SVR3, in the same VLAN, communicate with each other through Ethernet switching, whereas SVR1 and SVR4, in different VLANs, communicate through IP routing.
  • Cisco calls this type of interface (i.e. one port/interface supporting both switching and routing at the same time) a Switch Virtual Interface (SVI), and Juniper calls it a Routed VLAN Interface (RVI).

 

 

In the L3 switch shown in the figure above, we can see VLAN and MAC tables - which were not shown in the router illustration presented in the previous post - in both the control module and line card. These tables are used for Ethernet switching between ports within the same VLAN.

 

 

1. Delivering a Packet from SVR1 to SVR3 - Unknown MAC (Flooding)
 

 

SVR1 needs to send a packet to the destination network 1.1.1.30 (the packet is assumed to be pinged).

SVR1, through routing table lookup, finds out the destination address 1.1.1.30 is located in the same network (1.1.1.10) that SVR1  belongs to.
SVR1, now through ARP table lookup, knows the MAC address of destination address 1.1.1.30 is m3 (For easier explanation, we assume there is a matching entry in the ARP table).
SVR1 sends a packet containing the followings to the destination address 1.1.1.30:

 

[Ethernet Header] Destination MAC address = m3 (SVR3's MAC address), Source MAC address = m1 (SVR1's MAC address)
[IP Header] Destination IP address = 1.1.1.30 (SVR3's IP address), Source IP address = 1.1.1.10 (SVR1's IP address)

 

The line card #1 in R1 that received the packet through ge1/1 port momentarily keeps the packet in the ingress packet buffer.


Source MAC Learning
Now it's time to learn the source MAC address of the received packet. The packet processor in the line card #1 checks its MAC table to see if there is an entry that matches m1, the source MAC address of the received packet. In this example, there is no matching entry.
So, the packet processor informs the control module about the source MAC learning event (VLAN=10, Source MAC=m1, Port=ge1/1).
The control module then records the following in its MAC table: m1, the source MAC address, is connected to ge1/1 port, which belongs to VLAN 10 (source MAC learning)
The control module needs to forward the learned MAC address to line cards. But, as noted earlier, the learned MAC address is not needed by all the line cards, but shared by only those with the same VLAN. So, the control module checks the VLAN table. Now it finds out that ge1/1, ge1/2 and ge2/1 belong to VLAN 10, and that the line cards #1 and #2 support the VLAN. Note that entries in the VLAN table are created when VLAN values are assigned to each port through CLI.
The control module sends the MAC information (VLAN=10, Source MAC=m1, Port=ge1/1) to the line cards #1 and #2 so that the same is saved in their MAC tables (allowing for source MAC learning).


IP Routing or Ethernet Switching
Next, the control module checks the destination MAC address of the received packet to decide whether to perform IP routing (delivering through FIB lookup) or Ethernet switching (delivering through MAC table lookup).

  • If the destination MAC address is a1, the MAC address of L3 switch R1, then IP routing is performed
  • If not, Ethernet switching is performed.

In this example, Ethernet switching is performed because the destination MAC address is m3.


Ethernet Switching based on Destination MAC
Now it's time to perform Ethernet switching (packet delivery). So the packet processor at the line card #1 checks its MAC table to see if there is an entry that matches the destination MAC address of the received packet, m3. In this example, there is no matching entry.
In case of Ethernet switching, if there is no matching entry (destination MAC address) in the MAC table, received packets are flooded to all the ports - except for the one where the packets were received - in the same VLAN. So, the packet processor refers to the VLAN table, and knows it should flood the packet to ge1/2 and ge2/1, but not to ge1/1.
The packet processor in the line card #1 moves the packet kept in the ingress packet buffer to the egress packet buffer to forward it to ge1/2 port, which also is in the same line card. It also forwards the packet to the egress packet buffer in the line card #2 through the switching fabric in order to send the packet to ge2/1, which is in a different line card.
The packet is now flooded to ge1/2 and ge2/1, either immediately or a bit later according to the QoS policy, and then received by SVR2 and SVR3.

 


2. Delivering a Packet from SVR3 to SVR1 - Known MAC (Unicasting)

 

 

Upon receiving the packet, SVR2 discards it because the destination MAC address, m3, does not match its own. However, SVR3 forwards the packet to the destination address 1.1.1.10 as a response to Ping (again, we assume that SVR3 knew that the MAC address of SVR1 was m1). At this time, the packet consists of the following values:

 

[Ethernet Header] Destination MAC address = m1 (SVR1's MAC address), Source MAC address = m3 (SVR3's MAC address)
[IP Header] Destination IP address = 1.1.1.10 (SVR1's IP address), Source IP address = 1.1.1.30 (SVR3's IP address)

 

The packet processor at the line card #2 keeps the received packet in the ingress packet buffer for a while.
It checks the source MAC address of the packet, and finds out it has no matching entry in its MAC table.
So, it informs the control module about the "source MAC learning" event.
Based on the received event, the control module records the values (VLAN=10, Source MAC=m3, Port=ge2/1) in its MAC table.
It refers to the VLAN table, and finds out to which line cards the MAC information should be forwarded.
Then, it forwards the MAC information to the line cards #1 and #2 so that the same can be copied into their MAC tables.
The packet processor notices the destination MAC address is not a1, the MAC address of L3 switch R1. So, Ethernet switching should be performed.
Now, the packet processor checks its MAC table to see if there is an entry that matches m1, the destination MAC address of the received packet, and finds one. In the MAC table, m1 is mapped to ge1/1.
Accordingly, the packet processor sends the packet to the line card #1 through the switching fabric. Then, the packet processor in the line card #1 keeps it in the egress packet buffer.
The packet is now forwarded to ge1/1 (i.e. unicasted as it is sent to a single matching port in the MAC table), immediately or after a while according to the QoS policy, and then received by SVR1.


This is how SVR1 and SVR3 communicate with each other through Ethernet switching by L3 switch.


In the next post, we will discuss IP forwarding by L3 switch, i.e. packet delivery from SVR1 to SVR4 in the figure above.

 

 

csp 2016-05-22 16:30:48

Excellent way of putting illustrating the Forwarding Process. 

One q - In step 1.3 - How does SVR1 know that the MAC address of destination address 1.1.1.30 is m3? How did entry m3 get into SVR1s ARP table? 

 

Chris 2016-05-23 13:17:43

Because SVR1 and SVR3 locate at same VLAN (subnet), SVR3 will reply with its own MAC address (m3) for the ARP request from SVR1.

Please refer to the following link for the detailed ARP procedure.

https://www.netmanias.com/en/?m=view&id=blog&no=6330

amalksk 2017-09-02 14:42:35

As updated by Chris, m3 is learned during arp repy, R1 will already have the mac and vlan table updated with m3. Then why we need unknown mac flooding as described above?

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (823)
4.5G (1) 5G (89) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (55) KT (43) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (3) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password