Configure Fast Convergence
SUMMARY This topic describes Fast Convergence in Juniper® Cloud-Native Contrail Networking (CN2) Release 23.2 and later in a Kubernetes-orchestrated environment.
What Is Convergence
Convergence or routing convergence is a state in which a set of routers share the same topological information. The routers collect the topology information through the routing protocol. Convergence happens when routers send this information to all routers in the network. Any change in the network (link failure, router failure, or change in the topology) affects convergence until the change is propagated to all routers in the network and convergence occurs again. The time taken by the routers in the network to reach convergence after a change is referred to as "convergence time".
Network convergence and fast failover are critical for high performance service provider networks that run sensitive applications. The speed of achieving convergence in a network depends on the following actions:
-
Detection—A device detects a failure in the route. Corrective action, such as identifying a new forwarding path, is taken only after the identifying the device that failed.
In a virtual network, device reachability is established through keepalive messages. To achieve fast convergence, the detection time (the time it takes to detect a failure) is of high importance so you must keep the be kept within the acceptable limits.
-
Local Repair—As soon as a device failure is detected in the primary route, traffic is diverted to the backup route. When this occurs, the failure or change in topology, is not propagated to all the devices in the network.
-
Global Repair—Global repair (or network convergence) happens when the change in topology is propagated to all devices in the network though the routing protocols.
The availability of services depends on the time it takes to detect and correct any failures.
Fast Convergence in a Network Managed by CN2
CN2 provides an SDN solution that offers network virtualization at the compute node-level through overlay networking. In an SDN, failures can occur in the overlay or in the underlay. A failure in the overlay can be caused by a failed virtual machine or a failed pod. The vRouter detects, rectifies, and propagates any failure to the gateways by using health checks. Of the several possible types of failure in the underlay, the most critical failures are the SDN gateway and compute node failures.
Fast convergence improves the convergence time in case of failures in a cluster managed by CN2. In a typical Cloud-Native Contrail network, the customer endpoints connect to the vRouter through MPLSoUDP, GRE, or VXLAN overlay tunnels from the gateway device. The vRouters connect to the MPLS gateway through the fabric endpoints.
With fabric underlay routing, most fabric underlay failures such as those in the leaf or spine, can be addressed quickly without impacting the flow of traffic. However, two types of failures can lead to silent packet drop failures in the vRouter and failures in the gateway device. These failures are referred to as tunnel endpoint failures.
The control node maintains the overlay tunnels, which exchanges routes between the tunnel endpoints. The control node uses BGP to exchange routes with the gateway devices and XMPP to exchange routes with the vRouter. Because no keepalive messages are running on the overlay tunnels, the control node depends on the BGP hold time expiration to diagnose failures in northbound connectivity to the gateway, and on the XMPP timeout for failures for southbound connectivity to the vRouter. Any gateway failure in the gateway can lead to a silent packet drop for up to 90 seconds (the default value for BGP hold time and expiration). This is because the control node detects the gateway failure only after the BGP hold time expires. Similarly, a failure in the vRouter can lead to a silent packet drop for up to 15 seconds (default value for XMPP timeout).
Example Scenarios
Figure 1 shows what happens when the gateway router fails. In this example, the BGP hold time expires after 90 seconds as the destination is unreachable. This same hold time is propagated to the control node, which recognizes that the gateway router has failed. This scenario leads to a silent packet drop for 90 seconds until the routing table in the control node updates and convergence happens.
Figure 2 shows a scenario where the vRouter fails. In this example, the control node recognizes the vRouter failure only after 15 seconds when the XMPP hold time expires. Traffic is dropped during these 15 seconds until convergence happens.
Fast convergence reduces the convergence time if an overlay endpoint fails. The Contrail control plane responds to the changes in the underlay network and quickly reduces the convergence time. Typically, the spines learn of tunnel endpoint failures through BFD or from link down protocols. With fast convergence, the spine propagates failure information to the Contrail controller and removes the tunnel endpoint from the control node through a routing table update. The control node then recognizes this as a tunnel endpoint failure and initiates routing convergence.
-
To achieve fast convergence if a gateway fails (northbound failure), the control node performs a next-hop reachability check. If a failure is detected, the control plane then initiates convergence.
-
To achieve fast convergence if the vRouter fails (southbound failure), you must configure the XMPP hold time. The default hold time is 90 seconds, although the recommend timeout value is 9 seconds. A lower value (less than 9 seconds) is recommended only for smaller clusters. Whenever the XMPP hold time expires, the control node recognizes the failure and initiates convergence.
Figure 3 shows how CN2 achieves fast convergence. Fast convergence is achieved by using the destination reachability information the spine gathers through the BFD or Linkdown protocols, and by using the XMPP timeout information sent to the control node to detect a failure in the vRouter.
Configure Fast Convergence
By default, fast convergence is not enabled. To configure this feature, edit the
global-system-config
spec using the following command:
kubectl edit gsc default-global-system-config
To enable fast convergence:
Add the fastConvergenceParameters
attribute under the
spec
field and set enable
to
true
.
Alternatively, you can configure the following parameters:
-
xmppHoldTime
— XMPP hold time is used to detect vRouter failures. The timer expires when a vRouter fails. When the hold time is up, the control node again initiates convergence.By default, the XMPP hold time is 90 seconds. You can enter a value in the range 1—90 seconds. The recommend timeout value is 9 seconds. A lower value (less than 9 seconds) is recommended only for smaller clusters.
-
nhReachabilityCheck
—Next-hop reachability determines the next-hop IP address for forwarding packets to a specific destination. To check next-hop reachability for the gateway and vRouter, setnhReachabilityCheck
totrue
.
The following is an example of a fast convergence configuration:
apiVersion: v1 items: - apiVersion: core.contrail.juniper.net/v4 kind: GlobalSystemConfig metadata: creationTimestamp: "2023-05-02T01:06:46Z" generation: 8 labels: back-reference.core.juniper.net/e7868747b69fb26facc616309440afd4b538819946ee7b838dcc9632: BGPRouter_contrail_5a11s30 name: default-global-system-config resourceVersion: "4361491" uid: ad026e2c-1b9a-4bd7-b395-f90b92437a7f spec: autonomousSystem: 64512 bgpRouterReferences: - apiVersion: core.contrail.juniper.net/v2 fqName: - default-domain - contrail - ip-fabric - default - 5a11s30 kind: BGPRouter name: 5a11s30 namespace: contrail uid: ac6d821c-bbd3-4973-bf26-a918cd664f82 enable4bytesAS: false fastConvergenceParameters: enable: true nhReachabilityCheck: true xmppHoldTime: 9 fqName: - default-global-system-config ibgpAutoMesh: true status: observation: "" state: Success kind: List metadata: resourceVersion: ""