cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2529
Views
20
Helpful
8
Replies

BGP Route-reflector question regarding prefixes not being seen

Ravi Pande
Level 1
Level 1

Hello,

I have the following topology for studying BGP route-reflector.
Screen Shot 2018-10-15 at 10.15.39 PM.png

So R2 I have configured as Route-reflector and R5 is Non-client and R1,R3 are clients for R2(reflector). Next, I have configured R3 as route-reflector with R4 & R2 being its clients. I see all the loopbacks in BGP table for R2 & R3. For R1 & R5 I see all the prefixes in BGP excerpt the loopback of R4. And for R4 I see only prefixes from R2,R3,R4. I was expecting all the prefixes on all routers not sure what is wrong. Any help would be appreciated.
=====================

1) R1

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.64.32.1/32   0.0.0.0                  0         32768 i

*>i172.64.32.2/32   10.0.0.13                0    100      0 i

* i172.64.32.3/32   10.0.0.10                0    100      0 i

* i172.64.32.5/32   10.0.0.6                 0    100      0 i

 

2) R2

Network          Next Hop            Metric LocPrf Weight Path

*>i172.64.32.1/32   10.0.0.14                0    100      0 i

*> 172.64.32.2/32   0.0.0.0                  0         32768 i

*>i172.64.32.3/32   10.0.0.10                0    100      0 i

* i172.64.32.4/32   10.0.0.18                0    100      0 i

*>i172.64.32.5/32   10.0.0.6                 0    100      0 i

 

3) R3

Network          Next Hop            Metric LocPrf Weight Path

* i172.64.32.1/32   10.0.0.14                0    100      0 i

*>i172.64.32.2/32   10.0.0.9                 0    100      0 i

*> 172.64.32.3/32   0.0.0.0                  0         32768 i

*>i172.64.32.4/32   10.0.0.18                0    100      0 i

* i172.64.32.5/32   10.0.0.6                 0    100      0 i

4) R4

  Network          Next Hop            Metric LocPrf Weight Path

* i172.64.32.2/32   10.0.0.9                 0    100      0 i

*>i172.64.32.3/32   10.0.0.17                0    100      0 i

*> 172.64.32.4/32   0.0.0.0                  0         32768 i

5)R5

Network          Next Hop            Metric LocPrf Weight Path

* i172.64.32.1/32   10.0.0.14                0    100      0 i

*>i172.64.32.2/32   10.0.0.5                 0    100      0 i

* i172.64.32.3/32   10.0.0.10                0    100      0 i

*> 172.64.32.5/32   0.0.0.0                  0         32768 i

========================

1) R2 route-reflector

 sh run | s bgp

router bgp 100

no synchronization

bgp log-neighbor-changes

network 172.64.32.2 mask 255.255.255.255

neighbor 10.0.0.6 remote-as 100

neighbor 10.0.0.6 next-hop-self

neighbor 10.0.0.10 remote-as 100

neighbor 10.0.0.10 route-reflector-client

neighbor 10.0.0.10 next-hop-self

neighbor 10.0.0.14 remote-as 100

neighbor 10.0.0.14 route-reflector-client

neighbor 10.0.0.14 next-hop-self

no auto-summary

 

2) R3 route-refelctor

do sh run | s bgp

router bgp 100

no synchronization

bgp log-neighbor-changes

network 172.64.32.3 mask 255.255.255.255

neighbor 10.0.0.9 remote-as 100

neighbor 10.0.0.9 route-reflector-client

neighbor 10.0.0.9 next-hop-self

neighbor 10.0.0.18 remote-as 100

neighbor 10.0.0.18 route-reflector-client

neighbor 10.0.0.18 next-hop-self

no auto-summary

========================


Thanks & Regards,
Ravi

1 Accepted Solution

Accepted Solutions

Hello,

 

Next-hop-self doesn't work by default on prefixes received from ibgp neighbors and advertised to ibgp neighbors as per RFC 4456 reccomandation

https://tools.ietf.org/html/rfc4456#section-10

In addition, when a RR reflects a route, it SHOULD NOT modify the
following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potentially result in routing loops.

Next-hop-self can be forced on IOS devices by appending the "all" keyword to the command and by applying the command "ibgp policy out enforce-modifications" on IOS-XR. NX-OS needs a route-map to change the value.

 

If you questiona have been answered remember to mark this post as solved.

 

Cheers,

ADP

View solution in original post

8 Replies 8

ADP_89
Level 1
Level 1

Hello Ravi,

 

If you take a closer look at your "show ip bgp " output you will see that some prefixes are missing the > symbol. This means that the prefixes are not the best route so they will never be forwarded/reflected to other neighbors. My guess on this is that you are missing an IGP inside you AS so the routers R1-R2-R3-R4 do not know how to reach the next hop reported by the prefixes.

There are a few ways to fix your scenario, some of them are the following:

- Run an IGP(EIGRP,OSPF,IS-IS) inside the AS and do the peerings over the loopback interface(this is a best practice in case you have redundant links between the routers). Create a new one if you just want to check/play with BGP advertisements

- On R2 apply the "neighbor X.X.X.X next-hop-self" to R1 and R3 sessions, this will announce R5 IPs inside the 100 with R2 as next-hop. In this way you do not need to include the inter-AS link in your IGP.

 

With this couple of changes you will see all the prefixes not only in BGP table but they also be installed into the routing-table so you can do ping/connection tests end to end.

 

HTH,

ADP

 

 


@ADP_89 wrote:

Hello Ravi,

 

If you take a closer look at your "show ip bgp " output you will see that some prefixes are missing the > symbol. This means that the prefixes are not the best route 

Hello

That is in correct!

This  symbol > states it IS the best route not that it isn’t 

 

* This states it is valid 

 

Can you verify rtr4 - 5 have a valid path to each other as @ADP_89 suggested it does looks like this is due to nlri failure

 

show ip route | in 10.0.0

sh ip bgp update-group

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul


@paul driver wrote:

 

Hello

That is in correct!

This  symbol > states it IS the best route not that it isn’t 

* This states it is valid 

 

You probably misread my sentence or I have written it in a non correct English form but with my "This" I was referring to the whole previous sentence, not to the symbol.

So if that symbol is missing the route is not the best.(This is what I was trying to say)

 

Cheers,

ADP

Hello

@ADP_89 apologies now reading it again I did misread it  - your are correct in what you were saying 

 

and i I agree also that this failure is most probably down to those rtrs not having any valid reachability 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Thanks for your reply.
I have already added next-hop-self on R2 and R3.I have included R2 & R3 bgp config details. Yes, I do not have any IGP configured.

I will configure IGP and then update this post.

Hi @ADP_89 & @paul driver - Thanks for pointing that out. I configured OSPF and see that it is working fine. Could you please let me know why it was not working before.  I had configured next-hop-self on both the route reflectors so I was assuming that I do not need an IGP.


Thanks,
Ravi

Hello

Yes it’s down to bgp synchronisation rule stating a route shouldn’t be advertised unless there is a valid route in this case to its advertised next hop by an igp ( static- rip- ospf -eigrp)

 

now with synchronisation turned off this prefix is being advertised in bgp but as you don’t have a nlri ( reachability)  to the nexthop of that prefix its not being addied to the route table and just show as valid and not best route in the bgp table 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello,

 

Next-hop-self doesn't work by default on prefixes received from ibgp neighbors and advertised to ibgp neighbors as per RFC 4456 reccomandation

https://tools.ietf.org/html/rfc4456#section-10

In addition, when a RR reflects a route, it SHOULD NOT modify the
following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potentially result in routing loops.

Next-hop-self can be forced on IOS devices by appending the "all" keyword to the command and by applying the command "ibgp policy out enforce-modifications" on IOS-XR. NX-OS needs a route-map to change the value.

 

If you questiona have been answered remember to mark this post as solved.

 

Cheers,

ADP

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: