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]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
