I really need your help....
I'm struggling with a problem I can't place a finger on. I guesst I'm just to frustrated now to find an obvious error in my config.
I did a lot of searching in the last 4 days, but I didn't find anything matching my problem. If there already are threads.... I appreciate any link!
I attached a simple diagram of the current setup.
The pink routers R1, R2, R3 are the route reflectors. Those are of course fully meshed.
Routers Ra...Rg are the rout reflector clients.
Those are peered to the local RR, as well as to one of the others, the corresponding RRs are specified in the diagram.
IGP is OSPF, redistributing only the loopback IPs.
Pure local advertisements (meaning from one of those above routers, regardless of whether a RR or a client announces the prefix) get propagated just fine, no problem here.
So for the complex part / problem:
R1 does have an additional instance with a different AS# to ebgp peer Azure. A second one will be added to Rb as soon as we got the rest stable.
So, to get the prefixes announced from Azure to our own iBGP, we added a new instance with our own AS# and enabled "redistribute-other-bgp=yes".
Those Azure prefixes get propagated just fine to:
- all RRs (iBGP peers without reflection)
- all rr-clients peered directly with R1
but those rr-clients, that aren't directly peered with R1, but with R2+R3, won't receive the Azure prefixes.
The rr-clients that are peered with R1+R2/3 are getting the prefixes only once, directly from R1.
R2 + R3 aren't showing the Azure routes in /routing bgp advertisements either even though the filter would allow them (are the same as on R1).
So... to give you some more insights, here's the config of the "problematic area" marked in orange in the diagram. R1 + R3 + Rd to contain two RRs and one rr-client missing the routes.
/routing bgp instance set default as=65013 add as=65000 cluster-id=172.16.66.1 name=bgp1 redistribute-other-bgp=yes router-id=172.16.66.1 /routing bgp peer add in-filter=azure-ipsec-test name=azure1 remote-address=192.168.16.2 remote-as=12076 ttl=default add in-filter=azure-ipsec-test name=azure2 remote-address=192.168.16.6 remote-as=12076 ttl=default add in-filter=bgp-backbone instance=bgp1 name=R3 out-filter=bgp-backbone remote-address=172.16.52.1 remote-as=65000 update-source=172.16.66.1
/routing bgp instance set default disabled=yes add as=65000 name=bgp1 router-id=172.16.52.1 /routing bgp peer add in-filter=bgp-backbone instance=bgp1 name=Rd out-filter=bgp-backbone remote-address=172.16.52.3 remote-as=65000 route-reflect=yes update-source=172.16.52.1 add in-filter=bgp-backbone instance=bgp1 name=R1 out-filter=bgp-backbone remote-address=172.16.66.1 remote-as=65000 update-source=172.16.52.1
/routing bgp instance set default disabled=yes add as=65000 name=bgp1 router-id=172.16.52.3 /routing bgp peer add in-filter=bgp-backbone instance=bgp1 name=R3 out-filter=bgp-backbone remote-address=172.16.52.1 remote-as=65000 update-source=172.16.52.3 add in-filter=bgp-backbone instance=bgp1 name=R2 out-filter=bgp-backbone remote-address=172.16.50.1 remote-as=65000 update-source=172.16.52.3
(BGP) Routing table of Rd
> /routing filter print where chain=bgp-backbone Flags: X - disabled 0 chain=bgp-backbone prefix=10.0.0.0/8 prefix-length=0-29 invert-match=no action=accept set-bgp-prepend-path="" 1 chain=bgp-backbone invert-match=no action=discard set-bgp-prepend-path=""
(172.16.50.4 is the originating router Rg - this is just a test prefix to test propagation)
> /ip route print where bgp Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADb 10.13.13.0/28 172.16.50.4 200 1 Db 10.13.13.0/28 172.16.50.4 200
(BGP) Routing table of R3:
> /ip route print where bgp Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADb 10.13.13.0/28 172.16.50.4 200 1 Db 10.19.35.0/24 172.16.66.1 200 2 ADb 10.23.0.0/16 172.16.66.1 200 [...]
> /routing bgp advertisements print Rd PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF Rd 10.13.13.0/28 172.16.50.4 igp 100
I already tried:
- setting different cluster-id's on all RR-servers => no change
- switching all internal systems to 65013, the AS# used for azure peering to avoid redistributing other AS => no change
- Do routes have to be *active* to be advertised to rr-clients? Meaning: when there is an other route of an other IGP with lower distance, will a RR non-the-less advertise the route to it's clients or not? I asume it would have to and is not taking other IGPs in account, but I'm not absolutely sure who the rule is for such a case.
Thank you so much for reading my stuff and in advance for pointing me in the right direction!