Friday, August 23, 2013

External BGP neighbors multihop peering

eBGP Multihop


Very often in SP scenarios as in the Enterprise the external BGP peerings are often using IP subnet that is not directly connected. This is because of the best practice of using the Loopback interfaces on Cisco and Junos routers, as they are always up. In case of failures in the copper and optic interfaces there is always an alternative path to the BGP loopback address. The loopback address is always used as the router-id.

I have configured this simple scenario to demonstrate how to perform BGP peering with only external eBGP neighbors that do not allow direct explicit BGP neighbor connections.


This small scenario demonstrates particular connection with a private AS 65535 and the global AS 100. Here as follows are loopback IP addresses and static routes between the R4 and ISP routers. It is always best practice to establish a static route between eBGP neighbors because of the lowest AD.

R4#sh running-config interface loopback 0
interface Loopback0
 ip address 11.11.11.11 255.255.255.0

R4#sh running-config | include ip route
ip route 10.0.0.1 255.255.255.255 172.17.1.1

ISP1#sh running-config interface loopback 0
interface Loopback0
 ip address 10.0.0.1 255.255.255.255

ISP1#sh run | include ip route
ip route 11.11.11.0 255.255.255.0 172.17.1.2

We can now ping ther eBGP peers. In the replies below we can see that the eBGP peers have no problems with the ICMP traffic and that the BGP session can be initiated on the TCP 179 port.

ISP1#ping 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/60 ms


R4#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/44 ms

Next step, after evaulating the successfull traffic control and data plane between the eBGP routers is to define the basic BGP configurations. We have to define the AS number, and the neighbor remote AS and IP address. The local update source of the BGP messages will be the loopback 0 address on both routers. This interface will be used to send and receive the Hello, Update and ACK messagess.

R4#sh running-config | section bgp
router bgp 65535
 no synchronization
 bgp log-neighbor-changes
 network 11.11.12.0 mask 255.255.255.0
 neighbor 10.0.0.1 remote-as 100
 neighbor 10.0.0.1 update-source Loopback0
 no auto-summary

ISP1#sh running-config | section bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 11.11.11.11 remote-as 65535
 neighbor 11.11.11.11 update-source Loopback0
 no auto-summary

After this basic config we must verify the eBGP session. If we wait for the neighbor bring the UP state, that will not happen as we can see in the troubleshoot output.


ISP1#sh ip bgp summary
BGP router identifier 10.0.0.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4 65535       0           0           0         0      0           never          Idle

R4#sh ip bgp summary
BGP router identifier 11.11.11.11, local AS number 65535
BGP table version is 2, main routing table version 2
1 network entries using 117 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 417 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1           4   100       0              0          0          0       0        never         Idle

Now we have a problem. The neighbors are in idle state and not UP. So the exchange of the BGP informations cannot continue. We have reacheability via static routes but no eBGP session. 
Now the ebgp-multihop 2 command kicks in. Using this config we are telling the BGP speaking router that the eBGP neighbor is 2 hops away. This is true, since we are using a static route to the lo0 interface.

R4(config-router)#neighbor 10.0.0.1 ebgp-multihop 2
ISP1(config-router)#neighbor 11.11.11.11 ebgp-multihop 2


And after a couple of seconds we have a neighbor in the UP state.
*Mar  1 02:22:10.415: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Up

The summary shows us that we are receiving one prefix from the R4 router and that the session is ok now !!!
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4 65535       5           4          2          0        0 00:00:46                   1

The received prefix is the one that is advertised in the bgp configs on the R4 router. 

ISP1#show ip bgp
BGP table version is 2, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.12.0/24    11.11.11.11              0             0 65535 


To test the eBGP control and data plane we can ping a network learned via eBGP with the source of the loopback interface defined at the ISP router.

ISP1#ping 11.11.12.1 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.12.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/28 ms



We have a succesfull ping. This is cool. Many other security features in this scenario can be used. One of them is the TTL security feature that can prevent of mis-using the multihop feature. 
That top will be explained on future blogs.

Thanks!

No comments:

Post a Comment