Unicast is defined as sending IP traffic from one host to another. Broadcast is sending traffic from one host to all hosts; whether the recipient host is interested or not, it will receive the traffic. Broadcast is commonly used in the LAN environment.

Multicast, on the other hand, is the method of sending traffic from one host to many receivers that are interested in what the source host is sending. Multicast uses the Class D IP address range from 224.0.0.0 to 239.255.255.255 to distinguish different multicast groups. The source of the multicast traffic sends the traffic to a multicast address and any interested host tells its multicast networking device that it wants to receive traffic from a particular group. The figure below shows the traffic flow differences between unicast, broadcast, and multicast. This shows how scalable multicast is where bandwidth is concerned.

There are different multicast address ranges based on their purpose.

Multicast employs a variety of protocols but the most common are IGMP and PIM. IGMP (Internet group management protocol) is used for communications between the end hosts and network devices. IGMP has several type of “messages”; the two most common are membership report and membership query. Membership report is used by hosts to inform the router that there is a host interested in receiving traffic for a multicast group. Membership query is used for routers to check if there are hosts interested in receiving traffic for a group. There are three versions of IGMP, of which versions 2 and 3 are most commonly used.

PIM (protocol independent multicast) is a protocol commonly used for router-to-router communications. This protocol is used to build the multicast routing. It’s called independent because it works with any unicast routing protocol used. PIM has two common modes, dense and sparse. Dense is commonly used where bandwidth is not an issue, as in LAN environments. It can also be used as interim solutions and quick deployment because it is easy to deploy. Dense mode behavior is “flood and prune,” meaning it just floods out multicast traffic and waits for other routers to tell the sending router to stop because there are no interested hosts in a particular router. Sparse mode is commonly used in the WAN environment where bandwidth can be a concern. Sparse mode uses RP (rendezvous point). Routers with hosts joining a multicast group register with the RP and RP sends the multicast traffic to these routers. The source also sends the traffic to the RP so that the RP can distribute it to the routers with member hosts. This is called a “shared tree.” This is the initial behavior for sparse. However, there is a feature that allows the routers to directly register to the router of the multicast source, bypassing the RP. This happens when there is an optimal path from the source to the member. This called the shortest path tree.

Now that we have a brief introduction to multicast concepts, let’s proceed with our lab. Our tasks will be:

  1. OSPF has been preconfigured. Check OSPF neighborship by pinging a multicast address.
  2. Configure multicast routing on all of the devices. Enable PIM dense mode on all of the interfaces with connected routers except the serial link between R2 and R4.
  3. Configure R1’s loopback0 to join multicast group 239.1.1.1. Simulate R5’s loopback0 as the multicast source.
  4. Configure an OSPF cost of 1 on the serial link between R2 and R4 and OSPF Cost of 10 on the Fa0/1 between the two routers. Shut link between R3 and R4. Verify if the multicast routing is working. Fix if there is a problem.
  5. Unshut the interface between R4 and R3. Configure sparse mode on all point-to-point interfaces. R3 should be the RP for 239.3.3.3 while R4 should be the RP for 239.4.4.4.
  6. Simulate R5 as the source for 239.3.3.3 and 239.4.4.4. R1 Loopback0 joins 239.3.3.3 while R2 joins 239.4.4.4.

Task 1: OSPF has been preconfigured. Check OSPF neighborship by pinging a multicast address.

R1#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 1.1.1.1, 1 ms
Reply to request 0 from 10.1.13.3, 24 ms
Reply to request 0 from 10.1.12.2, 24 ms

R2#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 2.2.2.2, 1 ms
Reply to request 0 from 10.1.12.1, 16 ms
Reply to request 0 from 10.1.24.4, 16 ms

R3#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 3.3.3.3, 4 ms
Reply to request 0 from 10.1.13.1, 20 ms
Reply to request 0 from 10.1.34.4, 20 ms

R4#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 4.4.4.4, 1 ms
Reply to request 0 from 10.1.45.5, 20 ms
Reply to request 0 from 10.1.24.2, 20 ms
Reply to request 0 from 10.1.34.3, 20 ms

R5#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 5.5.5.5, 1 ms
Reply to request 0 from 10.1.45.4, 24 ms

The multicast IP address 224.0.0.5 is used by all OSPF routers for the operation of the protocol. This belongs to the locally scoped multicast IP addresses and is not forwarded. IANA has a list of well-known multicast groups and can be found here. When the ping was done, the router sent out the ping all interfaces that are OSPF enabled.

Task 2: Configure multicast-routing on all of the devices. Enable PIM dense mode on all of the interfaces with connected routers except the serial link between R2 and R4.

R1(config)#ip multicast-routing
R1(config)#int fa0/0
R1(config-if)#ip pim dense-mode
R1(config-if)#int fa0/1
R1(config-if)#ip pim dense-mode

R2(config)#ip multicast-routing
R2(config)#int fa0/0
R2(config-if)#ip pim dense-mode
R2(config-if)#int fa0/1
R2(config-if)#ip pim dense-mode

R3(config)#ip multicast-routing
R3(config)#int fa0/0
R3(config-if)#ip pim dense-mode
R3(config-if)#int fa0/1
R3(config-if)#ip pim dense-mode

R4(config)#ip multicast-routing
R4(config)#int fa0/0
R4(config-if)#ip pim dense-mode
R4(config-if)#int fa0/1
R4(config-if)#ip pim dense-mode
R4(config-if)#int fa1/0
R4(config-if)#ip pim dense-mode

R5(config)#ip multicast-routing
R5(config)#int fa1/0
R5(config-if)#ip pim dense-mode

Always remember to enable “ip multicast-routing” so PIM and other multicast protocols will work. Let’s check the PIM neighbors and interfaces by issuing the “show ip pim neighbors” and “show ip pim interface” commands on R4.

R4#sh ip pim int

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
10.1.34.4        FastEthernet0/0          v2/D   1      30     1      10.1.34.4
10.1.24.4        FastEthernet0/1          v2/D   1      30     1      10.1.24.4
10.1.45.4        FastEthernet1/0          v2/D   1      30     1      10.1.45.5
R4#sh ip pim neigh
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.1.34.3         FastEthernet0/0          00:02:33/00:01:38 v2    1 / S
10.1.24.2         FastEthernet0/1          00:02:30/00:01:41 v2    1 / S
10.1.45.5         FastEthernet1/0          00:01:51/00:01:22 v2    1 / DR S

The PIM DR is responsible for forwarding join messages from the host to the RP. This means that DR is not relevant to PIM dense mode where there is no RP required. The PIM DR is elected on a per-segment basis and is typically the router that has the highest IP address. To change the DR, the “ip pim dr priority” command can be used.

Task 3: Configure R1’s loopback0 to join multicast group 239.1.1.1. Simulate R5’s loopback0 as the multicast source.

R1(config)#int loopback0
R1(config-if)#ip igmp join-group 239.1.1.1

R5#ping 239.1.1.1 source l0

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 

Reply to request 0 from 10.1.13.1, 64 ms

The command “ip igmp join-group” makes a router interface join a particular multicast group. This command is often used to test multicast connectivity by simulating a host joining the group. R5 is simulated as the source by pinging the group 239.1.1.1 and sourcing the pings from the Loopback0.

We can check the multicast route by issuing the command below:

R3#sh ip mroute 239.1.1.1 | beg Interface
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:04:07/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:04:07/00:00:00
    FastEthernet0/0, Forward/Dense, 00:04:07/00:00:00

(10.1.45.5, 239.1.1.1), 00:00:55/00:02:12, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 10.1.34.4
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:00:55/00:00:00

RPF, or reverse path forwarding is a method used by multicast to ensure a loop-free traffic flow and prevent any IP spoofing. RPF verifies that the traffic from the source is received from the interface that is used to reach the source. It uses the unicast routing table to verify if RPF passes. In our case, to reach 10.1.45.5, the interface FastEthernet0/0 is used and, since multicast traffic from R5 to R1 uses this, then the RPF check is successful. OIL (the outgoing interface list) is what the router uses to forward the traffic towards the destination, which in our case is R1.

Task 4: Configure an OSPF cost of 1 on the serial link between R2 and R4 and OSPF Cost of 10 on the Fa0/1 between the two routers. Shut link between R3 and R4. Verify if the multicast routing is working. Fix if there is a problem.

R4(config)#int fa0/0
R4(config-if)#shut
R4(config-if)#int fa0/1
R4(config-if)#ip ospf cost 10
R4(config-if)#int se2/0
R4(config-if)#no shut
R4(config-if)#ip ospf cost 1

R2(config)#int se2/0
R2(config-if)#no shut
R2(config-if)#ip ospf cost 1
R2(config-if)#int fa0/1
R2(config-if)#ip ospf cost 10

Let’s try that ping again from R5 to R1.

R5#ping 239.1.1.1 source l0 rep 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
.....

The ping eventually fails because of the RPF check failure. The best path to reach 10.1.45.5 is through Serial2/0, however this interface is not configured with PIM.

R1#traceroute 10.1.45.5

Type escape sequence to abort.
Tracing the route to 10.1.45.5

  1 10.1.12.2 24 msec 12 msec 24 msec
  2 172.16.24.4 40 msec 36 msec 44 msec
  3 10.1.45.5 68 msec 68 msec *

Let’s fix the problem by creating a static mroute. This is used as a solution to those RPF check failures.

R2(config)#ip mroute 0.0.0.0 0.0.0.0 10.1.24.4

R5#ping 239.1.1.1 source l0 rep 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 

Reply to request 0 from 10.1.12.1, 64 ms
Reply to request 1 from 10.1.12.1, 60 ms
Reply to request 2 from 10.1.12.1, 60 ms.
Reply to request 4 from 10.1.12.1, 56 ms

Task 5: Unshut the interface between R4 and R3. Configure sparse mode on all point-to-point interfaces. R3 should be the RP for 239.3.3.3 while R4 should be the RP for 239.4.4.4.

R1(config)#int fa0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#int fa0/1
R1(config-if)#ip pim sparse-mode

R2(config)#int fa0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int fa0/1
R2(config-if)#ip pim sparse-mode

R3(config-if)#int fa0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#int fa0/1
R3(config-if)#ip pim sparse-mode

R4(config)#int fa0/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#int fa0/1
R4(config-if)#ip pim sparse-mode

R5(config)#int fa1/0
R5(config-if)#ip pim sparse-mode

Sparse mode is configured similarly in the interface as dense. The difference now is that we need an RP. For this lab, we will deal with static RPs. The dynamic means to get RP information is through auto-RP and BSR, which we will discuss in the next article.

On all routers:

ip access-list standard R3-RP
 10 permit host 239.3.3.3
!
ip access-list standard R4-RP
 10 permit host 239.4.4.4
!
ip pim rp-address 3.3.3.3 R3-RP
ip pim rp-address 4.4.4.4 R4-RP

The commands below need to be configured on all routers, including the RPs themselves. If there is no access-list specified, then the IP address specified becomes the RP for all groups. Let’s check the RP mappings.

R1#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Acl: R3-RP, Static
    RP: 3.3.3.3 (?)
Acl: R4-RP, Static
    RP: 4.4.4.4 (?)

Task 6: Simulate R5 as the source for 239.3.3.3 and 239.4.4.4. R1 Loopback0 joins 239.3.3.3 while R2 joins 239.4.4.4.

R1(config-if)#int Loopback0 
R1(config-if)#ip pim sparse-mode
R1(config-if)#ip igmp join-group 239.3.3.3

R2(config)#int Loopback0
R2(config-if)#ip pim sparse-mode
R2(config-if)#ip igmp join-group 239.4.4.4

R5#ping 239.3.3.3 rep 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.3.3.3, timeout is 2 seconds:

Reply to request 0 from 10.1.13.1, 60 ms
Reply to request 1 from 10.1.13.1, 60 ms
Reply to request 2 from 10.1.13.1, 56 ms
Reply to request 3 from 10.1.13.1, 60 ms
Reply to request 4 from 10.1.13.1, 60 ms

R5#ping 239.4.4.4 rep 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:

Reply to request 0 from 10.1.12.2, 84 ms
Reply to request 1 from 10.1.12.2, 88 ms
Reply to request 2 from 10.1.12.2, 84 ms
Reply to request 3 from 10.1.12.2, 80 ms
Reply to request 4 from 10.1.12.2, 80 ms

R2#sh ip mroute sum       
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.4.4.4), 00:13:37/00:02:26, RP 4.4.4.4, OIF count: 1, flags: SJCL

(*, 224.0.1.40), 00:17:21/00:02:23, RP 0.0.0.0, OIF count: 1, flags: DCL


R4#sh ip pim rp 239.4.4.4  
Group: 239.4.4.4, RP: 4.4.4.4, next RP-reachable in 00:01:19

R3#sh ip pim rp 239.3.3.3
Group: 239.3.3.3, RP: 3.3.3.3, next RP-reachable in 00:00:27

 

Now R1 is using R3 as the RP for 239.3.3.3 and R2 for 239.4.4.4 as specified in the static RP configurations.

References

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html

http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfmulti.html