[j-nsp] [c-nsp] LACP between router VMs (James Bensley)

[Chris Burton]

This has been discussed a few times on this list and other forums. That 
being said, if you are looking to do this with Linux bridge you will 
need to modify the net/br_private.h header library to remove the mask 
restriction placed on using group_fwd_mask setting in /sys/class/net and 
recompile the kernel to allow it forward LACP BPDU's.

If you are looking to use Openvswitch you can do as Sergio mentioned and 
set the OVS bridge to allow forwarding of LACP BPDU's after you manually 
add each interface, but if you want to use the default vmx.sh script to 
bind the interfaces with OVS you will need to modify the 
config/vmx-junosdev.conf file and add in "use_ovs_transport: True" as a 
key, and depending on what version of OS you are running (I presume 
Ubuntu 16.04) you may also need to modify the sub-script that vmx.sh 
--bind-dev calls to prevent it from checking for the 
"openvswitch-datapath-source" package. I have only tested OVS 2.6 
(Ubuntu cloud repo) with version 16.1 of VMX, but unless the sub-scripts 
are different for earlier or later versions it should work (but it is 
unlikely to be supported since I do not see mention of using OVS in any 
of the official Juniper documents, and they likely will not support this 
even if OVS is supported as it breaks standards, same goes for LB mod's).

It should be understood though that you are breaking standards 
compatibility and could create massive problems on the network, so 
running this type of configuration outside of a lab environment should 
fall under the do not do it category. If you are going to do this 
production you should use physical NICs and SR-IOV with VF’s which 
eliminates the issue as was mentioned by James.

-C


On 11/09/2017 07:30 PM, Sergio D. wrote:
> You can use the following on ovs:
>
> ovs-vsctl set bridge <bridge-name> other-config:forward-bpdu=true
>
> according to the ovs-vsctl docs[0] this includes 01:80:c2:00:00:0x which is
> LACP.
>
> [0] http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html
>
>
>>     1. Re: [c-nsp] LACP between router VMs (James Bensley)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 8 Nov 2017 18:21:07 +0000
>> From: James Bensley <jwbensley at gmail.com>
>> To: adamv0025 at netconsultings.com
>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>,
>>          juniper-nsp <juniper-nsp at puck.nether.net>
>> Subject: Re: [j-nsp] [c-nsp] LACP between router VMs
>> Message-ID:
>>          <CAAWx_pVE_Ya4473u8=X0VLP_WfMRu_YWB1y-7uNSoesES3GJDw@
>> mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On 8 November 2017 at 16:30, Jeff Meyers <Jeff.Meyers at gmx.net> wrote:
>>> Hi Adam,
>>>
>>> LACP packets (so called slow packets in the linux kernel) are never
>>> forwarded by the bridging code. If it didn't change in the last ~2 years,
>>> you will have to hack your kernel in order to let them pass. It's
>> actually
>>> only a minor change in a couple of lines. The same applies btw to STP
>>> packets.
>>>
>>>
>>> Jeff
>>>
>>>
>>> Am 08.11.2017 um 17:09 schrieb adamv0025 at netconsultings.com:
>>>> Hi folks,
>>>>
>>>>
>>>> Slightly off topic but I'm gonna give it a shot anyways.
>>>>
>>>> Would anyone know how can I make linux bridges or better OVS to forward
>>>> LACP
>>>> PDUs instead of swallowing 'em?
>>>>
>>>> Basically "l2protocol forward lacp" equivalent.
>>>>
>>>> Couldn't find a single article on this and just can't believe I'm the
>>>> first
>>>> person that ever tried this.
>>>>
>>>> Aren't linux bridges or OVS MEF compliant :-) ?
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> adam
>> If you have NIC(s) that support SR-IOV in your hypervisor boxes then
>> binding a virtual-function from the PF to your VMs should allow the
>> LACP frames to pass.
>>
>> Cheers,
>> James,
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> juniper-nsp mailing list
>> juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> ------------------------------
>>
>> End of juniper-nsp Digest, Vol 180, Issue 8
>> *******************************************
>>
>
>