Community discussions

MikroTik App
 
irrwitzer
just joined
Topic Author
Posts: 6
Joined: Mon Apr 11, 2022 11:54 pm

ROSv6: iBGP + multiple AS/Instances with redist, Route Reflection problem

Mon Oct 17, 2022 10:45 pm

Hi guys,

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.

R1 (172.16.66.1):
/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

R3 (172.16.52.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

Rd (172.16.52.3):
/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

> /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=""
(BGP) Routing table of Rd
 > /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
(172.16.50.4 is the originating router Rg - this is just a test prefix to test propagation)

(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


Silly question:
- 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!

Best regards,

Johannes
You do not have the required permissions to view the files attached to this post.
 
irrwitzer
just joined
Topic Author
Posts: 6
Joined: Mon Apr 11, 2022 11:54 pm

Re: ROSv6: iBGP + multiple AS/Instances with redist, Route Reflection problem  [SOLVED]

Thu Oct 20, 2022 11:06 am

Okay, to answer my own posting and maybe help others avoid this shameful experience:
Silly question:
- 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.
That actually was the problem.

I'm doing this whole OSPF+BGP dance to replace a historic RIP installation. RIP is still the active (lower distance than iBGP) protocol here.
R2 and R3, the ones who receive the routes from R1 but don't redistribute them to their clients, don't have the iBGP routes as active in their table because of the "better" RIP routes.

I knew and accepted that from the beginning, but I was absolutely sure that won't matter - thinking that R2&R3 would readvertise those routes nevertheless, because they are in their BGP-table and they would have to hand down the advertisements to their rr-clients. Either I'm to uneducated about BGPs behaviour, or other platforms handle this differently, I'm not sure. It's the first time I have to deal with a legacy protocol that has to be replaced in a production environment.

Either way, thank you very much @ZeroByte for his lenghty reply in an older thread: viewtopic.php?t=105030#p522440

BR,
Johannes

Who is online

Users browsing this forum: No registered users and 5 guests