[vpp-dev] Documentation to install networking VPP plugin on openstack

[suresh vuppala]

HI ALL,

Can someone help and point me to the documentation to install networking VPP 
plugin on openstack.

thanks,
Suresh

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21947): https://lists.fd.io/g/vpp-dev/message/21947
Mute This Topic: https://lists.fd.io/mt/93986291/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Stats (rx/tx bytes) per MAC address

[Andre Courchesne]

Great. Thanks for taking the time to reply.

Andre Courchesne


On Wed, Sep 28, 2022 at 7:04 PM Neale Ranns  wrote:

> Hi Andre,
>
>
>
> The adjacency counters are for TX. There’s no way currently to get RX
> stats per MAC.
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Andre
> Courchesne via lists.fd.io 
> *Date: *Thursday, 29 September 2022 at 04:00
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] Stats (rx/tx bytes) per MAC address
>
> Thanks Neale.
>
>
>
> This seems to provide only total packet/bytes and does not split between
> RX and TX. Know any way to get the discrete RX and TX counters ?
>
> Andre Courchesne - Consultant
> http://net-forces.blogspot.ca
> 
> https://www.co2.click
> 
> Twitter: @IndianaTux
> LinkedIn: http://www.linkedin.com/pub/andr%C3%A9-courchesne/0/b0b/688
> 
>
> L'information contenue dans le présent document est la propriété de Andre
> Courchesne. Et est divulguée en toute confidentialité. Cette information ne
> doit pas être utilisée, divulguée à d'autres personnes ou reproduite sans
> le consentement écrit explicite de Andre Courchesne.
>
> The information contained in this document is confidential and property of
> Andre Courchesne. It shall not be used, disclosed to others or reproduced
> without the express written consent of Andre Courchesne.
>
>
>
>
>
> On Tue, Sep 27, 2022 at 8:43 PM Neale Ranns  wrote:
>
>
>
> Hi Andre,
>
>
>
> For L3 forwarding you can use the per-adjacency counters. This are not
> enabled by default, because, like all stats, they come with a performance
> cost.
>
> DBGvpp# adjacency counters ?
>
>   adjacency counters   adjacency counters
> [enable|disable]
>
>
>
> you’ll then find then in the ‘sh adj’ output and also in the stats segment
> at ‘/net/adjacency’’.
>
>
>
> /neeale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Andre
> Courchesne via lists.fd.io
> 
> 
> *Date: *Wednesday, 28 September 2022 at 05:47
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] Stats (rx/tx bytes) per MAC address
>
> Hi,
>
>
>
> Is there a way to retrieve the number of bytes per MAC address
> transferred through VPP ?
>
>
>
> Thanks.
>
> Andre
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21946): https://lists.fd.io/g/vpp-dev/message/21946
Mute This Topic: https://lists.fd.io/mt/93958112/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Stats (rx/tx bytes) per MAC address

[Neale Ranns]

Hi Andre,

The adjacency counters are for TX. There’s no way currently to get RX stats per 
MAC.

/neale

From: vpp-dev@lists.fd.io  on behalf of Andre Courchesne 
via lists.fd.io 
Date: Thursday, 29 September 2022 at 04:00
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Stats (rx/tx bytes) per MAC address
Thanks Neale.

This seems to provide only total packet/bytes and does not split between RX and 
TX. Know any way to get the discrete RX and TX counters ?

Andre Courchesne - Consultant
http://net-forces.blogspot.ca
https://www.co2.click
Twitter: @IndianaTux
LinkedIn: 
http://www.linkedin.com/pub/andr%C3%A9-courchesne/0/b0b/688

L'information contenue dans le présent document est la propriété de Andre 
Courchesne. Et est divulguée en toute confidentialité. Cette information ne 
doit pas être utilisée, divulguée à d'autres personnes ou reproduite sans le 
consentement écrit explicite de Andre Courchesne.

The information contained in this document is confidential and property of 
Andre Courchesne. It shall not be used, disclosed to others or reproduced 
without the express written consent of Andre Courchesne.


On Tue, Sep 27, 2022 at 8:43 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Andre,

For L3 forwarding you can use the per-adjacency counters. This are not enabled 
by default, because, like all stats, they come with a performance cost.

DBGvpp# adjacency counters ?

  adjacency counters   adjacency counters [enable|disable]

you’ll then find then in the ‘sh adj’ output and also in the stats segment at 
‘/net/adjacency’’.

/neeale

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Andre Courchesne 
via 
lists.fd.io
 mailto:net-forces@lists.fd.io>>
Date: Wednesday, 28 September 2022 at 05:47
To: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Stats (rx/tx bytes) per MAC address
Hi,

Is there a way to retrieve the number of bytes per MAC address transferred 
through VPP ?

Thanks.

Andre



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21945): https://lists.fd.io/g/vpp-dev/message/21945
Mute This Topic: https://lists.fd.io/mt/93958112/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Stats (rx/tx bytes) per MAC address

[Andre Courchesne]

Thanks Neale.

This seems to provide only total packet/bytes and does not split between RX
and TX. Know any way to get the discrete RX and TX counters ?

Andre Courchesne - Consultant
http://net-forces.blogspot.ca 
https://www.co2.click
Twitter: @IndianaTux
LinkedIn: http://www.linkedin.com/pub/andr%C3%A9-courchesne/0/b0b/688

L'information contenue dans le présent document est la propriété de Andre
Courchesne. Et est divulguée en toute confidentialité. Cette information ne
doit pas être utilisée, divulguée à d'autres personnes ou reproduite sans
le consentement écrit explicite de Andre Courchesne.

The information contained in this document is confidential and property of
Andre Courchesne. It shall not be used, disclosed to others or reproduced
without the express written consent of Andre Courchesne.


On Tue, Sep 27, 2022 at 8:43 PM Neale Ranns  wrote:

>
>
> Hi Andre,
>
>
>
> For L3 forwarding you can use the per-adjacency counters. This are not
> enabled by default, because, like all stats, they come with a performance
> cost.
>
> DBGvpp# adjacency counters ?
>
>   adjacency counters   adjacency counters
> [enable|disable]
>
>
>
> you’ll then find then in the ‘sh adj’ output and also in the stats segment
> at ‘/net/adjacency’’.
>
>
>
> /neeale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Andre
> Courchesne via lists.fd.io 
> *Date: *Wednesday, 28 September 2022 at 05:47
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] Stats (rx/tx bytes) per MAC address
>
> Hi,
>
>
>
> Is there a way to retrieve the number of bytes per MAC address
> transferred through VPP ?
>
>
>
> Thanks.
>
> Andre
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21944): https://lists.fd.io/g/vpp-dev/message/21944
Mute This Topic: https://lists.fd.io/mt/93958112/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] nat44-ed distinct pool for out if

[Amir Hossein]

Oh you're right.
thanks to your guidance i was able to reach correct configuration.
thanks a lot!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21943): https://lists.fd.io/g/vpp-dev/message/21943
Mute This Topic: https://lists.fd.io/mt/93820447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] MAC address only based ACL

[Andre Courchesne]

Hi,

I have read many documentation but did not find my answers, so here is the
question.

Is there a way in VPP to redirect all TCP traffic to a host Linux process
unless the traffic comes from a MAC address that is part of some sort of
ACL.

We used to do this without VPP using iptables and ipset, but now that all
the traffic is handled by VPP how can we do this ?

Thanks for any hints

Andre

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21942): https://lists.fd.io/g/vpp-dev/message/21942
Mute This Topic: https://lists.fd.io/mt/93972096/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in patch

[Guangming]

I have some idea that is not good 
1,   spi should be one key in inbound  policy serach   
typedef union
{
  struct
  {
ip4_address_t ip4_src_addr;
ip4_address_t ip4_dest_addr;
U32  spi;
ipsec_spd_policy_type_t policy_type;
  }; // 16 bytes total
  ipsec4_hash_kv_16_8_t kv_16_8;
} ipsec4_inbound_spd_tuple_t;

2, Maybe we  do not need a  write a unified method to be fit to  both  inbound 
and outbound. 
3,  We should use another  method (Eg: remove on entry) , not reset cache 
entry, when add or del one spd.  
 In roadwarrior scenario , for server , many client attach and  detach is 
usaual beviour.  

Thanks 
 Guangming


zhangguangm...@baicells.com
 
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2022-09-28 16:22
To: vpp-dev@lists.fd.io
CC: Zhang, Roy Fan; Bronowski, PiotrX; Lijian Zhang; Honnappa Nagarahalli
Subject: Re: [vpp-dev] There is bug in patch
Looks like it would be a good time to unify slow-path/fastpath and 
inbound/outbound policy matching code 
 
Best
ben
 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Zachary Leaf
> Sent: Wednesday, September 28, 2022 10:10
> To: vpp-dev@lists.fd.io
> Cc: Zhang, Roy Fan ; Bronowski, PiotrX
> ; Lijian Zhang ;
> Honnappa Nagarahalli 
> Subject: Re: [vpp-dev] There is bug in patch
> 
> Copying in Piotr, Fan and some other folks for awareness/any input.
> 
> Best,
> Zach
> 
> On 28/09/2022 09:07, Zachary Leaf via lists.fd.io wrote:
> > Hi Guangming,
> >
> > Thanks for the report. I think you may have uncovered some of the bugs
> > in the general inbound matching logic.
> >
> > I think there are 2 problems with the logic for the standard linear
> > search (not flow cache, but impacts flow cache):
> > 1. Only matches source/dest ip, and doesn't match source/dest ports
> > or protocol
> > 2. First looks for a match in a vector of all PROTECT policies, then in
> > BYPASS, then finally in DISCARD if nothing matched above
> >
> > In contrast the way I think the matching logic should work is matching a
> > full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
> > policies searched in one vector so priorities are respected [1].
> >
> > From what you've said I think what may cause your issue is a
> > combination of the 2 above problems, flow cache activation and the
> > particular policy you included:
> >
> > - First packet enters, does not match any PROTECT rules, so searches and
> > matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
> > (inbound logic does not check port ranges or protocol)
> > - Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
> > match every packet in future
> >
> > Obviously the inbound logic is pretty broken, I think it really needs a
> > full re-write to align with outbound side. In hindsight it would have
> > been better to fix all this before adding flow cache but these issues
> > weren't really clear before.
> >
> > As far as fixing your problem, disabling flow cache would work to match
> > the PROTECT policy because of the ordering of the linear search (see 2
> > above), but doesn't fix any of the other possible issues.
> >
> > Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
> > and match everything in flow cache if the first packet that enters
> > matches one of these rules.
> >
> > You can try using the new fast path functionality, but from a quick look
> > this also might only be matching sip/dip and not a full 5-tuple so
> > possibly will have the same issue.
> >
> > Best,
> >
> > Zach
> >
> > 1: https://gerrit.fd.io/r/c/vpp/+/34252/3#message-
> 958bacb4654a030e835502af5e486f614c5a1433
> >
> >
> >
> >
> >
 
 
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21941): https://lists.fd.io/g/vpp-dev/message/21941
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in patch

[Benoit Ganne (bganne) via lists.fd.io]

Looks like it would be a good time to unify slow-path/fastpath and 
inbound/outbound policy matching code 😊

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Zachary Leaf
> Sent: Wednesday, September 28, 2022 10:10
> To: vpp-dev@lists.fd.io
> Cc: Zhang, Roy Fan ; Bronowski, PiotrX
> ; Lijian Zhang ;
> Honnappa Nagarahalli 
> Subject: Re: [vpp-dev] There is bug in patch
> 
> Copying in Piotr, Fan and some other folks for awareness/any input.
> 
> Best,
> Zach
> 
> On 28/09/2022 09:07, Zachary Leaf via lists.fd.io wrote:
> > Hi Guangming,
> >
> > Thanks for the report. I think you may have uncovered some of the bugs
> > in the general inbound matching logic.
> >
> > I think there are 2 problems with the logic for the standard linear
> > search (not flow cache, but impacts flow cache):
> > 1. Only matches source/dest ip, and doesn't match source/dest ports
> > or protocol
> > 2. First looks for a match in a vector of all PROTECT policies, then in
> > BYPASS, then finally in DISCARD if nothing matched above
> >
> > In contrast the way I think the matching logic should work is matching a
> > full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
> > policies searched in one vector so priorities are respected [1].
> >
> > From what you've said I think what may cause your issue is a
> > combination of the 2 above problems, flow cache activation and the
> > particular policy you included:
> >
> > - First packet enters, does not match any PROTECT rules, so searches and
> > matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
> > (inbound logic does not check port ranges or protocol)
> > - Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
> > match every packet in future
> >
> > Obviously the inbound logic is pretty broken, I think it really needs a
> > full re-write to align with outbound side. In hindsight it would have
> > been better to fix all this before adding flow cache but these issues
> > weren't really clear before.
> >
> > As far as fixing your problem, disabling flow cache would work to match
> > the PROTECT policy because of the ordering of the linear search (see 2
> > above), but doesn't fix any of the other possible issues.
> >
> > Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
> > and match everything in flow cache if the first packet that enters
> > matches one of these rules.
> >
> > You can try using the new fast path functionality, but from a quick look
> > this also might only be matching sip/dip and not a full 5-tuple so
> > possibly will have the same issue.
> >
> > Best,
> >
> > Zach
> >
> > 1: https://gerrit.fd.io/r/c/vpp/+/34252/3#message-
> 958bacb4654a030e835502af5e486f614c5a1433
> >
> >
> >
> >
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21940): https://lists.fd.io/g/vpp-dev/message/21940
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in patch

[Zachary Leaf]

Copying in Piotr, Fan and some other folks for awareness/any input.

Best,
Zach

On 28/09/2022 09:07, Zachary Leaf via lists.fd.io wrote:
> Hi Guangming,
> 
> Thanks for the report. I think you may have uncovered some of the bugs
> in the general inbound matching logic.
> 
> I think there are 2 problems with the logic for the standard linear
> search (not flow cache, but impacts flow cache):
> 1. Only matches source/dest ip, and doesn't match source/dest ports
> or protocol
> 2. First looks for a match in a vector of all PROTECT policies, then in
> BYPASS, then finally in DISCARD if nothing matched above
> 
> In contrast the way I think the matching logic should work is matching a
> full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
> policies searched in one vector so priorities are respected [1].
> 
> From what you've said I think what may cause your issue is a
> combination of the 2 above problems, flow cache activation and the
> particular policy you included:
> 
> - First packet enters, does not match any PROTECT rules, so searches and
> matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
> (inbound logic does not check port ranges or protocol)
> - Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
> match every packet in future
> 
> Obviously the inbound logic is pretty broken, I think it really needs a
> full re-write to align with outbound side. In hindsight it would have
> been better to fix all this before adding flow cache but these issues
> weren't really clear before.
> 
> As far as fixing your problem, disabling flow cache would work to match
> the PROTECT policy because of the ordering of the linear search (see 2
> above), but doesn't fix any of the other possible issues.
> 
> Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
> and match everything in flow cache if the first packet that enters
> matches one of these rules.
> 
> You can try using the new fast path functionality, but from a quick look
> this also might only be matching sip/dip and not a full 5-tuple so
> possibly will have the same issue.
> 
> Best,
> 
> Zach
> 
> 1: 
> https://gerrit.fd.io/r/c/vpp/+/34252/3#message-958bacb4654a030e835502af5e486f614c5a1433
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21939): https://lists.fd.io/g/vpp-dev/message/21939
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in patch

[Zachary Leaf]

Hi Guangming,

Thanks for the report. I think you may have uncovered some of the bugs
in the general inbound matching logic.

I think there are 2 problems with the logic for the standard linear
search (not flow cache, but impacts flow cache):
1. Only matches source/dest ip, and doesn't match source/dest ports
or protocol
2. First looks for a match in a vector of all PROTECT policies, then in
BYPASS, then finally in DISCARD if nothing matched above

In contrast the way I think the matching logic should work is matching a
full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
policies searched in one vector so priorities are respected [1].

>From what you've said I think what may cause your issue is a
combination of the 2 above problems, flow cache activation and the
particular policy you included:

- First packet enters, does not match any PROTECT rules, so searches and
matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
(inbound logic does not check port ranges or protocol)
- Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
match every packet in future

Obviously the inbound logic is pretty broken, I think it really needs a
full re-write to align with outbound side. In hindsight it would have
been better to fix all this before adding flow cache but these issues
weren't really clear before.

As far as fixing your problem, disabling flow cache would work to match
the PROTECT policy because of the ordering of the linear search (see 2
above), but doesn't fix any of the other possible issues.

Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
and match everything in flow cache if the first packet that enters
matches one of these rules.

You can try using the new fast path functionality, but from a quick look
this also might only be matching sip/dip and not a full 5-tuple so
possibly will have the same issue.

Best,

Zach

1: 
https://gerrit.fd.io/r/c/vpp/+/34252/3#message-958bacb4654a030e835502af5e486f614c5a1433

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21938): https://lists.fd.io/g/vpp-dev/message/21938
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-