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.