Cisco offers numerous IP video solutions that can be used in Enterprise and Service Provider environments. Cisco IP video solutions are based on the industry-standard H.323 protocol. Within the Enterprise, the Cisco Unified Video Advantage solution can be used to add video to your communications experience by providing video telephony functionality to Cisco Unified IP phones and the Cisco IP Communicator soft-phone application.
This solution comprises Unified Video Advantage software and Cisco VT Camera III, which is a high-definition two megapixel video telephony USB camera. In addition to the call agent, IP phones, and the Cisco VT camera, the Cisco IP video solution can also work with H.323 Multipoint Control Units (MCUs). The MCU is simply an endpoint that provides conference facilities for users who want to conference three or more endpoints together. This can be used for both audio and video calls.
While voice and video traffic share most of the same characteristics, such as being sensitive to latency and delay, there is a significant difference in the delivery of IP voice versus IP video. While IP voice traffic is Unicast, IP video is typically delivered via Multicast. For this reason, it is important to have a fundamental understanding of IP Multicast which allows you to understand how to design IP networks to support IP video. Additionally, this understanding also facilitates the support and troubleshooting of IP video in the network.
IP Multicast Fundamentals
Unicast traffic involves the transmission of packets from one particular network host to another host. This one-to-one communication is the most prevalent method of transmission used on modern networks and is very easy to implement. Until recently, there was no method to send traffic from one host to many different hosts without using Broadcast transmission.
Unfortunately, Broadcast packets are flooded to hosts that do not necessarily need to receive the packets, rendering this method very undesirable when the traffic only needs to be received by a select few hosts. Multicast transmission is similar to Broadcast in that it uses a one-to-many forwarding model. This allows a single host to transmit a single data stream which is then received by multiple hosts. The difference between Broadcast and Multicast transmission lays in which hosts process the traffic. Multicast packets are sent only to a particular group of interested hosts which is performed by sending a single packet to the Multicast group address. This means that only the hosts that belong to that Multicast group address receive the packets.
Layer 3 Multicast Addressing
In order to use IP Multicast, special or reserved IP addresses are required. When a receiving host wishes to receive Multicast traffic, it sends a request to a network device requesting to receive traffic from a group address. A sending host generates packets and sends them to this group address, which it specifies in the destination field of the IP header. Each Multicast data stream is uniquely identified by the combination of the traffic source and the group address.
The IP address range used by Multicast is the Class D address space ranging from 224.0.0.0 to 239.255.255.255. This address range is exclusively reserved for IP Multicast traffic by IANA. Within this range, certain addresses are further reserved for special purposes. The IETF has provided the IANA with guidance on how IP Multicast address space should be allocated in RFC 3171. These special Multicast addresses and their usage are illustrated in Table 12-2:
| Multicast Address Range | Multicast Address Mask | Description |
|---|---|---|
| 224.0.0.0–224.0.0.255 | 255.255.255.0 | Local Network Control Block |
| 224.0.1.0–224.0.1.255 | 255.255.255.0 | Internetwork Control Block |
| 224.0.2.0–224.0.255.255 | N/A | Ad Hoc Block |
| 224.1.0.0–224.1.255.255 | N/A | Unassigned |
| 224.2.0.0–224.2.255.255 | 255.255.0.0 | SDP/SAP Block |
| 224.3.0.0–231.255.255.255 | N/A | Unassigned |
| 232.0.0.0–232.255.255.255 | 255.0.0.0 | Source Specific Multicast Block |
| 233.0.0.0–233.255.255.255 | 255.0.0.0 | GLOP Block |
| 234.0.0.0–238.255.255.255 | N/A | Unassigned |
| 239.0.0.0–239.255.255.255 | 255.0.0.0 | Administratively Scoped Block |
The 224.0.0.0/24 address range is reserved for local Multicast transmissions. This address range is commonly referred to as the Link Local Block. This means that packets destined to any address in this range are not forwarded any further than the local segment. This range is used by routing protocols, for example.
The range of 224.0.1.0 through 224.0.1.255 is the Internetwork Control Block. These IP addresses are similar to the Link Local address range except for the fact that they are used by network protocols when control messages need to be Multicast beyond the local network segment. The Multicast messages sent with the same IP TTL value of traditional Unicast packets, which allows all routers along to path to forward these packets beyond the local link. Examples of applications or protocols that use addresses in this range include Cisco Rendezvous Point (RP) messages. RPs and RP messages are described in additional detail later in this chapter.
The Multicast group range of 224.0.2.0 through 224.0.255.255 is referred to as the Ad Hoc Block. Multicast addresses in this range have been assigned to applications that fall somewhere in between the Link Local and Internetwork Control Multicast groups. This Multicast address range is only assigned by IANA under special circumstances.
The SDP/SAP Block uses the Multicast address range of 224.2.0.0 through 224.2.255.255, with a subnet mask of 255.255.0.0, or /16. This block of addresses is reserved for applications that send and receive multimedia session announcements using the SAP described in RFC 2974. A common example of an application that uses SAP is the Session Directory tool (SDR), which transmits global scope SAP announcements on groups 224.2.127.254 and 224.2.127.255. SDR is beyond the scope of the TSHOOT exam and will not be described in an further detail.
The Multicast group range of 232.0.0.0 through 232.255.255.255 (232/8) is reserved for Source Specific Multicast (SSM). SSM is supported in IGMPv3, and described in RFC 3569. Under normal circumstances, an end host requests a connection to the Multicast group address and it is connected to the closest source of the traffic, which is typically determined by routing protocol metrics. However, with SSM, an end station can request and receive data streams for a Multicast group from a specific source of the traffic. IGMP is described later in this chapter.
The 233.0.0.0 /8 address range is reserved for Multicast GLOP addressing, as defined in RFC 2770. This block of addresses has been assigned by the IANA as an experimental, statically assigned range of Multicast addresses intended for use by Content Providers, ISPs, or anyone wishing to source content into the Internet. GLOP addressing is beyond the scope of the TSHOOT and is not described in any detail in this chapter or in the remainder of this guide.
And finally, the 239.0.0.0 /8 address range is defined in RFC 2365 and is reserved for Multicast addresses that are locally significant to that specific Multicast domain. In other words, they do not cross the boundaries of the domain. This is a similar concept to RFC 1918 address space, which cannot be used on the Internet. The key properties of these IP Multicast addresses are:
- Packets addressed to Administratively Scoped Multicast addresses do not cross configured administrative boundaries, which are called Zones or Scoped Zones
- Administratively Scoped Multicast addresses are locally assigned and are not required to be unique across administrative boundaries
Layer 2 Multicast Addressing
When Multicast traffic reached the network edge the packet must be converted to a frame and forwarded to hosts that belong to the Multicast group and requested the packet. In a Unicast transmission, the router determines the destination MAC address of the host or hosts by using the Address Resolution Protocol (ARP).
IP Multicast presents a problem in this method of address resolution in that because the number of stations wishing to receive Multicast packets can change at any time, the router would always have to send Broadcast ARP requests to determine which hosts still belong to the Multicast groups and then forward the frames to the received destination addresses. However, this results in an excessive amount of ARP Broadcasts on the network, which is not desirable. In addition to this, the router would need to send a single copy of the frame to every host that responds, which defeats the purpose of Multicast, where a single frame is sent to a single group address, avoiding multiple copies of the same packet to multiple hosts.
In order to address these issues, the IEEE makes provisions for the transmission of IP Multicast and Broadcast packets via the use of the Broadcast/Multicast and Address Distinguisher bits in a MAC address. The first bit of the first octet in an IEEE MAC address indicates whether the destination address of the frame is a Broadcast, Multicast or Unicast address. This is the Broadcast/Multicast bit. If this bit is set, the MAC frame is destined either for an arbitrary group of hosts or all hosts on the network. If this bit is not set, i.e. the field contains a 0; the MAC frame is destined for a single host. IP Multicasting at Layer 2 uses this capability to transmit IP multicast packets to a group of hosts on a LAN segment.
The second bit of the first byte is the Address Distinguisher bit. MAC addresses can either be universally administered addresses or locally administered addresses. A universally administered address is uniquely assigned to a device by its manufacturer; these are sometimes called burned-in addresses, or BIA. A locally administered address is assigned to a device by a network administrator, overriding the burned-in address. Locally administered addresses do not contain Organizationally Unique Identifier (OUI) which is used to uniquely identify a vendor, manufacturer, or other organization. Figure 12-2 shows the location of these bits in a standard MAC address:
Fig. 12-2. Broadcast/Multicast and Address Distinguisher Bits
To support Multicast capability at Layer 2, a process for encoding a specific IP Multicast group address within an Ethernet destination MAC address has been defined. This process allows routers to transmit each data packet onto the network only once and each interested end station receives the data only once, which negates the need for the router or the hosts to continuously send Address Resolution Protocol (ARP) requests.
All Multicast frames begin with the 24-bit prefix of 0x0100.5E. To determine the Multicast MAC address for a specific group, we take the last 23 bits of the Multicast group address and prepend a single 0 bit to them. These 24 bits now form the lower half of the 48-bit MAC address. This concept may be somewhat confusing at first glance, therefore, we will go over a few examples illustrating how a Layer 3 Multicast address is mapped to a Layer 2 Multicast address.
In order to map Layer 3 Multicast addresses to Layer 2 Multicast addresses it is imperative that you understand that MAC addresses use Hexadecimal Numbering while IP addresses use Decimal Numbering. This means that any Decimal values in the last 23 bits of the IP address must be mapped to the Hexadecimal equivalent in the MAC address. The Decimal numbers 0 through 9 are also represented as 0 through 9 in Hexadecimal. However, the Decimal numbers 10 through 15 are represented by the letters A through F in Hexadecimal.
In the first example, we will demonstrate how to map the Layer 3 IP Multicast address 227.7.7.7 to a Layer 2 Multicast address. The first step is to write out the OUI used by all Layer 2 Multicast addresses. This is illustrated in Figure 12-3:
Fig. 12-3. Mapping Multicast Addresses at Layer 2
The second step is to convert the last 23 bits of the IP Multicast group address to their Binary value equivalent. In order to complete the 24-bit address, the last bit of the first octet will always be set to zero (0). In Binary notation, 7.7.7 would be written as 00000111. 00000111. 00000111. This transformation is illustrated in Figure 12-4:
Fig. 12-4. Mapping Multicast Addresses at Layer 2, contd.
The third step is to add these bits to the MAC address (in their Hexadecimal equivalent form) to complete the Layer 2 Multicast OUI. 0000 0111 in Binary is the equivalent of 0 7 in Decimal. 0 7 in Decimal is the equivalent of 0 7 in Hexadecimal. These values are added to the Layer 2 Multicast OUI, which results in the Layer 2 Multicast address of 0100:5E07:0707 for the Layer 3 Multicast address of 227.7.7.7. The Layer 2 Multicast group address is shown in Figure 12-5:
Fig. 12-5. Mapping Multicast Addresses at Layer 2, contd.
Alternatively, the address can also be written as 01:00:5E:07:07:07. Either format is acceptable.
In the second example, we will be converting the Multicast group address 228.224.150.1 to the equivalent Layer 2 Multicast address. Again, the first step is to write out the OUI used by all Layer 2 Multicast addresses, which is 01-00-5e. Following this, the second step entails converting the last 23 bits of the Layer 3 Multicast group address to their Binary equivalent. The last 23 bits are included in the last three octets, which have the values 224.150.1. In Binary notation, these bits would be written as 11100000.10010110.00000001.
The third step is to add these bits to the MAC address (in their Hexadecimal equivalent form) to the Layer 2 Multicast OUI. This is performed by converting the Binary values to Decimal and then converting the Decimal values to Hexadecimal. Because the last bit in the first octet is always set to zero, the first octet would be 0110 0000 which is the equivalent of 6 0 in Hexadecimal. The second octet, 1001 0110 is the equivalent of 9 6 in Hexadecimal. And finally, the third octet, 0000 0001 is the equivalent of 0 1 in Hexadecimal. The Layer 2 Multicast address of the Layer 3 address 224.150.1 is 0100:5E60:9601 as illustrated in Figure 12-6:
Fig. 12-6. Mapping Multicast Addresses at Layer 2, contd.
In the third and final example, we will be converting the Multicast group address 239.135.7.7 to the equivalent Layer 2 Multicast address. As we learned in the previous example, the first step is to write out the OUI used by all Layer 2 Multicast addresses. Next, the second step is to convert the last 23 bits of the Layer 3 Multicast group address to their Binary equivalent. The last 23 bits are included in the last three octets, which have the values 135.7.7. In Binary notation, these bits would be written as 100000111.00000111.00000111.
The third step is to add these bits to the MAC address (in their Hexadecimal equivalent form) to the Layer 2 Multicast OUI. This is performed by converting the Binary values to Decimal and then converting the Decimal values to Hexadecimal. Because the last bit in the first octet is always set to zero, the first octet would be 0000 0111 which is the equivalent of 0 7 in Hex.
The second octet, 0000 0111 is the equivalent of 0 7 in Hexadecimal. And finally, the third octet, 0000 00111 is the equivalent of 0 1 in Hexadecimal. The Layer 2 Multicast address of the Layer 3 address 239.135.7.7 is 0100:5E07:0707 address is illustrated in Figure 12-7:
Fig. 12-7. Mapping Multicast Addresses at Layer 2, contd.
You will notice that this is the same Layer 2 Multicast address as the one derived for Layer 3 Multicast group 227.7.7.7. This example was purposely designed to illustrate and highlight a very important fact in regards to Layer 3 to Layer 2 Multicast address mapping. This fact is Layer 2 Multicast address ambiguity.
Layer 2 Multicast address ambiguity occurs because only 23 bits of the IP Multicast address are used when a Layer 3 Multicast address is mapped to a Layer 2 IEEE MAC address which results in a 32:1 address ambiguity. This means that each Layer 2 Multicast MAC can represent 32 different IP Multicast addresses. In other words, each Layer 3 Multicast address will have 31 other Layer 3 Multicast addresses using the same Layer 2 MAC address.
NOTE: The number 32 is derived by simply multiplying the number of addresses in the valid Multicast range (i.e. 224 – 240) by the number 2.
As an example, assume that four (4) different Multicast groups are configured on a network and these groups are assigned group addresses 224.1.1.1, 224.129.1.1, 225.1.1.1 and 225.129.1.1. Because of Layer 3 to Layer 2 Multicast address ambiguity, these four Layer 3 Multicast addresses all map to the single Layer 2 Multicast address 01:00:5E:01:01:01. Based on this address ambiguity, hosts joined to any one group will also receive traffic that is destined to one of the other three groups. Even though these hosts are not interested in this stream, they must still process the received packets before determining that they do not need them and should discard or ignore them. This consumes valuable computing resources on the hosts.
Unfortunately, the only way to resolve this issue is to allocate different Multicast addresses, if more than one Multicast group exists on a LAN. This is why it is imperative to understand the mapping of the Layer 3 Multicast address to the Layer 2 Multicast MAC. By ensuring that the allocated Layer Multicast group addresses do not translate to the same Layer 2 Multicast MAC, this inherent design flaw can be avoided.
Internet Group Management Protocol
IGMP allows receivers to request a Multicast data stream from a particular group address. The IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. Every IGMP message carries an IP Router Alert option in its IP header, as defined in RFC 2113. The IP Router Alert option notifies transit routers to more closely examine the contents of the packet.
IGMP operates between the host, referred to as the receiver, and the local router using the IP Multicast address 224.0.0.1, which is the all hosts on subnet Multicast group address. This address is part of the Link Local Multicast address range which ensures that these packets are confined only to the local network segment.
IGMP join messages defined in RFC 1112 allow the receivers to request a Multicast data stream from a particular group address. A receiver sends an IGMP ‘join group’ message to the Multicast source or sender. Each router that forwards an IGMP join message records the group ID and source interface in its Multicast forwarding table. When the sender sends IP Multicast traffic, the Layer 3 device will then forward the traffic only to those interfaces from which it has received the join messages. This ensures that the router forwards IP Multicast traffic only to those hosts that have requested it.
In the event that there is more than one router on the network segment, only a single router will translate the request into a Multicast routing protocol packet and forwards it to an appropriate source for the group. The router that performs this function is referred to as the designated router or designated querier.
RFC 2236 defines ‘leave group’ messages that enable IP Multicast-aware devices to keep current information on group membership. This message type allows Multicast receivers to leave Multicast groups when they are no longer interested in receiving Multicast packets. At a bare minimum, you should know that the function of IGMP is to enable a receiver to join a Multicast group, remain connected to that Multicast group, and (if so desired) leave that particular Multicast group. There are three versions of IGMP. These are versions 1, 2 and 3. These versions are described in additional detail in the following sections.
IGMP version 1 is defined in RFC 1112. This version of IGMP provides the most basic services to a Multicast host. IGMPv1 uses only two message types: IGMP Host Membership Queries and IGMP Membership Reports. IGMP Queries are sent by IGMPv1-enabled routers to the group address 224.0.0.1 (all hosts on subnet). IGMP Reports are sent unilaterally by hosts or in response to an IGMP Query received from a router.
IGMP version 2 is defined in RFC 2236. This version of IGMP introduces several changes that make IGMP more efficient in joining and leaving the Multicast group. IGMPv2 is backward compatible with version 1 and includes the ability for a host to explicitly notify the router that it is leaving the group address. However, there are some most important changes that have been made in IGMPv2. These changes include the following:
- The Querier Election Mechanism
- The ‘Leave Group’ Message
- The Group-Specific Query
On multi-access networks, such as Ethernet, if there is more than one (1) router on the segment, then one of the routers is elected as the designated querier router. The designated querier is the only router on the segment that sends Host Membership Query packets. This election is based on router priority values or the highest IP address if the priority values are the same.
The leave group message in IGMPv2 allows hosts to send a leave message if they are no longer interested in receiving packets from a particular Multicast group. This reduces latency in IGMPv2 compared to IGMPv1 where hosts simply ignore Query packets from the router, and the router has to wait for an interval of three times the Query interval before it times out the Multicast group. This message is sent to the all routers Multicast address of 224.0.0.2 by the host that is no longer interested in receiving packets for a particular group. However, it should be noted that in environments that have both IGMPv1 and IGMPv2 hosts, the IGMPv2 router will ignore IGMPv2 leave messages as long as IGMPv1 hosts are present.
In IGMPv2, the receiver now generates a ‘leave group’ message addressed to the 224.0.0.2 Multicast group address representing all routers on the segment. When the querier router receives the Leave message, it generates a Group-Specific Query message addressed to the group being left. This message is sent to ensure that there are no more receivers left on the network segment that might still be interested in receiving packets from that group.
The IGMP join mechanism used in IGMPv2 is the same as that in IGMPv1. The host generates a Version 2 Membership Report message addressed to the Multicast group. The local router locates an available source and begins transmitting the data stream onto the segment. The querier router also generates a Query message every 60 seconds and transmits it to the 224.0.0.1 group address representing all hosts.
The Query message contains the maximum response time value of 10 seconds, which the hosts use as their maximum random timer value before sending a Report message. A Report received by a host before its timer has expired causes that host to not send its own Report message. In other words, if there is more than one host on the network segment, only one host still sends out a Membership Report.
By default, when Protocol Independent Multicast, which is a Cisco IP Multicast routing protocol that will be described in detail later in this chapter, is enabled on a Cisco IOS router interface, IGMPv2 is enabled. In order to specify IGMPv1, the ip igmp version <version> interface configuration command must be issued on the interface on which IGMPv1 is to be run. In environments that include both IGMPv1 and IGMPv2 routers and hosts, IGMPv2 devices will send IGMPv1 messages to maintain backward compatibility. For example, an IGMPv2 host would send an IGMPv1 Membership Report to an IGMPv1 router. Likewise, an IGMPv2 router will ignore received IGMPv2 leave messages as long as IGMPv1 hosts are present.
Version 3, the most recent modification of the IGMP specification, is defined in RFC 3376. This version (IGMPv3) now allows the host to request traffic from a specific host in the network. Hosts can also specify a list of sources that they should not receive Multicast traffic from. These changes provide support for the use of Source Specific Multicast within the 232.0.0.0 /8 Multicast group address range.
While IGMPv3 is backward-compatible with versions 1 and 2, there are some changes that have been made to this new specification. These changes include the addition of the General Query and the Group-and-Source-Specific Query messages. General Queries are sent with an IP destination address of 224.0.0.1. Group-Specific and Group-and-Source-Specific Queries are sent with an IP destination address equal to the Multicast address of interest, i.e. the Multicast address of the host interested in receiving the Multicast packets. Due to this difference, the Group Address field in IGMPv3 is set to zero when sending a General Query, and set to the IP Multicast address being queried when sending either a Group-Specific Query or Group-and-Source-Specific Query. You are not required to go into additional detail on these messages.
In Cisco IOS software, default and non-default IGMP parameters can be viewed by using theshow ip igmp interface command, a sample output of which is shown below:
| R1#show ip igmp interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Internet address is 10.0.0.1/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is disabled on interface Multicast TTL threshold is 0 Multicast groups joined by this system (number of users): 227.1.1.1(1) |
Multicast Forwarding
Multicast forwarding is the manner in which Multicast traffic is forwarded. There are three Multicast forwarding mechanisms, which are:
- Reverse Path Forwarding
- Dense Mode Forwarding
- Sparse Mode Forwarding
NOTE: You are not expected to go into detail on Multicast forwarding; however, you should have a basic understanding of the forwarding mechanisms for the TSHOOT exam.
The basic function of a router is the examination of a destination IP address and the forwarding of data to the next-hop router along the path towards that particular network. This works well when the router is forwarding Unicast packets that have a specific source address.
In a Multicast network, this process is not effective because the destination IP address of the packets is the Multicast group address. This Multicast group address may contain numerous Multicast members, all physically dispersed within the network. From the perspective of the router, the packets may have to be sent out multiple interfaces. Because of this, Multicast operates in the opposite way to Unicast. While Unicast routing is concerned about where the packet is going, Multicast routing is concerned with where the packets are coming from.
The default behavior of a Multicast router is to forward the data packet out of all interfaces that are enabled for Multicast, except the interface on which the packet was received. This behavior has the potential for forming a forwarding loop in the network. To prevent forwarding loops when Multicast routing is being used, routers use the concept of Reverse Path Forwarding.
Reverse Path Forwarding (RPF) allows Multicast routers to forward packets only if the source address of the Multicast packet is received on the same interface via which that address is known in the Unicast routing table. If this condition is met, the RPF check succeeds and Multicast packets are forwarded. However, if the RPF check fails, the router will silently discard any Multicast packets received via that interface. This prevents forwarding loops within the Multicast domain.
Dense mode Multicast routing protocols assume that every user segment in the network wants to receive the Multicast data stream. When running in dense mode, the router floods Multicast packets out of all interfaces enabled for dense mode. Segments that do not want to receive the Multicast packets receive prune messages from neighboring routers and those branches are pruned. Because of this method of operation, dense mode is also referred to as a flood-and-prune mechanism to forward Multicast packets.
Dense mode flooding builds what is referred to as a source-based tree. This source-based tree has the Multicast source at the top of a forwarding tree. Each network segment forwarding the traffic forms a branch of the tree while the end-station hosts form the leaves. This makes dense mode flooding very efficient when you know that a large number of receivers exist because it uses a (S, G) forwarding mechanism by building the source-based tree, which is also sometimes referred to as a shortest-path tree (SPT). When using dense mode forwarding, only one source can exist for any given Multicast group at any given time.
In the event that a router running dense mode does not have any receivers that are interested in receiving the Multicast packets, the router sends a prune message to the router that forwarded the Multicast packet. When the router receives the prune message, it waits for three seconds before it stops forwarding Multicast packets for the group via that interface. The reason the router waits three seconds is to give any other devices that may be on the segment a chance to override the prune message by sending a join request. If no join messages are received within this three second delay, the router safely assumes that no one on that segment wants the Multicast packets and ceases flooding them via that interface.
Sparse mode forwarding operates in a manner that is opposite to dense mode forwarding. That is, while dense mode assumes that all Multicast-enabled interfaces are interested in receiving Multicast packets unless explicitly configured otherwise, sparse mode assumes that no Multicast interfaces are interested in receiving Multicast packets unless explicitly configured otherwise; that is to say, unless a PIM join message is received on the interface. As such, routers in a sparse-mode network must explicitly request that the data stream be forwarded to them. The advantage to this is that it makes sparse-mode more scalable than dense-mode; however, the downside to this is that sparse-mode becomes more complex.
When sparse-mode is enabled, one of the routers in the network performs a special function as a connection point between the source and the receiver. This router is referred to as the Rendezvous Point, or RP. The RP combines knowledge of the group source with the requests from the receiver. The RP is where the sender and the receiver first meet before the shortest-path tree is established. In other words, once the sender and receiver are aware of each other via the use of the RP, they use the shortest path between sender and receiver, based on routing protocol metric, to send and receive Multicast packets.
Once the Multicast traffic from the source and the requests from the receivers connect at the RP, the traffic is forwarded through the network. This shared tree has the RP at the top of the forwarding tree with the network segments and receivers as the branches and leaves, respectively. This is often referred to as the Rendezvous Point Tree (RPT). The shared-tree used by sparse mode is represented with the (*, G) notation. The * is used as a wildcard because the actual source of the Multicast stream is never known until registered with the RP.
In sparse-mode, the Multicast flow has two parts. The first part entails receivers sending PIM join messages to the RP. The second part entails the source sending PIM registers to the RP. This allows each intermediate router to establish the (S, G) PIM state in the network for forwarding these data packets. This establishes the Shortest Path Tree (SPT) in the network. Once the data stream is received directly from the source, the routers prune themselves from the shared-tree by sending a prune message to the RP.
While sparse-mode is more complex than dense-mode forwarding, because it is more scalable, it is the preferred method of Multicast forwarding used in the networks of today. The pruning mechanism used by sparse-mode is similar to the one used by dense-mode. If the router has no hosts that are interested in receiving any Multicast packets, it will send a prune message back toward the Multicast source via its upstream neighbor and Multicast traffic will no longer be forwarded via that router.
Multicast Routing Protocols
Because Multicast packets sometimes need to traverse multiple routers in order for packets from the source to receive group members, intermediate devices between the sender and receiver (i.e. routers) need to have a protocol that allows for Multicast packets to be delivered efficiently and loop-free from the source to intended receivers.
There are three Multicast routing protocols. These are Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF) and Protocol Independent Multicast (PIM). Of these three, the only protocol that you are required to know about is Protocol Independent Multicast. However, before we delve into the specifics of PIM, we are going to learn the basics pertaining to DVMRP and MOSPF.
DVMRP is based on the RIP protocol but is used to forward Multicast packets. When DVMRP is running, the router generates a routing table with the Multicast group that it has knowledge of and includes the groups corresponding metric (i.e. hop-count). When the DVMRP router receives a Multicast packet, it is forwarded via the router interfaces specified in the Multicast routing table. DVMRP is considered a legacy protocol and is seldom used today.
The Multicast Open Shortest Path First (MOSPF) protocol is an extension to the Open Shortest Path First (OSPF) protocol to support Multicast routing, allowing routers to share information about group memberships. MOSPF forwards a Multicast datagram on the basis of both the datagram’s source and destination. The OSPF link state database provides a complete description of the Autonomous System’s topology. MOSPF uses Type 6 LSAs and is not supported in Cisco devices.
Protocol Independent Multicast (PIM) is the most popular and prevalent IP Multicast routing protocol used in the networks of today. However, it is important to know that PIM is not actually a routing protocol. This is because routing protocols, such as DVMRP and MOSPF, actually build routing tables; however PIM does not build a routing table, but instead relies on the Unicast routing tables of other routing protocols to forward Multicast packets and prevent loops within the Multicast domain, via the use of the RPF check. The reason PIM is referred to as a routing protocol is because it basically replaced Multicast routing protocols such as DVMRP and MOSPF.
PIM is a Multicast routing protocol developed by Cisco. There are two versions of PIM, version 1 and version 2. PIMv1 packets are encapsulated in IGMP Type 14 packets. This means that PIMv1 uses the frame format of IGMP to send information between neighbors. PIMv1 has been replaced by PIMv2. PIMv2 is not encapsulated in IGMP and uses its own protocol number, which is IP protocol number 103. PIMv2 packets are sent to the Multicast group address 224.0.0.13. You are not required to be familiar with the details pertaining to PIMv1 or PIMv2 as part of the TSHOOT exam requirements.
Implementing PIM Dense and Sparse Mode in Cisco IOS Software
Prior to delving into specifics on the configuration of IP Multicast, it is very critical that you are aware that you are not expected to perform any Multicast configurations in the TSHOOT exam. This section has been included to reinforce the theoretical concepts pertaining to IP Multicast that are described in the previous sections. From a troubleshooting perspective, however, it would not take anything away from you to remember the show commands that are included in this section and how to verify basic IP Multicast functionality.
By default, IP Multicast routing is disabled in Cisco IOS software; however, this functionality is enabled using the ip multicast-routing global configuration command.
As was previously stated, Cisco IOS devices can be configured for either dense-mode or sparse-mode forwarding. The configuration of dense-mode forwarding is a straightforward task which requires that only the ip pim dense-mode command be enabled under all interfaces which should forward Multicast traffic within the domain. The following configuration example illustrates how to enable IP Multicast routing and enable PIM dense-mode forwarding for two router interfaces: Serial 0/0 and FastEthernet 0/0:
| R1(config)#ip multicast-routing R1(config)#interface fastethernet 0/0 R1(config-if)#ip address 10.1.1.1 255.255.255.0 R1(config-if)#ip pim dense-mode R1(config-if)#exit R1(config)#interface serial 0/0 R1(config-if)#ip address 10.0.0.1 255.255.255.0 R1(config-if)#ip pim dense-mode R1(config-if)#exit |
The forwarding method enabled on an interface when PIM is enabled can be verified by using theshow ip pim interface command. You can specify the actual interface at the end of this command or use the detail keyword for detailed information on the PIM interface. The following shows a sample output of the show ip pim interface command:
| R1#show ip pim interfaceAddress Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.0.0.1 Serial0/0 v2/D 1 30 1 10.0.0.3 10.1.1.1 FastEthernet0/0 v2/D 1 30 1 10.1.1.3 |
To enable PIM sparse-mode forwarding, the ip pim sparse-mode interface configuration command is specified instead. The following configuration example illustrates how to enable IP Multicast routing and enable PIM dense-mode forwarding for two router interfaces: Serial 0/0 and FastEthernet 0/0:
| R1(config)#ip multicast-routing R1(config)#interface fastethernet 0/0 R1(config-if)#ip address 10.1.1.1 255.255.255.0 R1(config-if)#ip pim sparse-mode R1(config-if)#exit R1(config)#interface serial 0/0 R1(config-if)#ip address 10.2.2.1 255.255.255.0 R1(config-if)#ip pim sparse-mode R1(config-if)#exit |
Again, the forwarding method enabled on an interface when PIM is enabled can be verified by using the show ip pim interface command as illustrated below:
| R1#show ip pim interfaceAddress Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.0.0.1 Serial0/0 v2/S 1 30 1 10.0.0.3 10.1.1.1 FastEthernet0/0 v2/S 1 30 1 10.1.1.3 |
NOTE: When implementing Multicast in Cisco IOS software, if you enable either dense-mode or sparse-mode forwarding under an interface and IP Multicast routing has not been enabled globally, the router or switch will not forward Multicast packets. Additionally, the software will print the following error message on the console to advise you of this:
| R1(config)#interface fastethernet 0/0 R1(config-if)#ip pim sparse-mode WARNING: “ip multicast-routing” is not configured, IP Multicast packets will not be forwarded R1(config-if)# |
Following these configuration steps, if dense-mode forwarding has been enabled and Multicast hosts reside on the network, no additional configuration is required on the router or switch to allow the hosts to receive Multicast traffic. However, if sparse-mode forwarding has been enabled, additional configuration is required before hosts are able to receive Multicast traffic. As was stated in the previous section, sparse-mode operation requires the use of an RP. In Cisco IOS Software, there are three ways in which the location of the RP can be specified:
- By statically configuring the router or switch with the RP IP address
- Automatically, using the Cisco Auto-RP mechanism
- Automatically, using the Bootstrap Router mechanism with PIMv2
Given that the configuration of IP Multicast is beyond the scope of the TSHOOT exam, we will not be delving into the specifics of configuring any of these methods. However, you should remain familiar with the fact that three methods do exist and can be used in Cisco IOS Software when configuring a Rendezvous Point (RP) on Multicast-enabled devices.
Following basic Multicast configuration, you can use the show ip mroute command to view the contents of the Multicast routing table. This command also includes all Multicast groups and sources. Cisco IOS software populates the Multicast routing table by creating source, group (S,G) entries from star, group (*,G) entries. The star (*) refers to all source addresses, the ‘S’ refers to a single source address, and the ‘G’ is the destination multicast group address. In creating (S,G) entries, the software uses the best path to that destination group found in the Unicast routing table using Reverse Path Forwarding (RPF). Following is a sample output of the information that is printed by this command:
| 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 Outgoing interface flags: H – Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.39), 00:39:04/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse-Dense, 00:39:04/00:00:00(1.1.1.1, 224.0.1.39), 00:03:00/now, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 10.1.1.1 Outgoing interface list: Null(*, 224.0.1.40), 01:18:46/00:00:00, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse-Dense, 01:18:46/00:00:00(2.2.2.2, 224.0.1.40), 00:23:04/00:02:48, flags: PCLT Incoming interface: FastEthernet0/0, RPF nbr 10.1.1.1 Outgoing interface list: Null(*, 227.3.3.3), 01:18:47/00:00:00, RP 1.1.1.1, flags: SJPCL Incoming interface: FastEthernet0/0, RPF nbr 10.1.1.1 Outgoing interface list: Null |