Multicast VPN – PIM SSM in The Core
By Mike Down on Thursday, July 2, 2009 11:07The topology for this lab is kind of big because I wanted to have a circle of routers in the middle. This is always fun for troubleshooting RPF failures J. Other than that is a basic BGP/MPLS VPN.
For the sake of brevity, I will summarize much of the base configuration:
- P and PE routers are configured for OSPF area 0, MPLS/LDP, PIM-SM and multicast-routing
- PE routers are VPNv4 peers in a mesh and have multicast routing enabled on the VRF
- PE2 and PE4 have simulated CEs by using loopbacks in a VRF (advertised in BGP)
- CE3-PE3 protocol does not matter, I am using a static route
- CE3 has an igmp join command for group 238.0.0.1
Ultimately, the INT VRF Table will look like this:
PE2#sho ip route vrf INT | begi Gat
Gateway of last resort is not set
100.0.0.0/32 is subnetted, 3 subnets
C 100.1.1.22 is directly connected, Loopback100
B 100.1.1.23 [200/0] via 100.1.1.13, 00:03:36
B 100.1.1.24 [200/0] via 100.1.1.14, 00:03:51
Testing IP connectivity is always a must so before we get heavy into multicast configuration, make sure you can ping 100.1.1.22 and 100.1.1.24 from CE3. The last thing you want to find out when troubleshooting multicast is that you have IP connectivity issues!
Now for the good stuff J. The INT VRF will use PIM-SM, with CE3 as the RP so here’s the configuration on PE2, it looks the same on PE3 and PE4:
ip vrf INT
rd 100:1
route-target export 100:1
route-target import 100:1
mdt default 239.0.0.1
mdt data 239.1.1.0 0.0.0.255 threshold 10
!
ip multicast-routing
ip multicast-routing vrf INT
!
ip pim vrf INT rp-address 100.1.1.23
Now if we were using PIM-SM in the core would configure an RP globally on all the PE and P routers. With PIM-SSM there is no need for an RP. The main thing to remember is that the SSM range must contain your default MDT and data MDT. Here is the configuration on all P and PE routers:
ip pim ssm range MDT-SSM
!
ip access-list standard MDT-SSM
permit 239.0.0.0 0.0.0.255
permit 239.1.1.0 0.0.0.255
Let’s test, debug and look at some verification commands. First the ping:
PE2#ping vrf INT 238.0.0.1 sou lo 100 re 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 238.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.22
Reply to request 0 from 10.10.233.23, 240 ms
Reply to request 1 from 10.10.233.23, 360 ms
Reply to request 2 from 10.10.233.23, 252 ms
Reply to request 3 from 10.10.233.23, 268 ms
Reply to request 4 from 10.10.233.23, 368 ms
Debug ip mpacket looks like normal. The source is the loopback of PE2 because the actual packet is being tunneled. The destination is the Default MDT. If the data MDT threshold is reached you will see a data MDT group.
P2#debug ip mpac
IP multicast packets debugging is on
*Mar 1 02:05:02.751: IP(0): s=100.1.1.12 (Serial1/2) d=239.0.0.1 (Serial1/0) id=2737, ttl=254, prot=47, len=124(124), mforward
*Mar 1 02:05:02.779: IP(0): s=100.1.1.12 (Serial1/2) d=239.0.0.1 (Serial1/0) id=2738, ttl=254, prot=47, len=124(124), mforward
On P2 the route table looks like this:
P2#sho ip mroute ssm
(100.1.1.12, 239.0.0.1), 00:28:01/00:03:28, flags: sT
Incoming interface: Serial1/2, RPF nbr 10.10.122.12
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:09:34/00:03:16
(100.1.1.13, 239.0.0.1), 00:28:29/00:03:28, flags: sT
Incoming interface: Serial1/0, RPF nbr 10.10.12.1
Outgoing interface list:
Serial1/2, Forward/Sparse, 00:09:31/00:02:40
(100.1.1.14, 239.0.0.1), 00:28:43/00:03:18, flags: sT
Incoming interface: Serial1/0, RPF nbr 10.10.12.1
Outgoing interface list:
Serial1/2, Forward/Sparse, 00:09:34/00:02:50
Notice the lowercase in the flags section, this means the group is an SSM group. Let’s push a bunch of data through so we can see the MDT in action.
PE2#ping vrf INT 238.0.0.1 sou lo 100 re 100 size 15000
P2#sho ip mrout count
IP Multicast Statistics
7 routes using 3444 bytes of memory
3 groups, 1.33 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.1.1.0, Source count: 1, Packets forwarded: 217, Packets received: 217
Source: 100.1.1.12/32, Forwarding: 217/9/519/38, Other: 217/0/0
Group: 239.0.0.1, Source count: 3, Packets forwarded: 1143, Packets received: 1168
Source: 100.1.1.12/32, Forwarding: 770/13/343/75, Other: 785/0/15
Source: 100.1.1.13/32, Forwarding: 174/0/75/0, Other: 174/0/0
Source: 100.1.1.14/32, Forwarding: 199/1/70/0, Other: 200/0/1
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
P2#
Excellent. Now we see the first data MDT group being used, 239.1.1.0. Finally let’s see some other flags in action on PE3:
PE3#sho ip mroute 239.1.1.0 | be \(
(100.1.1.12, 239.1.1.0), 00:02:38/00:02:54, flags: sTIZ
Incoming interface: Serial1/0, RPF nbr 10.10.133.3
Outgoing interface list:
MVRF INT, Forward/Sparse, 00:02:38/00:00:23
The lowercase s (SSM) and uppercase T (SPT) flags we already know. The I is for “Received Source Specific Host Report” which is SSM specific and Z is for Multicast tunnel. This is a pretty simple configuration. Just remember that you SSM range needs to include your default and data MDT IP addresses.
Regards, Bryan (Post by Bryan Bartik)

Satinder Singh says:
February 2nd, 2010 at 11:39 pm
Execent post for basic understanding