Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Manuel, Yes, and the default destination port for a VXLAN-GPE tunnel should be 4790 then. Best regards Laszlo -Original Message- From: Manuel Buil Sent: Tuesday, November 29, 2016 3:02 PM To: László Sürü ; Jiri Benc ; Yang, Yi Y

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Jiri, I think ovs pushes that metadata because the packet ingresses ovs through a vxlan-gpe port with exactly those parameters. -Manuel -Original Message- From: Jiri Benc [mailto:jb...@redhat.com] Sent: Thursday, November 24, 2016 3:24 PM To: Yang, Yi Y Cc:

Re: [sfc-dev] Potential bug in NSH patch for OVS

On Thu, 24 Nov 2016 13:34:29 +, Yang, Yi Y wrote: > Vxlan implementation doesn't provide a field to change it, do you > know how we can change it? I search ovs source code, there isn't a > field to change tp_dst in tunnel header. Hmm, seems you're right. So, first thing that you need to

Re: [sfc-dev] Potential bug in NSH patch for OVS

On Thu, 24 Nov 2016 12:57:40 +, Yang, Yi Y wrote: > I noticed vxlan module always uses tp_dst from tunnel metadata in > preference to vxlan->cfg.dst_port, this isn't the result we want in > some use cases, for example, if we create two vxlan port which have > different dst_port, when we

Re: [sfc-dev] Potential bug in NSH patch for OVS

On Thu, 24 Nov 2016 08:29:29 +, Jan Scheurich wrote: > This looks like a bug in OVS VXLAN tunnel port implementation (in the > kernel datapath). This is not a bug in the kernel datapath. > For the OVS upstream development we'll have to make sure that the > tunnel port implementation uses the

Re: [sfc-dev] Potential bug in NSH patch for OVS

Jiri, here is description of this issue I sent to ovs-discussion mailing list, we didn't change these code, vxlan module in vanilla ovs will have the same behavior. Hi, folks I noticed vxlan module always uses tp_dst from tunnel metadata in preference to vxlan->cfg.dst_port, this isn't the

Re: [sfc-dev] Potential bug in NSH patch for OVS

Manuel, I have sent an email about this in ovs-discussion mailing list. Let us wait for their feedback. From: Manuel Buil [mailto:manuel.b...@ericsson.com] Sent: Thursday, November 24, 2016 4:21 PM To: Yang, Yi Y Cc: sfc-dev@lists.opendaylight.org; Georgios Paraskevopoulos

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Yi Yang, Great! Thanks for your help :) Should we communicate the change you suggest to the appropriate community (OVS)? Or is it in your NSH patch for OVS? Regards, Manuel From: Yang, Yi Y [mailto:yi.y.y...@intel.com] Sent: Thursday, November 24, 2016 2:53 AM To: Manuel Buil

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi, Manuel I checked vxlan module code, tunnel tp_dst will inherit tp_dst in tunnel metadata when you send the packet to the vxlan port, because the packet is from a vxlan-gpe port, so tunnel metadata is there and its tp_dst is vxlan-gpe port's dst_port, so vxlan module will use it for your

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi, Here is another set-up where we can see the problem: client and server are in compute1 and SF is in compute2. Compute1 has IP 192.168.2.3 Compute2 has IP 192.168.2.4 If we tcpdump what goes from compute2 to compute1 and while sniffing we send traffic through the chain, this is what we

Re: [sfc-dev] Potential bug in NSH patch for OVS

Manuel, can you send the openflow entry for this output? If it is an explicit output to vxlan port, vxlan module will set tp_dst to vxlan's tp_dst. In dump-flows you provided, there was't any packet hitting that flow entry. From: Manuel Buil [mailto:manuel.b...@ericsson.com] Sent: Wednesday,

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Yi Yang, Compute1 has both ports, vxlangpe controlled by SFC and vxlan controlled by netvirt. The packets egress through vxlan port but using the destination port 6633. They don't egress through vxlan-gpe. /Manuel From: Yang, Yi Y [mailto:yi.y.y...@intel.com] Sent: Wednesday, November 23,

Re: [sfc-dev] Potential bug in NSH patch for OVS

ovember 23, 2016 11:36 AM To: Manuel Buil <manuel.b...@ericsson.com>; Paraskevopoulos Georgios <geo...@intracom-telecom.com>; Yang, Yi Y <yi.y.y...@intel.com> Cc: sfc-dev@lists.opendaylight.org Subject: Re: [sfc-dev] Potential bug in NSH patch for OVS Manuel, A minor

Re: [sfc-dev] Potential bug in NSH patch for OVS

Then the SFF in compute1 should have two vlxan ports, one (vxlangpe) is controlled by SFC, another (vxlan) is controlled by netvirt, so it should be SFC's issue but not ovs' issue. From: Manuel Buil [mailto:manuel.b...@ericsson.com] Sent: Wednesday, November 23, 2016 4:34 PM To: Yang, Yi Y

Re: [sfc-dev] Potential bug in NSH patch for OVS

Manuel, A minor correction on your last statement: Currently the last SFF is NOT popping the NSH header. Instead, we send the packet to Netvirt with the NSH header. Netvirt processes the packet and strips the NSH header. Currently, if we dont do it this way, and the classifier is

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Georgios, Don't be sorry, it is great to see more people participating in the discussion :). The last SF should not egress the packet to another compute, it should egress the packet to the SFF. Then, if it is the last SFF, it pops the NSH header and hands over the packet to the Netvirt

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi, Sorry to step in. Just a remark. It seems to me that the problem is that when the last SF egresses the packet to another compute, it incorrectly does it through vxlan_gpe, rather than vxlan. So it might be that the problem is not that some value is hardcoded, rather that OVS does an

Re: [sfc-dev] Potential bug in NSH patch for OVS

Hi Yi Yang, I think we have different views here. The packet was already processed by the SFC pipeline and now it is again in the Netvirt pipeline. Why should then the packet be sent using the vxlan-gpe interface from the compute? The packet should use the vxlan interface of Netvirt which is

Re: [sfc-dev] Potential bug in NSH patch for OVS

Yi, In the test Manuel is running, SFC is only "active/installed" on compute1, since that's the only SFF that has been configured. The bridge on compute2 is not in the SFC domain, and is only known to netvirt, not to SFC. So, netvirt shouldnt need a classifier on compute2, hence no vxgpe

Re: [sfc-dev] Potential bug in NSH patch for OVS

I think that is NetVirt classifier issue, in sfc103 demo, we have on SF use case. In your case, you must have two classifiers, one is in compute1, another is in compute2, for compute1, I think you have enabled NetVirt to send back the packet to the client, but for compute2, NetVirt can't

[sfc-dev] Potential bug in NSH patch for OVS

Hi Yi Yang, I am observing that sometimes our SFC OPNFV test case fails. I am trying to investigate why and I think I found the problem. ### SET-UP ### The environment is the following: the http traffic from client gets classified and assigned to a chain with one SF. After the traffic visits