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).
[email protected]> configure Entering configuration mode [edit] [email protected]# set routing-options autonomous-system 65000 [email protected]# set protocols bgp group Cisco neighbor 1.1.1.2 [email protected]# set protocols bgp group Cisco neighbor 2.2.2.2 [email protected]# set protocols bgp group Cisco peer-as 65000 [email protected]# set protocols bgp group Cisco type internal [email protected]# commit commit complete [edit] [email protected]#
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:
[email protected]> 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 [email protected]>
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 *):
[email protected]> 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 [email protected]>
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:
[email protected]# set int lo0 unit 0 family inet address 192.168.1.1/24 [email protected]# edit policy-options [edit policy-options] [email protected]# set policy-statement ADVERTISE_LO0 from interface lo0 [email protected]# set policy-statement ADVERTISE_LO0 then accept [edit policy-options] [email protected]# exit [edit] [email protected]# set protocols bgp group Cisco export ADVERTISE_LO0 [edit] root@NewYork# commit commit complete [edit] [email protected]#
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:
[email protected]# edit protocols bgp group Cisco [edit protocols bgp group Cisco] [email protected]# set multipath [edit protocols bgp group Cisco] [email protected]# exit [edit] [email protected]# commit commit complete [edit] [email protected]# exit Exiting configuration mode [email protected]> 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 [email protected]> 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 [email protected]>
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.