[FROG] The feature request that are closed - where to go?

[Donald Sharp]

If you have a feature that you want implemented you have several options:

a) Open a issue request and hope that someone in the community picks it
up.  This is unlikely to ever happen.  All the developers that I am aware
of that are working on FRR are being paid for it by some company.  Most do
not have the liberty of working on what they feel like.  You have already
done this route, right?
b) Purchase a switch/router that some company is selling support for FRR
and get them to implement this feature for you.  There are more than a few
( 6Wind, Nvidia, Cisco to name a few off the top of my head ) that do
this.  This is also a hard route to go down unless you have a lot of
purchasing power.
c) Hire a developer to develop the feature for you.  If you want to go this
route, message me privately and I can get you in touch with a group that
does this.
d) Implement it yourself.  The community always welcomes new code that
meets our guidelines.

thanks!

donald

On Mon, Sep 2, 2024 at 8:35 AM Konstantin Shalygin <k0ste at k0ste.ru> wrote:

> Hi list,
>
> I created a request [1], waited 5 years, then it was closed, but nothing
> was done. Is there possible don't do that? Because is still actually for
> us. The current PBR implementation is very limited and woks only for input
> packets on interface. It may be a secret for some, but the network
> connections of the Linux host itself are created without an interface. This
> means that even if you hang the policy on the interface lo - the rule will
> not work
>
> Sep 02 17:46:51 example.com kernel: LINUX OUTPUT IS: *IN=* OUT=vlan999
> SRC=109.202.2.222 DST=1.1.1.1 LEN=73 TOS=0x00 PREC=0x00 TTL=64 ID=13835
> PROTO=UDP SPT=41942 DPT=53 LEN=53 UID=973 GID=973 *MARK=0xd3*
>
> For example:
>
> !
> interface lo
>  pbr-policy sample
> exit
> !
> nexthop-group sample
>  nexthop 10.9.0.1 tap0 weight 50
>  nexthop 10.10.0.1 tap1 weight 50
> exit
> !
> pbr-map sample seq 5
>  match mark 211
>  set nexthop-group sample
> exit
>
>
> Thats produces rule: from all fwmark 0xd3 *iif lo* lookup 10000 proto
> zebra
>
> How-to make this rule actually work
>
> * make ability for FRR to omit the *iif* field (for example, via pbr
> (pbr-global?) without interface or with special sub-command)
> * allow to set *table_id* or *prio* in pbr-map (for 3rd-party
> workarounds):
>   * set nexthop-group sample *table_id 10* (10010, for the 'pbr table
> range')
>   * with fixed *table_id* number we can add the ip rule via custom script
> (the same rule as FRR created, without iif filed)
> * allow to set *prio* filed for the rule in pbr-map (for 3rd-party
> workarounds):
>   * set nexthop-group sample *prio 10010*
>   * this produces: from all fwmark 0xd3 iif lo lookup 10000 *prio 10010*
> proto zebra
>   * now possible to add custom script with rule 'from all fwmark 0xd3 *goto
> 10010*'
>
>
> From my point of view, it looks like a very simple fix can significantly
> expand the capabilities of FRR for the PBR functions
>
> Thanks,
> k
> [1] https://github.com/FRRouting/frr/issues/3242
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20240902/997639a7/attachment.htm>