[ovs-discuss] DP_Packet Payload Modification

[Luca Mancini]

Hello,
This is sort of a repost from my previous question about creating a custom udp 
payload.
I figured I could just clone a received udp payload and modify its payload, do 
you think this is possible?  I tried creating a packet from 0 but I just 
couldn’t manage to do it.

I’m guessing I could do something along the lines of dp_packet_clone(), 
dp_packet_l4() to get the pointer to the UDP header and then overwrite it with 
memcpy?
Any help is really appreciated, Thanks!

Luca Mancini

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] check_pkt_larger precision

[Miroslav Kubiczek]

On 03. 06. 20 20:09, Numan Siddique wrote:
This email was sent from an external sender. Do not click links or 
open attachments unless you recognize the sender and know the content 
is safe.




On Wed, Jun 3, 2020 at 8:27 PM Miroslav Kubiczek 
> wrote:



On 29. 05. 20 12:51, Numan Siddique wrote:

This email was sent from an external sender. Do not click links
or open attachments unless you recognize the sender and know the
content is safe.



On Fri, May 29, 2020 at 3:41 PM Miroslav Kubiczek
mailto:miroslav.kubic...@adaptivemobile.com>> wrote:


On 29. 05. 20 11:29, Numan Siddique wrote:

On Fri, May 29, 2020 at 2:25 PM Miroslav Kubiczek
mailto:miroslav.kubic...@adaptivemobile.com>> wrote:

Hi, I have finally implemented flows with
check_pkt_larger action. Partial flow dump is
here:table=0, priority=100
actions=check_pkt_larger(60)->NXM_NX_REG0[0],resubmit(,1)
table=1, priority=1000,reg0=0x1 actions=resubmit(,2)
table=1, priority=100,reg0=0 actions=resubmit(,3) I run
a test which sends UDP packets (with VLAN) with size:
58, 59, 62, 63 and 69 in a loop. Only the packet with 69
match the action (1st line in table=1). In 2nd test I
set check_pkt_larger  just by one byte less to 59 and then all the 
above packets match. So the precision seems to be rounded to 8 bytes or 
something like that.
Can this be fixed to be more precise ideally to exact 1 byte?


Can you try without VLAN and see the accuracy ?


I tried without VLAN, it's not accurate.


This is how the pkt length comparison is done

in vswitchd -

https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-xlate.c#L6265
in kernel datapath -

https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/heads/master/net/openvswitch/actions.c#1183


I can see the problem only when using DPDK. Does it use the same code?

For flow translation the same code is hit.
I think for ovs-dpdk datapath flows, the code here [1] should get hit.

[1] - 
https://github.com/openvswitch/ovs/blob/master/lib/odp-execute.c#L766


I never tested with ovs-dpdk when I worked on it.



Thanks Numan, I added logging and I can see in that 
dp_packet_size(packet) is always greater or equal 60 even if the real 
packet size is 59 or less.





Thanks
Numan

When tested with non DPDK then it's working fine. Both versions are:
$ ovs-ofctl --version
ovs-ofctl (Open vSwitch) 2.13.0
OpenFlow versions 0x1:0x6

Thanks,
Miro



Thanks
Numan



man ovs-actions for check_pkt_larger says


Syntax:
       check_pkt_larger(pkt_len)->dst

       Checks if the packet is larger than the specified
length in pkt_len. If so, stores 1 in dst, which should be a
1-bit field; if not, stores 0.

       The packet length to check againt the argument
pkt_len includes the L2 header and L2 payload of the packet,
but not the VLAN tag (if present).

       Examples:
              ·  check_pkt_larger(1500)->reg0[0]
              ·  check_pkt_larger(8000)->reg9[10]

**

Thanks
Numan

Thanks,
Miro




___
discuss mailing list
disc...@openvswitch.org 
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org 
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Vlan transparency in OVN

[Daniel Alvarez Sanchez]

Hi Slawek

On Thu, Jun 4, 2020 at 9:53 AM Slawek Kaplonski  wrote:

> Hi,
>
> On Tue, Jun 02, 2020 at 05:37:37PM -0700, Ben Pfaff wrote:
> > On Tue, Jun 02, 2020 at 01:25:05PM +0200, Slawek Kaplonski wrote:
> > > Hi,
> > >
> > > I work in OpenStack Neutron mostly. We have there extension called
> > > "vlan_transparent". See [1] for details.
> > > Basically it allows to send traffic with vlan tags directly to the VMs.
> > >
> > > Recently I was testing if that extension will work with OVN backend
> used in
> > > Neutron. And it seems that we have work to do to make it working.
> > > From my test I found out that for each port I had rule like:
> > >
> > > cookie=0x0, duration=17.580s, table=8, n_packets=6, n_bytes=444,
> idle_age=2, priority=100,metadata=0x2,vlan_tci=0x1000/0x1000 actions=drop
> > >
> > > which was dropping those tagged packets. After removal of this rule
> traffic was
> > > fine.
> > > So we need to have some way to tell northd that it shouldn't match on
> vlan_tci
> > > at all in case when neutron network has got vlan_transparency set to
> True.
> > >
> > > From the discussion with Daniel Alvarez he told me that somehow we can
> try to
> > > leverage such columns to request transparency (for example:
> parent_name=none
> > > and tag_request=0). With this, northd can enforce transparency per
> port.
> > >
> > > Another option could be to create an option in the “other_config”
> column in the
> > > logical switch to have the setting per Neutron network
> > > (other_config:vlan_transparent) While this seems more natural, it may
> break the
> > > trunk/subport current feature.
> > >
> > > What do You, as ovn developers thinks about that?
> > > Is that maybe possible somehow to do currently in northd? Or is one of
> the
> > > options given above doable and acceptable for You?
> >
> > This might be a place to consider using QinQ (at least, until Neutron
> > introduces QinQ transparency).
>
> I'm not sure if I understand. For now Neutron don't supports QinQ - old
> RFE is
> postponed currently [1].
> And my original use case is related to the Neutron tenant networks which is
> Geneve type. How QinQ can help with that?
>

I think that Ben's suggestion could possibly allow you to achieve your goal
while at the same time having QinQ in OVN:?

On one hand, not matching on CFI bit (vlan_tci=0x1000/0x1000) based on some
configuration of the Logical Switch, would achieve the VLAN transparency by
allowing traffic tagged on a logical switch port that is originally
untagged.

While this is probably enough for your use case, it'll break the
trunk/subport use case where we expect the traffic to be tagged. In this
case we'll need to pop one VLAN tag (the one to achieve VLAN transparency)
and match on the second tag to determine the logical port (subport). This
could be solved in the general case by QinQ but looks more complex I
believe.

Thoughts?

>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1705719
>
> --
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Vlan transparency in OVN

[Slawek Kaplonski]

Hi,

On Tue, Jun 02, 2020 at 05:37:37PM -0700, Ben Pfaff wrote:
> On Tue, Jun 02, 2020 at 01:25:05PM +0200, Slawek Kaplonski wrote:
> > Hi,
> > 
> > I work in OpenStack Neutron mostly. We have there extension called
> > "vlan_transparent". See [1] for details.
> > Basically it allows to send traffic with vlan tags directly to the VMs.
> > 
> > Recently I was testing if that extension will work with OVN backend used in
> > Neutron. And it seems that we have work to do to make it working.
> > From my test I found out that for each port I had rule like:
> > 
> > cookie=0x0, duration=17.580s, table=8, n_packets=6, n_bytes=444, 
> > idle_age=2, priority=100,metadata=0x2,vlan_tci=0x1000/0x1000 actions=drop
> > 
> > which was dropping those tagged packets. After removal of this rule traffic 
> > was
> > fine.
> > So we need to have some way to tell northd that it shouldn't match on 
> > vlan_tci
> > at all in case when neutron network has got vlan_transparency set to True.
> > 
> > From the discussion with Daniel Alvarez he told me that somehow we can try 
> > to
> > leverage such columns to request transparency (for example: parent_name=none
> > and tag_request=0). With this, northd can enforce transparency per port.
> > 
> > Another option could be to create an option in the “other_config” column in 
> > the
> > logical switch to have the setting per Neutron network
> > (other_config:vlan_transparent) While this seems more natural, it may break 
> > the
> > trunk/subport current feature.
> > 
> > What do You, as ovn developers thinks about that?
> > Is that maybe possible somehow to do currently in northd? Or is one of the
> > options given above doable and acceptable for You?
> 
> This might be a place to consider using QinQ (at least, until Neutron
> introduces QinQ transparency).

I'm not sure if I understand. For now Neutron don't supports QinQ - old RFE is
postponed currently [1].
And my original use case is related to the Neutron tenant networks which is
Geneve type. How QinQ can help with that?

> 

[1] https://bugs.launchpad.net/neutron/+bug/1705719

-- 
Slawek Kaplonski
Senior software engineer
Red Hat

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss