<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi Bruno,</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
I just hit the same (or a very similar) issue doing a multinode deployment with RDO on CentOS 6.4 (OVS 1.10) while we had no problem until now using Ubuntu 12.04 (OVS 1.4).</div>
</span></div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Can you please provide some more details about the Linux OS you are using and your multinode configuration?</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
I tested it with flat and VLAN networks, so far it doesn't look like an Hyper-V related issue.</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Thanks,</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
</div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Alessandro</div>
</span></span><br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Jun 7, 2013, at 23:51 , Bruno Oliveira ~lychinus <<a href="mailto:brunnop.oliveira@gmail.com">brunnop.oliveira@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">"(...)Do you have your vSwitch properly configured on your hyper-v host?(...)"<br>
<br>
<blockquote type="cite">
<blockquote type="cite">I can't say for sure, Peter, but I think so...<br>
</blockquote>
</blockquote>
<br>
In troubleshooting we did (and are still doing) I can tell that<br>
regardless of the network model that we're using (FLAT or VLAN<br>
Network),<br>
the instance that is provisioned on Hyper-V (for some reason) can't<br>
reach the quantum-l3-agent "by default"<br>
(I said "default" because, we just managed to do it after a hard, long<br>
and boring troubleshoting,<br>
yet, we're not sure if that's how it should be done, indeed)<br>
<br>
Since it's not something quick to explain, I'll present the scenario:<br>
(I'm not sure if it might be a candidate for a fix in quantum-l3-agent,<br>
so quantum-devs might be interested too)<br>
<br>
<br>
Here's how our network interfaces turns out, in our network controller:<br>
<br>
==============================<br>
External bridge network<br>
==============================<br>
<br>
Bridge "br-eth1"<br>
Port "br-eth1"<br>
Interface "br-eth1"<br>
type: internal<br>
Port "eth1.11"<br>
Interface "eth1.11"<br>
Port "phy-br-eth1"<br>
Interface "phy-br-eth1"<br>
<br>
==============================<br>
Internal network<br>
==============================<br>
<br>
Bridge br-int<br>
Port "int-br-eth1"<br>
Interface "int-br-eth1"<br>
Port br-int<br>
Interface br-int<br>
type: internal<br>
Port "tapb610a695-46"<br>
tag: 1<br>
Interface "tapb610a695-46"<br>
type: internal<br>
Port "qr-ef10bef4-fa"<br>
tag: 1<br>
Interface "qr-ef10bef4-fa"<br>
type: internal<br>
<br>
==============================<br>
<br>
There's another iface named "br-ex" that we're using for floating_ips,<br>
but it has nothing to do with what we're doing right now, so I'm skipping it...<br>
<br>
<br>
************ So, for the hands-on ****************<br>
<br>
I know it may be a little bit hard to understand, but I'll do my best<br>
trying to explain:<br>
<br>
1) the running instance in Hyper-V, which is linked to Hyper-V vSwitch<br>
is actually<br>
communicating to bridge: "br-eth1" (that is in the network controller).<br>
<br>
NOTE: That's where the DHCP REQUEST (from the instance) lands<br>
<br>
<br>
2) The interface MAC Address, of that running instance on Hyper-V, is:<br>
fa:16:3e:95:95:e4. (we're gonna use it on later steps)<br>
Since DHCP is not fully working yet, we had to manually set an IP for<br>
that instance: "10.5.5.3"<br>
<br>
<br>
3) From that instance interface, the dhcp_broadcast should be forward -><br>
FROM interface "eth1.12" TO "phy-br-eth1"<br>
And FROM interface "phy-br-eth1" TO the bridge "br-int" *** THIS<br>
IS WHERE THE PACKETS ARE DROPPED ***.<br>
<br>
Check it out for the "actions:drop"<br>
---------------------------------------------------------------------------------------------<br>
root@osnetwork:~# ovs-dpctl dump-flows br-int |grep 10.5.5.3<br>
<br>
in_port(4),eth(src=fa:16:3e:f0:ac:8e,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.5.5.3,tip=10.5.5.1,op=1,sha=fa:16:3e:f0:ac:8e,tha=00:00:00:00:00:00),<br>
packets:20, bytes:1120, used:0.412s, actions:drop<br>
---------------------------------------------------------------------------------------------<br>
<br>
4) Finally, when the packet reaches the bridge "br-int", the<br>
DHCP_REQUEST should be forward to the<br>
dhcp_interface, that is: tapb610a695-46 *** WHICH IS NOT<br>
HAPPENING EITHER ***<br>
<br>
<br>
5) How to fix :: bridge br-eth1<br>
<br>
-------------------------------------------<br>
5.1. Getting to know the ifaces of 'br-eth1'<br>
-------------------------------------------<br>
root@osnetwork:~# ovs-ofctl show br-eth1<br>
<br>
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000e0db554e164b<br>
n_tables:255, n_buffers:256 features: capabilities:0xc7, actions:0xfff<br>
<br>
1(eth1.11): addr:e0:db:55:4e:16:4b<br>
config: 0<br>
state: 0<br>
current: 10GB-FD AUTO_NEG<br>
advertised: 1GB-FD 10GB-FD FIBER AUTO_NEG<br>
supported: 1GB-FD 10GB-FD FIBER AUTO_NEG<br>
<br>
3(phy-br-eth1): addr:26:9b:97:93:b9:70<br>
config: 0<br>
state: 0<br>
current: 10GB-FD COPPER<br>
<br>
LOCAL(br-eth1): addr:e0:db:55:4e:16:4b<br>
config: 0<br>
state: 0<br>
<br>
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0<br>
<br>
<br>
-------------------------------------------<br>
5.2. Adding flow rules to enable passing (instead of dropping)<br>
-------------------------------------------<br>
<br>
# the source mac_address (dl_src) is the from the interface of the<br>
# running instance on Hyper-V. This fix the DROP (only)<br>
<br>
root@osnetwork:~# ovs-ofctl add-flow br-eth1<br>
priority=10,in_port=3,dl_src=fa:16:3e:95:95:e4,actions=normal<br>
<br>
<br>
<br>
6) How to fix :: bridge br-int<br>
<br>
-------------------------------------------<br>
6.1. Getting to know the ifaces of 'br-int'<br>
-------------------------------------------<br>
<br>
root@osnetwork:~# ovs-ofctl show br-int<br>
<br>
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:000092976d64274d<br>
<br>
n_tables:255, n_buffers:256 features: capabilities:0xc7, actions:0xfff<br>
<br>
1(tapb610a695-46): addr:19:01:00:00:00:00<br>
config: PORT_DOWN<br>
state: LINK_DOWN<br>
<br>
4(int-br-eth1): addr:5a:56:e1:53:e9:90<br>
config: 0<br>
state: 0<br>
current: 10GB-FD COPPER<br>
<br>
5(qr-ef10bef4-fa): addr:19:01:00:00:00:00<br>
config: PORT_DOWN<br>
state: LINK_DOWN<br>
<br>
LOCAL(br-int): addr:92:97:6d:64:27:4d<br>
config: 0<br>
state: 0<br>
<br>
-------------------------------------------<br>
6.2. Adding flow rules to enable FORWARD<br>
FROM: interface int-br-eth1 (4)<br>
TO: interface tapb610a695-46 (1) -> dhcp_interface<br>
<br>
and the REVERSE_FORWARD: from (1) to (4)<br>
-------------------------------------------<br>
root@osnetwork:~# ovs-ofctl add-flow br-int<br>
priority=12,in_port=4,dl_src=fa:16:3e:f0:ac:8e,action=1,normal<br>
root@osnetwork:~# ovs-ofctl add-flow br-int<br>
priority=12,in_port=1,dl_dst=fa:16:3e:f0:ac:8e,action=4,normal<br>
<br>
<br>
==================<br>
Conclusion<br>
==================<br>
<br>
That way, and only *that way*, the Hyper-V instance is able to<br>
exchange ARP with the dhcp (network controller).<br>
<br>
Even though, it is functional, we're not sure if that's how it HAS to<br>
be done. May I have your thoughts on it?<br>
<br>
Should we really have to create those rules/actions in openVSwitch to<br>
make the instance (of hyper-v) to reach out<br>
DHCP ? It seems either bug or something is wierd in my configurations...<br>
<br>
May I have your opinions on it?<br>
<br>
<br>
We'd greatly appreciate your feedback. Thank you very much.<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</body>
</html>