Hi Kirill, At this point, session rules table is only used for blocking or allowing traffic, but the intent is to support more complex actions in the future. More inline.
> On Nov 20, 2025, at 8:30 PM, Kirill Shileev via lists.fd.io > <[email protected]> wrote: > > Hi Florin > > I have 2 dpdk ifaces in the bridge domain instrumented with loop BVI having > 30.22.0.201. I want all packets coming from one dpdk with any combination of > src and dst ip first to come to VCL app You may want to take a look at hsi (host stack intercept) plugin as well, although at this point variants of it have been only integrated with builtin apps. > being modified somehow inside the app and then go out via another dpdk. For > that I do > > session rule add appns default proto tcp 0.0.0.0/0 <http://0.0.0.0/0> 443 > 0.0.0.0/0 <http://0.0.0.0/0> 443 action 3 > > where 3 is idx of VCL app running either as native VCL or via LD_PRELOAD That will indeed force traffic that hits that rule to be matched to an action_index (3) which data plane lookups interpret (currently) as app_index which is subsequently converted to first app listener (see session_lookup_connection_wt4). This should probably need to be enhanced in the future to match app listeners instead of apps. But the thing to note here, given the wildcard match, any other listener to be added in default namespace after the rule above, will fail to bind (as you’ve noticed already). Another note is that > Since this session rule feature is not very well documented, I'm just > experimenting. My assumptions: > > 1. that 3 is actually a VCL app index as reported by sh app. Some people say > (also GPT) that it's type of action instead and in 25.10 just 2 of them > exist : > #define SESSION_RULES_TABLE_ACTION_DROP (MMA_TABLE_INVALID_INDEX - 1) > #define SESSION_RULES_TABLE_ACTION_ALLOW (MMA_TABLE_INVALID_INDEX - 2) > > the above is session_rule_table.h: 62 Those are the two currently supported actions. The other actions, in particular the use of app_index, were part of a rudimentary POC built 8+ years ago that hasn’t been improved/productized since. > > 2. proto tcp 0.0.0.0/0 <http://0.0.0.0/0> 443 0.0.0.0/0 <http://0.0.0.0/0> > 443 is just 5-tuple filter meaning that tcp packets with any src ip and port > and dst ip and port is to be transported to app 3 > and nothing like NAT happens. Correct. > 3. what is not clear for me - on which ip my VCL app needs to bind in > vppcom_session_bind( > VCL binds to ip:port pair provided by app. For vcl one can specify interface also, in which case ip is selected, but if this is nginx it’ll be just an ip:port pair from the config. If that ip:port pair matches in vnet_listen a listener looked up via app_listener_lookup, the bind is refused. Note that there is some inconsistency in how the listener is looked up (patch here [1]). But I suspect it won’t help as the listener will still be found. Regards, Florin [1] https://gerrit.fd.io/r/c/vpp/+/44204 > please confirm what is valid > > > On Fri, Nov 21, 2025 at 5:40 AM Florin Coras via lists.fd.io > <http://lists.fd.io/> <[email protected] > <mailto:[email protected]>> wrote: >> Hi Kirill, >> >> That is probably accurate, although I’ve never tried it. The rules table >> does apply to listeners but the listener lookup logic (see >> app_listener_lookup) will just use the action_index to find an app listener. >> So if there is an app listener with that index, bind will report port is in >> use. >> >> Could you provide a bit more details about your usecase? >> >> Regards, >> Florin >> >>> On Nov 20, 2025, at 4:35 AM, Kirill Shileev via lists.fd.io >>> <http://lists.fd.io/> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi folks >>> >>> I'm trying to do something like that: >>> vppctl ses rule add appns default proto tcp 0.0.0.0/0 <http://0.0.0.0/0> >>> 443 {ssl}/32 443 action 3 >>> >>> then bind some VCL app to port 443, this fails. >>> >>> According to GPT: >>> >>> The bind fails because: >>> >>> Port 443 is reserved by a VPP session rule >>> → VCL apps cannot bind to ports controlled by rules. >>> >>> Fix: >>> >>> vppctl session rule del lcl 0.0.0.0/0 443 rmt 30.22.0.201/32 443 >>> >>> please confirm that this is indeed impossible! And if GPT's wrong, please >>> point me in the right direction with some good example? >>> >>> -- >>> Best wishes, Kirill >>> >>> >>> >> >> >> >> > > > > -- > Best wishes, Kirill > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26544): https://lists.fd.io/g/vpp-dev/message/26544 Mute This Topic: https://lists.fd.io/mt/116389781/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
