[mpls-linux-devel] L2 VPLS thoughts

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

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?

Ultimately I'd like to get the inner label stack for the VPLS distributed via BGP but probably should start with static
configuration.


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.


Here's how I did it:

I did several different configurations. For the first config I used 2 LSRs as edge routers (LER1 and LER2) with one customer per LSR.

LER1 script:

#!/bin/bash

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

# Router interfaces
# eth0 -> VM administration interface
# eth1 -> connection to the customer
# eth2 -> connection to LER2 (192.168.15.2)

# Bridge has 2 interfaces
# eth1 -> connection to the customer
# ler1 -> MPLS tunnel to LER2. We use inner label 100 to identify this VPLS and outer label 1000

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

# Customer to LER1
key1=`add_mpls "nhlfe add key 0 instructions push gen 1000 nexthop eth2 ipv4 192.168.15.2"`
key2=`add_mpls "nhlfe add key 0 instructions push gen 100 forward $key1"`

# Create a 2 label MPLS tunnel to ler2 and set the tunnel interface type to ARPHRD_ETHERNET (ether_setup())
mpls tunnel add dev ler2 nhlfe $key2 type ethernet
ip link set ler2 up

# Set split-horizon value on this interface to 1 so frames received on this interface will not
# be forwarded to other interfaces with horizon value 1. This is only needed when we have more than
# one LSR tunnel bridged.
brctl addif br0 ler2 sethorizon br0 ler2 1

# Bridge inbnound to Customer
mpls labelspace set dev eth2 labelspace 0
mpls labelspace set dev ler2 labelspace 0

# Process MPLS packets from LER2 - pop the outer label and look at the inner label
mpls ilm add label gen 2000 labelspace 0 instructions set-rx-if ler2 pop peek

# Pass MPLS packets with label 100 to the mplsbr module which will set skb->dev to the ler2
# tunnel interface and send it to the Linux bridging code for receive processing. This allows
# proper MAC learning.
mpls ilm add label gen 100 labelspace 0 proto packet


LER2 script:

#!/bin/bash

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

# Router interfaces
# eth0 -> VM administration interface
# eth1 -> connection to the customer
# eth2 -> connection to LER1 (192.168.15.1)

# Bridge has 2 interfaces
# eth1 -> connection to the customer
# ler1 -> MPLS tunnel to LER1. We use inner label 100 to identify this VPLS and outer label 2000

modprobe bridge
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

############################################################################################
# Customer to LER1
key1=`add_mpls "nhlfe add key 0 instructions push gen 2000 nexthop eth2 ipv4 192.168.15.1"`
key2=`add_mpls "nhlfe add key 0 instructions push gen 100 forward $key1"`

# Create a 2 label MPLS tunnel to ler1 and set the tunnel interface type to ARPHRD_ETHERNET (ether_setup())
mpls tunnel add dev ler1 nhlfe $key2 type ethernet
ifconfig ler1 up

# Set split-horizon value on this interface to 1 so frames received on this interface will not
# be forwarded to other interfaces with horizon value 1. This is only needed when we have more than
# one LSR tunnel bridged.
brctl addif br0 ler1 sethorizon br0 ler1 1


############################################################################################
# Bridge inbnound to Customer
mpls labelspace set dev eth2 labelspace 0
mpls labelspace set dev ler1 labelspace 0

# Process MPLS packets from LER1 - pop the outer label and look at the inner label
mpls ilm add label gen 1000 labelspace 0 instructions set-rx-if ler1 pop peek

# Pass MPLS packets with label 100 to the mplsbr module which will set skb->dev to the ler1
# tunnel interface and send it to the Linux bridging code for receive processing. This allows
# proper MAC learning.
mpls ilm add label gen 100 labelspace 0 proto packet



It is very easy to add another LER and customer to the setup but it requires configuration on each
LER in the VPLS. I did a 3 LER setup with one customer per LER and also a 2 LER setup with 2 customers
on the 2nd LER. Using the Linux bridge with split-horizon and MPLS tunnel interface approach seems to work
well but I'm concerned about scalability. The number of tunnel interfaces will grow exponentially as customers
and LERs are added. A few thousand interfaces won't cause any problems though.

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.


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