Thanks Reid, please find the inline comments. From: [email protected] Date: Sun, 20 May 2012 01:56:05 -0700 Subject: Re: [ovs-discuss] why vm can't ping host eth1 To: [email protected] CC: [email protected]; [email protected]
On Sat, May 19, 2012 at 3:42 PM, Salman Malik <[email protected]> wrote: Thanks a lot Reid. That was one awesome explanation. Few more questions: 1) In the first figure VMs can not communicate with the outside world (except using NAT) ? Yup. I'm not sure what NAT would mean in this context, all tap1/2 traffic will be going directly into br0, and br0 (as shown) has no way to get to the outside world. I was thinking if traffic from any VM could go through bridge interface and then traverse through the IP stack to go out to any ethX? 2) (Sorry if this is very basic stuff) Do the ports have any addresses (like MAC or IP) in either physical or real bridges/switches ? Could you clarify this one? I'm not sure what ports you're talking about, or what physical/real bridges/switches. An ovs 'port', as labeled in the ascii, has only those attributes described by 'ovs-vsctl list Port <port>' - which does not include a MAC or IP (perhaps also look at 'ovs-vsctl list Interface <iface>'). Here I was actually looking for the addresses of ports and if addressing differs in the software and hardware switch or not. And I have looked at the commands you mentioned. It turns out that both of the interface and port have a mac parameter which shows up as an empty list(at leas interfaces should have a MAC ?). Another observation related to this is one of the interface shows an external_id parameter having values of attached_mac, iface-id and status, what does this supposed to mean? 3) Robin said that uplink interface (in this case eth1) doesn't need an IP address. Is it true in every scenario or is it specific to this scenario( where IP stack would black hole the traffic if it is directed to eth1) Two sides of the same coin. Any physical interface attached to a bridge doesn't need IP configuration. That configuration will be ignored, and having any such configuration will generally be confusing and unhelpful (see previous comments on routing). If the physical interface is not attached to a bridge, then OVS will have no effect on it. Great, I would try removing IP configs from interfaces attached to the bridge. 4) What does it mean for a bridge to be standalone mode and what are the other possible modes? Just because I haven't had a good excuse for one of these before =) http://lmgtfy.com/?q=ovs+standalone+bridge&l=1 Here I am using 'standalone' to refer to an ovs bridge that does not have any custom forwarding flows in place, only a single NORMAL action which would cause it to act as a learning L2 switch. The other built-in mode is 'secure', which drops all traffic by default. Both modes may be augmented with flows - there are many resources documenting this, try the man page for 'ovs-ofctl', and look at 'add flow ___'. -Reid Thanks, Salman From: [email protected] Date: Sat, 19 May 2012 13:04:17 -0700 Subject: Re: [ovs-discuss] why vm can't ping host eth1 To: [email protected] CC: [email protected]; [email protected] I drew a little ascii art, does this clarify things? Hypervisor +--------------------------------------------------------+ | | +------ | -- iface <--------------------------------------+ | | | eth0 | | | | | | {network} | | | | | v | | | | +------ | -- iface <-------------------------------> {IP stack} | | eth1 | | ^ | | bridge br0 | | | +---+ | | | | | (internal) | | | | +-- port -- iface -------+ | | | | br0 br0 | | | | | | | | VM 1 | | | | +-----+ | | | +-- port -- iface -- | | | | | | tap1 tap1 +-----+ | | | | | | | | VM 2 | | | | +-----+ | | | +-- port -- iface -- | | | | | | tap2 tap2 +-----+ | | +---+ | | | +---------------------------------------------------------+ ******************************************* user@host$ ovs-vsctl add-port br1 eth1 * ****************************************** Hypervisor +--------------------------------------------------------+ | | +------ | -- iface <--------------------------------------+ | | | eth0 | | | | | | {network} | | | | | v | | | | +------ | -- iface <---+ X------------------------> {IP stack} | | eth1 | | | | ^ | | | bridge br1 | | | | +---+ | | | v | | (internal) | | | port --+ +-- port -- iface <------+ | | eth1 | | br1 br1 | | | | VM 1 | | | | +-----+ | | | +-- port -- iface -- | | | | | | tap1 tap1 +-----+ | | | | | | | | VM 2 | | | | +-----+ | | | +-- port -- iface -- | | | | | | tap2 tap2 +-----+ | | +---+ | | | +---------------------------------------------------------+ Non-Effects:IP configuration of eth1 is unchanged IP configuration of br0 is unchangedRouting table is unchanged Effects:Traffic routed to eth1 by the IP stack will be blackholed, since it is now attached to port eth1 Traffic routed to br0 by the IP stack has eth1 as a potential egress port Usual Correction:Move IP configuration of eth1 to br1 Remove IP configuration from eth1 Effects: If bridge br1 is in 'standalone' mode: - eth1's old IP is reachable from the network - VM 1 and VM 2 are reachable from the network (and would see eth1's traffic as well) On Fri, May 18, 2012 at 7:19 AM, Salman Malik <[email protected]> wrote: Thanks Robin and Reid. Its still a little fuzzy to me. Can you suggest some pointers which explains the bridge and related interfaces configuration ? I have worked for some time with ovs and integration bridge (that ovs manages) and I couldn't get my head around the routing mechanism e.g. doing an ifconfig would show all the interfaces like br100 and eth1. So is bridge an interface or an emulation of a real bridge ? (because I could see a HWaddress associated with this bridge/interface... and for some reason I think that each port of real bridge should have a MAC/IP associated with it, but I don't know). And when we add interface eth1 to br100 as a port, I understand that all the VM traffic would now go through eth1 (acting as an uplink, and conveying traffic from bridge to real switch and the VMs themselves can get the IP address in the same subnet as host itself, right?), but I can't visualize the scenario, given the output of ifconfig, brctl show or ovs-vsctl show/ ovs-ofctl show br100. Any explanation is much appreciated. Thanks, Salman CC: [email protected]; [email protected] From: [email protected] Subject: Re: [ovs-discuss] why vm can't ping host eth1 Date: Thu, 17 May 2012 22:31:08 -0700 To: [email protected] One thing I have seen in the past: if ethX has an ip as well as brX, it usually means that routing will try to send traffic out ethX. That traffic will be dropped, since brX is now the one hooked up to the ip stack (not ethX). On May 17, 2555 BE, at 20:49, Robin Wang <[email protected]> wrote: eth1, sorry for typo mistake. 在 2012-5-18 上午11:48，"Robin Wang" <[email protected]>写道： Because uplink doesn't need IP address. Here eth0 is used to connect two switches, one virtual, one physical. Thanks. 在 2012-5-18 上午10:49，"Salman Malik" <[email protected]>写道： Hi Dongsheng, Could you please tell me, why do we need to clear up the eth1 IP address? Does it interfere with the bridge ? If yes then how ? Bridge management is a bit unclear to me so thats why I am asking. Thanks, Salman > From: [email protected] > Date: Fri, 18 May 2012 10:32:23 +0800 > To: [email protected] > CC: [email protected] > Subject: Re: [ovs-discuss] why vm can't ping host eth1 > > On Thu, May 17, 2012 at 7:12 PM, yue wang <[email protected]> wrote: > > > > i think vm1/vm2/host are connected to each other by OVS, vm and host should > > communicate with each other. > > Sure, please see another thread: > http://openvswitch.org/pipermail/discuss/2012-May/007201.html > > You must clean ALL ip address on eth1, and set the ip address on the > corresponding bridge device, > say 'br1', here is a example: > > /usr/bin/ovs-vsctl add-br br1 > /usr/bin/ovs-vsctl add-port br1 eth1 > > /sbin/ip addr add ${IP} dev br1 > /sbin/ip link set br1 up > /sbin/ip address flush dev eth1 > /sbin/ip route replace default via ${GW} # if you have gateway > corresponding eth1 > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
