BGP Load Balancing with Cisco IOS and Junos

Today we are going to do some BGP load balancing between a Cisco router and a Juniper router.

We have a very simple topology:

The Juniper router (JUNOS1) is called NewYork and the Cisco router (R1) is called London.

We have two connections between them 1.1.1.1/24 on the Juniper to 1.1.1.2/24 on the Cisco, and 2.2.2.1 on the Juniper to 2.2.2.2 on the Cisco. We will be using AS 65000 for the BGP AS.

For the Juniper basic configuration please check out these two posts:

Juniper router emulation in GNS3
Basic Juniper Router commands

What is BGP Load Balancing?

Load balancing can use two or more connections to send data to the same destination. Load balancing in BGP requires that we enable multi-pathing, so that the router knows that it can use more than one path at a time.

We will start with the basic BGP configuration and from there advertise a loopback network on each side, then we will set up multi-pathing.

Cisco IOS BGP setup

I won’t explain all the Cisco steps as they shouldn’t be anything new – but there are links to my book here. Shameless plug I know!

London(config)#router bgp 65000
London(config-router)#neighbor 1.1.1.1 remote-as 65000
London(config-router)#neighbor 2.2.2.1 remote-as 65000
London(config-router)#exit
London(config)#exit
London#

Juniper JunOS BGP setup

For the JunOS set up we will create the BGP AS under routing options, and then create a group called Cisco to add the two peerings to the Cisco router to, setting the AS number to match our own, and the type to be internal (iBGP).

root@NewYork> configure
Entering configuration mode

[edit]
root@NewYork# set routing-options autonomous-system 65000
root@NewYork# set protocols bgp group Cisco neighbor 1.1.1.2
root@NewYork# set protocols bgp group Cisco neighbor 2.2.2.2
root@NewYork# set protocols bgp group Cisco peer-as 65000
root@NewYork# set protocols bgp group Cisco type internal
root@NewYork# commit
commit complete

[edit]
root@NewYork#

At this stage our BGP peers should come up:

London#
*Apr 21 13:19:18.087: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
London#
*Apr 21 13:19:22.227: %BGP-5-ADJCHANGE: neighbor 2.2.2.1 Up
London#

We can confirm this by looking at the bgp neighbors on the NewYork router:

root@NewYork> show bgp neighbor
Peer: 1.1.1.2+46617 AS 65000   Local: 1.1.1.1+179 AS 65000
  Type: Internal    State: Established    Flags: 
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: 
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 2.2.2.2         Local ID: 1.1.1.1      Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 0   
  BFD: disabled, down
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Peer does not support Receiver functionality
  Peer supports 4 byte AS extension (peer-as 65000)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              1
    Received prefixes:            1     
    Accepted prefixes:            1
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 15   Sent 22   Checked 40  
  Input messages:  Total 8 Updates 2  Refreshes 0  Octets 226
  Output messages: Total 7 Updates 0  Refreshes 0  Octets 173
  Output Queue[0]: 0

Peer: 2.2.2.2+179 AS 65000     Local: 2.2.2.1+51595 AS 65000
  Type: Internal    State: Established    Flags: 
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: 
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 2.2.2.2         Local ID: 1.1.1.1      Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 1   
  BFD: disabled, down
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Peer does not support Receiver functionality
  Peer supports 4 byte AS extension (peer-as 65000)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            1
    Accepted prefixes:            1
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 13   Sent 21   Checked 35  
  Input messages:  Total 5 Updates 2  Refreshes 0  Octets 135
  Output messages: Total 6 Updates 0  Refreshes 0  Octets 154
  Output Queue[0]: 0

root@NewYork>

Advertising BGP prefixes in Cisco IOS and Juniper JunOS

Now we can add our loopback interfaces, and advertise them into BGP:

London(config)#int lo0
London(config-if)#ip add 172.20.1.1 255.255.255.0
London(config-if)#router bgp 65000
London(config-router)#network 172.20.1.0 mask 255.255.255.0
London(config-router)#

NewYork sees the route coming from both peering sessions, it prefers the one with the lower IP address (denoted by a *):

root@NewYork> show route
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.0/24         *[Direct/0] 01:08:36
                    > via em0.0
1.1.1.1/32         *[Local/0] 01:08:36
                      Local via em0.0
2.2.2.0/24         *[Direct/0] 01:08:36
                    > via em1.0
2.2.2.1/32         *[Local/0] 01:08:36
                      Local via em1.0
172.20.1.0/24      *[BGP/170] 00:01:20, MED 0, localpref 100
                      AS path: I
                    > to 1.1.1.2 via em0.0
                    [BGP/170] 00:01:20, MED 0, localpref 100
                      AS path: I
                    > to 2.2.2.2 via em1.0

root@NewYork>

Now let’s add a loopback interface on the NewYork router and advertise it in BGP as well. The process isn’t exactly as straight forward in JunOS, all advertisement is done through policy statements, which is then used to export (advertise to BGP neighbors) based on the specified group:

root@NewYork# set int lo0 unit 0 family inet address 192.168.1.1/24
root@NewYork# edit policy-options                                      

[edit policy-options]
root@NewYork# set policy-statement ADVERTISE_LO0 from interface lo0    
root@NewYork# set policy-statement ADVERTISE_LO0 then accept 

[edit policy-options]
root@NewYork# exit 

[edit]
root@NewYork# set protocols bgp group Cisco export ADVERTISE_LO0       

[edit]
root@NewYork# commit 
commit complete

[edit]
root@NewYork# 

And if all is well then the London router should see the new prefix:

London#sh ip route | beg Gate
Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, GigabitEthernet1/0
L        1.1.1.2/32 is directly connected, GigabitEthernet1/0
      2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        2.2.2.0/24 is directly connected, GigabitEthernet2/0
L        2.2.2.2/32 is directly connected, GigabitEthernet2/0
      172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.20.1.0/24 is directly connected, Loopback0
L        172.20.1.1/32 is directly connected, Loopback0
B     192.168.1.0/24 [200/0] via 1.1.1.1, 00:00:15
London#

It does, again choosing the router with the lower IP address. Now let’s set up load balancing.

Enabling load balancing for BGP in Cisco IOS

Enabling load balancing in BGP on Cisco IOS is as simple as enabling the maximum-paths option.

London(config-router)#maximum-paths ibgp 2
London(config-router)#do sh ip route | beg Gate
Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, GigabitEthernet1/0
L        1.1.1.2/32 is directly connected, GigabitEthernet1/0
      2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        2.2.2.0/24 is directly connected, GigabitEthernet2/0
L        2.2.2.2/32 is directly connected, GigabitEthernet2/0
      172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.20.1.0/24 is directly connected, Loopback0
L        172.20.1.1/32 is directly connected, Loopback0
B     192.168.1.0/24 [200/0] via 2.2.2.1, 00:00:02
                     [200/0] via 1.1.1.1, 00:00:02
London(config-router)#do sh ip bgp
BGP table version is 5, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.20.1.0/24    0.0.0.0                  0         32768 i
*mi192.168.1.0      1.1.1.1                       100      0 i
*>i                 2.2.2.1                       100      0 i
London(config-router)#

So our London router has now installed two paths into the routing table, courtesy of the maximum-paths command. Let’s configure the same on the NewYork router.

Enabling load balancing for BGP in Juniper JunOS

Similarly to the Cisco IOS all we need to do with JunOS is to enable multipath under our BGP peer group:

root@NewYork# edit protocols bgp group Cisco
[edit protocols bgp group Cisco]
root@NewYork# set multipath 

[edit protocols bgp group Cisco]
root@NewYork# exit 

[edit]
root@NewYork# commit 
commit complete

[edit]
root@NewYork# exit 
Exiting configuration mode

root@NewYork> show route 172.20.1.0    

inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.20.1.0/24   *[BGP/170] 00:24:56, MED 0, localpref 100, from 1.1.1.2
                   AS path: I
                   to 1.1.1.2 via em0.0
                 > to 2.2.2.2 via em1.0
                 [BGP/170] 00:11:42, MED 0, localpref 100
                   AS path: 
                 > to 2.2.2.2 via em1.0

root@NewYork> show route 172.20.1.0 detail 

inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
172.20.1.0/24 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x9408078
                Next-hop reference count: 2
                Source: 1.1.1.2
                Next hop type: Router, Next hop index: 520
                Next hop: 1.1.1.2 via em0.0
                Next hop type: Router, Next hop index: 554
                Next hop: 2.2.2.2 via em1.0, selected
                Protocol next hop: 1.1.1.2
                Indirect next hop: 9384000 131071
                Protocol next hop: 2.2.2.2
                Indirect next hop: 93840e8 131070
                State: 
                Local AS: 65000 Peer AS: 65000
                Age: 18:57  Metric: 0  Metric2: 0 
                Task: BGP_65000.1.1.1.2+19079
                Announcement bits (2): 0-KRT 3-Resolve tree 1 
                AS path: I
                Accepted Multipath
                Localpref: 100          
                Router ID: 172.20.1.1
         BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x93345f8
                Next-hop reference count: 2
                Source: 2.2.2.2
                Next hop type: Router, Next hop index: 554
                Next hop: 2.2.2.2 via em1.0, selected
                Protocol next hop: 2.2.2.2
                Indirect next hop: 93840e8 131070
                State: 
                Inactive reason: Not Best in its group - Update source
                Local AS: 65000 Peer AS: 65000
                Age: 2:13  Metric: 0  Metric2: 0 
                Task: BGP_65000.2.2.2.2+45024
                AS path: I
                Accepted MultipathContrib
                Localpref: 100
                Router ID: 172.20.1.1

root@NewYork>

Here we can see that also with just the setting up of multipathing our Juniper router will also now load-balanced – the “show route 172.20.1.0 detail” shows this with it’s two next hop addresses and also the line “Accepted Multipath”.

We can actually do a lot more with load-balancing, we can use unequal bandwidth to load-balance according to the resources at our disposal, or load-balance on a per-packet basis, but as far as simple load-balancing goes, this is pretty much it. It’s not hard to set up as I hope this post has shown.