Missed this response, sorry. Thanks Robin for the assistance and bringing this back near the top of my emails =)
On Sun, May 20, 2012 at 7:39 AM, Salman Malik <[email protected]> wrote: > 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? > > See Robin's response. I haven't done this myself, but in theory you can do many such things. It may be easier to reason about forwarding if you use only ovs constructs and flows. Perhaps take a look at patch ports, which can be used to link bridges. > > 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? > > Open vSwitch does not set any of these fields itself. It does not snoop incoming packets, or manage any state (the only exception that comes to mind is the NORMAL action). In most use cases an external controller or the hypervisor integration scripts will populate mac or iface-id fields, for use elsewhere. The fields are not reference-able in openflow flows directly, in any case. > > 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. > OK. If it works, do respond so that future readers know this was the correct response. > > > > > 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 unchanged > Routing 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]> > [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]>[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]>[email protected] > > Date: Fri, 18 May 2012 10:32:23 +0800 > > To: <[email protected]>[email protected] > > CC: <[email protected]>[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]> > [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> > 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]>[email protected] > > <http://openvswitch.org/mailman/listinfo/discuss> > http://openvswitch.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list > <[email protected]>[email protected] > <http://openvswitch.org/mailman/listinfo/discuss> > 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
