Wednesday, April 8, 2015

eBGP Peering

External BGP peers exchange Network Layer Reachability Information (NLRI) between different autonomous systems (AS). It may be Internet Service Providers (ISP) exchanging prefixes with each other or maybe a large enterprise peering with multiple ISPs.

The main loop prevention mechanism of eBGP is simply to not accept updates containing its own AS number. The AS number is recorded in the AS_SEQ and AS_SET attributes and if a router receives an update containing its own AS number in these attributes, the update is ignored.

The command neighbor <ip address> remote-as <asn> under the BGP process is all it takes to configure a peer and the external/internal decision is based on a comparison of the BGP process ID on the local router and the AS number (ASN) configured in the "remote-as" part of the command, for the peer - if they differ, they will be eBGP peers.

Unlike iBGP peers, the default TTL of packets going between eBGP peers is 1, which means that eBGP peers must be directly connected to form a neighbor relationship. This behaviour can be altered in multiple ways:

The command neighbor <ip address> ebgp-multihop [ttl] will manually set the TTL of the BGP packets sent to that neighbor - so if the neighbor is 5 hops away the command neighbor <ip address> ebgp-multihop 5 would allow the packet to have TTL high enough to traverse the network - a higher TTL would also be allowed.

The command neighbor ttl-security hops [ttl] does the same as the previous, but in a slightly different and more secure way. If, again, the peers are 5 hops apart the command neighbor ttl-security hops 5 would both make the router send a packet with a TTL of 255 as well as expect a packet from the peer, which started with a TTL of 255 and then decremented by 5 hops - if a packet is received with a different TTL value it will be dropped by the router - thus making this a more secure solution.

These two commands are mutually exclusive.

If the need for higher TTL is due to the fact that the eBGP peers use loopback interfaces for peering, but are still directly connected, then the command neighbor <ip address> disable-connected-check will allow for them to connect without tampering with the TTL of the packets.

Below is an example eBGP configuration between two routers.

eBGP peering between R1 and R2


R1 Config
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet1
 no shutdown
!
interface GigabitEthernet1.12
 encapsulation dot1Q 12
 ip address 140.1.12.1 255.255.255.0
!
interface GigabitEthernet1.21
 encapsulation dot1Q 21
 ip address 140.1.21.1 255.255.255.0
!
router bgp 1.1
 bgp asnotation dot
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2.2
 neighbor 2.2.2.2 disable-connected-check
 neighbor 2.2.2.2 update-source Loopback0
!
ip route 2.2.2.2 255.255.255.255 140.1.12.2
ip route 2.2.2.2 255.255.255.255 140.1.21.2
R2 Config
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1
 no shutdown
!
interface GigabitEthernet1.12
 encapsulation dot1Q 12
 ip address 140.1.12.2 255.255.255.0
!
interface GigabitEthernet1.21
 encapsulation dot1Q 21
 ip address 140.1.21.2 255.255.255.0
!
router bgp 2.2
 bgp asnotation dot
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1.1
 neighbor 1.1.1.1 disable-connected-check
 neighbor 1.1.1.1 update-source Loopback0
!
ip route 1.1.1.1 255.255.255.255 140.1.12.1
ip route 1.1.1.1 255.255.255.255 140.1.21.1
The routers are connected with two direct links between each other for redundancy. As seen in the config examples above, the configuration uses the loopback interfaces for peering and the disable-connected-check feature.

No comments:

Post a Comment