On Wed, Nov 30, 2016 at 6:24 AM, László Sürü <laszlo.s...@ericsson.com> wrote:
> Hi Manuel, > > Yes, and the default destination port for a VXLAN-GPE tunnel should be > 4790 then. > Does this matter yet? Meaning, is any of the gpe stuff really in use yet? Typically we just use the vxlan-gpe vtep as a standard vxlan vtep. The 6633 port was just a way to have a different tunnel. Or the actual port number really didn't matter. > > Best regards > Laszlo > > -----Original Message----- > From: Manuel Buil > Sent: Tuesday, November 29, 2016 3:02 PM > To: László Sürü <laszlo.s...@ericsson.com>; Jiri Benc <jb...@redhat.com>; > Yang, Yi Y <yi.y.y...@intel.com> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; > sfc-dev@lists.opendaylight.org; Georgios Paraskevopoulos ( > geo...@intracom-telecom.com) <geo...@intracom-telecom.com>; Georg > Schmuecking <georg.schmueck...@ericsson.com> > Subject: RE: Potential bug in NSH patch for OVS > > Hi Laszlo, > > It should use destination port 4789 which is the one defined for the > default connectivity among computes. However, if the packet was ever in the > SFC pipeline, it uses 6633. > > Regards, > Manuel > > -----Original Message----- > From: László Sürü > Sent: Monday, November 28, 2016 5:54 PM > To: Manuel Buil <manuel.b...@ericsson.com>; Jiri Benc <jb...@redhat.com>; > Yang, Yi Y <yi.y.y...@intel.com> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; > sfc-dev@lists.opendaylight.org; Georgios Paraskevopoulos ( > geo...@intracom-telecom.com) <geo...@intracom-telecom.com>; Georg > Schmuecking <georg.schmueck...@ericsson.com> > Subject: RE: Potential bug in NSH patch for OVS > > Hi All, > Sorry for the late reply, just catching up with this discussion. > > Regarding the tp_dst port, I've noted the above described misbehavior > before, that is Instead of the IETF reserved 4790 destination port for > VXLAN-GPE OpenStack Tacker - if used for NFVI use case - uses the hard > coded 6633 destination port. > > Manuel, can this be the case here? > > Best regards > Laszlo > > -----Original Message----- > From: Manuel Buil > Sent: Thursday, November 24, 2016 6:01 PM > To: Jiri Benc <jb...@redhat.com>; Yang, Yi Y <yi.y.y...@intel.com> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; > sfc-dev@lists.opendaylight.org; Georgios Paraskevopoulos ( > geo...@intracom-telecom.com) <geo...@intracom-telecom.com>; Georg > Schmuecking <georg.schmueck...@ericsson.com>; László Sürü < > laszlo.s...@ericsson.com> > Subject: RE: 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 <yi.y.y...@intel.com> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; Manuel Buil < > manuel.b...@ericsson.com>; sfc-dev@lists.opendaylight.org; Georgios > Paraskevopoulos (geo...@intracom-telecom.com) <geo...@intracom-telecom.com>; > Georg Schmuecking <georg.schmueck...@ericsson.com>; László Sürü < > laszlo.s...@ericsson.com> > Subject: Re: Potential bug in NSH patch for OVS > > On Thu, 24 Nov 2016 13:34:29 +0000, 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 figure out is why ovs is pushing > "actions:set(tunnel(tp_src=49676,tp_dst=6633))" to the kernel when > outputting to a tunnel that has a different port configured. Because this > is the problem, not the kernel code. > > Btw, I just tried it and ovs doesn't do that for me. But I have most > certainly a different configuration than you do. > > Jiri > > > > _______________________________________________ > sfc-dev mailing list > sfc-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/sfc-dev >
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
