Page MenuHomeVyOS Platform

Migration from vyatta-quagga to FRR
Closed, ResolvedPublicFEATURE REQUEST

Description

As discussed with @dmbaturin
Creating this task to track progress on migration
and also for subtasks that may appear during the migration process

Details

Difficulty level
Hard (possibly days)
Version
1.2
Why the issue appeared?
Will be filled on close

Event Timeline

Antti made some quick tests see diagram

3PqpIr1.png (615×955 px, 103 KB)

Hi!

Tried some routing protocols.

  • Multi-area OSPF with stubs, RIP, BGP
  • Redistributions (via one router)

Diagram: https://imgur.com/3PqpIr1

All worked as expected, minus this one thing: when attempting to redistribute connected to ospf, using route-map, I kept getting this:

vyos@VYOSALPHA12-1## set protocols ospf redistribute connected route-map REDISTCONN
[edit]
vyos@VYOSALPHA12-1# commit
[ protocols ospf redistribute connected ]
% Unknown command.
protocols ospf failed
Commit failed

If I leave the route-map out, all is good.

Also, few times got into this kind of slump after commit:
vyos@vyos# save
DEBUG vexit_internal: calling getEditResetEnv() without config session
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vyos# exit
exit
There are stopped jobs.
DEBUG vexit_internal: calling getEditResetEnv() without config session
[edit]

I've upgraded from 1.1.7 to this alpha version.

When configuring BGP I cannot set a hold-time less than 4 seconds. FRR allows for 3 seconds (I didn't configure BGP until this alpha version, so this issue may exist in 1.1.7 as well).

I adjusted this in
/opt/vyatta/share/vyatta-cfg/templates/protocols/bgp/node.tag/timers/holdtime/node.def

val_help: u32:3-65535; Hold-time in seconds (default 180)
syntax:expression: $VAR(@) == 0 || ($VAR(@) >= 3 && $VAR(@) <= 65535);

"hold-time interval must be 0 or between 3 and 65535"

PS. I am a long timer user of VyOS since the original version when it forked from Vyatta. Hopefully I can help contribute to the project.

  • Matt

I have upgraded my "parallel" universe. It look like redistribute static does not work.

This router is upgraded from 1.1.6 to 1.2.0 frr
config in 1.1.6 and saved during upgrade:

protocols {

ospf {
    area 0.0.0.0 {
        network 172.18.0.0/16
    }
    parameters {
        abr-type cisco
        router-id 172.18.255.62
    }
    redistribute {
        static {
            metric 10
            metric-type 2
        }
    }
}
static {
    route 172.16.136.0/24 {
        next-hop 172.18.41.16 {
        }
    }
    route 172.18.254.76/31 {
        next-hop 172.18.161.44 {
        }
    }
    route 172.18.255.76/32 {
        next-hop 172.18.161.44 {
        }
    }
    route 172.18.255.77/32 {
        next-hop 172.18.161.44 {
        }
    }
    route 172.18.255.252/31 {
        next-hop 172.18.161.44 {
        }
    }
    route 172.24.0.120/29 {
        next-hop 172.18.41.16 {
        }
    }
    route 172.31.0.0/19 {
        next-hop 172.18.161.108 {
        }
    }
    route 192.168.223.64/28 {
        next-hop 172.18.41.1 {
        }
    }
}

}

I am also unable to redistribute static into OSPF if metric is defined.

I think it make sense to do subtask per some particular issue.
It will be easier to track
as @dmbaturin suggested, there will be a lot of work on cli

Are we going for FRR in 1.2, or are we going to keep Quagga?
I'm just wondering what I should test ;-)

@aopdal I suppose 1.2.0 will stick with quagga, though if we are able to weed out all issues with FRR in reasonable timeframe, perhaps we can attempt migration to FRR in 1.2.0 rather than a release after it.

@dmbaturin is there a (estimated/proposed) releasedate on 1.2.0?

The current Quagga included is rather old, so if it is possible to migrate to FRR that would make a big difference.
I am testing my configs in the alpha release and so far it looks good. To assist i can test setups and configs.

We are hit by bugs in the OSPF of Quagga which are not fixed in newer versions, but are fixed in FRR. Most of my stuff is working. Getting up to date on Quagga is probably also quite some job, and from the testing perspective it's just the same. Everything must be tested... From the design and documentation perspective we need to put down some more work if we are using FRR.

I may help out with testing and documentation, and are willing to spend more time if we are going with FRR than Quagga because then I will get the bugs which are hitting me resolved...

Hi,

Probably not the best place to ask, but can anyone guide me the steps to build VyOS 1.2 with frr. I have built the latest source but it still comes with quagga (and without IS-IS support which is enabled in 1.2 alpha image).

syncer changed the subtype of this task from "Task" to "Feature Request".Oct 18 2018, 5:47 AM

Since most of the work is done and every release candidate of 1.2.0 has been using FRR already, I suppose we should close it. Remaining issues that are causes by FRR incompatibilities should, and are getting their own tasks anyway.

Unknown Object (User) changed the status of subtask T832: `show monitoring protocols bgp` doesn't work with frr from Open to Backport pending.May 13 2020, 10:34 AM