Project

General

Profile

Actions

Feature #11206

open

FRR 7.5

Added by Ben Hughes 7 months ago. Updated 7 months ago.

Status:
Pull Request Review
Priority:
Normal
Assignee:
Category:
FRR
Target version:
-
Start date:
12/31/2020
Due date:
% Done:

0%

Estimated time:

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

Actions #2

Updated by Ben Hughes 7 months ago

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?

Actions #3

Updated by Jim Pingle 7 months ago

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.

Actions #4

Updated by Ben Hughes 7 months ago

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.

Actions #6

Updated by Ben Hughes 7 months ago

Actions #7

Updated by Jim Pingle 7 months ago

  • Status changed from New to Pull Request Review
Actions #8

Updated by Christian McDonald 7 months ago

If we are moving forward with 7.5, we should consider including the loopback interface ospf modification here too https://redmine.pfsense.org/issues/11186

Actions #9

Updated by Gavin Owen 7 months ago

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.

Actions #10

Updated by Ben Hughes 7 months ago

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.

Actions

Also available in: Atom PDF