BGP DMZ Link Bandwidth

6 Comments

1. dear:

   could you make video solution for this one 🙂

2. I sure will, hopefully it’s done in December (that will be a nice Xmas present 😀 )

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

   -bava

4. 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.

   [i]"Ensure traffic from router Athens is load balanced proportionally over all available links."[/i]

   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 00:05:40 ago
   Routing Descriptor Blocks:
   * 3.3.3.3, from 3.3.3.3, 00:05: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, 00:05: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 00:00:32 ago
   Routing Descriptor Blocks:
   * 192.168.24.4, from 192.168.24.4, 00:00: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 00:00:26 ago
   Routing Descriptor Blocks:
   * 192.168.25.5, from 192.168.25.5, 00:07: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, 00:00: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)
   [color=blue](192.168.35.3)[/color]
   (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)
   [color=blue](192.168.25.2)[/color]
   (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)
   [color=blue](192.168.24.2)[/color]
   (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.

   [b]Cheers![/b]

   -Justin

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

5. this lab aided me in determining the difference btwn BGP max paths and BGP DMZ link.

   here is a good link to this topic and on the “PING REPORT” Justin K used in his comment:
   http://blog.ine.com/2010/04/06/move-over-variance-bgp-proportional-load-balancing-is-here/

   typing in all the “extended ping” commands became tiresome for me, so i wrote myself a TCL script to make it easier… i’m lazy LOL:

   proc rping {} {
   typeahead “5.5.5.5\n10\n52\n3\ny\n1.1.1.1\n184\n\n\n\nr\n3\n\n\n”
   set X [ regexp -all -inline {192\.168\.[2345]+\.[23]|timed\sout} [ exec “ping ip” ] ]
   foreach Y $X {
   if { [ regexp -all {192\.168\.25\.2} $Y ] != 0 } {
   puts “$Y DMZ Link”
   } else {
   puts $Y }
   }
   }

   the resultant output looks like this:

   Athens(tcl)#rping
   192.168.24.2
   192.168.35.3
   192.168.25.2 DMZ Link
   timed out
   192.168.24.2
   192.168.35.3
   192.168.24.2
   192.168.35.3
   192.168.25.2 DMZ Link
   192.168.35.3

   Athens(tcl)#

   two thumbs way up on another one of Rene’s superb labs !! 🙂

Comments are closed.