Comware

 View Only
Back to discussions
Expand all | Collapse all

Load-balancing algorithm with Route-Aggregation Groups

This thread has been viewed 1 times

  • 1.  Load-balancing algorithm with Route-Aggregation Groups

    Posted 4 hours ago

    Hi, 

    A customer has 2 X WAN circuits linking two Hospitals

    The WAN circuits terminate on their HPE Comware L3-CORE in either location

    At present, we have configured a /29 IP transit networks on either WAN circuit and use OSPF ECMP to load-balance traffic across the two WAN circuits

    Switchport config pasted below

    Hospital-A-CORE-SW

    <CORE-5945-STACK>display current-configuration interface Twenty-FiveGigE 1/0/43
    #
    interface Twenty-FiveGigE1/0/43
     port link-mode route
     description ## 2GB WAN-1 circuit CORE-5710-STACK 1/0/47 ##
     bandwidth 2000000
     speed 10000 
     mtu 9000
     jumboframe enable 9000
     ip address 172.27.4.17 255.255.255.248
     ospf cost 6
     ospf network-type p2p
     sflow flow collector 1
     sflow sampling-rate 2000
    #
    return
    <CORE-5945-STACK>display current-configuration interface Twenty-FiveGigE 3/0/43
    #
    interface Twenty-FiveGigE3/0/43
     port link-mode route
     description ## 2GB WAN-2 circuit CORE-5710-STACK 2/0/47 ##
     bandwidth 2000000
     speed 10000 
     mtu 9000
     jumboframe enable 9000
     ip address 172.27.4.25 255.255.255.248
     ospf cost 6
     ospf network-type p2p
     sflow flow collector 1
     sflow sampling-rate 2000
    #

    Hospital-B-CORE-SW

    <CORE-5710-STACK>display current-configuration int Ten-GigabitEthernet 1/0/47
    #
    interface Ten-GigabitEthernet1/0/47
     port link-mode route
     description ## 2GB WAN-1 CORE-5945-STACK WGE1/0/43 ##
     bandwidth 2000000
     mtu 9000
     jumboframe enable 9000
     ip address 172.27.4.22 255.255.255.248
     ospf cost 6
     ospf network-type p2p
     sflow flow collector 1
     sflow sampling-rate 2000
    #
    return
    <CORE-5710-STACK>display current-configuration int Ten-GigabitEthernet 2/0/47
    #
    interface Ten-GigabitEthernet2/0/47
     port link-mode route
     description ## 2GB WAN-2 CORE-5945-STACK WGE3/0/43 ##
     bandwidth 2000000
     mtu 9000
     jumboframe enable 9000
     ip address 172.27.4.30 255.255.255.248
     ospf cost 6
     ospf network-type p2p
     sflow flow collector 1
     sflow sampling-rate 2000
    #

    This works fine so far (2 years)

    However, the circuits are getting busier and for specific source-ip and destination-ip sessions (e.g. VxLAN tunnel between their VTEPs) , the OSPF ECMP algorithm favours using one of the WAN circuits primarily. This is because ECMP does not mean load-balancing. Based on hash algorithm it will choose the next hop. If the source and destination is always same (e.g. a VxLAN tunnel) the nexthop chosen across two WAN circuits will always be same

    We're trying to address this ECMP behaviour because the bulk of the inter-site traffic is storage replication within that VxLAN tunnel

    My idea was to bundle the two WAN circuits into a single "Route-Aggregation Group" , instead of having two separate IP transit links

    We could re-configure the 4 switchports on either end of the two 2GB WAN circuits to be part of the same "Route-Aggregation Group"  and then take advantage of improved load-balancing

    My question is about the load-balancing algorithm associated with Comware "Route-Aggregation Groups" – is it superior to the OSPF ECMP  algorithm ?

    In other words, would the VxLAN tunnel traffic between the VTEP endpoints 172.27.4.202 ßà 172.26.254.202 be more evenly shared between the two WAN circuits, using a Route-aggregation Group instead of OSPF ECMP ?

    Thanks for any advice



    -------------------------------------------


Related Content