Feature #11206
closed
Added by Ben Hughes almost 4 years ago.
Updated 4 months ago.
Description
Update the FRR port to 7.5 and update pfSense-pkg-frr to use 7.5 new features and other changes and fixes.
- FRR reload configuration when removing a list item
- Update FRR port to 7.5
- Add IP type to FRR access and prefix lists
- When used in a route-map the type needs to be known to select the correct `match` statement to use
- Enhance validation so the correct address types can only be present
- Add migrations
- Add checkbox for `any` matches to unify behaviour between IPv4 and IPv6
- Add force service restart button to FRR main page
- FRR Improve logging
- Add FRR 7.5 new features
- BGP
- Add force option to `maximum-prefix`
- Add `maximum-prefix-out` option
- Add neighbor shutdown message
- Add neighbor automatic shutdown
- Add global neighbor shutdown
- OSPF6d
- Area generator function write directly
I've bumped the port version to 0.7.0 for pfSense-pkg-frr because of the changes, but looking back at everything that's been done I think it really needs a major version bump to 1.0.0 as there's been a lot of changes and most of them not backwards compatible. Just wanted to know what the general thoughts around that were?
Ben Hughes wrote:
I've bumped the port version to 0.7.0 for pfSense-pkg-frr because of the changes, but looking back at everything that's been done I think it really needs a major version bump to 1.0.0 as there's been a lot of changes and most of them not backwards compatible. Just wanted to know what the general thoughts around that were?
It's probably past time for it to be set that high, so that's fine to do on the next big change.
Ok sounds a plan, as you say in hindsight I should've started at 1.0.0 when first starting the move to a integrated config file. I suppose at least this will be only be generally released with 2.5 so lessens the impact somewhat.
As I need to split the FRR and pfsense PKG ports up into two separate PRs and the access/prefix lists aren't backwards compatible I'll take the liberty of bumping the PKG version at the same time.
- Status changed from New to Pull Request Review
Network engineer here - have been configuring routers since the early 90's (Cisco IOS/IOS-XR/Nexus, Juniper, Alcatel-Lucent, Huawei and others in Enterprise and ISP) and have never not used a loopback address for Router ID (Cisco routing basics 101... using a LAN interface for BGP or OSPF RID is basically a sackable offence! :o And for what it's worth most places I've worked prefer each device to have a separate OSPF RID from the BGP RID if speaking both). It would be much appreciated if we could set one or more Loopback interface addresses as routing IDs within FRR/pfSense. Thanks.
I'm still not following what this has to do with making the loopback participate in OSPF? You can set the OSPF/BGP/OSPF6/global router-id settings to whatever you'd like as it stands.
I see that Ben is no longer logging in?
Login: bmh.01
Registered on: 10/04/2018
Last connection: 02/24/2021
Can someone close this stale case off as resolved? Anything outstanding would be been raised separately (and maybe closed already). We are well beyond FRR 7.5 now. Thanks.
- Status changed from Pull Request Review to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by