iamjeffvader's studymotron and rantatorium

In the last post we saw a description of how to configure your core to support mLDP based mVPN services and it was admittedly straightforward.  The meat of the work happens in the service configuration which we will look at here.  I will focus on the configs and save the actual operation of the service for another post as the debug is quite long.

All the mVPN service configuration happens in the, wait for it, mvpn hierarchy.   For me one of the most critical parts of the standard is the use of BGP auto-discovery to, well, discover other PE routers in the mVPN without relying on PIM in the core.  Let’s configure that first.  We have the choice of ‘default’ or ‘mdt-safi’ and we are going to choose ‘default’ as we are not interested in the MDT SAFI.  Auto discovery is agnostic to the transport mechanism.

There is a certain order of operations to follow which we will see.  Before we can configure C signalling we need to configure the A-D method.

Again more order of operations, before we configure our tunnels we have to enable C multicast signalling.  Here we need to choose between BGP and PIM for signalling between the PE routers.  As we want to get rid of PIM from our core let’s go with BGP.

OK now the router is ready for our tunnel configuration. In a Draft Rosen VPN we would need to associate our mdt with a VPN, we don’t have to do that with NG mVPN but we do need to enable transport for our trees.  In multicast VPNs we have the concept of the default and data trees which are known as the I-PMSI and S-PMSI respectively.  The I-PMSI serves the same function as the default tree, where GRE tunnels are created in Draft Rosen at service initiation.  This allows the entire VPN to receive multicast traffic but is not efficient.  Why is it inefficient?  Any PE without interested receivers connected will still receive traffic on this tree but drop it meaning waste resources in the network.  The S-PMSI takes care of this by building a tree between interested PEs only and switching traffic over it, typically when traffic exceeds a particular data rate threshold.  To enable these we go in to provider-tunnel and no shut our transport within the I-PMSI or S-PMSI.

We have three options for transport: mLDP, RSVP-TE and PIM

As we are using mLDP for this service we will go ahead and enable that for the inclusive and selective tunnels.  We can’t do this if we have not enabled the VRF PIM process, which we took care of in this post

I think this highlights why I am such a fan of SROS.  It is so simple to do some pretty complicated things even though you must do things in a specific order.  Time was you would have all sorts of crazy patches and elaborate nonsensical configs but this OS I well structured for the most part.  Lets not spoil the moment by thinking about QoS and triple play configs :).

If you were in the process of migrating from a PIM core to a pure MPLS one you could enable PIM as your provider tunnel here for nodes that don’t support mLDP.  Because this is done on a per service basis you could gradually migrate away from your legacy PIM based core.

Anyway we are just one short commands away from finishing our service and testing it out.  If you want you can configure your mVPN specific route targets, maybe you want to import routes at different remote PEs,  but if you don’t need to do this you can inherit them from the unicast RT

Thats it!  The service should be up because of course we have configured the same thing on each of our participating PEs.  So is it up? The tension is killing me…

And service is up with mLDP based provider tunnels.  The next post will cover what actually happens as we enable service and traffic starts to flow