<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">Guys,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">

<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">Any thoughts on this? </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">

<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">Like I said, we're not sure if we, either, are doing too much unnecessary</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">

things stuff (or just working around it) or if there's a right (and hopefully simpler) way to do it.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">
<br>
</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">Any comments or suggestions on this will be very welcome. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">

<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(68,68,68)">Thank you.</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><span style="color:rgb(68,68,68);font-family:arial,helvetica,sans-serif;font-size:small">--</span><br>

</div><div><br></div><div><br></div></div></div><div class="gmail_quote">On Fri, Jun 7, 2013 at 5:51 PM, Bruno Oliveira ~lychinus <span dir="ltr"><<a href="mailto:brunnop.oliveira@gmail.com" target="_blank">brunnop.oliveira@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"(...)Do you have your vSwitch properly configured on your hyper-v host?(...)"<br>
<br>
>> I can't say for sure, Peter, but I think so...<br>
<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>
</blockquote></div><br></div></div>