Thread: [mpls-linux-devel] Moving forward
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel
|
From: Scott A. Y. <sy...@im...> - 2009-01-05 19:28:51
|
James, I'd like to help out with L3 BGP VPNs. In several e-mails on list you mentioned work that needed to be done on a label manager and the new network namespaces in 2.6 that might be used instead of vrf. I had come to the conclusion that the kernel's implementation of namespaces was not well suited for the creation of multiple L3 VPNs from a single process. I see that Vivien Chappelier submitted a patchset that allows interfaces and processes to attach to a namespace. What is the current status of this patchset and will it be used by the mpls-linux project? I have the latest p4 code (Quagga 0.99.10) checked out and am happy to report that it compiles and runs fine in my testbed (simple 2 host 2 LER setup). So to get L3 BGP VPN support moving forward which subproject should I start with? The label manager? Thanks, Scott Yoder ImageStream Internet Solutions, Inc. E-mail: sy...@im... |
|
From: James J. <ja...@fr...> - 2009-01-05 20:24:47
|
I would not know. I am not an active developer on this project, sorry. Anyone else on the list want to pipe up? On Tue, Jan 6, 2009 at 8:11 AM, Scott A. Yoder <sy...@im...> wrote: > James, > > I'd like to help out with L3 BGP VPNs. In several e-mails on list you mentioned work > that needed to be done on a label manager and the new network namespaces in 2.6 that > might be used instead of vrf. > > I had come to the conclusion that the kernel's implementation of namespaces was not > well suited for the creation of multiple L3 VPNs from a single process. I see that > Vivien Chappelier submitted a patchset that allows interfaces and processes to attach > to a namespace. What is the current status of this patchset and will it be used by > the mpls-linux project? > > I have the latest p4 code (Quagga 0.99.10) checked out and am happy to report that it compiles and runs > fine in my testbed (simple 2 host 2 LER setup). > > So to get L3 BGP VPN support moving forward which subproject should I start with? The label manager? > > Thanks, > Scott Yoder > ImageStream Internet Solutions, Inc. > E-mail: sy...@im... > > ------------------------------------------------------------------------------ > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > -- James Jones Managing Director Freedom Networks +64 6 3678300 +1 413 771 1402 ja...@fr... |
|
From: James R. L. <jl...@mi...> - 2009-01-06 02:48:03
|
Hello Scott,
On Mon, Jan 05, 2009 at 02:11:03PM -0500, Scott A. Yoder wrote:
> James,
>
> I'd like to help out with L3 BGP VPNs. In several e-mails on list you mentioned work
> that needed to be done on a label manager and the new network namespaces in 2.6 that
> might be used instead of vrf.
Correct, along with a lot of other areas, but these pieces are pretty core
to the work that is needed.
> I had come to the conclusion that the kernel's implementation of namespaces was not
> well suited for the creation of multiple L3 VPNs from a single process. I see that
> Vivien Chappelier submitted a patchset that allows interfaces and processes to attach
> to a namespace. What is the current status of this patchset and will it be used by
> the mpls-linux project?
You are correct again. The namespace code is meant to provide a
process and it's children access to a private network namespace.
As you saw with Vivien's code it doesn't take much to make the
network namespace implementation useful for VRF type usage. To
that end I've adopted most of Vivien's patches into my VRF tree,
and I will augment them with some additional work (replace the static
number of VRFs with a dynamic scheme).
> I have the latest p4 code (Quagga 0.99.10) checked out and am happy to report that it compiles and runs
> fine in my testbed (simple 2 host 2 LER setup).
>
> So to get L3 BGP VPN support moving forward which subproject should I start with? The label manager?
Here are a couple of areas to start, note these are just beginings, not
finished products. I'm also open to other ideas. For example if there is a
particular area that you find interesting, challenging, or benifits you
in some way, let me know and I'm sure we can make it work.
BGP transmit side
- a VTY interface to creating VPN4 NLRI with tagging info
- peer with an existing implementation to make sure they
get added to the peers correct VRF
BGP receive side
- implement RFC2547 policy interface
- apply policy to incoming VPN4 NLRI and put the results into
different quagga tables (not neccessariy VRFs at this point)
generic VRF quagga infrastructure
- implement code for a generic interface to creating
static routes in VRFs which are stored in different quagga
tables
- implement various VRF drivers (using linux tables and rules,
solaris zones?, and linux namespace/VRF, null - just use single
routing table but warn when overlaping address space is encountered)
- probably involves modifying ZEBRA protocol ...
support for recursive/hierachical MPLS labeling
- tagged BGP route that have a nexthop that uses a static route with a
label attached, the result is a route in the table that points
to a NHLFE that pushes two labels (or fwds to another NHLFE ...)
label manager
- sync API for protocols (LDP, BGP, RSVP-TE) to query for a label
which will be installed as an ILM and distributed to a peer
- make sure static label assignments do not conflict
- make sure that 'service' labels (BGP and L2VPN etc) are allocated
and used only on like labelspaces (most often global)
namespace/VRF kernel work
- finish API for creating/deleting VRFs
> Thanks,
> Scott Yoder
> ImageStream Internet Solutions, Inc.
> E-mail: sy...@im...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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...> - 2009-01-06 19:09:09
|
James R. Leu wrote: > Here are a couple of areas to start, note these are just beginings, not > finished products. I'm also open to other ideas. For example if there is a > particular area that you find interesting, challenging, or benifits you > in some way, let me know and I'm sure we can make it work. > > BGP transmit side > - a VTY interface to creating VPN4 NLRI with tagging info > - peer with an existing implementation to make sure they > get added to the peers correct VRF > BGP receive side > - implement RFC2547 policy interface > - apply policy to incoming VPN4 NLRI and put the results into > different quagga tables (not neccessariy VRFs at this point) As much as I'd like to get the label manager foundation done first I'd also like to see some quick results. I think I'm going to start with the VPNV4 exchange to see it working and then go back and finish up the label manager. I haven't done a lot of coding with Quagga so I'm spending some time familiarizing myself with the code. I'll also bounce ideas off of the list as much as possible. Thanks, Scott Yoder ImageStream Internet Solutions, Inc. E-mail: sy...@im... |
|
From: James R. L. <jl...@mi...> - 2009-01-09 04:56:48
|
Scott, This sounds like a great first step. Please don't hesitate to ask questions or bounce ideas off the list. On Tue, Jan 06, 2009 at 02:09:08PM -0500, Scott A. Yoder wrote: > James R. Leu wrote: > > Here are a couple of areas to start, note these are just beginings, not > > finished products. I'm also open to other ideas. For example if there is a > > particular area that you find interesting, challenging, or benifits you > > in some way, let me know and I'm sure we can make it work. > > > > BGP transmit side > > - a VTY interface to creating VPN4 NLRI with tagging info > > - peer with an existing implementation to make sure they > > get added to the peers correct VRF > > BGP receive side > > - implement RFC2547 policy interface > > - apply policy to incoming VPN4 NLRI and put the results into > > different quagga tables (not neccessariy VRFs at this point) > > As much as I'd like to get the label manager foundation done first I'd also like to > see some quick results. I think I'm going to start with the VPNV4 exchange to see > it working and then go back and finish up the label manager. > > I haven't done a lot of coding with Quagga so I'm spending some time familiarizing myself > with the code. I'll also bounce ideas off of the list as much as possible. > > Thanks, > Scott Yoder > ImageStream Internet Solutions, Inc. > E-mail: sy...@im... -- James R. Leu jl...@mi... |
|
From: Scott A. Y. <sy...@im...> - 2009-01-09 20:31:49
|
After some more research I think we'll need the VRF infrastructure first since both the BGP transmit and receive depend on the route distinguisher and import/export route targets defined by the VRF. Scott Yoder Support Engineer ImageStream Internet Solutions, Inc. E-mail: sy...@im... James R. Leu wrote: > Scott, > > This sounds like a great first step. Please don't hesitate to > ask questions or bounce ideas off the list. > > On Tue, Jan 06, 2009 at 02:09:08PM -0500, Scott A. Yoder wrote: >> James R. Leu wrote: >>> Here are a couple of areas to start, note these are just beginings, not >>> finished products. I'm also open to other ideas. For example if there is a >>> particular area that you find interesting, challenging, or benifits you >>> in some way, let me know and I'm sure we can make it work. >>> >>> BGP transmit side >>> - a VTY interface to creating VPN4 NLRI with tagging info >>> - peer with an existing implementation to make sure they >>> get added to the peers correct VRF >>> BGP receive side >>> - implement RFC2547 policy interface >>> - apply policy to incoming VPN4 NLRI and put the results into >>> different quagga tables (not neccessariy VRFs at this point) >> As much as I'd like to get the label manager foundation done first I'd also like to >> see some quick results. I think I'm going to start with the VPNV4 exchange to see >> it working and then go back and finish up the label manager. >> >> I haven't done a lot of coding with Quagga so I'm spending some time familiarizing myself >> with the code. I'll also bounce ideas off of the list as much as possible. >> >> Thanks, >> Scott Yoder >> ImageStream Internet Solutions, Inc. >> E-mail: sy...@im... > |
|
From: Scott A. Y. <sy...@im...> - 2009-01-09 21:11:11
|
Oops I didn't mean to hit send on that yet. I've been looking at common MPLS VPN configurations and for the most part they look like: ip vrf red rd 1:1 route-target export 1:1 route-target import 1:1 ! interface Ethernet1 ip vrf forwarding red ip address 10.10.4.1 255.255.255.0 ! router bgp 65535 neighbor 10.200.254.2 remote-as 1 ! address-family vpnv4 neighbor 10.200.254.2 activate neighbor 10.200.254.2 send-community both ! >From my reading on the way that other router company does it, it's the VRF that creates the vpnv4 prefixes. Routes in the VRF will become vpnv4 routes subject to route filtering on the vrf with the VRF's designated route distinguisher and route target attributes. It looks like there can be multiple route targets added to the vpnv4 prefix. On the BGP receive side vpnv4 prefixes received use the route-target import to determine which VRFs the route is installed into (after stripping off the RD). Since the existing vpnv4 code was written to support route reflector mode it ignores the route target attributes. We'd have to be sure to support route reflector mode properly. Do I have most of the basics correct? Thanks, Scott Yoder Support Engineer ImageStream Internet Solutions, Inc. E-mail: sy...@im... |
|
From: James R. L. <jl...@mi...> - 2009-01-13 05:38:45
|
Hey there Scott.
First off, I think your example below contains all the components to
a Cisco MPLS BGP VPN config and the description of how NLRI are generate
and processes seems accurate.
As you're probably seeing right now, there is a lot of VTY work
and other infrastructure required before you will get to test anything.
Also the quagga BGP implementation may not support sending the VPNV4 NLRI
or the extended communities needed to implement import/export policies.
In an effort to expose the weaknesses if they exist and to provide a
mechanism to test them you could take a short cut. The short cut
I'm suggesting will allow you to learning how to interact with the
BGP code but minimize the amount of VTY code you need to write at
this time.
First make sure the address-family code that exists in bgpd allows
for adding vpnv4 to a session. Second, create a new version of the
'ip route' command that is specifically for creating a VPN4 NLRI.
Something like:
vpnv4 route 1:1:10.0.0.0/8 target 1:1
The VTY code behind the scene would push a VPNV4 NLRI with the associated
route target into the BGP rib and advertise to the BGP sessions that support
the VPNV4 NLRI.
So if you peer with a Cisco or Juniper (or other MPLS BGP implementation)
you should see the NLRI you added in their rib-in.
Once you get this far, then you can work on the receive side, which
would be to make sure quagga can receive a VPNV4 NLRI.
After you get the 'bits on the wire' stuff figured out in quagga
then you can start working on the infrastructure to learn and add
routes from/to a 'VRF' table.
If you do not have a Cisco or a Juniper to test against, let me know
I believe I might be able to help you out there.
On Fri, Jan 09, 2009 at 04:11:02PM -0500, Scott A. Yoder wrote:
> Oops I didn't mean to hit send on that yet.
>
> I've been looking at common MPLS VPN configurations and for the most part they look like:
>
> ip vrf red
> rd 1:1
> route-target export 1:1
> route-target import 1:1
> !
> interface Ethernet1
> ip vrf forwarding red
> ip address 10.10.4.1 255.255.255.0
> !
> router bgp 65535
> neighbor 10.200.254.2 remote-as 1
> !
> address-family vpnv4
> neighbor 10.200.254.2 activate
> neighbor 10.200.254.2 send-community both
> !
>
> From my reading on the way that other router company does it, it's the VRF that creates the vpnv4 prefixes.
> Routes in the VRF will become vpnv4 routes subject to route filtering on the vrf with
> the VRF's designated route distinguisher and route target attributes. It looks like there can be multiple route
> targets added to the vpnv4 prefix.
>
> On the BGP receive side vpnv4 prefixes received use the route-target import to determine which VRFs the route is installed
> into (after stripping off the RD).
>
> Since the existing vpnv4 code was written to support route reflector mode it ignores the route target attributes. We'd have
> to be sure to support route reflector mode properly.
>
> Do I have most of the basics correct?
>
> Thanks,
> Scott Yoder
> Support Engineer
> ImageStream Internet Solutions, Inc.
> E-mail: sy...@im...
--
James R. Leu
jl...@mi...
|
|
From: Scott A. Y. <sy...@im...> - 2009-01-14 20:34:22
|
Thanks for the suggestion James. I think it's a great idea. While digging around in
bgp_mplsvpn.c I came across this vty command that I believe does almost the same thing you've
proposed.
/* For testing purpose, static route of MPLS-VPN. */
DEFUN (vpnv4_network,
vpnv4_network_cmd,
"network A.B.C.D/M rd ASN:nn_or_IP-address:nn tag WORD",
I think the tag is the MPLS label. I might just be able to modify this command to
accept a route-target attribute for export.
Scott Yoder
Support Engineer
ImageStream Internet Solutions, Inc.
E-mail: sy...@im...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X