No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

BGP Peer Relationship Fails to Be Established After the Configuration of ebgp-max-hop 2 Is Changed to valid-ttl-hops 1

Publication Date:  2013-09-13 Views:  42 Downloads:  0
Issue Description
1. The topology is as follows:
TX-1---------------------TX-2 (loopback 202.97.XXX.XXX)
||                                    ||
||                                    ||  EBGP
||                                    ||
|| POS15/1/0                ||POS12/0/0
NE5000E-1------------NE5000E-2 (loopback 61.146.XXX.XXX)
2. TX-2 and NE5000E-2 establish an EBGP peer relationship through loopback interfaces. The ebgp-max-hop 2 command is configured on both TX-2 and NE5000E-2.
3. To enhance device security, the valid-ttl-hops 1 command is executed to adjust the ebgp-max-hop 2 command configuration. The BGP peer relationship is normal. Then, the reset bgp command is executed and the BGP peer relationship fails to be established.
Handling Process

The possible causes are as follows:
1. The valid-ttl-hops 1 command is incorrectly configured.
2. The processing mechanism on the device is faulty.
3. The security policy is incorrect.

The fault location process is as follows:

1. Verify the valid-ttl-hops 1 configurations on devices at both ends. The configurations are the same as those at successful sites.
2. Enable debugging on NE5000E-2. NE5000E-2 sends BGP protocol packets with the TTL as 255 and receives response packets with the TTL as 64 from TX-2. NE5000E-2 detects that the response packets do not meet requirements and discards the response packets. For details, see NE5000E-2 alarm log in the attachment.
3. Enable debugging on TX-2. TX-2 receives BGP protocol packets with TTL as 255 from NE5000E-2 and returns response packets with the TTL as 64 (correct TTL is 255, complying with the RFC; the TX-2 version is incorrect). At the same time, TX-2 sends BGP protocol packets with the TTL as 255 but receives no response packets from NE5000E-2. For details, see TX alarm log in the attachment.
4. BGP peer relationships are established by negotiation of two peers regardless of which peer initiates the negotiation.
a. NE5000E-2 sends negotiation packets to TX-2, but TX-2 does not return correct response packets. The BGP peer relationship fails to be established.
b. If TX-2 sends negotiation packets to NE5000E-2 and NE5000E-2 returns correct response packets, the BGP peer relationship is properly established.
The problem is that NE5000E-2 receives no negotiation packets from TX-2, leading to a failure in establishing the BGP peer relationship.
5. On NE5000E-2, check the port connected to TX-2. Find that a routing policy is configured on the port. The policy allows data packets with a BGP source port at the inbound direction, but not data packets with a BGP destination port. This configuration is not standard.
 rule 220 permit tcp source-port eq bgp
Negotiation packets actively sent by TX-2 are data packets with BGP port as the destination port. NE5000E-2 discards the packets because they do not match the policy.
Root Cause
A routing policy is configured on the port of NE5000E-2 connected to TX-2. The policy allows data packets with a BGP source port at the inbound direction, but not data packets with a BGP destination port. This configuration is not standard.
 rule 220 permit tcp source-port eq bgp
Negotiation packets actively sent by TX-2 are data packets with BGP port as the destination port. NE5000E-2 discards the packets because they do not match the policy.
Solution
You can rectify the fault in either of the following solutions:
1. Configure a policy allowing data packets with a BGP port destination port on NE5000E-2.
2. Configure all IP packets of the loopback address segment on TX-2.
In this case, solution 2 is selected.
Suggestions
1. The valid-ttl-hops 1 command is executed to adjust the ebgp-max-hop 2 command configuration. The BGP peer relationship is normal. Then, the reset bgp command is executed and the BGP peer relationship fails to be established. Why?
Before BGP is reset, GTSM is not enabled. The device does not check the TTL sent by the neighbor, so the neighbor relationship is normal.
2. Because the data configuration of the customer is incorrect. Before the valid-ttl-hops 1 command is executed to adjust the ebgp-max-hop 2 command configuration, NE5000E sends requests to negotiate with the TX. There are potential security risks. When performing security hardening for the device, verify the script.

END