Open Stack

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
<expresswebsys+openstack at gmail.com> 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 <brian.haley at hp.com> 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     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>



-- 
Kevin Benton