I will have to upgrade a router soon. Should I use MT v3.7 or go with quagga?

Its been a while since I asked or saw feedback with current version. I need two full feeds from two upstreams and one internal interface with OSPF advertising default route. I am not redistributing BGP routes into OSPF - only the default route.

I will need to add an extra ASN to one interface to reduce a bit of its traffic in favor of our faster peer - but other than that its all pretty vanilla.

Thanks,
Scott

Hi,

I have one RB1000 running with 3.7. 2 iBGP, 1 eBGP session. eBGP is only
backup (one default route). iBGP carry full feed.

Sessions are 10 day's up now. Works without a flaw until now.

I've noticed some strange OSPF behavior on the direct attached net since
this box is running. 2 2.9.x boxes did not get all routes sometimes (very
sporadic). Other 2.9 boxes and ciscos work fine. I'm not sure what the problem
is and wether it has to do with this 3.7 machine. But be warned there might
be an OSPF issue.

Stefan

But be warned there might be an OSPF issue.

Yeah, we have seen something similar on our 3.x routers speaking OSPF, except in our case some 2.9.x boxes have "sporadic" problems maintaining OSPF adjacency with 3.x while others are fine (just like you), but our Ciscos do have trouble with 3.x as well. This is contrasted with later versions of 2.9.x (say, .42 and up) with routing-test enabled, which have been mostly solid for us.

We have also seen occasions where OSPF on 3.x will work great (for the most part) as long as you don't touch anything! If OSPF is working on a 3.x box and we just leave it alone, it will, for the most part, continue to work, but if we reboot it for whatever reason, or change any aspect of the OSPF configuration or change the status-quo, we risk complete OSPF meltdown on that particular router. Once we changed a simple setting, and the 3.x box lost all its neighbors. Another time we introduced a new OSPF neighbor on the backbone area, and as soon as the 3.x box saw it it freaked out and did a similar thing (lost neighbors). It usually takes several reboots of the box after this happens for everything to be normal again. Once we get it back up we just don't touch it again if we can help it.

We have submitted a bug report to MikroTik complete with several SUPOUT files, but they have been unable to reproduce it so far (AFAIK), and frustratingly enough, we have also had trouble reproducing it on the bench. I have a collection of Cisco 2620/IOS 12.x, RouterOS 2.9.51, and RouterOS 3.7 boxes all connected up together in a test network in the "lab" and I cannot for the life of me make OSPF fail on the 3.x box when it has those other boxes as its neighbors in the lab setting no matter what I do. It seems to run just perfectly. So apparently, whatever the problem is, it is obscure enough to evade all of us, and we don't know what the key factor is on our production network that is causing the failures.

So, yes, be warned that 3.x might have some OSPF issues lurking about, though hopefully we can manage to figure out soon what is going on...

Regards,

-- Nathan

But be warned there might be an OSPF issue.

Yeah, we have seen something similar on our 3.x routers speaking OSPF, except in our case some 2.9.x boxes have "sporadic" problems maintaining OSPF adjacency with 3.x while others are fine (just like you), but our Ciscos do have trouble with 3.x as well. This is contrasted with later versions of 2.9.x (say, .42 and up) with routing-test enabled, which have been mostly solid for us.

We have also seen occasions where OSPF on 3.x will work great (for the most part) as long as you don't touch anything! If OSPF is working on a 3.x box and we just leave it alone, it will, for the most part, continue to work, but if we reboot it for whatever reason, or change any aspect of the OSPF configuration or change the status-quo, we risk complete OSPF meltdown on that particular router. Once we changed a simple setting, and the 3.x box lost all its neighbors. Another time we introduced a new OSPF neighbor on the backbone area, and as soon as the 3.x box saw it it freaked out and did a similar thing (lost neighbors). It usually takes several reboots of the box after this happens for everything to be normal again. Once we get it back up we just don't touch it again if we can help it.

We have submitted a bug report to MikroTik complete with several SUPOUT files, but they have been unable to reproduce it so far (AFAIK), and frustratingly enough, we have also had trouble reproducing it on the bench. I have a collection of Cisco 2620/IOS 12.x, RouterOS 2.9.51, and RouterOS 3.7 boxes all connected up together in a test network in the "lab" and I cannot for the life of me make OSPF fail on the 3.x box when it has those other boxes as its neighbors in the lab setting no matter what I do. It seems to run just perfectly. So apparently, whatever the problem is, it is obscure enough to evade all of us, and we don't know what the key factor is on our production network that is causing the failures.

So, yes, be warned that 3.x might have some OSPF issues lurking about, though hopefully we can manage to figure out soon what is going on...

Regards,

-- Nathan

Hi Nathan,

have you tried to influence the OSPF Priority to ensure the 3.7 box is not designated or
backup designated router on this segment? May be there is a problem when 3.7 takes
one of this roles.

Stefan

I was mostly concerned with BGP behaviour... I have OSPF working fine across the board and I make changes regularly. I have 2.9.50 and 3.7 mostly, with a quagga or two in the mix.

I need to upgrade a bgp router and are considering options.

Scott