Dear all,
Regarding in-band management, I'll report next the observed behaviour
on a simple loop topology. It seems definitely not in-line with the
content documented in the DESIGN.txt file from the OvS 2.3.0 source
tree. However, it is the appropriate behaviour to prevent management
traffic storms as explained by the same text.
Context:
OS: Ubuntu 14.04.1 LTS (trusty)
OvS: 2.3.0 (locally compiled)
Emulator: CORE (not relevant)
Topology:
n1
-------(eth0)_OvS1_(eth1)----------------------(eth1)_OvS2_(eth0)-------
n2 (the OF controller)
|
|
(eth2)
(eth2)
\
/
\
/
`---------(eth2)_OvS3_(eth1)------´
|
(eth0)
|
|
n3
Observed behaviour summary:
All OvS switches are programmed with a management IP and set up
with the IP address of the controller (hosted by node n2). Both IP
addresses belong to the same IP network. OvS2 connects to the
controller since it has a direct physical link to it (both are L1
neighbors) and the local installed flow entries. Default installed
flow rules (at OvS2), however, prevent the remaining switches (not
directly connected to the controller) to reach the controller (all
in-transit frames/packets are dropped by all the OvS switches).
Connectivity of OvS1 and OvS3 depends solely from the subsequent flows
installed by the controller at the OvS2 switch. In this way the
connectivity between the OvS switches and the controller is expected
to evolve progressively from the controller's nearest switches to the
farthest ones. This is the approach to prevent traffic storms that can
otherwise occur (check DESIGN.txt for further details).
Is it the case to turn the DESIGN.txt file more clear/correct?
" ... - Between Switch and Remote. This switch is between another
switch and the remote, and we want to allow the other switch's traffic
through. This uses rules (d), (e), (h), and (i). It uses (b) and (c)
indirectly in order to know the MAC address for rules (d) and (e)."
Best regards,
LS
On Wed, Nov 26, 2014 at 12:50 PM, Luís Santos
<[email protected]> wrote:
>
> Dear all,
>
> I have the following very basic topology:
>
> ovs1 ---- ovs2 ---- controller.
>
> According to the DESIGN.txt file (from the OvS source tree), it seems that
> the OvS switch is able to handle such scenario regarding the "in-band
> management" needs:
> " ... - Between Switch and Remote. This switch is between another switch
> and the remote, and we want to allow the other switch's traffic through.
> This uses rules (d), (e), (h), and (i). It uses (b) and (c) indirectly in
> order to know the MAC address for rules (d) and (e). Note that DHCP for the
> other switch will not work unless an OpenFlow controller explicitly lets this
> switch pass the traffic.
> "
>
> However what I'm being observing is a different behavior. After programming
> ovs2 with the controller's IP, this switch presents the following flow
> entries (that I sort by priority and number for reference):
> 1) duration=3s, n_packets=3, n_bytes=162,
> priority=180008,tcp,nw_src=10.0.0.12,tp_src=6633,actions=NORMAL
> 2) duration=3s, n_packets=3, n_bytes=222,
> priority=180007,tcp,nw_dst=10.0.0.12,tp_dst=6633,actions=NORMAL
> 5) duration=3s, n_packets=0, n_bytes=0,
> priority=180006,arp,arp_spa=10.0.0.12,arp_op=1,actions=NORMAL
> 8) duration=3s, n_packets=0, n_bytes=0,
> priority=180005,arp,arp_tpa=10.0.0.12,arp_op=2,actions=NORMAL
> 6) duration=2s, n_packets=0, n_bytes=0,
> priority=180004,arp,dl_src=00:00:00:aa:00:02,arp_op=1,actions=NORMAL
> 4) duration=2s, n_packets=0, n_bytes=0,
> priority=180003,arp,dl_dst=00:00:00:aa:00:02,arp_op=2,actions=NORMAL
> 7) duration=3s, n_packets=1, n_bytes=42,
> priority=180002,arp,dl_src=00:00:00:aa:00:03,arp_op=1,actions=NORMAL
> 3) duration=3s, n_packets=1, n_bytes=42,
> priority=180001,arp,dl_dst=00:00:00:aa:00:03,arp_op=2,actions=NORMAL
> 9) duration=3s, n_packets=0, n_bytes=0,
> priority=180000,udp,in_port=LOCAL,dl_src=00:00:00:aa:00:03,tp_src=68,
> tp_dst=67,actions=NORMAL
>
> After that I program ovs1 with the same controller's IP address ovs2 is
> using. I capture ARP.Requests sent by ovs1 and reaching ovs2. OvS2 however is
> not forwarding them. Is it the expected behavior? It seems that the
> ARP.Request sent by ovs1 (looking for the MAC of the controller 10.0.0.12)
> should match flow entry 8 but the packet counter of this flow entry remains
> zero. After more experiments I found out that such traffic (ARP.Req) is
> matching the following entry:
> table_id=254, duration=1409s, n_packets=205, n_bytes=17092,
> priority=0,reg0=0x2,actions=drop
>
> Is this an OvS bug? Help me understanding this behavior, please. Where are
> the table 254 usage documented?
>
> Best regards,
> LS
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
