Rosen Draft 7 - Example

In this topology the three PE routers are running a basic PIM-SM configuration. The VRF "VPN_A" configured on each PE is the customer L3 VPN over which the customer is running multicast. eBGP runs between each PE and attached CPE for IPv4 unicast only, each CPE is advertising it's loopback0 IP into the L3 VPN. PIM is configured on the PE-CE link inside the VRF.

A unique /24 PIM-SSM group address range has been assigned for this L3 VPN on each PE under the customer's VRF. Between PEs the address family inet-mdt is enabled so that BGP signalled autodiscovery for data MDTs can occur.

Initial Setup

A draft-rosen MVPN with service provider tunnels operating in SSM mode uses BGP signalling for autodiscovery of the PE routers. These MVPNs are also referred to as Draft Rosen 7. Each PE sends an MDT-SAFI (AFI=1, SAFI=66) BGP NLRI which contains the following information:

Route distinguisher

Unicast address of the PE router to which the source site is attached (usually the loopback)

Multicast group address

Route target extended community attribute

Each remote PE router imports the MDT-SAFI advertisements from each of the other PE routers if the route target matches.

Each PE router then joins the (S,G) tree rooted at each of the other PE routers. After the PE routers are discovered, PIM is notified of the multicast source and group addresses. PIM binds the (S,G) state to the multicast tunnel (mt) interface and sends a join message for that group.

The output below shows all PEs have exchanged BGP routes for the default 232.1.1.1 RP-discovery group, because they have matching RTs they are imported into the customers multicast VRF:

Below the PIM output shows that inside the global routing table each PE has joined the multicast groups signalled by the other PEs over BGP-MDT. There are three source specific multicast groups (S,G) 232.1.1.1,1.1.1.1, 232.1.1.1,2.2.2.2 and 232.1.1.1,3.3.3.3. They were signalled by BGP. The output below is from vMX-PE1 which is why the upstream interface list is "local" as this PE is the root of this source-specific multicast group tree and the downstream interface list contains the interfaces facing vMX-PE2 and vMX-PE3.

vMX-PE1 is also downstream of the 232.1.1.1,2.2.2.2 and 232.1.1.1,3.3.3.3 groups so in both cases the upstream interface list contains the point-to-point interface towards the relevant PE and the downstream interface (how this PE would receive traffic from those upstream nodes) is via the point-to-multipoint GRE tunnel interface mt-0/0/10.1081344:

Each PE has discovered its PIM neighbours through multicast hellos, below vMX-PE1 has two PIM neighbours (vMX-PE2 and vMX-PE3) inside the global routing table / inet.0 however, the available groups to join (shown in the about above) were signalled by BGP-MDT:

mt-0/0/10.32768 is the point to multipoint tunnel inside the VPN_A VRF.

mt-0/0/10.1081344 is the point to multipoint tunnel inside inet0 / GRT.

Within the inet.0 table vMX-PE3 is statically configured as the rendezvous point, within the VRF vMX-CE1 is statically configured as the RP. SSM is being used so the RP is not actually being used to find an available source like with ASM (Any Source Multicast):

The output below shows just a default any-source multicast group of (*,G) *,224.0.1.40 initially exists inside the multicast VRF VPN_A. 224.0.1.40 is the IANA well know group address for rp-discovery. vMX-CE1 is statically configured as the RP inside this VRF on all devices which is why the vMX-PE1 to vMX-CE1 interface is listed as the upstream interface for this default group and the point-to-multipoint GRE interface towards vMX-PE2 and vMX-PE3 inside the VRF is listed as the downstream interface:

Equally, on vMX-PE2 we can see that the upstream interface is the point to multipoint tunnel towards vMX-PE1 and vMX-PE3 and the downstream interface is ge-0/0/5 facing IOS-CPE2. So everything looks to be in place however the RP isn’t used in SSM:

Below is the output from vMX-CE1 showing it has a PIM a neighborship with vMX-PE1 and the only group currently is the default RP-announce group, the downstream interface for this is ge-0/0/3 facing vMX-PE1, the upstream interface is Local this device is the static RP:

A ping is started on HOST1 towards 232.10.10.2 from it's source IP 10.0.44.1. vMX-CE1 recognises the packet destination is within the 232/8 source specific multicast ranges and creates a new PIM group entry, a source specific entry (S,G) 10.0.44.1,232.1.1.1. Initially there are no downstream interfaces for this S,G entry as no listeners have joined this SSM group, only an upstream interface ge-0/0/4 towards HOST1 interface Fa0/0:

Next a source specific IGMP Join is simulated on HOST3 interface Fa0/0, this will be a listener for this source specific group 232.10.10.1,10.0.44.1:

conf t int Fa0/0 ip igmp join-group 232.10.10.1 source 10.0.44.1

IOS-CPE2 receives the IGMP join request. IOS-CPE2 is pre-preconfigured with the static RP for this customer VRF, 4.4.4.4, the loopback IP on vMX-CPE1. IOS-CPE2 first sends a PIM Join request towards vMX-PE2 to the IANA well-known All PIM Routers address 224.0.013, to join the IANA well-known RP discovery group address 224.0.1.40 to register with the RP 4.4.4.4 (vMX-CPE1 Loopback):

IOS-CPE2 also automatically sets up a GRE tunnel called Tu0 towards the RP for the VRF, 4.4.4.4:

IOS-CPE2 also converts the IGMP Join it received from HOST2 into a PIM Join and sends this towards vMX-PE2. The screenshot below shows that IOS-CPE2 sends a PIM Join to the IANA well-known address for All PIM Routers, 224.0.0.13. The PIM Join is for the group 232.10.10.1 with the specific source of 10.0.44.1. The upstream neighbour is the vMX-PE2 interface IP on the vMX-PE2 to IOS-CPE2 link, vMX-PE2 is upstream of IOS-CPE2 in this multicast tree towards the RP:

IOS-CPE2 now has the following multicast routes present within the customer VRF, one source specific S,G route to receive traffic sent from HOST1 and forward it to HOST2 with vMX-PE2 as the RP, and one any source *,G route for the IANA well-known rp-discovery group address:

vMX-PE2 receives the PIM Join message on an interface inside a VRF, “VPN_A” in this case. vMX-PE2 will multicast the PIM Join to the group address setup that reaches the other PEs in the core, 232.1.1.1, from its loopback IP 2.2.2.2. The packet is sent over the inet.1 point to multipoint GRE tunnel from vMX-PE2 to vMX-PE1 and vMX-PE3. This is because BGP has signalled 232.1.1.1 from each PE to every other PE:

vMX-PE2 also adds a multicast route inside the customer VRF for this S,G, the next hop interface index resolves to the vMX-PE2 to IOS-CPE2 interface ge-0/0/5, packets heading to 232.10.10.1 from 10.0.44.1 will be sent out of this interface. This shows how the PIM information above is implemented in to the RIB and eventually FIB:

The PIM Join is received by vMX-PE1 and the group entry has been created on vMX-PE1 with the downstream interface set to the point-to-multipoint GRE tunnel towards vMX-PE2 and vMX-PE3, and the upstream interface set to the vMX-PE1 to vMX-CE1 link ge-0/0/5:

The same IGMP Join can be configured on HOST3 to make it listener for the same S,G range. The same process happenes, a Join ripples from IOS-CPE3 to vMX-CPE1 with the outgoing interfaces along the path added to the PIM Group details. Now HOST1 receives two ICMP echo replies for ever echo request sent, one from HOST2 and one from HOST3:

It can be seen in the packet capture above on the link between vMX-PE1 and vMX-PE2, that the ICMP echo requests are sent to the multicast address 232.1.1.1 inside the VRF. vMX-PE1 sends the data over the point-to-multipoint GRE tunnel towards vMX-PE2 and vMX-PE3 also with the destination address of 232.1.1.1. Both vMX-PE1 and vMX-PE2 receive the ICMP echo requests but only vMX-PE1 has a receiver active for this SSM group at present.

ICMP echo replies are “normal” unicast responses back to the source IP 10.0.45.2:

Below the multicast routes can be seen from vMX-PE2’s perspective inside the customers multicast VRF:

On vMX-PE1 we can see that the point-to-multipoint GRE tunnel mt-0/0/10.32768 is the outgoing interface for traffic to this multicast group (even when HOST3 joins the multicast group as a 2nd listener the output below stays the same):