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