external IP address unavailable after openvswitch starts
I seem to be having an issue with getting openvswitch configured properly. I am able to setup the OVS bridges br-tun and br-int with no issue and I can ping both the local IP (10.0.2.22) and the other vxlan endpoint (10.0.2.35) with no issue. However once I start the agent the IPs stop responding. The only way I can recover is to stop the agent and remove/readd br-tun.
When I start the agent the vxlan tunnel is created does not seem to work. The other end is a Centos 7.2 Liberty setup and I have successfully run another Centos 7.2 compute node using OVS and vxlan...
Here is the ovs-vsctl show:
C:\Users\Administrator>ovs-vsctl show
d35452eb-9055-4fa3-b027-272833e0e4bd
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "external.1"
Interface "external.1"
Port "vxlan-0a000223"
Interface "vxlan-0a000223"
type: vxlan
options: {df_default="true", dst_port="8472", in_key=flow, local_ip="10.0.2.22", out
_key=flow, remote_ip="10.0.2.35"}
Port internal
Interface internal
Bridge br-int
fail_mode: secure
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
I'm not sure how to continue to debug this...
Here is the OVS config:
Here is the OVS config on the server:
[DEFAULT]
bridge_mappings = public:public-vs1
verbose=true
debug=false
control_exchange=neutron
policy_file=C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\etc\policy.json
rpc_backend=neutron.openstack.common.rpc.impl_kombu
rabbit_host=controller
rabbit_port=5672
rabbit_userid=openstack
rabbit_password=kb2rgb66
logdir=D:\OpenStack\Log\
logfile=neutron-ovs-agent.log
[agent]
tunnel_types = vxlan
vxlan_udp_port = 8472
enable_metrics_collection=false
[SECURITYGROUP]
enable_security_group=true
[ovs]
local_ip = 10.0.2.22
tunnel_bridge = br-tun
integration_bridge = br-int
tenant_network_type = vxlan
enable_tunneling = true
Other OVS information;
The only flow getting packets is fropping them:
cookie=0xa4424c7dd109bf50, duration=58.055s, table=0, npackets=51, nbytes=3821, idle_age=0, priority=0 actions=drop
C:\Users\Administrator>ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:00007eb58589ab4cn_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(external.1): addr:00:00:00:00:00:00
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
2(internal): addr:00:00:00:00:00:00
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
3(patch-int): addr:02:9b:32:fb:4b:6a
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
4(vxlan-0a000223): addr:8a:27:a8:42:66:d0
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
5(vxlan-0a000224): addr:7e:29:aa:d4:1d:b6
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
LOCAL(br-tun): addr:00:00:00:00:00:00
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
C:\Users\Administrator>ovs-vsctl list-ports br-tun
external.1
internal
patch-int
vxlan-0a000223
vxlan-0a000224
C:\Users\Administrator>ovs-vsctl list-ports br-int
patch-tun
C:\Users ...
If I add a flow in table 0 at priority 1 or two with an action of NORMAL I am again able to ping the other endpoints. However, that prevents the packet from reaching table 10 which should be the VXLAN learning flow (or at least that is my understanding) I'm not sure what I am missing...