BGP DMZ Link Bandwidth

dear:

could you make video solution for this one

I sure will, hopefully it's done in December (that will be a nice Xmas present )

Awesome job..keep up the good work and add more videos..

-bava

Hello Rene!

Thanks for this great lab and making it available for all of us to attempt and learn from!

I went over this scenario and for the sake of clarity I believe the final bullet point may need to be revised or perhaps the final solution may be revised to meet the criteria.

"Ensure traffic from router Athens is load balanced proportionally over all available links."

At the end of the scenario only 2 of the 3 WAN links are being used in BGP unequal cost load balancing.

This can be verified by running an extended ping from Athens to an address in the 192.168.45.0/24 subnet. Verification can also be had by checking the routing tables on Athens and Sparta to any network advertised by BGP AS 2.

Traffic will be sent to Delphi (3.3.3.3) and (Sparta) 2.2.2.2 in a 1:10 ratio respectively if the preferred route to the 192.168.45.0/24 subnet is advertised from Sparta, reachable via the FastEthernet1/0 interface or 240:37 before shutting the serial2/0 interface as demonstrated in your video (at this point, to meet the criteria of your lab, packets are routing as desired):

Athens#show ip route 192.168.45.0
Routing entry for 192.168.45.0/24
Known via "bgp 1", distance 200, metric 0
Tag 2, type internal
Last update from 3.3.3.3 005:40 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 3.3.3.3, 005:40 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2
2.2.2.2, from 2.2.2.2, 005:40 ago
Route metric is 0, traffic share count is 10
AS Hops 1
Route tag 2

The problem that is preventing all 3 WAN links from being utilized can be found via Sparta's routing table:

Sparta#show ip route 192.168.45.0 255.255.255.0
Routing entry for 192.168.45.0/24
Known via "bgp 1", distance 20, metric 0
Tag 2, type external
Last update from 192.168.24.4 000:32 ago
Routing Descriptor Blocks:
* 192.168.24.4, from 192.168.24.4, 000:32 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2

To remedy this issue we can use the router-configuration command "maximum-paths 2" to allow multiple eBGP paths to be selected for a route. Furthermore the current dmzlink-bw configuration will provide the unequal cost load balancing:

Sparta#show run | s bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
bgp dmzlink-bw
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 1.1.1.1 send-community extended
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
neighbor 192.168.24.4 remote-as 2
neighbor 192.168.24.4 dmzlink-bw
neighbor 192.168.25.5 remote-as 2
neighbor 192.168.25.5 dmzlink-bw
maximum-paths 2
no auto-summary

Following the maximum-paths 2 command the new routing paths can be verified via Sparta's routing table:

Sparta#show ip route 192.168.45.0
Routing entry for 192.168.45.0/24
Known via "bgp 1", distance 20, metric 0
Tag 2, type external
Last update from 192.168.24.4 000:26 ago
Routing Descriptor Blocks:
* 192.168.25.5, from 192.168.25.5, 007:30 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2
192.168.24.4, from 192.168.24.4, 000:26 ago
Route metric is 0, traffic share count is 60
AS Hops 1
Route tag 2

Sparta#show ip bgp 192.168.45.0
BGP routing table entry for 192.168.45.0/24, version 11
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x800
Advertised to update-groups:
1 2 3
2
192.168.24.4 from 192.168.24.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, multipath
DMZ-Link Bw 12500 kbytes
2
192.168.35.5 (inaccessible) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
2
192.168.25.5 from 192.168.25.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, external, multipath, best
DMZ-Link Bw 193 kbytes

For the best 'visual' verification an extended ping can be run on Athens to verify the traffic path. Due to the 60:1 ratio of the current bandwidth settings the following is just a snipped of all 3 WAN links being traversed. I used a repeat count of 120 to demonstrate the load balancing ratios:

Athens#ping
Protocol [ip]:
Target IP address: 192.168.45.5
Repeat count [5]: 120
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
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 ]: 7
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 120, 100-byte ICMP Echos to 192.168.45.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet has IP options: Total option bytes= 31, padded length=32

Reply to request 0 (40 ms). Received packet has options
Total option bytes= 32, padded length=32
Record route:
(192.168.123.1)
(192.168.35.3)
(192.168.45.5)
(192.168.35.5)
(192.168.123.3)
(1.1.1.1)
(0.0.0.0)
End of list

Reply to request 1 (56 ms). Received packet has options
Total option bytes= 32, padded length=32
Record route:
(192.168.123.1)
(192.168.25.2)
(192.168.45.5)
(192.168.35.5)
(192.168.123.3)
(1.1.1.1)
(0.0.0.0)
End of list

Reply to request 2 (52 ms). Received packet has options
Total option bytes= 32, padded length=32
Record route:
(192.168.123.1)
(192.168.24.2)
(192.168.45.4)
(192.168.45.5)
(192.168.35.5)
(192.168.123.3)
(1.1.1.1)

End of list

--

I hope that helps clear up any questions other may have had about the final solution to this well put together lab.

Cheers!

-Justin

Hello Justin thanks for sharing this and pointing it out to me, good to see you share your knowledge with us