ADC Training Aug23

A10 ADC
Corp SE Team
Confidential | ©A10 Networks, Inc.

ADC Overview
What is ADC?
 An ADC is a networking device that intelligently performs the task of delivering

application traffic.
 The A10 ADC will deliver traffic by means of load balancing decisions to server farms,
firewall, and cache servers.
 The A10 ADC also performs the following functions:
 Layer 7 packet manipulation.
 Networks and Application layer Security.
 SSL Off-loading
 HTTP Compression.
 RAM Caching.
 Global Server Load balancing.
 DNS caching, DNS optimization
 Transparent Cache Switching
Confidential | ©A10 Networks, Inc. 3

ADC functions
 The A10 ADC can perform advanced switching (L2 functions)

 Vlan concepts
 Support for vlan tagging and untagging.
 Support for static and dynamic Ethernet link aggregation.(static trunks & LACP)
 The A10 ADC can perform advanced routing (L3 functions)

 IP-NAT, DHCP relay.
 Static routes, RIP, OSPF, IS-IS, and BGP.

Server Load Balancing Concept
 Most ADC deployments involve the utilization of the server load balancing
features.
 The purpose of server load balancing:
 To distribute traffic across a cluster of servers.
 To increase throughput and performance.
 Minimizes response times.
 Avoids resource overload.
 Increases reliability by having server redundancy in a server cluster.

Server Load Balancing (SLB) Concept
 Consists of 3 elements
–Virtual Server(s) : VIP Service Group - Web Web
 Representative IP address for the services Application
 contains one or more service ports Service Group - DNS DNS
 Defines various advanced features Application Server
– Enhanced security
Service Group - SMTP SMTP
– Application acceleration
Application
–Service Group(s)


Service port collection
Contains back-end servers as member
VIP Web
Application
 Defines load-balancing algorithm
 Health Checks DNS
Application Server
–Server(s)
DNS
 Real (back-end) server information Application
 Rich health-check techniques

Load Balancing Algorithms
 Server Load Balancing Decisions are based on the following algorithms:

SLB Function
 Once a server load balancing decision is made, the A10 ADC will take the
following actions to forward the traffic to the correct server:
• Change the destination MAC address to that of the server (sometimes called layer 2
rewrite or layer 2 NAT)
• Change the destination IP address to that of the real server (sometimes called
destination NAT).
• Change the destination port number (if configured to do so using the port-translation
command under the virtual-port).
• Change the source IP and source port if source-nat is configured

SLB NAT
Cient IP: 10.10.10.153
 ACOS device can perform source
and destination NAT on client-VIP SLB
traffic. (1)
(4)
Src IP: 10.10.10.153
Src IP: 10.10.10.100
 By default destination NAT is Dst IP: 10.10.10.100
Dst IP: 10.10.10.153
performed for client-VIP SLB traffic.

 Before forwarding client packet to
real server, ACOS translates VIP: 10.10.10.100
destination address from VIP IP to
Real Server IP
 It reverses the translation before (2)
(3)
sending the reply to the client, the

Src IP: 20.20.20.154
Src IP: 10.10.10.153
Dst IP: 10.10.10.153
Dst IP: 20.20.20.154
source-IP is translated from real
server’s IP to VIP IP address
Server IP: 20.20.20.154

Source NAT
 SLB source NAT is disabled by default

 ACOS allows source-nat to be enabled on virtual-port. In cases where the real
server are in different subnet, source-nat ensures that reply traffic from server will
pass back through the ACOS device.
 Source NAT can be configured in the following ways:
• Defining a single pool of NAT IP addresses and binding the pool under virtual-port
• Creating a pool group with multiple NAT pools of IP addresses and binding the pool-group
under the virtual-port
• Using source-nat auto under virtual-port

Source-NAT with single NAT pool
Cient IP: 10.10.10.153
 The following commands configure the IP address pools. Each pool
contains addresses in one of the real server subnets.
ip nat pool p1 20.20.20.200 20.20.20.200 netmask /32
(1)
(4)
Src IP: 10.10.10.153
Src IP: 10.10.10.100
 The following commands binds the IP NAT pool to a virtual port on the Dst IP: 10.10.10.100
Dst IP: 10.10.10.153
VIP:
slb virtual-server vip1 10.10.10.100
port 80 tcp
source-nat pool p1
VIP: 10.10.10.100
service-group sg1-http NAT: 20.20.20.200
(3)
(2)
Src IP: 20.20.20.154
Src IP: 20.20.20.200
Dst IP: 20.20.20.200
Dst IP: 20.20.20.154
Server IP: 20.20.20.154

Source NAT with Pool-Group and Source-nat auto
 With Pool Group configuration  Source-NAT Auto configuration

• Define multiple pool groups • enable command under vport
ip nat pool p1 20.20.20.200 20.20.20.200 netmask /32 slb virtual-server vip1 10.10.10.100
ip nat pool p2 40.40.40.200 40.40.40.200 netmask /32 port 80 tcp

source-nat auto
• Create a pool-group and bind the nat pools as members
under it service-group sg1-http
ip nat pool-group nat-group

member p1 Note: Source-nat auto utilizes the physical/ve port IP address as source-IP.
We recommend using regular source-nat when the traffic rate is very high
member p2 since we will run out of ports to use with the nat IP since its using a single IP
address as source.
• Bind the pool-group under the virtual-port
slb virtual-server vip1 10.10.10.100
port 80 tcp
source-nat pool nat-group
service-group sg1-http

ACOS Architecture
ACOS Architecture Overview

ACOS Architecture
 Physical interfaces: copper, gigabit fiber, 10 gig fiber, 40 gig fiber or 100gig fiber ports
 Switching ASIC: Used for l2/l3 programming and maintaining the mac table. Receive packets and hash's
them based on the src-ip, src-port, dest-ip, dest-port as tuple to select the FPGA via Xaui
 FTA(Flexible Traffic Asic): Takes care of CPU selection based on following hash:
L2: Source-MAC-Destination-MAC
L3: Source-IP-Destination-IP
L4: Source-Port-Destination-Port hash
Fragmented packets: IP-ID
 CPU: Handles processing of everything including l4-l7 sessions, application data, cgn, natting
 SSL acceleration card: takes care of all SSL encryption/decryption. CPU is connected to SSL cards via PCIE links, for SSL
offload traffic, CPU sends traffic to SSL card for processing encryption/decryption, once done SSL card sends traffic
back to CPU. We can have a mThunderimum of 4 SSL cards
 Mgmt port: A10 supports an out of band management port which is connected via PCIE directly to the ASIC. This
makes it independent from the data path and even if the device is under attack or data plane stops working you can
still control the device via mgmt port
 Control CPU: Takes care of control functions like CLI, GUI, health checking

Shared memory
 ACOS features a shared memory architecture which sets us apart from competition. This shared memory
stores everything including session tables, buffer information, application data etc. The memory is shared
between all CPU’s and thus saves a lot of extra processing
 For competition there is a dedicated memory per CPU and each CPU is not aware of what is stored in the
other memory block, this arises the need for a dedicated CPU to communicate between different
memory blocks to consolidate information and provide to data CPU’s. This is called as inter processor
communication channel (IPC). This causes a lot of overhead communicating between different memory
blocks to consolidate information
 This shared memory architecture makes ACOS a lot faster and efficient and saves a lot of extra processing
cycles.

FTA vs Non-FTA vs Hybrid
 FTA: Contains both FPGA and Switching ASIC
• More expensive but provides best performance since hardware handles packet processing
 NON-FTA: no FPGA and no ASIC present.

• CPU takes care of FPGA functionality and kernel is used instead of switching Asic.
• Utilizes 2 CPU's and they take care of FPGA's functions of selecting the data CPU’s.
• Saves cost, FPGA very expensive since its hardware.
• Its good for enterprise level customer who do not need the high end performance model
• limitation: fpga can drop attack traffic and do some checksum verification gives much better performance since its hardware,
adds security benefits
 Hybrid: No switching ASIC, FPGA present

• Physical ports directly connected to FPGA since no ASIC layer in between.
• A group of ports are mapped to a certain FPGA so all traffic coming to these ports will go to same FPGA, so recommend using
ports from different groups so traffic is distributed to all FPGA's.
• However if only one port is used it goes to same FPGA for all traffic irrespective of its source-ip/port and dest Ip port. Since asic is
not present traffic is not distributed between different FPGA’s. So all FPGA's are not utilized which does not utilize the system to
fullest

System architecture (FTA vs Non-FTA vs Hybrid)
CPU selection
SSL cards L2: SMAC-DMAC
L3: SIP-DIP
L4 SP-DP hash
Mgmt Port Frag: IP-ID
CPU Non-FTA System:

No FTA or Switching
ASIC.
FTA is replaced by
HRX HTX HPD CPU. ASIC role is
performed by Kernel
Hybrid System:
FTA does not have
MRX MTX Switching ASIC.
XAUI Physical
interfaces are
directly
Switching connected to
ASIC FPGA
XAUI selection
PHY is done by
ASIC based
on 4 tuple
How to quickly identify key HW components
Non-FTA
Th-1030#sh hardware
 The commands below will provide most of the Thunder Series Unified Application Service Gateway TH930
information needed to identify the HW components Serial No : TH10A63214261003
CPU : Intel(R) Xeon(R) CPU
 show version: Uptime, CPU, Memory, Code 4 cores
9 stepping
Storage : Single 74G drive
 show hardware: FPGA version, SSL cards, etc Memory : Total System Memory 8130 Mbyte, Free Memory 2925 Mbyte
L2/3 ASIC : 0 device(s) present ---> No SSL card, ASIC or FPGA present
 show interface: Number of ports. Link type and IPMI : Not Present
speed Ports
Flags
: 10
: No CF
SMBIOS : Build Version: 4.6.5
Release Date: 05/17/2013
FTA model Hybrid
TH5840(config)#sh hardware TH3230S#sh hardware
Thunder Series Unified Application Service Gateway TH5840S Thunder Series Unified Application Service Gateway TH3230S
Serial No : TH58014015470002 Serial No : TH32A03015040002
CPU : Intel(R) Xeon(R) CPU CPU : Intel(R) Xeon(R) CPU
36 cores 8 cores
2 stepping 4 stepping
Storage : Single 93G drive Storage : Single 74G drive
Memory : Total System Memory 65012 Mbyte, Free Memory 45716 Mbyte Memory : Total System Memory 15413 Mbyte, Free Memory 5355 Mbyte
SSL Cards : 4 device(s) present SSL Cards : 2 device(s) present
4 Nitrox III each with 56 cores 2 Nitrox III each with 56 cores
L2/3 ASIC : 1 device(s) present -- Has all 3, SSL cards, ASIC & FPGA L2/3 ASIC : 0 device(s) present -- No ASIC present
IPMI : Present IPMI : Present
Ports : 28 PSU 0 : PFE600-NA AC
Flags : CF PSU 1 : PFE600-NA AC
SMBIOS : Build Version: 5.6.5 Ports : 8
Release Date: 03/02/2016 Flags : No CF
FPGA : 6 instance(s) present SMBIOS : Build Version: 4.6.5
Date & Time: 08042016 Release Date: 11/07/2014
FPGA : 4 instance(s) present
Date & Time: 08192016
Memory Pre-allocation
Th1030#sh memory
Total(KB) Used Free Usage
---------------------------------------------------
-
Memory: 6123096 4545948 1577148 74.2%
Why memory usage is so high on a system with empty

config and no traffic?
Because ACOS pre-allocates memory for some

commonly used function and features. This is done to:
Minimize dynamic memory allocation
Improve system performance
The allocation is based on platform (RAM size) and start-

up configuration (system-resource configuration).
Mostly, session table takes away high percentage of

pre-allocated memory. So in cases where customer
needs high memory consumption for other feature but
they are not having high concurrent sessions, we can
recommend to reduce session capacity to free up some
memory.

A10 Thunder ADC Portfolio
High Performance & High Scale ADC
Thunder ADC Hardware Appliances
10M
Thunder 7440
Thunder 6630 (100GbE)

L4 CPS
Thunder 5840
Thunder 5630 Thunder 6440
5M
Thunder 6430
Thunder 5440
Thunder 5430-11
Thunder 5330
3M
Thunder 4440
Thunder 4430
Thunder 3430
Thunder 3230
1M
Thunder 3040 All inclusive licensing
Thunder 1030S
Thunder 840
5 Gbps 30 Gbps 40 Gbps Throughput 100 Gbps 220 Gbps

Thunder ADC Hardware Appliances – SPE(Security and
Policy Engine) Models*
7.1M
Thunder 6635 SPE (100GbE)
Thunder 6435 SPE
L4 CPS
3.7M
Thunder 5435 SPE
3.1M
Thunder 4435 SPE
All inclusive licensing
40 Gbps Throughput 155 Gbps
Confidential | ©A10 Networks, Inc. * SPE (Security Policy Engine) acceleration included 23
Thunder ADC Hybrid Virtual Appliances (HVA)
40 VMs
Thunder 3530S HVA

SSL security processor
Installed VMs
8 VMs
Thunder 3030S HVA

SSL security processor
Hybrid Virtual Appliance (HVA):

 Hardware performance, virtual flexibility
 Pre-installed vThunder appliances on KVM hypervisor
 SR-IOV enabled for network and SSL acceleration
 No performance or feature licenses
35 Gbps Throughput 100 Gbps

Thunder ADC Software Appliances
Bare Metal
Bare Metal
vThunder
Bare Metal
L4 CPS
vThunder
vThunder
vThunder
vThunder (Perpetual Licensing)
 All ADC features inclusive
vThunder  VMware, KVM, Hyper-V hypervisors support
 DPDK, SR-IOV supported*
 Public could: Azure, and AWS hypervisors
vThunder
200 Mbps 1 Gbps 4 Gbps 8 Gbps 10 Gbps 20 Gbps 40 Gbps
Throughput
4 Cores 8 Cores 14 Cores
Confidential | ©A10 * Depending on hypervisor
Networks, Inc. 25
Other vThunder Appliances and Flexible Billing Options
Rent (RBM) Utility (UBM)
License per Month License per Byte
vThunder for AWS or Azure vThunder Pay-as-You-Go Licensing

 10 Mbps to 1 Gbps licensing  Elastic & adaptive
 1 click provisioning of 64-bit Amazon Machine  “Pay-as-you-Go” metering
Image (AMI)  Automated licensing
 EC2 or VPC environments  For IaaS providers only
 No feature limitations; licensed by bandwidth
 BYOL perpetual license or hourly based license

ACOS Modes of
Deployment
Deployment Scenarios
 Switch Mode or Transparent Mode

 Inline
 One Arm
 Router Mode or Gateway Mode
 Inline
 One Arm

Transparent(Switch) Inline Mode
 ACOS behaves as layer 2 switch

 ACOS is inserted directly between the (1) (4)
gateway router and real servers Router: 20.20.101.1
 Real servers and ACOS both use the Packet Flow:
router as their default gateway

Eth 1
(1) Source IP: Client IP
Thunder: 20.20.101.2 Dest IP: 20.20.101.100
VIP: 20.20.101.100
 ACOS and server are in the same Eth 3 (2) Source IP: Client IP
Dest IP: 20.20.101.50
subnet (3) Source IP: 20.20.101.50
(3) Dest IP: Client IP
(2)
 In this example Default SLB NAT is (4) Source IP: 20.20.101.100
used (ACOS replaces VIP IP in the Dest IP: Client IP
destination with server IP address in

forward traffic and replaces server IP
with VIP IP as source in reserve
direction)
Server1: 20.20.101.50 Server3: 20.20.101.52
Server2: 20.20.101.51 Server4: 20.20.101.53

Transparent Inline Mode
 In-line Topology Switch Mode

 Transparent/switch mode – limited to layer 2 functionality:
 ARP, Vlans, tagged/untagged interfaces, logical link aggregation, multi-netted environment.
 In-line Physical Topology

 Typically, clients and default-gateway are off one interface.
 Real servers are off another, separate, interface.
 Advantages
 Ease of configuration and deployment.
 Ease of troubleshooting.
 Disadvantages
 No layer 3 functionalities.
 Dependent on L3 device for routing decisions.
 Thunder processes pass through L2/L3 traffic.

Configuration: Transparent Inline Mode

Troubleshooting Commands

Routed(Gateway) Inline Mode
 ACOS/Client/Server can all be in

different subnets
(1) (4)
 ACOS would be the default gateway Router: 20.20.1.10

for servers, downstream routers Eth 1
Packet Flow:
Ve10: 20.20.1.1
 ACOS can be enabled to run
Dest IP: 20.20.1.100
VIP: 20.20.1.100
OSPF/IS-IS and also configure static Eth 3 (2) Source IP: Client IP
routes
Ve20.20.20.101.1 Dest IP: 20.20.101.50
(3) Source IP: 20.20.101.50
 If a pair of devices in VRRP are being

Dest IP: Client IP
(2) (3)
used then the downstream devices

(4) Source IP: 20.20.1.100
Dest IP: Client IP
would use the floating IP as the

default gateway.
Server1: 20.20.101.50 Server3: 20.20.101.52

Server2: 20.20.101.51 Server4: 20.20.101.53

In-line Topology Router Mode
 Router/gateway mode.
 Full support for Layer 2 functionalities: ARP, Vlans, tagged/untagged interfaces, logical link aggregation, multi-
netted environment.
 Full support for Layer 3 functionalities: IP NAT, Access-list, static routes, RIP, OSPF, IS-IS, and BGP.
 In-line Physical Topology

 Clients and default-gateway are off one interface or VE.
 Real servers are off another interface or VE.
 Advantages
 Easy to integrate into Layer 2 and Layer 3 network.
 Disadvantages
 Can easily become over complicated when many features are configured.
 Thunder processes pass through L2/L3 traffic.

Configuration: In-line Topology Router Mode
In-line topology: Verification Commands:
vlan 10
untagged ethernet 1 show interface brief
router-interface ve 10 show arp
! show mac
vlan 20 show ip route
untagged ethernet 3
show slb server
router-interface ve 20
!
show slb virtual
interface ethernet 1 show slb service-group
name "client" show slb http
!
interface ethernet 3
name "server" AX-1-2500#show interface brief
! Port Link Dupl Speed Trunk Vlan MAC IP Address IPs Name
interface ve 10 ------------------------------------------------------------------------------------
ip address 20.20.1.1 255.255.255.0 mgmt Up Full 1000 N/A N/A 001f.a001.e754 192.168.144.163/24 1
!
1 Up Full 1000 None 10 001f.a002.60a8 0.0.0.0/0 0 client
interface ve 20
ip address 20.20.101.1 255.255.255.0
2 Up Full 1000 None 1 001f.a002.60a9 0.0.0.0/0 0
! 3 Up Full 1000 None 20 001f.a002.60aa 0.0.0.0/0 0 server
ip route 0.0.0.0 /0 20.20.1.10 4 Up Full 1000 None 1 001f.a002.60ab 0.0.0.0/0 0
! 5 Down None None None 1 001f.a002.60ac 0.0.0.0/0 0
slb server web-50 20.20.101.50 6 Down None None None 1 001f.a002.60ad 0.0.0.0/0 0
port 80 tcp 7 Down None None None 1 001f.a002.60ae 0.0.0.0/0 0
slb server web-51 20.20.101.51 8 Down None None None 1 001f.a002.60af 0.0.0.0/0 0
port 80 tcp 9 Down None None None 1 001f.a002.85c8 0.0.0.0/0 0
slb server web-52 20.20.101.52 10 Down None None None 1 001f.a002.85c9 0.0.0.0/0 0
port 443 tcp
11 Down None None None 1 001f.a002.85ca 0.0.0.0/0 0
slb server web-53 20.20.101.53
port 443 tcp
12 Down None None None 1 001f.a002.85cb 0.0.0.0/0 0
! ve10 Up N/A N/A N/A 10 001f.a002.85ca 20.20.1.1/24 1
slb service-group https_server tcp ve20 Up N/A N/A N/A 20 001f.a002.85c8 20.20.101.1/24 1
member web-52:443
member web-53:443
slb service-group http_servers tcp AX-1-2500#show arp
member web-50:80 Total arp entries: 6 Age time: 300 secs
member web-51:80 IP Address MAC Address Type Age Interface Vlan
---------------------------------------------------------------------------
slb virtual-server web_servers 20.20.1.100
20.20.1.10 000c.29d2.53f8 Dynamic 212 ve10 10
port 80 tcp
name _20.20.1.100_TCP_80
20.20.101.50 000c.299c.6853 Dynamic 201 ve20 20
service-group http_servers 20.20.101.51 000c.299c.6853 Dynamic 219 ve20 20
port 443 tcp 20.20.101.52 000c.299c.6853 Dynamic 193 ve20 20
name _20.20.1.100_TCP_443 20.20.101.53 000c.299c.6853 Dynamic 59 ve20 20
service-group https_server 192.168.144.1 001f.a002.eec3 Dynamic 27 Management 1
=================

Verification Commands: In-line Topology Router Mode
AX-1-2500#show mac
Total active entries: 2 Age time: 300 secs
MAC-Address Port Type Index Vlan Age
---------------------------------------------------------
000c.29d2.53f8 1 Dynamic 866 10 130 AX-1-2500#show slb virtual
000c.299c.6853 3 Dynamic 988 20 10 Total Number of Virtual Services configured: 2
Virtual Server Name IP Current Total Request Response Peak
AX-1-2500#show ip route Service-Group Service connection connection
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP packets packets connection
O - OSPF, IA - OSPF inter area ----------------------------------------------------------------------------------------
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 *web_servers(A) 20.20.1.100 All Up
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area port 80 tcp 0 10 34 31 0
* - candidate default http_servers 80/tcp 0 1 7 4 0
Total received conn attempts on this port: 10
Gateway of last resort is 20.20.1.10 to network 0.0.0.0
port 443 tcp 0 0 0 0 0
S* 0.0.0.0/0 [1/0] via 20.20.1.10, ve 10 https_server 443/tcp 0 0 0 0 0
C 20.20.1.0/24 is directly connected, ve 10 Total received conn attempts on this port: 0
C 20.20.101.0/24 is directly connected, ve 20
AX-1-2500#show slb server Troubleshooting Commands:

Total Number of Services configured: 4
Current = Current Connections, Total = Total Connections show session
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets show slb l4
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
--------------------------------------------------------------------------------------- AX-2-2500#axdebug
web-50:80/tcp 0 1 7 4 0 Up AX-2-2500(axdebug)#
web-50: Total 0 1 7 4 0 Up AX-2-2500(axdebug)#filter 1
AX-2-2500(axdebug-filter:1)#ip 20.20.1.100 /32
web-51:80/tcp 0 0 0 0 0 Up AX-2-2500(axdebug)#capture detail save src-nat-test-1
web-51: Total 0 0 0 0 0 Up AX-2-2500(axdebug)#show axdebug file
AX-2-2500(axdebug)#show axdebug filter
web-52:443/tcp 0 5 15 15 0 Up AX-2-2500(axdebug)#show axdebug status
web-52: Total 0 5 15 15 0 Up AX-2-2500#export axdebug tcp_reset_a use-mgmt-port scp://[user@]host/
file
web-53:443/tcp 0 4 12 12 0 Up
web-53: Total 0 4 12 12 0 Up

Transparent One-armed Mode
 One-armed Topology Switch Mode
 Transparent/switch mode – limited to layer 2
functionality:
 ARP, Vlans, tagged/untagged interfaces,
Router: 20.20.101.1
logical link aggregation, multi-netted (1) (4)
environment. Thunder: 20.20.101.2
VIP: 20.20.101.203 Packet Flow:
 One-armed Physical Topology (1) Source IP: Client IP
 Clients, default-gateway, and real server are Eth3
Dest IP: 20.20.101.203
off the same interface. IP NAT Pool

vlan 20 (2) Source IP: 20.20.101.210
Dest IP: 20.20.101.50
20.20.101.210
 Source-nat is required to guarantee return
(2) (3) Source IP: 20.20.101.50
traffic is returned to Thunder. (3) Dest IP: 20.20.101.210
 From server perspective, all traffic is sourced (4) Source IP: 20.20.101.203
from source-nat ip. Dest IP: Client IP
 Advantages
 Ease of network integration, configuration and
deployment.
 Thunder does not process pass-through L2-3
traffic.
Server1: 20.20.101.50 Server3: 20.20.101.52
 Disadvantages Server2: 20.20.101.51 Server4: 20.20.101.53
 No layer 3 functionalities.
 Dependent on L3 device for routing decisions.
Configuration: Transparent One-armed Mode
Source-NAT Configuration Switched Mode: Verfication Commands:
show interface brief
======================= show ip
show arp
vlan 20
show mac
untagged ethernet 3 show slb server
! show slb virtual
ip address 20.20.101.2 255.255.255.0 show slb service-group
ip default-gateway 20.20.101.1 /24 show ip nat pool stat
! show session
ip nat pool src-nat-pool 20.20.101.210 20.20.101.210 netmask /24
======================= AX2500(config)#sh int brief
Port Link Dupl Speed Trunk Vlan MAC IP Address IPs Name
slb server web-50 20.20.101.50 ------------------------------------------------------------------------------------
mgmt Up Full 1000 N/A N/A 001f.a001.ef74 192.168.144.164/24 1
port 80 tcp
1 Disb None None None 10 001f.a004.03c8
! 2 Disb None None None 10 001f.a004.03c9
slb server web-51 20.20.101.51 3 Up Full 1000 None 10 001f.a004.03ca
port 80 tcp 4 Disb None None None 1 001f.a004.03cb
! 5 Disb None None None 1 001f.a004.03cc
slb server web-52 20.20.101.52 6 Disb None None None 1 001f.a004.03cd
port 443 tcp 7 Disb None None None 1 001f.a004.03ce
! 8 Disb None None None 1 001f.a004.03cf
slb server web-53 20.20.101.53 9 Disb None None None 1 001f.a002.8c94
port 443 tcp 10 Disb None None None 1 001f.a002.8c95
!
slb service-group https tcp
member web-52:443 AX2500#show ip
member web-53:443 System is running in Transparent Mode
! IP address: 20.20.101.2 255.255.255.0
slb service-group http tcp IP Gateway address: 20.20.101.1
member web-50:80 SMTP Server address: Not configured
member web-51:80
! AX2500#sh arp
slb virtual-server src-nat-vip-203 20.20.101.203 Total arp entries: 6 Age time: 300 secs
IP Address MAC Address Type Age Interface Vlan
port 80 tcp
---------------------------------------------------------------------------
name _20.20.101.203_TCP_80 20.20.101.1 001f.a002.60aa Dynamic 154 ethernet 3 10
source-nat pool src-nat-pool 20.20.101.50 000c.299c.6853 Dynamic 69 ethernet 3 10
service-group http 20.20.101.51 000c.299c.6853 Dynamic 185 ethernet 3 10
port 443 tcp 20.20.101.52 000c.299c.6853 Dynamic 69 ethernet 3 10
name _20.20.101.203_TCP_443 20.20.101.53 000c.299c.6853 Dynamic 69 ethernet 3 10
source-nat pool src-nat-pool 192.168.144.1 001f.a002.eec3 Dynamic 1 Management 1
service-group https

Verification Commands: One-armed Switch Mode
AX2500#show mac Troubleshooting Commands:
Total active entries: 2 Age time: 300 secs
MAC-Address Port Type Index Vlan Age
---------------------------------------------------------
AX-2-2500#axdebug
001f.a002.60aa 3 Dynamic 429 10 20 AX-2-2500(axdebug)#
000c.299c.6853 3 Dynamic 938 10 0 AX-2-2500(axdebug)#filter 1
AX-2-2500(axdebug-filter:1)#ip 20.20.101.203 /32
AX2500#show slb server AX-2-2500(axdebug)#capture detail save src-nat-test-1
Total Number of Services configured: 4
Current = Current Connections, Total = Total Connections
AX-2-2500(axdebug)#show axdebug file
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets AX-2-2500(axdebug)#show axdebug filter
Service Current Total Fwd-pkt Rev-pkt Peak-conn State AX-2-2500(axdebug)#show axdebug status
--------------------------------------------------------------------------------------- AX-2-2500#export axdebug tcp_reset_a use-mgmt-port scp://[user@]host/file
web-50:80/tcp 0 4561 36487 22805 0 Up
web-50: Total 0 4561 36487 22805 0 Up
AX2500#debug packet l3-protocol ?
web-51:80/tcp 0 4562 36495 22813 0 Up arp ARP
web-51: Total 0 4562 36495 22813 0 Up ip IP
ipv6 IPv6
web-52:443/tcp 0 0 0 0 0 Up AX2500#debug packet l4-protocol ?
web-52: Total 0 0 0 0 0 Up
web-53:443/tcp 0 0 0 0 0 Up
icmp
web-53: Total 0 0 0 0 0 Up icmpv6
tcp
AX2500#show slb virtual <src-nat-vip-203> udp
Virtual server: src-nat-vip-203(A) State: All Up IP: 20.20.101.203 AX2500#debug monitor
Port Curr-conn Total-conn Rsv-Pkt Fwd-Pkt Peak-conn
-------------------------------------------------------------------------------
AX2500#no debug packet
Virtual Port:80 / service:http / state:All Up
port 80 tcp 334 16910 84553 135272 0
Virtual Port:443 / service:https / state:All Up
port 443 tcp 0 0 0 0 0
Total Traffic 334 16910 84553 135272 0
AX2500#show ip nat pool stat

Pool Address Port Usage Total Used Total Freed Failed
-------------------------------------------------------------------------------
src_nat 20.20.101.254 325 21490 21165 0

Verification Commands
AX2500#sh session
Traffic Type Total
------------------------------------------------------
TCP Established 1
TCP Half Open 362
UDP 0
Non TCP/UDP IP sessions 0
Other 0
Reverse NAT TCP 0
Reverse NAT UDP 0
Curr Free Conn 16735861
Conn Count 267109
Conn Freed 266746
TCP SYN Half Open 0
Conn SMP Alloc 0
Conn SMP Free 0
Conn SMP Aged 0
Conn Type 0 Available 32964604
Conn SMP Type 0 Available 32833536
Prot Forward Source Forward Dest Reverse Source Reverse Dest Age Hash Flags
----------------------------------------------------------------------------------------------------------------
Tcp 20.20.1.10:20395 20.20.101.203:80 20.20.101.50:80 20.20.101.254:14880 0 1 NFe0
Tcp 20.20.1.10:20660 20.20.101.203:80 20.20.101.51:80 20.20.101.254:15145 0 1 NFe0
Tcp 20.20.1.10:20655 20.20.101.203:80 20.20.101.50:80 20.20.101.254:15140 0 1 NFe0
Tcp 20.20.1.10:20415 20.20.101.203:80 20.20.101.50:80 20.20.101.254:14900 0 1 NFe0
Tcp 20.20.1.10:20480 20.20.101.203:80 20.20.101.51:80 20.20.101.254:14965 0 1 NFe0
Tcp 20.20.1.10:20580 20.20.101.203:80 20.20.101.51:80 20.20.101.254:15065 0 1 NFe0
Tcp 20.20.1.10:20465 20.20.101.203:80 20.20.101.50:80 20.20.101.254:14950 0 1 NFe0
Tcp 20.20.1.10:20690 20.20.101.203:80 20.20.101.51:80 20.20.101.254:15175 0 1 NFe0
Tcp 20.20.1.10:20720 20.20.101.203:80 20.20.101.51:80 20.20.101.254:15205 0 1 NFe0
Tcp 20.20.1.10:20745 20.20.101.203:80 20.20.101.50:80 20.20.101.254:15230 0 1 NFe0
Tcp 20.20.1.10:20695 20.20.101.203:80 20.20.101.50:80 20.20.101.254:15180 0 1 NFe0

Routed One Arm Mode
 ACOS device is added to the network
without inserting the device directly into
the traffic path between clients and servers
 ACOS is connected to the L2 switch via a (1) (4)
Router: 1.1.1.1
single interface with separate IP interface vlan 10
tag eth3
Packet Flow:
to each real server subnet VIP: 1.1.1.100
VE 10: 1.1.1.2

 These IP interfaces are configured as VE Eth3
Dest IP: 1.1.1.100
interfaces by tagging eth 3 on different

vlan 20 (2) Source IP: Client IP
tag eth3
Dest IP: 10.20.101.50
VE 20: 10.20.101.1 (2)
vlans (3) (3) Source IP: 10.20.101.50
Dest IP: Client IP
 A default route on the ACOS routes server
reply traffic through the Layer 3 routers to
(4) Source IP: 1.1.1.100
Dest IP: Client IP
clients
 Source NAT is used for communication with
the server if server is in different subnet. A
separate pool is configured for each server Server1: 10.20.101.50 Server1: 10.20.101.52
Server2: 10.20.101.53
Server2: 10.20.101.51
subnet. Else server can point to VE as
default gateway
One-armed Router Mode
 Router/gateway mode.
 Full support for Layer 2 functionalities: ARP, Vlans, tagged/untagged interfaces, logical link aggregation, multi-
netted environment.
 Full support for Layer 3 functionalities: IP NAT, Access-list, static routes, RIP, OSPF, IS-IS, and BGP.
 One-armed Physical Topology

 Clients and default-gateway are off one interface or VE.
 Real servers may use Thunder VE as their default-gateway.
 Advantages
 Easy to integrate into Layer 2 and Layer 3 network.
 Thunder may not processes pass through L2/L3 traffic.
 Disadvantages
 May need to manipulate routes on servers and other network devices.

Direct Server Return Concept
 It is a method whereby a server in a load balancing configuration responds

directly to the client, bypassing the load balancer on the way out.
 By bypassing the load balancer, we can get better performance because now
the load balancer only has to process request traffic, dramatically cutting down
the number of packets processed.
 Specially useful for streaming media where response packets are much larger
than request packets

Layer 2 DSR
 It works by using a process known as MAT (MAC Address Translation)

 Incoming traffic comes into the Virtual IP (VIP) on the load balancer.
 Then all the load balancer does is change the destination MAC (to real server in
the pool) and sends it out to the switch which delivers the packets to the
selected real server.
 Destination IP of the traffic is unchanged (VIP IP address)
 On the real servers, VIP IP address is configured as Loopback address and bound
to the application.
 The real servers must be in the same Layer 2 domain as the load balancer.

Layer 2 DSR Packet Flow
 Client sends request to VIP

 ACOS selects real server and
Router: 3.3.3.1 replaces Destination MAC address to
server’s MAC
MAC: M1
Packet Flow:
VIP: 3.3.3.100 (1)

(1) Source IP: Client IP SMAC: M1
Dest IP: 3.3.3.100 DMAC: M2  Server replies directly to client directly
MAC: M2
(2) Source IP: Client IP SMAC: M2 using VIP IP as source-IP and uses the
(3) Dest IP: 3.3.3.100 DMAC: M4
default gateway’s MAC as
(3) Source IP: 3.3.3.100 SMAC: M4
Dest IP: Client IP DMAC: M1 destination MAC
(2)
Server1: 3.3.3.10 Server3: 3.3.3.11

MAC: M3 MAC: M4
Loopback: 3.3.3.100 Loopback: 3.3.3.100

Configuration
 Define servers and service-group  Enable health-checks for l2-dsr

slb server s3 3.3.3.10 health monitor l2dsr
port 80 tcp method tcp port 80
no health-check slb dsr-health-check-enable
slb server s4 3.3.3.11
port 80 tcp  Real Server Configuration
slb service-group sg2 tcp Server has to accept the packets with VIP as the destination IP.
Therefore, VIP must be configured as a loopback IP address on
health-check l2dsr each real server.
member s3:80 [root@no185 ~]# ip addr add 3.3.3.100/32 dev lo
member s4:80  Disable ARPS on the loopback interface.
 In order to use direct server return, the load balancer must [root@no185 ]# cd /proc/sys/net/ipv4/conf/lo/
not translate the IP address in requests, so we disable
destination-nat. [root@no185 lo]# echo 2 > arp_announce
slb virtual-server vip 3.3.3.100 [root@no185 lo]# echo 1 > arp_ignore
port 80 tcp
service-group sg2
no-dest-nat

Limitations of L2 DSR
 Port translation is not possible because port selection is done at Layer 4. A10 does
not change anything in the packet beyond Layer 2 ( MAC addresses) in L2 DSR.
 LB and all servers should be on the same L2 network segment.

Moving from L2 to L3 DSR
 Server needs to know the following:  This extra information is saved in the
-clients source IP address Differentiated Services Code Point
(DSCP) in the IP header, originally
-VIP address for which the request was known as Type of Service which has 6
made free bits.
 LB needs to do the following  The VIP IP is mapped to these 6
-tell the server behind the VIP the unused bits.
source IP address of the client  LB and server work on this mutually
-send the request to the real server IP agreed DSCP VIP mapping
and not the VIP IP
-tell server the original destination
address(VIP IP)

Layer 3 DSR
 Client sends request to the VIP.

 ACOS selects real server and sets the
Router: 5.5.5.1 DSCP bit and sends the packet out to
(1)
real server IP address.
Packet Flow:
(1) Source IP: Client IP  Server replies directly to client using
VIP: 5.5.5.101
Dest IP: 5.5.5.101
DSCP: 0x0 VIP IP as source-IP.
Dest IP: 7.7.7.101
DSCP: 0x10
(2) (3) Source IP: 5.5.5.101

Dest IP: Client IP
(3)
Server3: 7.7.7100 Server4: 7.7.7.101

Configuration
 LB needs to modify the DSCP field value on the IP header. Thunder supports this by slb virtual-server vip-dsr 5.5.5.101
configuring a port template.
port 80 tcp
slb template port dscp
service-group sg2-l3dsr
dscp 10
no-dest-nat
 Define the real servers and bind the port template under the server  Server has to accept the packets with VIP as the destination IP. Therefore, VIP must
be configured as a loopback IP address on each real server.
[root@no185 ~]# ip addr add 5.5.5.101/32 dev lo
port 80 tcp
Disable ARPS on the loopback interface.
template port dscp
[root@no185 ]# cd /proc/sys/net/ipv4/conf/lo/
port 80 tcp [root@no185 lo]# echo 2 > arp_announce
template port dscp [root@no185 lo]# echo 1 > arp_ignore
Add
 Define the health monitor iptables -t mangle -A INPUT -m dscp --dscp 10 -j DADDR --set-daddr=5.5.5.101
health monitor l3dsr where X is the dscp value and 1.2.3.4 is the loopback IP on the server.
method tcp port 80
slb dsr-health-check-enable
slb service-group sg2 tcp
health-check dscp
member s1:80
member s2:80 Confidential | ©A10 Networks, Inc. 51

L2/L3 DSR Summary
L2 DSR L3 DSR

 Client sends request to the Virtual IP.  Client sends request to the Virtual IP
 LB determines which real server to  LB sets DSCP according to known
load balance. mapping
 LB performs MAC address translation  LB changes dest IP to the real servers
 Server responds directly to the client IP
using its loopback address bypassing  Server checks DSCP bits and rewrites
the LB dest address to the VIP address
 Server responds directly to the client
with VIP address

VRRP-A High Availability
VRRP-A
 VRRP-A provides device level redundancy and session
synchronization to ensure continuity of service to clients Router
and seamless failover
Layer 2/3
 Simplifies configuration of multi-system redundancy, Aggregation
allows up to 8 devices to serve as mutual backups for IP
addresses Data Path Data Path
 VRRP-A is A10s implementation of high availability ADC 1 ADC 2

and does not interoperate with standard VRRP
heartbeat
VRRP-A
VRRP-A
 VRRP-A can provide redundancy for the following IP Device 1
Device 2
Standby
resources Active
– Virtual server IP addresses (VIPs)

– Floating IP addresses used as default gateways
– NAT Pools (Ipv4 & IPv6)
– Ipv4 static range lists and individual mappings for inside
source-nat
VRRP States: A=Active S=Standby

Configuration Components
 Device ID: Unique identifier for each

device within VRRP-A
 Set ID: Unique identifier for a set of
VRRP-A devices. All devices in the
same set must be in the same L2
domain.
 Priority: Priority is used to determine
the order in which the devices should
become active
 Heartbeat: Hello messages sent by
the active device to standby devices
to indicate the active device for the
VRID is still operating

 Vrid: It is a logical container grouping

functional elements(VIPS, NAT Pools,
Floating IP’s) together. In case of
failover the elements from that group
are picked up by the other device
taking over
 By default shared and each partition
has its own default VRID and the
numerical value for this VRID is 0

 Floating IP: This is the IP address that  Tracking Options: Determine the
provides redundancy for the default events to be tracked in order to
gateway IP address used by the trigger a failover. Vlans, interfaces,
downstream devices gateways can be tracked to trigger a
 Configure sync: to sync configuration failover.
between the VRRP-A devices. Can  VRRP interface: Define an interface to
be done via both management port be used specifically to send out the
and data port. heartbeat messages between the
 Session sync: Also called connection VRRP peers
mirroring, session synchronization
sends information about active client
sessions to the Standby Thunder
device. If a failover occurs, the client
sessions are maintained without
interruption. Use ha-conn-mirror to
enable session syncing on individual
Deployment Modes: Active-Standby Mode
Thunder1 Vlan 10 Thunder2

Ve 10.10.10.0/24
vrrp-a common vrrp-a common
device-id 1 heartbeat device-id 2
set-id 1 set-id 1
enable Vlan 30 enable
! Eth3 !
vrrp-a vrid 0 Ve 30.30.30.0/24 vrrp-a vrid 0
floating-ip 10.10.10.3 Active Vlan 20 Standby floating-ip 10.10.10.3
floating-ip 20.20.20.3 Ve 20.20.20.0/24 floating-ip 20.20.20.3
blade-parameters blade-parameters
priority 200 priority 110
! !
vrrp-a interface ethernet 3 vrrp-a interface ethernet 3
vlan 30 vlan 30
Slb virtual-server vip1 10.10.10.100 Slb virtual-server vip1 10.10.10.100

Port 80 tcp Port 80 tcp
ha-conn-mirror ha-conn-mirror
service-group sg1-http service-group sg1-http

Deployment: Active-Standby Mode
 Active Thunder device processes all the production traffic

 One vrid (default) is sufficient to implement active-standby mode
 Each vrid has a shared MAC address 021f.a000.nnnn. The 02 portion of address
indicates this is an HA virtual-MAC address instead of system MAC address (00).
The last 2 bytes (nnnn portion) of the address indicate the partition ID,
VRRP-A set ID, and VRID
 On failover, the peer device is elected as active
 Newly elected device sends gratuitous ARP’s for virtual-servers IP addresses,
floating IP address and NAT pool IP addresses to update the upstream and
downstream devices
 Devices that receive the ARP’s learn the new information and update their forwarding
table.
 New sessions are then served by the newly elected device

Deployment Modes: Active-Active Mode
Thunder1 Thunder2
vrrp-a common
device-id 1 vrrp-a common
set-id 1 device-id 2
enable set-id 1
enable
! Vlan 10 !
vrrp-a vrid 0 Ve 10.10.10.0/24 vrrp-a vrid 0
floating-ip 10.10.10.3
floating-ip 20.20.20.3 floating-ip 10.10.10.3
blade-parameters heartbeat floating-ip 20.20.20.3
priority 200 blade-parameters
vrrp-a vrid 1 Vlan 30 priority 100
floating-ip 10.10.10.4 Eth3 vrrp-a vrid 1
floating-ip 20.20.20.4 Active for VIP1 Vlan 20
Ve 30.30.30.0/24 Standby for VIP1 floating-ip 10.10.10.4
floating-ip 20.20.20.4
blade-parameters
priority 150 Standby for VIP2 Ve 20.20.20.0/24 Active for VIP2 blade-parameters
priority 210
!
vrrp-a interface ethernet 3 !
vlan 30 vrrp-a interface ethernet 3
vlan 30
Slb virtual-server vip1 10.10.10.100
Port 80 tcp Slb virtual-server vip1 10.10.10.100
ha-conn-mirror Port 80 tcp
service-group sg1-http ha-conn-mirror
Slb virtual-server vip2 10.10.10.101
vrid 1 Slb virtual-server vip2 10.10.10.101
Port 80 tcp vrid 1
ha-conn-mirror Port 80 tcp
service-group sg2-http ha-conn-mirror

Deployment: Active-Active Mode
 Both the Thunder devices process traffic on different VIPs

 Different vrids are bound to Virtual-servers which determine which virtual-server is
in active state.
 Each Vrid has its own priority and floating IP configured and is bound to the set of
components (VIP’s, NAT pools) that will reflect the active-standby status of those
components

Active device selection
 Device with the highest weight or  In case the standby device fails then
priority will become the active unit. the backup device with highest
 If multiple devices have same priority priority takes over, in case of tie the
then device with lowest device ID lowest device ID takes over.
becomes the active device
 In a set with more than 2 devices the
device with second highest priority
becomes the hot standby and
remaining devices act as backup
 If multiple secondary devices have
the same priority then the one with
the lowest device ID becomes the
hot standby

Failover Triggers
 The standby ACOS device stops  The VRRP-A priority on the active
receiving VRRP-A hello messages device is manually reduced below
from the active ACOS device. the priority on the standby device by
 Using Tracking options: The VRRP-A an administrator, and preemption is
priority on the active device is enabled.
dynamically reduced below the  The force-self-standby option is used
priority on the standby device. The on the active device by an
priority can be dynamically reduced administrator.
when a tracked default gateway,  Policy based failover defined by
data port, or VLAN goes down, a configuration templates.
tracked route is not in the data route
table or a server bound to a service
group in a VIP fails its health check.

Floating IP
 Always remains active on active

device, configured same on both
active and peer devices (or all
devices in the VRRP-A chassis)
 When a failover occurs the floating IP
moves from former active device to
the newly active device.
 To help the neighbors find out about
the MAC change ACOS sends a G-
ARP for floating IP address. The other
devices learn about the new MAC
from gratuitous ARP’s for Ipv4 or
neighbor advertisements in IPv6.

Tracking options available
 Lost link to default gateway

 Vlan inactivity
 Lost link on a trunk
 Lost data route
 Lost link or an Ethernet port

Basic Deployment example
Active device: Standby device

 Enabling VRRP (device id 1-8, set id 1-15)  Enabling VRRP:
ACOS(config)# vrrp-a common ACOS(config)# vrrp-a common
ACOS(config-common)# device-id 1 ACOS(config-common)# device-id 2
ACOS(config-common)# set-id 10 ACOS(config-common)# set-id 10
ACOS(config-common)# enable ACOS(config-common)# enable
ACOS(config-common)# preemption delay 100 ACOS(config-common)# preemption delay 100
ACOS-Active(config-common)# exit  prompt updated to refect status ACOS-Standby(config-common)# exit  prompt updated to reflect status
 Device Vrids and parameters  Device Vrids and parameters:

ACOS-Active(config)# vrrp-a vrid 13 ACOS-Active(config)# vrrp-a vrid 13
ACOS-Active(config-vrid:13)# floating-ip 192.168.9.9 ACOS-Active(config-vrid:13)# floating-ip 192.168.9.9
ACOS-Active(config-vrid:13)#blade-parameters ACOS-Active(config-vrid:13)#blade-parameters
ACOS-Active(config-vrid:13-blade-parameters)#priority 200 ACOS-Active(config-vrid:13-blade-parameters)#priority 150
ACOS-Active(config-vrid:13-blade-parameters)#tracking-options ACOS-Active(config-vrid:13-blade-parameters)#tracking-options
ACOS-Active(config-vrid:13-blade-parameters-trac...)#interface Ethernet 4 priority-cost 100 ACOS-Active(config-vrid:13-blade-parameters-trac...)#interface Ethernet 4 priority-cost 100
 Define vrrp interface to send hello messages  Define vrrp interface to send hello messages
ACOS-Active(config)#vrrp-a interface ethernet 2 ACOS-Active(config)#vrrp-a interface ethernet 2
ACOS-Active(config-ethernet:2)#vlan 100 ACOS-Active(config-ethernet:2)#vlan 100
 Define the preffered session sync port for session syncing  Define the preffered session sync port for session syncing
ACOS-Active(config)#vrrp-a preferred-session-sync-port ethernet 3 vlan 200 Confidential |ACOS-Active(config)#vrrp-a
©A10 Networks, Inc. preferred-session-sync-port ethernet 3 vlan 200 76
Configuration Contd.
 Manually put the active device to standby mode

ACOS(config)# vrrp-a force-self-standby vrid 2 enable
 To place VRID 2 in a self-standby state even after a restart or reload, use the following command:
ACOS(config)# vrrp-a force-self-standby-persistent vrid 2
 To place all VRIDs in partition (partA) in self-standby state even after a restart or reload, execute the following command in partition
“partA:”
ACOS[partA](config)# vrrp-a force-self-standby
 Sync configuration from active to standby device
ACOS1(config)# configure sync all partition shared 192.168.216.202
ACOS1(config)# show config-sync
Partition Name Sync Status for running-config and startup-config
------------------------------------------------------------------------------------
shared (running-config) sync to ip 192.168.216.202 at 20:32:05 IST Wed May 18 2016
shared (startup-config) sync to ip 192.168.216.202 at 20:32:27 IST Wed May 18 2016

Viewing VRRP information
 On active:  On Standby
vThunder_150-Active(config)#show vrrp-a vThunder_151-Standby(config)#show vrrp-a
vrid 0 vrid 0
Unit State Weight Priority Unit State Weight Priority
1 (Local) Active 65534 200 2 (Local) Standby 65534 150 *
became Active at: Apr 11 17:07:14 2017 became Standby at: Apr 11 17:07:06 2017
for 0 Day, 0 Hour,20 min for 0 Day, 0 Hour,20 min
2 (Peer) Standby 65534 150 * 1 (Peer) Active 65534 200
vrid that is running: 0 vrid that is running: 0

VRRP verification commands
 #show vrrp-a
 #show run vrrp-a
 #show vrrp-a detail
 #show vrrp-a statistics
 #show vrrp-a mac
VRRP-A vrid MACs
0 021f.a000.0001

Notes
 Inline mode is only supported with single  Priority is recalculated for each vrid
Vrid group every few seconds.
 By default VRRP-A uses IP multicast  To prevent unnecessary failover
address(224.0.0.210) as destination for configure track event delay.
VRRP-A heartbeat messages.  Preemption enabled by default, which
 Total of 512 VRIDS can be configured means any manual change in the
system-wide, 32 on shared(numbered 0- priority will trigger a failover in 3 secs
31) and 8 on each L3V  Configure preemption delay to allow
partition(numbered 0-7) enough time for the session
 The virtual MAC assigned for each VRID synchronization before failover happens.
is numbered as follows Default is 6 seconds.
021f.a000.nnnn  Force self standby if applied to shared
The last 2 bytes (nnnn portion) of the applies to all vrids on all partitions, if
applied in private partition only applies
address indicate the partition ID, VRRP-A
set ID, and VRID to that partitions in that vrid

Notes
 Session sync happens only between  Priorities are defined under vrid config
active and standby device(hot and can be changed under vrids.
standby) Weights can only be changed using
 Session sync applies to L4 sessions. the policy template.
Does not apply to DNS, Natted ICMP  Preemption cannot be disabled for
sessions or to static NAT sessions. weights it is enabled by default.
 If no interface is defined as VRRP
interface then by default interface
which can reach the other device is
used for VRRP hello messages.
 If a interface is explicitly configured
for VRRP then all hello messages for
shared and L3V are sent on this
interface for all vrids. This operation
can only be prepared in the shared
partition Confidential | ©A10 Networks, Inc. 81
HTTP Load Balancing
HTTP load balancing and features
 HTTP load balancing manages HTTP traffic across a Web server farm.
 ACOS supports the following services types for HTTP virtual-port:
 HTTP – Complete TCP stack. Use this service type if you plan to customize any
templates. For example, if you plan to use SSL (HTTPS load balancing or SSL
offload), or customize the HTTP template to change information in the HTTP
headers of server replies, use the HTTP service type. Also use this service type for
stream-based applications such as RAM Caching and compression.
 Fast-HTTP – Streamlined hybrid stack for high performance. If you do not plan to
offload SSL or customize any templates, use Fast-HTTP.

HTTP Template
 HTTP templates provide many SLB options. Some options control selection of real
servers or service groups, while other options modify HTTP header information or
enhance website performance.
 HTTP templates can be used with the following service (virtual port) types:
• HTTP
• HTTPS
• Fast-HTTP (does not support all options under the template)

HTTP Template options
Options for Server and Service Group Selection Performance Enhancing Options
 URL hash switching – Selects a real server based on a hash  HTTP Packet Flow Modes – ACOS devices define two
value calculated from part of the URL string. HTTP/HTTPS proxy packet flow modes that specify the device
method of managing High-speed HTTP Content Replacement
 URL / host switching – Selects a service group based on the – Allows quick configuration of content replacement in HTTP
URL path or domain in the client’s GET request. replies from load-balanced servers.
 Failover URL – If the URL in GET request cannot be reached  Content Compression – You can configure the ACOS device
due to server unavailability, the ACOS device sends a 302 to offload content compression from real servers.
Redirect to the client.
Options that Modify HTTP Requests
 5xx retry and reassignment – Retries a server that replies to a
request with a 5xx status code instead of sending the status  Client IP insertion – Inserts the client’s IP address into GET
code to the client, and reassigns the request to another requests before sending the requests to a real server. The
server if the first server continues to reply with a 5xx status address is added as a value to the X-ClientIP field by default.
code.
 Header insertion / erasure – Inserts a field:value pair into
 Strict transaction switching – Performs server selection for requests or responses, or deletes a header.
each request within a client-server session, rather than
performing server-selection once per session. This option Options that Modify Server Replies
provides a simple method to force rebalancing of server  Redirect rewrite – Modifies 302 Redirect messages from real
selection. servers before sending the redirect messages to clients. This
 Non-HTTP bypass – Redirects non-HTTP traffic to a specific option can convert HTTP URLs into HTTPS URLs, and can
service group. This feature helps prevent non-HTTP traffic from modify the domain or URL path in the redirect message.
being dropped by the ACOS device.

Configuration
 URL-switching to a service-group:  View the detailed counters for http

ACOS(config)# slb template http urlswitch vThunder_150-Active(config)#show slb http-proxy debug
ACOS(config-http)# url-switching starts-with /abc service-group sg-abc
URL switching 0 11 11
ACOS(config-http)# url-switching starts-with /123 service-group sg-123
URL switching (succ) 0 11 11
ACOS(config)#slb virtual-server vip1-http 10.10.10.100 Header insert 0 42 42

ACOS(config-slb vserver)# port 80 http Insert client IP 0 21 21
ACOS(config-slb vserver-vport)# template http urlswitch
ACOS(config-slb vserver-vport)# service-group sg1-http
 Insert client IP:

ACOS(config)# slb template http insert-ip
ACOS(config-http)# insert-client-ip X-forwarded-For
ACOS(config)#slb virtual-server vip2-http 10.10.10.101
ACOS(config-slb vserver)# port 80 http
ACOS(config-slb vserver-vport)# template http insert-ip
ACOS(config-slb vserver-vport)# service-group sg1-http

Configuration Contd.
 Using URL / Host Switching along with Cookie Persistence:  The following command configures an HTTP template that
ACOS supports use of URL / host switching and cookie inserts “Cookie: c=3” into every HTTP request. If the request
persistence in the same SLB configuration. However, to already contains “Cookie” headers, the first header is
enable this support, you must enable the match-type service- replaced.
group option in the cookie persistence template.
ACOS(config)# slb template http replace-cookie
ACOS(config)# slb template persist cookie persist-cookie-sg
ACOS(config-HTTP template)# request-header-insert "Cookie: c=3"
ACOS(config-cookie persist)# name SGCookie
ACOS(config-cookie persist)# match-type service-group
ACOS(config)# slb virtual-server vs1 1.1.1.1
ACOS(config-slb vserver-vport)# template http urlswitch
ACOS(config-slb vserver-vport)# service-group sg-abc
ACOS(config-slb vserver-vport)# template persist-cookie-sg
 The following command configures replacement of

“Welcome to Company X” with “Greetings from Company
Y!”:
ACOS(config)# slb template http http1
ACOS(config-http)# response-content-replace "Welcome to Company X" "Greetings

from Company Y!“

Debugging HTTP
 Useful commands:
• Show slb http-proxy
• Show slb http-proxy detail
• Show slb http-proxy debug

Debug packet command & output
ACOS#debug pack l3 ip 10.10.10.105 c 0

ACOS#debug http-proxy
ACOS#debug mon

RAM Caching
What is RAM Caching
 Ram Cache is a high performance in-memory Web cache, it can store variety of
static and dynamic content.
 Its a feature that allows HTTP responses to be cached (temporarily stored) on the
A10 device.
 The A10 device stores these HTTP responses in memory and serves it to clients
directly from the cache, when requested.

Why use RAM Caching
 Reduce number of connections and transactions to backend servers, thus
reducing the load to those servers.
 Improves response time because content does not need to be fetched from the
backend server and delivered directly to the client from the RAM.
 It reduces latency and computation costs on servers by caching dynamic pages
and drastically improves the page download time and bandwidth utilization.
HTTP/HTTPS HTTP/HTTPS
requests requests
HTTP/HTTPS
responses
HTTP/HTTPS RAM Caching
responses

Cacheability Behavior of A10 RAM Cache
 Only responses for HTTP GET requests are cached.

 Thunder considers the follow HTTP response codes to be cache able:
–200 OK
–203 Non-Authoritative Response
–300 Multiple Choices
–301 Moved Permanently
–302 Found
–410 Gone

Cacheability Behavior of A10 RAM Cache
 If HTTP GET request contains any of the following headers, the response is not cached.
– “Authorization”
– “Proxy-Authorization”
– “If-Match”
– “If-Unmodified-Since”
 If HTTP response contains any of the following headers, the response is not cached.
– “Pragma”
– “Cache-Control”
 No-Cache
 No-Store
 Private
– “Set-Cookie”

“Age” and “Via” Headers in Cached Responses
 By default, the A10 inserts the “Age” and “Via” headers into responses served from the
cache.
 “Age” header specifies how long the cached response has been in the cache, in
seconds.
 “Via” header provides a little bit of information about the A10. The value of this header
has the following format:
– “A10-CACHE-<software-version(major.minor)>: <last-octet-of-VIP-address>
 You can disable the insertions of these headers using the “disable-insert-age” and
“disable-insert-via” options under the cache template.
HTTP/1.1 200 OK
Server: Thunder-3200
Date: Thu, 04 Mar 2010 20:46:23 GMT
Content-Type: text/plain
Content-Length: 4096
Last-Modified: Fri, 29 Jan 2010 00:37:46 GMT
Age: 230
Via: A10-CACHE-4.1:130

RAM Caching Rules
 When Processing the Request:
• If a cache policy is configured, ACOS checks if the URI in the request matches
any of the URIs configured for the cache policy. If there is a match, the configured
action (invalidate, cache, nocache) is remembered for that request.
• If there is no URI match, ACOS checks to see if default-policy-nocache is
configured; if it is configured, the request is marked as not cacheable.
 When Processing the Response to a Request Received from the Server:
• ACOS checks to see if response should be cached based on what was
determined during the request processing.
• If the response is cacheable, ACOS ignore the Cache-Control from server
response.

Dynamic Caching (Cache Policies)
 When no RAM caching policies are configured (default), the Thunder caches
everything that meets the requirements of the cache template as long as the
content is cacheable.
 Thunder has the option to configure policies, which provides more granular
control over what is and isn’t cache.
 Policies also provide you the ability to invalidate entries that are currently in the
cache, forcing the Thunder to re-fetch content from the real server.

RAM Caching – Dynamic Objects
 Allows the Thunder to cache non-static objects

 Need to understand application behavior to determine if an object can be
cached
–What is to be cached?
–How long is the cached content valid?
–What is the trigger that would cause the response to change?
 Parameterized requests
–The URL matches a specific pattern
–Specific query parameters are present
–Specific cookies in the request are present
–Specific HTTP headers in the request are present

RAM Caching – Dynamic Objects Policies
 Caching rules determine what is cacheable and what is not

 Caching policies can be used to override/augment standard HTTP/S behavior
 Policies are specified as follows:
–policy <condition> <action>
–Where: <condition> is of the form URI <pattern>, <action> is cache <seconds>, no-cache, or
invalidate <entry>
 Policies are evaluated in the order they are specified
 Action in the first policy that matches will be applied

RAM Caching – Dynamic Objects – Example
 You have a Web application with the following URLs and actions
–http://x.y.com/list Lists all items from database
http://x.y.com/add?a=p1&b=p2 Adds item to database
http://x.y.com/del?c=p3 Deletes item from database
http://x.y.com/private?user=u1 Private info for user
 The “list” URI gets a lot of hits. It makes sense to cache that URI while it remains up
to date. However, when the user does an add/delete operation, or one of the
other URIs arrives, the database would change and the cached list needs to be
refreshed

Configuration
ACOS(config)# slb template cache ram-cache Bind the template to virtual-server:
ACOS(config-ram caching)# policy uri /list cache 3000 ACOS(config)# slb virtual-server cached-vip 10.10.10.101
ACOS(config-ram caching)# policy uri /private nocache ACOS(config-slb vserver)# port 80 http
ACOS(config-ram caching)# policy uri /add invalidate /list ACOS(config-slb vserver-vport)# service-group cached-group
ACOS(config-ram caching)# policy uri /del invalidate /list ACOS(config-slb vserver-vport)# template cache ram-cache
The policy that matches on “/list” caches content for 50 minutes. The
policy that matches on “/private” does not cache content. The policies
that match on “/add” and “/del” invalidate the cached “/list” content.
Configuration To Flush Specific Cache Entries
If you need to flush specific entries from the RAM cache, you can do so
using an invalidate policy. Here is an example:
ACOS(config)# slb template cache ram-cache
ACOS(config-ram caching)# policy uri /story cache 3600
ACOS(config-ram caching)# policy uri /flush invalidate /story
This policy is configured to flush (invalidate) all cached entries that have
“/story” in the URI. The policy is activated when a request is received with
the URI “/flush”.

Viewing RAM Cache Entries
 #show slb cache <vip-name> <port-number>

Viewing RAM cache counters
vThunder_150-Active(config)#show slb cache
Total Responses (from cache)
--------------------------------------------------------------- - 304 Not Modified 0
Cache Hits 1 (100.0%) - 200 OK - No Comp 1
Cache Misses 0 - 200 OK - Gzip 0
Memory Used 2112 - 200 OK - Deflate 0
Bytes Served 445 - Other 0
Requests Entries
- Total Requests 1 - Cached 1
- Cacheable Requests 1 - Replaced 0
- No-cache Requests 0 - Aged Out 0
- IMS Requests 0 - Cleaned 0
Responses (from server) - Create failures 0
- 304 Not Modified 0 Revalidation
- 200 OK - Cont Len 0 - Successes 0
- 200 OK - Chnk Enc 0 - Failures 0
- 200 OK - Other 0 Policies
- Not cacheable 0 - URI nocache 0
- URI cache 1
Viewing Sessions
 #show session
 Notice that if content is served from the cache, you will see * in the “Reverse
Source” and “Reverse Dest” fields.

Debug Packet Output
 #debug cache
th1030#debug cache
th1030#debug monitor
Wait for debug output, enter <ctrl c> to exit
[CACHE]
HTTP Request: GET /images1.jpg HTTP/1.1
[CACHE] ---------------- Request Headers ----------------

[CACHE] User-Agent: curl/7.18.1 (i386-redhat-linux-gnu) libcurl/7.18.1 NSS/3.12 Beta 3 zlib/1.2.3 libidn/0.6.14
[CACHE] Accept: */*
[CACHE] Host: www.couyon.net
[CACHE] -------------------------------------------------
[CACHE] accept_enc = 0

Debug Packet Output
[CACHE] CACHE] ------- Response Headers written to cache -------
HTTP Response: HTTP/1.1 200 OK [CACHE] Date: Thu, 23 Aug 2012 21:31:06 GMT
[CACHE] Server: Apache
[CACHE] --------------- Response Headers ---------------- [CACHE] Keep-Alive: timeout=30, mThunder=195
[CACHE] Date: Thu, 23 Aug 2012 21:31:06 GMT [CACHE] Content-Type: text/html; charset=iso-8859-1
[CACHE] Server: Apache [CACHE] Content-Length: 672
[CACHE] Keep-Alive: timeout=30, mThunder=195 [CACHE] Content-Type: text/html; charset=UTF-8
[CACHE] Connection: Keep-Alive [CACHE] Age: 0
[CACHE] Content-Type: text/html; charset=iso-8859-1 [CACHE] Via: Thunder-CACHE-2.6:52
[CACHE] Content-Length: 672 [CACHE] -------------------------------------------------
[CACHE] Content-Type: text/html; charset=UTF-8 [CACHE] Cache miss. Creating entry to store response...
[CACHE] ------------------------------------------------- [CACHE] Header offset=17; Payload offset=250
[CACHE] Response has Content-Length header [CACHE] Cache entry 0x93a55410: saved 250 bytes...
[CACHE] Request cacheable: cache enabled via aFleX [CACHE] Cache entry 0x93a55410: saved 672 bytes...
[CACHE] Response code 200: Cacheable [CACHE] Cache entry 0x93a55410: saved response 922 bytes total.
[CACHE] Headers: 231 bytes, Payload: 672 bytes, Total: 0 bytes [CACHE] Successfully saved response (922 bytes) in cache

Compression
Compression
 Compresses HTTP/HTTPS objects

 Uses less bandwidth and provides faster client download time and offloads the
servers from doing the compression
 Thunder ADC HTTP compression
–Compresses objects sent to the clients
Note: By default, "text" (such as html/css/js) and "application" (such as doc/xls/ppt/pdf) are
compressed
–If HTTP compression is enabled, Thunder ADC transparently offloads this task from servers
HTTP/HTTPS
HTTP/HTTPS
HTTP Compression

How Compression Works
 Policies can be defined to compress

additional content from server or
exclude certain URI’s
 ACOS supports compression level 1-9
(default:1)
 When accept-encoding header is
enabled on the client, ACOS removes
this field from the request before sending
it to the server and once the response is
received ACOS compresses it and sends
it to the client
 Hardware based compression is also
available with a compression module.
HW compression is disabled by default,
once enabled it uses the settings from
the HTTP template except the
compression level.
Configuration
 Configure HTTP compression template  Apply template to the virtual service port
ACOS(config)# slb template http http-compress slb virtual-server VIP-HTTP 10.10.10.100
ACOS(config-HTTP template)# compression enable port 80 http
ACOS(config-HTTP template)# compression level 5 service-group SG-HTTP
ACOS(config-HTTP template)# compression content-type image template http http-compress
ACOS(config-HTTP template)# compression exclude-content-type
application/zip
 Configure a real server and a service group

slb server s1 192.168.19.48
port 80 tcp
!
slb service-group SG-HTTP tcp
member s1 80

Viewing Compressed entries
ACOS#show slb compression vip5-compress

Virtual Server Name Port Ratio(%) Before/After Data Saved
---------------------------------------------------------------------------------
vip5-compress 80 0.00 0.00B/0.00B 0.00B
---------------------------------------------------------------------------------
Total/Avg 0.00 0.00B/0.00B 0.00B

SSL Acceleration
Brief introduction to SSL/TLS
 A session layer protocol used for providing encryption, authentication and
integrity.
 Mostly used with HTTP, but can be technically used with any application
protocol which uses reliable transport layer protocol (i.e. TCP)
 SSL is an obsolete term and TLS is the current standard, but the terms are used
interchangeably. TLS 1.2 is the most popular version currently
Application
Application
SSL / TLS
TCP TCP
Network Network
Data Data

HTTPS
 Versions supported
 SSL v3.0
 TLS v1.0 (default)
 TLS v1.1
 TLSv1.2

TLS/SSL Connection
TCP SYN/SYN+ACK/ACK (TCP Port 443)
(1)Client Hello: SSL Version, Ciphers Supported, Session ID, session specific data
(2)Server Hello: SSL Version, Cipher Settings, assigned Session ID, session specific Data
Server Certificate (Public Key, Authentication Signature) Client Certificate Request (optional)
(3)Verify Server Certificate (Eg. Common name, date, issuer)
Create a pre-master secret for the session depending on the cipher selected and encrypt it with servers public key
(4) Client Key Exchange: Send premaster secret + client Certificate if requested
Server uses its private key to decrypt the pre-master secret, and compute a shared secret, verify client certificate
(Generate sessions keys which are used to encrypt and decrypt information exchanged during SSL session
(8)Exchange Messages with the shared secret key

SSL Handshake
 1. The handshake begins when a client connects to an SSL-enabled server, requests a secure connection, and
presents a list of supported ciphers and versions.
 2. From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client
of the decision. Additionally, the server sends back its identification in the form of a digital certificate. The
certificate usually contains the server name, the trusted certificate authority (CA), and the server’s public
encryption key.
 3. The client verifies that the certificate is valid and that a Certificate Authority (CA) listed in the client’s list of
trusted CAs issued it. These CA certificates are typically locally configured.
 4. If it determines that the certificate is valid, the client generates a master secret, encrypts it with the server’s
public key, and sends the result to the server. When the server receives the master secret, it decrypts it with its
private key. Only the server can decrypt it using its private key.
 5. The client and server then convert the master secret to a set of symmetric keys called a keyring or the session
keys. These symmetric keys are common keys that the server and browser can use to encrypt and decrypt
data. This is the one fact that makes the keys hidden from third parties, since only the server and the client
have access to the private keys.
 6. This concludes the handshake and begins the secured connection allowing the bulk data transfer, which is
encrypted and decrypted with the keys until the connection closes. If any one of the above steps fails, the SSL
handshake fails, and the connection is not created.

SSL Handshake with ACOS device
 Client begins a secure session by

initiating a SSL handshake with the VIP
IP
 ACOS on behalf of the server
responds with certificate along with its
public key bound to the client-SSL
template.
 Client verifies the certificates validity
by checking its certificate store.
 Once the handshake is complete and
the master-key is exchanged, data
between client and ACOS is
encrypted using the shared secret
key.

Certificate Options
CA-signed
To obtain a CA-signed certificate, an admin creates a key and a Certificate
Signing Request (CSR), and sends the CSR to the CA. The CSR includes the key. The
CA then creates and signs a certificate. The admin installs the certificate on the
ACOS device. When a client sends a HTTPS request, the ACOS device sends a
copy of the certificate to the client, to verify the identity of the server (ACOS
device).
Self-Signed
Self-signed certificate is a certificate that is created and signed by the ACOS
device. CA is not used to create or sign the certificate
Note: If you configure the ACOS device to present a self-signed certificate to clients, the client’s browser
may display a certificate warning. This can be alarming or confusing to end users. Users can select the option
to trust a self-signed certificate, in which case the warning will not re-appear.

Chain Certificates
 A certificate must be validated by a root CA.

Certificates from root CAs are the most trusted. They
do not need to be signed by a higher (more trusted)
CA.
 If the CA that signed the server certificate is not a root
CA, the client browser should have another certificate
or a certificate chain that includes the CA that signed
the CA’s certificate.
 A certificate chain contains the “chain” of signed
certificates that leads from the CA to the signature
authority that signed the certificate for the server.
Typically, the certificate authority that signs the server
certificate also will provide the certificate chain.
 The certificate at the top of the certificate chain file is
the root CA’s certificate. The next certificate is an
intermediary certificate signed by the root CA. The
next certificate is signed by the intermediate signature
authority that was signed the root CA.
ACOS(config)# slb template client-ssl clientssl
ACOS(config-client ssl)# chain-cert examplechaincert

SSL templates
 Client SSL Template

Contains keys and certificates for SSL-encrypted traffic between clients and the
ACOS device. A client-SSL template can also contain a certificate chain.
CA signed public
1. Request server certificate certificate +
Private key
2. Server certificate + Public Key
4. (optional) Request client certificate

3. Validate server 6. Validate client
certificate certificate
5. Client certificate
7. Create master secret to encrypt the data
List of trusted CAs CA to use for client

certificate validation

Client-SSL Template Options
 key
– Private key that A10 will use (as a server)
 cert
– Specifies the certificate that the A10 will use (as a server)
 ca-cert (optional)
– Used to authenticate client certificate
– Only used if “client-certificate request/require” is used
 chain-cert (optional)
– Uses the intermediate cert, if necessary
 cipher (optional)
– Chooses the cipher suite that A10 will allow

Client-SSL Template Options
 client-certificate {ignore | request | require}
–ignore – A10 does not request client certificate (default)
–request - request certificate from client during SSL handshake
 cert can be invalid or null, handshake will still occur
–require - request certificate from client during SSL handshake
 cert MUST be valid, or else handshake will not occur
 close-notify
–A10 will send a close_notify message to client before the SSL transaction is over
 Some applications require this, such as PHP cgi.
 crl (Certificate Revocation List)

–Uses a CRL to verify that a client cert has not been revoked

SSL Template
 Server SSL Template

Contains CA certificates for SSL-encrypted traffic between servers and the ACOS
device.
CA signed public
certificate +
1. Request server public certificate Private key
3. (optional)
Validate server 2. Server public certificate
certificate
CA to use for server

certificate validation
NOTE: If you replace a certificate and key in a client-SSL or server-SSL template, you must unbind the
template from the virtual ports that use it, then rebind the template to the virtual ports, to place the change
into effect.
Server-SSL Template Options
 ca-cert
– Used to authenticate back-end server certificate
 key
 Specifies the private key that the
 cert A10 will use
– Specifies the client-certificate that the A10 will use  Only used if the back-end server
uses client certificate request
– Only used if the back-end server uses client
certificate request
 version
 cipher  Version of SSL that is being used.
– Chooses the cipher suites that A10 will allow  TLSv1.2
 close-notify  SSLv3.0
 TLSv1.0 (SSLv3.1)
– A10 will send a close_notify message to server
before the SSL transaction is over

SSL configuration options on A10
 SSL with L4 TCP Virtual Port
 SSL with L7 HTTPS Virtual Port

 SSL Offload: Front end encryption, but no encryption on backend
 End-to-End SSL: Encryption on both front and backend
 SSL with SSL-Proxy Virtual Port

SSL with L4 TCP virtual port
 An example of a basic configuration for SSL with a TCP Virtual Port

 With this setup the SSL authentication is done by the backend server.
 The A10 in this case will do basic load balancing but in terms of inspection can only see
up to layer 4.
slb virtual-server ssl-l4 10.10.10.100
port 443 tcp
name _10.10.10.100_TCP_443
Encrypted
source-nat pool snat
service-group sg-443 Decrypted
HTTPS HTTPS

SSL with L4 TCP Virtual Port
 Advantages:
–Consumes less resources on the A10
–If your traffic load exceeds what the A10 can handle for L7 sessions, it could be
beneficial with this setup.
–Minimal configuration needed on the A10.
 Disadvantages:
–You can not do any Layer 7 configuration for the traffic
–For example, you can not do redirects, cookie persistence, or any aFlex event
that has to do L7 packet inspection
–If you require any of these features your backend server must do them
–You can not do any SSL offloading to the A10

SSL Offload
• SSL Offload relieves the server of SSL encryption/decryption

• Client connects to the VIP via https
• ACOS device acts as the server and provides certificate to client for server verification
• ACOS decrypts and sends traffic to webservers via http
• Maintains HTTPS connection with client and HTTP(clear text) connection with server
• Off-loads encryption CPU cycles from webservers
Encrypted
• Provides faster server response time and higher server scalability
• Requires Client SSL template on V-Port Decrypted
HTTPS HTTP

Configuration
 Import or create a certificate and its key to use for TLS sessions  Configure the real servers for the TCP service:
with clients.
ACOS(config)#slb server HTTPS1 10.5.5.2
ACOS#import cert sslcert1.crt ftp:
ACOS(config-real server)#port 80 tcp
Address or name of remote host []?1.1.1.2
ACOS(config)#slb server HTTPS2 10.5.5.3
User name []?Admin-15
ACOS(config-real server)#port 80 tcp
Password []?*********
The following configures a service group for the HTTPS servers:
File name [/]?sslcert1.crt
ACOS(config)#slb service-group HTTPS_servers tcp
ACOS#import key sslcertkey.pem ftp:
ACOS(config-slb svc group)#member HTTPS1 80
Address or name of remote host []?1.1.1.2
ACOS(config-slb svc group-member:80)#member HTTPS2 80
User name []?Admin-15
 Configure a virtual server and add a virtual port that has the
Password []?********* service type https. Bind the service-group to the virtual port
File name [/]?sslcertkey.pem
and to the HTTP template (if configured) and client-SSL
template.
 Configure a client SSL template and bind the certificate and
ACOS(config)#slb virtual-server v1 10.6.6.6
key to it.
ACOS(config-slb vserver)#port 443 https
ACOS(config)#slb template client-ssl sslcert-tmplt
ACOS(config-slb vserver-vport)#service-group HTTPS_servers
ACOS(config-client ssl)#cert sslcert.crt
ACOS(config-slb vserver-vport)#template client-ssl sslcert-tmplt
ACOS(config-client ssl)#key sslcertkey.pem
The SSL offload feature is enabled by the https option of the port
command.

SSL Offload: Advantages & Disadvantages
 Advantages
–The ability to take full advantage of nearly all the features that the A10 offers even for
encrypted traffic
–The reason for this is because the cert/key is stored on the A10, the A10 is able to decrypt the
packet which allows the A10 to look at L7 headers.
–From the backend servers point of view the traffic is not encrypted, and for customers with
weaker servers it takes some of the burden away
 Disadvantages
–Because this is a proxy connection, there could be more latency when compared to a L4
configuration. This is due to the fact that are twice as many packets.
–In terms of A10 resources, the A10 can support a much greater traffic rate when configured
with L4 vs L7 (SSL-Proxy).

End-to-End SSL
• ACOS provides encrypted connection on both client side and server side
• Client connects to the VIP via https
• ACOS initiates HTTPS connection with the server.
• Server provides with its certificate to ACOS and a secure connection is established with server
as well
• Provides end-to-end encryption Encrypted
• Requires Client SSL and Server SSL template on V-Port Decrypted

HTTPS HTTPS

Configuration
 Import or create a certificate and its key to use for TLS sessions  Configure the real servers for the tcp service listening on
with clients. https:
ACOS#import cert sslcert1.crt ftp: ACOS(config)#slb server HTTPS1 10.5.5.2
Address or name of remote host []?1.1.1.2 ACOS(config-real server)#port 443 tcp
User name []?Admin-15 ACOS(config)#slb server HTTPS2 10.5.5.3
Password []?********* ACOS(config-real server)#port 443 tcp
File name [/]?sslcert1.crt  The following configures a service group for the HTTPS servers:
ACOS#import key sslcertkey.pem ftp: ACOS(config)#slb service-group HTTPS_servers tcp
Address or name of remote host []?1.1.1.2 ACOS(config-slb svc group)#member HTTPS1 443
User name []?Admin-15 ACOS(config-slb svc group-member:80)#member HTTPS2 443
Password []?*********  Configure a virtual server and add a virtual port that has the
File name [/]?sslcertkey.pem service type https. Bind the service-group to the virtual port
and to the HTTP template (if configured),client-SSL template
 Configure a client SSL template and bind the certificate and and server-ssl template
key to it.
ACOS(config-slb vserver)#port 443 https
ACOS(config-slb vserver-vport)#service-group HTTPS_servers
3. Configure a server SSL template and optionally bind the CA to it
ACOS(config-slb vserver-vport)#template server-ssl ca-cert
ACOS(config)#slb template server-ssl ca-cert
End-to-End SSL
 Advantages
–This setup would mainly be used by customers who need to make sure that all of their traffic
will always be encrypted (I.E: Banks) while taking advantage of the A10 L7 Features
 Disadvantages
–There is an additional SSL handshake that needs to take place between the A10 and server
–The server still has to have the cert/key and so there is no load taken off of the server.

SSL Proxy
• In SSL proxy, the ACOS device acts as a Layer 4 SSL proxy for TCP services such as POPS,
SMTPS, IMAPS, and LDAPS. It combines TCP load balancing (Layer 4 SLB) with these proxy
services.
• Client connects to the VIP via HTTPS
• ACOS initiates encrypted/decrypted connection with the server.
• Requires Client SSL template on V-Port Encrypted
Decrypted
SSL Request Encrypted/decrypted

SSL-Proxy Virtual Port
 SSL-Proxy is a hybrid between the port type TCP and HTTPS.
 SSL-Proxy does not support L7 features such as redirect.
 However it allows the customer to offload the SSL authentication to the A10 by
putting the cert/key on the A10
 Because of this SSL-Proxy can have the backend servers to be encrypted or
unencrypted with the same reasoning as HTTPS

Configuration
 Import or create a certificate and its key to use for TLS sessions  Configure the real servers for the TCP service. The following
with clients. commands configure proxy SSL for POPS
ACOS#import cert sslcert1.crt ftp: ACOS(config)#slb server POP1 10.5.5.2
Address or name of remote host []?1.1.1.2 ACOS(config-real server)#port 110 tcp
User name []?Admin-15 ACOS(config)#slb server POP2 10.5.5.3
Password []?********* ACOS(config-real server)#port 110 tcp
File name [/]?sslcert1.crt 3. The following commands configure a service group for the POP servers:
ACOS#import key sslcertkey.pem ftp: ACOS(config)#slb service-group POP_servers tcp
Address or name of remote host []?1.1.1.2 ACOS(config-slb svc group)#member POP1 110
User name []?Admin-15 ACOS(config-slb svc group-member:110)#member POP2 110
Password []?*********  The following commands configure a virtual server (VIP)
File name [/]?sslcertkey.pem which proxies for the service POP server (port 110): The
following commands configure the VIP to which clients will
 Configure a client SSL template and bind the certificate and send POPS traffic (that is, port 110):
key to it.
ACOS(config-slb vserver)#port 110 ssl-proxy
ACOS(config-slb vserver-vport)#service-group SMTP_servers

SSL cards
 Why it is important to know the card?
– For performance and PFS support
 Older models use Nitrox-PX cards which has less cores does not support PFS ciphers
(ECDHE/DHE)
 Some AX models and all Thunder models use Nitrox-III which supports ECDHE/DHE
starting 2.7.2-P2
 Some systems have PX card installed on board and a Nitrox-III can be added later.
When both cards are present, Thunder will use Nitrox-III only (e.g. Thunder3400)
 All Nitrox-III are not same. They have different number of cores. To confirm use the
‘show hardware’ and ‘show slb ssl stat’ command. This command is not available in
2.6 code.
 Note: ECHDE/DHE performance has been optimized a lot in the later 2.7.2 releases
and hence always recommend customer to use 2.7.2 latest patch.
 We use HSM cards as well in some systems which are used for FIPS compliance.

SSL cards
Nitrox -III Nitrox -PX
Thunder2500-Active-vMaster[2/1]#show slb ssl stat
ACOS#show slb ssl stat
SSL module: Hardware
SSL module: Hardware
Number of SSL modules: 1
Number of SSL modules: 1
SSL module 1
SSL module 1
number of enabled crypto engines: 6
number of enabled crypto engines: 16
number of available crypto engines: 6
number of available crypto engines: 16
number of requests handled: 0
number of requests handled: 2318019
number of requests with errors: 0
number of requests with errors: 0
Current clientside SSL connections: 0
ACOS#show hardware
Thunder2500-Active-vMaster[2/1]#show hardware
Thunder Series Unified Application Service Gateway TH1030S
Thunder Series Advanced Traffic Manager Thunder2500
Serial No : TH10A73314020108
Serial No : Thunder25051110280111
8 cores
8 cores
9 stepping
5 stepping
Memory : Total System Memory 8148 Mbyte, Free Memory 2936 Mbyte
Memory : Total System Memory 6122 Mbyte, Free Memory 1475 Mbyte
SMBIOS : Build Version: 4.6.5
SMBIOS : Build Version: 080015
SSL Cards : 1 device(s) present
SSL Cards : 1 device(s) present
1 Nitrox III each with 16 cores
1 Nitrox PX
GZIP : 0 compression device(s) present
GZIP : 0 compression device(s) present
L2/3 ASIC : 0 device(s) present
L2/3 ASIC : 0 device(s) present
IPMI : Present
Ports : 12
Ports : 10
ACOS#
Cipher Support ECDHE/DHE & Optimization
 ACOS also provides support for ECDHE/DHE ciphers, including ECDHE-RSA ciphers,
DHE-RSA ciphers, ECDHE-ECDSA ciphers, and GCM & SHA384. This feature also
allows for the configuration of EC and DH parameters, EC Curve selection, the
importing/verification of EC Keys for ECDSA ciphers, and support for TLS1.0/TLS1.1.
 Offload data CPU by configuring ec-names which enables Nitrox card hardware
to process the ECDHE/DHE client traffic thus lowering the data CPU’s
 Nitrox III SSL card only offers hardware support for two Elliptical Curves, ec-name
secp256r1 and secp384r1, which must be explicitly configured in the client SSL
template to take advantage of hardware offload.
 When processing a SSL handshake, if the user has configured a template for both
ECDHE and DHE with the same priority levels, the priority is given to ECDHE over
DHE to optimize CPU usage on the ACOS device. DHE ciphers will be considered
as the lowest priority if there are other supported ciphers in the client-hello
message.

SSL verification commands
vThunder_150-Active#show slb ssl stats Record too big 0

SSL module: Software Total client ssl context malloc failures: 0
Current clientside SSL connections: 24 MThunderimum SSL contexts N/A Current SSL contexts in use
2
Total clientside SSL connections: 65
SSL Forward Proxy
Current serverside SSL connections: 0
Bypass Failsafe SSL sessions: 0
Total serverside SSL connections: 0
Bypass SNI sessions: 0
Total Non SSL Bypass connections: 0
Bypass Client Auth sessions: 0
Total times of reusing SSL sessions(IDs) in client ssl 0
Failed in SSL handshakes: 0
Total times of reusing SSL sessions(IDs) in server ssl 0
Failed in crypto operations: 0
Failed SSL handshakes: 0
Failed in TCP: 0
Failed crypto operations: 0
Failed in Certificate verification: 0
SSL memory usage: 18714 bytes
Invalid OCSP Stapling Response: 0
SSL server certificate errors: 0
Revoked OCSP Response: 0
SSL client certificate authorization failed: 0
Unsupported SSL version: 0
SSL fail CA verification 0
HW Context Memory alloc failed 0
HW ring full 0
SSL verification commands
 #show slb ssl error
 #show pki cert
Name: 2k.crt Type: certificate/key Expiration: Jan 24 23:10:41 2019 GMT
[Unexpired, Bound]

SSL debug information
vThunder_150-Active#debug pack l3 ip 10.10.10.105
vThunder_150-Active#debug ssl
vThunder_150-Active#debug mon

Integrated DDoS Protection
Thunder ADC Security Overview
 DDoS Mitigation
–Check traffic for IP anomalies
 Policy-based SLB (PBSLB)
–Black/White List individual clients or subnets
 IP Limiting (Rate Limiting)
- enhanced connection limit and rate limit
 SYN Cookie
- Protects against TCP SYN flood attack
 WAF

IP Anomaly Filtering
 IP Anomaly filtering detects and drops packets that contain common signature
DDoS attacks
 Following filters are currently available

Considerations for IP Anomaly
 ALL IP anomaly are supported for Ipv4

 All IP anomaly are supported for Ipv6 except for the IP-option
 Ddos protection is hardware based on: Th3200-12, Th6430S, Th6430 & Th5430S.
Software based on all other models
 Ping of death drops all IP packets longer than 32000 bytes on Th3030S, Th1030S
and Th930. On all other models it drops packets longer than 65535bytes

Configuration
 Following commands enable the IP anomaly options. By

default all IP anomaly filters are disabled. Commands below
enable them system-wide basis.
ACOS(config)# ip anomaly-drop ping-of-death
ACOS(config)# ip anomaly-drop out-of-sequence 10
ACOS(config)# ip anomaly-drop tcp-syn-fin
 Following command is used to see the statistics for IP

Anomaly:
ACOS(config)# show ip anomaly-drop statistics

Policy-Based SLB
 PBSLB can load balance traffic based on user defined policy, which can be
dropping packets, resetting connections, limiting concurrent connections, limiting
connection rate and selecting a service group.
 ACOS allows you to black-list or White-list individual client or client subnets.
 For white-lists the traffic can be steered to a different service-group.
 For black-lists you can specify the action to be taken (drop or reset) on a new
connection that exceeds the configured connection threshold.
 PBSLB can be applied on a system-wide basis or on individual virtual-ports.
 IP lists for PBSLB can be configured by using BW-list or class list.

Black/White List
 B/W List: It is an IP/subnet list that maps IP lists to a group ID which define the rules
to be applied to the IP list. It also provides connection limit feature.
 It can be created on external device and imported to ACOS or created on the
ACOS device on GUI/CLI
 It can contain upto 8million individual host addresses and upto 64000 subnets
 Syntax for bw-list
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]

BW-list Syntax
 Importing from remote host:  IP addr: host or subnet address of client

ACOS(config)# import bw-list bwlist1 ftp://1.1.1.2/home/user/bwlist1  Network-mask: optional network mask
User name []? ACOSadmin
 Group-id: number between 1-31 identifies a
Password []? *********
group of IP host or subnet addresses in the list
BW-List format:
and maps to one of the following actions: drop,
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string] reset or send to a specific service-group.
 Conn-limit: maximum number of concurrent
connections that are allowed from the client.

Example
 Configure the black/white list and bind it to the group-ids’s and define connection limit if
needed
10.10.1.3 4; blocking a single host. 4 is the drop group
10.10.2.0/24 4; blocking the entire 10.10.2.x subnet
192.168.1.1/32 #20 ; 20 concurrent connections max, any group ok
192.168.4.69 2 20 ; assign to group 2, and allow 20 max
 The rows in the list specify the following:

• For individual host 10.10.1.3, use IP limiting rule configured in group ID 4 in the policy template.
• For all hosts in subnet 10.10.2.0/24, use IP limiting rule configured in group id 4 , which is configured in a policy template.
• For individual host 192.168.1.1, limit concurrent connections to 20
• For individual host 192.168.4.69, use limiting rule configured in group id 4 and allow max 20 concurrent connections.

PBSLB – Configuration example using BW-list
 Import the black-white list from the remote host  Bind it to the virtual-port
ACOS(config)# import bw-list sample-bwlist tftp://myhost/TFTP- ACOS(config)# slb virtual-server PBSLB_VS1 10.10.10.69
Root/ACOS_bwlists/sample-bwlist.
 Display the imported bw-list ACOS(config-slb vserver-vport)#service-gorup sg1-http
ACOS(config)# show bw-list ACOS(config-slb vserver-vport)# template policy bw1
Name Url Size(Byte) Date
 Display the pbslb information
------------------------------------------------------------------------------
ACOS(config-slb vserver-vport)# show pbslb
sample-bwlist tftp://myhost/TFTP-Root/ACOS_ N/A N/A
Total number of PBSLB configured: 1
bwlists/sample-bwlist.txt Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
Total: 1 ------------------------------------------------------------------------------
 Create the policy template, bind the imported bwlist PBSLB_VS1 80 sample-bwlist 2 0 0 0
and create the group ID’s with actions to take 4 0 0 0
ACOS(config)# slb template policy bw1

ACOS(config-policy)# bw-list name sample-bwlist
ACOS(config-policy)# bw-list id 2 service-group sg2-http
ACOS(config-policy)# bw-list id 4 drop

Class-List
 Class-List: It is a set of IP host or subnet addresses that are mapped to IP limiting

rules.
 ACOS supports up to 255 class lists and each class list can contain up to 8 million
host IP’s and 64000 subnets.
 Class-lists can be only configured in the shared partition. The policy template can
use class-list from shared partition in a private partition.

Class-List - Syntax
 Importing from remote host:  Age: removes a host entry from class list after specified
number of minutes. (not supported for subnets)
ACOS(config)#import class-list class_list ftp://1.1.1.2/home/user/class_list
 Global Limit number (Glid/Lid): Number from 1-31 that
User name []? ACOSadmin
identifies the rule
Password []? *********
 Connection limit: Maximum number of concurrent
Using CLI:
connections that are allowed for a client.
 Creating class list on CLI:  Connection rate limit: Maximum number of new connections
that are allowed for a client in a given limit period.
class-list <name> [type]  Request limit: Maximum number of concurrent Layer 7
ipaddr/network-mask [glid num|lid num][age minutes][;comment-string] requests allowed for a client
 Defining glids  Request-rate limit: maximum number of layer 7 requests that
glid <id>
are allowed for a client in the limit period
conn-limit <conn-limit-num>  Over limit action: action to take when a client exceeds at
least one limit: drop/reset/forward. If logging is enabled
conn-rate-limit(num) per <num-of-100ms> ACOS also generated a log
request-limit <request-limit-num>  Lockout period: Number of minutes during which to apply the
request-rate-limit (num) per <num-of-100ms> over-limit-action over limit action after the client exceeds the limit.
[forward|reset] [lockout] [log ]
 Logging: generated log messaged when clients exceed a
limit.

Example
 Here is an example of a simple class list. This list matches on all clients and uses an IP
limiting rule that is configured at the global configuration level:
0.0.0.0/0 glid 1
 Here is an example with more options:

2.2.2.0 /24 lid 2 ; LID 2 applies to every single IP of this subnet
0.0.0.0 /0 lid 10 ; LID 10 applied to every undefined single IP
3.3.3.3 /32 glid 3 ; Use global LID 3
4.4.4.4 /32 ; No LID is applied (exception list)
The rows in the list specify the following:

• For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is configured in a policy template.
• For all hosts that do not match another entry in the class list, use IP limiting rule 10, which is configured in a policy template.
• For individual host 3.3.3.3, use IP limiting rule 3, which is configured at the global configuration level.
• For individual host 4.4.4.4, do not use an IP limiting rule.

Configuration – PBSLB using Class-lists
 Create class-list with the IP rules and their glid/lid  Bind the policy template to the virtual-port
binding ACOS(config)# slb virtual-server vs-55 55.1.1.55
ACOS(config)# class-list 2 ACOS(config-slb vserver)# port 80 http
ACOS(config-class list)# 5.1.1.100/32 glid 1023 ACOS(config-slb vserver-vport)# service-group sg1-http
ACOS(config-class list)# 55.1.1.0/24 lid 31 ACOS(config-slb vserver-vport)# template policy global_policy
 Create glid with the IP limiting rules

ACOS(config)# glid 1023
ACOS(config-glid:1023)# request-limit 10
ACOS(config-glid:1023)# request-rate-limit 2 per 100
ACOS(config-glid:1023)# over-limit-action reset log
 Create policy template, bind the class list and define

ip limiting rules for lid
ACOS(config)# slb template policy global_policy
ACOS(config-policy)# class-list 2
ACOS(config-policy-class-list:l3)# lid 31
ACOS(config-policy-class-list:l3-lid:31)# request-limit 10
ACOS(config-policy-class-list:l3-lid:31)# request-rate-limit 2 per 100
ACOS(config-policy-class-list:l3-lid:31)# over-limit-action drop log

Notes
 Request limit and request rate limit only applicable to policy templates bound to
a virtual-port. They can only be applied to HTTP, fast-HTTP and HTTPS virtual-ports.

Dynamic Entries
 Wild card entries such as “0.0.0.0/0” can be configured in a bw-list or class-list and
applied globally and is used by system-wide PBSLB policy
 When a client sends an HTTP or HTTPS connection request, the ACOS device
checks the system-wide PBSLB policy’s black/white list for the client’s IP address,
with one of the following results:
If there is no entry for the client, the ACOS device creates a dynamic entry for
the client’s host address.
If there is a dynamic entry for the client, the ACOS device resets the timeout value
for the entry.
The timeout value can be set to 1-127 mins (default 5 mins)
 ACOS supports 8 million dynamic client entries for system-wide PBSLB. Once limit
reached it will not track connections or anomaly for additional clients

Configuration
0.0.0.0/0 1 #20
 The clients who do not match the static entry in the list are assigned to group 1
and are limited to 20 concurrent connections.
 The connection limit is applied to each client that has a dynamic entry in the
black/white list

Wildcard Addresses
 Wildcard address (0.0.0.0/0) is supported for black/white list that is used by a

virtual-ports PBSLB policy.
 The group id and connection limit is applied to all clients that do not have a static
entry in the list, however this does not create a dynamic entry.

Configuration - System Wide PBSLB
Configuring Sytem wide PBSLB using BW-list and policy template Configuring System wide pbslb using class list and glid
 The following example drops any connections from clients exceeding  The following commands configure a standalone IP limiting rule to be
one of the following limits: applied globally to all IP clients, which match class list “global”
• The connection limit that is configured in the specified Black/White list. ACOS(config)# glid 1
• The threshold of any of the new IP anomaly filters. ACOS(config-glid:1)# conn-rate-limit 10000 per 1
Logging is enabled and messages are generated two minutes. ACOS(config-glid:1)# conn-limit 1000000
ACOS(config)# slb template policy pol1 ACOS(config-glid:1)# over-limit-action forward log
ACOS(config-policy)# bw-list id 1 drop logging 2 ACOS(config-glid:1)# exit
ACOS(config-policy)# bw-list over-limit lockup 5 logging 2 ACOS(config)# system glid 1
ACOS(config-policy)# exit  The following commands configure class list “global”, which matches
on all clients and uses IP limiting rule 1:
 Apply the policy template at the system level:
ACOS(config)# class-list global
ACOS(config)# system template policy pol1
ACOS(config-class list)# 0.0.0.0/0 glid 1

Configuration – PBSLB with class-list
 Example with glid  Example with lid

class-list ip_1.1.1.5 ipv4 class-list ip_1.1.1.6 ipv4
1.1.1.5 /32 glid 1 1.1.1.6 /32 lid 1
glid 1 slb template policy policy
conn-rate-limit 2 per 100 class-list name ip_1.1.1.6
request-rate-limit 2 per 100 class-list lid 1
over-limit-action log conn-limit 1
conn-rate-limit 1 per 100
slb template policy policy request-limit 1
class-list name ip_1.1.1.5 request-rate-limit 1 per 100
over-limit-action reset log
slb virtual-server vip 1.1.1.153
port 80 http slb virtual-server vip 1.1.1.153
source-nat pool snat port 80 http
service-group http source-nat pool snat
template policy policy service-group http
template policy policy

Viewing PBSLB entries
 #Show log
Apr 11 2017 18:03:45 Info [PBSLB]:[ve 10] TCP 10.10.10.153 > 10.10.10.106:80 PBSLB resets connection because connection number is over limit (VP Policy
class)
Apr 11 2017 18:03:45 Info [PBSLB]:[ve 10] TCP 10.10.10.153 > 10.10.10.106:80 PBSLB resets connection because connection number is over limit (VP Policy
class)
 #show pbslb virtual-server vip7-pbslb port 80 http

Virtual port class list statistics:
F = Flag (C-Connection, R-Request, S-Response code, D-direct action), Over-L = Over-limit, Over-RL = Over rate limit, LkupT = Lockup time left, Lkup# =
Lockup number
when F=S; Rcode = response code range, Rate = number of RSP code in period
when F=D; Please use the description with ()
Source Destination Rcode F Current Rate Over-L Over-RL LkupT Lkup# Age
(lid num) (D) (drop) (Reset) (Ser-sel) (Ser-sel-fail) (Age)
---------------+--------------------+-------+-+---------+---------+----------+----------+-----+-----+----
10.10.10.153 10.10.10.106:80 C1 0 1040 0 0 0 6
Total: 1

Debug Packet Output
ACOS#debug pack l3 ip 10.10.10.106 c 0

ACOS#debug mon
@841196 o( 1, 0, dce2)> ip 10.10.10.106 > 10.10.10.153 tcp 80 > 43331 RA adb8e474:424dd178(0)
@841196 i( 1, 10, db42)> ip 10.10.10.153 > 10.10.10.106 tcp 43331 > 80 PA 424dd178:adb8e474(175)
@841196 o( 1, 0, db42)> ip 10.10.10.106 > 10.10.10.153 tcp 80 > 43331 RA adb8e474:424dd227(0)
Note: The policy is to reset the connections once the connection limit is reached for the client, we can see
resets being sent to the client

SYN- Cookie
 During the syn flood attack the attacker opens many TCP SYN requests, receives
SYN-ACK’s from the server but does not respond back with an ack. This opens
large number of half open connections on the server and consume system
resources. Under large scale attack it causes the TCP connection queue to
become full and causes legitimate traffic to get dropped.
 SYN cookie mitigates the damage caused by such attack by preventing the
attacks from consuming system resources

Dynamic Syn Cookie
 Allows you to configure threshold to enable/disable syn cookie once the number
of half open connections are met.
On-threshold – specifies the mThunderimum number of concurrent half-open TCP
connections that are allowed on the ACOS device, before SYN cookies are
enabled. 0- 2147483647 half-open connections.
Off-threshold – specifies the minimum number of concurrent half-open TCP
connections for which to keep SYN cookies enabled. If the number of half-open
TCP connections falls below this level, SYN cookies are disabled. You can specify
0-2147483647 half-open connections.

SYN Cookie
 By default, hardware-based SYN cookies are disabled.

 Hardware-based SYN cookies are available on Thunder 6430S, Thunder 6430, and
Thunder 5430S. The cookies are also available on Thunder Series models Thunder
2200, Thunder 2200-11, Thunder 3100, Thunder 3200, Thunder 3200-11, Thunder
3200-12, Thunder 3400, Thunder 5100, Thunder 5200, and Thunder 5200-11.
 Software-based SYN cookies can be enabled on individual virtual ports. This
version of the feature is available on all Thunder models.
 If ADP are configured, HW SYN cookie applies to all partitions, its not a partition
aware feature.

Configuration
 On FTA models:
ACOS(config)# syn-cookie enable  Once syn-cookie is enabled the MAC address on the virtual-
server changes:
Dynamic Syn-cookie
TH3430S-Active(config)#show slb virtual-server v2 detail
ACOS(config)# syn-cookie enable on-threshold 50000 off-threshold
30000 Virtual server name: v2
 Non-FTA Models Virtual server IP address: 5.1.1.240
To enable software-based SYN cookies, use the syn-cookie command at Virtual server MAC: 021f:a020:0001
the virtual-port level. For example:
ACOS(config)# slb virtual-server vip1
 Disable syn-cookie:
ACOS(config-slb vserver)# port 80 tcp
TH3430S-Active(config)#show slb virtual-server v2 detail
ACOS(config-slb vserver-vport)# syn-cookie
Virtual server name: v2
 Modifying the threshold for tcp handshake completion
(default is 4), For example, to set the threshold to 3 seconds: Virtual server IP address: 5.1.1.240
ACOS(config)# ip tcp syn-cookie threshold 3 Virtual server MAC: 021f:a000:0001

Virtual server template: default
 Disable Syn-cookie
ACOS(config)# no syn-cookie enable  Display syn-cookie stats:
ACOS# show slb l4
Total
------------------------------------------------------------------
Confidential | ©A10 Networks,
IP Inc. 0
out noroute 168
Health Monitors
Purpose of Health Monitors
 Determine State
 Periodically sent
 In simple words, Thunder says “are you there?” and the server responds “yes, I am”

Identify The Health Monitor in the OSI Model

Health Monitor Overview
 Essential to determine whether the backend servers are really operational or not.
 The Thunder will mark the server as “Up” or “Down”
 Depending on the Health monitor status, the Thunder will forward or load balance traffic
to the server
 Default and custom health checks

Default Health Monitor (HM)
Default Methods:
 ICMP at server level
 After ICMP health check passes, the Thunder will issue a Layer 4 health check to the
configured port under the server.
–TCP Handshake
–Packet sent for UDP and no responds is expected
By default how often does the Thunder perform health monitors and when does it take the
server out of rotation?
 Interval is 5 seconds (Configurable from 1 to 180sec)
 Retries is 3 (Configurable from 1 to 10)
 Timeout is 5 (Configurable from 1 to 180sec)
 Up-retry (Configurable from 1 to 10)

What IP does the Thunder use when performing HC:
 In switch mode, Thunder box global IP address performs the HC. In a multi-netted
environment, the Thunder will use the source-nat ip address for the health checks.
 In routed mode, the “VE” interfaces ip address or interface ip address will be used to
perform the HC.
 Similarly, in multi-netted environment, the respective VE ip address will perform the health
checks.

What IP does the Thunder use when performing HC:
Routed Mode Switch Mode
20.2020.2
30.30.30.2
Vlan 20
Eth1
VE 20 20.20.20.1
Eth1
AX AX
Ip address 30.30.30.1/24
Vlan 30 Eth2 Ip default-gateway 30.30.30.2
Ethe 2
VE 30 30.30.30.1
30.30.30.101 30.30.30.102 30.30.30.103

30.30.30.101 30.30.30.102 30.30.30.103

Layer 3: Default ICMP Health Monitor
 In the Routed mode, diagram in previous slide, the health checks are issued from VE interface 30.30.30.1 to all the servers.
 When we first define a server with command as below
Thunder3200-12-65(config)# slb server s1 30.30.30.101
VE interface sends ICMP request and makes server up when we get ICMP response .
Thunder3200-12-65#debug packet l3 ip 30.30.30.101
Thunder3200-12-65#debug mon
Wait for debug output, enter <ctrl c> to exit
@1785438 o( 3, 30, a83e)> ip 30.30.30.1 > 30.30.30.101 icmp echo req seq=12
@1785438 i( 3, 30, 8069)> ip 30.30.30.101 > 30.30.30.1 icmp echo rsp seq=12
@1786695 o( 3, 30, a842)> ip 30.30.30.1 > 30.30.30.101 icmp echo req seq=13
@1786695 i( 3, 30, 806d)> ip 30.30.30.101 > 30.30.30.1 icmp echo rsp seq=13
Thunder3200-12-65(config)#show health stat
IP address Port Health monitor Status Cause(Up/Down) Retry PIN
-------------------------------------------------------------------------------------------------------------
30.30.30.101 default UP 11 /0 @0 0 0 /0 0
Thunder3200-12-65#devcall hm_up_reason(11)
ICMP Receive OK

Layer 4: Default TCP Port Health Monitor
 If we define a TCP port in the server, then Thunder starts its default health check at port level.
Thunder3200-12-65(config)# slb server s1 30.30.30.101
Thunder3200-12-65(config-real server)# port 80 tcp
 As seen in the above pcap file, there is a proper 3way handshake and closing (closing can be a 3way or a 4 way).
Thunder3200-12-65(config)#show health stat
-------------------------------------------------------------------------------------------------------------
30.30.30.101 80 default UP 20 /0 @0 0 0 /0 0
TCP Verify Connection OK

Layer 4: Default UDP Port Health Monitor
 As see from above capture, we started default HC after defining a server port as 69 (tftp).
Thunder3200-12-65(config-real server)# port 69 udp
30.30.30.101 69 default UP 24 /0 @0 2 0 /0 0
UDP No Response
 As previously mentioned, for UDP health checks, the Thunder sends a packet with garbage data and no response is expected
for UDP Layer 4. If the server is not listening on the specified UDP port, it will issue an ICMP port unreachable message.

Layer 7: Custom Health Monitors
Custom Layer 7 Health Checks

 Provides the monitoring of the application.
 Provides granular health checking for content within the application.
 Server may be physically available to ICMP and to TCP/UDP but application may not be
responding correctly.
 The Layer 3 and Layer 4 HC would not be able to detect application problems.
 The Thunder supports the following application health checks:
–HTTP/HTTPS, DATABASE, DNS, FTP, LDAP/LDAPS, IMAP, KERBEROS-KDC, NTP, POP3, SMTP,RADIUS,
RTSP, SIP, and SNMP.

Layer 7: Custom Health Monitors for HTTP.
 HTTP protocol based on request and response model in a client-server environment.

 HTTP Request Methods. There are 9 HTTP request methods. Thunder Health Check
supports only 3.
–GET
–HEAD
–POST

Layer 7: Custom HM for HTTP
 Below is the HTTP request header:
 This example shows a GET request for “index.html”.

 HTTP protocol relies on a messaging scheme for responding to client

requests.
 The first digit of the status code specifies one of five classes of responses.
 HTTP Response codes:
–1xx Informational
–2xx Success
–3xx Redirection
–4xx Client Error
–5xx Server Error


 HTTP Response header format:
 In this example, the server replies with a HTTP 200 OK response code. This is in response to the GET
“index.html” request in previous slide.
 Notice that the message body says that the site is under maintenance.

 Example customer HM from the Thunder:
Thunder3200-12(config)#health monitor <name>

Thunder3200-12(config)#health monitor http_hc
Thunder3200-12(config-health:monitor)#method http url GET /index.html
 Apply the named health monitor “http_hc” to the server, server port or at service-group level.
Thunder3200-12(config)#slb server s1 30.30.30.101

Thunder3200-12(config-real server)#health-check http_hc
slb service-group http tcp

health-check http_hc
member web-50:80
member web-51:80

 First, the Layer-4 TCP 3-way handshake is established between the Thunder and server using the VE
interface. Then the Thunder issues a Layer 7 health check (HTTP GET URI “/index.html”)requesting
content from the server. Finally, the server replies with a HTTP 200 OK response code.

Global Health Monitor Parameters
 By default, the Thunder issues a HC every 5 seconds. If the health check fails, the Thunder will try three more
times (15 sec). On the fourth try, or after 20 secs, the Thunder marks the server as “down”. At this point the
Thunder will continue to issue HC at 5 sec interval, until the server responses properly.
 The default timeout, intervals, and retries can be changed locally or globally.
 Globally changing the parameters do not affect existing health monitors until the Thunder is rebooted. Global
parameters take affect when new health monitors are configured.
 Example:
Thunder3200-12(config)#health global interval 2 retry 1 timeout 2 up-retry 2 (custom)
Thunder3200-12(config)#health global interval 5 retry 3 timeout 5 up-retry 1 (default)
Note: Be careful when changing these variables. You don’t want to be too aggressive nor too slow in flagging
the servers as “Up or Down”…

Local Health Monitor Parameters
 The example below applies the same changes in the interval, retry, and
timeout. However, it is applied locally under the real server.
health monitor http_hc interval 2 retry 1 timeout 2

method http url GET /index.html expect 200
slb server web-50 20.20.101.50

port 80 tcp
health-check http_hc

Disabling Health Checks
Health checks may be disabled upon business or network requirement.

–Firewalls
–For very large deployments
–Disable HC for troubleshooting purposes
Issue the command “no health-check” at server level to disable ICMP HC and at port level
to disable port level HC.
slb server s2 30.30.30.102 slb server s1 10.1.1.11
no health-check health-check-disable
port 80 tcp port 80 tcp
no health-check health-check-disable
QUESTION: what if we issue “no health-check” at both server and port level. Does Thunder
stop doing health check? If yes why? If no why?

Compound Health Checks
 Certain applications have dependencies with each other.

 Applications are running on different ports and require to be taken out of rotation if one of them
should fail.
 Compound health checks provide the ability of taking down one application port
 Compound health monitor must have an interval longer than the sub-monitors interval time times
retry
 See the example configuration below:
health monitor tcp_9480
override-port 9480
method tcp port 9480
health monitor tcp_9400

override-port 9400
method tcp port 9400
health monitor tcp_9480_9400

method compound sub tcp_9480 sub tcp_9400 and
slb service-group sg2 tcp

health-check tcp_9480_9400
member s3:9480

 Compound health checks being executed on port 9480 and 9400.

 If the server stops listening on one of the ports, the Thunder will bring down both ports.

 Thunder#show health stat
 IP address Port Health monitor Status Cause(Up/Down) Retry PIN
 --------------------------------------------------------------------------------
 30.30.30.103 9480 tcp_9480_9400 DOWN 25 /92 @1 0 0 /0 0
 Thunder#devcall hm_down_reason(92)
 Compound Down
 Thunder#show slb service-group
 Total Number of Service Groups configured: 2
 Current = Current Connections, Total = Total Connections
 Fwd-p = Forward packets, Rev-p = Reverse packets
 Peak-c = Peak connections
 Service Group Name
 Service Current Total Fwd-p Rev-p Peak-c
 -----------------------------------------------------------------------------------------------
 *sg2 State: Down
 s3:9480 0 0 0 0 0

 Thunder#show health stat
 IP address Port Health monitor Status Cause(Up/Down) Retry PIN
 --------------------------------------------------------------------------------
 30.30.30.103 9480 tcp_9480_9400 DOWN 25 /92 @1 0 0 /0 0
 Thunder#devcall hm_down_reason(92)
 Compound Down
 Thunder#show slb service-group
 Total Number of Service Groups configured: 2
 Current = Current Connections, Total = Total Connections
 Fwd-p = Forward packets, Rev-p = Reverse packets
 Peak-c = Peak connections
 Service Group Name
 Service Current Total Fwd-p Rev-p Peak-c
 -----------------------------------------------------------------------------------------------
 *sg2 State: Down
 s3:9480 0 0 0 0 0

GSLB – Global Server Load
Balancing
Global Server Load Balancing (GSLB)
Key Thunder GSLB
benefits
 Provides data center failover and
continuity
 Optimizes multi-site deployments
 Ensures users' Web experience is

the fastest
DNS Proxy Technology

 Continue to use existing DNS infrastructure without changing DNS server
configuration
 No need to create or delegate sub domains, existing DNS maintains control

Types of Global Server Load Balancing
 DNS-Based GSLB
–Global Server Load Balancing enables Thunder devices to add intelligence to authoritative
Domain Name System (DNS) servers
–The GSLB controller evaluates the DNS replies, and based on the results of that evaluation it
directs traffic to the ‘best’ site by replacing the IP address in the DNS reply
 IP-Based Route Health Injection (RHI)
–Routing based global server load balancing
–RHI allows the Thunder devices to advertise the availability of a VIP throughout the network
–Inject static route for VIP and redistribute using routing protocols such as RIP, OSPF, IS-IS, BGP,
RIPng, OSPFv3, IS-ISv6, BGP4+
–Typical topology includes primary and backup site, with backup monitoring primary’s
health, and inject VIP route in case of primary failure
–Also supports ‘IP Anycast’

DNS-based GSLB Overview
 DNS-based GSLB uses Domain Name Service (DNS) technology to extend

load balancing to a global scale
 Provides dynamic and flexible policies for selecting fairness and
distribution to multiple sites
 Operates in two main modes
–Proxy mode – The Thunder device acts as a proxy for an external DNS server. In proxy mode,
the Thunder device can update the A and AAAA records in its response to client requests,
but it forwards requests for all other record types to the external DNS server.
–Server mode – The Thunder device directly responds to queries for specific service IP
addresses in the GSLB zone. In server mode, the Thunder device can reply with A, AAAA,
MX, NS, PTR, SRV and SOA records. For all other records, the Thunder device will attempt
proxy mode unless configured as fully authoritative.

GSLB Controller as Authoritative DNS
GSLB Proxy-Mode Using Existing DNS
Authoritative DNS Servers Domain: a10networks.com
Service: Web (http)
Thunder acts as Host: www
the Authoritative DNS A-Records: VIP-West, VIP-East
DNS
DNS Query DNS Query

2 GSLB Controller 2
LDNS #1 LDNS #2
3 3
DNS Reply DNS Reply
DNS Query 1 4 DNS Reply DNS Query 1 4 DNS Reply

Internet / Intranet
5 5 Client-2
Client-1 Connect to Connect to
VIP-West
VIP-East VIP West VIP East VIP-West
VIP-East
DNS Reply IP List: VIP-West,

VIP-East, VIP-West
VIP-East VIP-East, VIP-West
DNS Reply IP List: VIP-West, VIP-East
SLB West SLB East
Web Web
Servers Servers
DC West - Active DC East - DR

DNS-based GSLB: Proxy Mode
 Advantages:
–Can be implemented without impacting current DNS traffic
–Does not require change in DNS server IP address
–Customer can be using external DNS service
 Disadvantages:
–Requires changes to DNS server configuration
 Add Sub-domain to existing DNS for Thunder
 Add Thunder “proxy ip” as NS records
 Add Thunder “proxy ip” as A records
 CNAME existing records to sub-domain
–Requires second DNS request by client

DNS-based GSLB: Server Mode (Authoritative)
 Advantages:
–Does not require changes to current DNS server configuration
–Single client request for DR services
–Can be implemented with DNS firewall, and provide SLB services to DNS servers
 Disadvantages:
–Requires changes to DNS server IP address, or change in registered NS server IP
address
–Can not be implemented without downtime
–Customer has to own and run their own DNS servers

GSLB Components
 Controller  Sites
– Receives client DNS requests, maintains GSLB – A server farm that is locally managed by an
configuration and health status among site Thunder device that performs Server Load
devices. Can have multiple controllers for Balancing for the site
redundancy
 Services
 Policy – An application such as HTTP or FTP. Each zone
– A series of configurable parameters which are can be configured with one or more services.
evaluated against a client request in order to “www.example.com” is a service where “www”
select the “best” site to send the request to is the http service or an application in the
“example.com” zone
 Zones
– A DNS domain for GSLB. A device can be
 Service IP
configured with one or more GSLB zones. Each – The virtual servers defined under service-ip are
zone can contain one or more GSLB sites. used for GSLB
“example.com” is a domain.

GSLB Server Mode Configuration
 Configure SLB (if not already configured)

 Create DNS Server VIP
 Configure Service IPs for VIPs
 Create (or modify existing Default) GSLB Policy
 Create Sites, add SLB Devices and VIPs for the Site
 Create Zone and configure service
 Enable the GSLB protocol for site device function (Controller or Device)
Note – To configure Proxy mode, follow standard SLB procedures (Servers, Service Groups, VIP, etc.) that utilize “external” DNS
servers and enable it for GSLB when configuring the virtual port
Note 2 – GSLB Policies will be covered in another module

GSLB Protocol
 Uses TCP port 4149

–Thunder devices use the GSLB protocol for GSLB management traffic (between GSLB
controller and sites)
 The GSLB controller collects following information from the site Thunder ADCs
–Virtual IP addresses & active servers
–aRDT (active-Round Delay Time)
–Site session capacity statistics
–Connection load
–Number of active sessions
 Default Update interval is 30 seconds (ranges from 1 to 300 seconds)
–VIP information is sent asynchronously

GSLB Metrics
 Server Health
 Services that pass health checks are preferred
 Weighted IP
 Service IP addresses with higher weights are used more often than
service IP addresses with lower weights
 Weighted Site
 Sites with higher weights are used more often than sites with lower
weights
 Session Capacity
 Sites with more available sessions based on respective
mThunderimum session capacity are preferred
 Active Servers
 Sites with most currently active (i.e. healthy) servers are preferred
** Dynamic Metric – requires GSLB protocol

GSLB Metrics (cont)
 Active-Round Delay Time (aRDT)
 Sites with faster round-delay-times for DNS queries and replies
between a site Thunder and the GSLB local DNS are preferred
 Geographic
 Services located within the client’s geographic region are preferred.
Also can be used for IP affinity.
 Connection-Load
 Sites not exceeding their thresholds for new connections are
preferred
 Num-Session
 Sites that are not exceeding available Session-Capacity threshold
compared to other sites are treated as having the same preference
 Admin-Preference
 Site with highest administratively set preference is selected

GSLB Metrics (cont)
 Bandwidth-Cost
 Selects sites based on bandwidth utilization on the site Thunder links
 Least-Response
 Service IP addresses with the fewest hits are preferred
 Admin-IP
 Site IP address is preferred based on administratively assigned weight
 Alias-Admin-Preference
 Selects the DNS CNAME record with the highest set preference
 Weighted-Alias
 Prefers CNAME records with higher weight values over CNAME
records with lower weights. Similar to Weighted-IP, but applies only to
CNAME
 Round-Robin

Competitive Overview vs F5
Business and Sales Oriented Factors
 A10 key advantages
–Support
–Far superior “bang for the buck”
–Persistent, straightforward business model
–Transparent and open sales approach
–Simplified Cisco ACE migration
–Better scalability
–Synergistic product offerings

Customer Satisfaction
Features 95%
“ How would you rate your

Performance/Scalability 96%
Thunder Series on the
following capabilities when Usability/Deployment Speed 93%
compared to competitive “ Reliability 93%
products?
Quality of Support 92%
Superior/ Much Better/ Better Same Not as Good
CUSTOMERS WERE ASKED:

Source: TechValidate

Competitive Takeout
Cisco 34%
Which of the following
F5 Networks 33%
“ Brocade 9%
vendors/solutions did HAProxy 9%
Citrix Systems (Netscaler) 6%
you replace with “ KEMP Technologies 6%
Thunder Series products? NGINX 6%
Radware 6%
Barracuda Networks 6%
Coyote Point Systems 2%
Riverbed Technology 2%
CUSTOMERS WERE ASKED:
Other 16%

85% of Organizations
Are Likely to Recommend
A10 Thunder Series

Scalability
 F5 claims ‘On Demand Scaling’, in reality very limited scaling
–Higher-end ‘s’ platforms (4000s, 5000s, etc.) may be upgraded to ‘v’ versions
 Upgrade only available within same platform.
–iSeries models upgradable within a given series (i.e., i7600 to i7800)
–VIPRION scaling requires buying and installing another blade (if chassis slot open)
 New blades obsolete existing blades – no mix and match
 A10 offers mThunderimum performance on given models

–No costly upgrades and associated penalties
–Clustering aVCS licenses are included to enable over 1 Tbps of capacity
–Virtual chassis deployments much simpler to install than new blades

Architectural and Design Oriented Factors
 A10 key architectural advantages
 Optimized ACOS architecture: Shared Memory, SSMP
 Unlimited concurrent module use
 Innovative hardware design
 Highest density multi-tenant offerings
 Easy to deploy small form factor appliances
 Simplified clustering without chassis-based limits

Architectural: F5 Computing and Memory Design
 F5 based on TMOS initiated in 1999 F5 TMOS
–Code not originally designed for 64-bit multicore CPUs Communication Bus
 F5 concurrent sessions drop by 25% when moved to 64-bit

 Use of iRules can cause a ~15% reduction in performance
–CPU and distributed memory highly inefficient
 IPC results in bus scheduling, interrupts and locking overhead L4-7
CPU 1
L4-7
CPU 2
L4-7
CPU 3
L4-7
CPU 4
L4-7
CPU 5
 Distributed memory aggravates IPC overhead and duplicates
memory
–Session tables limited to 20M
 VIP required for every route
 Increases use of session tables
 Impacts service providers’ default router
–Non traditional Proxy-based routing

Architectural: A10 Computing and Memory Design
 A10 uses shared memory and eliminates IPC A10 ACOS

–Results in numerous benefits in capacity, scalability
High-speed
–For comparable resource levels, A10 performs much better Shared Memory
–True dynamic routing
L4-7 L4-7 L4-7 L4-7 L4-7

CPU 1 CPU 2 CPU 3 CPU 4 CPU 5

Product and Feature Oriented Factors
 A10 Key advantages:

–Lightning ADS ADC-as-a-Service
–Rapidly expanding set of functionality
–First to market with key features, for example
 SSL Intercept*
 DNS Application Firewall
 CGNAT**
 NAT64/DNS64**
 DDoS protection in hardware (FTA/FPGA)
–ADPs superior to ‘route domain’ deployments

–Ease of installation and configuration

A10 Advantages Summary
A10 F5
Highest performance and lowest cost solutions with all-inclusive license
Capable of running any/all modules simultaneously with no feature limits
Unsurpassed multi-tenancy support: Up to 100x F5’s partition density
Most extensible, robust and scalable architectural design with ACOS
Broadest support for Cloud Services: ADCaaS, multi-cloud controller, IaaS
Highest scalable software based appliances: vThunder and Bare Metal
Easiest Cisco ACE migration: Similar CLIs and converting contexts to ADPs
Simplest management interface and reporting tools
100 percent programmable features with REST-based ThunderAPIs
Smallest footprint with lowest power and cooling
Synergistic license offerings: ADC, CGN, TPS, CFW, SSLi

AppCentric Templates (ACT)
AppCentric Templates (ACT)
● A10 ACOS GUI Plug-in Module

● Enhancing User Experience to
– Deploy, Monitor, and Troubleshoot Applications in a Frictionless manner
Benefits Full Cycle of Ops Use-case Driven Agile
• Quick • Configuration • Embedded Best • Continuous

Practices Update and
• Easy • Monitoring
Release
• Insightful • Troubleshooting

AppCentric Templates – Key Components
In-service, hitless
App Specific Template upgrade of Templates
Dashboard Wizard Configuration Troubleshooting
Real-time Insights Quick and easy Customized Instant

deployment with deployment with troubleshooting
visual information embedded best by point-n-click
practices and
contextual help

AppCentric Templates – Key Components
Quick and easy Customized

deployment with Wizard Config deployment
visual information
ACT
Automated
and
Real-time Insights Dashboard Troubleshooting Point-and-click

Available ACTs and Key Features
● 9 ACTs
– L4 SLB, HTTPS, Exchange, SharePoint, WIA
– SSLi, Security, IPsec
– Dashboard Wizard
● Fully Customizable Dashboard with Point-n-Click

● Ease of Updating ACT from Cloud
* To access ACT, navigate to System – App Templates on ACOS GUI

Exchange

Dashboard Wizard - Fully Customizable Dashboard
API Navigation

Ease of Updating ACT from Cloud
From Cloud

How ACT is Different from Competitors’ Offerings
● Flow-based, Interactive Wizard for Quick Configuration

– Vs. Questionnaire
● Embedded Best Practices

– Fool-proof security and application policy, e.g., A+ SSL rating out of box
● Tied into Dashboard Crafted for a Target Application

● Problem Solving Tool
– Application specific troubleshooting tool, e.g. SSL inspection
● Abstracted Configuration menu to allow for easy changes

– Initial configuration done with Wizard and subsequent changes done with
abstracted configuration menu
● Embracing Cloud for More Ease-of-Use and Agility

– Some intelligence comes from cloud, e.g., ACT update

Resources
● ACT Download if your version is not cloud ready

– Download the ACT file from:
 https://docs.google.com/forms/d/10VOcTff-QwIg6Al9AK-VAVb0rgcSTNBnRFZLFjeX1UQ/edit
– Navigate to System – AppTemplate Import

 Ensure the ACOS clock is set correctly.
● E-mail Alias for Questions, Issues, and Feedback

– app-template@a10networks.com
● Demo Videos
– https://a10.sharefile.com/d-s3f50f93cdf54e6fa

ADC Training Aug23

Uploaded by

Copyright:

Available Formats

ADC Training Aug23

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADC Training Aug23

Uploaded by

Copyright:

Available Formats

A10 ADC

Confidential | ©A10 Networks, Inc.

 An ADC is a networking device that intelligently performs the task of delivering

Confidential | ©A10 Networks, Inc. 3

 The A10 ADC can perform advanced switching (L2 functions)

 The A10 ADC can perform advanced routing (L3 functions)

Confidential | ©A10 Networks, Inc. 4

Confidential | ©A10 Networks, Inc. 5

Confidential | ©A10 Networks, Inc. 6

 Server Load Balancing Decisions are based on the following algorithms:

Confidential | ©A10 Networks, Inc. 7

Confidential | ©A10 Networks, Inc. 8

performed for client-VIP SLB traffic.

sending the reply to the client, the

Confidential | ©A10 Networks, Inc. 9

 SLB source NAT is disabled by default

Confidential | ©A10 Networks, Inc. 10

Server IP: 20.20.20.154

Confidential | ©A10 Networks, Inc. 11

 With Pool Group configuration  Source-NAT Auto configuration

ip nat pool p2 40.40.40.200 40.40.40.200 netmask /32 port 80 tcp

ip nat pool-group nat-group

Confidential | ©A10 Networks, Inc. 12

Confidential | ©A10 Networks, Inc. 14

Confidential | ©A10 Networks, Inc. 15

Confidential | ©A10 Networks, Inc. 16

 NON-FTA: no FPGA and no ASIC present.

 Hybrid: No switching ASIC, FPGA present

Confidential | ©A10 Networks, Inc. 17

CPU Non-FTA System:

Why memory usage is so high on a system with empty

Because ACOS pre-allocates memory for some

The allocation is based on platform (RAM size) and start-

Mostly, session table takes away high percentage of

Confidential | ©A10 Networks, Inc. 20

Thunder 6630 (100GbE)

5 Gbps 30 Gbps 40 Gbps Throughput 100 Gbps 220 Gbps

Confidential | ©A10 Networks, Inc. 22

All inclusive licensing

40 Gbps Throughput 155 Gbps

Thunder 3530S HVA

Thunder 3030S HVA

Hybrid Virtual Appliance (HVA):

35 Gbps Throughput 100 Gbps

Confidential | ©A10 Networks, Inc. 24

Rent (RBM) Utility (UBM)

License per Month License per Byte

vThunder for AWS or Azure vThunder Pay-as-You-Go Licensing

Confidential | ©A10 Networks, Inc. 26

 Switch Mode or Transparent Mode

Confidential | ©A10 Networks, Inc. 28

 ACOS behaves as layer 2 switch

gateway router and real servers Router: 20.20.101.1

 Real servers and ACOS both use the Packet Flow:

router as their default gateway

destination with server IP address in

Confidential | ©A10 Networks, Inc. 29

 In-line Topology Switch Mode

 In-line Physical Topology

Confidential | ©A10 Networks, Inc. 30