Incidentally, before going any further, for a great review of the multicast concepts head to:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/prod_presentation0900aecd8031088a.pdf
If any of the above doesn't make sense to you, or you just want to brush up on your PIM Sparse mode, I strongly recommend you take a look at my first blog post, the concepts we are about to discuss all really depend on understanding PIM Sparse Mode. OK! Let's start!
So when we spent time talking about PIM we looked at how when a receiver wants to join a multicast group, the closest router to that receiver (also known as the last hop router) will send a message up the tree to the RP to say hey, this guy wants to start receiving multicast so start getting the interfaces ready to start forwarding.
We kind of glossed over how the device itself tells the router it wants to start receiving the multicast though, this happens via IGMP. In simple terms an IGMP message tells the router that the host wants to receive the multicast, you can have a router join a multicast group with:
ip igmp join-group 239.1.1.1 (where 239.1.1.1 is the multicast group you want the device to join)
A Source can then generate traffic to 239.1.1.1 and start receiving the multicast stream.
Everything looking fine and dandy so far? OK, here are a few problems with this approach:
- What happens when two sources are transmitting to the same multicast address? the receivers will receive two streams, wasting network bandwidth
- A malicious user could start sending traffic to a multicast address and have it delivered to multiple hosts, potentially knocking them off the the network or degrading performance or interfering with the legitimate multicast application
- We need an RP to discover the devices that want to receive multicast traffic, and we also need an RP for the first multicast frame from the source to reach our receiver (then we switch to a shortest path tree), what if our RP dies?
- If i am trying to build multicast applications for the internet (something which I would like to point out, doesn't really seem to have happened yet unless I am mistaken, do you know of a multicast application used out on the internet? Let us know in the comments section! :)) who runs the RP? Which ISP? Why do I trust them? Without an RP how do I learn about multicast sources and who wants to receive the traffic?
First of all, Let's quickly look at an IGMP Packet: (Picture source article: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html#wp1015526)
As you can probably tell from the above picture, with such a small type field, IGMP version 1 which is illustrated above is not exactly a complicated protocol. The host sends an IGMP Packet requesting to join the group address listed in the packet.
IGMP Version 2 added some extra message types that are not relevant to our discussion at the moment, the important thing is to see that the only major field this packet contains is a group address that wishes to be joined.
Below is an IGMPv3 Packet:
As you can see, this packet not only contains the group we wish to join, but a source field, which can be used to specifiy "I want to join this multicast stream from THESE sources".
Here things get interesting.
Let's assume our host knows what multicast group it wants to join and also knows the source address, this could have been learnt via some sort of external directory of multicast sources, like a webpage or something like that. The important thing to know is, somehow our host has discovered the group it wants to join, and what sources it should expect traffic from.
Here is an example of the packets generated when we join a group using IGMPv3 on a router:
Router(config-if)#ip igmp version 3
Router(config-if)#ip igmp join-group 232.1.1.1 source 1.1.1.1*Feb 3 17:42:52.567: IGMP(0): WAVL Insert group: 232.1.1.1 interface: GigabitEthernet1/0Successful
*Feb 3 17:42:52.571: IGMP(0): Create source 1.1.1.1
*Feb 3 17:42:52.571: IGMP(0): Building v3 Report on GigabitEthernet1/0
*Feb 3 17:42:52.575: IGMP(0): Add Group Record for 232.1.1.1, type 5
*Feb 3 17:42:52.575: IGMP(0): Add Source Record 1.1.1.1*Feb 3 17:42:52.575: IGMP(0): Add Group Record for 232.1.1.1, type 6
*Feb 3 17:42:52.579: IGMP(0): No sources to add, group record removed from report
*Feb 3 17:42:52.579: IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet1/0
From the above we can see that an IGMP membership report is being sent out and we are specifically saying we want the source to be 1.1.1.1.
IGMPv3 is going to be used for a host of reasons, but our main concern with it for our CCIE DC is it's use in SSM (Source specific multicast), SSM in combination with IGMPv3 means that we already now know the source address of the multicast stream, we don't need an RP to tell us that: the receiver requesting the stream has told us via IGMPv3! So since we already know the Source address, we can just send a normal join request up the tree towards the source! No more shared trees, yet we are still using PIM Sparse Mode, Hooray!
SSM has other advantages too, because we are now joining multicast groups based on an (S,G) Entry, because the S is always unique, we can avoid multicast collision, let's say for example you wanted to stream out on the internet, you have this great idea for "the next youtube" using multicast, so you start sending multicast traffic to 238.0.0.1, what's to stop someone else using that exact same address at some point in time to stream THERE multicast traffic? Why should the ISP your using forward this traffic for you? How do they know you have receivers who really want to hear this traffic? With SSM every multicast stream is unique because the multicast route is: (S,G), not (*,G)
The 232.0.0.0/8 range has been set aside by the IETF for use on the internet for SSM multicast.
Let's load up our topology files and start checking this out!
If you read my first Multicast post, you will know that this is a LIVE follow along blog post that you can try out yourself, all the config's you need for GNS3 and the topology file is available: here
Here is a diagram of the network:
Ok let's get started.
Once you have enabled PIM sparse mode on all interfaces, the only remaining bit of configuration is to enable SSM for your multicast range with the following command on each router (Except the source and receiver routers)
ip pim ssm default
The default keyword tells PIM to treat the range 232.0.0.0/8 as an SSM range, you could specify any range you wanted here however.
Let's take a look at what happens when our receiver joins the multicast group.
Receiver1:
interface GigabitEthernet1/0
ip address 2.2.2.1 255.255.255.0
ip pim sparse-mode
ip igmp join-group 232.1.1.1 source 1.1.1.1
ip igmp version 3
You can see the config....
You see the messages get sent:
debug ip igmp
eb 3 18:56:55.539: IGMP(0): Building v3 Report on GigabitEthernet1/0
*Feb 3 18:56:55.543: IGMP(0): Add Group Record for 239.1.1.1, type 5
*Feb 3 18:56:55.547: IGMP(0): No sources to add, group record removed from report
*Feb 3 18:56:55.551: IGMP(0): Add Group Record for 239.1.1.1, type 6
*Feb 3 18:56:55.551: IGMP(0): Add Source Record 1.1.1.1
*Feb 3 18:56:55.551: IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet1/0
But for some reason... the multicast routing table on PIM2 does not update
PIM2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:09:50/00:02:12, RP 0.0.0.0, flags: DL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2/0, Forward/Sparse, 00:09:37/stopped
Let's investigate further, perform a debug ip igmp on PIM2 and you will get your answer:
*Feb 3 18:58:41.547: IGMP(0): Received v3 Query on GigabitEthernet2/0 from 2.2.2.1
*Feb 3 18:58:45.535: IGMP(0): v3 report on interface configured for v2, ignored
Ahh, it is now obvious what has happened, you need to specify version 3 IGMP for this interface, this is an example of the kind of troubleshooting you might have to do as part of the CCIE DC, so keep it in mind!
Ok, let's enable IGMP V3 on PIM2 and watch what happens...
PIM2(config)#int gi2/0
PIM2(config-if)#ip igmp version 3
*Feb 3 18:59:50.507: IGMP(0): Switching IGMP version from 2 to 3 on GigabitEthernet2/0
*Feb 3 18:59:50.511: IGMP(0): The v3 querier for GigabitEthernet2/0 is this system
*Feb 3 18:59:50.515: IGMP(0): Send v3 init Query on GigabitEthernet2/0
*Feb 3 18:59:51.931: IGMP(0): Received v3 Report for 2 groups on GigabitEthernet2/0 from 2.2.2.1
*Feb 3 18:59:51.931: IGMP(0): Received Group record for group 224.0.1.40, mode 2 from 2.2.2.1 for 0 sources
*Feb 3 18:59:51.931: IGMP(0): WAVL Insert group: 224.0.1.40 interface: GigabitEthernet2/0Successful
*Feb 3 18:59:51.935: IGMP(0): Switching to EXCLUDE mode for 224.0.1.40 on GigabitEthernet2/0
*Feb 3 18:59:51.935: IGMP(0): Updating EXCLUDE group timer for 224.0.1.40
*Feb 3 18:59:51.935: IGMP(0): MRT Add/Update GigabitEthernet2/0 for (*,224.0.1.40) by 0
*Feb 3 18:59:51.939: IGMP(0): Received Group record for group 232.1.1.1, mode 1 from 2.2.2.1 for 1 sources*Feb 3 18:59:51.943: IGMP(0): WAVL Insert group: 232e: GigabitEthernet2/0Successful
*Feb 3 18:59:51.943: IGMP(0): Create source 1.1.1.1
*Feb 3 18:59:51.943: IGMP(0): Updating expiration time on (1.1.1.1,232.1.1.1) to 180 secs
*Feb 3 18:59:51.943: IGMP(0): Setting source flags 4 on (1.1.1.1,232.1.1.1)
*Feb 3 18:59:51.943: IGMP(0): MRT Add/Update GigabitEthernet2/0 for (1.1.1.1,232.1.1.1) by 0
*Feb 3 18:59:51.963: PIM(0): Insert (1.1.1.1,232.1.1.1) join in nbr 10.0.0.1's queue
*Feb 3 18:59:51.979: PIM(0): Building Join/Prune packet for nbr 10.0.0.1
*Feb 3 18:59:51.983: PIM(0): Adding v2 (1.1.1.1/32, 232.1.1.1), S-bit Join
*Feb 3 18:59:51.983: PIM(0): Send v2 join/prune to 10.0.0.1 (GigabitEthernet3/0)
Let's go through these entries shall we? First thing we see once we enable IGMPv3 on the interface is that the router basically asks "Hey guys is anyone out there?", our receiver router sends a report back "Hey I am here!" and I am part of a few groups!, the first group is 224.0.1.40 which we don't really care about, but the next one is the one we DO care about, we have received a group request for 232.1.1.1 and important for 1 source, the source is 1.1.1.1, once we know what that source is, the router checks to see how it would route to reach 1.1.1.1 (remember, next hop reachability!:)
PIM2#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.0.1 on GigabitEthernet3/0, 00:17:50 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 1.1.1.2, 00:17:50 ago, via GigabitEthernet3/0
Route metric is 2, traffic share count is 1
It determines the route to 1.1.1.1 is via Gi3/0, so thus a PIM join message is sent up that interface towards the neighbor.
Wooo Hoo! let's check out the routing table of the appropriate routers:
PIM2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(1.1.1.1, 232.1.1.1), 00:05:27/00:02:23, flags: sTI
Incoming interface: GigabitEthernet3/0, RPF nbr 10.0.0.1
Outgoing interface list:
GigabitEthernet2/0, Forward/Sparse, 00:05:27/00:02:23
We can see from the above output we now have an entry for the (S,G) 1.1.1.1, 232.1.1.1, the flags are quite interesting, a small s for SSM group, T for SPT-Bit Set (in other words, this is a shortest path tree not a shared tree since we have not involved an RP in any way shape or form) and finally an I Flag to say the receiver asked for a particular source!
let's look at PIM1's routing table:
PIM1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(1.1.1.1, 232.1.1.1), 00:07:10/00:03:11, flags: sT
Incoming interface: GigabitEthernet1/0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet3/0, Forward/Sparse, 00:07:10/00:03:11
The tree has been built and we haven't involved an RP at any point in time! (In my config, i don't even have an RP specified: go ahead and try it yourself without an RP!)
Let's try a ping:
Source1Receiver2#ping 232.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Reply to request 0 from 2.2.2.1, 80 ms
Success! We have a multicast tree from our source to our receiver.
Let's try getting clever here, on source1 let's create a loopback interface and see if it can reach the receiver...
Source1Receiver2(config)#int lo1
Source1Receiver2(config-if)#ip add 50.50.50.50 255.255.255.255
Source1Receiver2#ping 2.2.2.1 source lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50
!!!!!
Source1Receiver2#ping 232.1.1.1 source lo1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50
.
No dice! the source has reachability to 2.2.2.1 via 50.50.50.50, but because no multicast groups are setup for this because the host didn't ask for that source, the ping doesn't work as no multicast tree has been built on PIM1:
PIM1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(1.1.1.1, 232.1.1.1), 00:11:14/00:03:02, flags: sT
Incoming interface: GigabitEthernet1/0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet3/0, Forward/Sparse, 00:11:14/00:03:02
Some of the more observant of you might have noticed that there is no (*,G) tree at all, because there is no RP there is no way to establish an (*,G) Tree.
Let's try a few more expirements.
Create a loopback on the RP Router and specify it as the RP on PIM1 and PIM2
RP:
int lo1
ip add 3.3.3.3 255.255.255.255
Ip pim rp-address 3.3.3.3
PIM1/PIM2:
Ip pim rp-address 3.3.3.3
Now that's done, lets see what happens when we try and source traffic from 50.50.50.50 again
.
Source1Receiver2#ping 232.1.1.1 source lo1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50
.
Still no luck, why?
The reason is we have set aside this group as an SSM Group, the routers will absolutely not forward any multicast traffic for these groups unless they have specifically received a join with the source specified in the message
On the receiver router, we have turned off the source and have just specified the group, we don't have a specific source listed:
interface GigabitEthernet1/0
ip address 2.2.2.1 255.255.255.0
ip pim sparse-mode
ip igmp join-group 232.1.1.2
ip igmp version 3
!
What happens now? We changed the group number to make this easier to see to 232.1.1.2:
The ip mroute table on PIM2 doesn't show this table having been built:
PIM2#
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:31:56/00:02:15, RP 3.3.3.3, flags: SJCL
Incoming interface: GigabitEthernet1/0, RPF nbr 10.2.0.2
Outgoing interface list:
GigabitEthernet2/0, Forward/Sparse, 00:31:43/00:02:15
No entry in mcast table? won't be forwarded...
The following debug messages show for IGMP on PIM2:
*Feb 3 19:18:24.323: IGMP(0): Received v2 Query on GigabitEthernet3/0 from 10.0.0.1
*Feb 3 19:18:25.063: IGMP(0): Received v3 Report for 1 group on GigabitEthernet2/0 from 2.2.2.1
*Feb 3 19:18:25.067: IGMP(0): Received Group record for group 232.1.1.2, mode 4 from 2.2.2.1 for 0 sources
*Feb 3 19:18:25.071: IGMP(0): Group Record mode 4 for SSM group 232.1.1.2 from 2.2.2.1 on GigabitEthernet2/0, ignored
The last line tells us all we need to know: our receiver is asking to join group (*,232.1.1.2), the range 232.0.0.0/8 is a SSM group, so the (*,G), or Any Source Multicast (ASM) IGMP Join request is completely ignored.
If we join a non SSM enabled multicast range...
Source2Receiver1(config)#int gi1/0
Source2Receiver1(config-if)#ip igmp join
Source2Receiver1(config-if)#ip igmp join-group 239.1.1.1
Our multicast table is built as normal, facing towards the RP.
PIM2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:00:09/00:02:50, RP 3.3.3.3, flags: SJC
Incoming interface: GigabitEthernet1/0, RPF nbr 10.2.0.2
Outgoing interface list:
GigabitEthernet2/0, Forward/Sparse, 00:00:09/00:02:50
So as you can see, multicast SSM and normal groups can live together in complete harmony.
I hope SSM has been adequately described to you. The Next blog post we will look at Bi-Directional PIM.
