VxLAN-GPE+ETH+NSH should be then 0x03 isn't it ? According to the VxLAN-GPE spec :
0x3 : Ethernet 0x4 : Network Service Header When the NP is set as 0x04 then the interpreter will assume that the immediate contents after the VxLANheader is that of NSH, but ovs would be encoding a MAC header instead. This is confusing. Please clarify. Regards, Ramesh On Wed, Aug 3, 2016 at 6:08 AM, Yang, Yi Y <[email protected]> wrote: > The original patch supports VxLAN-gpe + NSH, but current ovs doesn’t allow > this, so we have to add Ethernet header, this is a workaround. Hard code is > just to avoid misuse, current version is VxLAN-gpe+Eth+NSH only, no other > choice. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ramesh Devarajan > *Sent:* Wednesday, August 3, 2016 1:41 AM > *To:* [email protected] > *Subject:* [sfc-dev] Regarding NSP set as 0x04 > > > > The flows that gets installed in OVS for forwarding packets to > SF/Classifier looks like this: > > > > cookie=0xba5eba11ba5eba11, duration=480.712s, table=10, n_packets=0, > n_bytes=0, priority=650,nsi=254,nsp=48 > actions=move:NXM_NX_NSH_MDTYPE[]->NXM_NX_NSH_MDTYPE[],move:NXM_NX_NSH_NP[]->NXM_NX_NSH_NP[],move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[0..23]->NXM_NX_NSP[0..23],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31], > *load:0x4->NXM_NX_TUN_GPE_NP*[],IN_PORT > > > > cookie=0xba5eba11ba5eba11, duration=480.712s, table=10, n_packets=0, > n_bytes=0, priority=650,nsi=255,nsp=48 > actions=move:NXM_NX_NSH_MDTYPE[]->NXM_NX_NSH_MDTYPE[],move:NXM_NX_NSH_NP[]->NXM_NX_NSH_NP[],move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31] > ,*load:0x4->NXM_NX_TUN_GPE_NP*[],IN_PORT > > > > 0x04 is for NSH immediately following the VXLAN-GPE header. Ideally we > should be using 0x03 for VXLAN-GPE+MAC+NSH. > > The problem is that if i send a packet with the VXLAN-GPE NSP set as 0x03, > the flow overrides this with the value of 0x04. > > I suppose it would be appropriate if we can copy this field from the > packet headers itself, like the tunnel ID and other NSH fields. > > Any specific reason why we hard code this in the flow rule ? > > > > Regards, > > Ramesh >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
