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:

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:

Code:Select all

/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?

Is route reflection enabled on the BGP instance?

Yes, of course... indeed IPv4 route-reflection works normally.

What code are you trying this on?

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.
Using/routing bgp instance export verboseshows!cluster-id

while after setting it through the cli using/routing bgp instance set AS8224 cluster-id=255.2.2.4export shows the correct configuration:
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.

1) Upgrade at a minimum, a RR and two RR clients to the same 6.x code
2) 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.

这是一段时间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 wonder if this is a result of the recursive-nexthop issue in IPv6 iBGP for ROS.

这是一段时间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.

They told us we should wait for ROS v7 as this is the only way they would fix this issue.

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....

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 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.
再一次,我会及时更新核心系统be willing to pay some (moderate) fee if development would be advanced by those payments.
Kindest regards,
hk

for timely updates to core systems I'd be willing to pay some (moderate) fee if development would be advanced by those payments.

As would we..

与其他用户在妈妈事件在美国,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:

1) 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"

2) 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

IPv6 route reflection still doesn't work and it's causing a lot of troubles in our network. Is it really the only option to wait for ROS v7?

I will be more than happy to compare notes.. since I just had to do this and have it working on our MT Routers.. Two Edges, doing RR to each other....
Had to use Ipv6 prefix between the connections (no link state). Additionally on a 3rd router, I had to put static route to 2nd Edge router to get around the recursive ip bug.

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

Totally agree with you Harald. Another option for MT to consider would be to move in a completely new direction by generally opening up their hardware platform for Linux and thus also for open-source routing suites likehttps://frrouting.org/.

We got something similar to Cisco 6PE working by using route reflectors to distribute IPv6 prefixes between PE (provider edge) routers. Prefixes are originated in to iBGP using the PE router's IPv6 loopback IP and the same IP is assigned to a BGP signalled VPLS bridge interface with a /64 subnet mask. Each router can subsequently find next hop via MPLS switched path.

No IPv6, OSPFv3, BGP nor per-hop-routing lookups on P routers. This way we only have to manage infrastructure using IPv4, OSPF and Traffic Engineering (where needed) and both IPv4 and IPv6 follow the same MPLS path.

Full lab setup detailed here:
viewtopic.php?f=14&t=42268&start=58#p688490

IPv6 route reflection still doesn't work and it's causing a lot of troubles in our network. Is it really the only option to wait for ROS v7?

Route reflection works fine here with v4 and v6 -- we also have separate peers for v4 and v6 with route reflection in at least one case, and it works.

However, I discovered something recently and I don't know if it is normal behavior or a special MikroTik behavior, but it may explain your issue. In our case the v6 route reflection was working but v4 seemingly was not. Then I noticed that there was one v4 route getting reflected properly, and that one was the only route not in OSPF.

Based on that, it seems that if the BGP route is inactive on the route reflector itself (due for instance to an OSPF route or static route with shorter distance), the route does not get reflected. The BGP route seems to have to be active on the route reflector to be reflected to the other routers. It could be that all of your v6 routes are available in your reflector either as static routes or OSPFv3 routes with a shorter metric, and therefore the BGP routes are inactive, preventing them from being reflected.

I am having this issue with IPv4. Because OSPF overrides the BGP routes (making them not active) the router will not reflect the BGP routes.

How do i fix this? Is it a v7 thing? I have Client to Client Reflection turned on, I have tried enabling "Redistribute other BGP" nothing seems to make it work besides "Redistribute OSPF" but that doesn't seem right.

Oddly enough, i'm running Mikrotik Core and Edge with JunOS vRR Route Reflectors and the issue with NextHOP Lookup is resolved for ipv6.

+1

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.