BGP Traffic Engineering Unsuppress-Map

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. Thank you for this creativity, how can I run lab?

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

   1. Thats awesome! BGP attributes got revised! 🙂

5. Good use of un-suppress map command and traffic engineering via more specific subnet-mask.

Comments are closed.