BGP Route Reflection – Troubleshooting

By Bryan Bartik on December 21st, 2009

Often when you are a few hours into a lab, some things become a little hazy. You are flying by and everything is working as expected, then you run into a snag. You know the answer will be easy, once you find it. Forgetting to configure route reflection can be one of those things. In this post, we look at the show ip bgp neighbor command to figure how the router tells us that there is no reflection going on. This is of course assuming you couldn’t figure it out with a show run (which happens a lot!).

 

R1—-R2—-R3

The three routers above are in AS 100. R2 is peered with R1 and R3. R1 is advertising the prefix 192.168.100.1/32 to R2. R2 receives and installs this in the route table, but R3 does not.

Let’s have a look:

R2#sho ip bgp | be Netw
Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.100.1/32 1.1.1.1                  0    100      0 i
R3#sho ip bgp
R3#

On R2, let’s look closer at the BGP entry:

R2#sho ip bgp 192.168.100.1
BGP routing table entry for 192.168.100.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
1.1.1.1 (metric 65) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best

Notice the entry says “Not advertised to any peer” but does not give us a clue why. Let’s look at another command. This is going to give us a lot of output, so I will cut out the part that’s relevant.

R2#sho ip bgp neighbors 3.3.3.3
For address family: IPv4 Unicast
BGP table version 2, neighbor version 2/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent       Rcvd
Prefix activity:               ----       ----
Prefixes Current:               0          0
Prefixes Total:                 0          0
Implicit Withdraw:              0          0
Explicit Withdraw:              0          0
Used as bestpath:             n/a          0
Used as multipath:            n/a          0
Outbound    Inbound
Local Policy Denied Prefixes:    --------    -------
Bestpath from iBGP peer:              1        n/a
Total:                                1          0
Number of NLRIs in the update sent: max 0, min 0

In the last few lines of output we see a section called “Local Policy Denied Prefixes.” A count and a reason of why prefixes have been denied are summarized in this section. We can see that one route has been denied outbound to this neighbor because “Bestpath from iBGP peer.” What does this mean? It means that the best path was learned through an IBGP peer and thus is not advertised to this (the one specified in the command outbound) IBGP peer. It would be nice for the output to say “Route reflection is not configured” but that’s wouldn’t be quite right since you could also use confederations!

This section of the command may also give other clues such as a route-map or prefix-list that could be blocking an advertisement. Plus, it displays inbound and outbound. One of my favorite commands just for digging around!

Good luck!

Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Be Sociable, Share!

    Leave a Reply