On Wed, Nov 30, 2016 at 6:24 AM, László Sürü <[email protected]> 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ü <[email protected]>; Jiri Benc <[email protected]>; > Yang, Yi Y <[email protected]> > Cc: Jan Scheurich <[email protected]>; > [email protected]; Georgios Paraskevopoulos ( > [email protected]) <[email protected]>; Georg > Schmuecking <[email protected]> > 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 <[email protected]>; Jiri Benc <[email protected]>; > Yang, Yi Y <[email protected]> > Cc: Jan Scheurich <[email protected]>; > [email protected]; Georgios Paraskevopoulos ( > [email protected]) <[email protected]>; Georg > Schmuecking <[email protected]> > 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 <[email protected]>; Yang, Yi Y <[email protected]> > Cc: Jan Scheurich <[email protected]>; > [email protected]; Georgios Paraskevopoulos ( > [email protected]) <[email protected]>; Georg > Schmuecking <[email protected]>; László Sürü < > [email protected]> > 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:[email protected]] > Sent: Thursday, November 24, 2016 3:24 PM > To: Yang, Yi Y <[email protected]> > Cc: Jan Scheurich <[email protected]>; Manuel Buil < > [email protected]>; [email protected]; Georgios > Paraskevopoulos ([email protected]) <[email protected]>; > Georg Schmuecking <[email protected]>; László Sürü < > [email protected]> > 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 > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
