BGP- Authenticating BGP Peerings

BGP authentication is implemented through TCP Option 19, the MD5 hash. 

router bgp 65003
neighbor 155.1.13.1 remote-as 100
neighbor 155.1.13.1 password CISCO

BGP-Neighbor Disable-Connected-Check

One way of resolving non directly connected peer problem is to simply increase the TTL between the peers. In designs where the peers are directly connected but the peering address is a Loopback instead of the connected interface between them, the  disable-connected-check neighbor option may also be used. Although similar in result to increasing the EBGP TTL, the difference between these features is that the  disable-connected-check prevents cases in which the EBGP session between two devices is routed over another transit router.




R1(config-router)#do show run | s bgp
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 65003
 neighbor 3.3.3.3 ebgp-multihop 3
 neighbor 3.3.3.3 disable-connected-check
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

R3(config-router)#do show run | s bgp
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 65001
 neighbor 1.1.1.1 ebgp-multihop 3
 neighbor 1.1.1.1 disable-connected-check
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary
 

 

BGP-Multihop EBGP Peerings

eBGP (external BGP) by default requires two Cisco IOS routers to be directly connected to each other in order to establish a neighbor adjacency. This is because eBGP routers use a TTL of one for their BGP packets. When the BGP neighbor is more than one hop away, the TTL will decrement to 0 and it will be discarded. When these two routers are not directly connected then we can still make it work but we’ll have to use multihop. This requirement does not apply to internal BGP

R2(config-router)#do show run | s bgp

router bgp 200

 no synchronization

 bgp log-neighbor-changes

 neighbor 1.1.1.1 remote-as 100

 neighbor 1.1.1.1 ebgp-multihop 3

 neighbor 1.1.1.1 update-source Loopback0