In this final installment of Networking as a Second Language, we are going to explore the most exciting topic in networking, IP multicast.
IP multicast is a technology that allows a server to deliver content simultaneously to multiple receivers. In this architecture, a server provides a single source of content while the routers in the multicast network handle the task of replicating and distributing the content to the receivers. This content can be software updates, video conferencing, or voice calls over IP multicast. A new exciting implementation of IP multicast will be used by your local movie house to distribute movies digitally from Hollywood producers. OK, I think I've got your attention. Let's take a look at this technology.
Every morning at 0500 sharp, a network server sends out network broadcasts to every computer in the Sprockets' network. The broadcast message is intended for the manufacturing floor robots. These are update messages and CNC codes for the parts that will be fabricated on this workday. You will notice from Figure 10-1 that the CNC robots are scattered across multiple network segments. Therefore the network broadcasts are not limited to a single segment, but are forwarded to multiple segments. Access lists are configured on the router to identify the interfaces that will forward the broadcast messages and which will block them from being forwarded.
On the network segments receiving the broadcast messages, end-user workstations, quality-assurance monitoring PCs, and robots all coexist. Only the robot systems are interested in the CNC updates. The other devices must read and discard every broadcast packet.
This is the close of our series on networking. If you'd like to see an article covering a networking topic that Michael hasn't written about, or if you have general questions about this topic, let us know.
A better approach to this problem is to have a set of systems that subscribe to CNC updates. That is, only the robots will receive the updates; the other devices won't be involved. The trick is to have an IP address available for a group. When information is requested, a system will join a group. IP multicast employs this behavior.
From our previous discussion on classes of IP addresses (see Net Surfing with IP Protocol), a class D address range is reserved for IP multicast. Classes A through C were ranges for unicast addresses. A class D address, whose range is 188.8.131.52 to 184.108.40.206, identifies a specified multicast group. Devices subscribing to a group are called receivers. In the Sprockets' network, the robots would subscribe to a multicast group 220.127.116.11 (an arbitrary multicast address for illustration). The server would send CNC updates to multicast group 18.104.22.168. The router would forward the CNC updates to interfaces that contained segments with active groups.
In our unicast-addressing model, the IP header required source and destination addresses. The layer 2 Ethernet header required source and destination MAC addresses. Likewise, a multicast group requires a MAC address. The multicast MAC address serves an interesting purpose compared to its normal MAC address counterpart. A MAC address, as you recall, uniquely identifies a specific piece of hardware. It is a burned-in address that is assigned when the hardware is manufactured. A multicast group consists of many devices requesting a service. Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
Routers perform the forwarding of multicast packets out to the necessary interfaces. On the network device side (such as your computer), a layer 2 frame, encapsulating a multicast packet, is read by every system receiving multicast data. In a nutshell, many computers on a single LAN segment can belong to different multicast groups. When a computer joins a multicast group it will instruct the NIC to trigger an interrupt when a multicast MAC address is detected on the wire. The layer 2 frame is grabbed and the layer 3 IP addresses are examined. If the destination IP address matches the multicast group, the computer is joined to, the packet is then processed. Otherwise, it is discarded.
The problem IP multicast routing resolves is the sending of a single IP packet to multiple hosts. The operative mechanism, in multicast, is to send the packet to an IP multicast group. An IP multicast group is uniquely identified by a class D IP address. Routers typically use Internet Group Management Protocol (IGMP) to handle multicast traffic. Other multicast routing protocols exist; IGMP is the most prevalent.
Routers and hosts use IGMP messaging to start, manage, and stop multicast services. A host will send an IGMP join-group message to request multicast services. If the group is active, the router will forward the desired multicast group packets to the interface the join request was detected on. The complementary message to join is the IGMP leave message. A host sends a message to leave a group when it no longer desires to receive the multicast services of that specific group.
A multicast service may not be localized to the router. The router maintains multicast route tables of groups it has learned about and learns about groups from routing protocols.
The router and the hosts use IGMP to send messages on group states. A router uses its routing protocol to learn routes and build routing tables. Protocol Independent Multicast (PIM) uses the routing table information to manage the multicast packet forwarding. PIM does not maintain an explicit multicast routing table. It relies on the router's routing table for forwarding multicast packets.
Server Load Balancing
Letís take a look at Nanna Spacelyís multicast solution for the Sprocketsí network. For the moment, Nanna only intends to route information for multicast group 22.214.171.124 in the manufacturing network. Nanna later plans to add voice-over-ip and multimedia data streams which will require a complex multicast network. At first, Nanna is just going to address the needs of the manufacturing floor and enable IP multicast for the CNC robots.
Using Cisco routers, Nanna must enable IP multicast routing in the routerís configuration. She enters the following commands to accomplish this.
manfloor1# config t Enter configuration commands, one per line. End with CNTL/Z. manfloor1(config)# ip multicast-routing manfloor1(config)#end manfloor1#
The router now has IP multicast routing enabled. PIM must now be configured on an interface basis to manage multicast flow out of the desired interfaces. Figure 3 shows the fast Ethernet interfaces on the router we desire to enable PIM on.
Nanna configures PIM on the manfloor1 router fast Ethernet interface, id 0/0, with the following command IOS command syntax.
manfloor1# config t Enter configuration commands, one per line. End with CNTL/Z. manfloor1(config)# interface fast eth 0/0 manfloor1(config-if)# ip pim sparse-dense-mode manfloor1(config-if)#end manfloor1#
The other two interfaces on the router, fe 0/1 and fe 0/2, will be configured in a likewise manner. Upon completion of the configuration modifications, IP multicast routing will be enabled. Remember, PIM is required for extrapolating group addresses and routes from the routing unicast-based tables. If youíre curious about the sparse-dense-mode syntax, you should read up on the multicast PIM density modes.
Itís a modest multicast network, but Nanna managed to get the services up and running for the manufacturing CNC robots. There are many complexities involved with IP multicast networks. The current multicast bible is the book Developing IP Multicast Networks Volume I, by Beau Williamson. Word on the streets is that volume II is in the works. For a quick and dirty primer that is free, checkout Multicast Quick Start Configuration Guide on Cisco Systemís online documentation site.
This multicast network was a simple confidence builder for Nanna. Now sheís considering adding voice-over-ip multicast and videoconference streams. But that's another day. Right now, Nanna wants to treat herself to a nice afternoon at the movies. A new action-martial arts flick from Hong Kong has been downloaded to her local high tech multiplex cinema.
Michael J. Norton is a software engineer at Cisco Systems.
Read more Networking as a 2nd Language columns.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.