ACL Based Load Balancing Support

With this release ACL Based Load Balancing Support is introduced in SecGW. SecGW runs as a vPC-SI instance on Virtualized Services Module (VSM) card in ASR9K chassis. Each chassis can have multiple VSM cards running separate SecGW instances (separate IPs). So it becomes important to have a single virtual IP for SecGW and a load balancing solution to distribute the load across VSMs. Also, with 4VM approach (introduced in 17.1 for performance improvement), each VSM runs 4 different SecGW instances (vPC-SI instances). This makes the load balancing solution even more valuable for the SecGW.

The solution allows us to configure a single virtual IP for all SecGW instances in a chassis. ACL Based Load Balancing feature distributes the load and packets for each tunnel are directly forwarded to the particular SecGW instance to achieve better throughput.

The following sections provide more detailed information:

ABF based Load Balancing at ASR 9000

XR already supports ABF (ACL based forwarding) at interface level. ACL needs to be applied at the interface level in INGRESS direction and it is applicable for both control and data traffic (Upstream). It allows configuration of multiple ACL rules with different priorities. These rules can be applied at the interface level to forward the packet via a specific physical interface. Please refer ASR 9000 user guide for more detail on ABF.

This rule can be used to have a source based forwarding for SecGW. Traffic from a set of peers can be forwarded to a particular SecGW instance supporting a static load balancing.

ABF based load balancing is static load balancing. Load from one peer always goes to a particular SecGW. There are chances of one SecGW getting loaded compared to others. Also there might be some impact on the overall throughput in a fully loaded chassis in future releases where single VM approach is planned with 30Gbps traffic.

Memory and Performance Impact

On Typhoon Line Card(LC) we expect 40% impact with small packets (64B) on fully loaded ports (assuming the ports running 10G traffic). But minimum impact on Tomahawk LC.

This impact is again based on number of ACLs configured. We can configure around 50K ACLs per interface. The impact will be seen if the numbers are in 1000s. If the rules are in 10s and 100s, the impact is not much. It is assumed that with 10s, there will not be any impact, and with 100s, it will be very minimal.

ACL Based Load Balancing Configuration

Use the below configuration to enable ACL Based Load Balancing.

To enable the feature configure the ACL rules under an access-list. The rules can be designed based on the deployment (peers and how the distribution should be). For e.g. below, packets from peers 1.0.0.0 are handled by VSM1-VM1 and 1.0.0.1 are handled by VSM1-VM2, etc. 


      ipv4 access-list acl1 
      10 permit ipv4 1.0.0.0 255.255.255.252 any nexthop1 ipv4 192.168.5.2 --> VSM1-VM1 
      20 permit ipv4 1.0.0.1 255.255.255.252 any nexthop1 ipv4 192.168.6.2 --> VSM1-VM2 
      40 permit ipv4 1.0.0.2 255.255.255.252 any nexthop1 ipv4 192.168.7.2 --> VSM2-VM1 
      40 permit ipv4 1.0.0.3 255.255.255.252 any nexthop1 ipv4 192.168.8.2 --> VSM2-VM2 
      ..........   
	     ! 
      interface TenGigE0/0/0/0 --> external physical ike int 
      ipv4 address 192.173.0.7 255.255.0.0 
      ipv4 access-group acl1 ingress!  
      ..........   
	     ! 
      interface TenGigE0/2/1/0 --> forge ike int for VSM1-VM1  
      ipv4 address 192.168.5.1 255.255.255.0 
      ..........   
	     ! 
      interface TenGigE0/2/4/0 --> forge ike int for VSM1-VM2  
      ipv4 address 192.168.6.1 255.255.255.0 
      ..........   
	     ! 
      interface TenGigE0/3/1/0 --> forge ike int for VSM2-VM1 
      ipv4 address 192.168.7.1 255.255.255.0 
      ..........   
	     ! 
      interface TenGigE0/3/4/0 --> forge ike int for VSM2-VM2 
      ipv4 address 192.168.8.1 255.255.255.0