Re: [mpls-linux-devel] L2 VPLS thoughts

[Scott A. Y. <sy...@im...>]

James R. Leu wrote:
> First off, I think it is very cool that you are digging into the
> code and trying to get new stuff to work.  Thank you very much for
> the time you're putting in to this.
> 

I'm happy to be of assistance. You've got a good base of code to work with. It's time to push this
project ahead. :)

> On Wed, Mar 26, 2008 at 11:25:48AM -0400, Scott A. Yoder wrote:
>> James,
>>
>> I wanted to get your ideas on setting up a statically configured (not BGP signalled) layer 2 VPLS with Quagga.
>>
>> I see you've got some "xconnect vfi" commands in ldp_vty.c as placeholders and commented out l2cc_interface code. What
>> were your plans for these commands?
> 
> These commands were intended for EoMPLS (LDP) configuration.  There is nothing
> saying that it couldn't be extended to support a static mode and VPLS as well.
> 
>> Ultimately I'd like to get the inner label stack for the VPLS distributed via BGP but probably should start with static
>> configuration.
> 
> This is probably a good approach.  There are many issues that need
> to be resolved still, like how to determine when and how to configure
> a label stack in the forwarding plane, and how to build the L2 "stuff" like
> bridges and what not.  Not to mention the work you're doing below.
> 

After reviewing other Cisco configurations I think I have a better understanding of what the commands should be doing.
The "l2 vfi" and "xconnect vfi" Cisco commands do the magic. You've already got the command primitives in the ldp_vty.c file.
I think the only big thing we are missing pseudowire negotiation using LDP as per RFC 4762.

Consider the following Cisco configuration:

PE1: 5.5.5.1/32
PE2: 5.5.5.2/32
PE3: 5.5.5.3/32

PE1 config:

  l2 vfi PE1-VPLS-A manual
    vpn id 100
    neighbor 5.5.5.2 encapsulation mpls
    neighbor 5.5.5.3 encapsulation mpls
  !
  interface loopback 0
    ip address 5.5.5.1 255.255.255.255
  !
  interface fastethernet0/0
    no ip address
    xconnect vfi PE1-VPLS-A
  !


I think I can see how to implement these commands following my mpls tunnel bridging scripts to create point-to-point and multipoint L2VPNs:

The "vpn id 100" command would create the base bridge group for the specified vpn id, say vfi100.

The "neighbor" commands would do the following:
  1) Set up a targeted LDP session to each neighbor.
  2) Create a pseudowire to each neighbor.
  3) Send an LDP label mapping message to signal the exchange of pseudowire demultiplexors as per RFC 4762 section 6.1.
  4) Upon receipt of an LDP label mapping message for this PW create a new ILM which looks like "proto packet instructions set-rx-if vfi100n1"

Pseudowire procedures
  1) Add a new PW nhlfe with an instruction to forward to the nhlfe for the neighbor.
  2) Create an mpls tunnel interface, say vfi100n1, using the new PW nhlfe
  3) Add the tunnel interface to the vfi100 bridge group with a horizon id value set to the vpn id
  4) If the outbound LSP changes the tunnel's nhlfe key must change also.
  5) If the inbound LSP changes the ILM must be updated to reflect the new label.

The "xconnect vfi" command would add the specified customer-facing interface to the vfi100 bridge group with no horizon value.


The neat thing about this approach is it makes BGP autodiscovery easy.

The "l2 vfi WORD autodiscovery" will create the bridge group. The "xconnect vfi" command will add the specified interface to the bridge group and will
cause BGPd to send a VPLS NLRI message for the new VPLS.

Upon receipt of a VPLS BGP NLRI for a VPLS ID we already have configured we can add a pseudowire to each of the new neighbors specified in the
message. We also create the ILM to send inbound traffic to the PW interface.


To do a quick test I can forgo the RFC 4762 signalling and assume a 1:1 mapping of VPLS ID to label.

>> Just as an fyi I was able to set up a multipoint L2 VPLS without LDP with a few minor kernel mods and mpls-linux patches.
>> I did a simple split-horizon patch to the Linux bridging module and added an option to the mpls tunnel code to set the
>> interface type to ethernet for bridging support. I wanted to use the virtual MPLS tunnel interface so the normal Linux
>> bridging code would function correctly. Using ebtables to send frames to the bridge works fine for a 1-1 tunnel but
>> doesn't allow for proper MAC learning in a multipoint VPLS setup.
> 
> <snip>
> 
> I would very much like to add the "interface type" support that you've
> implemented.  You can post the patch to sourceforge.  Please notify
> me when its been posted.
> 

I'll get that posted soon. I spent a lot more time than I thought I would doing research for this e-mail.

>> Do you think we can use any of these techniques within Quagga/LDPD? I'm thinking we'll configure a targeted LDP session
>> to the remote LER and set up a tunnel interface to add the inner VPLS label to the dynamically allocated label added
>> by the targeted session.
> 
> The idea is that the neighbour configured in the "xconnect vfi" results
> in a targeted LDP session.
> 
>> Thanks,
>> Scott Yoder
>> Support Engineer
>> ImageStream Internet Solutions, Inc.
>> E-mail: sy...@im...
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> mpls-linux-devel mailing list
>> mpl...@li...
>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
> 


I also found a problem with my original VPLS script. The set-rx-if should have been on the inner label not the outer label. I've also found a simple
way to make it work with LDP. I created a new script to create a L2VPLS using a route lookup to the neighbor. It has no error checking and assumes LDP
has already established a LSP to the peer.

New script:

#!/bin/bash

PE2_IP="5.5.5.2"

function add_mpls()
{
key=`mpls $1 | grep key | cut -c 17-26`
echo $key
}

modprobe mplsbr
brctl addbr br0
brctl addif br0 eth1
ip -4 addr flush dev eth1
ip link set eth1 up
ip link set br0 up

# VPN 100 to PE2
key1=`ip route | grep $LER2_IP | cut -f 7 -d ' '`
key2=`add_mpls "nhlfe add key 0 instructions push gen 100 forward $key1"`
mpls tunnel add dev VPN100PE2 nhlfe $key2 type ethernet
ip link set VPN100PE2 up

brctl addif br0 VPN100PE2 sethorizon br0 VPN100PE2 1

# VPN1 inbnound
mpls labelspace set dev eth2 labelspace 0
mpls labelspace set dev VPN100PE2 labelspace 0
mpls ilm add label gen 100 labelspace 0 proto packet instructions set-rx-if VPN100PE2 pop deliver


Thanks,
Scott Yoder
ImageStream Internet Solutions, Inc.
E-mail: sy...@im...