Just realized that I might have misunderstood your question.
The ovs-vsctl show output you provided is from the compute node, right?
On your node that hosts the API endpoints, is there also the
neutron-server and neutron-dhcp service running?
First you're talking about not getting a dhcp reply (which should be
unicast), but later on you're talking about outgoing dhcp broadcast,
which sounds more like a request. Does your request reach the dhcp and
only the reply does not come back properly? Or is the request not going
out of the compute node?
--
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
