This article will present you how to configure NG-MVPN architecture based on RSVP P2MP as provider tunnel. Actually, Junos supports several Provider Tunnels (aka. P-Tunnel). Those are listed there:
Here we will cover the P-Tunnel type 1: RSVP-TE P2MP LSP. And we will consider that multicast streams will be SSM (Source Specific Multicast). We will consider that receivers know the source address of the multicast streams (there is no RP in this topology).
The concepts of NG-MVPN is quite simple. We keep at the edge, between PE and CE routers, the PIM protocol. At this level we speak about C-PIM protocol (C for Customer). C-PIM allows to exchange Join / Prune information. PE, then converts those information in BGP via a new NLRI. Moreover at the data plane level, between PE and CE we keep native IP multicast forwarding but within the provider network the IP
Multicast is conveyed in what we call the provider tunnel.
The provider tunnel could be Inclusive or Selective. it means:
- Inclusive Tunnel. All PE are connected to the P-Tunnel. It means that all PE will receive the multicast streams convey within the P-tunnel even if there is no receiver attached to the PE.
- Selective Tunnel. A subset of PE are connected to a dedicated P-tunnel. Only those PE will receive multicast streams.
We will focus on only the Inclusive Tunnel mode.
For the rest of the article we will refer to this topology:
As you can see, our core network is made of a single ISIS area with LDP/RSVP protocols enabled:
We have one CE acting as a multicast source (CE3) and 2 receivers (CE1 and CE2). The RR peers with all PE. The BGP NLRIs exchanged are the following. As you can see, we will exchange PMSI (P-Multicast Service Interface) routes and also classical L3VPN routes. Hereafter the BGP configuration of the Route-Reflector . The global BGP configuration is the same for the 3 others PEs, except they only peer with the RR.
Now, let's move on to the configuration of the 3 PEs. There are 2 configs. The PE 3 is a Sender Site, unlike PE 1 and 2 that are Receiver Sites only. The configuration is done at routing-instance Level. Routing-instances are classical VRF instance, we just add the multicast service inside.
The configuration of the PE3 is the following:
When you enable MVPN on a VRF routing-instance you need to add the knob vrf-table-label. This knob allows 2 things. The first one is the allocation of a unique Label per VRF (not per Prefix as default). The second one is to allow a double lookup after the decap. action. Indeed, without the knob the encap. data coming from the provider network is only decap. and forwarded to the right interface connected to the VRF (the Per-Prefix Label allocation allows to do that). But for Multicast over P-Tunnel, the router needs to update the multicast routing and forwarding tables of the VRF, so it needs to analyse the packet carried in the tunnel. The vrf-table-label allows to do that.
As PE3 acts as a Sender Site only. We specify that explicitly to avoid unused states and to scale more.
The multicast source which is not directly connected to the PE3 (actually this is the lo0 of the CE3) need to be explicitly known on PE3. This is why we add a static-route to allow PE3 to know the source and accept multicast traffic coming from this source (RPF Check).
Finally, as PE3 is connected to Multicast Source we need to define the P-tunnel configuration. Here, we simply define the P-Tunnel as RSVP-TE P2MP tunnel. As remote PEs will be discovered dynamically we cannot define statically the Leaves of the P2MP tunnel. We only configure an LSP template that specifies the global parameters of the RSVP LSP. Each time the PE3 will discover dynamically a remote PE (Via BGP PMSI type 1 route), RSVP-TE will graft the remote PE to the P2MP LSP via RSVP Path msg:
The LSP Template is defined in the mpls section like this:
Now, let's analyse the configuration of the 2 receivers PE1 and PE2. The configuration is very simple. The knob vrt-table-label is again mandatory to allow the double lookup and we configured the 2 sites as receiver-site explicitly. In this case the P-tunnel configuration is not needed.
It's time to check our VRF routing table. As we use vrf-target to assign statically Import & Export RT, by default all routes within the VRF are advertised via the family inet-vpn unicast. Let's move on to the VRF routing table of PE2:
You see that PE receives 3 BGP routes which are:
- 1.1.1.1/32 the Multicast source sent by PE3 (which known it via its static-route)
- 2 x /30 subnets which are the PE/CE interco. from PE1 and PE3.
At this step, we can consider that all the 3 PE know the multicast source. PE3 directly attached to it via the static-route and PE1 and PE2 remotely via the BGP route sent by PE3. Here, there is nothing in relation with MVPN, only classical L3VPN configuration.
Now, it's time to start the MVPN signaling family of PE2. When PE2 becomes up (it means when it join the MVPN topology), it first sends a I-PMSI AD Route.
The type 1 route is sent via a BGP MP-NLRI (AFI : 1 ; SAFI : 5). It sends its router-distinguisher as a unique identifier of the PE. The Next-hop of the route is the primary loopback address of the PE. Hereafter the PE2 BGP update which conveys I-PMSI type 1 route sent by PE2 and received by PE3 (via the Route-Reflector):
On PE3, you can check MVPN routes in the mvpn.0 table of the routing-instance.
As you can see PE3 has got 3 MVPN routes. Its route and the 2 other I-PMSI Type 1 from PE1 and PE2. It's really as PE are multicast neighbors. Anyway it is how Junos considers this MVPN relationships. To show the PE3 MVPN neighbors:
When PE3 receives the PE2 I-PMSI type 1 route it triggers a RSVP Path message toward PE2 (the NH carried into the I-PMSI Type 1 route).
You can now check the P2MP status. First on ingress PE, which is PE3:
You can see that the same Label is assigned to the 2 remotes PE which are PE1 and PE2 loopback address (label merging). And you can check on a transit P router (P2) the state of the P2MP LSP. Here you can notice that as there is a replication, the first on to P1 to reach PE1 and the second one toward P3 to reach PE2, the "label out" is different.
Great. All our PEs are now enabled and the P2MP LSP has been set up after the Auto-discovery phase (via the I-PMSI Type 1 routes exchange). But there is no multicast stream yet. It's time to bring up our multicast source which is in our topology the CE3. To simulate this given SSM multicast stream (11.1.1.1 ; 232.0.1.1), we use this trick on Junos (very useful):
Don't forget to specify a TTL value (by default is 1). This command generates a 10pps multicast stream toward PE3. On PE3 we can check the multicast routing table:
The multicast stream is well received and accepted (RPF check - thanks to the static-route). But as you can see its forwarding state is still Pruned. Indeed, remember there is not yet receivers UP on PE2 and PE1. In this case the multicast stream is silently discarded on PE3 and not forwarded through the P-Tunnel.
Now we add a receiver connected to PE2. To simulate that we simply add a IGMP version 3 static group on CE2 to force CE2 to sent to PE2 a PIM Join for the multicast stream (11.1.1.1 ; 232.0.1.1). When PE2 receives this PIM Join, it first check it's unicast VRF routing table, to find which is the source of the multicast stream. In our topology, 11.1.1.1/32 has been sent by PE3.
PE2 then converts the PIM Join in a PMSI Type 7 route.
Here the BGP update sent by PE2 to PE3 (via the RR):
All the PE participating to this MVPN topology receive this update (via the RR), but only PE3 takes into account it because it is mentioned in the update via the RD field of the I-PMSI route. On PE2 you can check the status of the PIM conversion. You can see which (S;G) streams are active and on which RSVP P2MP tunnel they are mapped:
Let's move back on PE3. We can check the MVPN routing table of the VRF to see the PMSI type 7 installed route:
When PE3 receives this route it starts to forward inside the P-Tunnel. the multicast stream matching the I-PMSI Stream parameters (here 11.1.1.1 and 232.0.1.1). We can confirm that by seeing back the multicast forwarding table of PE3:
Great. The Forwarding state is no more in Pruned state and we have on Downstream Interface which is actually the interface where the P-Tunnel is routed. We can see on PE3, that the P2MP LSP conveys now multicast packets:
On transit node, P2, where the replication takes place, you can see also the LSP statistics.
You can see that the stream received from P4 is forwarded to P1 and P3 to reach PE1 (which has no receivers) and PE2 (which has got receiver). To be sure that the bandwidth is well used. I mean that PE3 (ingress PE) sends well one copy of the mcast stream along the PATH : PE3-P4-P2 and that only P2 replicates the stream, I'm checking the interfaces statistics on P2:
We receive 10 pps from P4 (so from PE3 the ingress PE) and we forward those 10 pps to PE1 and PE2. Remember with Inclusive P-Tunnel we flood the stream over the P-Tunnel. So PE1 that doesn't have receiver receives also the stream via its Provider Interface. But PE1 will do not forward this stream and this one is silently discarded. You can check this behavior by analyzing the multicast routing table of PE1:
The forwarding state is in Pruned state.
Unlike PE1, PE2 has got receiver, and its forwarding state is different:
PE2 forwards the multicast stream on ge-0/0/2.0 interface which is connected to CE2 (the receiver). If CE2 leaves the Stream, it sends to PE2 a PIM Prune message. This Prune message is converted by PE2 in PMSI Type 7 WITHDRAW route. As we are in L3VPN environement, the withdraw routes are conveyed as MP Unreachable NLRI. Hereafter an example of BGP update sent by PE2 when it wants to prune the given (S;G):
CONCLUSION :
This chapter do not cover the Selective Tunnel configuration which allows to have specific P-Tunnel for Specific Multicast Stream. Moreover we considered here that multicast sources are well known. In some configuration this is not the case and you need to add for example SSM-Mapping on PE on PE acting as RP-router. Also iNET ZERO's JNCIE-SP workbook contains excellent NG-VPN practice scenario's.
