[FDB] L2 traffic from PTF container couldn't reach DUT #585
Comments
|
Packets shall not be captured on the DUT. Since it is the data plane traffic, it won't be trapped and captured to the CPU. ICMP packets, on the contrary, will be captured and send up to CPU and that is why you could see the ICMP packets. Could you check the counters of the DUT and make sure that the DUT receives the packets? You might need to find out specifically on which step the packets get lost. Meanwhile, you will also need to check the NIC on your server to see if it supports our test scenario. |
|
Thank you stcheng, That was what I thought too. At least I can make sure the PTF container has the correct port mapping and Vlan tagging with the ICMP packets. I modified the PTF script to send 10-100 L2 packets but didn't see the same counter hits on both the Fanout switches and the SONiC DUT. So look like testbed server failed to send the L2 traffic out. My server NIC is Mellanox CX-4. Do you have any suggestion for my case? |
|
@lvphuc133 are you able to capture those packets on the server port which connected to the fanout? If yes and at the same time you can not see the counter change on the fanout trunk port, maybe you need to check the server, like upgrade the NIC firmware and MLNX_OFED, etc. |
|
I did more debugging and found the following:
FDB table on the DUT 10 1000 24:8A:07:92:7A:08 Ethernet32 Dynamic And the script also changed PTF ports' MAC addresses as following root@79fe7233672f:~# ifconfig | grep eth
But somehow I don't know yet this packet is never sent out of my server NIC. I couldn't capture it on the wire. I modified DMAC of the packet in the PTF script, if its DMAC is not in the PTF nic's MAC above then it will be able to be sent out of the server NIC and hit the DUT. I checked the OVS FDB table for all bridges and don't see any PTF MAC addresses $sudo ovs-vsctl list-br | xargs -n1 sudo ovs-appctl fdb/show I have no idea of where my L2 traffic get dropped so far Am I doing something wrong here? |
|
@lvphuc133 I encountered a similar issue on one of my testbeds with FDB test case, DUT already learned the MACs of the PTF container interfaces, but the followed verification packets cannot be sent out to the fanout and loopback from the src port, resulting in the FDB case failure. Finally, it resolved by upgrading the NIC firmware and MLNX_OFD. |
|
@keboliu |
|
@keboliu |
i added my Mellanox CX4 firmware below
|
|
@mooncat2 |
|
@keboliu |
|
The Test case has the Following steps • Step1 : Create a VLAN 1000 and Add Port(s) Ethernet1- Ethernet24 as Untagged VLAN Members. The L3 VLAN Interface is created with the L3 VLAN IP as 192.162.0.1/24 Where the test Case Fails ? The Test case fails in the Step 4. Deep Analysis of the Issue In Step 4, the PTF expects the packet as shown Below. If we closely examine the packet we see the packet is having a DA MAC = SA MAC which is wrong. This Mac entries are read by the test script from ARP table of the PTF server and filled in DA and SA fields. The test script expectation is send a Packet from one interface say eth0 , the packet will be switched back to eth1 by DUT and received in eth1 interface of PTF, since the MAC address of the eth1 is already learned in the DUT (in Step3) Since DA and SA are filled wrongly with the same MAC in the packet, the packet is dropped since DA and SA are pointing to same Ports after SA learning of the malformed packet (Source Port Suppression) |
Description
FDB test failed because L2 traffic from PTF container couldn't reach DUT.
Steps to reproduce the issue:
Run the test script and pause it before sending the L2 traffic
Send the traffic using PTF script manually
ptf --test-dir ptftests fdb_test.FdbTest --platform-dir ptftests --platform remote -t "testbed_type='t0';router_mac='a4:8c:db:b9:b3:00';fdb_info='/root/fdb_info.txt';vlan_ip='192.168.0.1'" --relax --debug info --log-file /tmp/fdb_test.FdbTest.2018-04-23-18:28:36.log --disable-vxlan --disable-geneve --disable-erspan --disable-mpls --disable-nvgre 2>&1
Capture traffic on the testbed server trunk port connected to the root fanout switch
#sudo tcpdump -ne -i ens1f0
18:23:07.978961 24:8a:07:92:7a:00 > a4:8c:db:b9:b3:00, ethertype 802.1Q (0x8100), length 64: vlan 1708, p 0, ethertype 0x1234,
18:23:07.978975 24:8a:07:92:7a:01 > a4:8c:db:b9:b3:00, ethertype 802.1Q (0x8100), length 64: vlan 1683, p 0, ethertype 0x1234,
18:23:07.978978 24:8a:07:92:7a:02 > a4:8c:db:b9:b3:00, ethertype 802.1Q (0x8100), length 64: vlan 1707, p 0, ethertype 0x1234,
18:23:07.978982 24:8a:07:92:7a:03 > a4:8c:db:b9:b3:00, ethertype 802.1Q (0x8100), length 64: vlan 1684, p 0, ethertype 0x1234,
a4:8c:db:b9:b3:00 is DUT MAC
24:8a:07:92:7a:xx is Server MACs (PTF MACs)
The L2 traffic sent out to test the L2 forwarding
18:23:09.190015 24:8a:07:92:7a:00 > 24:8a:07:92:7a:01, ethertype 802.1Q (0x8100), length 64: vlan 1681, p 0, ethertype 0x1234,
Capture traffic on the DUT for port Ethernet0
=> There is no packets captured ???? So the problem should be here. Traffic sent from PTF should reach DUT at this port but there is nothing found here.
Try to send another traffic
I tried to use a Python script to send ICMP packet to Vlan1000 interface (IP 192.168.0.1 MAC = DUT MAC) from PTF container.
And capture the traffic using tcpdump similar to step#4 and I can see the ICMP packet sent from PTF container.
Describe the results you received:
Don't see the L2 packet to DMAC 24:8a:07:92:7a:01 received on port eth1 (Vlan = 1682) on the PTF
Describe the results you expected:
L2 packet to DMAC 24:8a:07:92:7a:01 should arrive port eth1 of PTF (Vlan = 1682)
Can someone show me what should cause this problem?
Did I miss anything in test testbed or in script?
Thank you.
Additional information you deem important:
The text was updated successfully, but these errors were encountered: