i have some clarifications on RR's:
1. I enabled next-hop-self on my RRserver and im getting the next-hop of my providers on my RRclient, should i not have the next-hop of my server?
2. I get rib-failures on my RRserver routes advertised by my Client.
You shouldn't set next-hop-self on RRserver but rather it should be set on RRclient. This should modify the next-hop for each ebgp carried updates received by RRserver from the Provider.
make sure Synchronization is not set (Turned OFF) on RRclient, Synch rule has to validate any updates received from Client1 by the IGP.
1st: If i remove next-hop-self on the RRserver my bgp wont come up.
2nd:i already have no synchronization on all my routers.
tnx a lot.
1- It's important to be set on RRclient, if the bgp session wont come up then you dont have to remove it from RRserver.
2- Does RRserver receive another partial Networks from RRclient? Did you set up a route-reflector?
1. If i set this on RRclient, what will be the next hop of my ebgp clients connected to this RRclient?
compnayA is advertising to RRClient
RRserver see's it as rib-failure
I am not sure I understand your setup. Is this a pure IP network with BGP or do you have some MPLS features enabled? Posting some relevant configuration from each device would help to better understand your scenario.
In any case, referring to your original post:
1. Have you tried to clear the iBGP session from the RRserver soft out towards the RRclient?
2. Do you have the subnet used for the eBGP session between Client1 and RRclient in your IGP? Client1 advertises towards RRclient routes with a next-hop that is passed unmodified by RRclient to RRserver (at least in standard BGP setup and without next-hop-self in RRclient), so RRserver needs to have this next-hop in its routing table to resolve the eBGP routes.
Iam not saying setting it on RRclient for the ebgp link, I am Saying setting it on RRclient for IBGP link to RRserver, so that the Nexthop for Networks received by the Provider be the RRserver on RRclient. Since the next-hop is manadtory attribute carried on each ebgp update you dont have to set it between client1 and RRclient.
2- Based on what u are describing, I really dont know what else could be the reason behind that other than Synchronization.
Is it possible that the Route Reflector that is experiencing RIB failures is learning the routes from some other source in addition to the route reflector client? That is a common cause of RIB failure is that the router is learning the prefix from something that has a better Administrative Distance than the IBGP from the route reflector client.
Can you identify one of the prefixes that is experiencing RIB failure and post the output of show ip route
im also looking at that. here's the output of one of the block advertised by my ebgp companyA connected to the RRclient.
RRServer#sh ip route xxx.xxx.10.0
Routing entry for xxx.xxx.10.0/24
Known via "ospf 100", distance 110, metric 20, type extern 2, forward metric 1
Last update from yyy.yyy.176.22 on GigabitEthernet1/2, 00:02:57 ago
Routing Descriptor Blocks:
* yyy.yyy.176.22, from yyy.yyy.176.251, 00:02:57 ago, via GigabitEthernet1/2
Route metric is 20, traffic share count is 1
And on the RRclient here is the ospf settings.
router ospf 1
redistribute connected subnets
redistribute static subnets
The odd thing is my RRclient and RRserver has a different area id on the ospf.
Another thing, all advertised by the RRserver to the RRclient are all the best path? and my RRclient has the same next hop as the RRserver?
Thanks for the additional information. If the route reflector is learning the prefix via IBGP from the reflector client, and is also learning that prefix via OSPF then that clearly explains the RIB failure. BGP can not put the prefix into the routing table (causing the RIB failure) because the prefix is in the routing table already with a better Administrative Distance.
(note that RIB failure is not necessarily a sign of a problem. When we see a message that includes the word failure, we tend to assume that it is a bad thing. In the case of RIB failure it is not necessarily a bad thing and not necessarily a problem.)
I think that you are confusing the OSPF process ID (OSPF 100 and OSPF 1) with the area ID. I do not see anything in this post that tells what the area ID is. And if the routers have become neighbors, then it is pretty sure that they are both in a common area.
Sorry for the mixed up it is the process id that are not the same. And since i have a static routes from my RRClient to the CompanyA, and i have a redistribute static there thats why it is known via ospf, is that correct? The RRclient and RRserver have a different process id, yet im receiving the routes via ospf.
Yes it is the process ID that is different. The process ID is only locally significant, so one router has no idea what is the process ID of a neighbor. The area ID is significant. The area ID is part of the OSPF hello message, and routers will not become neighbors if the area ID does not match.
If the prefix is redistributed into OSPF and advertised, then that route will be preferred to the route learned via IBGP.
It is clearer now, just to answer this question.
All the routes advertised by the RRserver to the RRclient are the best routes right? And i have the next-hop-self on the RRserver and still my RRclient next-hop are my provider edge routers.
next-hop-self on the RR only affects those routes that have been received via eBGP, not the reflected routes (iBGP learnt routes).