Configuring conversion from BGP IPv4 Unicast Routes to Labeled Routes

Configuring conversion from BGP IPv4 unicast routes to labeled routes can ensure that traffic is forwarded along a specified LSP.

Usage Scenario

On the network shown in Figure 1, an IBGP peer relationship and an MPLS LSP are established between the user device and DeviceA. It is required that traffic from DeviceB to the user device be forwarded along the MPLS LSP.

To meet this requirement, DeviceA and DeviceB need to be enabled to send or receive labeled routes, and DeviceA needs to be enabled to convert BGP IPv4 unicast routes to labeled routes and allocate MPLS labels using a route-policy. Then, DeviceA can convert the IPv4 public network unicast route (1.1.1.0/24 in this example) learned from the user device to a labeled route and advertise the labeled route to DeviceB. After traffic from DeviceB reaches DeviceA, DeviceA performs the POPGO action. Specifically, DeviceA removes the BGP label, adds an LSP label, and forwards the traffic to the user device along the MPLS LSP.

Figure 1 Networking for configuring conversion from BGP IPv4 unicast routes to labeled routes

Procedure

Perform the following operations on the labeled route sender (DeviceA):
1. Run system-view
  The system view is displayed.
2. Run route-policy route-policy-name permit node node
  A route-policy is created.
3. Run apply mpls-label
  DeviceA is enabled to assign a label to each IPv4 unicast route.
4. Run quit
  Return to the system view.
5. Run bgp as-number
  The BGP view is displayed.
6. Run peer { group-name | ipv4-address } label-route-capability [ check-tunnel-reachable ]
  The device is enabled to exchange labeled routes with a specified peer or peer group.
  
  To prevent a traffic loop, it is recommended that check-tunnel-reachable be specified to allow the device to check tunnel reachability when imported routes are advertised as labeled routes.
  
  Figure 2 shows the networking diagram for a traffic loop. If check-tunnel-reachable is not specified, DeviceA converts the routes learned from the user side into labeled routes and advertises them to DeviceB, regardless of whether the tunnel is reachable. Traffic from DeviceB is forwarded based on the BGP label. When the traffic reaches DeviceA, the BGP label is removed. If the tunnel is unreachable, the traffic recurses to a specific outbound interface and next hop through IP forwarding. In this case, if a route that DeviceA learns from another device is more specific than that learned from the user side, traffic will be forwarded over an incorrect route or even be routed back to DeviceB, thereby causing a traffic loop.
  
  Figure 2 Networking diagram for a traffic loop
7. Run peer { group-name | ipv4-address } route-policy route-policy-name export
  The route-policy is configured as an export policy based on which DeviceA advertises routes to DeviceB.
8. Run unicast-route label advertise
  DeviceA is enabled to convert received IPv4 unicast routes to labeled routes and advertise the labeled routes to peers with the labeled route exchange capability.
9. Run quit
  Return to the system view.
10. Run commit
  The configuration is committed.
Perform the following operations on the labeled route receiver (DeviceB):
1. Run bgp as-number
  The BGP view is displayed.
2. Run peer { group-name | ipv4-address } label-route-capability [ check-tunnel-reachable ]
  DeviceB is enabled to receive labeled routes.
3. Run quit
  Return to the system view.
4. Run commit
  The configuration is committed.

Verifying the Configuration

After configuring conversion from BGP IPv4 unicast routes to labeled routes, verify the configuration.

Run the display bgp routing-table label [ statistics ] command to check labeled route information in the BGP routing table.