[ovs-discuss] Packet drops in OVS Bridge

[chetandeep singh]

Hi Scott,

the idea with this is that with secondary port (no IP assigned)  part of
the bridge, and ip routes for all default packets set through primary port.
We can have VM's interact with rest of network by adding taps into the
bridge as well. I have been debugging why pings between host and VM are not
happening and can see packets getting dropped in the bridge itself.

On Wed, Jul 20, 2016 at 11:17 PM, Scott Lowe <scott.lowe at scottlowe.org>
wrote:

> Please see my response below.
>
>
> > On Jul 20, 2016, at 5:04 PM, chetandeep singh <
> chetandeep.singhh at gmail.com> 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 <blp at 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  ?
>
>
> Forgive me for what seems to be a simple question, but is it possible
> you're creating a bridging loop? You indicated that you have a primary port
> (eth2) and the drops come when you add a secondary port (eth3), so a
> bridging loop seems like a plausible explanation.
>
> Good luck!
>
> --
> Scott
>
>


-- 
" In financial markets, the majority is always wrong "
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160720/b65f9ede/attachment-0002.html>