From Congestion to Capacity: Expanding LAG in an Airtel MPLS Network

By Admin | 01-01-2026

Abstract:

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 requires 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 becomes 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.