Closed izadorozhna closed 1 month ago
UPD: as you see from the issue history, the initial issue described that tg88 was not deployed. However, the other tests show that tg88 is deployed and sends the traffic. So, looks like tg88 is not configured correctly for the LLDP, ARP traffic. Thus, the issue description was changed.
Btw, when the LLDP, ARP traffic from tg88 is sent to the switch, it is detected successfully. But when it is sent to the flow, it is not detected on the flow devices.
This issue can be closed as the root cause of the LLDP/ARP absence has been found. Tg88 works properly, but the created flow has an incorrect port number(the port number was the port number of the first tg on the 08_ switch). Due to the logic of selection of flow_tg_port, the first tg_port is selected on the switch, that's why a flow was created with port = tg8_port => absence of LLDP/ARP.
Steps to reproduce:
topology.yaml
has 2 traffgens forofsw8
:Expected result:
Both traffgens of switch 8 are working fine including sending LLDP and ARP traffic.
Actual result:
When the lab is deployed with 2 traffgens for 8th switch as shown in step 2, tg88 was not working in fact for LLDP, APR traffic. When the test selects tg88 traffgen, the traffic is sent using the API requests (i.e. HTTP PUT request to \<address>:8288/api/1/traffgen/tg88/address/fbc7ecb8-121b-11ef-86ee-0242ac110002/arp), but the flow connected devices is not detected in fact. So it seems like only the first traffgen in the list of ofsw8-related traffgens is deployed and configured correctly for APR, LLDP devices.
Workaround:
Created #5664 PR as a workaround tp skip tg88 in this test case.