[lxc-users] running quagga on linux containers

[Guido Jäkel]

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
>