Configuring Traffic Diversion

If a fault occurs, the new business master device takes over traffic. The original upstream and downstream traffic also needs to be switched to the new master device.

Context

Traffic diversion plans vary with networking:

For connections to Layer-2 devices, use VRRP-based traffic diversion. A business group is bound to a VRRP group. If the business group is in the Master state, the VRRP state is Master. If the business master device's interface fails, the business group status changes. Then, the VRRP status changes accordingly, and traffic is diverted to another device.
For connections to Layer-3 devices, service traffic diversion or route-based traffic diversion is used.
- In a service traffic diversion scenario, you need to configure a traffic diversion address in the business group. The traffic diversion address indicates the device's UNR that needs to be advertised. After the address is configured, the cluster advertises the route regarding the traffic diversion address for traffic diversion of upstream and downstream services.
- In a route-based traffic diversion scenario, you need to associate a routing protocol with the business group. After that, the cost of the OSPF route advertised by the device is affected by its status in the business group. Traffic related to the business group is preferentially sent to the business master device for the purpose of upstream and downstream traffic diversion.
Currently, OSPF, IS-IS, and BGP support route-based traffic diversion. The following services require UNRs: NAT address pools and source addresses of outer IPSec tunnels (the addresses are used to divert packets to devices for IPSec).

Currently, business groups can be associated only with OSPF processes. Therefore, route-based traffic diversion applies only to OSPF networks.

You should configure route-based and service traffic diversion on the management master device. The configuration will be automatically synchronized to other members in the cluster. For VRRP-based traffic diversion, configure it on each member device in a business group.

Procedure

VRRP-based traffic diversion
1. Access the service interface view from the system view.
```
interface interface-type interface-number
```
  The interfaces that support VRRP groups include Layer-3 Ethernet interfaces and their subinterfaces, Layer-3 Eth-Trunk interfaces, and VLANIF interfaces.
2. Configure a VRRP group.
```
vrrp vrid virtual-router-id virtual-ip virtual-address [ ip-mask | ip-mask-length ] { active | standby }
```
  active/standby can be any value, which does not affect the cluster configuration.
3. Configure synchronous status switching between the VRRP group and business group.
```
vrrp vrid virtual-router-id track business-group business-group-id
```

Service traffic diversion

Access the business group view from the system view.
```
business-group business-group-id
```

Configure traffic diversion addresses for the business group.

ip-section [ section-id ] start-address [ end-address ] [ source-vsys vsys-name ] [ destination-vsys vsys-name ]

In the OSPF, BGP, or IS-IS routing protocol view, import UNRs and implement routing policies.

import-route unr route-policy cluster_rt

After the cluster function is enabled, the system automatically generates a routing policy named cluster_rt. The routing policy configuration is as follows:

#
route-policy cluster_rt permit node 0
 if-match preference 57
 apply cost + 1
#
route-policy cluster_rt permit node 1
 if-match preference 58
 apply cost + 5
#
route-policy cluster_rt permit node 2
 if-match preference 59
 apply cost + 10
#

Configure route-based traffic diversion.
1. Optional: In the system view, run the cluster adjust{ ospf-cost | bgp-cost } add add-cost command to configure a step for the business group to adjust the route cost.
  The default route cost step is 1000.
2. Run the business-group business-group-id command to access the business group view.
3. Associate the business group with the routing protocol.
  - Associate the business group with the OSPF process: bind ospf process-id
  - Associate the business group with the BGP peer: bind bgp peer peer-ip [ vpn-instance vpn-instance-name ]
    
    The configuration of this command cannot be backed up in a cluster. Therefore, you need to configure this command in each cluster member.
    
    When BGP routes are imported to OSPF, the imported BGP routes may not take effect because the default preference of BGP routes is lower than that of OSPF routes. To enable the imported BGP routes to take effect, run the preference command to increase the preference of BGP routes.
  - Associate the business group with the routing policy: bind route-policy route-policy-name match rank rank & <1-8>
    
    This command controls whether a routing policy takes effect. For example, in a scenario where you run the bind route-policy test match rank 1 command in business group 1, if the device ranks the first in the business group, routing policy test takes effect; if the device does not rank the first in the business group, routing policy test does not take effect.
    
    In a DCN east-west traffic protection scenario, to ensure that the eastbound and westbound traffic is transmitted along the same path, you need to run this command to enable only the master device to advertise routes.