Hi, tcpdump on a ovs bridges is not really working. The bridge is like a real switch, so what you need to do is to set up port mirroring [1] for all or a specific port. But although this is not working very well (to my experience).
So if you can't see any packets on br-tun with tcpdump, that working as expected. I would ask you to dump on your eth interface that has your tunnel IP (172.26.64.13) configured, to see if packets are going out encapsulated. On the remote node you could can do the same on its eth interface to check if vxlan encapsulated packets are entering the system. What you also could check is if the vxlan port (udp 4789) is open in your hosts firewalls. [1] http://openvswitch.org/pipermail/discuss/2012-December/008527.html -- Andreas (irc: scheuran) On Thu, 2015-02-26 at 12:17 -0800, Abhishek Chanda wrote: > Hi all, > > I am trying to run Juno Neutron in two boxes. One box runs the API > endpoints, the other one runs nova compute and neutron OVS agent. > After I boot up VMs, they do not get a reply for DHCP discover. I > noticed that the broadcasts reach br-int but are getting dropped after > that. Here is my setup: > > mngmt3:/opt/openstack # ovs-vsctl show > afc8ab2b-96b4-4363-b258-660efeb5f92f > Bridge br-tun > Port br-tun > Interface br-tun > type: internal > Port patch-int > Interface patch-int > type: patch > options: {peer=patch-tun} > Port "vxlan-ac1a400c" > Interface "vxlan-ac1a400c" > type: vxlan > options: {df_default="true", in_key=flow, > local_ip="172.26.64.13", out_key=flow, remote_ip="172.26.64.12"} > Bridge br-int > fail_mode: secure > Port int-br-ex > Interface int-br-ex > type: patch > options: {peer=phy-br-ex} > Port "qvo020cae33-fb" > Interface "qvo020cae33-fb" > Port br-int > Interface br-int > type: internal > Port patch-tun > Interface patch-tun > type: patch > options: {peer=patch-int} > Bridge br-ex > Port phy-br-ex > Interface phy-br-ex > type: patch > options: {peer=int-br-ex} > Port br-ex > Interface br-ex > type: internal > Port "eth0" > Interface "eth0" > ovs_version: "2.1.3" > > mngmt3:/opt/openstack # brctl show > bridge name bridge id STP enabled > interfaces > docker0 8000.56847afe9799 no > qbr020cae33-fb 8000.bea5fc15ea51 no > qvb020cae33-fb > > tap020cae33-fb > > mngmt3:/opt/openstack # ovs-ofctl dump-flows br-int > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=245697.535s, table=0, n_packets=25253, > n_bytes=8125454, idle_age=10, hard_age=65534, priority=1 > actions=NORMAL > cookie=0x0, duration=245696.905s, table=0, n_packets=59, > n_bytes=3540, idle_age=1680, hard_age=65534, priority=2,in_port=1 > actions=drop > cookie=0x0, duration=245697.516s, table=23, n_packets=0, n_bytes=0, > idle_age=65534, hard_age=65534, priority=0 actions=drop > > mngmt3:/opt/openstack # ovs-ofctl dump-flows br-tun > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=245702.144s, table=0, n_packets=2, n_bytes=180, > idle_age=65534, hard_age=65534, priority=0 actions=drop > cookie=0x0, duration=245702.152s, table=0, n_packets=25251, > n_bytes=8125274, idle_age=15, hard_age=65534, priority=1,in_port=1 > actions=resubmit(,2) > cookie=0x0, duration=245701.592s, table=0, n_packets=1, n_bytes=90, > idle_age=65534, hard_age=65534, priority=1,in_port=2 > actions=resubmit(,4) > cookie=0x0, duration=245702.127s, table=2, n_packets=25251, > n_bytes=8125274, idle_age=15, hard_age=65534, > priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 > actions=resubmit(,22) > cookie=0x0, duration=245702.136s, table=2, n_packets=0, n_bytes=0, > idle_age=65534, hard_age=65534, > priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 > actions=resubmit(,20) > cookie=0x0, duration=245702.118s, table=3, n_packets=0, n_bytes=0, > idle_age=65534, hard_age=65534, priority=0 actions=drop > cookie=0x0, duration=245702.110s, table=4, n_packets=1, n_bytes=90, > idle_age=65534, hard_age=65534, priority=0 actions=drop > cookie=0x0, duration=245702.101s, table=10, n_packets=0, n_bytes=0, > idle_age=65534, hard_age=65534, priority=1 > actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1 > cookie=0x0, duration=245702.093s, table=20, n_packets=0, n_bytes=0, > idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,22) > cookie=0x0, duration=245702.084s, table=22, n_packets=25251, > n_bytes=8125274, idle_age=15, hard_age=65534, priority=0 actions=drop > > Here is what I see: > 1. tcpdump on tap020cae33-fb, which is the VM's interface on the host, > shows outgoing DHCP broadcasts. > 2. Those also show up in qbr020cae33-fb, qvb020cae33-fb and br-int > 3. No traffic shows up in br-tun > > Since br-int and br-tun are connected via a patch port, shouldn't they > get identical traffic? How do I debug this? > > Thanks > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
