hi list:
I recently set up an openstack project using a compute node(node1) and a
controller, VMs in compute nodes can ping each other, everything is OK. But
when I use floodlight as a controller, VMs suddenly cannot ping each other.
I use openvswitch-switch 1.9.90-1bsn7 which is built by BigSwitch for
floodlight, openstack quantum uses namespace.
I debuged floodlight, when VM1 pings VM2, if floodlight does not know how
to route the arp or ping packet, it send a FLOOD action to OVS, but there
are no flow in node1's OVS db:
root@node1:~# ovs-appctl bridge/dump-flows br-int
duration=46s, priority=180006, n_packets=0, n_bytes=0,
priority=180006,arp,arp_spa=30.0.0.1,arp_op=1,actions=NORMAL
duration=46s, priority=180000, n_packets=0, n_bytes=0,
priority=180000,udp,in_port=65534,dl_src=b2:b1:1c:05:98:45,tp_src=68,tp_dst=67,actions=NORMAL
duration=46s, priority=180008, n_packets=0, n_bytes=0,
priority=180008,tcp,nw_src=30.0.0.1,tp_src=6633,actions=NORMAL
duration=46s, priority=180007, n_packets=0, n_bytes=0,
priority=180007,tcp,nw_dst=30.0.0.1,tp_dst=6633,actions=NORMAL
duration=46s, priority=180005, n_packets=0, n_bytes=0,
priority=180005,arp,arp_tpa=30.0.0.1,arp_op=2,actions=NORMAL
duration=46s, priority=180003, n_packets=0, n_bytes=0,
priority=180003,arp,dl_dst=44:03:a7:74:a6:49,arp_op=2,actions=NORMAL
duration=46s, priority=180001, n_packets=0, n_bytes=0,
priority=180001,arp,dl_dst=b2:b1:1c:05:98:45,arp_op=2,actions=NORMAL
duration=46s, priority=180004, n_packets=0, n_bytes=0,
priority=180004,arp,dl_src=44:03:a7:74:a6:49,arp_op=1,actions=NORMAL
duration=46s, priority=180002, n_packets=0, n_bytes=0,
priority=180002,arp,dl_src=b2:b1:1c:05:98:45,arp_op=1,actions=NORMAL
table_id=254, duration=4265s, priority=0, n_packets=2613, n_bytes=519476,
priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=4265s, priority=0, n_packets=0, n_bytes=0,
priority=0,reg0=0x2,drop
root@node1:~# ovs-dpctl dump-flows br-int
in_port(38),eth(src=fa:16:3e:5c:fd:52,dst=fa:16:3e:f7:3d:5e),eth_type(0x0800),ipv4(src=100.0.0.6,dst=100.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0),
packets:1, bytes:98, used:0.312s,
actions:userspace(pid=4294953729,slow_path(controller))
I can capture packet at br-int, but no packets at eth2 or br-tun(packets
should go through eth2 in GRE tunnel br-tun, br-tun and br-int are
interconnected with port patch-int and patch-tun)
root@node1:~# 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
16:36:29.805357 ARP, Request who-has 100.0.0.1 tell 100.0.0.6, length 28
16:36:31.804091 ARP, Request who-has 100.0.0.1 tell 100.0.0.6, length 28
root@node1:~# 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
16:38:34.271453 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2,
1 group record(s), length 28
16:38:35.119489 IP6 fe80::c478:c5ff:fecf:f64a > ff02::2: ICMP6, router
solicitation, length 16
16:38:39.131454 IP6 fe80::c478:c5ff:fecf:f64a > ff02::2: ICMP6, router
solicitation, length 16
root@node1:~# tcpdump -i eth2 proto gre -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
How can I let the arp request packets go through br-tun to eth2, so that
the controller node can receive them?
root@node1:~# ovs-vsctl show
afaf59ee-48cc-4f5b-9a1d-4311b509a6c5
*Bridge br-int*
*Controller "tcp:30.0.0.1:6633"*
* is_connected: true*
Port "qvof3dc86e4-82"
tag: 1
Interface "qvof3dc86e4-82"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qvofc3fe9ed-fb"
tag: 4095
Interface "qvofc3fe9ed-fb"
Port br-int
Interface br-int
type: internal
Port "qvo8cb91d2a-7f"
tag: 1
Interface "qvo8cb91d2a-7f"
Port "qvo329db52d-81"
tag: 1
Interface "qvo329db52d-81"
Bridge "qbr329db52d-81"
Port "qbr329db52d-81"
Interface "qbr329db52d-81"
type: internal
Port "tap329db52d-81"
Interface "tap329db52d-81"
Port "qvb329db52d-81"
Interface "qvb329db52d-81"
Bridge "qbrc8ec86f4-3a"
Port "qbrc8ec86f4-3a"
Interface "qbrc8ec86f4-3a"
type: internal
Port "qvbc8ec86f4-3a"
Interface "qvbc8ec86f4-3a"
Bridge "qbrf3dc86e4-82"
Port "qbrf3dc86e4-82"
Interface "qbrf3dc86e4-82"
type: internal
Port "qvbf3dc86e4-82"
Interface "qvbf3dc86e4-82"
Port "tapf3dc86e4-82"
Interface "tapf3dc86e4-82"
Bridge "qbr31c6e35b-81"
Port "qbr31c6e35b-81"
Interface "qbr31c6e35b-81"
type: internal
Port "qvb31c6e35b-81"
Interface "qvb31c6e35b-81"
Bridge "qbr28117358-50"
Port "qvb28117358-50"
Interface "qvb28117358-50"
Port "qbr28117358-50"
Interface "qbr28117358-50"
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 "qbr8cb91d2a-7f"
Port "tap8cb91d2a-7f"
Interface "tap8cb91d2a-7f"
Port "qvb8cb91d2a-7f"
Interface "qvb8cb91d2a-7f"
Port "qbr8cb91d2a-7f"
Interface "qbr8cb91d2a-7f"
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 br-tun*
*Port "gre-1"*
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, remote_ip="30.0.0.1"}
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
.....
ovs_version: "1.9.0"
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
