BFD (Bidirectional Forwarding Detection) protocol provides a method to quickly detect the connectivity of forwarding paths between two neighboring routers with light load. In this way, protocol neighbors can quickly detect the connectivity failure of forwarding paths, accelerate the activation of backup forwarding paths, and improve the performance of existing networks.
There are two types of BFD messages: control messages and response messages. Among them, the echo message is only concerned by the local system of BFD session, but not by the far end, so the protocol does not specify its specific format. The protocol only specifies the format of the control message. At present, there are two versions of the control message format (version 0 and version 1). The default version of BFD session establishment is version 1. However, if the message sent by the other system is version 0, it will automatically switch to version 0 to establish a session. You can check the adopted version by using the show bfd neighbors command. The format of version 1 is shown in the chart 1:
Vers: version number of BFD protocol, currently 1.
? Diagnosis: Give the reasons for the last local transition from the UP state to other states, including:
0— No diagnostic information.
1- Control timeout detection
2- Echo function failure
3- Neighbor announces session closed
4- Reset the forwarding plane.
5-channel fault
6- Connection channel failure
7- Downward management
? Sta:BFD local status, with the value of AdminDown being 0, Down being 1, Init being 2 and Up being 3;
? P: When the parameters change, the sender puts this flag in the BFD message, and the receiver must respond to the message immediately.
? F: The F flag must be set in the response message in response to the setting of the P flag.
? C: forwarding/control separation flag. Once set, the change of control plane will not affect BFD detection. For example, if the control plane is OSPF, BFD can continue to detect the link status when OSPF restarts/gr.
? A: certification ID. When set, this means that the session needs to be authenticated.
? D: Query request, when set, indicates that the sender expects to detect the link by query.
? M: For future point-to-multipoint applications, it must be set to 0 at present.
? Detection multiple: detection timeout multiple, which is used by the detector to calculate the detection timeout.
? Length: Message length
? My discriminator: the local identifier of the BFD session connection.
? Yourdiscriminator: the remote identifier of the BFD session connection.
? Minimum required sending interval: the minimum locally supported BFD message sending interval.
? Minimum required receiving interval: the minimum locally supported BFD message receiving interval.
? Minimum Echo RX interval required: the minimum Echo message receiving interval supported locally (set to 0 if the Echo function is not supported locally).
? Authentication Type: Authentication Type (optional). At present, the agreement stipulates that:
Simple password
Keying MD5
Careful keying MD5
Keying SHA 1
Fine keying SHA 1
? Authentication length: authentication data length.
? Authentication data: authentication data area
BFD session establishment includes the following modes.
Active mode
Before establishing a session, whether or not a control message for establishing a BFD session is received from the opposite end, the control message for establishing a BFD session will be actively sent.
passive mode
Before the session is established, the control message for establishing the BFD session will not be actively sent until the control message for establishing the BFD session sent by the opposite end is received.
BFD can include the following detection modes:
Asynchronous mode
In asynchronous mode, the system periodically sends BFD control messages to each other. If the system does not receive the BFD control message from the peer within the detection time, it will declare the session closed.
Query mode
In query mode, it is assumed that each system has an independent method to confirm whether it is connected to other systems. In this way, once the BFD session is established, the system will stop sending BFD control messages unless the system needs to explicitly verify connectivity. In the case of explicitly verifying connectivity, the system will send a short sequence of BFD control packets and declare the session closed if no returned message is received within the detection time. If the response message from the opposite end is received, the forwarding path is normal.
Echo function
The local system sends BFD echo messages regularly, and the remote system sends back the messages through its forwarding channel. If several consecutive response messages are not received locally during the detection, the session is declared closed. The echo function can be used with the above two detection modes. The detection function of echo message is adopted, which does not involve the control plane of the remote system. The message is turned back through the forwarding plane of the remote system, which reduces the delay and detects the fault faster than sending the control message. If the echo function is enabled in asynchronous mode, the sending of control messages can be greatly reduced, because the detection work is completed by the echo function; If the echo function is enabled in query mode, the control message can be completely cancelled after the session is established. The loopback function must be enabled at both points of the BFD session, otherwise the loopback function will not work.
After the BFD session is established, BFD session parameters (such as expected minimum Tx interval, required minimum RX interval, detection Mult, etc. ) can be modified. After modification, the BFD session will be renegotiated, and the latest parameters will be used for session detection, and the modified session can continue to be in the UP state.
The BFD protocol allows authentication in the following ways:
1. Simple password
2. Keying MD5
3. Careful keying MD5
4. Keying SHA 1
5. Fine keying SHA 1
The vast majority of the application scenarios of BGPv4 are the interconnection of enterprise boundary devices, which uses the fixed Internet ip of operators to establish neighbor relations, and the other is the interconnection of branches of enterprises through operators' private lines, which is actually achievable.
This chapter mainly introduces the latter. The branches of enterprises are interconnected by operators' private lines, establishing BGP neighbor relations and optimizing the principle of active and standby line switching.
BGP is a triggered update. The main line is interrupted and switched to the standby line. By default, 180 is required to recognize the handover. Or when you find an interrupt alarm, you can converge the routing entries by manually clearing the neighbor relationship using clear ip bgp * hard or clear ip bgp * soft.
This redundant architecture should be understandable, and a simple topology diagram is drawn here with GNS.
In order to realize the normal access between PC 1 in Department A and PC2 in Department B, when the link between the main routes in Department AB is disconnected, it can be unconsciously switched to the standby line for communication.
First of all, we must connect the IBGP in Department A and the IBGP in Department B.. The primary router and backup router of AB department should establish the neighbor relationship of EBGP.
The neighbor status of the standby router will not be displayed.
My actual environment is that the data centers of all departments adopt the redundancy of operators' main and standby lines. Logically, it is a leap. Our border equipments are all made by Cisco, but they are not the same model. There are 2900, 2800, 3900 and 4300 series. Therefore, during the configuration process, a status bit will appear, and the status is admin down. It was also quite depressing at that time. Are configured with reference to the configuration manual. Why is the status not up but admin down?
In the process of configuration, we should pay attention to the negotiation of ports, such as full duplex, and the rate should match. The operator's private line used to be equipped with double unions, but now China Telecom Unicom has fixed the related bugs.
There is also cisco4300, which is equipped with neg auto under the interface, which can negotiate automatically and cannot be dropped. You need to configure the media type rj45 under the interface, and then enter duplex, speed 100 in no neg auto.
It is basically done at this time, and the device will be restarted at this time.
After restarting, you can see the establishment of bfd neighbors. The specific parameters of bfd are determined according to the needs of their own enterprises. My configuration parameters can basically achieve non-perceptual switching.