Bug #11686
closedFRR generated ACCEPTFILTER permit statement broken
0%
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
Related issues
Updated by Jim Pingle almost 4 years ago
- Project changed from pfSense to pfSense Packages
- Category changed from Routing to FRR
- Target version deleted (
2.5.1) - Release Notes deleted (
Default)
Updated by Viktor Gurov almost 3 years ago
- Assignee set to Viktor Gurov
Updated by Jim Pingle almost 3 years ago
- Status changed from New to Pull Request Review
Updated by Marcos M almost 3 years ago
- File acceptfilter.txt acceptfilter.txt added
This can be applied using the System Patches package.
Updated by Viktor Gurov almost 3 years ago
- Related to Bug #11836: FRR ACCEPTFILTER shows out of order prefix-list added
Updated by Azamat Khakimyanov almost 3 years ago
- 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.