BGP DMZ Link Bandwidth

Leave a Comment / BGP, Cisco, DMZ Link Bandwidth, Networking, Routing Protocols / By /

BGP allows you to distribute traffic over paths that have different bandwidth. This is different from the unequal cost load balancing that EIGRP can perform, as it is not based on the route’s metric. Instead, it is based on a calculation of your neighbor’s link bandwidth that is configured to use this feature. Let’s take a look at the topology we are going to use for this scenario.

So in the above topology, we have R1 connected point-to-point to R2, R3, and R4, all of which have different link bandwidths, as stated in the above diagram.

I have taken care of the base BGP configuration and the speed configuration on the point-to-point frame-relay links on R2, R3, and R4. R1 is advertising its loopback0 interfaces into BGP AS100, while R5 is advertising its loopback0 interface into BGP AS2345. I did this so we can see the load balancing happening.

Here are the BGP configurations for R1 – R5 and the interface configurations for R2 – R4.

Configuration

R1 BGP Configuration

router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 10.1.12.2 remote-as 2345
neighbor 10.1.13.3 remote-as 2345
neighbor 10.1.14.4 remote-as 2345
no auto-summary

R2 BGP Configuration

router bgp 2345
no synchronization
bgp log-neighbor-changes
neighbor 10.1.12.1 remote-as 100
neighbor 172.16.234.5 remote-as 2345
neighbor 172.16.234.5 next-hop-self
no auto-summary

R2 Interface Configuration

interface Serial0/0.21 point-to-point
bandwidth 64
ip address 10.1.12.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 201

R3 BGP Configuration

router bgp 2345
no synchronization
bgp log-neighbor-changes
neighbor 10.1.13.1 remote-as 100
neighbor 172.16.234.5 remote-as 2345
neighbor 172.16.234.5 next-hop-self
no auto-summary

R3 Interface Configuration

interface Serial0/0/0.31 point-to-point
bandwidth 256
ip address 10.1.13.3 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 301

R4 BGP Configuration

router bgp 2345
no synchronization
bgp log-neighbor-changes
neighbor 10.1.14.1 remote-as 100
neighbor 172.16.234.5 remote-as 2345
neighbor 172.16.234.5 next-hop-self
no auto-summary

R4 Interface Configuration

interface Serial0/0/0.41 point-to-point
bandwidth 128
ip address 10.1.14.4 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 401

R5 BGP Configuration

router bgp 2345
no synchronization
bgp log-neighbor-changes
network 5.5.5.5 mask 255.255.255.255
neighbor 172.16.234.2 remote-as 2345
neighbor 172.16.234.3 remote-as 2345
neighbor 172.16.234.4 remote-as 2345
no auto-summary

Verify BGP Table

As we would suspect, the R5 BGP process has chosen the best path to R1’s loopback0 interface. In this instance, the best path is going over R2, as shown in the command below.

R5#sh ip bgp 1.1.1.1 255.255.255.255
BGP routing table entry for 1.1.1.1/32, version 3
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
100
172.16.234.4 from 172.16.234.4 (172.16.234.4)
Origin IGP, metric 0, localpref 100, valid, internal
100
172.16.234.2 from 172.16.234.2 (10.1.12.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
100
172.16.234.3 from 172.16.234.3 (172.16.234.3)
Origin IGP, metric 0, localpref 100, valid, internal
R5#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 2345", distance 200, metric 0
Tag 100, type internal
Last update from 172.16.234.2 00:08:26 ago
Routing Descriptor Blocks:
* 172.16.234.2, from 172.16.234.2, 00:08:26 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100

So, what if we are tasked to use all three links? Without any unique configuration, BGP can not accomplish this. But if we use BGP dmzlink-bw, this can be accomplished.

Configure BGP DMZLink-BW

The configuration is pretty straightforward. If we take our topology and cut R2 – 4 down the middle, on the side facing R1, we enable the BGP dmzlink-bw command and an IPv4 address family mode, and we activate that neighbor and enable them for the feature. Facing R5, we have to activate the neighbor and set it up so that the router sends extended communities to R5. Let us look at the configuration on R2 (it will be the same for R3 and R4).

R2(config)#router bgp 2345
R2(config-router)#address-family ipv4 unicast
R2(config-router-af)#bgp dmzlink-bw
R2(config-router-af)#neighbor 10.1.12.1 activate
R2(config-router-af)#neighbor 10.1.12.1 dmzlink-bw
R2(config-router-af)#neighbor 172.16.234.5 activate
R2(config-router-af)#neighbor 172.16.234.5 send-community extended

These commands will repeat on R3 and R4 for their respective neighbors.

Verify BGP Table

Now, if we look at a new line in it, referencing the DMZ-Link Bw.

R5#sh ip bgp 1.1.1.1 255.255.255.255
BGP routing table entry for 1.1.1.1/32, version 4
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
100
172.16.234.4 from 172.16.234.4 (172.16.234.4)
Origin IGP, metric 0, localpref 100, valid, internal
DMZ-Link Bw 16 kbytes
100
172.16.234.2 from 172.16.234.2 (10.1.12.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
DMZ-Link Bw 8 kbytes
100
172.16.234.3 from 172.16.234.3 (172.16.234.3)
Origin IGP, metric 0, localpref 100, valid, internal
DMZ-Link Bw 32 kbytes

*Note: you may have to reset the BGP session on R5 soft to see the settings take effect.

Verify Routing Table

So, if we look at the routing table, we should see three paths to 1.1.1.1 with different traffic share numbers. Let’s take a look.

R5#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 2345", distance 200, metric 0
Tag 100, type internal
Last update from 172.16.234.2 00:19:34 ago
Routing Descriptor Blocks:
* 172.16.234.2, from 172.16.234.2, 00:19:34 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100

So, what is missing here is the maximum-paths that BGP is allowed to use. If we look at show ip protocols, we will see that BGP only allows one path to a destination by default.

R5#sh ip protocols
Routing Protocol is "bgp 2345"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
172.16.234.2
172.16.234.3
172.16.234.4
Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
172.16.234.2 200 00:20:26
Distance: external 20 internal 200 local 200

So how do we fix it? This is an iBGP route. We can raise the maximum prefix count for iBGP to 3.

R5(config)#router bgp 2345
R5(config-router)#maximum-paths ibgp 3

Let’s see if that fixed it:

R5#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 2345", distance 200, metric 0
Tag 100, type internal
Last update from 172.16.234.3 00:01:44 ago
Routing Descriptor Blocks:
* 172.16.234.4, from 172.16.234.4, 00:01:44 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
172.16.234.3, from 172.16.234.3, 00:01:44 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
172.16.234.2, from 172.16.234.2, 00:01:44 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100

It shows the three paths to the destination, but they have a traffic share value of 1. What is missing? Let’s see if we enabled BGP dmzlink-bw on R5:

R5#sh run | sect router bgp
router bgp 2345
no synchronization
bgp log-neighbor-changes
network 5.5.5.5 mask 255.255.255.255
neighbor 172.16.234.2 remote-as 2345
neighbor 172.16.234.3 remote-as 2345
neighbor 172.16.234.4 remote-as 2345
maximum-paths ibgp 3
no auto-summary

It looks like we did not add it. Let’s add it and see what happens:

R5(config)#router bgp 2345
R5(config-router)#bgp dmzlink-bw

*Note: this may require hard resetting the BGP sessions

Now, if we look at the routing table,

R5#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 2345", distance 200, metric 0
Tag 100, type internal
Last update from 172.16.234.3 00:03:22 ago
Routing Descriptor Blocks:
172.16.234.4, from 172.16.234.4, 00:03:22 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
172.16.234.3, from 172.16.234.3, 00:03:22 ago
Route metric is 0, traffic share count is 3
AS Hops 1
Route tag 100
* 172.16.234.2, from 172.16.234.2, 00:03:22 ago
Route metric is 0, traffic share count is 30
AS Hops 1
Route tag 100

Verify Traffic Distribution with a Counting Access List

We see that network 1.1.1.1 is being load-shared between all neighbors. Now, how do we verify this is working? On R2 – 4, we will create an access-list matching the source address of 5.5.5.5 and the destination address of 1.1.1.1 and tie it to an access group on the frame-relay interfaces.
On R2-4, the configuration will be

# Router 2 Config
R2(config)#access-list 100 permit icmp host 5.5.5.5 host 1.1.1.1 log
R2(config)#access-list 100 permit ip any any
R2(config)#int f0/0
R2(config-if)#ip access-group 100 in

# Router 3 Config
R3(config)#access-list 100 permit icmp host 5.5.5.5 host 1.1.1.1 log
R3(config)#access-list 100 permit ip any any
R3(config)#int f0/0
R3(config-if)#ip access-group 100 in

# Router 4 Config
R4(config)#access-list 100 permit icmp host 5.5.5.5 host 1.1.1.1 log
R4(config)#access-list 100 permit ip any any
R4(config)#int f0/0
R4(config-if)#ip access-group 100 in

Now we send 10000 pings from R5 to R1 and look at how the load was distributed over the links (to get the results I wanted, I changed the load sharing to per packet)

So out of those 10000 pings, we see the following.

R2#sh access-list | inc 10.per
10 permit icmp host 5.5.5.5 host 1.1.1.1 log (8750 matches)
R3#sh access-list | inc 10.per
10 permit icmp host 5.5.5.5 host 1.1.1.1 log (625 matches)
R4#sh access-list | inc 10.per
10 permit icmp host 5.5.5.5 host 1.1.1.1 log (625 matches)

R2 sent the bulk of traffic, while R3 and R4 sent the same amount. We can also check CEF to see how the packet will be sent.

R5#sh ip cef 1.1.1.1 internal
1.1.1.1/32, version 13, epoch 0, per-packet sharing
0 packets, 0 bytes
via 172.16.234.4, 0 dependencies, recursive
traffic share 1, current path
next hop 172.16.234.4, FastEthernet0/0 via 172.16.234.4/32
valid adjacency
via 172.16.234.3, 0 dependencies, recursive
traffic share 3
next hop 172.16.234.3, FastEthernet0/0 via 172.16.234.3/32
valid adjacency
via 172.16.234.2, 0 dependencies, recursive
traffic share 30
next hop 172.16.234.2, FastEthernet0/0 via 172.16.234.2/32
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
Load distribution: 0 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (refcount 1)
Hash OK Interface Address Packets
1 Y FastEthernet0/0 172.16.234.4 0
2 Y FastEthernet0/0 172.16.234.3 0
3 Y FastEthernet0/0 172.16.234.2 0
4 Y FastEthernet0/0 172.16.234.2 0
5 Y FastEthernet0/0 172.16.234.2 0
6 Y FastEthernet0/0 172.16.234.2 0
7 Y FastEthernet0/0 172.16.234.2 0
8 Y FastEthernet0/0 172.16.234.2 0
9 Y FastEthernet0/0 172.16.234.2 0
10 Y FastEthernet0/0 172.16.234.2 0
11 Y FastEthernet0/0 172.16.234.2 0
12 Y FastEthernet0/0 172.16.234.2 0
13 Y FastEthernet0/0 172.16.234.2 0
14 Y FastEthernet0/0 172.16.234.2 0
15 Y FastEthernet0/0 172.16.234.2 0
16 Y FastEthernet0/0 172.16.234.2 0

So the hashing algorithm worked out: R4 gets 1 out of 16 packets, R3 gets 1 out of 16 packets, and R2 gets 14 out of 16 packets.