Kudos Gregory! I think this in-band problem in mininet is equivalent to Fermat's last theorem in math. Congrats again. BTW, it would be awesome if you can share the steps that you took in a blog post.
On Fri, Apr 4, 2014 at 5:19 AM, Gregory Gee <[email protected]> wrote: > > I figured out the problem I was having. It was a simple IP address > assignment issue. For the IP addresses that I gave the internal bridge > interfaces, I used a /32 prefix. I should have given them the same /8 > prefix that the host was using that had the controller. Once I set the > correct MASK, the controller started getting control messages. > > I got myself mixed up configuring the internal bridge interface like a > layer 3 loopback interface on a router instead of configuring it like the > IP address of an SVI/VLAN interface. I'm glad that's all that needed to be > done. I've finally been able to complete my experiment of running multiple > OVS on a host but each in their own network namespace and talking to an > inband controller all inside Mininet. > > Thanks for the push. > > Greg > > > On 03/04/2014 10:47 AM, Ben Pfaff wrote: > >> OVS uses flooding and MAC learning to find the controller. >> >> Yes, setting an IP is all that is needed. >> >> On Thu, Apr 03, 2014 at 08:58:40AM -0400, Gregory Gee wrote: >> >>> So if there is no extra configuration required, how does OVS know >>> which port to send the control traffic to the controller? Are you >>> saying that setting an IP on the internal bridge interface is all >>> that is required for inband control to work? >>> >>> Greg >>> >>> On 02/04/2014 5:02 PM, Ben Pfaff wrote: >>> >>>> OK. >>>> >>>> No extra flows are needed, so this is a configuration error or a bug. >>>> >>>> On Wed, Apr 02, 2014 at 02:46:56PM -0400, Gregory Gee wrote: >>>> >>>>> No, as you can see in the original email, the 11.0.0.1 and 11.0.0.2 >>>>> are on >>>>> the bridge internal interface. Instead of the interface being called >>>>> br0 >>>>> as in your example, they are called s1 and s2 in my setup. >>>>> >>>>> So I have the IP address set on the bridge internal interface as >>>>> needed. >>>>> What are the extra flows that I need to install that tells OVS which >>>>> port >>>>> to talk to the controller. My setup works fine if I have the >>>>> controller >>>>> out of band, but I can't figure out the extra steps to make the >>>>> controller >>>>> connection work if it is inband. >>>>> >>>>> Greg >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 12:06 AM, Ben Pfaff <[email protected]> wrote: >>>>> >>>>> On Tue, Apr 01, 2014 at 10:49:16PM -0400, Gregory Gee wrote: >>>>>> >>>>>>> I've been searching for quite a while and experimenting but there >>>>>>> must be an extra step I am missing to get a simple inband controller >>>>>>> example to work. Here is the simple example topology. >>>>>>> >>>>>>> s2---s1---controller >>>>>>> >>>>>>> s1 = 11.0.0.1/32 >>>>>>> s2 = 11.0.0.2/32 >>>>>>> controller = 11.0.0.100/8 >>>>>>> >>>>>>> An example ovs-vsctl show. >>>>>>> >>>>>>> Bridge "s1" >>>>>>> Controller "tcp:11.0.0.100:6633" >>>>>>> fail_mode: secure >>>>>>> Port "s1-eth1" >>>>>>> Interface "s1-eth1" >>>>>>> Port "s1-eth2" >>>>>>> Interface "s1-eth2" >>>>>>> Port "s1-eth12" >>>>>>> Interface "s1-eth12" >>>>>>> Port "s1" >>>>>>> Interface "s1" >>>>>>> type: internal >>>>>>> ovs_version: "1.10.0" >>>>>>> >>>>>>> # ovs-ofctl show s1 >>>>>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001 >>>>>>> n_tables:254, n_buffers:256 >>>>>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS >>>>>>> ARP_MATCH_IP >>>>>>> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC >>>>>>> SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST >>>>>>> ENQUEUE >>>>>>> 1(s1-eth1): addr:0a:a7:af:32:d9:7c >>>>>>> config: 0 >>>>>>> state: 0 >>>>>>> current: 10GB-FD COPPER >>>>>>> speed: 10000 Mbps now, 0 Mbps max >>>>>>> 2(s1-eth2): addr:06:57:97:21:9f:d5 >>>>>>> config: 0 >>>>>>> state: 0 >>>>>>> current: 10GB-FD COPPER >>>>>>> speed: 10000 Mbps now, 0 Mbps max >>>>>>> 3(s1-eth12): addr:26:96:80:3e:77:12 >>>>>>> config: 0 >>>>>>> state: 0 >>>>>>> current: 10GB-FD COPPER >>>>>>> speed: 10000 Mbps now, 0 Mbps max >>>>>>> LOCAL(s1): addr:36:21:10:be:02:43 >>>>>>> config: 0 >>>>>>> state: 0 >>>>>>> speed: 0 Mbps now, 0 Mbps max >>>>>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 >>>>>>> >>>>>>> # ifconfig s1 >>>>>>> s1 Link encap:Ethernet HWaddr 36:21:10:be:02:43 >>>>>>> inet addr:11.0.0.1 Bcast:255.255.255.255 Mask:0.0.0.0 >>>>>>> UP BROADCAST RUNNING MTU:1500 Metric:1 >>>>>>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>>>>>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >>>>>>> collisions:0 txqueuelen:0 >>>>>>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) >>>>>>> >>>>>> It looks like you put your IP address on a physical (or virtualized >>>>>> physical) interface. IP addresses need to be on internal interfaces. >>>>>> Please see the FAQ: >>>>>> >>>>>> Q: I created a bridge and added my Ethernet port to it, using commands >>>>>> like these: >>>>>> >>>>>> ovs-vsctl add-br br0 >>>>>> ovs-vsctl add-port br0 eth0 >>>>>> >>>>>> and as soon as I ran the "add-port" command I lost all >>>>>> connectivity >>>>>> through eth0. Help! >>>>>> >>>>>> A: A physical Ethernet device that is part of an Open vSwitch bridge >>>>>> should not have an IP address. If one does, then that IP address >>>>>> will not be fully functional. >>>>>> >>>>>> You can restore functionality by moving the IP address to an Open >>>>>> vSwitch "internal" device, such as the network device named after >>>>>> the bridge itself. For example, assuming that eth0's IP address >>>>>> is >>>>>> 192.168.128.5, you could run the commands below to fix up the >>>>>> situation: >>>>>> >>>>>> ifconfig eth0 0.0.0.0 >>>>>> ifconfig br0 192.168.128.5 >>>>>> >>>>>> (If your only connection to the machine running OVS is through the >>>>>> IP address in question, then you would want to run all of these >>>>>> commands on a single command line, or put them into a script.) If >>>>>> there were any additional routes assigned to eth0, then you would >>>>>> also want to use commands to adjust these routes to go through >>>>>> br0. >>>>>> >>>>>> If you use DHCP to obtain an IP address, then you should kill the >>>>>> DHCP client that was listening on the physical Ethernet interface >>>>>> (e.g. eth0) and start one listening on the internal interface >>>>>> (e.g. br0). You might still need to manually clear the IP address >>>>>> from the physical interface (e.g. with "ifconfig eth0 0.0.0.0"). >>>>>> >>>>>> There is no compelling reason why Open vSwitch must work this way. >>>>>> However, this is the way that the Linux kernel bridge module has >>>>>> always worked, so it's a model that those accustomed to Linux >>>>>> bridging are already used to. Also, the model that most people >>>>>> expect is not implementable without kernel changes on all the >>>>>> versions of Linux that Open vSwitch supports. >>>>>> >>>>>> By the way, this issue is not specific to physical Ethernet >>>>>> devices. It applies to all network devices except Open vswitch >>>>>> "internal" devices. >>>>>> >>>>>> > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
