I would dump the members of the IPv4c8238a74-1311-4700-9 set and make sure the expected IP addresses are in there.
ipset list IPv4c8238a74-1311-4700-9 On Tue, May 19, 2015 at 9:50 PM, Tom Walsh <[email protected]> wrote: > Yeah looking at the output of iptables clearly shows that the packets are > falling all the way through iptables and hitting the > neutron-openvswi-sg-fallback > > The relevant sections from iptables-save -c are: > > [23:1932] -A neutron-openvswi-FORWARD -m physdev --physdev-out > tapa6ad9dce-b0 --physdev-is-bridged -j neutron-openvswi-sg-chain > [23:1932] -A neutron-openvswi-sg-chain -m physdev --physdev-out > tapa6ad9dce-b0 --physdev-is-bridged -j neutron-openvswi-ia6ad9dce-b > [0:0] -A neutron-openvswi-sg-chain -m physdev --physdev-in tapa6ad9dce-b0 > --physdev-is-bridged -j neutron-openvswi-oa6ad9dce-b > [0:0] -A neutron-openvswi-ia6ad9dce-b -m state --state INVALID -j DROP > [0:0] -A neutron-openvswi-ia6ad9dce-b -m state --state RELATED,ESTABLISHED > -j RETURN > [0:0] -A neutron-openvswi-ia6ad9dce-b -s 162.220.48.123/32 -p udp -m udp > --sport 67 --dport 68 -j RETURN > [0:0] -A neutron-openvswi-ia6ad9dce-b -m set --match-set > IPv4c8238a74-1311-4700-9 src -j RETURN > [23:1932] -A neutron-openvswi-ia6ad9dce-b -j neutron-openvswi-sg-fallback > [23:1932] -A neutron-openvswi-sg-fallback -j DROP > > So it looks like the packets are coming in, and being sent to the > neutron-openvswi-ia6ad9dce-b table, and then missing all the rules there and > being pushed to the neutron-openvswi-sg-fallback table where they are being > dropped. This also shows that RELATED and ESTABLISHED packet states are > allowed, which also jives with what I was seeing in production. > > So this would seem to indicate a problem with my Security Groups. > > Upon checking the security groups in Nova (nova secgroup-list-rules default) > I am seeing the following: > > +-------------+-----------+---------+----------+--------------+ > | IP Protocol | From Port | To Port | IP Range | Source Group | > +-------------+-----------+---------+----------+--------------+ > | | | | | default | > | | | | | default | > +-------------+-----------+---------+----------+--------------+ > > Despite the fact that Horizon still shows the correct routes. > > So this looks to be a settings issue in the Security Group configuration. > Sadly I don't have a clue why the information I am seeing in Horizon is out > of sync with what I am seeing on the CLI. > > At this point I am glad to know where the problem lies, and how I can go > about correcting it so that it isn't a problem going forwards. > > Thanks for assisting in shining a light on what the problem is. > > Warm regards, > > Tom Walsh > ExpressHosting > http://expresshosting.net/ > > > On Tue, May 19, 2015 at 6:18 PM, Brian Haley <[email protected]> wrote: >> >> On 5/19/15 8:40 AM, Tom Walsh wrote: >>> >>> This is a new relatively new issue that has started occurring on our >>> OpenStack setup since we upgraded Juno (RDO based) to 2.2-1 (we had been >>> running Juno 2.0 before without issue). Our setup is: >> >> >> Since it started happening on an RDO upgrade my first suggestion is to >> contact Red Hat. >> >> I looked at your iptables output and didn't see anything out of the >> ordinary, although using 'iptables-save -c' might help show which rule is >> being hit to drop things (assuming it's the DROP rule in the fallback >> chain). >> >> Don't know of any upstream changes that would have broken this. >> >> -Brian > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : [email protected] > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Kevin Benton _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
