Troubleshooting EBGP Peering Stuck in Connect State
Question
-- Exhibit --
user@router> show configuration interfaces ge-1/0/0
unit 0 {
family inet {
address 192.168.100.1/30;
}
}
user@router> show configuration routing-options
autonomous-system 65001;
user@router> show configuration protocols bgp
group 65002 {
traceoptions {
file bgp-trace;
flag open detail;
}
neighbor 192.168.100.3 {
peer-as 65002;
}
}
user@router> show log bgp-trace
Feb 5 20:31:01 R4 clear-log[5510]: logfile cleared
Feb 5 20:32:22.658155 bgp_connect_completE. error connecting to 192.168.100.3 (External AS 65002): Socket is not connected user@router> run monitor traffic interface ge-1/0/0 extensive
Address resolution is ON. Use to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-1/0/0, capture size 1514 bytes
20:45:44.212833 Out
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22
Device Media Type Extension TLV #3, length 1, valuE. Ethernet (1)
Logical Interface Encapsulation Extension TLV #6, length 1, valuE. Ethernet (14)
Device Interface Index Extension TLV #1, length 2, valuE. 35328
Logical Interface Index Extension TLV #4, length 4, valuE. 70
Logical Unit Number Extension TLV #5, length 4, valuE. 32767
-----original packet-----
80:71:1f:c7:f8:60 > 84:18:88:8e:3b:3f, ethertype 802.1Q (0x8100), length 82: vlan 435, p 6, ethertype IPv4, (tos 0xc0, ttl 255, id 19548, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.100.1.bgp > 192.168.100.2.49373: S 1088527795:1088527795(0) ack 214564428 win 16384
20:45:44.213226 In
Juniper PCAP Flags [Ext, no-L2, In], PCAP Extension(s) total length 22
Device Media Type Extension TLV #3, length 1, valuE. Ethernet (1)
Logical Interface Encapsulation Extension TLV #6, length 1, valuE. Ethernet (14)
Device Interface Index Extension TLV #1, length 2, valuE. 35328
Logical Interface Index Extension TLV #4, length 4, valuE. 70
Logical Unit Number Extension TLV #5, length 4, valuE. 32767
-----original packet-----
PFE proto 2 (ipv4): (tos 0xc0, ttl 1, id 2367, offset 0, flags [none], proto: TCP (6), length: 52) 192.168.100.2.49373 > 192.168.100.1.bgp: . 1:1(0) ack 1 win
17376
-- Exhibit --
Click the Exhibit button.
You are asked to configure an EBGP peering to AS 65002. The EBGP peering is stuck in a Connect state.
Referring to the exhibit, what should be changed to the BGP configuration to bring up the peering?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.A
From the provided output, we can see that the BGP peering between the local router and the neighbor router with IP address 192.168.100.3 is stuck in the Connect state. The Connect state means that the TCP three-way handshake has not been completed, and the routers are unable to establish a BGP session. In this situation, we need to identify the root cause and make appropriate changes to the BGP configuration to bring up the peering.
Looking at the BGP configuration, we can see that the local AS is set to 65001, and the neighbor's AS is set to 65002. This indicates that the BGP peering is an external BGP (EBGP) peering between two different autonomous systems. However, the BGP configuration does not specify the local router's IP address to use for establishing the BGP session. Therefore, we need to add the local router's IP address to the BGP configuration to specify the source IP address for the BGP session.
The correct answer is option A: Configure the neighbor to 192.168.100.2. We need to change the BGP configuration to specify the correct neighbor IP address, which is 192.168.100.2, not 192.168.100.3. The correct BGP configuration should be:
sqlprotocols { bgp { group 65002 { traceoptions { file bgp-trace; flag open detail; } neighbor 192.168.100.2 { peer-as 65002; } local-address 192.168.100.1; } } } In this configuration, we have added the local-address statement with the IP address of the local router interface that is connected to the neighbor router. This statement specifies the source IP address for the BGP session, and it should match the IP address configured on the local router's interface.
Option B, configuring the local-as to 65001, is incorrect because this statement is already present in the BGP configuration, and it specifies the local autonomous system number.
Option C, configuring the peer-as to 65001, is incorrect because the neighbor's AS is already correctly configured as 65002 in the BGP configuration.
Option D, configuring the peering as passive, is not necessary in this case because the BGP peering is an active peering by default, and both routers are actively attempting to establish the BGP session.
