IPv4 Unicast Service Forwarding Control

When a link fails, the NetEngine 8000 F needs to refresh the MAC forwarding table of the connected LSW to correctly forward the user traffic. In addition, routes must be controlled to ensure that the network-side traffic can properly reach users. For single-BRAS services, downstream traffic is transmitted through address pool route advertisement. Address pool routes must be specially processed to ensure that downstream traffic can be correctly forwarded to users.

The NetEngine 8000 F supports downstream traffic control in either of the following modes:

Unshared Address Pool Mode

The NetEngine 8000 F controls downstream traffic by withdrawing and advertising address pool routes. As shown in Figure 1, Device1 is the master device, Device2 is the backup device, Device1 advertises an address pool route to the Device, and Device2 withdraws the address pool route. In this case, traffic sent from the Device to the PC can be correctly forwarded through Device1.

After a master/backup switchover, Device1 becomes the standby device, and Device2 becomes the active device. Device1 withdraws the address pool route, and Device2 advertises the address pool route. In this case, traffic sent from the Device to the PC can be correctly forwarded through Device2.

No matter whether the master/backup switchover is caused by a link failure or device fault, ensure that the master device is not the faulty node. The route control is based on the master/backup status. You can control the address pool route to ensure that the traffic from the Device to the PC can be correctly forwarded.

Figure 1 Traffic control based on unshared address pool routes

Shared Address Pool Mode

The NetEngine 8000 F uses technologies such as LSP, MPLS TE, GRE, and IP redirect to control downstream traffic. As shown in Figure 2, Device1 is the master device, Device2 is the backup device, Device1 advertises an address pool route to the Device, and Device2 advertises the address pool route to the Device. However, the route priority is lower than the priority of the route advertised by Device1. In this case, the Device has two routes destined for the PC. Because the two routes have different priorities, the traffic is sent to the PC through Device1.

After a master/backup switchover, Device1 and Device2 do not need to process the address pool route. Therefore, the traffic sent from the Device to the PC is still sent to Device1. However, Device1 is in the backup state and forwards the traffic to Device2 through a tunnel, instead of directly forwarding the traffic to the PC. After receiving the traffic, Device2 directly forwards the traffic to the PC.

Figure 2 Traffic control based on shared address pool routes

In dual-device hot backup scenarios, traffic from the network side to the user side can be forwarded through an SRv6 protection tunnel. The basic process of traffic recursion to a protection tunnel in dual-device hot backup scenarios is as follows: Configure an SRv6 protection tunnel on a non-VSU board, subscribe to the tunnel ID, and deliver traffic to the underlying table based on the forwarding-plane tunnel policy index. If traffic needs to enter the protection tunnel, it is diverted to an SRv6 tunnel and then to a service board through a VSU and finally forwarded through SRv6.