Re: [mpls-linux-general] VPNs using MPLS-Linux/LDP-Portable

[James R. L. <jl...@mi...>]

I think Yon has all of the info here, it's just a bit scattered ;-)

Requirements:

-you need to have a kernel that support mutiple "forwarding" tables.
 Linux 2.2 and 2.4 have this.  One forwarding table per VPN per edge rout=
er.
-you need to be able to add MPLS labels to the route entries in these
 "forwarding table" on the ingress routers and have MPLS labels point
 you to a "forwarding table" on the egress routers
-You need to have a route daemon that can run mulitple instances of
 lightwiegh protocol like RIPv2 or OSPF (or even static routes) and assoc=
iates
 the routes learned via this protocol to one of the "forwarding tables"
-you need a BGP implementation that con distribute routes for the VPN:IPV=
4
 address family and MPLS labels per route (could be the same label value)
-you need a MPLS signaling protocol that will create "tunnel" LSPs that
 span from edge router to edge router (across the core).  LDP protable co=
uld
 be used to do this, running in "juniper" mode.
-you then need some intelligence to tie the routes learned via BGP to
 and LSPs that cross the core.

Desired result:

-on ingress router a packet comes in a custoemr interface and a route
 lookup is done in it's vpn forwarding table.  There is a MPLS label
 associated with this route entry (learned via BGP) and the route entry
 has an LSP as the outgoing interface (an  MPLS tunnel setup via LDP to
 be exact).  The MPLS label associated with the route entry is pushed on
 the packet, then the MPLS label associated with the MPLS tunnel is pushe=
d
 on the label and is forwarded across the core.
-at the egress the label used to corss the core is popped off, the second
 label points to a "forwarding table".  The packet is delived to the
 vpn forwarding table were a IP lookup is done which will deliver the pac=
ket
 to a custoemr interface.

Most of the pieces to this puzzle exist, they just need to be tied togeth=
er.

Jim


On Tue, Feb 20, 2001 at 05:20:02PM +0100, Yon Uriarte wrote:
> On Tue, 20 Feb 2001, Arm=E9nio Pinto wrote:
> > Hi there,
>=20
> Hi hi,
>=20
>=20
> >      Has anyone tried to implement any kind of VPN using
> > MPLS-Linux/LDP-Portable packages? Thanks in advance.
>=20
>=20
> There is (was?) support for BGP-MPLS in zebra.
>=20
>  For LDP you need:
>=20
> 1) mpls support in zebra (zebra <-> kernel interface)
> 2) mpls support in zebra protocol (zebra <-> daemons)
> 3) port ldp-portable to zebra
>=20
>=20
>  For 1&2 you could just split Mr. Leu's mpls API (portability
> layer) in two, translating it to the zebra framework, mantaining
> the general function calls (just serializing them over the
> zebra protocol). For 1, you have to write some kind of
> mpls LIB manager, too.
>=20
>  I have started on 3, it is a mess, doesn't do anything useful
> yet, as I have problems understanding ldp-portable (to be
> precise: I don't want to learn how ldp-portable works,
> need-to-know is my keyword here).
>=20
>  So I have some cut'n'pasted code. It is quite basic, yet.
> I might start (paid) work soon, so I guess I'll put it up
> for grabs. I'll mail you.
>=20
>=20
>  Now, you wanted VPN, if you want to emulate cisco's vpn
> code, you need VRF, that is:
> 1) different packet forwarding tables in zebra
> 2) a way to attach such vrf to an interface
> 3) a way to route routes from such vrfs to/from routing processes
>=20
>=20
> 1 might be easy, maybe. Look at zebra/lib/table.h and
> zebra/lib/rib.* (at least). I'm no zebra expert.
>=20
> 2 is kernel dependent, linux 2.[2|4] could do it.
> For linux you'll have to clean the "local"
> table, too, or you will have problems, and
> anyway, I guess there are some other details. Just
> abstract this into a portable api for zebra.
>=20
> 3 zebra internals, see 1. Extend zebra protocol?
>=20
>=20
> Oh, and you want different routing processes (per VPN,
> at least, if not per interface), which isn't trivial
> with zebra at the moment, though it is possible,
> i've been told.
>=20
>=20
>  Afterward, mpls-linux will do all you want, no need to
> patch it, I guess.
>=20
>=20
> Disclaimer: I'm no expert at anything, this are just ideas
>   from my "a little knowledge and curiosity" standpoint.
>=20
>=20
> Have fun,
>  yon
>=20
>=20
>=20
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu