Hi Brady,
Yes, I agree with you that it must be that. However, I would say this is a
problem of OVS because normally if you want that a port gets the data from the
flows, you configure the parameters in OVS as "parameter"=flow, like here:
Port vxgpe
Interface vxgpe
type: vxlan
options: {dst_port="6633", exts=gpe, key=flow, "nshc1"=flow,
"nshc2"=flow, "nshc3"=flow, "nshc4"=flow, nsi=flow, nsp=flow, remote_ip=flow}
The vxlan ports in netvirt have the following configuration:
Port "vxlan-192.168.2.3"
Interface "vxlan-192.168.2.3"
type: vxlan
options: {key=flow, local_ip="192.168.2.4",
remote_ip="192.168.2.3"}
Perhaps if it is not specified what dst_port to use, they get the default 4789
and if there is something in the metadatd, that value overwrites the default.
How should we proceed? Should we investigate further or do we add tp_dst=4789
in one flow and fix the issue? The second option will be faster of course :).
Regards,
Manuel
From: Brady Allen Johnson
Sent: Wednesday, November 23, 2016 11:36 AM
To: Manuel Buil <[email protected]>; Paraskevopoulos Georgios
<[email protected]>; Yang, Yi Y <[email protected]>
Cc: [email protected]
Subject: 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 on
the same bridge as the SFF, the packet will get classified again, and we'll
have a nasty loop.
Back to the original discussion:
When the packet enters the SFF from the SF on the vxgpe port, OVS stores the
vxlan info in what I believe is called the packet metadata (not to be confused
with the openflow metadata). I suspect that when the packet is then egressed
out the vxlan port, it is using the some of the same packet metadata info as
when it came in the vxgep port. If this is the case, could it be that its using
the same tp_dst port of 6633? We may have to make a change to netvirt to
explicitly set the tp_dst port to 4789 to overwrite the previous value.
Regards,
Brady
On 23/11/16 10:48, Manuel Buil wrote:
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 pipeline. That pipeline is not aware of a
vxlan-gpe port.
Regards,
Manuel
From: Paraskevopoulos Georgios [mailto:[email protected]]
Sent: Wednesday, November 23, 2016 10:16 AM
To: Manuel Buil <[email protected]><mailto:[email protected]>;
Yang, Yi Y <[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: 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 extra NSH pop on the output of the last SF.
Cheers,
George
From: Manuel Buil [mailto:[email protected]]
Sent: Wednesday, November 23, 2016 10:34 AM
To: Yang, Yi Y
Cc: [email protected]<mailto:[email protected]>;
Georgios Paraskevopoulos
([email protected]<mailto:[email protected]>)
Subject: RE: 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 what actually happens. The
problem is that OVS confuses the port and sends it with port 6633 instead of
4789.
/Manuel
From: Yang, Yi Y [mailto:[email protected]]
Sent: Wednesday, November 23, 2016 1:21 AM
To: Manuel Buil <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
Georgios Paraskevopoulos
([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>
Subject: RE: 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 support this, right?
Classifier2 must have VxLAN-gpe port for this in compute2.
From: Manuel Buil [mailto:[email protected]]
Sent: Wednesday, November 23, 2016 1:12 AM
To: Yang, Yi Y <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
Georgios Paraskevopoulos
([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>
Subject: 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 that SF, the SFC
encapsulation is removed and the packet is sent to the netvirt pipeline. The
scenario that fails is the following: client and SF are in compute1, the server
is in compute2.
### PROBLEM ###
All the SFC process happens in one OVS because both classifier and SF are in
that OVS. Then the packet leaves SFC pipeline and gets into Netvirt pipeline
which egress the packet using the vxlan tunnel it has to connect to the
compute2. The problem is that instead of using udp port 4789 as it should, it
uses udp port 6633. Compute2 has no SFC service so there is no vxlan port
listening on udp port 6633 and thus the packet is dropped.
I captured the packet using ovs-dpctl and everything is correct except the
tp_dst which is 6633 even though it should be 4789:
recirc_id(0),nsh(nsi=254,nsp=3c,nsh_mdtype=1,nsh_np=3,nshc1=c0a80006,nshc2=12),tunnel(tun_id=0x3c,src=11.0.0.6,dst=10.20.0.11,vxlan(gpe(np=0x3c)),flags(-df+csum+key)),in_port(8),skb_mark(0),eth(src=fa:16:3e:6b:08:c7,dst=fa:16:3e:4a:be:0e),eth_type(0x0800),ipv4(dst=11.0.0.4/255.255.255.254,tos=0/0x3,frag=no),
packets:0, bytes:0, used:never,
actions:set(tunnel(tun_id=0x12,src=192.168.2.4,dst=192.168.2.3,ttl=64,tp_src=49676,tp_dst=6633,vxlan(gpe(np=0x4,flags=0)),flags(df|csum|key))),pop_nsh,4
These are the ports (you can see that it egresses on 4 ==> vxlan_sys_4789):
port 0: ovs-system (internal)
port 1: br-ex (internal)
port 2: p_aec4d661-0 (internal)
port 3: br-int (internal)
port 4: vxlan_sys_4789 (vxlan)
port 5: tapbbd70ea7-7b
port 6: tapd5cbb645-01
port 7: tap3f9a7479-51
port 8: vxlan_sys_6633 (vxlan)
If I sniff the packets, I can see that all the traffic coming from compute1 and
going to compute2 is sent through vxlan and udp port 4789, except for the
packets that traversed SFC, which are sent with port 6633:
16:30:45.508076 IP 192.168.2.4.60213 > 192.168.2.3.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 99: openflow:119801980855940
16:30:45.508288 IP 192.168.2.3.36551 > 192.168.2.4.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 97: openflow:93452943833469
16:30:46.356412 IP 192.168.2.4.52024 > 192.168.2.3.6633: VXLAN, flags [I]
(0x08), vni 18
IP 11.0.0.4.38652 > 11.0.0.5.http: Flags [S], seq 340357625, win 28200, options
[mss 1410,sackOK,TS val 561484 ecr 0,nop,wscale 7], length 0
16:30:46.356679 IP 192.168.2.3 > 192.168.2.4: ICMP 192.168.2.3 udp port 6633
unreachable, length 118
16:30:47.354970 IP 192.168.2.4.52024 > 192.168.2.3.6633: VXLAN, flags [I]
(0x08), vni 18
IP 11.0.0.4.38652 > 11.0.0.5.http: Flags [S], seq 340357625, win 28200, options
[mss 1410,sackOK,TS val 561734 ecr 0,nop,wscale 7], length 0
16:31:20.508294 IP 192.168.2.3.36551 > 192.168.2.4.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 97: openflow:93452943833469
16:31:20.509431 IP 192.168.2.4.60213 > 192.168.2.3.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 99: openflow:119801980855940
16:31:25.507641 IP 192.168.2.3.36551 > 192.168.2.4.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 97: openflow:93452943833469
16:31:25.507728 IP 192.168.2.4.60213 > 192.168.2.3.4789: VXLAN, flags [I]
(0x08), vni 0
LLDP, length 99: openflow:119801980855940
Can you investigate if this problem might be related to your NSH patch for OVS?
Perhaps packets that traverse the SFC pipeline have L4 port destination
hardcoded as 6633?
Thanks,
Manuel
_______________________________________________
sfc-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
