It is just me, or BGP route-reflection doesn’t work with IPv6 ?
We have it working in our service provider lab on 6.29.1 … have you enabled the IPv6 address family on every peer as well as the route-reflection commands on the instance and peers?
Here is the config of an IPv6 RR from our lab:
/routing bgp instance
set default as=1 redistribute-connected=yes router-id=1.1.1.1
/routing bgp peer
add address-families=ip,ipv6 name=peer1 remote-address=2001:db8:100::2 \
remote-as=1 route-reflect=yes ttl=default
add address-families=ip,ipv6 name=peer2 remote-address=2001:db8:200::2 \
remote-as=1 route-reflect=yes ttl=default
Yes, the only difference is that I have separate peers for ipv4 and ipv6. I will check if it starts working by enabling also the ipv4 address family (which in my topology should not be enabled).
I did some experiments, but I didn’t find a way to let it work. IPv4 runs smoothly as expected, IPv6 doesn’t.
On the route-reflector:
/routing bgp peer
add address-families=ipv6 in-filter=ibgp-v6-frr-client instance=AS8224 name=
v6-uni-mix-cr1 out-filter=ibgp-v6-frr-client remote-address=2a01:2d8:
x
remote-as=8224 route-reflect=yes tcp-md5-key=****** ttl=default
update-source=2a01:2d8:x
On the route-reflector client:
/routing bgp peer
add address-families=ipv6 in-filter=ibgp-v6-frr-client instance=AS8224 name=
v6-uni-frr1 out-filter=ibgp-v6-frr-client remote-address=2a01:2d8:x
remote-as=8224 tcp-md5-key=****** ttl=default
update-source=2a01:2d8:x
On the route-reflector there are 21K IPv6 routes and the client receives 0.
Routing filters are correct, even removing filters the results don’t change.
Should I open a ticket?
Two things.
Is route reflection enabled on the BGP instance?
What code are you trying this on?
Yes, of course… indeed IPv4 route-reflection works normally.
I don’t get the question, do you mean which routers/ROS version I am using? It’s configured on various devices (RB1100, CCR, MIPSBE..) and it’s like this since ever (all 6.x versions for sure). If you want to know something else, just ask.
I just found a bug: in winbox the cluster-id is set to: 255.2.2.4, but export (both compact and verbose) don’t recognize it.
> /routing bgp instance export
/routing bgp instance
set default disabled=yes
add as=8224 name=AS8224 router-id=x.x.x.x
Using /routing bgp instance export verbose shows !cluster-id
while after setting it through the cli using /routing bgp instance set AS8224 cluster-id=255.2.2.4 export shows the correct configuration:
> /routing bgp instance export
/routing bgp instance
set default disabled=yes
add as=8224 cluster-id=255.2.2.4 name=AS8224 router-id=x.x.x.x
Anyway this doesn’t solve the issue, I still don’t receive any IPv6 reflected route.
Assuming the cluster-id bug is not contributing to this, the main difference between our setups seems to be the code version.
There have been a number of IPv6 improvements / bug fixes throughout the 6.x series and it would be helpful to do one of two things.
- Upgrade at a minimum, a RR and two RR clients to the same 6.x code
- Replicate the config in GNS3 / VirtualBox and migrate the config onto router with the same 6.x code
We’d a similar issue, as we were running two RRs we could easily show to MT it doesn’t work as expected.
They told us we should wait for ROS v7 as this is the only way they would fix this issue.
ergo do not try to use MT as RR for IPv6 running ROS v6.xx
I wonder if this is a result of the recursive-nexthop issue in IPv6 iBGP for ROS.
It’s been a while since I was messing around with it, but I seemed to find an issue with it when using link-local addressing at an eBGP peering point.
I think it’s unrelated to recursive-nextop. In this case the routes are not even distributed to iBGP peers.
Do they (MikroTik) actually tell clients to wait for ROS v7???
I hope it means they have intentions that nobody yet knows about.
They definitely say this - and it’s definitely stated in regards to routing protocol functionality.
They’re apparently doing an overhaul of the routing code in ROS, and I’m not sure what sorts of things are limitations based on the current code base, so I just have to have faith that this is truly a position based on avoiding duplication of effort. That having been said, it sure would be nice to have some sort of reassurance that v7 is going to reach beta stage soon.
It’s not because we are fanatic to test ROS 7, it’s because it is more than 2 years that we are waiting for IPv6 features like recursive lookup, route reflection and other things that currently don’t work on ROS 6. Our V6 network is actually someway crippled…
Agree 100%.
There are several broken things in ROS implementation of both OSPF and BGP which are subtle, but really hinder one from easily deploying a well-designed network using ROS as the backbone.
There are several not so subtle things broken too.
E.g.
- BFD
- L3VPN + PE-CE BGP NLRI updates (NLRI updates do NOT occur when the best path changes)
- IPV6 recursive next-hop lookup
- VRF + BGP Passive Peers
- Advertised Routes for BGP peers in a VRF
- BGP often stops retrying connection attempts
- SNMP queries can cause routing process to crash
v7 is long overdue.
There are several not so subtle things broken too.
E.g.
- BFD
- L3VPN + PE-CE BGP NLRI updates (NLRI updates do NOT occur when the best path changes)
- IPV6 recursive next-hop lookup
- VRF + BGP Passive Peers
- Advertised Routes for BGP peers in a VRF
- BGP often stops retrying connection attempts
- SNMP queries can cause routing process to crash
v7 is long overdue.
I second that.
On the other hand: which other supplier gives away free updates for their $x-OS so I’d be happy to see things fixed,but I understand MT is still a hardware based business and we get updates and bugfixes without ever paying a monthly/yearly fee, so I’m patiently waiting for ROSv7 to come up.
Then again, for timely updates to core systems I’d be willing to pay some (moderate) fee if development would be advanced by those payments.
Kindest regards,
hk
As would we..
Talking to other users at MUM events in USA, Australia and New Zealand it was widely discussed that users would be happy to pay recurring support fees to Mikrotik for priority support and bug fixes.
Maybe one day.. 
I am really torn on this issue:
-
On the one hand, we are patiently waiting like everyone else for v7 to fix a number of issues and introduce features and would love a paid support “fast path”
-
But on the other hand, MiktoTik has become the company we all go to for cost effective hardware because they don’t have the massive OPEX for Sales/Support that Cisco, Juniper and others have.
I want to see support continue to get better but I don’t want the price of the box to go up to offset the increased support cost. It seems unlikely that priority support can be entirely funded by a nominal support fee. The support fee will either have to be steep, or the company has to bake part of that cost into the product.
It’s a slippery slope 
It is indeed a slippery slope.
What if MikroTik took us to the test and started some outside funding project on kickstarter (or whatever crowdfinance portal) in order to get major development done?
This way we could (hopfeully) keep our beloved MikroTik HW+SW, but we could help advance their efforts to build a better RouterOS.
Anyone from MT reading this?
Regards,
hk