[ovs-discuss] OVS 2.3.0: Loop prevention in fail_mode "secure"

Lukas Hubschmid lukas.hubschmid at pop.agri.ch
Sun Feb 21 14:05:43 UTC 2016


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 at 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




More information about the discuss mailing list