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

Reply via email to