openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #20749
Re: How the linux bridge work in Quantum
Thanks all of guys.
I have found the root cause. It is related to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=877704 . The explanation is
below
When netns support is enabled, nat table is placed under a different
namespace which doesn't contain the bridge interface inside it. So the
value of net.bridge.bridge-nf-call-iptables doesn't affect the rule
matching.
On Thu, Feb 7, 2013 at 1:42 AM, Willard Dennis <willarddennis@xxxxxxxx>wrote:
> Hi Lei,
>
> Perhaps this article I wrote on the packetpushers.net blog can be helpful
> to you --
> http://packetpushers.net/openstack-quantum-network-implementation-in-linux/
>
> Best,
> Will
>
>
> *From:* Lei Zhang
> *Sent:* February 6, 2013 1:40 AM
> *To:* openstack@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: [Openstack] How the linux bridge work in Quantum
>
> I am following the steps from
> http://d.hatena.ne.jp/enakai00/20121118/1353226066
>
>
> On Wed, Feb 6, 2013 at 2:36 PM, Lei Zhang <zhang.lei.fly@xxxxxxxxx> wrote:
>
>> Directly, here is the issue I meet.
>>
>> I start a all-in-one openstack Folsom with Quantum network( using linux
>> bridge plugin)
>>
>> - First I can not ping outside of the host. Following is the network
>> setting. I think this should be work. But I can ping 10.10.0.1(gate way) in
>> the host
>> - Second, what's the usage for ns-1c37cab7-6b qg-82fef397-e1
>> qg-82fef397-e1, they are attached on nothing bridge.
>>
>> eth0: public Ethernet 10.10.0.0/24
>> eth1 <http://10.10.0.0/24eth1>: private Ethernet 192.168.101.0/24
>> eth2 <http://192.168.101.0/24eth2>: manage Ethernet 10.12.0.0/24
>>
>>
>> [root@all-in-one ~]# brctl show
>> bridge name bridge id STP enabled interfaces
>> brq3958ea96-9d 8000.080027f1f512 no eth0
>> tap82fef397-e1
>> brq399d07f4-8c 8000.080027b61c6f no eth1.101
>> tap1c37cab7-6b
>> tap21afddbd-80
>> tap629410b3-2d
>>
>> *Part of ip link*
>>
>> [root@all-in-one ~]# ip link
>>
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 08:00:27:f1:f5:12 brd ff:ff:ff:ff:ff:ff
>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 08:00:27:b6:1c:6f brd ff:ff:ff:ff:ff:ff
>> 10: eth1.101@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
>> link/ether 08:00:27:b6:1c:6f brd ff:ff:ff:ff:ff:ff
>>
>> * Part of ip addr*
>>
>> [root@all-in-one instance-00000005]# ip a
>>
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 08:00:27:f1:f5:12 brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::a00:27ff:fef1:f512/64 scope link
>> valid_lft forever preferred_lft forever
>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 08:00:27:b6:1c:6f brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::a00:27ff:feb6:1c6f/64 scope link
>> valid_lft forever preferred_lft forever
>> 8: qr-21afddbd-80: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 22:af:8e:70:bf:43 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.101.1/24 brd 192.168.101.255 scope global qr-21afddbd-80
>> inet6 fe80::20af:8eff:fe70:bf43/64 scope link
>> valid_lft forever preferred_lft forever
>> 10: eth1.101@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
>> link/ether 08:00:27:b6:1c:6f brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::a00:27ff:feb6:1c6f/64 scope link
>> valid_lft forever preferred_lft forever
>> 11: brq399d07f4-8c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>> link/ether 08:00:27:b6:1c:6f brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::a0ef:23ff:fe72:8085/64 scope link
>> valid_lft forever preferred_lft forever
>> 12: qg-82fef397-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 42:de:03:55:d6:96 brd ff:ff:ff:ff:ff:ff
>> inet 10.10.0.2/24 brd 10.10.0.255 scope global qg-82fef397-e1
>> inet6 fe80::40de:3ff:fe55:d696/64 scope link
>> valid_lft forever preferred_lft forever
>> 14: brq3958ea96-9d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>> link/ether 08:00:27:f1:f5:12 brd ff:ff:ff:ff:ff:ff
>> inet 10.10.0.200/24 brd 10.10.0.255 scope global brq3958ea96-9d
>> inet6 fe80::b4a2:c5ff:fe8c:3b1c/64 scope link
>> valid_lft forever preferred_lft forever
>> 15: ns-1c37cab7-6b: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>> link/ether 2e:0d:c2:31:23:23 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.101.2/24 brd 192.168.101.255 scope global ns-1c37cab7-6b
>> inet6 fe80::2c0d:c2ff:fe31:2323/64 scope link
>> valid_lft forever preferred_lft forever
>>
>> * ip route *
>>
>> [root@all-in-one instance-00000005]# ip r 192.168.101.0/24 dev ns-1c37cab7-6b proto kernel scope link src 192.168.101.2 192.168.101.0/24 dev qr-21afddbd-80 proto kernel scope link src 192.168.101.1 10.10.0.0/24 dev qg-82fef397-e1 proto kernel scope link src 10.10.0.2 10.10.0.0/24 dev brq3958ea96-9d proto kernel scope link src 10.10.0.200 10.12.0.0/24 dev eth2 proto kernel scope link src 10.12.0.2 169.254.0.0/16 dev eth1 scope link metric 1003
>> default via 10.10.0.1 dev brq3958ea96-9d metric 100
>>
>>
>>
>> On Wed, Feb 6, 2013 at 1:31 PM, Lei Zhang <zhang.lei.fly@xxxxxxxxx>wrote:
>>
>>> Hi all,
>>> I am learning the Quantum project. But I am confused about the whole
>>> architecture. Is there any article to explain how the package flow in
>>> the
>>> network model, which will help me to debug the network issue.
>>> For example, how the ping package flow from the VMs to the external
>>> internet?
>>>
>>> --
>>> Lei Zhang
>>>
>>> Blog: http://jeffrey4l.github.com
>>> twitter/weibo: @jeffrey4l
>>>
>>
>>
>>
>> --
>> Lei Zhang
>>
>> Blog: http://jeffrey4l.github.com
>> twitter/weibo: @jeffrey4l
>>
>
>
>
> --
> Lei Zhang
>
> Blog: http://jeffrey4l.github.com
> twitter/weibo: @jeffrey4l
>
--
Lei Zhang
Blog: http://jeffrey4l.github.com
twitter/weibo: @jeffrey4l
References
