Re: [vpp-dev] Question about acl match/permit behavior.
On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko
wrote:
> I suggest making a unit test that captures this behavior and fails, then
> we can look at what is the best way of fixing it and incorporate into the
> CI...
>
> I remember this type of scenario being addressed once, not sure if it was
> the same one or not...
>
> But you could probably work around it by having the ACLs on the inner
> interface.
>
> --a
>
>
Hi Andrew,
In general, for NAT and stateful ACL to coexist, the NAT and ACL nodes must
be ordered in the opposite order for in2out vs out2in packets. E.g. if you
the NAT ran first followed by a stateful output ACL for outbound packets,
then inbound packets must use the reverse ordering - input ACL followed by
NAT. I ran into the same problem Venkat is having a while back due to the
order of the NAT & ACL features nodes being the same in both directions. I
did fix it and added a unit test, but I think I only fixed it for endpoint
dependent mode. The endpoint independent in2out nodes look like some of
them are running after the ACL plugin output node:
VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-in2out-output",
.runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};
VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-in2out-output-worker-handoff",
.runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};
VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-hairpin-src",
.runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};
I'm not positive about the "hairpin" node, but I think it ought to work if
the code above is changed to look like this:
VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-in2out-output",
.runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
.runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-in2out-output-worker-handoff",
.runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
.runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-hairpin-src",
.runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
.runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
Venkat, are you using any of the nodes listed above (i.e. are you using the
output-feature variant of the in2out node in endpoint independent mode)? If
so, I suggest applying the change I described and building from that code
and test whether it solves your problem.
-Matt
> On 22 Sep 2020, at 18:58, Venkat wrote:
>
>
> Thank you Andrew for the pointers and setting the expectations for VPP
> ACL.
>
> On another topic, since the stateful behavior of ACL is per interface, I
> setup permit+reflect output ACL on WAN interface ( Internet-facing Public
> IP) for internet bound traffic. And I also have to Deny all incoming
> traffic (input ACL on WAN interface) for security purposes. In addition, I
> have SNAT configured on the same interface so that packets get source NATed
> when going to the internet.
>
> Now the problem is since the ACL node comes before the SNAT node in the
> feature ARC, stateful ACL sessions are built for the original Source/Dest
> IP pair prior to SNAT.
> Return traffic coming into the WAN interface comes with WAN IP (public
> IP), gets dropped because of Deny all input ACL and the purpose of stateful
> ACL is lost.
> How is this scenario typically addressed?
>
> thanks
> Venkat
>
>
>
> On Thu, Sep 17, 2020 at 3:19 PM Andrew Yourtchenko
> wrote:
>
>>
>>
>> On 17 Sep 2020, at 23:55, Venkat wrote:
>>
>>
>>
>> 2. What happens when ACL config is modified while traffic is flowing?
>> Would the packets continue to hit the special-case "-1" session until the
>> session is timed out and re-claimed? If that's true, then packets would
>> continue to sneak through even when a user modifies the ACL from
>> Permit+Reflect to Deny.
>>
>>
>> Yep. You can look at the code, there is a debug CLI tweak to reclassify
>> sessions, but I am not sure anyone actually uses it.
>>
>> There is no “always right” answer to this ~20 year old question.
>>
>> ACL plugin is very explicitly not a “fancy firewall”.
>>
>> [VD]: One more question on this behavior. If packets continue to hit
>> the special-case "-1" session, would they ever hit the modified ACL? Or
>> does the reclassify sessions logic kick in periodically (every timeout
>> independent of traffic hit) and cleans up the special-case "-1" sessions so
>> that new sessions build up again based on the current state of ACLs rule? I
>> would assume,
Re: [vpp-dev] Question about acl match/permit behavior.
But you could probably work around it by having the ACLs on the inner interface. [VENKAT]: We currently are following that approach. Setting ACLs on the LAN interface. But it comes with its own problems. - First, the WAN interface is wide open to the internet without any FW rules - Second, input ACLs on LAN interferes with ABF functionality as the ACL node comes before the ABF node. It's getting trickier as we configure multiple features and it's co-existence. thanks Venkat On Tue, Sep 22, 2020 at 10:21 AM Andrew Yourtchenko wrote: > I suggest making a unit test that captures this behavior and fails, then > we can look at what is the best way of fixing it and incorporate into the > CI... > > I remember this type of scenario being addressed once, not sure if it was > the same one or not... > > But you could probably work around it by having the ACLs on the inner > interface. > > --a > > On 22 Sep 2020, at 18:58, Venkat wrote: > > > Thank you Andrew for the pointers and setting the expectations for VPP > ACL. > > On another topic, since the stateful behavior of ACL is per interface, I > setup permit+reflect output ACL on WAN interface ( Internet-facing Public > IP) for internet bound traffic. And I also have to Deny all incoming > traffic (input ACL on WAN interface) for security purposes. In addition, I > have SNAT configured on the same interface so that packets get source NATed > when going to the internet. > > Now the problem is since the ACL node comes before the SNAT node in the > feature ARC, stateful ACL sessions are built for the original Source/Dest > IP pair prior to SNAT. > Return traffic coming into the WAN interface comes with WAN IP (public > IP), gets dropped because of Deny all input ACL and the purpose of stateful > ACL is lost. > How is this scenario typically addressed? > > thanks > Venkat > > > > On Thu, Sep 17, 2020 at 3:19 PM Andrew Yourtchenko > wrote: > >> >> >> On 17 Sep 2020, at 23:55, Venkat wrote: >> >> >> >> 2. What happens when ACL config is modified while traffic is flowing? >> Would the packets continue to hit the special-case "-1" session until the >> session is timed out and re-claimed? If that's true, then packets would >> continue to sneak through even when a user modifies the ACL from >> Permit+Reflect to Deny. >> >> >> Yep. You can look at the code, there is a debug CLI tweak to reclassify >> sessions, but I am not sure anyone actually uses it. >> >> There is no “always right” answer to this ~20 year old question. >> >> ACL plugin is very explicitly not a “fancy firewall”. >> >> [VD]: One more question on this behavior. If packets continue to hit >> the special-case "-1" session, would they ever hit the modified ACL? Or >> does the reclassify sessions logic kick in periodically (every timeout >> independent of traffic hit) and cleans up the special-case "-1" sessions so >> that new sessions build up again based on the current state of ACLs rule? I >> would assume, it's the latter case, otherwise, modified ACL would never hit >> if traffic continues to flow. >> >> >> Only with the idle timeout. >> >> ACL plugin is not intended to participate in a SWAT team, really. :-) >> >> —a >> >> >> >> On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko < >> ayour...@gmail.com> wrote: >> >>> >>> >>> On 17 Sep 2020, at 19:29, Venkat wrote: >>> >>> >>> Andrew, >>> >>> I have a few follow up questions on the stated behavior. >>> >>> 1. Does the behavior you outlined about hitting special-case "-1" >>> entries apply to UDP traffic as well if the ACL rule is stateful? >>> >>> >>> Yup. >>> >>> >>> 2. What happens when ACL config is modified while traffic is flowing? >>> Would the packets continue to hit the special-case "-1" session until the >>> session is timed out and re-claimed? If that's true, then packets would >>> continue to sneak through even when a user modifies the ACL from >>> Permit+Reflect to Deny. >>> >>> >>> Yep. You can look at the code, there is a debug CLI tweak to reclassify >>> sessions, but I am not sure anyone actually uses it. >>> >>> There is no “always right” answer to this ~20 year old question. >>> >>> ACL plugin is very explicitly not a “fancy firewall”. >>> >>> >>> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL >>> hit would result in the creation of such a session and subsequent packets >>> would by-pass ACL rules and continue to be served by special-case "-1". >>> >>> >>> ...as your have observed it. The return packets on that interface >>> matching the same five tuple, too. >>> >>> —a >>> >>> >>> >>> thanks >>> Venkat >>> >>> >>> On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko < >>> ayour...@gmail.com> wrote: >>> Hi Venkat, Before doing ACL checks, acl-plugin checks the establshed sessions on the given interface. If an already established session is hit the action is set to "3" and no further ACL check is done, which is what you see in your output.
Re: [vpp-dev] Question about acl match/permit behavior.
Thank you Andrew for the pointers and setting the expectations for VPP ACL. On another topic, since the stateful behavior of ACL is per interface, I setup permit+reflect output ACL on WAN interface ( Internet-facing Public IP) for internet bound traffic. And I also have to Deny all incoming traffic (input ACL on WAN interface) for security purposes. In addition, I have SNAT configured on the same interface so that packets get source NATed when going to the internet. Now the problem is since the ACL node comes before the SNAT node in the feature ARC, stateful ACL sessions are built for the original Source/Dest IP pair prior to SNAT. Return traffic coming into the WAN interface comes with WAN IP (public IP), gets dropped because of Deny all input ACL and the purpose of stateful ACL is lost. How is this scenario typically addressed? thanks Venkat On Thu, Sep 17, 2020 at 3:19 PM Andrew Yourtchenko wrote: > > > On 17 Sep 2020, at 23:55, Venkat wrote: > > > > 2. What happens when ACL config is modified while traffic is flowing? > Would the packets continue to hit the special-case "-1" session until the > session is timed out and re-claimed? If that's true, then packets would > continue to sneak through even when a user modifies the ACL from > Permit+Reflect to Deny. > > > Yep. You can look at the code, there is a debug CLI tweak to reclassify > sessions, but I am not sure anyone actually uses it. > > There is no “always right” answer to this ~20 year old question. > > ACL plugin is very explicitly not a “fancy firewall”. > > [VD]: One more question on this behavior. If packets continue to hit > the special-case "-1" session, would they ever hit the modified ACL? Or > does the reclassify sessions logic kick in periodically (every timeout > independent of traffic hit) and cleans up the special-case "-1" sessions so > that new sessions build up again based on the current state of ACLs rule? I > would assume, it's the latter case, otherwise, modified ACL would never hit > if traffic continues to flow. > > > Only with the idle timeout. > > ACL plugin is not intended to participate in a SWAT team, really. :-) > > —a > > > > On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko > wrote: > >> >> >> On 17 Sep 2020, at 19:29, Venkat wrote: >> >> >> Andrew, >> >> I have a few follow up questions on the stated behavior. >> >> 1. Does the behavior you outlined about hitting special-case "-1" entries >> apply to UDP traffic as well if the ACL rule is stateful? >> >> >> Yup. >> >> >> 2. What happens when ACL config is modified while traffic is flowing? >> Would the packets continue to hit the special-case "-1" session until the >> session is timed out and re-claimed? If that's true, then packets would >> continue to sneak through even when a user modifies the ACL from >> Permit+Reflect to Deny. >> >> >> Yep. You can look at the code, there is a debug CLI tweak to reclassify >> sessions, but I am not sure anyone actually uses it. >> >> There is no “always right” answer to this ~20 year old question. >> >> ACL plugin is very explicitly not a “fancy firewall”. >> >> >> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL >> hit would result in the creation of such a session and subsequent packets >> would by-pass ACL rules and continue to be served by special-case "-1". >> >> >> ...as your have observed it. The return packets on that interface >> matching the same five tuple, too. >> >> —a >> >> >> >> thanks >> Venkat >> >> >> On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko >> wrote: >> >>> Hi Venkat, >>> >>> Before doing ACL checks, acl-plugin checks the establshed sessions on >>> the given interface. >>> >>> If an already established session is hit the action is set to "3" and >>> no further ACL check is done, which is what you see in your output. >>> >>> For that case, the ACL# in the trace is a special-case "-1", same as >>> lc_index-1 - because we actually never get it to ACL lookup so do not >>> need it; and the rule# is the session index; and the trace_bits tells >>> us that this session is classifed to use timeout type "3", which is >>> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes >>> sense, since you are sending the packets in one direction and thus the >>> session never establishes and the timeout type never changes to >>> "TCP_IDLE". >>> >>> Of the packets you sent in total, 15002 packets had hit the ACL#3 >>> rule and caused the sessions to be created. The rest of the packets >>> had hit the established session entries and this is one of those that >>> you have captured. >>> >>> At the time of taking the outputs the traffic was stopped and the >>> sessions were deleted by idle timeout (which for the transient state >>> is short). >>> >>> Does this make sense ? >>> >>> --a >>> >>> >>> >>> >>> On 9/14/20, Venkat wrote: >>> > Hello Andrew, >>> > >>> > I am doing a simple test by sending TCP flows from Trex traffic >>> generator. >>> > Traffic source is
Re: [vpp-dev] Question about acl match/permit behavior.
I suggest making a unit test that captures this behavior and fails, then we can look at what is the best way of fixing it and incorporate into the CI... I remember this type of scenario being addressed once, not sure if it was the same one or not... But you could probably work around it by having the ACLs on the inner interface. --a > On 22 Sep 2020, at 18:58, Venkat wrote: > > > Thank you Andrew for the pointers and setting the expectations for VPP ACL. > > On another topic, since the stateful behavior of ACL is per interface, I > setup permit+reflect output ACL on WAN interface ( Internet-facing Public IP) > for internet bound traffic. And I also have to Deny all incoming traffic > (input ACL on WAN interface) for security purposes. In addition, I have SNAT > configured on the same interface so that packets get source NATed when going > to the internet. > > Now the problem is since the ACL node comes before the SNAT node in the > feature ARC, stateful ACL sessions are built for the original Source/Dest IP > pair prior to SNAT. > Return traffic coming into the WAN interface comes with WAN IP (public IP), > gets dropped because of Deny all input ACL and the purpose of stateful ACL is > lost. > How is this scenario typically addressed? > > thanks > Venkat > > > > On Thu, Sep 17, 2020 at 3:19 PM Andrew Yourtchenko > wrote: >> >> >>> On 17 Sep 2020, at 23:55, Venkat wrote: >>> >>> >>> 2. What happens when ACL config is modified while traffic is flowing? Would the packets continue to hit the special-case "-1" session until the session is timed out and re-claimed? If that's true, then packets would continue to sneak through even when a user modifies the ACL from Permit+Reflect to Deny. >>> >>> Yep. You can look at the code, there is a debug CLI tweak to reclassify >>> sessions, but I am not sure anyone actually uses it. >>> >>> There is no “always right” answer to this ~20 year old question. >>> >>> ACL plugin is very explicitly not a “fancy firewall”. >>> >>> [VD]: One more question on this behavior. If packets continue to hit the >>> special-case "-1" session, would they ever hit the modified ACL? Or does >>> the reclassify sessions logic kick in periodically (every timeout >>> independent of traffic hit) and cleans up the special-case "-1" sessions so >>> that new sessions build up again based on the current state of ACLs rule? I >>> would assume, it's the latter case, otherwise, modified ACL would never hit >>> if traffic continues to flow. >> >> Only with the idle timeout. >> >> ACL plugin is not intended to participate in a SWAT team, really. :-) >> >> —a >> >>> >>> >>> On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko >>> wrote: > On 17 Sep 2020, at 19:29, Venkat wrote: > > > Andrew, > > I have a few follow up questions on the stated behavior. > > 1. Does the behavior you outlined about hitting special-case "-1" entries > apply to UDP traffic as well if the ACL rule is stateful? Yup. > > 2. What happens when ACL config is modified while traffic is flowing? > Would the packets continue to hit the special-case "-1" session until the > session is timed out and re-claimed? If that's true, then packets would > continue to sneak through even when a user modifies the ACL from > Permit+Reflect to Deny. Yep. You can look at the code, there is a debug CLI tweak to reclassify sessions, but I am not sure anyone actually uses it. There is no “always right” answer to this ~20 year old question. ACL plugin is very explicitly not a “fancy firewall”. > > 3. And regarding the special-case "-1" lookups, I assume a stateful ACL > hit would result in the creation of such a session and subsequent packets > would by-pass ACL rules and continue to be served by special-case "-1". ...as your have observed it. The return packets on that interface matching the same five tuple, too. —a > > > thanks > Venkat > > > On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko > wrote: >> Hi Venkat, >> >> Before doing ACL checks, acl-plugin checks the establshed sessions on >> the given interface. >> >> If an already established session is hit the action is set to "3" and >> no further ACL check is done, which is what you see in your output. >> >> For that case, the ACL# in the trace is a special-case "-1", same as >> lc_index-1 - because we actually never get it to ACL lookup so do not >> need it; and the rule# is the session index; and the trace_bits tells >> us that this session is classifed to use timeout type "3", which is >> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes >> sense, since you are sending the packets in one
Re: [vpp-dev] Question about acl match/permit behavior.
Dear Matthew,
Thank you for the response.
Yes, we are using NAT44 ED mode and have an output-feature variant
configured on the wan interface.
wan-ens7 output-feature out
Will try to follow the suggestion you posted to re-order the NAT/ACL nodes
so that ACL gets applied post-SNAT of the original packet.
thanks again for the response
regards
Venkat
On Tue, Sep 22, 2020 at 11:48 AM Matthew Smith wrote:
>
> On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko
> wrote:
>
>> I suggest making a unit test that captures this behavior and fails, then
>> we can look at what is the best way of fixing it and incorporate into the
>> CI...
>>
>> I remember this type of scenario being addressed once, not sure if it was
>> the same one or not...
>>
>> But you could probably work around it by having the ACLs on the inner
>> interface.
>>
>> --a
>>
>>
> Hi Andrew,
>
> In general, for NAT and stateful ACL to coexist, the NAT and ACL nodes
> must be ordered in the opposite order for in2out vs out2in packets. E.g. if
> you the NAT ran first followed by a stateful output ACL for outbound
> packets, then inbound packets must use the reverse ordering - input ACL
> followed by NAT. I ran into the same problem Venkat is having a while back
> due to the order of the NAT & ACL features nodes being the same in both
> directions. I did fix it and added a unit test, but I think I only fixed it
> for endpoint dependent mode. The endpoint independent in2out nodes look
> like some of them are running after the ACL plugin output node:
>
> VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
> VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output-worker-handoff",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
> VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-hairpin-src",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
>
> I'm not positive about the "hairpin" node, but I think it ought to work if
> the code above is changed to look like this:
>
> VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
> VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output-worker-handoff",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
> VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-hairpin-src",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
>
> Venkat, are you using any of the nodes listed above (i.e. are you using
> the output-feature variant of the in2out node in endpoint independent
> mode)? If so, I suggest applying the change I described and building from
> that code and test whether it solves your problem.
>
> -Matt
>
>
>
>
>> On 22 Sep 2020, at 18:58, Venkat wrote:
>>
>>
>> Thank you Andrew for the pointers and setting the expectations for VPP
>> ACL.
>>
>> On another topic, since the stateful behavior of ACL is per interface, I
>> setup permit+reflect output ACL on WAN interface ( Internet-facing Public
>> IP) for internet bound traffic. And I also have to Deny all incoming
>> traffic (input ACL on WAN interface) for security purposes. In addition, I
>> have SNAT configured on the same interface so that packets get source NATed
>> when going to the internet.
>>
>> Now the problem is since the ACL node comes before the SNAT node in the
>> feature ARC, stateful ACL sessions are built for the original Source/Dest
>> IP pair prior to SNAT.
>> Return traffic coming into the WAN interface comes with WAN IP (public
>> IP), gets dropped because of Deny all input ACL and the purpose of stateful
>> ACL is lost.
>> How is this scenario typically addressed?
>>
>> thanks
>> Venkat
>>
>>
>>
>> On Thu, Sep 17, 2020 at 3:19 PM Andrew Yourtchenko
>> wrote:
>>
>>>
>>>
>>> On 17 Sep 2020, at 23:55, Venkat wrote:
>>>
>>>
>>>
>>> 2. What happens when ACL config is modified while traffic is flowing?
>>> Would the packets continue to hit the special-case "-1" session until the
>>> session is timed out and re-claimed? If that's true, then packets would
>>> continue to sneak through even when a user modifies the ACL from
>>> Permit+Reflect to Deny.
>>>
>>>
>>> Yep. You can look at the code, there is a debug CLI tweak to
Re: [vpp-dev] How to include my custom plugin in the rpm packages.
Hi, Has anyone figured this out?? I'm using 'make pkg-deb' and I'm similar results as above. 'make run' and 'make debug' show my plugin, but it is not included in the packages using 'make pkg-deb' Thanks Mauricio -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17479): https://lists.fd.io/g/vpp-dev/message/17479 Mute This Topic: https://lists.fd.io/mt/71944155/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] How to include my custom plugin in the rpm packages.
Hi Himanshu, When I created a plugin, I started by running extras/emacs/make-plugin.sh. That script automatically set things up so the plugin could be built and installed with the other VPP plugins. Then I started adding actual code to the stubbed-out files which the script created. I tested that script again just now and the stub plugin that is created by that script seems to have been built successfully and it was included in the vpp-plugins RPM that was built when I ran 'make pkg-rpm'. I did the following while in a directory containing a VPP repo which was freshly cloned from gerrit: sudo dnf install emacs cd src/plugins ../../extras/emacs/make-plugin.sh I was asked for a name of the plugin and whether it was dual loop, I typed 'foobar' for the name and chose dual loop. The script ran for a second and there were files under src/plugins/foobar when it completed. git add foobar git commit cd ../.. make pkg-rpm After waiting a while for the build to complete: $ rpm -qlp build-root/vpp-plugins-21.01-rc0~84_gf79b34036.x86_64.rpm | grep foobar /usr/lib/vpp_api_test_plugins/foobar_test_plugin.so /usr/lib/vpp_plugins/foobar_plugin.so /usr/share/vpp/api/foobar.api.json It should be noted that this didn't work on my first attempt because I did not commit the files under src/plugins/foobar. The pkg-rpm target builds a tar archive of source files using 'git archive'. If you had files for the plugin which are on your local filesystem and the files have not been committed in the local repo, they won't be built. Even if you don't feel like using that script, you shouldn't need to do anything special. The RPM spec file at extras/rpm/vpp.spec has this: %files plugins %defattr(-,bin,bin) /usr/lib/vpp_plugins/* /usr/lib/vpp_api_test_plugins/* /usr/share/vpp/api/* If your plugin files are being installed under /usr/lib/vpp_plugins, /usr/lib/vpp_api_test_plugins, and /usr/share/vpp/api, the above ought to cause it to be included in vpp-plugins automatically. In src/plugins/, is there a CMakeLists.txt with an add_vpp_plugin() in it? -Matt On Fri, Mar 13, 2020 at 11:42 PM Himanshu Rakshit wrote: > Hi All, > > We have developed a custom plugin (under the folder *src/plugin*). We are > able to compile it successfully and also able to run in the local setup > using *make run* or *make debug* command. > > Our intention is not run in a different system(different for the build > system). So we make the rpm package using the *make pkg-rpm *command and > install the rpms in the remote system. But the custom plugin is not a part > of the rpm packages and not installed in the system. > > Need your help on this. > > What is best possible way to install the custom plugin in a remote > system(different form the build system.) > > I followed the following steps > > *make install-dep* > *make build* > *make pkg-rpm* > > *rpm -ivh * > > Thanks, > Himanshu > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17485): https://lists.fd.io/g/vpp-dev/message/17485 Mute This Topic: https://lists.fd.io/mt/71944155/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vpp committers: project PTL self-nominations close Thurs 9/22/2020 at 2100 UTC
Thanks... Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17487): https://lists.fd.io/g/vpp-dev/message/17487 Mute This Topic: https://lists.fd.io/mt/77025295/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Happy Trails to Me...
Thanks... Much appreciated... Dave -Original Message- From: St Leger, Jim Sent: Thursday, September 17, 2020 12:13 PM To: d...@barachs.net; vpp-dev@lists.fd.io; t...@lists.fd.io Subject: RE: [vpp-dev] Happy Trails to Me... Dave: Wow...I'm starting to wonder what the community would do without you, but grateful to hear you'll remain active. You have been "the" foundation of FD.io wrt VPP since the inception (and of course for many more years when VPP was solely software within Cisco.) Your leadership and contributions have been invaluable. We are all tremendously indebted and grateful for all that you've done. And we will continue to be appreciative for all you will continue to do. All the very best, Jim -Original Message- From: vpp-dev@lists.fd.io On Behalf Of d...@barachs.net Sent: Thursday, September 17, 2020 7:32 AM To: vpp-dev@lists.fd.io; t...@lists.fd.io Subject: [vpp-dev] Happy Trails to Me... Folks, I'm departing the employment rolls towards the end of next month. Although I intend to remain active in the fd.io vpp community as a coder, committer, and resident greybeard, it's time for the community to pick a new PTL. According to the project governance document, https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf: 3.2.3.1 Project Technical Leader Candidates Candidates for the project's PTL will be derived from the Committers of the Project. Candidates must self-nominate. I'd like to invite any interested vpp project committer to self-nominate for the PTL role. Please email vpp-dev@lists.fd.io. Let's close the self-nomination period in one week: more specifically, by 5pm EDT on Thursday, September 24, 2020; committer vote to follow thereafter. I'll be glad to answer unicast questions about the PTL role from eligible committers. Thanks... Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17486): https://lists.fd.io/g/vpp-dev/message/17486 Mute This Topic: https://lists.fd.io/mt/76911198/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Qeustion about qos mark
Hi guys, I am testing the Qos mark feature recently, my useage is like this: When I use vpp to send a udp packet by a vlan sub-interface, I want to mark dscp and vlan pri at the same time. So I create a qos egress map like this and qos mark the output interface. qos egress map id 0 [ip][0]=30 qos egress map id 0 [vlan][0]=5 qos egress map id 0 [ip][1]=32 qos egress map id 0 [vlan][1]=6 qos mark vlan GigabitEthernet6/0/2.30 id 0 I tried to mark the packet like this (993-995) I add some log and capture the output packet, I can only see IP dscp is marked as expected and Vlan pri is not . I checked the qos_mark_inline function, and it only use the input_source to get the qos bits, so it will always get qos value for IP dscp, as I can only mark the qos.source as IP or VLAN, can not mark it as both of them. So should I use output_source to get qos0 ? I tried to modified the code with output_source, and it works as expected. Regards Jinlei -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17488): https://lists.fd.io/g/vpp-dev/message/17488 Mute This Topic: https://lists.fd.io/mt/77025751/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
