Скачать или смотреть Why Do BGP Neighbors Toggle Between Idle, Connect, and Active States?

Why Do BGP Neighbors Toggle Between Idle, Connect, and Active States?

1. The Neighbor Statement Is Incorrect
2. No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer
3. The update-source Command Is Missing Under BGP
4. A typing error resulted in the wrong IP address in the neighbor statement or the wrong autonomous system number.
5. Unicast is broken due to one of these reasons:
Wrong virtual circuit (VC) mapping in an Asynchronous Transfer Mode (ATM) or Frame Relay environment in a highly redundant network.
Access list is blocking the unicast or TCP packet.
Network Address Translation (NAT) is running on the router and is translating the unicast packet.
Layer 2 is down.
6. The lack of the ebgp-multihop command is a common mistake that keep peers from appearing.


1. The Neighbor Statement Is Incorrect
R1:
router bgp 400
neighbor 10.10.10.2 remote-as 400
neighbor 10.10.10.2 update-source Loopback0
!
ip route 2.2.2.2 255.255.255.255 10.10.10.2

R2:
router bgp 400
neighbor 10.10.10.1 remote-as 400
neighbor 10.10.10.1 update-source Loopback0
!
ip route 1.1.1.1 255.255.255.255 10.10.10.1

Solution:
In order to remedy this situation, either correct the loopback address in the neighbor statement,
or remove the update-source command from the configuration.

R1:
router bgp 400
neighbor 2.2.2.2 remote-as 400
neighbor 2.2.2.2 update-source Loopback0
!
ip route 2.2.2.2 255.255.255.255 10.10.10.2

R2:
router bgp 400
neighbor 1.1.1.1 remote-as 400
neighbor 1.1.1.1 update-source Loopback0
!
ip route 1.1.1.1 255.255.255.255 10.10.10.1


show ip bgp summary
debug ip bgp
debug ip tcp transactions


2. No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer
R1:
router bgp 400
neighbor 2.2.2.2 remote-as 300
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
R2:
router bgp 300
neighbor 1.1.1.1 remote-as 400
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0

Solution
The solution is to include a route to the next hop in the BGP neighbor statement.
You can use a static or dynamic route depending on the situation.
Use the neighbor ebgp-multihop command only when the IP address you are peering to on your eBGP peer is not directly connected.
Note: A default route is never going to be used to establish a BGP session (iBGP/eBGP),
and you see the same (no route) output in the debugs, although you are able to ping the BGP neighbor.

R1:
ip route 2.2.2.2 255.255.255.255 10.10.10.2

R2:
ip route 1.1.1.1 255.255.255.255 10.10.10.1


The update-source Command Is Missing Under BGP

R1:
router bgp 400
neighbor 2.2.2.2 remote-as 400
!
ip route 2.2.2.2 255.255.255.255 10.10.10.1

R2:
router bgp 400
neighbor 1.1.1.1 remote-as 400
!
ip route 1.1.1.1 255.255.255.255 10.10.10.2


Solution
In order to solve this problem, either configure the update-source command on both routers,
or remove the update-source command and change the neighbor statement on both routers.
NOTE: You only have to use the update-source command when someone is peering to your loopback address.
This is true for an iBGP peer and an eBGP peer.


The update-source command is configured on both routers:
R1:
router bgp 400
neighbor 2.2.2.2 remote-as 400
neighbor 2.2.2.2 update-source Loopback0
!
ip route 2.2.2.2 255.255.255.255 10.10.10.1

R2:
router bgp 400
neighbor 1.1.1.1 remote-as 400
neighbor 1.1.1.1 update-source Loopback0
!
ip route 1.1.1.1 255.255.255.255 10.10.10.2



The update-source command is removed and the neighbor statement is changed on both routers:
R1:
router bgp 400
neighbor 10.10.10.2 remote-as 400

R2:
router bgp 400
neighbor 10.10.10.1 remote-as 400


Rerences:
https://www.cisco.com/c/en/us/support...
https://www.ciscopress.com/articles/a...

#cisco #ccna #ccnp #ccie