openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #23358
Re: openflow FLOOD data can not go through br-int to br-tun
It seems OK after I set controller for both br-tun and br-int. but
floodlight official installation only set br-int's controller, am I correct?
On Tue, May 7, 2013 at 2:33 PM, Liu Wenmao <marvelliu@xxxxxxxxx> wrote:
> hi all:
>
> I have set up quantum+floodlight, there are a compute node and a
> controller, so I create a VM in the compute node, but the VM(100.0.0.4) can
> not ping its gateway(100.0.0.1) in the controller node.
>
> When the VM send a ARP request to OVS of the compute node, a packet_in
> request is sent to the controller, then the controller send a packet_out
> response to the OVS, telling it to flood the ARP request.
>
> I run tcpdump at both br-int and br-tun interface, packets are captured at
> br-int, but no packets are captured at br-tun:
>
> root@node1:/var/log/openvswitch# tcpdump -i br-int -nn
> tcpdump: WARNING: br-int: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on br-int, link-type EN10MB (Ethernet), capture size 65535 bytes
> 14:26:45.485978 ARP, Request who-has 100.0.0.1 tell 100.0.0.4, length 28
> 14:26:46.482442 ARP, Request who-has 100.0.0.1 tell 100.0.0.4, length 28
> 14:26:47.482416 ARP, Request who-has 100.0.0.1 tell 100.0.0.4, length 28
> ^C
> 3 packets captured
> 3 packets received by filter
> 0 packets dropped by kernel
> root@node1:/var/log/openvswitch# tcpdump -i br-tun -nn
> tcpdump: WARNING: br-tun: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on br-tun, link-type EN10MB (Ethernet), capture size 65535 bytes
> ^C
> 0 packets captured
> 0 packets received by filter
> 0 packets dropped by kernel
>
> root@node1:/var/log/openvswitch# ovs-ofctl snoop br-int
> OFPT_PACKET_IN (xid=0x0): total_len=42 in_port=6 data_len=42
> buffer=0x0000044d
> priority0:tunnel0:in_port0006:tci(0)
> macfa:16:3e:9f:5b:2c->ff:ff:ff:ff:ff:ff type0806 proto1 tos0 ttl0
> ip100.0.0.4->100.0.0.1 arp_hafa:16:3e:9f:5b:2c->00:00:00:00:00:00
> fa:16:3e:9f:5b:2c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42:
> Request who-has 100.0.0.1 tell 100.0.0.4, length 28
> OFPT_PACKET_OUT (xid=0x0): in_port=6 actions_len=8 actions=FLOOD
> data_len=42
> fa:16:3e:9f:5b:2c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42:
> Request who-has 100.0.0.1 tell 100.0.0.4, length 28
>
> I guess it is because the gateway is on another node, so ARP request
> should go through br-int->br-tun->eth2[compute node
> side]----------------------> [controller side]eth2->br-tun->br-int, but the
> ARP request seems to be blocked between br-int and br-tun.
>
> I don't know why the ARP request is not sent to br-tun. it seems that ARP
> request is sent to normal port of the OVS because VM 100.0.0.4 can ping
> other VMs(100.0.0.2) on the same OVS.
>
>
>
>
> root@node1:/var/log/openvswitch# ovs-vsctl show
> afaf59ee-48cc-4f5b-9a1d-4311b509a6c5
> *Bridge br-int*
> Controller "tcp:30.0.0.1:6633"
> is_connected: true
> Port "qvoe06ea8d8-d7"
> tag: 1
> Interface "qvoe06ea8d8-d7"
> Port "qvoa96762cb-f3"
> tag: 4095
> Interface "qvoa96762cb-f3"
> Port "qvo38f23ca0-59"
> tag: 1
> Interface "qvo38f23ca0-59"
> Port "qvofc3fe9ed-fb"
> tag: 4095
> Interface "qvofc3fe9ed-fb"
> Port br-int
> Interface br-int
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "eth3"
> Interface "eth3"
> Port "qvo1021fd99-eb"
> tag: 4095
> Interface "qvo1021fd99-eb"
> Port "qvo329db52d-81"
> tag: 4095
> Interface "qvo329db52d-81"
> Bridge "qbre06ea8d8-d7"
> Port "qbre06ea8d8-d7"
> Interface "qbre06ea8d8-d7"
> type: internal
> Port "qvbe06ea8d8-d7"
> Interface "qvbe06ea8d8-d7"
> Port "tape06ea8d8-d7"
> Interface "tape06ea8d8-d7"
> Bridge "qbr329db52d-81"
> Port "qbr329db52d-81"
> Interface "qbr329db52d-81"
> type: internal
> Port "qvb329db52d-81"
> Interface "qvb329db52d-81"
> Bridge "qbrc8ec86f4-3a"
> Port "qbrc8ec86f4-3a"
> Interface "qbrc8ec86f4-3a"
> type: internal
> Port "qvbc8ec86f4-3a"
> Interface "qvbc8ec86f4-3a"
> *Bridge br-tun*
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> Port br-tun
> Interface br-tun
> type: internal
> Port "gre-1"
> Interface "gre-1"
> type: gre
> options: {in_key=flow, out_key=flow, remote_ip="30.0.0.1"}
> Bridge "qbr31c6e35b-81"
> Port "qbr31c6e35b-81"
> Interface "qbr31c6e35b-81"
> type: internal
> Port "qvb31c6e35b-81"
> Interface "qvb31c6e35b-81"
> Bridge "qbr38f23ca0-59"
> Port "qbr38f23ca0-59"
> Interface "qbr38f23ca0-59"
> type: internal
> Port "tap38f23ca0-59"
> Interface "tap38f23ca0-59"
> Port "qvb38f23ca0-59"
> Interface "qvb38f23ca0-59"
> Bridge "qbr28117358-50"
> Port "qvb28117358-50"
> Interface "qvb28117358-50"
> Port "qbr28117358-50"
> Interface "qbr28117358-50"
> type: internal
> Bridge "qbr1021fd99-eb"
> Port "qvb1021fd99-eb"
> Interface "qvb1021fd99-eb"
> Port "qbr1021fd99-eb"
> Interface "qbr1021fd99-eb"
> type: internal
> Bridge "qbr054163ed-d1"
> Port "qvb054163ed-d1"
> Interface "qvb054163ed-d1"
> Port "qbr054163ed-d1"
> Interface "qbr054163ed-d1"
> type: internal
> Bridge "qbr5c2a6893-3c"
> Port "qvb5c2a6893-3c"
> Interface "qvb5c2a6893-3c"
> Port "qbr5c2a6893-3c"
> Interface "qbr5c2a6893-3c"
> type: internal
> Bridge "qbra96762cb-f3"
> Port "qvba96762cb-f3"
> Interface "qvba96762cb-f3"
> Port "qbra96762cb-f3"
> Interface "qbra96762cb-f3"
> type: internal
> Bridge "qbrfc3fe9ed-fb"
> Port "qvbfc3fe9ed-fb"
> Interface "qvbfc3fe9ed-fb"
> Port "qbrfc3fe9ed-fb"
> Interface "qbrfc3fe9ed-fb"
> type: internal
> Bridge "br0"
> Port "eth0"
> Interface "eth0"
> Port "br0"
> Interface "br0"
> type: internal
> Bridge "qbr42d41f3f-e8"
> Port "qbr42d41f3f-e8"
> Interface "qbr42d41f3f-e8"
> type: internal
> Port "qvb42d41f3f-e8"
> Interface "qvb42d41f3f-e8"
> Bridge "qbr4881e5be-2f"
> Port "qbr4881e5be-2f"
> Interface "qbr4881e5be-2f"
> type: internal
> Port "qvb4881e5be-2f"
> Interface "qvb4881e5be-2f"
> ovs_version: "1.4.0+build0"
>
References
