Hello everybody,
I have a question regarding loop prevention when using OVS as OF-switch
in fail_mode "secure".
I built a simple leaf-spine-topology using 4 OVS 2.3.0 (2 leafs, 2
spines), each running in a seperate VM (Debian 8.2). Each leaf is
connected to both spines. This gives a physical loop (S1 --> L1 --> S2
--> L2 --> S1).
The OpenFlow controller (ONOS) is connected to S1.
Now: I configured fail_mode "secure" on all OVS to prevent a broadcast
storm because of the loop. When I start all 4 OVS but not yet the
controller, it works fine (no broadcast storm). But as soon as I connect
3 of the 4 switches (say, S1, L1 and L2) to the controller, I get a
broadcast storm:
S2 (not yet connected but sending ARP requests) sends an ARP request for
an IP (not necessarily the controller) - because of the hidden flows
(see below), the request is forwarded to "NORMAL" and thus flooded to
both uplinks (to L1 and L2). The ARP request is received on L1 (already
connected to controller) and forwarded to the controller. The controller
(ONOS with proxyarp app) floods the ARP request on all ports (except
incoming port) - so in this case the only port to flood is the uplink
port to S2 ond L2. So S2 receives it's own ARP request, and because of
the hidden flow (arp, dl_src=<switch_mac>,arp_op=1,actions=NORMAL) the
ARP request is flooded again to L1 --> LOOP! Analog for the request
received on L2.
For preventing such a loop: shouldn't the hidden flow match only for ARP
request from LOCAL port
(in_port=LOCAL,arp,dl_src=<switch_mac>,arp_op=1,actions=NORML)? With
this change, the ARP request receveid from L2 would be dropped and not
flooded again --> no loop. Only a new ARP request from the switch itself
(in_port LOCAL) would be flooded (or am I wrong?)
Here's the output for the hidden flows on S2 (switch_mac=08:00:27:0c:fe:a0):
root@dc01-s02:~# ovs-appctl bridge/dump-flows br0
duration=2940s, n_packets=0, n_bytes=0,
priority=180008,tcp,nw_src=10.0.0.41,tp_src=6633,actions=NORMAL
duration=2940s, n_packets=0, n_bytes=0,
priority=180006,arp,arp_spa=10.0.0.41,arp_op=1,actions=NORMAL
duration=2940s, n_packets=0, n_bytes=0,
priority=180007,tcp,nw_dst=10.0.0.41,tp_dst=6633,actions=NORMAL
duration=3444s, n_packets=0, n_bytes=0,
priority=180003,arp,dl_dst=02:56:54:5e:5c:00,arp_op=2,actions=NORMAL
duration=3444s, n_packets=0, n_bytes=0,
priority=180001,arp,dl_dst=08:00:27:0c:fe:a0,arp_op=2,actions=NORMAL
duration=2940s, n_packets=0, n_bytes=0,
priority=180005,arp,arp_tpa=10.0.0.41,arp_op=2,actions=NORMAL
duration=3444s, n_packets=885677, n_bytes=37198434,
priority=180002,arp,dl_src=08:00:27:0c:fe:a0,arp_op=1,actions=NORMAL
duration=3444s, n_packets=0, n_bytes=0,
priority=180004,arp,dl_src=02:56:54:5e:5c:00,arp_op=1,actions=NORMAL
duration=3444s, n_packets=0, n_bytes=0,
priority=180000,udp,in_port=LOCAL,dl_src=08:00:27:0c:fe:a0,tp_src=68,tp_dst=67,actions=NORMAL
table_id=254, duration=3444s, n_packets=0, n_bytes=0,
priority=1,actions=drop
table_id=254, duration=3444s, n_packets=0, n_bytes=0,
priority=0,reg0=0x3,actions=drop
table_id=254, duration=3444s, n_packets=4286, n_bytes=278950,
priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=3444s, n_packets=0, n_bytes=0,
priority=0,reg0=0x2,actions=drop
table_id=254, duration=3444s, n_packets=0, n_bytes=0,
priority=2,recirc_id=0,actions=resubmit(,0)
Many thanks in advance!
KR & Thanks,
Lukas
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
