Pages

CCNP Route: BGP Lab - multihop and maximum-paths

BGP configuration with load sharing over multiple equal-bandwidth routes

BGP multihop - maximum-paths

GNS3 Lab Topology - https://db.tt/7b430RhL

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html

Load balancing is an attempt to process traffic evenly across a network with multiple links.
Load balancing is a more "dynamic" concept in the sense that you want to actively balance the load across two or more active paths.  Typically you want to spread it out as evenly as possible.  Load balancing typically works via a dynamic protocol, such as OSPF, EIGRP, etc.  At the hardware level you do it across port channels, and you can even tweak how you do it, whether it is per packet, per flow, etc.

Load sharing means one can split the traffic from a network to be transported by different routers (paths).
Load sharing is a term used when attempting to share some of the traffic across multiple links.Load sharing is more along what you do with BGP - you can manipulate traffic flows on a static basis, by doing local preference, weight for outbound decisions, and prepending or MED for inbound traffic manipulation(albeit, inbound traffic manipulation is always "best effort" unless your peer agrees to a policy - as they can always override whatever Path Attribute you're sending them)
Load balancing is next to impossible with BGP.  BGP is not concerned with traffic load, delay, etc, it only cares about Path Attributes assigned to NLRIs (aka prefixes).

Very important fact to keep in mind is that any load-sharing/load-balancing configurations are UNI-directional, influencing traffic in one direction. 
If the return traffic had to be balanced in the same manner, the same configuration would be needed in the opposite direction.


Sample config

Route 8.8.8.8/32 (AS8) is available via 2 equal-bandwidth parallel links (AS7): fa0/0 and fa0/1.
R9 will send packets to 8.8.8.8 via R7, and R7 will try to load-share the packets number.


 R7
!
interface Loopback1
 ip address 7.7.7.7 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.252
!
interface FastEthernet0/1
 ip address 10.1.0.1 255.255.255.252
!
interface FastEthernet1/0
 ip address 192.168.1.7 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
 log-adjacency-changes
 redistribute bgp 7 subnets
!
router bgp 7
 no synchronization
 bgp log-neighbor-changes
 network 7.7.7.7 mask 255.255.255.255
 aggregate-address 10.0.0.0 255.0.0.0
 redistribute ospf 1
 neighbor 10.0.0.2 remote-as 8
 neighbor 10.1.0.2 remote-as 8
 no auto-summary
!
R9
!
interface Loopback1
 ip address 9.9.9.9 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.1.9 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
 log-adjacency-changes
!

R8
!
interface Loopback1
 ip address 8.8.8.8 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.252
!
interface FastEthernet0/1
 ip address 10.1.0.2 255.255.255.252
!
router bgp 8
 no synchronization
 bgp log-neighbor-changes
 network 8.8.8.8 mask 255.255.255.255
 aggregate-address 10.0.0.0 255.0.0.0
 neighbor 10.0.0.1 remote-as 7
 neighbor 10.1.0.1 remote-as 7
 no auto-summary
!
Initial (default) BGP behavior, BGP select ONLY the best and installs it in RIB:
R7#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 8.8.8.8/32       10.0.0.2                 0             0 8 i
*                   10.1.0.2                 0             0 8 i

*> 9.9.9.9/32       192.168.1.9              2         32768 ?
*  10.0.0.0         10.0.0.2                 0             0 8 i
*>                  0.0.0.0                            32768 i
*                   10.1.0.2                 0             0 8 i
*> 10.10.10.10/32   10.0.0.2                 0             0 8 i
*                   10.1.0.2                 0             0 8 i



R7#sh ip route
     8.0.0.0/32 is subnetted, 1 subnets
B       8.8.8.8 [20/0] via 10.0.0.2, 00:03:03
     9.0.0.0/32 is subnetted, 1 subnets
O       9.9.9.9 [110/2] via 192.168.1.9, 02:33:36, FastEthernet1/0
     10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
B       10.10.10.10/32 [20/0] via 10.0.0.2, 00:28:11
...

Maximum-paths
R7(config)#router bgp 7
R7(config-router)# maximum-paths 4
R7#sh ip route
     7.0.0.0/32 is subnetted, 1 subnets
C       7.7.7.7 is directly connected, Loopback1
     8.0.0.0/32 is subnetted, 1 subnets
S       8.8.8.8 [1/0] via 10.1.0.2
                [1/0] via 10.0.0.2
     9.0.0.0/32 is subnetted, 1 subnets
O       9.9.9.9 [110/2] via 192.168.1.9, 02:10:21, FastEthernet1/0
     10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
     8.0.0.0/32 is subnetted, 1 subnets
B       8.8.8.8 [20/0] via 10.1.0.2, 00:00:06
                [20/0] via 10.0.0.2, 00:00:06

     10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
B       10.10.10.10/32 [20/0] via 10.1.0.2, 00:25:45
                       [20/0] via 10.0.0.2, 00:25:15
R9#sh ip route
     8.0.0.0/32 is subnetted, 1 subnets
O E2    8.8.8.8 [110/1] via 192.168.1.7, 00:04:58, FastEthernet0/0
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2    10.10.10.10/32 [110/1] via 192.168.1.7, 00:30:36, FastEthernet0/0
O E2    10.0.0.0/8 [110/1] via 192.168.1.7, 00:30:36, FastEthernet0/0
...
R9#
Test the load-sharing from R7 - working OK
R7#ping        
Protocol [ip]:
Target IP address: 8.8.8.8
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback1 
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]: 4
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7
Packet has IP options:  Total option bytes= 19, padded length=20
 Record route: <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)

Reply to request 0 (32 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (7.7.7.7)   <*>  End of list

Reply to request 1 (16 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:   (10.1.0.1)   (8.8.8.8)   (10.1.0.2)   (7.7.7.7)   <*> End of list

Reply to request 2 (16 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (7.7.7.7)   <*> End of list

Reply to request 3 (16 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:   (10.1.0.1)   (8.8.8.8)   (10.1.0.2)   (7.7.7.7)   <*> End of list

Reply to request 4 (16 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (7.7.7.7)   <*> End of list

....ommitedSuccess rate is 100 percent (10/10), round-trip min/avg/max = 12/17/32 ms
R7#

Test the load-sharing from R9 - working OK
Without using a loopback as the update source, within BGP, an IGP would always see the next hop as better through only 1 interface, especially a directly connected interface,   If we use a loopback with an eBGP peer, to give load balancing a chance, that would also involve the eBGP-multihop x statement associated with that neighbor, so in effect the eBGP-multihop is required. (https://learningnetwork.cisco.com/thread/12590)

R9#ping     
Protocol [ip]:
Target IP address: 8.8.8.8  
Repeat count [5]: 6
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 6, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 9.9.9.9
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)   (0.0.0.0)

Reply to request 0 (28 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.1.0.1)   (8.8.8.8)   (10.1.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Reply to request 1 (36 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Reply to request 2 (32 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.1.0.1)   (8.8.8.8)   (10.1.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Reply to request 3 (32 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Reply to request 4 (28 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.1.0.1)   (8.8.8.8)   (10.1.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Reply to request 5 (52 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:   (192.168.1.9)   (10.0.0.1)   (8.8.8.8)   (10.0.0.2)   (192.168.1.7)   (9.9.9.9) <*>   (0.0.0.0)   (0.0.0.0)   (0.0.0.0) End of list

Success rate is 100 percent (6/6), round-trip min/avg/max = 28/34/52 ms
R9#
R9#traceroute 8.8.8.8 probe 10    <-with IP CEF enabled
  1 192.168.1.7 8 msec 20 msec 16 msec 20 msec 20 msec 20 msec 20 msec 16 msec 20 msec 20 msec
  2 10.1.0.2 32 msec 40 msec 28 msec 44 msec 44 msec 36 msec 40 msec 40 msec 40 msec 44 msec
R9#
If IP CEF is disabled on R7 (no ip cef)
R9#traceroute 10.10.10.10 source loopback 1 probe 6
  1 192.168.1.7 8 msec 20 msec 20 msec 20 msec 20 msec 24 msec
  2 10.1.0.2 20 msec
    10.0.0.2 48 msec
    10.1.0.2 40 msec
    10.0.0.2 36 msec
    10.1.0.2 40 msec
    10.0.0.2 44 msec
R9#


Multihop
The use of loopback interfaces, update-source, and ebgp-multihop. The example is a workaround in order to achieve load balancing between two eBGP speakers over parallel serial lines. In normal situations, BGP picks one of the lines on which to send packets, and load balancing does not happen. With the introduction of loopback interfaces, the next hop for eBGP is the loopback interface. You use static routes, or an IGP, to introduce two equal-cost paths to reach the destination.
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#ebgpmulithoploadbal
Test with following config addition
router bgp 7
 neighbor 10.0.0.2 remote-as 8
 neighbor 10.0.0.2 update-source Loopback1
BGP session will be in Active state as default BGP packets have in IP TTL=1
iBGP session IP TTL of 255 by default
eBGP session IP TTL of 1 by default

R7(config)#do bgps
Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4          8     248     247        0    0    0 00:01:25 Active
10.1.0.2        4          8     248     247        0    0    0 00:01:25 Active
So enable multihop on those neighbors

R8(config)#
!
ip route 7.7.7.7 255.255.255.255 10.0.0.1
ip route 7.7.7.7 255.255.255.255 10.1.0.1
!
router bgp 8
no  neighbor 10.0.0.1 remote-as 7
no  neighbor 10.1.0.1 remote-as 7
neighbor 7.7.7.7 remote-as 7
neighbor 7.7.7.7 update-source loopback 1
neighbor 7.7.7.7 ebgp-multihop

R7(config)#
ip route 8.8.8.8 255.255.255.255 10.0.0.2
ip route 8.8.8.8 255.255.255.255 10.1.0.2
!
router bgp 7
no neighbor 10.0.0.2 remote-as 8
no neighbor 10.1.0.2 remote-as 8
no maximum-paths 4
neighbor 8.8.8.8 remote-as 8
neighbor 8.8.8.8 ebgp-multihop 255
neighbor 8.8.8.8 update-source Loopback1

R7(config)#do bgps
Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
8.8.8.8         4          8       4       6        9    0    0 00:00:58        1
R7(config)#
Test load sharing from R7
R7#traceroute 10.10.10.10 source loopback 1 probe 6
  1 10.1.0.2 16 msec
    10.0.0.2 20 msec
    10.1.0.2 16 msec
    10.0.0.2 20 msec
    10.1.0.2 20 msec
    10.0.0.2 24 msec
R7#
Test load sharing from R9
R9#tracerou  10.10.10.10 num probe 6 source loopback 1
  1 192.168.1.7 8 msec 20 msec 20 msec 20 msec 20 msec 20 msec
  2 10.1.0.2 24 msec 32 msec 48 msec 36 msec 44 msec 44 msec
R9#
With Cisco Express Forwarding switching, packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. Traffic destined for different pairs tend to take different paths.  http://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/18285-loadbal-cef.html
Also, traffic originated by router or destined to router is not CEF switched but process switched and process switching does per-packet load-sharing.
With fast switching, per destination switching may result in unequal load sharing because packets to one destination always follow the same path.

If IP CEF is disabled on R7 (no ip cef)
R9#tracerout 10.10.10.10 source loopback 1  probe 6
  1 192.168.1.7 16 msec 16 msec 20 msec 20 msec 20 msec 20 msec
  2 10.1.0.2 20 msec
    10.0.0.2 40 msec
    10.1.0.2 40 msec
    10.0.0.2 40 msec
    10.1.0.2 36 msec
    10.0.0.2 44 msec
R9#