| Previous | Table of Contents | Next |
A number of modern network design concepts do not fit within the framework of the CID exam objectives. While this book has incorporated some of these issues in the main text—Digital Subscriber Line (DSL) and on-demand routing (ODR), for example—there are other subjects that are best covered in an isolated chapter.
Therefore, this chapter will cover some of these other issues that confront modern network designers, including:
| The bulk of this chapter incorporates concepts that are not part of the Cisco exam objectives, and so readers are encouraged only to review this material. Some specific attention should be given to IP multicast, however. |
As the need for one-to-many communications increased, developers realized that the traditional unicast and broadcast would be unable to scale and accommodate the demand. A method to transmit a single packet and forward that packet to multiple receivers on a dynamic basis was needed.
IP multicast accomplishes precisely this function. Clients inform the network that they wish to receive a data stream. This is analogous to tuning a television. However, the multicast does not specify a certain channel. Rather, it sends a datagram with a specific IP address from the Class D block, which ranges from 224.0.0.0 to 239.255.255.255. Note that there are well-known multicast addresses that are used by some protocols, including HSRP and EIGRP—this section is more concerned with multicasts that traverse routers. All stations in the multicast group will use an address from this block to join and receive the data flow. It is interesting to note that the MAC address for these IP addresses is also defined in the protocol (RFC 1112). The first three octets are 01:00:5E, and the last 23 bits are defined from the last three octets of the multicast IP address. For example, multicast group 227.4.5.6 will use MAC address 01:00:5E:04:05:06, with the remaining bit (high order in the fourth octet) always set to 0.
 | Designers should refer to RFC 1469 for information regarding Token Ring multicast. |
Once the client joins the multicast, the routers are responsible for permitting the data flow to move from the server to the end station. This prevents the multicast from forwarding onto segments that do not wish to participate. In addition, the workstation can use the multicast address to determine whether it wishes to receive the multicast at Layer 2. For non-recipient stations on the same segment, this eliminates unnecessary interrupts. Figure 13.1 illustrates a typical multicast network. Only those routers that need to forward the multicast out an interface receive the data stream. The thicker lines and black serial connection indicate this arrangement. The white serial connections and the thin lines denote a pruned connection—the multicast is not forwarded on these links, which ultimately conserves bandwidth. Pruning, like trimming the branches on a tree, infers that the path from the trunk to the leaves has been cut.
Note that this diagram implies the use of CGMP, or Cisco Group Messaging Protocol. CGMP further parses the multicast flow by limiting it to specific switch ports. Without this function, all members of the VLAN would be flooded with the multicast—the switch would have no mechanism to block the multicast packets from non-recipient ports. CGMP differs from IGMP (Internet Group Management Protocol), described later in this chapter. CGMP is responsible for blocking multicast traffic from individual ports on a Cisco switch; IGMP is a workstation-to-router process that instructs the router to forward the multicast on a segment basis.
)
FIGURE 13 .1 IP multicast in the network
Network designers should consider the various implementations of IP multicast in their installations. However, there are some general guidelines that are common to most installations.
First, multicast clients request to join the multicast via an IGMP request to their local router. The primary rational behind this mechanism is to keep multicast traffic from forwarding onto a segment—allowing the segment to be pruned. Note that IGMP is a Layer 3 protocol, operating at the same layer as IP or ICMP.
Second, designers will need to select a multicast protocol that operates between the routers in the network. PIM (Protocol Independent Multicast) is typically found in many deployments. However, DVMRP (Distance Vector Multicast Routing Protocol) is also available. DVMRP is usually found in installations that connect the MBONE, or the Internet’s multicast backbone. Cisco’s implementation of DVMRP is incomplete, depending on the IOS (Internet Operating System) version, and so most installations use PIM.
PIM operates in three modes on Cisco routers: dense mode, sparse mode, and sparse-dense mode. Functionally, each of these modes works to control the multicast tree; however, sparse mode uses a rendezvous point (RP). Dense mode is very similar to DVMRP—both protocols assume that bandwidth is not a factor and that all routers wish to join the multicast. Sparse mode indicates that the routers are farther apart (sparsely populated) and that bandwidth is typically constrained. This situation is common in WAN environments; however, sparse mode may be used in LANs as well.
Sparse-mode protocols operate under the premise that each router must explicitly join the multicast. In this design, each source transmits its multi-cast along the shortest path to the RP, which distributes the packet to regis-tered receivers.
It is important to note that PIM relies on an underlying unicast routing protocol regardless of configuration for sparse or dense mode. In addition, each multicast group should contain a single rendezvous point. Sparse mode uses a process called shortest path switchover to join and leave the multicast tree, which conserves bandwidth.
As noted previously, PIM also operates in sparse-dense mode on Cisco routers. In this configuration, the router will first operate in sparse mode and will then convert to dense-mode operation if a problem arises. Such a problem typically involves failure of the RP. Therefore, Cisco recommends the use of sparse-dense mode for all large-scale multicast deployments. These types of installation typically involve low-bandwidth or geographically distant links and require some degree of redundancy. Designers should note that the RP can be located via two dynamic methods—auto-RP and candidate-RP announcements. In addition, every router in the multicast group can be configured with a static entry for the RP.
| Previous | Table of Contents | Next |
){kind=link}