iamjeffvader's studymotron and rantatorium

In the last post in this series we saw how to configure our services on the 7750.  This post will show you what actually happens at various stages of service operation.  Let’s get started!

The I-PMSI: Once we no shut the VPRN we will cause the generation of the Intra-AS I-PMSI message to all our BGP peers.  r1-rack3 is a route reflector so it will also send that to its clients.  As you can see in the embedded text the update carries the RD and originators IP address per the RFC6514 message detail.  As we enable the VPRN on each PE the equivalent message will be transmitted and if we create more VPRNs messages will be sent for them with different RDs.

LDP will also allocate labels to the service rooted at each PE.

And finally at this stage let’s look at the LIB.  We can see the label we advertised to pe2 is our ingress label with the tunnel ID matching too.

Once every PE knows about all others we have the default tree up and running, the overlay broadcast network. The customer should now be able to traffic.  We still have our receiver configured on r4-ce1-rp so now r5-ce2-src is going to transmit to the group and we simulate this by pinging the group address from r5-ce2-src

As we are only transmitting 100 bytes we should not trigger the S-PMSI creation at this point.  Two things will happen now, each BGP speaker will receive a source join from pe1 connected to r4-ce1-rp (rx) followed by a source active route from pe2 connected to r5-ce2-src (tx).

The source join contains the C-S address (10.5.2.5) and the C-G address (224.1.1.1).

The source active update is sent from the PE connected to the stream source, in our case this is pe2.  The mVPN relevant difference between the source join and here is the the ASN is not present in the source active update.

If we take a look at the BGP table we can see the I-PMSI, Source-Active and Source-Join entries.

The S-PMSI: OK so now we have our tree built we can go ahead and ramp up the traffic so that we see the S-PMSI updates. Let’s generate some more ICMP but increase the packet size:

This will cause our data threshold to breach and trigger the sending of S-PMSI from pe2 and traffic to switch over the selective/data tree.  Again we see the (C-S, C-G) state highlighted in yellow.

Along with this LDP will allocate and advertise labels for the new tree. Here we send a message to our neighbour advertising label 262129, note the tunnel ID.

The BGP table now has the S-PMSI entry to go along with the other three, let’s have a look.

Once traffic throttles back below the threshold or stops completely the S-PMSI A-D will be withdrawn.  As well as the BGP update we can see the LDP withdraw messages exchanged between pe1 and pe2.

So that’s pretty much all I have had time to test on the 7750. If you are interested in the topic I wrote a more vendor agnostic post over on packetpushers.net which I will elaborate on further and have little mini series there too.

Please leave feedback in the comments sections or suggest something else you would like covered.

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

Ok so it has been a while. I have done some testing on LDP based mVPN at this stage, not a huge amount, mainly basic functionality.

The first thing to note is 7750 MUST run in chassis mode D to allow the multicast commands required for mLDP. This means no IOM1 or IOM2 cards are allowed in the chassis and because of this I have a limited topology to play with.

Both PE routers are SR12s running CPM2-400G and have IMMs or IOM3 in the CE facing slots.  The CE routers are Cisco 1841, r4-ce1-rp is the RP and also the receiver, it’s config is below.  r5-ce2-src simply runs PIM on its uplink to pe2 and will source traffic to group 224.1.1.1.

Roll on up the 7750s.  The first task we do is create the VPRN service and place the CE facing interface in to the VRFs PIM process.  I have configured the CE facing interface name as “mvpn” just for clarity, it has no bearing on the mVPN configuration.  The remainder of the config is exactly the same as standard VPRN.  PIM configuration is very straightforward, all I do is enter the PIM process and add the interface.  The rest of the config below is defaulted.  I won’t be setting the RP address as I think that’s intrusive on the customers experience, they should have the freedom to change their RP as they see fit.

Once we do this, and assuming connectivity is good, we should see a PIM adjacency going up:

So that is the very basic element complete.  Now we just need to do the entire core!  Well not so much.  Per the diagram above I already have MP-BGP configured and both routers have address family mvpn-ipv4 activated.  I also have VPNv4 activated, not much point having mVPN and no IPv4 VPN to use.  Would anyone buy that service?

There is one other ‘core’  element we need to verify before we get in to the VRF specific multicast configuration.  We need to ensure our network interface will support multicast and the creation of mLDP trees. We simply enable it under the LDP interface…

and if we want to prevent multicast over an interface…

I have links to routers that do not run in mode D so multicast processing should be disabled.

OK so with MP-BGP and LDP multicast enabled we can configure the VPRN to carry the customers traffic.  That will come in the next post which will see the VPRN config and debug behaviour when the services comes up and how BGP updates trigger switchover to the S-PMSI.