ACL Based Load
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 ASR9K
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 ASR9K 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.
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
ACL Based Load
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 18.104.22.168 are handled
by VSM1-VM1 and 22.214.171.124 are handled by VSM1-VM2, etc.
ipv4 access-list acl1
10 permit ipv4 126.96.36.199 255.255.255.252 any nexthop1 ipv4 192.168.5.2 --> VSM1-VM1
20 permit ipv4 188.8.131.52 255.255.255.252 any nexthop1 ipv4 192.168.6.2 --> VSM1-VM2
40 permit ipv4 184.108.40.206 255.255.255.252 any nexthop1 ipv4 192.168.7.2 --> VSM2-VM1
40 permit ipv4 220.127.116.11 255.255.255.252 any nexthop1 ipv4 192.168.8.2 --> VSM2-VM2
interface TenGigE0/0/0/0 --> external physical ike int
ipv4 address 18.104.22.168 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