Configuring Control Plane and Data Plane High Availability Parameters
This article discusses the configurable high availability parameters for the control plane and the data plane.
Control Plane High Availability
A highly available Viptela network contains two or more vSmart controllers in each domain. A Viptela domain can have up to 20 vSmart controllers, and each vEdge router, by default, connects to two of them. You change this value on a per-tunnel basis:
vEdge(config-tunnel-interface)# max-control-connections number
When the number of vSmart controllers in a domain is greater than the maximum number of controllers that a domain's vEdge routers are allowed to connect to, the Viptela software load-balances the connections among the available vSmart controllers.
To maximize the efficiency of the load-balancing among vSmart controllers, use sequential numbers when assigning system IP addresses to the vEdge routers in the domain. One example of a sequential numbering schemes is 172.1.1.1, 172.1.1.2, 172.1.1.3, and so forth. Another is 172.1.1.1, 172.1.2.1, 172.1.3.1, and so forth.
Data Plane High Availability
BFD, which detects link failures as part of the Viptela high availability solution, is enabled by default on all Viptela devices. BFD runs automatically on all IPsec data tunnels between vEdge routers. It does not run on the control plane (DTLS or TLS) tunnels that vSmart controllers establish with all Viptela devices in the network.
You can modify the BFD Hello packet interval and the number of missed Hello packets (the BFD interval multiplier) before BFD declares that a link has failed.
Change the BFD Hello Packet Interval
BFD sends Hello packets periodically to detect faults on the IPsec data tunnel between two vEdge routers. By default, BFD sends these packets every 1000 milliseconds (that is, once per second). To change this interval on one or more traffic flow, use the hello-interval command:
vEdge(config)# bfd color color hello-interval milliseconds
The interval can be a value from 100 to 300000 milliseconds (5 minutes).
You configure the interval for each tunnel connection, which is identified by a color. The color can be 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, private1, private2, public-internet, red, or silver.
Change the BFD Packet Interval Multiplier
After BFD has not received a certain number of Hello packets on a link, it declares that the link has failed. This number of packets is a multiplier of the Hello packet interval time. By default, the multiplier is 7 for hardware vEdge routers and 20 for vEdge Cloud software routers. This means that if BFD has not received a Hello packet after 7 seconds, it considers that the link has failed and implements its redundancy plan.
To change the BFD packet interval multiplier, use the multiplier command:
vEdge(config)# bfd color color multiplier integer
The multiplier can be an integer from 1 to 60.
You configure the multiplier for each tunnel connection, which is represented by a color.
Control PMTU Discovery
On each transport connection (that is, for each TLOC, or color), the Viptela BFD software performs path MTU (PMTU) discovery, which automatically negotiates the MTU size in an effort to minimize or eliminate packet fragmentation on the connection. BFD PMTU discovery is enabled by default, and it is recommended that you use BFD PMTU discovery and not disable it. To explicitly enable it:
vEdge(config)# bfd color color pmtu-discovery
With PMTU discovery enabled, the path MTU for the tunnel connection is checked periodically, about once per minute, and it is updated dynamically. With PMTU discovery enabled, 16 bytes might be required by PMTU discovery, so the effective tunnel MTU might be as low as 1452 bytes. From an encapsulation point of view, the default IP MTU for GRE is 1468 bytes, and for IPsec it is 1442 bytes because of the larger overhead. Enabling PMTU discovery adds to the overhead of the BFD packets that are sent between the vEdge routers, but does not add any overhead to normal data traffic.
If PMTU discovery is disabled, the expected tunnel MTU is 1472 bytes (tunnel MTU of 1500 bytes less 4 bytes for the GRE header, 20 bytes for the outer IP header, and 4 bytes for the MPLS header). However, the effective tunnel MTU might be 1468 bytes, because the software might sometimes erroneously add 4 bytes to the header.