sdntrace_cp isn't detecting a loop when the outgoing interface is the same as the input interface
viniarck opened this issue · comments
sdntrace_cp isn't detecting a loop when the outgoing interface is the same as the input interface
I found this case when I was trying to explore some cases where a "loop" trace result type was expected.
How to reproduce
- You can use mininet with linear,3 topo:
mn --controller=remote,ip=127.0.0.1,port=6653 --switch=ovsk,protocols=OpenFlow13 --topo=linear,3
- Provision an EVC EPL to have a valid path with
mef_eline:
echo '{ "name": "epl", "service_level": 7, "dynamic_backup_path": true, "sb_priority": 5000, "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:1" } }' | http POST http://127.0.0.1:8181/api/kytos/mef_eline/v2/evc
- Wait for the EVC to get deployed, and confirm that ping works, and flows are as expected:
mininet> h1 ping h3
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.960 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.139 ms
^C
--- 10.0.0.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.139/0.549/0.960/0.410 ms
❯ sudo ovs-ofctl -O OpenFlow13 dump-flows s3
cookie=0xac00000000000003, duration=14.177s, 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=0xaab5853b27399041, duration=4.012s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=5000,in_port="s3-eth1" actions=push_vlan:0x88a8,set_field:4097->vlan_vid,output:"s3-e
th2"
cookie=0xaab5853b27399041, duration=4.011s, table=0, n_packets=1, n_bytes=74, send_flow_rem priority=5000,in_port="s3-eth2",dl_vlan=1 actions=pop_vlan,output:"s3-eth1"
cookie=0xab00000000000003, duration=17.231s, table=0, n_packets=5, n_bytes=210, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
- Now, install a higher priority flow that is expected to break mef_eline path looping the packet back to its origin using the same vlan (`"dl_vlan": 1 in this case):
❯ echo '{ "force": false, "flows": [ { "priority": 55000, "cookie": 100, "match": { "in_port": 2, "dl_vlan": 1 }, "actions": [ { "action_type": "output", "port": 2 }, {"action_type": "set_vlan", "vlan_id": 1 }] } ] }' | http POST http://localhost:8181/api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:03
- Confirm that indeed ping no longer works and the higher priority flow is in place:
mininet> h1 ping h3
^CPING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
--- 10.0.0.3 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1018ms
mininet>
❯ sudo ovs-ofctl -O OpenFlow13 dump-flows s3
cookie=0xaab5853b27399041, duration=1086.409s, table=0, n_packets=7, n_bytes=518, send_flow_rem priority=5000,in_port="s3-eth2",dl_vlan=1 actions=pop_vlan,output:"s3-eth1"
cookie=0x64, duration=987.810s, table=0, n_packets=8, n_bytes=564, send_flow_rem priority=55000,in_port="s3-eth2",dl_vlan=1 actions=output:"s3-eth2",set_field:4097->vlan_vid
cookie=0xac00000000000003, duration=1096.575s, 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=0xaab5853b27399041, duration=1086.410s, table=0, n_packets=9, n_bytes=630, send_flow_rem priority=5000,in_port="s3-eth1" actions=push_vlan:0x88a8,set_field:4097->vlan_vid,output:
"s3-eth2"
cookie=0xab00000000000003, duration=1099.629s, table=0, n_packets=365, n_bytes=15330, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
- Run a sdntrace request:
❯ echo '[ { "trace": { "switch": { "dpid": "00:00:00:00:00:00:00:01", "in_port": 1 }, "eth": { "dl_vlan": 105 } } }, { "trace": { "switch": { "dpid": "00:00:00:00:00:00:00:03", "in_port": 1 }, "eth": { "dl_vlan": 105 } } } ]' | http PUThttp://127.0.0.1:8181/api/amlight/sdntrace_cp/traces
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Content-Length: 941
Content-Type: application/json
Date: Thu, 09 Mar 2023 18:37:00 GMT
Server: Werkzeug/2.0.3 Python/3.9.15
{
"result": [
[
{
"dpid": "00:00:00:00:00:00:00:01",
"port": 1,
"time": "2023-03-09 15:37:00.006511",
"type": "starting",
"vlan": 105
},
{
"dpid": "00:00:00:00:00:00:00:02",
"port": 2,
"time": "2023-03-09 15:37:00.006544",
"type": "intermediary",
"vlan": 1
},
{
"dpid": "00:00:00:00:00:00:00:03",
"port": 2,
"time": "2023-03-09 15:37:00.006558",
"type": "intermediary",
"vlan": 1
},
{
"dpid": "00:00:00:00:00:00:00:02",
"port": 3,
"time": "2023-03-09 15:37:00.006568",
"type": "intermediary",
"vlan": 1
},
{
"dpid": "00:00:00:00:00:00:00:01",
"out": {
"port": 1,
"vlan": 105
},
"port": 2,
"time": "2023-03-09 15:37:00.006578",
"type": "last",
"vlan": 1
}
],
[
{
"dpid": "00:00:00:00:00:00:00:03",
"port": 1,
"time": "2023-03-09 15:37:00.006589",
"type": "starting",
"vlan": 105
},
{
"dpid": "00:00:00:00:00:00:00:02",
"port": 3,
"time": "2023-03-09 15:37:00.006598",
"type": "intermediary",
"vlan": 1
},
{
"dpid": "00:00:00:00:00:00:00:01",
"out": {
"port": 1,
"vlan": 105
},
"port": 2,
"time": "2023-03-09 15:37:00.006608",
"type": "last",
"vlan": 1
}
]
]
}
- Notice that from s1 to s3, the trace step is considered
"last", which is correct, but the"out"interface is the same as the incoming interface, so this should be a loop shouldn't it? Looking into the codehas_loop(trace_step, trace_result)is only consideringin_portwhich is correct in a looped node network graph, but then what if the packet is looped back to the same origin? I believe this should be considered a loop too.
{
"dpid": "00:00:00:00:00:00:00:01",
"out": {
"port": 1,
"vlan": 105
},
"port": 2,
"time": "2023-03-09 15:37:00.006578",
"type": "last",
"vlan": 1
}
cc'ing @gretelliz to confirm, could you double check this, Gretel?