Powered by ESDS®

Announcement

Collapse
No announcement yet.

Use of EBGP Multihop command in BGP (Border Gateway Protocol)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Use of EBGP Multihop command in BGP (Border Gateway Protocol)

    Best Practice while configuring BGP:
    • Configuring iBGP doesn't require the neighbor address to be directly connected.
    • The best practice for iBGP is to use the loopback address as the ip address configured on the BGP neighbor statement. Loopback interfaces never go down so provided that there is an alternate route to the loopback ip address through an IGP, BGP session will not be turn down.
    • Using loopback addresses for eBGP is also a good practice if there are multiple links between two routers on different autonomous system.
    • Scenario created for details explanation with configuration, as shown below diagram. This will also achieve load balancing.


    Click image for larger version

Name:	eBGP-Multihop.jpg
Views:	1
Size:	8.6 KB
ID:	13615

    The initial configuration for this lab is shown below;

    RTR-A#
    !
    interface Serial1/0
    ip address 10.10.10.1 255.255.255.0
    serial restart-delay 0
    end
    !
    interface Serial1/1
    ip address 10.10.20.1 255.255.255.0
    serial restart-delay 0
    end
    !
    interface Loopback0
    ip address 1.1.1.1 255.255.255.255
    !
    router bgp 1
    no synchronization
    bgp log-neighbor-changes
    neighbor 2.2.2.2 remote-as 2
    no auto-summary
    !
    ip route 2.2.2.2 255.255.255.255 10.10.10.2
    ip route 2.2.2.2 255.255.255.255 10.10.20.2

    RTR-B#
    !
    interface Serial1/0
    ip address 10.10.10.2 255.255.255.0
    serial restart-delay 0
    end
    !
    interface Serial1/1
    ip address 10.10.20.2 255.255.255.0
    serial restart-delay 0
    end
    !
    interface Loopback0
    ip address 2.2.2.2 255.255.255.255
    !
    router bgp 2
    no synchronization
    bgp log-neighbor-changes
    neighbor 1.1.1.1 remote-as 1
    no auto-summary
    !
    ip route 1.1.1.1 255.255.255.255 10.10.10.1
    ip route 1.1.1.1 255.255.255.255 10.10.20.1

    Notice that in both routers we put 2 static routes to achieve load balancing. Currently the BGP session is not established even though both loopbacks are reachable.

    The purpose of "ebgp-multihop" is to connect to eBGP neighbors that are not directly connected.As we know, BGP expects eBGP peers to be directly connected but this command will makeneighbor ship possible even though they are not directly connected.
    Now, letís configure "ebgp-multihop" on both routers and see if this will make the BGP session establish.

    RTR-A (config)#router bgp 1
    RTR-A (config-router)#neighbor 2.2.2.2 ebgp-multihop 2

    RTR-B (config)#router bgp 2
    RTR-B (config-router)#neighbor 1.1.1.1 ebgp-multihop 2

    RTR-A #sh ip bgp sum
    BGP router identifier 1.1.1.1, local AS number 1
    BGP table version is 1, main routing table version 1

    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    2.2.2.2 4 2 0 0 0 0 0 never Active
    Result as per current configuration:

    The BGP session is not established even though we configured the "ebgp-multihop" command. Letís troubleshoot why, first discuss the "ebgp-multihop" command.
    • The default value of this command if we don't put anything will be 255.
    • We put a value of 2 because it will take 2 hops to reach 2.2.2.2 from 1.1.1.1 as they are not directly connected.
    • Provided all the requirements are met except the hop count value, if the hop counts value is lesser than what it should be, the eBGP neighborship will not be established.


    Going back to why itís not established, itís because by default for BGP to establish the TCP session it will use the outgoing interface ip address as the source. The other router will reject the incoming TCP SYN packets because it doesn't recognize the source IP address as a configured neighbor. In our case, it will source the TCP session using the two physical interfaces ip addresses.

    Important Note:
    The BGP session updates should be sourced from the IP address that the neighbor configured for eBGP Multihop to work. The command "neighbor ip_address update-source Loopback0" in our example is needed.
    Now letís configure, the update-source command sourcing all BGP negotiations and updates from Loopback0;

    RTR-A(config)#router bgp 1
    RTR-A(config-router)#neighbor 2.2.2.2 update-source Loopback0

    RTR-B(config)#router bgp 2
    RTR-B(config-router)#neighbor 1.1.1.1 update-source Loopback0

    RTR-A#sh ip bgp su
    *Aug 13 14:41:43.175: %SYS-5-CONFIG_I: Configured from console by consolem
    BGP router identifier 1.1.1.1, local AS number 1
    BGP table version is 1, main routing table version 1



    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    2.2.2.2 4 2 11 11 1 0 0 00:00:47 0

    R2#sh ip bgp sum
    *Aug 13 14:41:38.099: %SYS-5-CONFIG_I: Configured from console by console
    BGP router identifier 2.2.2.2, local AS number 2
    BGP table version is 1, main routing table version 1

    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    1.1.1.1 4 1 11 11 1 0 0 00:00:42 0
    Waw!!! BGP session now established. We can see in CEF that this is load balanced.

    RTR-A#sh ip cef 2.2.2.2
    2.2.2.2/32, version 27, epoch 0, per-destination sharing
    0 packets, 0 bytes
    via 10.10.20.2, 0 dependencies, recursive
    traffic share 1
    next hop 10.10.20.2, Serial1/1 via 10.10.20.0/24
    valid adjacency
    via 10.10.10.2, 0 dependencies, recursive
    traffic share 1
    next hop 10.10.10.2, Serial1/0 via 10.10.10.0/24
    valid adjacency
    0 packets, 0 bytes switched through the prefix
    tmstats: external 0 packets, 0 bytes
    internal 0 packets, 0 bytes
    Now, BGP session is established. Let's try shutting down one link and see if the session is still established.
    RTR-B(config)#int se1/0
    RTR-B(config-if)#shut
    RTR-B(config-if)#^Z
    RTR-B#sh ihp b
    *Aug 13 14:42:38.871: %SYS-5-CONFIG_I: Configured from console by console
    *Aug 13 14:42:39.095: %LINK-5-CHANGED: Interface Serial1/0, changed state to administrativ
    *Aug 13 14:42:39.095: %ENTITY_ALARM-6-INFO: ASSERT INFO Se1/0 Physical Port Administrative State Down
    *Aug 13 14:42:40.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
    R2#sh ip bgp sum
    BGP router identifier 2.2.2.2, local AS number 2
    BGP table version is 1, main routing table version 1

    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    1.1.1.1 4 1 12 12 1 0 0 00:01:45 0
    GOOOD!!!
    BGP session still established.Thatís all about EBGP Multihop feature.

    Bharatkumar
    -Sr.Network Engineer-ESDS
    Attached Files
ban-img
Working...
X