Re: [ovs-discuss] OVS version for Linux 5.5 kernel version

[Tonghao Zhang]

On Wed, Jun 10, 2020 at 12:36 AM Sravan A Dinesh 
wrote:

> Hi OVS team
>   Can you please suggest the OVS version which is
> compatible with Linux 5.5 kernel version or is there any patch available
> for the same. Also when are you planning to release OVS version 2.14.
> Please let me know.
>
I guess ovs has supported kernel 5.5.Please see:
"What Linux kernel versions does each Open vSwitch release work with?"
http://docs.openvswitch.org/en/latest/faq/releases/
and
http://docs.openvswitch.org/en/latest/internals/release-process/

Maintainers may provide more information.

*With Best Regards*
> Sravan A Dinesh
> VVDN Technologies Pvt Ltd
> Cell: +91 8547955398
> Web: www.vvdntech.com
>
>
> *Disclaimer: **© 2020 VVDN Technologies Pvt. Ltd. This e-mail contains
> PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the
> addressee(s). If you are not the intended recipient, please notify the
> sender by e-mail and delete the original message. Further, you are not to
> copy, disclose, or distribute this e-mail or its contents to any other
> person and any such actions are unlawful.*
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>


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

Re: [ovs-discuss] OVN DNS support questions

[John Lang]

Thanks Numan, that makes more sense.  I got the impression no special routing 
was needed.

 

John Lang

w (303) 272-5457

c (970) 231-3724

 

From: Numan Siddique  
Sent: Tuesday, June 9, 2020 12:25 PM
To: John Lang 
Cc: ovs-discuss 
Subject: Re: [ovs-discuss] OVN DNS support questions

 

 

 

On Tue, Jun 9, 2020 at 11:49 PM John Lang mailto:john.x.l...@oracle.com"john.x.l...@oracle.com> wrote:

Numan,

 

Earlier I had send an e-mail with the following question that you responded to. 
 I maybe should have asked if the pipeline would redirect the DNS request to 
another DNS server to OVN.

 

1.   If OVN can’t answer a DNS request, does the pipeline forward it on the 
another DNS server?  How is that server address set?  Though the DHCP options?

 

Yes. If OVN can't anwer it resumes the packet pipeline. So if there are any 
other DNS servers, they should get the packet.

I was looking at the flows in my OVN setup configured for DNS, and I don’t see 
how the DNS request is redirected to a server external to OVN.

 

  table=16(ls_in_dns_lookup   ), priority=100  , match=(udp.dst == 53), 
action=(reg0[4] = dns_lookup(); next;)

  table=16(ls_in_dns_lookup   ), priority=0    , match=(1), action=(next;)

  table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 && 
reg0[4]), action=(eth.dst <-> eth.src; ip6.src <-> ip6.dst; udp.dst = udp.src; 
udp.src = 53; outport = inport; flags.loopback = 1; output;)

  table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 && 
reg0[4]), action=(eth.dst <-> eth.src; ip4.src <-> ip4.dst; udp.dst = udp.src; 
udp.src = 53; outport = inport; flags.loopback = 1; output;)

  table=17(ls_in_dns_response ), priority=0    , match=(1), action=(next;)

 

Based on these flows it looks like all udp.dst requests on port 53 are sent to 
dns_lookup.  If dns_lookup resolves the request it send the reply (either IPV4 
or IPV6).  If not, it proceeds to table 18, and I think eventually the request 
gets dropped.  Is there some later flow I should be looking for that would 
redirect the request to another DNS server (or is there something I’m missing 
in dns_lookup that does the redirect)?  If so, how does OVN/OVS know the ip 
address of that server?

 

OVN is not aware of any external DNS servers if any. So if OVN can't resolve 
the DNS, the packet resumes the pipeline

and is treated like any other packet. If the DNS server IP is to be routed it 
will be routed. Let me know If I'm not clear.

 

 

Thanks

Numan

 

 

John Lang

w (303) 272-5457

c (970) 231-3724

 

___
discuss mailing list
HYPERLINK "mailto:disc...@openvswitch.org"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] OVN DNS support questions

[Numan Siddique]

On Tue, Jun 9, 2020 at 11:49 PM John Lang  wrote:

> Numan,
>
>
>
> Earlier I had send an e-mail with the following question that you
> responded to.  I maybe should have asked if the pipeline would redirect the
> DNS request to another DNS server to OVN.
>
>
>
> 1.   If OVN can’t answer a DNS request, does the pipeline forward it
> on the another DNS server?  How is that server address set?  Though the
> DHCP options?
>
>
>
> Yes. If OVN can't anwer it resumes the packet pipeline. So if there are
> any other DNS servers, they should get the packet.
>
> I was looking at the flows in my OVN setup configured for DNS, and I don’t
> see how the DNS request is redirected to a server external to OVN.
>
>
>
>   table=16(ls_in_dns_lookup   ), priority=100  , match=(udp.dst == 53),
> action=(reg0[4] = dns_lookup(); next;)
>
>   table=16(ls_in_dns_lookup   ), priority=0, match=(1), action=(next;)
>
>   table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 &&
> reg0[4]), action=(eth.dst <-> eth.src; ip6.src <-> ip6.dst; udp.dst =
> udp.src; udp.src = 53; outport = inport; flags.loopback = 1; output;)
>
>   table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 &&
> reg0[4]), action=(eth.dst <-> eth.src; ip4.src <-> ip4.dst; udp.dst =
> udp.src; udp.src = 53; outport = inport; flags.loopback = 1; output;)
>
>   table=17(ls_in_dns_response ), priority=0, match=(1), action=(next;)
>
>
>
> Based on these flows it looks like all udp.dst requests on port 53 are
> sent to dns_lookup.  If dns_lookup resolves the request it send the reply
> (either IPV4 or IPV6).  If not, it proceeds to table 18, and I think
> eventually the request gets dropped.  Is there some later flow I should be
> looking for that would redirect the request to another DNS server (or is
> there something I’m missing in dns_lookup that does the redirect)?  If so,
> how does OVN/OVS know the ip address of that server?
>

OVN is not aware of any external DNS servers if any. So if OVN can't
resolve the DNS, the packet resumes the pipeline
and is treated like any other packet. If the DNS server IP is to be routed
it will be routed. Let me know If I'm not clear.


Thanks
Numan


>
> John Lang
>
> w (303) 272-5457
>
> c (970) 231-3724
>
>
> ___
> 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] OVN DNS support questions

[John Lang]

Numan,

 

Earlier I had send an e-mail with the following question that you responded to. 
 I maybe should have asked if the pipeline would redirect the DNS request to 
another DNS server to OVN.

 

1.   If OVN can't answer a DNS request, does the pipeline forward it on the 
another DNS server?  How is that server address set?  Though the DHCP options?

 

Yes. If OVN can't anwer it resumes the packet pipeline. So if there are any 
other DNS servers, they should get the packet.

I was looking at the flows in my OVN setup configured for DNS, and I don't see 
how the DNS request is redirected to a server external to OVN.

 

  table=16(ls_in_dns_lookup   ), priority=100  , match=(udp.dst == 53), 
action=(reg0[4] = dns_lookup(); next;)

  table=16(ls_in_dns_lookup   ), priority=0, match=(1), action=(next;)

  table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 && 
reg0[4]), action=(eth.dst <-> eth.src; ip6.src <-> ip6.dst; udp.dst = udp.src; 
udp.src = 53; outport = inport; flags.loopback = 1; output;)

  table=17(ls_in_dns_response ), priority=100  , match=(udp.dst == 53 && 
reg0[4]), action=(eth.dst <-> eth.src; ip4.src <-> ip4.dst; udp.dst = udp.src; 
udp.src = 53; outport = inport; flags.loopback = 1; output;)

  table=17(ls_in_dns_response ), priority=0, match=(1), action=(next;)

 

Based on these flows it looks like all udp.dst requests on port 53 are sent to 
dns_lookup.  If dns_lookup resolves the request it send the reply (either IPV4 
or IPV6).  If not, it proceeds to table 18, and I think eventually the request 
gets dropped.  Is there some later flow I should be looking for that would 
redirect the request to another DNS server (or is there something I'm missing 
in dns_lookup that does the redirect)?  If so, how does OVN/OVS know the ip 
address of that server?

 

John Lang

w (303) 272-5457

c (970) 231-3724

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

Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve table

[Han Zhou]

On Tue, Jun 9, 2020 at 9:06 AM Venugopal Iyer  wrote:

> Sorry for the delay, Han, a quick question below:
>
>
>
> *From:* ovn-kuberne...@googlegroups.com  *On
> Behalf Of *Han Zhou
> *Sent:* Wednesday, June 3, 2020 4:27 PM
> *To:* Girish Moodalbail 
> *Cc:* Tim Rozet ; Dumitru Ceara ;
> Daniel Alvarez Sanchez ; Dan Winship <
> danwins...@redhat.com>; ovn-kuberne...@googlegroups.com; ovs-discuss <
> ovs-discuss@openvswitch.org>; Michael Cambria ;
> Venugopal Iyer 
> *Subject:* Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve
> table
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Hi Girish, yes, that's what we concluded in last OVN meeting, but sorry
> that I forgot to update here.
>
>
> On Wed, Jun 3, 2020 at 3:32 PM Girish Moodalbail 
> wrote:
> >
> > Hello all,
> >
> > To kind of proceed with the proposed fixes, with minimal impact, is the
> following a reasonable approach?
> >
> > Add an option, namely dynamic_neigh_routes={true|false}, for a gateway
> router. With this option enabled, the nextHop IP's MAC will be learned
> through a ARP request on the physical network. The ARP request will be
> flooded on the L2 broadcast domain (for both join switch and external
> switch).
>
> >
>
>
>
> The RFC patch fulfils this purpose:
> https://patchwork.ozlabs.org/project/openvswitch/patch/1589614395-99499-1-git-send-email-hz...@ovn.org/
>
> I am working on the formal patch.
>
>
>
> > Add an option, namely learn_from_arp_request={true|false}, for a gateway
> router. The option is interpreted as below:\
> > "true" - learn the MAC/IP binding and add a new MAC_Binding entry
> (default behavior)
> > "false" - if there is a MAC_binding for that IP and the MAC is
> different, then update that MAC/IP binding. The external entity might be
> trying to advertise the new MAC for that IP. (If we don't do this, then we
> will never learn External VIP to MAC changes)
> >
> > (Irrespective of, learn_from_arp_request is true or false, always do
> this -- if the TPA is on the router, add a new entry (it means the remote
> wants to communicate with this node, so it makes sense to learn the remote
> as well))
>
> >
>
>
>
> I am working on this as well, but delayed a little. I hope to have
> something this week.
>
> *[vi> ] Just wanted to check if this should be learn_From_unsolicit_arp
> (unsolicited ARP request or reply) instead of learn_from_arp_request? This
> is just to protect from potential rogue usage of  GARP reply flooding the
> MAC bindings.?*
>
>
>

Hi Venu, as discussed earlier in this thread it is hard to check if it is
GARP in OVN from the router ingress pipeline. The proposal here cares about
ARP request only. It seems the best option so far.


> *Thanks,*
>
>
>
> *-venu*
>
>
>
> >
> > For now, I think it is fine for ARP packets to be broadcasted on the
> tunnel for the `join` switch case. If it becomes a problem, then we can
> start looking around changing the logical flows.
> >
> > Thanks everyone for the lively discussion.
> >
> > Regards,
> > ~Girish
> >
> > On Thu, May 28, 2020 at 7:33 AM Tim Rozet  wrote:
> >>
> >>
> >>
> >> On Thu, May 28, 2020 at 7:26 AM Dumitru Ceara 
> wrote:
> >>>
> >>> On 5/28/20 12:48 PM, Daniel Alvarez Sanchez wrote:
> >>> > Hi all
> >>> >
> >>> > Sorry for top posting. I want to thank you all for the discussion and
> >>> > give also some feedback from OpenStack perspective which is affected
> >>> > by the problem described here.
> >>> >
> >>> > In OpenStack, it's kind of common to have a shared external network
> >>> > (logical switch with a localnet port) across many tenants. Each
> tenant
> >>> > user may create their own router where their instances will be
> >>> > connected to access the external network.
> >>> >
> >>> > In such scenario, we are hitting the issue described here. In
> >>> > particular in our tests we exercise 3K VIFs (with 1 FIP) each
> spanning
> >>> > 300 LS; each LS connected to a LR (ie. 300 LRs) and that router
> >>> > connected to the public LS. This is creating a huge problem in terms
> >>> > of performance and tons of events due to the MAC_Binding entries
> >>> > generated as a consequence of the GARPs sent for the floating IPs.
> >>> >
> >>>
> >>> Just as an addition to this, GARPs wouldn't be the only reason why all
> >>> routers would learn the MAC_Binding. Even if we wouldn't be sending
> >>> GARPs for the FIPs, when a VM that's behind a FIP would send traffic to
> >>> the outside, the router will generate an ARP request for the next hop
> >>> using the FIP-IP and FIP-MAC. This will be broadcasted to all routers
> >>> connected to the public LS and will trigger them to learn the
> >>> FIP-IP:FIP-MAC binding.
> >>
> >>
> >> Yeah we shouldn't be learning on regular ARP requests.
> >>
> >>>
> >>>
> >>> > Thanks,
> >>> > Daniel
> >>> >
> >>> >
> >>> > On Thu, May 28, 2020 at 10:51 AM Dumitru Ceara 
> wrote:
> >>> >>
> >>> >> On 5/28/20 8:34 AM, Han Zhou wrote:
> >>> >>>
> >>> >>>
> >>> >>> On Wed, May 27, 2020 at 1:10 A

[ovs-discuss] OVS version for Linux 5.5 kernel version

[Sravan A Dinesh]

Hi OVS team
  Can you please suggest the OVS version which is
compatible with Linux 5.5 kernel version or is there any patch available
for the same. Also when are you planning to release OVS version 2.14.
Please let me know.

*With Best Regards*
Sravan A Dinesh
VVDN Technologies Pvt Ltd
Cell: +91 8547955398
Web: www.vvdntech.com

-- 



_Disclaimer: _© 2020 VVDN Technologies Pvt. Ltd. This e-mail contains 
PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the 
addressee(s). If you are not the intended recipient, please notify the 
sender by e-mail and delete the original message. Further, you are not to 
copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful._
_
_
_
__
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve table

[Venugopal Iyer]

Sorry for the delay, Han, a quick question below:

From: ovn-kuberne...@googlegroups.com  On 
Behalf Of Han Zhou
Sent: Wednesday, June 3, 2020 4:27 PM
To: Girish Moodalbail 
Cc: Tim Rozet ; Dumitru Ceara ; Daniel 
Alvarez Sanchez ; Dan Winship ; 
ovn-kuberne...@googlegroups.com; ovs-discuss ; 
Michael Cambria ; Venugopal Iyer 
Subject: Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve table

External email: Use caution opening links or attachments

Hi Girish, yes, that's what we concluded in last OVN meeting, but sorry that I 
forgot to update here.

On Wed, Jun 3, 2020 at 3:32 PM Girish Moodalbail 
mailto:gmoodalb...@gmail.com>> wrote:
>
> Hello all,
>
> To kind of proceed with the proposed fixes, with minimal impact, is the 
> following a reasonable approach?
>
> Add an option, namely dynamic_neigh_routes={true|false}, for a gateway 
> router. With this option enabled, the nextHop IP's MAC will be learned 
> through a ARP request on the physical network. The ARP request will be 
> flooded on the L2 broadcast domain (for both join switch and external switch).
>

The RFC patch fulfils this purpose: 
https://patchwork.ozlabs.org/project/openvswitch/patch/1589614395-99499-1-git-send-email-hz...@ovn.org/
I am working on the formal patch.

> Add an option, namely learn_from_arp_request={true|false}, for a gateway 
> router. The option is interpreted as below:\
> "true" - learn the MAC/IP binding and add a new MAC_Binding entry (default 
> behavior)
> "false" - if there is a MAC_binding for that IP and the MAC is different, 
> then update that MAC/IP binding. The external entity might be trying to 
> advertise the new MAC for that IP. (If we don't do this, then we will never 
> learn External VIP to MAC changes)
>
> (Irrespective of, learn_from_arp_request is true or false, always do this -- 
> if the TPA is on the router, add a new entry (it means the remote wants to 
> communicate with this node, so it makes sense to learn the remote as well))
>

I am working on this as well, but delayed a little. I hope to have something 
this week.
[vi> ] Just wanted to check if this should be learn_From_unsolicit_arp 
(unsolicited ARP request or reply) instead of learn_from_arp_request? This is 
just to protect from potential rogue usage of  GARP reply flooding the MAC 
bindings.?

Thanks,

-venu

>
> For now, I think it is fine for ARP packets to be broadcasted on the tunnel 
> for the `join` switch case. If it becomes a problem, then we can start 
> looking around changing the logical flows.
>
> Thanks everyone for the lively discussion.
>
> Regards,
> ~Girish
>
> On Thu, May 28, 2020 at 7:33 AM Tim Rozet 
> mailto:tro...@redhat.com>> wrote:
>>
>>
>>
>> On Thu, May 28, 2020 at 7:26 AM Dumitru Ceara 
>> mailto:dce...@redhat.com>> wrote:
>>>
>>> On 5/28/20 12:48 PM, Daniel Alvarez Sanchez wrote:
>>> > Hi all
>>> >
>>> > Sorry for top posting. I want to thank you all for the discussion and
>>> > give also some feedback from OpenStack perspective which is affected
>>> > by the problem described here.
>>> >
>>> > In OpenStack, it's kind of common to have a shared external network
>>> > (logical switch with a localnet port) across many tenants. Each tenant
>>> > user may create their own router where their instances will be
>>> > connected to access the external network.
>>> >
>>> > In such scenario, we are hitting the issue described here. In
>>> > particular in our tests we exercise 3K VIFs (with 1 FIP) each spanning
>>> > 300 LS; each LS connected to a LR (ie. 300 LRs) and that router
>>> > connected to the public LS. This is creating a huge problem in terms
>>> > of performance and tons of events due to the MAC_Binding entries
>>> > generated as a consequence of the GARPs sent for the floating IPs.
>>> >
>>>
>>> Just as an addition to this, GARPs wouldn't be the only reason why all
>>> routers would learn the MAC_Binding. Even if we wouldn't be sending
>>> GARPs for the FIPs, when a VM that's behind a FIP would send traffic to
>>> the outside, the router will generate an ARP request for the next hop
>>> using the FIP-IP and FIP-MAC. This will be broadcasted to all routers
>>> connected to the public LS and will trigger them to learn the
>>> FIP-IP:FIP-MAC binding.
>>
>>
>> Yeah we shouldn't be learning on regular ARP requests.
>>
>>>
>>>
>>> > Thanks,
>>> > Daniel
>>> >
>>> >
>>> > On Thu, May 28, 2020 at 10:51 AM Dumitru Ceara 
>>> > mailto:dce...@redhat.com>> wrote:
>>> >>
>>> >> On 5/28/20 8:34 AM, Han Zhou wrote:
>>> >>>
>>> >>>
>>> >>> On Wed, May 27, 2020 at 1:10 AM Dumitru Ceara 
>>> >>> mailto:dce...@redhat.com>
>>> >>> >> wrote:
>>> 
>>>  Hi Girish, Han,
>>> 
>>>  On 5/26/20 11:51 PM, Han Zhou wrote:
>>> >
>>> >
>>> > On Tue, May 26, 2020 at 1:07 PM Girish Moodalbail
>>> >>> mailto:gmoodalb...@gmail.com> 
>>> >>> >
>>> > 

Re: [ovs-discuss] DP_Packet Payload Modification [Solved I think]

[Gregory Rose]

On 6/6/2020 7:16 AM, Luca Mancini wrote:

Sorry for making a mess of this thread but I think I solved the issue.
I noticed by doing some pointer prints that I was overwriting the whole l4 
space including the header causing a mess with packet allignment so I used 
memcpy instead of dp_packet_put:

memcpy((char *) dp_packet_l4(packetAggr) + UDP_HEADER_LEN, dp_packet_buff1, 
sizeof(dp_packet_buff1));

packet is now complete and extraction of payload works, now I’ll start working 
on the sending part which is probably not as easy as I think.

Thanks for the help!



I'm not sure how much help I was but I'm glad you've got it figured out.

Good luck!

- Greg


Luca

From: Luca Mancini
Sent: Saturday, June 6, 2020 15:40
To: Luca Mancini; 
ovs-discuss@openvswitch.org; Gregory 
Rose
Subject: RE: [ovs-discuss] DP_Packet Payload Modification


UPDATE:
I made a mistake when calculating the size of the dummy string  when adding it 
with dp_packet_put, if I change it to
char payload [] = “hello world”
everything works fine, however if I add the actual buffer of packets as its 
payload (instead of the dummy string), when printing the packets some packet 
fields are zeroed out, even though the extraction works….

Packet structure when I do
dp_packet_put(packetAggr, dummystring, sizeof dummystring);
packetaggr: 
udp,vlan_tci=0x,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=33199,tp_dst=444
 udp_csum:6870

Packet structure when I do
dp_packet_put(packetAggr, dp_packet_buff1, sizeof dp_packet_buff1);
packetaggr: 
ip,vlan_tci=0x,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0

starting from nw_src everything is zeroed out, so it makes me think it’s 
getting overwritten, but the payload is extracted correctly with 
dp_packet_get_udp_paylaod meaning the payload is most likely aligned correctly. 
Any thoughts of what is happening?



Luca

From: Luca Mancini
Sent: Saturday, June 6, 2020 11:08
To: Gregory Rose
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] DP_Packet Payload Modification

Hi Greg,
Here’s the devil!
This is from the file ofproto-dpif-xlate.c, my whole action for now is 
implemented in userspace

#define UDP_MAX_PAYLOAD_SIZE 65507
#define PACKET_BUFF_ELEMENTS 5
static int index1;
static struct my_captured_packet dp_packet_buff1[PACKET_BUFF_ELEMENTS];

struct my_captured_packet
{
 struct dp_packet packet;
 int sizeofpayload;
};
compose_buffr_action(struct xlate_ctx *ctx)
{
 //creates the buffer of packet
 if(index1 < 5 && ctx->xin->packet)
 {
 //clone incoming packet
 struct dp_packet *packet_to_store = dp_packet_clone(ctx->xin->packet);

 //build my_captured_packet array using dp_packet (not the pointer) and 
the payload size
 dp_packet_buff1[index1].packet = *packet_to_store;
 dp_packet_buff1[index1].sizeofpayload = 
dp_packet_l4_size(ctx->xin->packet) - UDP_HEADER_LEN;

 //print payload taking into account its size otherwiseugly memory 
overlap occurs
VLOG_ERR("%.*s",dp_packet_buff1[index1].sizeofpayload, (char *) 
dp_packet_get_udp_payload(&dp_packet_buff1[index1].packet));
 index1++;
 }
 //create custom packet to send
 if(index1 == 5 )
 {
 index1 = 0;
 struct dp_packet *packetAggr;
 packetAggr = dp_packet_new(UDP_MAX_PAYLOAD_SIZE);

 struct flow flow;
 flow_extract(&dp_packet_buff1[0].packet, &flow);

 char * payload = "hello world";
 flow_compose(packetAggr, &flow, NULL, 0);
 dp_packet_put(packetAggr, payload, sizeof payload);

int s = dp_packet_l4_size(packetAggr) - UDP_HEADER_LEN; //get length of 
payload to print
VLOG_ERR("udp_pay of l4 of packet aggr: %.*s", s , (char *) 
dp_packet_get_udp_payload(packetAggr)); //prints “hello w”

 //extract buffer from custom packet print packets after extraction to 
see if I can retrieve the single dp_packets, commented out for now
/*
struct my_captured_packet *recvdpackets = (struct my_captured_packet *) 
dp_packet_data(packetAggr);
 for(int j=0; jmailto:gvrose8...@gmail.com>
Sent: Friday, June 5, 2020 23:05
To: Luca Mancini; 
ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] DP_Packet Payload Modification


On 6/5/2020 11:00 AM, Luca Mancini wrote:


Hi Greg,
I realized I didn’t give a lot of context..
Basically, I’m implementing a custom action which is meant to buffer an x 
amount of dp_packets that match a certain flow, and then send a new packet 
directly from the switch, containing the buffer of 

Re: [ovs-discuss] strange behavior when i send DP_PACKET from userspace

[Luca Mancini]

I believe it might be fixed by adding payload parameters to flow_compose() 
instead of setting it to null like I did


From: Luca Mancini
Sent: Tuesday, June 9, 2020 11:39
To: ovs-discuss@openvswitch.org
Subject: strange behavior when i send DP_PACKET from userspace


Hello,
I’m having problems with sending custom packets using the 
ofproto_dpif_send_packet().
As said in the previoius thread 
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050204.html I 
thought to have correctly created a custom udp packet that contains as a 
payload a buffer of dp_packets this is the code:


struct my_captured_packet
{
struct dp_packet packet;
int sizeofpayload;
};
static struct my_captured_packet dp_packet_buff1[PACKET_BUFF_ELEMENTS];

//function to copy incoming packets to dp_packet_buff1
//…..

//function part to send the buffer of packets as payload of new udp packet
struct dp_packet *packetAggr;
packetAggr = dp_packet_new(65535);

struct flow flow;
//extract a flow from a buffed pkt
flow_extract(&dp_packet_buff1[0].packet, &flow);
//use the flow to build a new packet
flow_compose(packetAggr, &flow, NULL, 0);

//copy buffer as udp payload
memcpy((char *) dp_packet_l4(packetAggr) + UDP_HEADER_LEN, dp_packet_buff1, 
sizeof(dp_packet_buff1));


//Then I reversed the procedure to see if I could extract the single packets 
from the payload of my custom packet
//struct my_captured_packet *recvdpackets = (struct my_captured_packet *) 
dp_packet_get_udp_payload(packetAggr);
//print dp_packet payloads extracted

for(int j=0; jxin->ofproto;
const struct ofport_dpif *portAggr;
ofp_port_t out_port = 2;
portAggr = ofp_port_to_ofport(ofproto, out_port);


ofproto_dpif_send_packet(portAggr, false,  packetAggr);


The above code works as intended, meaning after creating packetAggr and setting 
its payload to dp_packet_buff1 I can cast it back to its original type after 
retrieving it with dp_packet_get_udp_payload, and print the single packets.
However after I send this packet and do this same exact procedure as part of a 
new action that is intended to just extract the payload and single packets, the 
cast to struct my_captured_packet * doesn’t seem to work. The following is what 
gets printed on GDB:

//upon packet arrival, check the mac to see if it’s the packet intended for 
extraction
//print the packet
packet_recvd = dp_packet_clone (ctx->xin->packet);
VLOG_ERR("structure of pkt received: %s ", 
ofp_dp_packet_to_string(packet_recvd))

Gdb --> structure of pkt received by deaggr: 
udp,vlan_tci=0x,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=47981,tp_dst=444
 udp_csum:2eb2

//Extract the payload by casting
struct my_captured_packet *checkrecvd = (struct my_captured_packet *) 
dp_packet_get_udp_payload(packet_recvd);

VLOG_ERR("structure of first packet extracted from buffer: %s with size_ of 
%d", ofp_dp_packet_to_string(&checkrecvdAggr[0].packet),  
checkrecvdAggr[0].packet.size_);

Gdb--> structure of first packet extracted from buffer:  
packet_type=(0x302c,0x646c) //this should be a normal structured dp_packet

with size_ of 21299712 //size seems abnormal

I’ve tried this whole algorithm by sending a normal packet received without 
creating a new one and it works, so I’m guessing the problem is still in how I 
structure my custom packet, so my question is what am I missing in order to 
create a valid custom UDP packet that is sendable from OVS? Can I find examples 
anywhere in the codebase? I haven’t seen anything to be honest.
Help is really needed!

Thanks,

Luca














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

Re: [ovs-discuss] RFC - OVN end to end packet tracing - ovn-global-trace

[Tim Rozet]

Hi Dumitru,
Thanks for the detailed explanation. It makes sense and would like to
comment on a few things you touched on:
1. I do think we need to somehow functionally trigger conntrack when we do
ofproto-trace. It's the only way to know what the real session state ends
up being, and we need to be able to follow that for some of the complex
bugs where packets are getting dropped after they enter a CT based flow.
2. For your ovn-global-trace, it would be great if that could return a json
or other parsable format, so that we could build on top of it with a tool +
GUI to graphically show where the problem is in the network.
3. We really need better user guides on this stuff. Your email is the best
tutorial I've seen yet :) I didn't even know about the
ovs-tcpundump command, or ovn-detrace (until you told me previously). It
would be great to add an ovn troubleshooting guide or something to the docs.

As an administrator I would like to have GUI showing all of the logical
switch ports (skydive as an example, already does this) and then click on a
specific port that someone has reported an issue on. At that point I can
click on the port and ask it to tcpdump me the traffic coming out of it.
>From there, I can select which packet I care about and attempt to do an
ovn-global-trace on it, which will then show me where the packet is getting
dropped and why. I think this would be the ideal behavior.

Tim Rozet
Red Hat CTO Networking Team


On Mon, Jun 8, 2020 at 7:53 AM Dumitru Ceara  wrote:

> Hi everyone,
>
> CC-ing ovn-kubernetes mailing list as I know there's interest about this
> there too.
>
> OVN currently has a couple of tools that help
> tracing/tracking/simulating what would happen to packets within OVN,
> some examples:
>
> 1. ovn-trace
> 2. ovs-appctl ofproto/trace ... | ovn-detrace
>
> They're both really useful and provide lots of information but with both
> of them quite it's hard to get an overview of the end-to-end packet
> processing in OVN for a given packet. Therefore both solutions have
> disadvantages when trying to troubleshoot production deployments. Some
> examples:
>
> a. ovn-trace will not take into account any potential issues with
> translating logical flows to openflow so if there's a bug in the
> translation we'll not be able to detect it by looking at ovn-trace
> output. There is the --ovs switch but the user would have to somehow
> determine on which hypervisor to query for the openflows corresponding
> to logical flows/SB entities.
>
> b. "ovs-appctl ofproto/trace ... | ovn-detrace" works quite well when
> used on a single node but as soon as traffic gets tunneled to a
> different hypervisor the user has to figure out the changes that were
> performed on the packet on the source hypervisor and adapt the
> packet/flow to include the tunnel information to be used when running
> ofproto/trace on the destination hypervisor.
>
> c. both ovn-trace and ofproto/trace support minimal hints to specify the
> new conntrack state after conntrack recirculation but that turns out to
> be not enough even in simple scenarios when NAT is involved [0].
>
> In a production deployment one of the scenarios one would have to
> troubleshoot is:
>
> "Given this OVN deployment on X nodes why isn't this specific
> packet/traffic that is received on logical port P1 doesn't reach/reach
> port P2."
>
> Assuming that point "c" above is addressed somehow (there are a few
> suggestions on how to do that [1]) it's still quite a lot of work for
> the engineer doing the troubleshooting to gather all the interesting
> information. One would probably do something like:
>
> 1. connect to the node running the southbound database and get the
> chassis where the logical port is bound:
>
> chassis=$(ovn-sbctl --bare --columns chassis list port_binding P1)
> hostname=$(ovn-sbctl --bare --columns hostname list chassis $chassis)
>
> 2. connect to $hostname and determine the OVS ofport id of the interface
> corresponding to P1:
>
> in_port=$(ovs-vsctl --bare --columns ofport find interface
> external_ids:iface-id=P1)
> iface=$(ovs-vsctl --bare --columns name find interface
> external_ids:iface-id=P1)
>
> 3. get a hexdump of the packet to be traced (or the flow), for example,
> on $hostname:
> flow=$(tcpdump -xx -c 1 -i $iface $pkt_filter | ovs-tcpundump)
>
> 3. run ofproto/trace on $hostname (potentially piping output to
> ovn-detrace):
>
> ovs-appctl ofproto/trace br-int in_port=$in_port $flow | ovn-detrace
> --ovnnb=$NB_CONN --ovnsb=$SB_CONN
>
> 4. In the best case the packet is fully processed on the current node
> (e.g., is dropped or forwarded out a local VIF).
>
> 5. In the worst case the packet needs to be tunneled to a remote
> hypervisor for egress on a remote VIF. The engineer needs to identify in
> the ofproto/trace output the metadata that would be passed through the
> tunnel along with the packet and also the changes that would happen to
> the packet payload (e.g. NAT) on the local hypervisor.
>
> 6. Determine the ho

[ovs-discuss] strange behavior when i send DP_PACKET from userspace

[Luca Mancini]

Hello,
I’m having problems with sending custom packets using the 
ofproto_dpif_send_packet().
As said in the previoius thread 
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050204.html I 
thought to have correctly created a custom udp packet that contains as a 
payload a buffer of dp_packets this is the code:


struct my_captured_packet
{
struct dp_packet packet;
int sizeofpayload;
};
static struct my_captured_packet dp_packet_buff1[PACKET_BUFF_ELEMENTS];

//function to copy incoming packets to dp_packet_buff1
//…..

//function part to send the buffer of packets as payload of new udp packet
struct dp_packet *packetAggr;
packetAggr = dp_packet_new(65535);

struct flow flow;
//extract a flow from a buffed pkt
flow_extract(&dp_packet_buff1[0].packet, &flow);
//use the flow to build a new packet
flow_compose(packetAggr, &flow, NULL, 0);

//copy buffer as udp payload
memcpy((char *) dp_packet_l4(packetAggr) + UDP_HEADER_LEN, dp_packet_buff1, 
sizeof(dp_packet_buff1));


//Then I reversed the procedure to see if I could extract the single packets 
from the payload of my custom packet
//struct my_captured_packet *recvdpackets = (struct my_captured_packet *) 
dp_packet_get_udp_payload(packetAggr);
//print dp_packet payloads extracted

for(int j=0; jxin->ofproto;
const struct ofport_dpif *portAggr;
ofp_port_t out_port = 2;
portAggr = ofp_port_to_ofport(ofproto, out_port);


ofproto_dpif_send_packet(portAggr, false,  packetAggr);


The above code works as intended, meaning after creating packetAggr and setting 
its payload to dp_packet_buff1 I can cast it back to its original type after 
retrieving it with dp_packet_get_udp_payload, and print the single packets.
However after I send this packet and do this same exact procedure as part of a 
new action that is intended to just extract the payload and single packets, the 
cast to struct my_captured_packet * doesn’t seem to work. The following is what 
gets printed on GDB:

//upon packet arrival, check the mac to see if it’s the packet intended for 
extraction
//print the packet
packet_recvd = dp_packet_clone (ctx->xin->packet);
VLOG_ERR("structure of pkt received: %s ", 
ofp_dp_packet_to_string(packet_recvd))

Gdb --> structure of pkt received by deaggr: 
udp,vlan_tci=0x,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=47981,tp_dst=444
 udp_csum:2eb2

//Extract the payload by casting
struct my_captured_packet *checkrecvd = (struct my_captured_packet *) 
dp_packet_get_udp_payload(packet_recvd);

VLOG_ERR("structure of first packet extracted from buffer: %s with size_ of 
%d", ofp_dp_packet_to_string(&checkrecvdAggr[0].packet),  
checkrecvdAggr[0].packet.size_);

Gdb--> structure of first packet extracted from buffer:  
packet_type=(0x302c,0x646c) //this should be a normal structured dp_packet

with size_ of 21299712 //size seems abnormal

I’ve tried this whole algorithm by sending a normal packet received without 
creating a new one and it works, so I’m guessing the problem is still in how I 
structure my custom packet, so my question is what am I missing in order to 
create a valid custom UDP packet that is sendable from OVS? Can I find examples 
anywhere in the codebase? I haven’t seen anything to be honest.
Help is really needed!

Thanks,

Luca













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