Multicasting

In case of multicasting, multiple packets are generated at the gateway of destination, and not at source. This saves a lot of bandwitdth. But, most of the multicasting applications use UDP which comes with its drawbacks. Some obvious ones are discussed here: • Lack of congestion control: can cause significant choking of bandwidth. • Duplicate packets: when network topologies change, duplicate multicast packets are generated. The applications must be designed to handle this. • Out-of-sequence packets • No reliability of packet delivery • Security compromise: Eavesdropping is quite possible. Multicast Addressing The multicast IP address range is 224.0.0.0–239.255.255.255. According RFC 3171, we have

There are three general groups of multicast address groups that are used for reference. Those groups include: ◦ Local scope addresses ◦ Global scope addresses ◦ Administratively scoped addresses Local scope addresses run from 224.0.0.0 through 224.0.0.255 and are reserved by Internet Assigned Numbers Authority (IANA) for network protocol use. Multicasts in this range are never forwarded off the local link or network, no matter what the time to live (TTL) is (and

usually the TTL is set to 1). The Multicast MAC Address: ◦ lower order 23-bits of multicast IP address are mapped onto lower order 23-bits of MAC address. You can tell that the MAC address is a multicast frame because the low-order bit (0x01) in the first octet tells you that the frame is a multicast frame. The 0x01005e prefix (vendor code also known as OUI) has been reserved for use in mapping Layer 3 IP multicast addresses into Layer 2 MAC addresses, ◦ You know there are 23 bits mapped into the MAC because the first 24 bits of the MAC address are 0x01005e, and the 25th bit must be a zero. So, the last 23 bits of the MAC come from the last 23 bits of the IP address. ◦ you must keep in mind that there are 32 IP or Layer 3 addresses that can potentially map to a single Layer 2 multicast address. Multicast Protocols Internet Group Management Protocol(IGMP): a host-to-router protocol used to enable hosts to join a multicast group if they want to receive a specific flow of traffic. ◦ With the original, IGMP version 1, routers send a periodic membership query to the multicast address 224.0.0.1. Hosts then send membership reports to the group multicast address they want to join. ◦ One down side of version 1 is that hosts silently leave the multicast group, not notifying the router that they no longer wish to receive the traffic. ◦ IGMPv2: Group specific queries were introduced using which a router could query each group singlely for the membership instead of asking all of them. ◦ The difference between the group-specific query and the membership query is that a membership query is multicast to the all-hosts (224.0.0.1) address. A group-specific query, to group 224.1.1.1, for example, is a multicast to that specific group multicast address. ◦ Leave a group message lets the host tell router about its leaving and hence reduces group's time on when last member leaves. Cisco Group Management Protocol By default, Layer 2 switches treat multicast traffic like it has an unknown MAC address or a broadcast frame that causes the frame to be flooded out every port within a VLAN. This is huge wastage of bandwidth. You can think of CGMP as creating a type of client/server relationship, where the router would be considered a CGMP server and the switch takes on the client role. Protocol processes run on both devices. The router takes in the IGMP messages, translates the messages into CGMP commands and sends them to the switch for processing. In the switch, they are used to populate the Layer 2 forwarding tables with the multicast entries needed to forward multicast traffic out to the ports that requested it. when the router receives an IGMP message packet, it creates a CGMP packet that contains the request type (join or leave), the Layer 2 multicast MAC addresses, and the actual MAC address of the client.(CGMP actually gets Layer 3 device understand MACs) That packet is then sent to the well-known CGMP multicast MAC address, 0x0100.0cdd.dddd. All Cisco switches running CGMP listen to this address. The CGMP control message is then processed by the switch, and the proper entries are created in the switch content-addressable memory (CAM) table.

• • •

IGMP Snooping • The IGMP snooping process requires the CPU in each switch to listen for, identify, and intercept a copy of all IGMP packets traveling between the routers and end hosts. The process collects: *IGMP membership reports *IGMP leaves If you are not careful about how you configure IGMP snooping, a switch may have to collect every single Layer 2 multicast packet so that it can figure out which ones are IGMP packets. This can have a significant, in some cases huge, impact on switch performance.

Protocol Independent Module(PIM) PIM is the only multicasting routing protocol being supported by Cisco. In multicast, the paths are called trees. You can have shortest path trees (SPT) and shared trees. • Multicast paths must be loop free, just as unicast paths are, but since the traffic can be traveling on multiple networks at the same time, a different method must be used to ensure that no loops are made. • The method is called reverse path forwarding (RPF). RPF has to check every single multicast packet that it receives to make sure that it is traveling in the correct direction. Packets must be traveling away from the root of the tree, always in the direction of the hosts who need the traffic. • The path back to the source must be verified to ensure that the receiving interface is the interface that has the best path back to the source. If the interface is not in the best path from the source, then it is assumed that the traffic is from a looped path or was sent from a different place. In either case, the packet is dropped. The actual multicast distribution trees tell us the path from the source to the receivers or destinations; only traffic flowing over that path is accepted. • Shortest Path Tree: With a shortest path tree, a separate tree is built from each source down to where each and every member of its group is located. • In a shared tree situation, the creation of the forwarding paths relies on a centrally located router called a rendezvous point (RP), serves as a go-between for the multicast sources and destinations. Sources start out by sending their multicast traffic to the RP router, the RP then forwards data down through a shared tree, ultimately to all the members of the group. The multicast routing protocols run in two modes: 1. Dense Mode: where they assume that the network is made for heavy multicast traffic; they first flood everywhere and then prune is where ever there aren't any receivers. 2. Sparse Mode: use an explicit join mechanism. Using explicit tree join message information from the IGMP process, these protocols build distribution trees based on demand. The join messages are sent by the routers that have directly connected receivers. Multicast Operation and Configuration • You have to start out with a multicast source. There has to be some traffic or data that a user can sign up for or request to receive. The sign up or request process can be accomplished by clicking on a link the user received in email or picking a selection from a multicast application loaded on their host machine. The application must be updated somehow about the available data or sessions; the content usually maps to one or more IP multicast groups. The application might be getting its content from a directory service. Some type of directory services is available, and the application may contact the appropriate directory server. There

• •

are Session Directory (sd) applications that can act like a guide, displaying multicast content. The application runs on a host machine and displays available content to end users. The directory application uses either Session Description Protocol (SDP) or Session Announcement Protocol (SAP) to learn about the content. Commands to Accomplish Multi-cast Routing and Verification • • (config)#ip multicast-routing The second step is to enable PIM on interfaces; this automatically starts IGMP. PIM is enabled on the interface, so study your network and figure out which router interfaces should support PIM. Once you figure that out, activate PIM in interface-configuration mode. PIM runs in three modes: sparse, dense, and sparse-dense. (config-if)#ip pim {dense-mode | sparse-dense-mode | sparse-mode} (config-if)# ip pim version {1 | 2} The final step is to configure RPs. You have to manually configure the RP on every router— even the RP itself. Use the following global configuration command: Router(config)# ip pim rp-address ip-address [access-list] [override] To define a router as a mapping agent, use the following global configuration command: DalRtr1(config)# ip pim send-rp-discovery scope ttl Configure a router as a candidate RP with the following global configuration command: DalRtr1(config)# ip pim send-rp-announce type mod/num scope ttl [group-list access- list] [interval seconds] DalRtr1#show ip mroute #show ip pim interface #show ip pim neighbour

• •

• • •

Sign up to vote on this title
UsefulNot useful