Thread: [mpls-linux-devel] L2 VPLS thoughts
Status: Beta
Brought to you by:
jleu
From: Scott A. Y. <sy...@im...> - 2008-03-26 15:20:40
|
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... |
From: James R. L. <jl...@mi...> - 2008-03-27 03:33:24
|
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. 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. > 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. > 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 -- James R. Leu jl...@mi... |
From: Scott A. Y. <sy...@im...> - 2008-03-27 21:35:34
|
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... |