Incorrect trace when the EVC's UNI is a NNI

[Italo Valcy S Brito]

Hi,

If you have an EVC with a UNI as an NNI (valid use case when you have a peer SDN switch that supports hybrid mode, for instance), the sdntrace_cp ends up returning a wrong result. Consider the following example:

mn --topo=linear,4 --controller=remote,ip=127.0.0.1

Then create an EVC with the following request:

curl -X POST -H  'Content-type: application/json' http://127.0.0.1:8181/api/kytos/mef_eline/v2/evc/ -d '{"name":"test", "dynamic_backup_path":true,  "uni_a":{"interface_id":"00:00:00:00:00:00:00:01:1"},"uni_z":{"interface_id":"00:00:00:00:00:00:00:03:3"}}'

The flows on each switch are shown below:

# for sw in $(ovs-vsctl list-br); do echo "--> $sw"; ovs-ofctl dump-flows -O OpenFlow13 $sw; done
--> s1
 cookie=0x0, duration=1140.511s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:02 actions=CONTROLLER:65535
 cookie=0xaa10667ea4db0f46, duration=1004.835s, table=0, n_packets=2, n_bytes=140, send_flow_rem in_port="s1-eth1" actions=push_vlan:0x88a8,set_field:5755->vlan_vid,output:"s1-eth2"
 cookie=0xaa10667ea4db0f46, duration=1004.830s, table=0, n_packets=333, n_bytes=15318, send_flow_rem in_port="s1-eth2",dl_vlan=1659 actions=pop_vlan,output:"s1-eth1"
 cookie=0xab00000000000001, duration=1141.422s, table=0, n_packets=379, n_bytes=15918, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
--> s2
 cookie=0x0, duration=1140.582s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:01 actions=CONTROLLER:65535
 cookie=0x0, duration=1140.566s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:03 actions=CONTROLLER:65535
 cookie=0xaa10667ea4db0f46, duration=1005.101s, table=0, n_packets=2, n_bytes=148, send_flow_rem in_port="s2-eth2",dl_vlan=1659 actions=set_field:8082->vlan_vid,output:"s2-eth3"
 cookie=0xaa10667ea4db0f46, duration=1005.096s, table=0, n_packets=333, n_bytes=15318, send_flow_rem in_port="s2-eth3",dl_vlan=3986 actions=set_field:5755->vlan_vid,output:"s2-eth2"
 cookie=0xab00000000000002, duration=1141.462s, table=0, n_packets=758, n_bytes=31836, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
--> s3
 cookie=0x0, duration=1140.624s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:02 actions=CONTROLLER:65535
 cookie=0x0, duration=1140.598s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:04 actions=CONTROLLER:65535
 cookie=0xaa10667ea4db0f46, duration=1004.939s, table=0, n_packets=333, n_bytes=13986, send_flow_rem in_port="s3-eth3" actions=push_vlan:0x88a8,set_field:8082->vlan_vid,output:"s3-eth2"
 cookie=0xaa10667ea4db0f46, duration=1004.931s, table=0, n_packets=2, n_bytes=148, send_flow_rem in_port="s3-eth2",dl_vlan=3986 actions=pop_vlan,output:"s3-eth3"
 cookie=0xab00000000000003, duration=1141.457s, table=0, n_packets=425, n_bytes=17850, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
--> s4
 cookie=0x0, duration=1140.643s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:03 actions=CONTROLLER:65535
 cookie=0xab00000000000004, duration=1141.432s, table=0, n_packets=379, n_bytes=15918, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535

Then run a trace starting on sw1:1:

# curl -s -X PUT -H 'Content-type: application/json' http://127.0.0.1:8181/api/amlight/sdntrace_cp/trace -d '{"trace": {"switch": {"dpid": "00:00:00:00:00:00:00:01", "in_port": 1}}}' | jq -r
{
  "result": [
    {
      "dpid": "00:00:00:00:00:00:00:01",
      "port": 1,
      "time": "2022-11-10 14:19:13.629540",
      "type": "starting"
    },
    {
      "dpid": "00:00:00:00:00:00:00:02",
      "port": 2,
      "time": "2022-11-10 14:19:13.629616",
      "type": "trace",
      "vlan": 1659
    },
    {
      "dpid": "00:00:00:00:00:00:00:03",
      "port": 2,
      "time": "2022-11-10 14:19:13.629660",
      "type": "trace",
      "vlan": 3986
    },
    {
      "dpid": "00:00:00:00:00:00:00:04",
      "port": 2,
      "time": "2022-11-10 14:19:13.629704",
      "type": "trace"
    }
  ]
}

Expected result: the trace should stop on SW3

Actual result: as shown in the output above, the trace finishes on SW4

This is happening because when trace_step() returns None (the trace from SW3 to SW4), the trace function should stop immediately and return only the results so far but not that specific result (i.e., the trace_step returning None should trigger an immediate break on the trace loop - without append the current trace_step result).

The following patch seems to fix the issue:

diff --git a/main.py b/main.py
index 5649263..34909ec 100644
--- a/main.py
+++ b/main.py
@@ -123,7 +123,7 @@ class Main(KytosNApp):
                 else:
                     do_trace = False
             else:
-                do_trace = False
+                break
             trace_result.append(trace_step)
         self.traces.update({
             trace_id: trace_result