As discussed with @dmbaturin
Creating this task to track progress on migration
and also for subtasks that may appear during the migration process
Description
Details
- Version
- 1.2
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | FEATURE REQUEST | dmbaturin | T306 Migration from vyatta-quagga to FRR | ||
Resolved | UnicronNL | T309 Get FRR package | |||
Wontfix | dmbaturin | T447 show ip bgp neighbor x.x.x.x advertised-routes empty | |||
Resolved | BUG | syncer | T441 Enable VyOS images to build with FRR instead of vyatta-quagga | ||
Resolved | BUG | dmbaturin | T832 `show monitoring protocols bgp` doesn't work with frr | ||
Resolved | BUG | oleksandr.mamenko | T856 upgrade from 1.1.8 to 1.2.0-rolling breaks OSPF area-type NSSA |
Event Timeline
Antti made some quick tests see diagram
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 failedIf 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 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.
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).
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.