BGP Traffic Engineering Unsuppress-Map


Scenario:

The mystical creature corporation has a large international network of fantasy enthusiastics people sharing new mystical rumors. They are running BGP to exchange routing information between each other. At some point in the network you are aggregating a number of prefixes but a downside of this that you are unable to use traffic engineering. Let’s see what solution you can come up with.

Goal:

  • All IP addresses have been preconfigured for you.
  • Configure IBGP within AS 3.
  • Configure EBGP between AS 2 and AS 3.
  • Configure EBGP between AS 1 and AS 2.
  • Configure router Blob to advertise all loopback interfaces in BGP.
  • Configure BGP aggregation on router Behemoth to summarize the loopback interfaces in the most optimal summary towards AS 3.
  • Configure the network so AS 3 sends traffic to network 172.16.0.0 /24 through router Banshee.
  • Configure the network so AS 3 sends traffic to network 172.16.1.0 /24 through router BigFoot.
  • You are not allowed to use static, default routes or any IGP. Do not remove the summary on router Behemoth.
  • You are not allowed to use any BGP communities or attributes.

IOS:

c3640-jk9s-mz.124-16.bin

Topology:

BGP Traffic Engineering Unsuppress Map

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

9 Comments

  1. Hi,

    I gone through the exercise. After completing configuring bgp on all routers then advertising the routes on aera 3 and area 1. I looked at the bgp table on Behemoth. There is an “r>” on some of the routes, the legend says this is a RIB-failure, what does that mean? It doesn’t seem to have an impact on area 3 and area 1 pinging each other.

    Behemoth(config)#do sh ip bgp
    BGP table version is 8, local router ID is 192.168.24.2
    Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
    r RIB-failure, S Stale
    Origin codes: i – IGP, e – EGP, ? – incomplete

    Network Next Hop Metric LocPrf Weight Path
    *> 172.16.0.0/24 192.168.12.1 0 0 1 i
    *> 172.16.1.0/24 192.168.12.1 0 0 1 i
    *> 172.16.2.0/24 192.168.12.1 0 0 1 i
    r 192.168.23.0 192.168.24.4 0 3 i
    r> 192.168.23.3 0 0 3 i
    r 192.168.24.0 192.168.23.3 0 3 i
    r> 192.168.24.4 0 0 3 i

    1. RIB (Routing Information Base) is your global routing table (show ip route). If you see a RIB-failure it means BGP cannot install this network in the routing table. You can use the [b]show ip bgp rib-failure[/b] command to check what is going wrong.

      This might sound "bad" but it doesn’t have to be. If you learn a network through OSPF and BGP it will show up as "RIB-failure" because the administrative distance of OSPF is lower (better) than BGP.

  2. Also please explain the theory behind the “unsuppress-map” command, what does it do? Rene said it send the prefix along with the summary but I am not sure what that really mean. Please explain further.

    1. Behemoth#show ip bgp rib-failure
      Network Next Hop RIB-failure RIB-NH Matches
      192.168.23.0 192.168.23.3 [b]Higher admin [/b]distance n/a
      192.168.24.0 192.168.24.4 [b]Higher admin [/b]distance n/a

      As you can see above what is the reason behind the routing information base failure Higher Admin Distance

      192.168.23.0 and 192.168.24.0 are directly connected networks for Behemoth router and we are announcing those routes through BGP so those two routes cannot be installed into routing table..

      Hope it can clear things

    2. Let me explain this:

      Let’s say we have 8 networks:

      192.168.0.0/24
      192.168.1.0/24
      192.168.2.0/24
      192.168.3.0/24
      192.168.4.0/24
      192.168.5.0/24
      192.168.6.0/24
      192.168.7.0/24

      Let’s say I want to create a summary for these networks, the best summary I can come up with is:

      192.168.0.0/21

      This covers network 192.168.0.0-192.168.7.0.

      Now let’s advertise this with BGP:

      [code]router bgp 1
      aggregate-address 192.168.0.0 255.255.248.0[/code]

      This is what will happen:

      1) The summary 192.168.0.0/21 will be advertised.
      2) BGP will [b]also[/b] advertise all the other networks (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 etc.)

      If I only want the summary to be advertised this is what I have to do:

      [code]router bgp 1
      aggregate-address 192.168.0.0 255.255.248.0 summary-only[/code]

      The [b]summary-only[/b] keyword will make sure only the summary is advertised.

      Now the problem is….what if i still want to advertise 1 or 2 networks? There’s nothing in between. It’s either summary+all networks or only the summary. The unsuppress-map gives us a third option. You can send the summary + 1 or 2 additional networks, that’s what we do in this lab.

      Why would you want to do this? Keep in mind routers will always prefer the "most-specific" entry in the routing table. You can use this for "traffic engineering".

      In this lab router Behemoth will receive a summary for the loopbacks in AS 3 from router Banshee and Bigfoot. These summaries are equal so it’s possible that traffic for the loopback of Bigfoot is send towards Banshee. Not a problem but it’s not the most optimal path. If we take the loopback of Bigfoot "out of the summary" and advertise it towards Behemoth things will be different because router Behemoth now has a "more specific prefix". When it wants to send traffic to the loopback of Bigfoot it will always send it to Bigfoot directly because this is a "more specific" entry than the summary route.

      Does that make sense?

  3. MAN! Talk about an eye opener for me…

    I’ve gone through almost all of your labs and got stuck on this one. I advertised the transit networks to Banshee/Bigfoot on Behemoth and did everything to allow for connectivity throughout the network, seeing successful pings and everything was looking good…..

    except if I did a traceroute….both Banshee/Behemoth would take the next-hop through Behemoth instead of the intra-AS link (as intended).

    I verified that there was reachability to the loopback….

    Next, I did a “show ip bgp 192.168.23.0” from Bigfoot’s perspective.

    DUH!!!!

    Unless Banshee itself injects the 192.168.23.0 network via a network statement, Bigfoot will prefer the next-hop path THROUGH Behemoth instead (external>internal). After moving the network statements over to Banshee and Bigfoot, respectively, did I see traffic taking the CORRECT paths out of AS 3.

    Good eye opener!

Comments are closed.