The fourth question was:

* What happens when the receiver decides it wants to bypass the RP for group 239.0.1.23 and receive the multicast stream directly from the host?

Answer: So this is a pretty easy one (which makes me feel dumb for not writing it sooner).  By default, in sparse mode, a Cisco router with an attached listener will attempt to form a source-path tree (from the root-path tree) after receiving the first packet of data from the source.   Essentially, this means that in sparse mode, the receivers rely upon the RP to be the root of a tree which sends the stream of data that it’s interested in.  This is because it doesn’t really know where the sender is coming from (it could be unknown or from multiple places).  Once the router attached to the receiver realizes where the source of the stream is coming from, it can get it directly from the source.

How does this work?  Glad you asked.  Take a look at the following diagram.

Router B is going to be sending the data from the Source to the RP.   But look at the RP! The root path three is highlighted in red. It doesn’t make much sense for the Host to receive this data in this roundabout manner.  Why can’t Router A just get the stream from Router B?  That’s exactly what happens when Router A realizes that it received the data from an interface that isn’t consistent with it’s routing table.  Imagine that you could view Router A’s routing table.  It would show that the shortest path to get to the Source would be through Router B.  So Router A sends a PIM Join message to Router B which allows it to bypass the RP.  Now the flow follows the highlighted blue line. Much more efficient.

Can this behaviour be changed?  Absolutely.  The command (global) to use is:

ip pim spt-threshold <rate (in Kbps)>

When the configured rate is exceeded, the change to a SPT will be made.  If you send it to 0, the change will never occur.

The third question was:

* If the host is sending data for group 239.0.1.23 (and sparse-mode is being used), which router (A or B) is going to forward the stream to the RP?

Answer: If you take a look back at the answer to Multicast Question #1, the host will send an IGMP membership report using the destination address of the group (in this case, 239.0.1.23).  If both router A and B are listening to these IGMP messages, they will both receive the same membership report.  It is then the job of the router (A or B) to send the PIM Register message to the RP.  Assuming that there are hosts out there somewhere who want to receive the stream, the RP will accept the PIM Register message and the stream will head toward the RP.  Of course, the question was, WHICH router?!  The answer is the same as it was in Question #1.  The PIM DR for the segment will be the forwarder.

After firing up GNS3, we run a test:

R1#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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.1.23), 00:03:23/stopped, RP 192.168.0.1, flags: SJPCF
  Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.1
  Outgoing interface list: Null

(10.0.1.110, 239.0.1.23), 00:03:23/00:02:57, flags: FT
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
  FastEthernet0/1, Forward/Sparse, 00:00:07/00:02:52

Notice the flags that are set on the (*,G) entry.  The ‘C’ flag is set which indicates that there is a device connected to the router which belongs to the group.  In the (S,G) entry the RPF nbr of 0.0.0.0 means that it is connected to the sender.  It looks like our PIM DR theory proved true!

The second question was:

* Which router (A or B) is going to send the queries to the LAN to determine if there are any more active listeners?

Answer:  Obviously, only one of the routers should query the LAN to determine if there are any listening hosts.  IGMP determines which router should send the queries on to the segment using the IP addresses.  If R2 sends it’s query first, R1 will hear the query and determine that R2 should be the active querier on the segment because R2’s IP address is lower.  The opposite could happen, and R1 might be active first, send the query and then R2 could come alive.  In this case, R2 would see that it has a lower IP address and send it’s query.  R1 would then hear the query from a lower IP address and reliquesh it’s duties to R2.   So what happens if R2 fails?  R1 has a timer called the ‘query timeout’.  If that time runs out and R1 hasn’t heard a query from R2, it takes control and starts to query.

You can make a router join a specific multicast group to verification purposes.  This is great for testing in the lab:

First, join an interface to the group:

Router(config-if)# ip igmp join-group group-address [source source-address]

Now if you ping the group address from another router, you should be able to verify correct configuration using the ’show ip mroute’ command.  Remember that if you’ve joined the group and specified a specific source, you’ll only get a response when you ping from that source.

To enable a router to support Source Specific Multicast (SSM), you need to do two things:

1) Enable IGMPv3

Router(config-if)# ip igmp version 3

2) Enable SSM

Router(config)# ip pim ssm {default | range access-list}

Use default to use the standard SSM range of 232.0.0.0/8 or use an ACL to allow a different range of multicast addresses

First, enable multicast routing:

Router(config)# ip multicast-routing

Next, you must make sure that there is multicast connectivity between all of the nodes within the multicast network.  This can get a little tricky for a couple of reasons:

1) Frame-relay must support the multicasting between spoke nodes.  Either inverse-arp is enabled with dynamic mapping or make sure you have the mapping statically configured with the broadcast flag

2) The sparse-dense problem.  For RP mapping to occur using autoRP, the two multicast group which are utilized must be in dense mode.  Remember that autoRP is used to dynamically discover RPs.  If the autoRP mapping agent sends out the mappings, it must flood them to the multicast network otherwise the RP will have to be known before anyone can join that group.  Obviously there’s some recursion there, so to avoid this, make sure one of the following is going on: dense mode or sparse-dense mode is enabled on all interfaces OR configure ‘ip pim autorp listener‘ in global config mode.

Router(config-if)# ip pim sparse-dense-mode

or

Router(config)# ip pim autorp listener

Configure the RP to send out announcements that it’s the RP (these are sent to group 224.0.1.239):

Router(config)# ip pim send-rp-announce {interface-type interface-number | ip-address} scope ttl-value [group-list access-list] [interval seconds] [bidir]

NOTE:  Make sure if you’re using the sparse-dense method, that the interface that is configured to source these announcements has the ip pim sparse-dense-mode configured.

Now, configure the mapping agent to send out the announcements:

Router(config)# ip pim send-rp-discovery [interface-type interface-number] scope ttl-value [interval seconds]

If needed, you can filter certain nodes from becoming the RP for a group.  This is done on the mapping agent with the following command:

Router(config)# ip pim rp-announce-filter rp-list access-list group-list access-list

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Verification of autoRP

Router(config)# show ip pim rp mapping