If you are connecting/BGP to an upstream provider and want to do both IPv4 and IPv6 do you create seperate instances for each protocol typically or how do you do that?

the same instance, the same peer. In peers configuration enable ipv6 address family, but note that your provider should do the same.

Note that v6 dynamic routing support is buggy as hell in ROS 4, Word from MT support is "wait for ROS 5, Use static for now"

You are speaking like IPv6 is not usable at all, which is not true. If you are facing a bug which is not fixed in v4 it doesn't mean that others will have the same config and will face the same bug.

We have a simple config of a full v6 bgp table, from time to time the v6 route table will not route just shows "no route to host" restarting BGP fix's it. MT support said bgp v6 is unstable

is this bug documented somewhere in this forum?

We have a simple config of a full v6 bgp table, from time to time the v6 route table will not route just shows "no route to host" restarting BGP fix's it. MT support said bgp v6 is unstable

Becarra, I just started having this issue after a full year of successful transit using IPv6. I am taking a full Cogent and HE.net feed. Just in the past week Cogents feed starting including something that I believe is crashing / breaking / something when its running for a few moments now. Do you have any more details, did yours work fine until a week or so ago? Which carrier?

If I disable the he.net feed then its stable again.

I can't even ping the other end of the /126 they assigned me, which is a connected route. I get "no route to host". If i kill either bgp peer then its stable again.

v3.30

This has been affecting us for about 2 months now, We too have a HE.net feed but it's not active as we have a native full feed from our main transit carrier.

Get the exact same thing as you, Not sure what it is but MT aren't looking into it since v5 is stable with it

Would anyone share an example config of doing BGP into HE.net dual stack with IPv4 and IPv6?

Hi have same problem:

Also uses Cogent native v6 and HE for complete IPv6 bgp table.

For only use HE for prefixes missed in Cogent table I prepend x4 In and Out HE session.

/routing filter
add action=accept address-family=ipv6 bgp-as-path-length=0-255 chain=transit-in-v6 comment="" disabled=no invert-match=no set-bgp-local-pref=130 set-bgp-med=500 set-distance=40
add action=discard chain=transit-in-v6 comment="" disabled=no invert-match=no
add action=accept address-family=ipv6 bgp-as-path="^\$" chain=transit-out-v6 comment="" disabled=no invert-match=no \
prefix-length=32
add action=discard chain=transit-out-v6 comment="" disabled=no invert-match=no

add action=accept address-family=ipv6 bgp-as-path-length=0-255 chain=transit-he-in-v6 comment="" disabled=no \
invert-match=no set-bgp-local-pref=125 set-bgp-prepend=4 set-distance=40
add action=discard chain=transit-he-in-v6 comment="" disabled=no invert-match=no
add action=accept address-family=ipv6 bgp-as-path="^\$" chain=transit-he-out-v6 comment="" disabled=no invert-match=no prefix-length=32 set-bgp-prepend=4 add action=discard chain=transit-he-out-v6 comment="" disabled=no invert-match=no

All on 4.16? I was going to upgrade from 3.30 to 4.16 to hopefully fix this, but I will wait if it isn't fixed still. Can MT please contact one of us for help to resolve this in 4.x? I'm sure it's an easy bug fix : ) I dare you to fix it : )

Yes, in my case we use ROS 4.16 on x86. Yet contact with support Ticket#2011022266000409

Also observed that all peerings restart (its generates autosupport) when change some filter (filter v6 is diferent that v4), i thing that process bgp kill and return to alive.

ROS 4 has issues with full bgp IPv6 tables where some routes dont become active or dont change, "it looks like some routes are still missing in kernel"

I'm being advised to use 5rc10 but I'm still suffering from the peer issue. I'm not sure if it's exactly related to your problem but MT aren't willing to backport the fix's to ROS 4.x for fear of stability problems.

We are trying to get around this issue by splitting off IPv6 from our core onto separate hardware so we can run 5rc10 without it causing problems for the IPv4 core

im only running 4-5k routes... ipv6 isnt that big yet. I think HE.net has almost 4k and cogent has about 2-3k.

Same here the global table is just over 4400 routes. Still ROS 4 and it seems 5rc10 still has issues with routes dropping in and out of being routable

Sorry to budge in. Sam - How does one get ahold of you these days?

This is a setting in the underlying Linux kernel. I've informed Mikrotik about this last week.

The problem is that some kernel-developer thought it was a smart move to set a max of 4096 ipv6 routes. So if there are more than 4096 routes in the active routing table, it looks like you have them, but they don't work.

See the following sysctl setting on your Linux box:
net.ipv6.route.max_size

Mikrotik needs to fix that, they said they will in the next update.

If I disable the he.net feed then its stable again.

I can't even ping the other end of the /126 they assigned me, which is a connected route. I get "no route to host". If i kill either bgp peer then its stable again.

v3.30

I am having exactly the same issue on two RB1100's. RouterOS 4.16

Problem is fixed, please wait v5RC12

will this be back ported to 4.x?
eta on RC12?

yes please 4.18 fix it ... : ) thank you ahead of time.

Wouldn't hold out hope. From my interactions with MT over this issue it sounds like ROS 4.xx would need a kernel upgrade to get the fix in place

Wouldn't hold out hope. From my interactions with MT over this issue it sounds like ROS 4.xx would need a kernel upgrade to get the fix in place

I will take a RC12 if that is all I can have... so an ETA would be great as I will upgrade as soon as its available. As we have just started seeing 4200+ routes it has all broken. Until now we have not had any huge issues with ipv6.

The bug with dynamic routing and v6 seems to be that some routes or all routes at random times will no install to the kernel and as such ROS will response with "no route to host", RC12 you can get from support now as we have done. So far so good for fixing this bug

thanks, ive contacted support (Ticket#2011032266000069) will wait and see if I can get rc12 today.

I have obtained rc12 via non-MikroTik support related methods and upgraded three RB1000 units from 5.0rc10.

It certainly fixes all of our IPv6-related issues (we have three full IPv6 routing tables) both concerning internal and external routing; it also appears to have solved our IPv6 VRRP issues (which are likely related to this).

Everything has been running perfectly since 11pm GMT last night...

Yes, ipv6 okay but problem with ipv4 in rc12

Some routes works and some doesn't.

In Rc11 no such problem regarding IPV4.

And both RC11 and RC12 have problem with packet loss (approx 1-2 packets lost per 1000packets while working BGP with ISP peers). This is not the case in 4.16

IPv6 seems to work now.

However, my IPv4 full table peerings cause massive CPU usage (80-100%). I'll email support with more info.

Hmm. Support says the higher CPU load is normal due to changes in the processing of BGP updates. I don't know about you guys, but I'm not really confortable with a router constantly running at 80-100% cpu..