Re: [mpls-linux-devel] Moving forward

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

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...