© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
@pasuder, sorry for the delay. for your questions:
- could you collect packet capture from instance, please?
It is exactly the same as I observed from tap-xxx.
- could you check bridge type of br-int, please?
I don't know how to check the bridge type, I just use devstack to build an openvswitch environment. If you know how to check the bridge type of openvswitch device, pls let me know.
But I believe it is a switch not a bridge, or else, every thing will be flooded, not just the frame from qr-xxx to sg-xxx, right?
- what is the connection between tapxxx and qr-xxx?
tap-xxx connects to a linuxbridge then connects to br-int as qvo-xxx device. It is a typical openvswitch connection with iptables as securitygroup implementation. I believe you know what I am talking about :)
The ports on br-int are listed in [1]. So tap-xxx and qr-xxx can be seen as being connected to br-int.
Actually, I have a temporary workaround for it. The root cause is that the mac table in br-int doesn't have record for sg-xxx. You can check it by
sudo ovs-appctl fdb/show br-int
The workaround is to add an openflow rule
sudo ovs-ofctl add-flow br-int "table=
So, br-int will have the chance the learn the mac address of sg-xxx device. And frame between qr-xxx and sg-xxx will be unicast.
[1] http://