I have two border routers that both keep full BGP routing tables of their upstream connection and their neighbors upstream connection. Typically the default iBGP configuration will announce all routes in the table to its peer. This seems impossible with RouterOS v7 for some reason. eBGP is announcing the prefixes I have in bgp-networks and have a static blackhole route for so that’s fine but I should not need to do that to share all routes with an iBGP peer. How is that accomplished in v7? I’m assuming there is a configuration setting i’m missing.
on the bgp connection for the ibgp peers do you have bgp checked for output redistribution ?
Yes I did try that and just tried again. Doesn’t seem to do anything. I tried without any input/output filters, with input/output filters. Nothing. If I connect a v6 router it will send all routes and v7 will receive them all though.
1 name=“peer5”
remote.address=2001:4:69::1 .port=179 .as=33333
local.address=2001:4:69::2 .port=179 .role=ibgp
connect=yes listen=yes routing-table=main router-id=204.88.94.45 templates=ibgp as=33333
address-families=ipv6
output.redistribute=bgp
input.filter=allowall
The ibgp template is same as default but without output.networks=
Above is the IPv6 peer entry but it’s the same story with IPv4.
The ony thing I see that is wrong is the router-id is an IP of a bridge interface that is actually down at the moment. I will try fixing that in case. eBGP works and announces despite that though so I’m not sure rouer-id is actually tied to an IP/interface being up/down.
does it do the same, if you change the local role to “igp rr”
with the new changes to BGP in v7 everything is explicitly defined i.e. filters are required.
try creating a outbound filter with only one rule ex: add chain=Default-Out disabled=no rule=“accept;”
with that defined it should pass all routes
I also have upgraded from 6.48 to 7.1.2 (stable) and routing filter rules are migrated to new format, all looks good, however destination (cisco) now sees only one / first route.
/routing bgp connection is using role=ebgp
That was it! igp-rr worked … I could’t find any documentation on that .. is there a list of roles some place?
Also, I actually did not need any output filter and redistribute bgp is not relevant either, the key is ibgp-rr as a role.
v7 actually follows more of the RFC standards for bgp
i believe egp and igp modes are documented there.
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/?include_text=1
igp rr should be equal to checking route reflect in v6 if i am not mistaken.
also https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328220
Actually, this was not the correct solution. I should not need route reflection enabled. Routers by default advertise all their eBGP learned routes to their iBGP peers. This is not happening from the v7 router to the v6 router. It might be one other issue I need to fix in the config and will report back.
When I enabled ibgp-rr on the v7 router it seemed to echo back routes learned from the v6 peer and now the routing table on the v6 router has double routes for every route and both have the same external gateway. It doesn’t seem to want to send the eBGP learned routes to the v6 router but like I said I have a known slight misconfig on a bridge/loopbakc interface I need to fix so I will test that over the weekend.
I think ‘igp rr’ is the correct setting to use however if you dont want clients to reflect the routes back to one another try setting the extra no client to client reflection flag
Ok, it had nothing to do with my config change. Everything works right except when the v6 router learns routes from v7 as a peer, it is setting the gateway incorrectly. It is setting the route to the same external eBGP gateway as other routes being learned on the v6 router.
4 ADb dst-address=1.0.4.0/22 gateway=213.xxx.129.182 gateway-status=213.xxx.129.182 reachable via ether7 distance=20
scope=40 target-scope=10 bgp-as-path=“1299,4826,38803” bgp-local-pref=160 bgp-origin=igp
bgp-communities=1299:35000 received-from=telia
5 Db dst-address=1.0.4.0/22 gateway=213.xxx.129.182 gateway-status=213.xxx.129.182 reachable via ether7 distance=200
scope=40 target-scope=30 bgp-as-path=“1299,4826,38803” bgp-local-pref=160 bgp-atomic-aggregate=yes
bgp-origin=igp bgp-communities=1299:35000 received-from=peer1
Notice received-from peer1 — that is a different router with a different upstream and interface IPs and yet, routes going out from the v7 router are getting the same gateway as routes received via Telia on the v6 router, which is useless. It doesn’t appear to be happening with IPv6 iBGP peers…
5 ADb dst-address=2001:200::/32 gateway=2001:yyyy:0:1c27::1 gateway-status=2001:yyyy:0:1c27::1 reachable via ether7
distance=20 scope=40 target-scope=10 bgp-as-path=“1299,2914,2500,2500” bgp-local-pref=160 bgp-origin=igp
bgp-communities=1299:25000 received-from=telia_v6
6 Db dst-address=2001:200::/32 gateway=2001:xxxx:69::2 gateway-status=2001:xxxx:69::2 reachable via ether17
distance=200 scope=40 target-scope=30 bgp-as-path=“1299,2914,2500,2500” bgp-local-pref=160
bgp-atomic-aggregate=yes bgp-origin=igp bgp-communities=1299:25000 received-from=peer5
I tried nexthop-choice=force-self but it didn’t have any effect. I’m going to keep looking for a little bit then probably roll back to v6 if I can’t figure it out.
https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3
This sounds simple enough – but this does not seem to be what is happening.
Also an iBGP mesh with all other vendors (Cisco, Juniper etc) just shares all routes without setting anything up as a route reflector. That should not be necessary to get iBGP to share routing tables. I’m not getting this.
OK I am able to get routes to announce to iBGP peers in role=ibgp mode as long as the networks are in output.network=addresslisthere AND directly connected/blackhole route exists (thats eBGP behavior and should not be like this when the role is iBGP) — they will not announce otherwise - so unless there is an address list entry that is a catch ALL , it’s not possible to configure one of the most common ISP BGP configurations in v7 with full routes ibgp mesh. I could possibly do some type of route reflector hack but it would not be correct.
Does anyone have a solution ?
I may have figured it out – adding my ONE /32 IPv6 block to output.networks seems to have allowed iBGP to announce all my directly connected smaller networks under that /32. So in theory I could add a default route to output.networks and a static default route blackhole and it should then announce all iBGP routes. Will try that soon.
– UPDATE – NOPE! Not even adding ::/0 to ibgp-networks address-list and creating a static route and static blackhole route for ::/0 worked. So I have no idea what to do here.
So… I guess with v7, iBGP full mesh/full route support is gone? Rolling back to v6 until it is realized / fixed or I figure out how to make it announce all iBGP routes (no, configuring route reflection is not the correct way).
I just want to update my situation/scenario
RouterOS 6 working with bgp with cisco.
After upgreade to RouterOS 7.1.3, some routes are not sent out.
I have found out the reason and fixed it. The issue was in /ip firewall access list, that had other subnet defined. Now in RouterOS it seems it has to match the correct IP subnet range as it is in /ip address. In my case , ip firewall address list had a bigger range to take multiple my ip address and its subnets.
it is possible that it simply is not fully ready for production yet. have you tried setting up a CHR lab to reproduce the issue ?
It’s definitely not, turns out, the whole time I was trying to test v7 on my less utilized router, it was flapping ALL my announcements continuously. Some providers dampened those announcements and I made the top 50 list of most active ASs on the entire internet. HAHAHAHAHHA. BOOM! rolled back to v6 for awhile. Not mad, it’s a funny story I can tell now.
Yep not ready for production. I for one will be waiting till all my lab testing passes with flying colors.
It’s sad really that v7 had been under development for more than 8 years and still is not ready for production use, and to make matters worse they are already releasing v7 only devices.
I do wonder what model did you run the test on? was it a CHR or was it a hardware device with a Tilera cpu ?
I appreciate the developers and their hard work. I suspect 7.x will be fine for simple routing situations but it should be considered BETA in regards to BGP at the least. It should come with that warning especially after seeing people come forward with show stopper bugs. This flapping one was quite bad. I believe the other end was a Juniper router, it flapped every 15-30 seconds.
Anyway, i’ll check the forums every now and then to see how testing/fixes are going.
Why no route aggregation!