I ran below commands and can see these drops. do they point to a specific point where packets might be getting dropped ?
sudo /usr/local/bin/ovs-ofctl dump-ports br0 OFPST_PORT reply (xid=0x2): 2 ports port LOCAL: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=523, errs=0, coll=0 port 1: rx pkts=611, bytes=54876, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 sudo /usr/local/bin/ovs-dpctl show system@ovs-system: lookups: hit:0 missed:641 lost:0 flows: 0 masks: hit:91 total:0 hit/pkt:0.14 port 0: ovs-system (internal) port 1: br0 (internal) port 2: eth3 On Wed, Jul 20, 2016 at 6:07 PM, Ben Pfaff <b...@ovn.org> wrote: > No. > > On Wed, Jul 20, 2016 at 06:04:39PM -0500, chetandeep singh wrote: > > Hi Ben > > > > I have a primary eth port eth2 and secondary Ethernet port eth3 that does > > not have any ip assigned to the same. So machine does not get locked up. > > The issue is that adding secondary port makes packets to get dropped in > > bridge . Any ideas why ? > > > > On Wednesday, July 20, 2016, Ben Pfaff <b...@ovn.org> wrote: > > > > > On Wed, Jul 20, 2016 at 05:45:27PM -0500, chetandeep singh wrote: > > > > I am trying to run some basic setup with OVS like creating a bridge > and > > > > adding taps for VM's in the bridge and a secondary ethernet port and > then > > > > eventually put the machine on the network. What I see is that if I do > > > below > > > > commands and add secondary eth3 port on the machine in the ovs > bridge, I > > > > see that packets start getting dropped. If I do ifconfig eth3, I > dont see > > > > any drops. > > > > > > > > Any idea why this might be happening in this case ? > > > > > > > > ovs-vsctl add-br br0 > > > > ovs-vsctl add-port br0 eth3 > > > > > > > > ifconfig br0 > > > > br0 Link encap:Ethernet HWaddr 3C:A8:2A:0D:F9:31 > > > > BROADCAST PROMISC MULTICAST MTU:1500 Metric:1 > > > > RX packets:0 errors:0 dropped:29 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) > > > > > > ### 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. > > > > > > > > > -- > > " In financial markets, the majority is always wrong " > -- " In financial markets, the majority is always wrong "
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss