From Congestion to Stability: The Role of LAG & Load Balancing in Capacity Planning

-

 Essence:

When traffic is above 70% it’s congestion and performance degradation, need to increase capacity. To achieve this adding more links to the existing Link Aggregation Group (LAG) increases bandwidth, distributes traffic better and ensures network stability. This prevents bottlenecks, optimize resource utilization and redundancy, reduces the risk of service disruptions. Expanding LAG allows scaling without downtime, so it’s a must have for handling growing network demands and high traffic environments.


Link Aggregation in Capacity Planning 

Link Aggregation (LAG) is part of capacity planning by combining multiple physical links into one logical link to increase bandwidth, redundancy and overall network performance. This prevents congestion by distributing traffic across multiple links, ensures optimal resource utilization. In capacity planning LAG allows network engineers to scale bandwidth without additional infrastructure changes, so it’s cost effective. Also, it provides link failure resilience, as traffic can reroute through remaining active links, minimize downtime and maintain service continuity. Properly implementing and managing LAG is key to network scalability, load balancing and traffic flow in high demand environments.

To increase capacity, you need to add another port to the existing LAG. Before you add the new link make sure the physical connection is up. Use Link Layer Discovery Protocol (LLDP) to test the link to verify connectivity, detect neighboring devices and confirm link parameters. This way you won’t have any mismatch or configuration issues when you add the new port to the LAG. Once validated you can add the new port to the LAG and boom! bandwidth utilization and overall network performance and redundancy will improve.




Role of LLDP for link validation testing 

Link Layer Discovery Protocol (LLDP) is a network protocol used for link validation testing to ensure proper connectivity and configuration before you add a link to a network. LLDP runs at data link layer, where devices can exchange essential information such as port ID, VLAN configuration and system capabilities. During link validation LLDP helps to detect neighboring devices, confirm bi-directional communication and verify link parameters, reduces the risk of misconfigurations. By using LLDP for testing, network engineers can ensure the new link is fully up and running and compatible before you add it to LAG or other network configuration, increase reliability and performance.

Scenario: In Airtel MPLS Network, Network Administrator Observed that -

Mumbai-R1 <> Pune_R1 Intra MPLS tunnel link utilization increases beyond 70% and it reflects over utilization in NMS. To overcome this as a future perspective need to establish new physical link between Mumbai_R1 <> Pune_R1 and require adding in one LAG. Before that as a prerequisite, Link validation testing require using LLDP.

Note: Both Routers are Nokia IXR_7250 series here.


                     Fig:1 Architecture of Airtel MPLS Network

Here LAG :288
 
Link 1: Mumbai -R1_2/1/c33/1 <>Pune-R1_2/1/c33/1
Link 2: Mumbai-R1_2/1/c34/1<> Pune-R1_2/1/c34/1

==========================================

Mumbai-R1#

/configure port 2/1/c34/1 admin-state enable
    /configure port 2/1/c34/1 description "PHY|100G|CORE|type:MPLS-P2P|rhost:Pune_R1|rport:2/1/C34/1|lagg:288|ragg:288"
    /configure port 2/1/c34/1 ethernet { }
    /configure port 2/1/c34/1 ethernet { mtu 9192 }
    /configure port 2/1/c34/1 ethernet { lldp }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge notification true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge port-id-subtype tx-if-name }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge receive true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge transmit true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs port-desc true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-name true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-desc true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-cap true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-mgmt-address system }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-mgmt-address system admin-state enable }
    /configure port 2/1/c34/1 ethernet { network }
    /configure port 2/1/c34/1 ethernet { network egress }
    /configure port 2/1/c34/1 ethernet { network egress queue-policy "MPLS-NETWORK-QUEUE-POLICY" }


Mumbai-R1# show lag 288 port 


====================================

Pune-R1#

/configure port 2/1/c34/1 admin-state enable
/configure port 2/1/c34/1 description "PHY|100G|CORE|type:MPLS-P2P|rhost:Mumbai_R1|rport:2/1/C34/1|lagg:288|ragg:288"
    /configure port 2/1/c34/1 ethernet { }
    /configure port 2/1/c34/1 ethernet { mtu 9192 }
    /configure port 2/1/c34/1 ethernet { lldp }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge notification true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge port-id-subtype tx-if-name }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge receive true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge transmit true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs port-desc true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-name true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-desc true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-tlvs sys-cap true }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-mgmt-address system }
    /configure port 2/1/c34/1 ethernet { lldp dest-mac nearest-bridge tx-mgmt-address system admin-state enable }
    /configure port 2/1/c34/1 ethernet { network }
    /configure port 2/1/c34/1 ethernet { network egress }
    /configure port 2/1/c34/1 ethernet { network egress queue-policy "MPLS-NETWORK-QUEUE-POLICY" }

Pune-R1# show lag 288 port


*We keep on monitor for half an hour, but new port does not pick up traffic.


===================================================

By applying Hash-Weight and Adaptive Load-Balancing in LAG Traffic Distribution

Hash-Weight Load Balancing:

Hash-weight load balancing in Link Aggregation Groups (LAG) ensures traffic distribution is efficient by assigning flows to individual member links based on a hash. The hash takes into account source/destination IP addresses, MAC addresses or port numbers to distribute traffic evenly. Hash weighting allows administrators to weight each link by capacity so higher capacity links get more traffic. This prevents uneven utilization, optimizes bandwidth and avoids congestion on specific links.

==========================================

Mumbai-R1#
configure lag 288 mode hash-based
configure lag 288
port 2/1/c33/1 weight 50 
port 2/1/c34/1 weight 50
==========================================

Pune-R1#
configure lag 288 mode hash-based
configure lag 288
port 2/1/c33/1 weight 50 
port 2/1/c34/1 weight 50
==========================================



Adaptive Load-Balancing:

Adaptive load balancing adjusts traffic distribution in real-time based on link utilization and performance metrics. Static hashing can lead to imbalanced traffic due to persistent flows. Adaptive load balancing monitors link congestion, latency and errors to redistribute traffic intelligently. This method improves network efficiency by preventing bottlenecks, redundancy and optimal bandwidth utilization.

Mumbai-R1#
----------------------------------------------
       description "Mumbai-R1_lag-288<>Pune-R1_lag-288"
       port 2/1/c33/1
       port 2/1/c34/1
       adaptive-load-balancing
       lacp active administrative-key 32546
       no shutdown


Pune-R1#
----------------------------------------------
       description "Pune-R1_lag-288<>Mumbai-R1_lag-288"
       port 2/1/c33/1
       port 2/1/c34/1
       adaptive-load-balancing
       lacp active administrative-key 32546
       no shutdown
----------------------------------------------

Both hash-weight and adaptive load balancing is important for traffic distribution in LAG. Hash-weight ensures initial balancing based on link capacity, adaptive load balancing adjusts in real-time to traffic patterns, to maximize performance and network stability.
=========================================

Mumbai-R1#
===============================================================================
Distribution of allocated flows
===============================================================================
Port                        Bandwidth (Gbps) Hash-weight  Flow-share (%)
-------------------------------------------------------------------------------
2/1/c33/1                   100.000          500          50.00
2/1/c34/1                   100.000          500          50.00
-------------------------------------------------------------------------------
Total operational bandwidth: 200.000

=================================================================

Pune-R1#
===============================================================================
Distribution of allocated flows
===============================================================================
Port                        Bandwidth (Gbps) Hash-weight  Flow-share (%)
-------------------------------------------------------------------------------
2/1/c33/1                   100.000          500          50.00
2/1/c34/1                   100.000          500          50.00
-------------------------------------------------------------------------------
Total operational bandwidth: 200.000


Observations:

1. For capacity planning we have added 1 additional 1*100G link in lag-288.
2. Each port shows up and active in lag-288.
3. We have not observed in alarm, FCS error on port.
4. LACP interface is also up with administrative key.
5. But our main objective after binding port , new port should be pick up traffic then our activity become successful otherwise binding extra ports no results if new port cannot pick up traffic.
6. We monitor our end for 30 minutes, but 2nd new port does not pick up traffic.
7. we apply hash-weight on both port for load balancing traffic but no luck, hence, revert back.

Conclusion:

1. New port in lag-288 is pick up traffic when we ping from loopback interface but not in balanced way.
2. In Nokia device only one EPL service is there so, it carries traffic accordingly.


It depends on service which service configured on port. If it is point to point i.e. VPWS (pseudo wire type), Epipe and EPL then it doesn't take balanced way even though hash-weight and adaptive load balance applied but if service is point to multi point i.e. VPLS, VPRN then it can be taking balance way as per hash weight and adaptive load balancing.

Comments

Post a Comment

Popular posts from this blog

Configuring NNI Interface Policies and Container Integration in Nokia SR and Juniper AG Networks

-
Image
 Objective: - This blog aims to give a comprehensive overview of the process for integrating containerized network services in a multi-vendor setting, specifically using Nokia Service Routers (SR) and Juniper Aggregation Routers (AG). It emphasizes the importance of NNI interface policies for facilitating smooth communication between different network segments and provides guidance on configuring management interfaces and routing to optimize connectivity and traffic flow. The goal of this guide is to help network engineers implement scalable and interoperable solutions while making complex network operations easier to manage. Scenario :- In Vodafone ISP, Pune location 2 SR non-production devices need to be launched in production. Router R1 acts as a primary and Router R2 acts as a secondary back up router. Both routers aggregate traffic combines at uplink Nasik Aggregate router. This uplink is connected with IXR router at Mumbai location. To automate process flow AWS containers are...
Read more

Designing a Secure Multi-VPC Architecture with AWS Transit Gateway and IGW

-
Image
 Preface In an AWS cloud Proof of Concept (PoC), Transit Gateway (TGW) and Internet Gateway (IGW) are key to secure, scalable and efficient communication between different VPCs and external networks. Transit Gateway (TGW) is a central routing hub where multiple VPCs can communicate without the complexity of multiple VPC peering connections. It simplifies network management, scales and enforces security policies through route tables to control traffic between connected VPCs. Internet Gateway (IGW) is required for outbound and inbound internet access for resources in public subnets. It allows public facing workloads like web servers and APIs to talk to external services while keeping private subnets secure through NAT Gateways . Together TGW and IGW provide a structured and controlled networking environment, so critical workloads are secure, isolated when needed and connected efficiently in a multi-VPC architecture. POC  The proposed Proof of Concept (PoC) focuses on estab...
Read more

AI in NOC: A New Era for Capacity Planning and Network Management

-
Image
   Introduction :- Predicting router interface traffic in modern network management is critical to achieve optimal network performance, resource allocation, and proactively eliminate bottlenecks. This case study suggests using machine learning on network datasets to develop a model that predicts an actual router’s interface traffic versus an ideal router’s traffic. By evaluating historical data of network traffic and utilizing well-established machine learning API-based algorithms like Neural Networks, Decision Trees, and Ensemble Methods, this analysis reviews the formation possibilities of a strong prediction model with grand accuracy. At the end of the study, this paper reviews multiple factors and features related to the traffic in the interface such as the hour in the day, the day’s sequence in the week, the network protocol, the application, and the structure of the network. Additionally, it explores the machine learning algorithms to compare the accuracy of the ML model...
Read more