Running OVS 2.3.0 on Ubuntu from a debian package.
I am creating two interfaces that are tunnels with duplicate configuration
as shown below and noticed that this causes some interesting behavior.
Everything appears to work but in reality, only one of the of-ports is able
to send traffic.
ovs-vsctl add-port br0 test1 -- set interface test1 type=gre
options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 options:key=1234
ovs-vsctl add-port br0 test2 -- set interface test2 type=gre
options:remote_ip=1.1.1.1 options:local_ip=2.2.2.2 options:key=1234
>From the ovs-vswitch.log it has detected the conflict, but allows things to
silently proceed and assigns them both an ofport.
2015-05-16T00:32:35.817Z|01079|bridge|INFO|bridge br0: added interface
test1 on port 10
2015-05-16T00:32:46.026Z|01086|tunnel|WARN|test2: attempting to add tunnel
port with same config as port 'test1' (2.2.2.2->1.1.1.1, key=0x4d2, dp
port=4, pkt mark=0)
2015-05-16T00:32:46.026Z|01087|bridge|INFO|bridge br0: added interface
test2 on port 11
Both ports end up getting marked up and have distinct configured flows
attempting to output to the ports. The flows are seeing the statistics
increment. But only which ever tunnel was added first actually sends out
packets on the wire and has statistics shown in the INTERFACE table or in
the "ovs-ofctl dump-ports" output, the second tunnel never sends or has
stats even though flows using it as the output action are incrementing.
Is this expected behavior? I can argue both ways, but would have though
that if the interface/port is going to be rendered useless, it would be
better to fail at install time rather than dumping a log and letting things
quietly proceed. Or was the intention to let both
tunnels/interface/ofports work and it's just a bug that only one works?
This is the ending output of the interface state before traffic is passed:
~# ovs-vsctl list INTERFACE test1
_uuid : f31b95ad-d8dd-43ba-a4a3-2fdbf9bd0627
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : []
external_ids : {}
ifindex : 0
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : []
link_state : up
mac : []
mac_in_use : "8e:cb:43:d5:77:ef"
mtu : []
name : "test1"
ofport : 10
ofport_request : []
options : {key="1234", local_ip="2.2.2.2", remote_ip="1.1.1.1"}
other_config : {}
statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
status : {tunnel_egress_iface="lan0",
tunnel_egress_iface_carrier=up}
type : gre
~# ovs-vsctl list INTERFACE test2
_uuid : dfc254e1-a4f2-41fe-b02b-0a0128af38c2
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : []
external_ids : {}
ifindex : 0
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : []
link_state : up
mac : []
mac_in_use : "ee:9d:36:18:6a:1d"
mtu : []
name : "test2"
ofport : 11
ofport_request : []
options : {key="1234", local_ip="2.2.2.2", remote_ip="1.1.1.1"}
other_config : {}
statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
status : {tunnel_egress_iface="lan0",
tunnel_egress_iface_carrier=up}
type : gre
~#
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
