BGP DMZ Link Bandwidth


Scenario:

You work for a greek ISP where you are known as “The Greek Wonder”. You solve routing problems faster than Zeus could shoot lightning bolts. One part of the network uses BGP and there are multiple links between AS 1 and AS 2. Not all links have the same bandwidth but you would like to use all of them. You just read about the Link Bandwidth feature for BGP and you are looking forward to implementing it.

Goal:

  • All IP addresses have been preconfigured for you.
  • Configure IBGP within AS 1. Use the loopback0 interfaces to source the BGP updates from.
  • Configure IBGP within AS 2. Use the loopback0 interfaces to source the BGP updates from.
  • Configure EBGP between AS 1 and AS 2.
  • Ensure traffic from router Athens is load balanced proportionally over all available links.

IOS:

c3640-jk9s-mz.124-16.bin

Topology:

BGP DMZ Link Bandwidth

Video Solution:

Configuration Files

You need to register to download the GNS3 topology file. (Registration is free!)

Once you are logged in you will find the configuration files right here.

Opt In Image
Do you want your CCNA or CCNP Certificate?

The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.

Written by René Molenaar - CCIE #41726

You May Also Like

About the Author: Rene Molenaar

René - CCIE #41726 is the creator of GNS3Vault.com where he shares CCNA, CCNP and CCIE R&S labs. He also blogs about networking on http://networklessons.com

6 Comments

  1. 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 🙂

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