Bug #11686
closed
FRR generated ACCEPTFILTER permit statement broken
Added by Robert Sailer over 3 years ago.
Updated almost 3 years ago.
Affected Architecture:
All
Description
When the ACCEPTFILTER is generated all goes well except the last line which is ip prefix-list ACCEPTFILTER seq 10 permit any.
When it starts ospf works fine and the routes are in the ospf database but zebra refuses to add them to the FIB.
After removing "seq 10" manually and restarting frr it just works as expected.
Solution proposed: Just remove "seq 10" when generating the last rule for the ACCESSFILTER from the generator code
Files
- Project changed from pfSense to pfSense Packages
- Category changed from Routing to FRR
- Target version deleted (
2.5.1)
- Release Notes deleted (
Default)
- Assignee set to Viktor Gurov
- Status changed from New to Pull Request Review
This can be applied using the System Patches package.
- Related to Bug #11836: FRR ACCEPTFILTER shows out of order prefix-list added
- Status changed from Pull Request Review to Resolved
Tested on 22.01-RELEASE (built on Mon Feb 07 16:37:59 UTC 2022) with patch applied.
I see correct ACL sequence now. For example for my setup
ip prefix-list ACCEPTFILTER seq 10 deny 192.168.25.0/24
ip prefix-list ACCEPTFILTER seq 20 deny 192.168.25.1/32
ip prefix-list ACCEPTFILTER seq 30 deny 172.31.25.0/24
ip prefix-list ACCEPTFILTER seq 40 deny 172.31.25.1/32
ip prefix-list ACCEPTFILTER seq 50 deny 10.10.87.0/30
ip prefix-list ACCEPTFILTER seq 60 deny 10.10.87.2/32
ip prefix-list ACCEPTFILTER seq 70 permit any
so I saw that Permit Any rule had correct sequence number (last in order)
I marked this Bug as resolved.
Also available in: Atom
PDF