pbr: T6430: Extend table number limits for policy route set table

[talmakion]

Change Summary

A simple range change on available rt-ids for PBR "set table", matching up against the range change done to VRFs.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://vyos.dev/T6430
• https://vyos.dev/T6254 - original referenced VRF change

Related PR(s)

Component(s) name

• policy route/pbr

Proposed changes

Simple change to the route table IDs available:

# set policy route TEST rule 10 set table 4000
# set policy route6 TEST6 rule 505 set table 60000

Previous range was 1-200, now it is 1-65535.

There is a dependence on fwmarks between iproute2 and nft parts of PBR, the IDs of which are calculated off the rt-id. I've done some quick checks that this change won't collide or interfere with other existing usage at the high end of fwmark's ID range but they were not comprehensive.

How to test

vyos@TEST-VYOS-LEFT# set policy route TEST rule 10 set table <TAB>
Possible completions:
   <1-65535>            Table number
   main                 Main table
      
[edit]
vyos@TEST-VYOS-LEFT# set policy route TEST rule 10 set table 4000
[edit]
vyos@TEST-VYOS-LEFT# commit
[edit]
vyos@TEST-VYOS-LEFT# sudo nft list table ip vyos_mangle
table ip vyos_mangle {
        chain VYOS_PBR_PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
        }

        chain VYOS_PBR_POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
        }

        chain VYOS_PBR_UD_TEST {
                counter packets 0 bytes 0 meta mark set 0x7ffff05f return comment "ipv4-route-TEST-10"
        }
}
[edit]
vyos@TEST-VYOS-LEFT# ip rule show
220:    from all lookup 220
1000:   from all lookup [l3mdev-table]
2000:   from all lookup [l3mdev-table] unreachable
4000:   from all fwmark 0x7ffff05f lookup 4000
32765:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default
[edit]
vyos@TEST-VYOS-LEFT# set policy route6 TEST6 rule 500 set table <TAB>
Possible completions:
   <1-65535>            Table number
   main                 Main table

[edit]
vyos@TEST-VYOS-LEFT# set policy route6 TEST6 rule 500 set table 45 
[edit]
vyos@TEST-VYOS-LEFT# set policy route6 TEST6 rule 505 set table 60000
[edit]
vyos@TEST-VYOS-LEFT# commit
[edit]
vyos@TEST-VYOS-LEFT# ip -6 rule show
45:     from all fwmark 0x7fffffd2 lookup 45
220:    from all lookup 220
1000:   from all lookup [l3mdev-table]
2000:   from all lookup [l3mdev-table] unreachable
32765:  from all lookup local
32766:  from all lookup main
60000:  from all fwmark 0x7fff159f lookup 60000
[edit]
vyos@TEST-VYOS-LEFT# sudo nft list table ip6 vyos_mangle
table ip6 vyos_mangle {
        chain VYOS_PBR6_PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
        }

        chain VYOS_PBR6_POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
        }

        chain VYOS_PBR6_UD_TEST6 {
                counter packets 0 bytes 0 meta mark set 0x7fffffd2 return comment "ipv6-route6-TEST6-500"
                counter packets 0 bytes 0 meta mark set 0x7fff159f return comment "ipv6-route6-TEST6-505"
        }
}

Smoketest result

$ python3 /usr/libexec/vyos/tests/smoke/cli/test_policy_route.py
test_pbr_group (main.TestPolicyRoute.test_pbr_group) ... ok
test_pbr_mark (main.TestPolicyRoute.test_pbr_mark) ... ok
test_pbr_mark_connection (main.TestPolicyRoute.test_pbr_mark_connection) ... ok
test_pbr_matching_criteria (main.TestPolicyRoute.test_pbr_matching_criteria) ... ok
test_pbr_table (main.TestPolicyRoute.test_pbr_table) ... ok

---

Ran 5 tests in 23.847s

OK

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[dmbaturin]

Could you please check if this will not interfere with any reserved tables, like 255? We were discussing the PR about VRFs and decided against merging it until we can prove that it's safe, and by extension, this change may not actually be safe either.

[talmakion]

I can try to figure out how to restrict it away from reserved IDs. default and main should be fine and we're not manipulating those tables but just directing traffic there. unspec (0) was always out of range.

Is it worth me running through some testing or if the VRF change has been dropped, just closing this one out?

Will VRFs still retain the 100-65535 range they've had for a while, so this PR could be modified to match (while also avoiding 255)? Or, is having PBR able to interact directly across VRF RTs a problem itself?

[c-po]

Is it worth me running through some testing or if the VRF change has been dropped, just closing this one out?

IMHO 200 non VRF routing tables should be enough for now. If anyone has a valid reason for "more" we can lift it