- Table of Contents
-
- H3C S3610[S5510] Series Ethernet Switches Operation Manual-Release 5301-(V1.03)
- 00-1Cover
- 00-2Product Overview
- 01-Login Configuration
- 02-VLAN Configuration
- 03-IP Addressing and Performance Configuration
- 04-QinQ-BPDU Tunneling Configuration
- 05-Port Correlation Configuration
- 06-Link Aggregation Configuration
- 07-MAC Address Table Management Configuration
- 08-IP Source Guard Configuration
- 09-MSTP Configuration
- 10-IPv6 Configuration
- 11-Routing Overview
- 12-IPv4 Routing Configuration
- 13-BFD-GR Configuration
- 14-IPv6 Routing Configuration
- 15-Multicast Protocol Configuration
- 16-802.1x-HABP-MAC Authentication Configuration
- 17-AAA-RADIUS-HWTACACS Configuration
- 18-ARP Configuration
- 19-DHCP Configuration
- 20-ACL Configuration
- 21-QoS Configuration
- 22-Port Mirroring Configuration
- 23-Cluster Management Configuration
- 24-UDP Helper Configuration
- 25-SNMP-RMON Configuration
- 26-NTP Configuration
- 27-DNS Configuration
- 28-File System Management Configuration
- 29-Information Center Configuration
- 30-System Maintaining and Debugging Configuration
- 31-NQA Configuration
- 32-VRRP Configuration
- 33-SSH Configuration
- 34-MCE Configuration
- 35-OAM Configuration
- 36-DLDP Configuration
- 37-RRPP Configuration
- 38-SSL-HTTPS Configuration
- 39-PKI Configuration
- 40-Appendix
- Related Documents
-
Title | Size | Download |
---|---|---|
13-BFD-GR Configuration | 246 KB |
Table of Contents
1.2 BFD Configuration Task List
1.3 Configuring BFD Basic Functions
1.3.1 Configuration Prerequisites
1.4 Configuring BFD for Static Routing
1.6 Displaying and Maintaining BFD
1.7 BFD Configuration Examples
1.7.1 Configuring BFD for Static Routing
2.1 Introduction to Graceful Restart
2.2 Basic Concepts in Graceful Restart
2.3 Graceful Restart Communication Procedure
2.4 Graceful Restart Mechanism for Several Commonly Used Protocols
Chapter 1 BFD Configuration
When configuring BFD, go to these sections for information you are interested in:
l Displaying and Maintaining BFD
& Note:
The term “router” or router icon in this document refers to a router in a generic sense or an Ethernet switch running routing protocols.
1.1 Introduction to BFD
Bidirectional forwarding detection (BFD) provides a consistent mechanism to quickly detect and monitor the connectivity of links or IP forwarding paths in networks. To improve network performance, protocols on adjacent devices must quickly detect communication failures to restore the communication through backup paths as soon as possible. Normally, a network employs the following detection methods:
l Quickly detecting link failures by sending hardware detection signals, such as SDH (synchronous digital hierarchy) transmission system alarms.
l If no hardware detection signals are provided or failures cannot be detected through hardware detection signals, the network uses the hello mechanism of a routing protocol for failure detection, which has a slower failure detection rate of more than one second. In Gigabit data transmission, such a rate will cause a large quantity of data to be dropped.
l Implementing real-time detection for all media types and protocols through a uniform mechanism and providing different detection intervals and costs.
1.1.1 How BFD Works
BFD provides a general-purpose, standard, medium- and protocol-independent fast failure detection mechanism. It can uniformly and quickly detect the failures of the bidirectional forwarding paths between two routers for upper-layer protocols, such as routing protocols and Multiprotocol Label Switching (MPLS).
BFD establishes sessions between two routers to monitor the bidirectional forwarding paths in between providing services for upper-layer protocols. BFD provides no neighbor discovery mechanism. Upper-layer protocols that BFD services notify BFD of routers to which it needs to establish sessions. After a session is established, if no BFD control packet is received from the peer within the negotiated BFD interval, BFD notifies a failure to the upper-layer, which takes appropriate measures.
I. How BFD interacts with an application-layer protocol
l After discovering neighbors by using its own neighbor discovery mechanism, an application-layer protocol notifies BFD of the protocol type, neighbor address, interface, and whether the neighbor is directly connected. Upon receiving the notification, BFD sends control packets to establish sessions.
l When BFD is disabled or a neighbor is removed, BFD receives a notification from the application-layer protocol to tear down the session. If no other applications need to monitor this link, BFD tears down the corresponding session.
II. Failure detection mechanism
After a BFD session is established, if no BFD control packet is received from the neighbor within the BFD interval, BFD sets the session state to down and notifies it to the protocol concerned.
Upon receiving the link failure notification from BFD, the application-layer protocol considers the neighbor down.
& Note:
No detection time resolution is defined in the BFD draft. At present, most devices supporting BFD provide detection measured in milliseconds.
III. BFD session modes
l Control packet mode: Both ends of the link exchange BFD control packets to monitor link status.
l Echo mode: One end of the link sends Echo packets to the other end, which then forwards the packets back to the originating end, thereby monitoring link status in both directions.
IV. BFD operation modes
Before a BFD session is established, there are two BFD operation modes: active or passive.
l Active mode: Before a session is established, BFD actively sends BFD control packets regardless of whether any BFD control packet is received from the peer.
l Passive mode: Before a session is established, no BFD control packet is sent until a BFD control packet is received from the peer.
During session initialization, at least one end of the two in communication must operate in the active mode for a session to be established.
After a BFD session is established, there are two BFD operation modes: asynchronous and query. Both ends in communication must operate in the same mode.
l Asynchronous mode: A device operating in the asynchronous mode periodically sends BFD control packets. It tears down the BFD session if it receives no BFD control packet from the peer within the BFD interval.
l Query mode: This mode assumes that every protocol acknowledges its connection to another protocol by using its unique method. In this way, the protocol stops sending BFD control packets as long as a BFD session is established, unless a protocol needs to explicitly verify the connectivity.
& Note:
l At present, only the asynchronous mode is supported.
l At present, BFD can be implemented in the Echo mode for static routes only and in a way different from that defined in the BFD draft.
l When a BFD session operates in the Echo mode, the session is independent of the operation mode.
V. Dynamic BFD parameter changes
VI. Authentication modes
BFD provides the following authentication methods:
l Simple: Plain text authentication
l MD5: MD5 (Message Digest 5) authentication
l SHA1: SHA1 (Secure Hash Algorithm 1) authentication
1.1.2
BFD Packet Format
Figure 1-1 illustrates the BFD control packet format.
Figure 1-1 BFD control packet format
l Vers: Protocol version. The protocol version is 1.
l Diag: This bit indicates the reason for the last transition of the local protocol from up to some other state. Table 1-1 lists the states.
Table 1-1 Diag bit values
Diag |
Description |
0 |
No Diagnostic |
1 |
Control Detection Time Expired |
2 |
Echo Function Failed |
3 |
Neighbor Signaled Session Down |
4 |
Forwarding Pane Reset |
5 |
Path Down |
6 |
Concatenated Path Down |
7 |
Administratively Down |
8~31 |
Reserved for future use |
l State (Sta): Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init, and 3 for Up.
l Demand (D): If set to 1, it means the transmitting protocol wishes to operate in the query mode; if set to 0, it means the transmitting protocol ignores the query mode or cannot operate in the query mode.
l Poll (P): If it is set to 1, the transmitting protocol requests the connection acknowledgement or acknowledges a parameter change. If it is set to 0, the transmitting protocol does not request the acknowledgement.
l Final (F): If it is set to 1, the transmitting protocol responds to a received BFD control packet that has the Poll (P) bit set. If it is set to 0, the transmitting protocol does not respond to any received BFD control packet that has the Poll (P) bit set.
l Control Plane Independent(C): If set to 1, it means the BFD implementation for the transmitting protocol is independent of its control plane. That is, BFD is implemented at the forwarding plane and takes effect even if the control plane fails. If set to 0, it means BFD is implemented at the control plane.
l Authentication Present (A): If it is set to 1, the control packet contains the authentication field and the session is authenticated.
l Reserved (R): It is set to 0 during transmission and ignored during reception.
l Detect Mult: Detect time multiplier. In the BFD asynchronous mode, the negotiated transmit interval multiplied by the detect time multiplier determines the detection time for the transmitting protocol.
l Length: BFD control packet length, in bytes.
l My Discriminator: It is a unique and non-zero discriminator value generated by the transmitting protocol to demultiplex multiple BFD sessions between two protocols.
l Your Discriminator: It is the discriminator received from the corresponding remote protocol. This field reflects the received value of My Discriminator or returns 0 if that value is unknown.
l Desired Min Tx Interval: Minimum interval at which the local protocol wishes to send BFD control packets, in milliseconds.
l Required Min Rx Interval: Interval at which the local protocol can receive BFD control packets, in milliseconds.
l Required Min Echo Rx Interval: Interval at which the local protocol can receive BFD echo packets, in milliseconds. If this field is set to 0, the transmitting protocol does not receive any BFD echo packets.
l Auth Type: Authentication type used by BFD control packets.
l Auth Len: Authentication field length, including authentication type field and authentication length field.
1.1.3
Protocols and Standards
BFD-related specifications are described in the following documents:
l draft-ietf-bfd-base-05: Protocol Independent Bidirectional Forwarding Detection
l draft-ietf-bfd-v4v6-1hop-05: BFD for IPv4 and IPv6 (Single Hop)
1.2 BFD Configuration Task List
Configure BFD to provide a detection mechanism for the network.
Complete the following tasks to configure BFD:
Task |
Remarks |
Optional BFD basic configurations provide basis for other configuration tasks. |
|
Required Enable BFD for the links of static routes. |
1.3 Configuring BFD Basic Functions
1.3.1
Configuration Prerequisites
Before configuring BFD detection modes, complete the following tasks:
l Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to each other at the network layer;
l Configure the routing protocols that support BFD
1.3.2
Configuration Procedure
Follow these steps to configure BFD session parameters:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Specify a BFD session initiation mode |
bfd session init-mode { active | passive } |
Optional active by default |
Configure the source IP address of echo packets |
bfd echo-source-ip ip-address |
Optional |
Enter interface view |
interface interface-type interface-number |
— |
Configure the minimum BFD transmit interval of the interface |
bfd min-transmit-interval value |
Optional 400 milliseconds by default |
Configure the minimum echo receive interval of the interface |
bfd min-echo-receive-interval value |
Optional 400 milliseconds by default |
Configure the minimum packet receive interval of the interface |
bfd min-receive-interval value |
Optional 400 milliseconds by default |
Configure the detect time multiplier |
bfd detect-multiplier value |
Optional 5 by default |
Configure the authentication type of the interface |
bfd authentication-mode { md5 key-id key | sha1 key-id key | simple key-id password } |
Optional By default, the interface operates in the non-authentication mode. |
& Note:
The source address of echo packets must be configured if the BFD session operates in the echo mode.
1.4 Configuring BFD for Static Routing
A dynamic routing protocol notifies BFD of the neighbor information. BFD uses such information to establish sessions with neighbors by sending BFD control packets. Static routing, which cannot discover neighbors dynamically, uses the following approaches:
l Configure a static route with the local device as the nexthop, and enable BFD on the peer device
l Use echo packets to establish a session. These echo messages use the local device interface address as the destination and are directly forwarded back to the local device after being sent to the nexthop, without being processed by the BFD processes.
Follow these steps to configure BFD for static routes:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enable BFD for a static route |
ip route-static dest-address mask | mask-length { [ gateway-address bfd { control-packet | echo-packet } ] | [ interface-type interface-number gateway-address bfd { control-packet | echo-packet } ] } |
Use either command |
ip route-static vpn-instance s-vpn-instance-name&<1-6> dest-address { mask | mask-length } { gateway-address bfd { control-packet | echo-packet } [ public ] | interface-type interface-number [ gateway-address bfd { control-packet | echo-packet } ] | vpn-instance d-vpn-instance-name gateway-address bfd { control-packet | echo-packet } } |
Caution:
l If route flaps occur, enabling BFD may worsen the route flaps. Therefore, enable BFD with care in such cases.
l BFD cannot be used for a static route with the outbound interface having the spoofing attribute.
l BFD can be used for a static route with a direct nexthop rather than a static route with a non-direct nexthop.
l In the draft, the BFD echo function is revised to specify that a BFD session is established at only one end when the echo mode is used.
l For static route configuration, refer to Static Routing Configuration in IPv4 Routing.
1.5 Enabling BFD Trap
Follow these steps to enable BFD trap:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enable BFD trap |
snmp-agent trap enable bfd |
Optional Enabled by default |
1.6 Displaying and Maintaining BFD
To do… |
Use the command… |
Remarks |
Display information about BFD-enabled interfaces |
display bfd interface [ verbose ] |
Available in any view |
Display PAF configuration information |
display bfd paf |
Available in any view |
Display BFD session information |
display bfd session [ verbose ] |
Available in any view |
Clear BFD session statistics. |
reset bfd session statistics |
Available in user view |
1.7 BFD Configuration Examples
1.7.1
Configuring BFD for Static Routing
I. Network requirements
Switch A, Switch B, and Switch C are interconnected and reachable to one another. Configure a static route on Switch A to Switch C and enable BFD.
II. Network diagram
Figure 1-2 Network diagram for BFD configuration on a static route
III. Configuration procedure
# Configure a static route on Switch A and enable BFD on it. Implement BFD through BFD echo packets.
<SwitchA> system-view
[SwitchA] bfd echo-source-ip 123.1.1.1
[SwitchA] interface vlan-interface 10
[SwitchA-vlan-interface10] bfd min-echo-receive-interval 300
[SwitchA-vlan-interface10] bfd detect-multiplier 7
[SwitchA-vlan-interface10] quit
[SwitchA] ip route-static 120.1.1.1 24
[SwitchA] quit
# Enable BFD debugging on Switch A.
<SwitchA> debugging bfd event
<SwitchA> debugging bfd scm
<SwitchA> terminal debugging
Enable BFD debugging on Switch A and tear down the link between Switch A and Switch B to verify the configuration. The display shows that Switch A can quickly detect the changes on Switch B.
Chapter 2 GR
Go to these sections for information you are interested in:
l Introduction to Graceful Restart
l Basic Concepts in Graceful Restart
l Graceful Restart Communication Procedure
l Graceful Restart Mechanism for Several Commonly Used Protocols
& Note:
Throughout this chapter, the term router in this document refers to a router in a generic sense or a Layer 3 switch.
2.1 Introduction to Graceful Restart
Graceful Restart ensures the continuity of packet forwarding when a routing protocol restarts.
The mechanism of Graceful Restart works as follows: after the routing protocol on a Graceful Restart capable device restarts, the device will notify its neighbors to temporarily preserve its adjacencies with them and the routing information. The neighbors will help the restarting device to update its routing information and to restore it to the state prior to the restart in minimal time. The routing and forwarding remain highly stable across the restart, the packet forwarding path remains the same, and the whole system can forward IP packets continuously. Hence, it is called “Graceful Restart”.
2.2 Basic Concepts in Graceful Restart
A router with the Graceful Restart feature enabled is called a Graceful Restart capable router. It can perform a Graceful Restart when its routing protocol restarts. Routers that are not Graceful Restart capable will follow the normal restart procedures after a routing protocol restart.
l GR Restarter: Graceful restarting router, the router whose routing protocol has restarted due to administrator instructions or network failure. It must be Graceful Restart capable.
l GR Helper: The neighbor of the GR Restarter, which helps the GR Restarter to retain the routing information. It must be Graceful Restart capable.
l GR Session: A Graceful Restart session, which is the negotiation between the GR Restarter and the GR Helper. A GR session includes restart notification and communications across restart. Through this session, GR Restarter and GR Helper can know the GR capability of each other.
l GR Time: The time taken for the GR Restarter and the GR Helper to establish a session between them. Upon detection of the down state of a neighbor, the GR Helper will preserve the topology and routing information sent from the GR Restarter for a period as specified by the GR Time.
2.3 Graceful Restart Communication Procedure
Configure a device as GR Restarter in a network. This device and its GR Helper must support GR or be GR capable. Thus, when GR Restarter restarts, its GR Helper can know its restart process.
& Note:
l In some cases, GR Restarter and GR Helper can replace with each other.
l If a router is to act as a Graceful Restarter, it must have the ability to preserve the routing information in the routing table (forwarding table). Routers that fail to meet this can only act as a GR Helper.
The communication procedure between the GR Restarter and the GR Helper works as follows:
1) A GR session is established between the GR Restarter and the GR Helper.
Figure 2-1 A GR session is established between the GR Restarter and the GR Helper
As illustrated in Figure 2-1, Router A works as GR Restarter, Router B, Router C and Router D are the GR Helpers of Router A. A GR session is established between the GR Restarter and the GR Helper.
2) GR Restarter restarting
Figure 2-2 Restarting process for the GR Restarter
As illustrated in Figure 2-2. The GR Helper detects that the GR Restarter has restarted its routing protocol and assumes that it will recover within the GR Time. Before the GR Time expires, the GR Helper will neither terminate the session with the GR Restarter nor delete the topology or routing information of the latter.
3) GR Restarter signaling to GR Helper
Figure 2-3 The GR Restarter signals to the GR Helper(s) after restart
As illustrated in Figure 2-3, after the GR Restarter has recovered, it will signal to all its neighbors and will reestablish GR Session.
4) The GR Restarter obtaining topology and routing information from the GR Helper
Figure 2-4 The GR Restarter obtains topology and routing information from the GR Helper
As illustrated in Figure 2-4, the GR Restarter obtains the necessary topology and routing information from all its neighbors through the GR sessions between them and calculates its own routing table based on this information.
2.4 Graceful Restart Mechanism for Several Commonly Used Protocols
The switch supports Graceful Restart for Boarder Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Intermediate System to Intermediate System (IS-IS).
For the implementation and configuration procedure of the Graceful Restart mechanism of the above protocols, refer to BGP Configuration, OSPF Configuration, and IS-IS Configuration in IPv4 Routing.