[lxc-users] running quagga on linux containers

[durga]

Thank You Guido, that makes sense.



Cheers!
Durga


On Sat, Nov 29, 2014 at 5:57 AM, Guido Jäkel <G.Jaekel at dnb.de> wrote:

> Dear Durga,
>
> it's a "implementation feature" of the Linux software bridge device that
> it don't have it's own MAC but *always* use the same MAC as one attached
> device. This used one will be the one with the lowest value and will
> change, if this device will deleted from the bridge.
>
> This may interrupt traffic to outerworld in the common case, where the
> bridge is connected to some real NIC and a couple of veth's used LXC or
> other kind of virtualisation if the MAC of the real NIC isn't the lowest
> one. Because if this don't hold, the outerside switch may see and have to
> learn a new MAC if the veth with the lowest MAC is dropped because it's
> container is stopped.
>
> Said that, it's a common practice here to use a "private MAC range" for
> the attached veth's starting with a high-value prefix like
> 00:50:c2:xx:yy:zz, which is higher than common vendor prefixes.
>
> With this explanation you'll understand for sure what had happen in your
> setup using one and two pairs of veths.
>
> greetings
>
> Guido
>
>
> On 12.11.2014 12:21, durga wrote:
> > Hello again,
> >
> > I think I figured out the issue.
> > lxcbr0 and one of the lxc containers seem to assuming same mac address,
> > thus during the database exchange stage(which is unicast with duplicated
> > mac address) , the lxcbr0 which has assumed the destination mac address
> > simply drops the DB description request OSPF packet, thus leaving the
> OSPF
> > neighbour establishment stage incomplete.
> >
> > When a secondary interface is configured, the mac address don't overlap ,
> > hence the multicast and following unicast packets get transmitted as in
> > normal multiple access networks.
> >
> >
> > Cheers!
> > Durga
> >
> >
> > On Wed, Nov 12, 2014 at 1:32 PM, durga <c.vijaya.durga at gmail.com> wrote:
> >
> >> hello All,
> >>
> >> I am kind of new to linux networking, so please bear with me.
> >> All I am trying to do is configure two linux containers  to run quagga
> >> routing engine.
> >>
> >> My inital setup was:
> >>
> >> lxc1 eth0(10.0.3.x) <—> lxcbr0(10.0.3.1) <—>(10.0.3.y)eth0 lxc2.
> >>
> >> both lxc1 and lxc2 are running quagga and ospf running on both the
> >> inerfaces.
> >> Since lxcbr0 is  a bridge - i was not expecting any issues. But it
> turned
> >> out otherwise.
> >>
> >> With help of wireshark, it turns out the multicast packets (neighbour
> >> relation -hello packets ) don't really cross over the bridge . Hence, no
> >> OSPF neighbour relation formed.
> >>
> >> As a trail and error method - I configured another pair of interfaces on
> >> the containers. so the second setup is
> >>
> >> lxc1 eth0(10.0.3.x) <—> lxcbr0(10.0.3.1) <—>(10.0.3.y)eth0 lxc2.
> >> …….eth1(8.8.8.x) <—>  lxcbr0(10.0.3.1) <—> (8.8.8.y) eth1 lxc2
> >>
> >> then , I ran ospf on these interfaces eth1 and neighbour relation was
> >> successful.
> >>
> >> I am now quite confused and trying to understand how lxcbr0 works. I
> dont
> >> want to believe that it has anything to do with IP addresses as bridge
> is a
> >> L2 device. Nor its an issue with multicast packets, otherwise OSPF
> should
> >> not work on any of the interfaces.
> >>
> >> Also, I have made no other updates to any of the configurations - except
> >> to change the config files of each lxc to reflect eth1.
> >>
> >> Any help or clarifications would help me progress onto next task. Its
> hard
> >> to progress unless i get this clarified.
> >>
> >>
> >>
> >> Cheers!
> >> Durga
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141129/e1f90fa2/attachment.html>