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
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
Switching and Routing - Part 2. Packet Forwarding by IP Router
June 18, 2014 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (3)

As noted in the previous post, we will explain the logic of IP packet delivery among routers.


Network Topology

Seen in the left figure below is the network topology to help you understand the packet delivery process among routers. In the middle of the figure lies a router (R1), and in the bottom, four servers are connected to the router through the ports ge1/1 ~ ge1/4, respectively. On the top of the router lies two ports (ge2/1 and ge2/2), and two routers (R2 and R3) are connected to R1 through these two ports, respectively. R2 is connected to network, and R3 is connected to network.



Now, we will see how packets are delivered from SVR1, via R1 and R2, to network. The MAC and IP addresses of the routers and servers are as follows:


   Server/Router  Port Name  MAC Address  IP Address  Description
   SVR1  Lan1  M1

 connected to R1








 connected to SVR1

 connected to SVR1





 connected to R1


1. Installing Routing Entries in RIB/FIB Using OSPF Protocol



R1 installs routing entries in the RIB/FIB by performing the following steps:
R1 exchanges OSPF LSA (routing information) with its OSPF neighbors, R2 and R3.
It saves all the routing information in the Link State Data Base (LSDB).
For OSPF, the best forwarding strategy is "to use the least-cost path". So, it calculates the shortest (least-cost) path to each destination through Shortest Path First (SPF) calculation.
It installs the results (the shortest path routing entries) in the RIB.
Then, the installed routing entries are copied to the FIB on each line card.

In case of the example in the figure above, the following routing information is installed in the RIB/FIB: (1) the destination network is directly connected to R1, and the outgoing interface (OIF) is ge1/1, and (2) the destination network is not connected to R1, and so the next hop is R2 ( and the OIF is ge2/1.

Please note that the routing entries for and are installed in the RIB/FIB according to OSPF calculation, whereas the rest routing entries are installed when the system operator configures an IP address for each interface (port) through CLI (e.g. when configuring an IP address (i.e. for interface ge1/1).

2. R1 MAC Address Learning by SVR1 (Filling in ARP Table)



Now, SVR1 wants to send an IP packet destined to (Destination IP address =
SVR1 refers to the routing table, and finds out that the destination is matched to the default route (, and thus (R1) is the gateway to use, and lan1 is the OIF.
Note: In case of usual user station (like regular PCs), the gateway IP address for the default route is also obtained when IP address is obtained through DHCP. In case of a server, however, the IP address and the gateway IP address of the default route are manually set by the administrator of each server.
SVR1 refers to its ARP table before sending a packet to the destined OIF (lan1) because it should know the MAC address of gateway in order to send the packet. Then, it finds no corresponding entry in the ARP table (ARP miss). 

Note: In Ethernet L2 (Link Layer), the MAC addresses of a sender (SVR1) and receiver (R1) should be respectively entered in the source MAC address and destination MAC address fields of the Ethernet header. 
So, SVR1 sends an ARP request packet to lan1 port to get the MAC address of gateway
R1, upon receiving the ARP request through ge1/1 port, responds to the request by sending an ARP reply packet (informing of a1, the MAC address of gateway back to SVR1.
SVR1 fills in its ARP table with the received information (saving a1 as the MAC address).


3. Sending a Packet from SVR1 to Router R1 for the First Time

SVR1, now with a1, the MAC address of gateway, sends a packet destined to through lan1 port. At this time the packet contains the following information:


[Ethernet Header] Destination MAC address = a1 (R1's MAC address), Source MAC address = m1 (SVR1's MAC address)
[IP Header] Destination IP address =, Source IP address = (SVR1's IP address)


This packet is received by R1 through ge1/1 port of the line card #1, and held in the ingress packet buffer momentarily (during FIB lookup).
Next, the packet processor, through FIB lookup (LPM: Longest Prefix Match) for the received packet, finds out the next hop and OIF are and ge2/1, respectively.
The packet processor attaches an internal header to the front of the packet, and forwards it to the switch module. This internal header may contain various information depending on each vendor's implementation. However, for easier understanding, here we assume there are only two types of information contained: (1) information about the line card/OIF where the packet is forwarded (i.e. ge2/1 here), and (2) address information of the next hop (router) where the packet is forwarded (i.e.
Now, the packet is passed through the switch module, and kept in the egress packet buffer of the line card #2.
The packet processor at the line card #2 checks the ARP table for the MAC address of the next hop
No corresponding entry in the ARP table. So, the packet processor informs the control module of the ARP miss event (reporting that there is no MAC address for
In response to the report, the control module sends an ARP request packet to ge2/1 port, and receives an ARP reply packet from R2.
The control module saves the received MAC address of (i.e. b2) in its ARP table.
Next, it forwards the saved information to the line card #2 that has informed of the ARP miss event, having the same copied to the ARP table of the card (but, not to other line cards).
The packet processor at the line card #2 now has the MAC address of the next hop (i.e. b2). So, it can simply forward the packet it previously kept in the egress packet butter to ge2/1. When forwarding the packet, the egress packet processor may either send the packet immediately according to the pre-set QoS policy (scheduling algorithm), or hold it in the egress packet buffer for a while to handle other packet(s) with a higher priority first. The packet forwarded by R1 to R2 consists of the following information.


[Ethernet Header] Destination MAC address = b2 (R2's MAC address), Source MAC address = a5 (R1's MAC address)
[IP Header] Destination IP address =, Source IP address = (SVR1's IP address)

Two things to note:
First, the main concern of the line cards is to forward packets at wire-speed. So, other exceptional events like ARP miss are taken care of by the control module.
Second, an ingress packet buffer is where packets are kept momentarily (instantaneously) while FIB lookup is performed, and hence is pretty small-sized (about hundreds of Kbytes). On the other hand, an egress packet buffer is where packets are kept according to the QoS policy when congestion occurs, and hence is pretty large-sized (several Mbytes).

4. Sending a Packet from SVR1 to Router R1 for the Second Time

Now, SVR1 sends a packet destined to 100.1.1 network for the second time.
②③④ and are the same as explained above, and so will not be discussed here again.
The packet processor at the line card #2 refers to the ARP table, and finds out the MAC address of the next hop is b2.
So, according to the QoS policy (scheduling algorithm), it takes the packet out of the egress packet buffer, and forwards to ge2/1 port. The packet forwarded by R1 to R2 consists of the following information.

[Ethernet Header] Destination MAC address = b2 (R2's MAC address), Source MAC address = a5 (R1's MAC address)
[IP Header] Destination IP address =, Source IP address = (SVR1's IP address)





Geetika 2014-08-08 13:42:35

Thanks for such a detailed explanation with example. It helped alot

csp 2015-04-04 00:48:42

Excellent illustration!

merkaba 2019-02-22 11:34:09


Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.

[HFR Private 5G: my5G]


Details >>







Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file







View All (858)
4.5G (1) 5G (102) AI (8) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) 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 (56) KT (43) Korea (20) 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 (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (11) QoS (3) RCS (4) Railway (1) 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.