April 2016

Example for Configuring BGP Auto FRR

As shown in Figure 1, Router A belongs to AS 100; Router B, Router C, and Router D belong to AS 200. BGP Auto FRR needs to be configure so that the route from Router A to Router D can have backup forwarding information.

Figure 1 Networking diagram of configuring BGP Auto FRR

Configuration Roadmap

The configuration roadmap is as follows:

Configure EBGP connections between Router A and Router B and between Router A and Router C. Configure IBGP connections between Router D and Router B, and between Router D and Router C.
Configure routing policies on Router B and Router C to change the MED values of routes to Router D to facilitate route selection.
Configure BGP Auto FRR on Router A.

Data Preparation

To complete the configuration, you need the following data:

Router IDs and AS numbers of Router A, Router B, Router C, and Router D
Names of routing policies and MED values of routes on Router B and Router C

Procedure

Configure IP addresses for interfaces. The configuration details are not mentioned here.
Configure EBGP connections between Router A and Router B, and between Router A and Router C. Configure IBGP connections between Router B and Router D, and between Router C and Router D. # Configure EBGP connections on Router A.
```
<RouterA> system-view
```
```
[RouterA] bgp 100
```
```
[RouterA-bgp] router-id 1.1.1.1
```
```
[RouterA-bgp] peer 10.1.1.2 as-number 200
```
```
[RouterA-bgp] peer 10.2.1.2 as-number 200
```
NOTE:

The configurations of Router B and Router C are the same as that of Router A, and the detailed configurations are not mentioned here.

# Configure IBGP connections on Router D.
```
<RouterD> system-view
```
```
[RouterD] bgp 200
```
```
[RouterD-bgp] router-id 4.4.4.4
```
```
[RouterD-bgp] peer 10.3.1.1 as-number 200
```
```
[RouterD-bgp] peer 10.4.1.1 as-number 200
```
NOTE:

The configurations on Router B and Router C are similar, and the detailed configurations are not mentioned here.

Configuring routing policies on Router B and Router C so that the MED values of routes to Router D are different # Configure a routing policy on Router B.

<RouterB> system-view

[RouterB] route-policy rtb permit node 10

[RouterB-route-policy] apply cost 80

[RouterB-route-policy] quit

[RouterB] bgp 200

[RouterB-bgp] ipv4-family unicast

[RouterB-bgp-af-ipv4] peer 10.1.1.1 route-policy rtb export

# Configure a routing policy on Router C.

<RouterC> system-view

[RouterC] route-policy rtc permit node 10

[RouterC-route-policy] apply cost 120

[RouterC-route-policy] quit

[RouterC] bgp 200

[RouterC-bgp] ipv4-family unicast

[RouterC-bgp-af-ipv4] peer 10.2.1.1 route-policy rtc export

# Advertise a route to 4.4.4.4/32 on Router D.

[RouterD] bgp 200

[RouterD-bgp] ipv4-family unicast

[RouterD-bgp] network 4.4.4.4 32

# Run the display ip routing-table verbose command on Router A to check detailed information about the learned route to 4.4.4.4/32.

<RouterA> display ip routing-table 4.4.4.4 32 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 4.4.4.4/32
     Protocol: BGP             Process ID: 0
   Preference: 255                   Cost: 80
      NextHop: 10.1.1.2         Neighbour: 10.1.1.2
        State: Active Adv             Age: 00h00m12s
          Tag: 0                 Priority: low
        Label: NULL               QoSInfo: 0x0
   IndirectID: 0x4
 RelayNextHop: 0.0.0.0          Interface: Pos1/0/0
     TunnelID: 0x0                  Flags:  D

Because the MED value of the route learnt from Router B is smaller, on Router A, the route to 4.4.4.4/32 selects the path RouterA→RouterB→RouterD. Because FRR is not configured, no backup information is available.

Enabling BGP Auto FRR on Router A, and checking the routing information # Enable BGP Auto FRR on Router A.

<RouterA> system-view

[RouterA] bgp 100

[RouterA-bgp] ipv4-family unicast

[RouterA-bgp-af-ipv4] auto-frr

# After the configuration, run the display ip routing-table verbose command on Router A to check the routing information.

<RouterA> display ip routing-table 4.4.4.4 32 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 4.4.4.4/32
     Protocol: BGP             Process ID: 0
   Preference: 255                   Cost: 80
      NextHop: 10.1.1.2         Neighbour: 10.1.1.2
        State: Active Adv             Age: 00h52m45s
          Tag: 0                 Priority: low
        Label: NULL               QoSInfo: 0x0
   IndirectID: 0x4
 RelayNextHop: 0.0.0.0          Interface: Pos1/0/0
     TunnelID: 0x0                  Flags:  D
    BkNextHop: 10.2.1.2       BkInterface: Pos2/0/0
      BkLabel: NULL           SecTunnelID: 0x0
 BkPETunnelID: 0x0        BkPESecTunnelID: 0x0
 BkIndirectID: 0x2

The preceding information shows that Router A has a backup next hop and a backup outbound interface to 4.4.4.4/32.

Configuration Files

Configuration file of Router A

#
 sysname RouterA
#
interface Pos1/0/0
 ip address 10.1.1.1 255.255.255.0
#
interface Pos2/0/0
  ip address 10.2.1.1 255.255.255.0
#
bgp 100
 router-id 1.1.1.1
 peer 10.1.1.2 as-number 200
 peer 10.2.1.2 as-number 200
#
 ipv4-family unicast
    auto-frr
#
return

Configuration file of Router B

#
 sysname RouterB
#
interface Pos1/0/0
 ip address 10.1.1.2 255.255.255.0
#
interface Pos2/0/0
  ip address 10.3.1.1 255.255.255.0
#
bgp 200
 router-id 2.2.2.2
 peer 10.1.1.1 as-number 100
 peer 10.3.1.2 as-number 200
#
 ipv4-family unicast 
    peer 10.1.1.1 route-policy rtb export
#
route-policy rtb permit node 10
 apply cost 80
#
return

Configuration file of Router C

#
 sysname RouterC
#
interface Pos1/0/0
 ip address 10.2.1.2 255.255.255.0
#
interface Pos2/0/0
 ip address 10.4.1.1 255.255.255.0
#
bgp 200
 router-id 3.3.3.3
 peer 10.2.1.1 as-number 100
 peer 10.4.1.2 as-number 200
 #
 ipv4-family unicast
    peer 10.2.1.1 route-policy rtc export
#
route-policy rtc permit node 10
 apply cost 120
#
return

Configuration file of Router D

#
 sysname RouterD
#
interface Pos1/0/0
 ip address 10.3.1.2 255.255.255.0
#
interface Pos2/0/0
  ip address 10.4.1.2 255.255.255.0
#
interface LoopBack1
 ip address 4.4.4.4 255.255.255.255
#
bgp 200
 router-id 4.4.4.4
 peer 10.3.1.1 as-number 200
 peer 10.4.1.1 as-number 200
 #
 ipv4-family unicast
  network 4.4.4.4 255.255.255.255
#
return

BGP Auto FRR

As a protection measure against faults over links, BGP Auto Fast Reroute (FRR) is applicable to networks with primary and backup links. With BGP Auto FRR, traffic can be switched between two BGP peers or next hops within sub-seconds.
With BGP Auto FRR, if a peer has multiple routes with the same prefix that are learned from different peers, the peer uses the optimal route as the primary link to forward packets and the less optimal route as a backup link. If the primary link fails, the peer rapidly notifies other peers that the BGP route has become unreachable and then switches traffic from the primary link to the backup link.

Usage Scenario

On the network shown in Figure 1, Device Y advertises a learned BGP route to Device X2 and Device X3 in AS 100; Device X2 and Device X3 then advertise the BGP route to Device X1 through RR. Therefore, Device X1 receives two routes whose next hops are Device X2 and Device X3 respectively. Then, Device X1 selects a route based on a configured routing policy. Assume that the route sent by Device X2 (Link A) is preferred. The route sent by Device X3 (Link B) then functions as a backup link.

Figure 1 Networking for BGP Auto FRR

If a node along Link A fails or faults occur on Link A, the next hop of the route from Device X1 to Device X2 becomes unavailable. If BGP Auto FRR is enabled on Device X1, the forwarding plane then quickly switches to Link B the traffic from Device X1 to Device Y, which ensures uninterrupted traffic transmission. In addition, Device X1 reselects the route sent by Device X3 based on the forwarding prefixes and then updates the FIB table.

BGP GR "Graceful Restart "

Graceful restart (GR) is one of the high availability (HA) technologies, which comprise a series of comprehensive technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-tolerant redundancy technology, GR ensures normal forwarding of data during the restart of routing protocols to prevent interruption of key services. Currently, GR has been widely applied to the master/slave switchover and system upgrade.
GR is usually used when the active route processor (RP) fails because of a software or hardware error, or used by an administrator to perform the master/slave switchover.

Prerequisite for Implementation

On a traditional routing device, a processor implements both control and forwarding. The processor finds routes based on routing protocols, and maintains the routing table and forwarding table of the device. Mid-range and high-end devices generally adopt the multi-RP structure to improve forwarding performance and reliability. The processor in charge of routing protocols is located on the main control board, whereas the processor responsible for data forwarding is located on the interface board. The design helps to ensure the continuity of packet forwarding on the interface board during the restart of the main processor. The technology that separates control from forwarding satisfies the prerequisite for GR implementation.
At present, a GR-capable device must have two main control boards. In addition, the interface board must have an independent processor and memory.

Related Concepts

The concepts related to GR are as follows:

GR Restarter: indicates a device that performs master/slave switchover triggered by the administrator or a failure. A GR Restarter must support GR.
GR Helper: indicates the neighbor of a GR Restarter. A GR Helper must support GR.
GR session: indicates a session, through which a GR Restarter and a GR Helper can negotiate GR capabilities.
GR time: indicates the time when the GR Helper finds that the GR Restarter is Down but keeps the topology information or routes obtained from the GR Restarter.
End-of-RIB (EOR): indicates BGP information, notifying a peer BGP that the first route upgrade is finished after the negotiation.
EOR timer: indicates a maximum time of a local device waiting for the EOR information sent from the peer. If the local device does not receive the EOR information from the peer within the EOR timer, the local device will select an optimal route from the current routes.

Principles

Principles of BGP GR are as follows:

During BGP peer relationship establishment, devices negotiate GR capabilities by sending supported GR capabilities to each other.
When detecting the master/slave switchover of the GR Restarter, a GR Helper does not delete the routing information and forwarding entries related to the GR Restarter within the GR time, but waits to re-establish a BGP connection with the GR Restarter.
After the master/slave switchover, the GR Restarter receives routes from all the negotiated peers with GR capabilities before the switchover, and starts the EOR timer. The GR Restarter selects a route when either of the following conditions is met:
- The GR Restarter receives the EOR information of all peers and the EOR timer is deleted.
- The EOR timer times out but the GR Restarter receives no EOR information from all peers.
The GR Restarter sends the optimal route to the GR Helper and the GR Helper starts the EOR timer. The GR Helper quits GR when either of the following conditions is met:
- The GR Helper receives the EOR information from the GR Restarter and the EOR timer is deleted.
- The EOR timer times out and the GR Helper receives no EOR information from the GR Restarter.

GR Reset

Currently, BGP does not support dynamic capability negotiation. Therefore, each time a new BGP capability (such as the IPv4, IPv6, VPNv4, and VPNv6 capabilities) is enabled on a BGP speaker, the BGP speaker tears down existing sessions with its peer and renegotiates BGP capabilities. This process will interrupt ongoing services.
To prevent the service interruptions, the CX600 provides the GR reset function that enables the CX600 to reset a BGP session in GR mode. With the GR reset function configured, when you enable a new BGP capability on the BGP speaker, the BGP speaker enters the GR state, resets the BGP session, and renegotiates BGP capabilities with the peer. In the whole process, the BGP speaker re-establishes the existing sessions but does not delete the routing entries for the existing sessions, so that the existing services are not interrupted.

Benefits

Through BGP GR, the forwarding is not interrupted. In addition, the flapping of BGP occurs only on the neighbors of the GR Restarter, and does not occur in the entire routing domain. This is important for BGP that needs to process a large number of routes.

MP-BGP

Conventional BGP-4 manages only IPv4 unicast routing information, and inter-AS transmission of packets of other network layer protocols, such as IPv6 and multicast, is limited.
To support multiple network layer protocols, the Internet Engineering Task Force (IETF) extends BGP-4 to Multiprotocol Extensions for BGP-4 (MP-BGP). RFC 4760 defines the MP-BGP standard. MP-BGP is forward compatible. Specifically, CX devices supporting MP-BGP can communicate with the CX devices that do not support MP-BGP.

Extended Attributes

BGP-4 Update packets carry three IPv4-related attributes: NLRI (Network Layer Reachable Information), Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP speaker that performs route aggregation.
To carry information about multiple network layer protocols in NLRI and Next_Hop, MP-BGP introduces the following route attributes:

MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise a reachable route and its next hop.
MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to delete an unreachable route.

The preceding two attributes are optional non-transitive. Therefore, the BGP speakers that do not support MP-BGP will ignore the information carried in the two attributes and do not advertise the information to other peers.

Address Family

The Address Family Information field consists of a 2-byte Address Family Identifier (AFI) and a 1-byte Subsequent Address Family Identifier (SAFI).
BGP uses address families to distinguish different network layer protocols. For the values of address families, see RFC 3232 (Assigned Numbers). The CX600 supports multiple MP-BGP extension applications, such as VPN extension and IPv6 extension, which are configured in their respective address family views.

Pages