Scenario 7-1: Configuring PIM Dense Mode Multicast Routing
| Before you can configure multicast features on Cisco Catalyst switches, you must have a network that supports IP multicast routing. IP multicast routing is traditionally supported on most Cisco routers and is also supported on Cisco Catalyst Layer 3 switches, such as the Catalyst 3550 with EMI image, the Catalyst 4000 with Supervisor 3, and the native IOS Catalyst 6000/6500. In this scenario, you learn how to configure a routed IP multicast network based upon PIM, using both Cisco IOS routers and Cisco Layer 3 switches. Figure 7-6 shows the network topology that is used to demonstrate the configuration of IP multicast routing for all scenarios in this chapter. Figure 7-6. Chapter 7 Scenario Topology
In Figure 7-6, four Cisco Catalyst 3550 switches with Enhanced Multilayer Image (EMI) software are used to provide Layer 3 switching functionality. These switches are named L3-Switch-A through L3-Switch-D. Switch-B and Switch-C provide Layer 2 LAN connectivity for various hosts attached to the network, which consist of a mixture of multicast receivers and non-multicast receivers. PIM can be configured to operate in one of the following modes:
In this scenario you will learn how to configure PIM dense mode (PIM-DM). Before configuring PIM, you need to understand a little bit about how PIM operateshow PIM routers discover and communicate with each other and how PIM routers operating in dense mode build multicast distribution trees. The following sections provide an introduction to PIM-DM operation:
Unicast Routing ConsiderationsBefore configuring PIM to operate in any mode, you must ensure that unicast routing protocol(s) are configured throughout the network to ensure that all devices can communicate with each other using unicast communications. PIM relies on unicast routing protocols for anything related to unicast IP addresses. For example, multicast traffic by definition has a unicast source IP address, and PIM relies on the unicast routing table to perform a RPF check, which determines the closest interface on a multicast router that leads to the source of a multicast transmission. The RPF check is crucial because it prevents multicast traffic from looping continuously in the network by ensuring that multicast traffic received is forwarded only if the traffic has been received on the closest interface (in terms of the unicast routing table) to the source. A detailed discussion on how to implement unicast routing protocols is outside the scope of this book, so it is assumed for all scenarios that you understand that a unicast routing topology has been configured and is in place. Neighbor DiscoveryThe first event that occurs in a multicast network configured for PIM is neighbor discovery. Each multicast router announces its presence to the network by multicasting PIM Hello messages every PIM-enabled interface every 30 seconds (by default). These messages are sent to the 224.0.0.13 group address, which is reserved for all PIM routers. All directly attached neighbors hear each other's Hello messages and form adjacencies with each other. On a multi-access network (such as an Ethernet segment), if multiple PIM routers are attached to the network, a designated router (DR) is selected for the segment. If you are familiar with OSPF, the DR selection is similar in concept to the OSPF DR selection on multi-access networks. In PIM-DM networks, the DR is not actually used, except for the situation where a multi-access network has IGMPv1 receivers attached. IGMPv1 specifies that if more than one multicast router is attached to a multi-access segment, the multicast routing protocol is used to select the IGMP Querier role. With PIM, the DR is selected to perform the IGMPv1 Querier role, which is responsible for determining if receivers exist on the network for a specific group address. NOTE With IGMPv2 routers, the IGMP Querier is determined independently from the multicast routing protocol in use; it is determined by the IGMPv2 router with the highest IP address on the LAN. Building Multicast Trees in PIM Dense Mode NetworksPIM-DM uses a source distribution tree or shortest path tree (SPT) for each group address present in the network. The goal of using multicast is to form a tree that includes only the necessary branches and leaves required to transport the multicast traffic to each receiver. Understanding how PIM-DM forms a source distribution tree is most easily explained by using an example. Assume that the topology of Figure 7-6 has been configured for PIM-DM operation, and that Host-A is multicast source. After neighbor discovery is complete, Figure 7-7 shows what happens when a PIM-DM network detects the new group address associated with Host-A (i.e., Host-A starts sending traffic to a new multicast address). Figure 7-7. Scenario 7-1 Topology Configured for PIM-DM
In Figure 7-7 the following events occur:
NOTE Notice that a receiver may receive multiple copies of the same multicast packet at this stage. For example, Router-C receives two copies of the multicast traffic from L3-Switch-B and L3-Switch-C. Receivers must be able to deal with duplicate packet delivery. Understand that the tree shown in Figure 7-7 is specific only to the source (S) and the multicast group the source is sending traffic to. In other words, Figure 7-7 represents the (10.1.1.10,239.1.1.1) tree. If other sources are present in the network for the same group or a different group, totally separate (S,G) trees exist for each unique (S,G) combination. Notice in Figure 7-7 that although multicast traffic is being successfully forwarded to all receivers, the distribution of the multicast traffic is not ideal. For example, multicast traffic does not need to be sent on the link between L3-Switch-B and L3-Switch-C, and Router-C is receiving two copies of multicast traffic (one from Switch-B and one from Switch-C). With PIM-DM operation, multicast traffic is initially flooded throughout the multicast-enabled network, which is inefficient. Once initial multicast packets have been flooded throughout the multicast network down the initial broadcast tree, the tree is shaped to the optimal shape so that only the necessary branches and leaves of the tree are active. This process is referred to as pruning. PIM-DM PruningPruning is the process of removing unnecessary branches in the SPT that is generated for each group. PIM routers can generate a PIM prune message, which indicates to PIM neighbors that they should not forward multicast traffic towards the router. PIM prune messages are generated based upon the following conditions:
It is important to understand that pruning operates differently on point-to-point interfaces (e.g., serial interfaces) than it does on multi-access interfaces (e.g., Ethernet interfaces). In Figure 7-6, there are no point-to-point interfaces, even though multicast routers/L3 switches are directly connected to each other because Ethernet by definition is a multi-access network. Figure 7-8 demonstrates how pruning works on the multi-access networks of the topology of Figure 7-6 and Figure 7-7. Figure 7-8. PIM Dense Mode Pruning
In Figure 7-8, because L3-Switch-D is a leaf router and has no receivers attached to the 10.7.0.0/16 subnet, L3-Switch-D generates a prune message for the (S,G) entry (10.1.1.10, 239.1.1.1) and sends the prune (Step 1) to its upstream PIM neighbor (L3-Switch-B). L3-Switch-B ignores this prune message because Router-C is a receiver and is attached to the 10.6.0.0/16 subnet. L3-Switch-D continues to generate prune messages every three minutes. Also in Figure 7-8, both L3-Switch-B and L3-Switch-C prune the multi-access network connecting both switches (Step 2) without sending PIM prune messages to each other because no receivers are attached to this network and each multicast router can reach the source via L3-Switch-A. PIM-DM AssertsAsserts are a mechanism used on multi-access networks, such as Ethernet segments, to determine which multicast router forwards multicast traffic to the segment. In Figure 7-7, you can see that in Step 5 both L3-Switch-B and L3-Switch-C are forwarding multicast traffic onto the Ethernet segment that attaches to Router-C (a receiver). Having both switches forwarding the multicast traffic is both a waste of bandwidth and performance drain because the application running on receivers must constantly handle duplicate packets, which may affect the performance of the multicast application. To ensure only a single multicast router forwards on a multi-access segment, PIM-DM uses asserts. An assert message is generated by a multicast router every time it receives traffic associated with a multicast group on a multi-access interface that is listed in the outgoing interface list for the multicast group. Figure 7-9 demonstrates how asserts are used in the topology described in Figure 7-7. Figure 7-9. PIM Dense Mode Asserts
In Figure 7-9, both L3-Switch-B and L3-Switch-C receive multicast traffic from each other on interface Fa0/3, which is an outgoing interface for the multicast group. In response to this, each switch sends a PIM assert message (indicated by step 1), which includes the routing protocol administrative distance and the routing protocol metric that each router can reach the source by. The administrative distance parameter determines how believable the routing information is. For example, EIGRP has an administrative distance of 90 for an internal route, whilst OSPF has an administrative distance of 110. The lower the administrative distance, the more believable it is. The administrative distance value is considered first, with the router sending the assert with the lowest administrative distance asserting itself successfully as the forwarding multicast router for the segment. If the administrative distance values are equal, the routing metric to the source is compared with each, with the lowest routing metric determining which is the assertive router. In Figure 7-9, assume that EIGRP is in use throughout the network and that both L3-Switch-B and L3-Switch-C both have equal cost routes (metrics) to the source. In this tiebreaker situation, where the administrative distance and route metrics are identical, the router with the highest IP address on the multi-access network asserts itself as the forwarding router for the segment. This principle means that L3-Switch-B becomes the forwarding router for the segment, because L3-Switch-B has the highest IP address (10.5.1.2). Thus, L3-Switch-C prunes back interface F0/3 from the outgoing interface list (as indicated by Step 2). At this point, L3-Switch-C has pruned back both interface Fa0/2 and interface Fa0/3 and, therefore, no longer needs to receive multicast traffic from L3-Switch-A. Thus, L3-Switch-C generates a prune message and sends the prune to L3-Switch-A. This causes both L3-Switch-A to prune the interface attached to L3-Switch-C (interface Fa0/2) from the outgoing interface list. PIM-DM GraftingThe scenario topology is now fully pruned, meaning that the multicast group traffic is forwarded only down the paths necessary to reach each receiver in the network. You might be wondering what happens if a new receiver attaches onto the network in an area that has been pruned from the SPT. Because networks are dynamic, receivers may come and go, and a multicast routing protocol must be able to adapt to these changes. PIM-DM uses a mechanism known as grafting, which in essence grafts a previously pruned network path to the SPT. Figure 7-10 demonstrates the process of grafting, after a new multicast receiver enters the network. Figure 7-10. PIM Dense Mode Grafting
In Figure 7-10, the solid arrows indicate the SPT after the prune and assert mechanisms of Figure 7-9 are complete. The dashed lines indicate the following new events:
At this point, the multicast forwarding tree has been extended to include L3-Switch-D and the segment that Host-A attaches to. Figure 7-10 demonstrates that PIM can dynamically adapt to changes that are required in the multicast forwarding tree to ensure all receivers can receive multicast traffic. NOTE PIM-DM networks age out pruning information after three minutes by default, at which time multicast routers once again flood the network, as described in Figure 7-8, with the appropriate pruning and assert mechanisms, described in Figure 7-9 and Figure 7-10, occurring all over again. To prevent this periodic flood and prune behavior, a recent enhancement to PIM-DM allows the multicast router(s) directly connected to the source of an (S,G) SPT to periodically send a PIM state refresh message to the multicast group G, which is flooded to all multicast routers and indicates that each router should keep any pruned interfaces for the (S,G) SPT in the pruned state, without using the clumsy flood and prune mechanism. Scenario PrerequisitesTo successfully commence the configuration tasks required to complete this scenario, Table 7-2 describes the prerequisite configurations required on each device in the scenario topology. Any configurations not listed can be assumed as being the default configuration.
Example 7-1 demonstrates the configuration required on a Layer 3 switch (L3-Switch-A) before you can begin this scenario. Example 7-2 demonstrates the configuration required for Router-A. Example 7-1. Scenario 7-1 Prerequisite Configuration for L3-Switch-ASwitch# configure terminal Switch(config)# hostname L3-Switch-A L3-Switch-A(config)# enable secret cisco L3-Switch-A(config)# line vty 0 15 L3-Switch-A(config-line)# password cisco L3-Switch-A(config-line)# exit L3-Switch-A(config)# ip routing L3-Switch-A(config)# interface FastEthernet0/1 L3-Switch-A(config-if)# no switchport L3-Switch-A(config-if)# ip address 10.2.1.1 255.255.0.0 L3-Switch-A(config-if)# exit L3-Switch-A(config)# interface FastEthernet0/2 L3-Switch-A(config-if)# no switchport L3-Switch-A(config-if)# ip address 10.3.1.1 255.255.0.0 L3-Switch-A(config-if)# exit L3-Switch-A(config)# interface FastEthernet0/3 L3-Switch-A(config-if)# no switchport L3-Switch-A(config-if)# ip address 10.1.1.1 255.255.0.0 Example 7-2. Scenario 7-1 Prerequisite Configuration for Router-ARouter# configure terminal Router(config)# hostname Router-A Router-A(config)# enable secret cisco Router-A(config)# line vty 0 4 Router-A(config-line)# password cisco Router-A(config-line)# exit Router-A(config)# interface FastEthernet0/0 Router-A(config-if)# no shutdown Router-A(config-if)# exit Router-A(config)# interface FastEthernet0/0.1 Router-A(config-if)# encapsulation isl 1 Router-A(config-if)# ip address 192.168.1.1 255.255.255.0 Router-A(config-if)# exit Router-A(config)# interface FastEthernet0/0.2 Router-A(config-if)# encapsulation isl 2 Router-A(config-if)# ip address 192.168.2.1 255.255.255.0 After the prerequisite configuration is implemented, you should attach each device as indicated in Figure 7-6 and verify ping connectivity between devices in the network before proceeding. Configuration TasksThis scenario demonstrates the configuration of Catalyst 3550 Layer 3 switches for IP multicast routing using PIM dense mode operation. Configuration of multicast routing on the Catalyst 3550 switches is identical to the configuration required on Cisco routers because both devices use Cisco IOS. The tasks required to enable multicast routing using PIM dense mode are very simple and include the following:
NOTE This scenario assumes that the IP configuration indicated in Figure 7-6 has been implemented on each routing device Configuring Unicast RoutingAs previously discussed, PIM relies on the unicast routing table to perform RPF checks, which protect against multicast traffic being looped continuously in the network. If you are implementing multicast routing in a network, unicast routing is likely already in place, because a network is not much use if devices cannot communicate with each other. Before implementing PIM, ensure that you have confirmed that complete and correct unicast routing protocols are in place and that all devices in the network can communicate with each other. Implementing PIM on a solid and reliable unicast routing topology ensures that PIM is much less likely to encounter issues. For the scenario topology of Figure 7-6, EIGRP is assumed to be the unicast routing protocol implemented on all routers and Layer 3 switches in the network. Because all subnets in the network fall within the 10.x.x.x Class A network, the EIGRP configuration required on each router and Layer 3 switch is very simple, as demonstrated in Example 7-3. Example 7-3. Configuring EIGRP on Routers and Layer 3 Switches for Scenario 7-1L3-Switch-A# configure terminal L3-Switch-A(config)# ip routing L3-Switch-A(config)# router eigrp 10 L3-Switch-A(config-router)# network 10.0.0.0 NOTE When configuring EIGRP, ensure that the autonomous system number matches on each router. In Example 7-3, the autonomous system is configured as 10. Notice that the global configuration command ip routing is required because by default all Cisco Catalyst Layer 3 switches (except for native IOS Catalyst 6000/6500 switches) have IP unicast routing disabled by default. After configuring IP unicast routing, verify that all routing devices have full knowledge of all subnets throughout the network. Example 7-4 demonstrates the unicast routing table on L3-Switch-A after all routing devices in Figure 7-6 have been configured for unicast routing. Example 7-4. Verifying IP Unicast RoutingL3-Switch-A# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets C 10.1.0.0/16 is directly connected, FastEthernet0/3 C 10.2.0.0/16 is directly connected, FastEthernet0/1 C 10.3.0.0/16 is directly connected, FastEthernet0/2 D 10.4.0.0/16 [90/30720] via 10.3.1.2, 00:03:00, FastEthernet0/2 [90/30720] via 10.2.1.2, 00:03:20, FastEthernet0/1 D 10.5.0.0/16 [90/30720] via 10.3.1.2, 00:03:00, FastEthernet0/2 [90/30720] via 10.2.1.2, 00:03:20, FastEthernet0/1 D 10.6.0.0/16 [90/30720] via 10.2.1.2, 00:03:20, FastEthernet0/1 D 10.7.0.0/16 [90/33289] via 10.2.1.2, 00:03:20, FastEthernet0/1 Example 7-4 demonstrates the configuration required on a Layer 3 switch (L3-Switch-A) before you can begin this scenario. Example 7-3 demonstrates the configuration required for Router-A. In Example 7-4, the important route from a multicast point of view for this scenario is the shaded connected route. This represents the route that indicates where the source of the multicast is located (Router-A10.1.1.10). Whenever multicast traffic is received that is generated by Router-A (i.e., Router-A is the source), L3-Switch-A performs an RPF check to determine which is the next-hop interface for the source IP address (10.1.1.10). By referring to the route table in Example 7-4, you can see that the next-hop interface is FastEthernet0/3. If multicast packets from the source are received on this interface, then L3-Switch-A forwards the multicast packet out all interfaces in the outbound interface list, because L3-Switch-A knows that the multicast packet has arrived on the nearest interface that faces the source. If the multicast packets from the source are received on any other interface, the packet is dropped, because this situation indicates that the packet must somehow have looped back around to L3-Switch-A. The same concepts relating to the unicast routing table and RPF checks apply to each of the multicast routers in Figure 7-6. The following lists each of the multicast routers and the RPF interfaces that should be determined via the unicast routing table on each.
If multicast packets are received with a source IP address of Router-A (10.1.1.10) on the interfaces listed, the multicast packets are forwarded. If multicast packets with a source IP address of 10.1.1.10 are received on any other interface, the packets are dropped. Configuring PIM Dense Mode Multicast RoutingRefer back to Figure 7-6 and note that the only devices that require multicast routing to be configured are as follows:
Router-A, Router-B, and Router-C do not require multicast routing configuration, because Router-A is a multicast source and Router-B and Router-C are receivers. Even though each of these devices are routers fully capable of participating in a multicast routing topology, for the purposes of this chapter, each of these devices are used only to provide the source and receiver components of the overall multicast-enabled network. Before you configure PIM dense mode, you must globally enable multicast routing, which is performed using the following global configuration mode command: Router(config)# ip multicast-routing Once multicast routing is enabled, you must then explicitly configure PIM on each routed interface on the Layer 3 switch (or router) that you want to participate in the multicast routing topology. When you are configuring Layer 3 switches, which often have a combination of routed and switched interfaces, understand that you can configure PIM only on routed interfaces. A routed interface on a Cisco Layer 3 switch can be either a physical interface or a switch virtual interface (SVI). NOTE For each scenario in this chapter, it is assumed that each interface on L3-Switch-A thru L3-Switch-D shown in Figure 7-6 has been confiugred as a routed interface using the no switchport interface configuration command and configured with an appropriate IP address. To configure a routed interface for PIM operation, you must first enable PIM on the interface, specifying the appropriate PIM version (version 1 or version 2). The default and recommended PIM version is version 2, which is the default version of PIM used in Cisco IOS from Cisco IOS Release 11.3(2)T onwards. To enable PIM on a routed interface, use the ip pim interface configuration command: Router(config-if)# ip pim [version {1 | 2}] If you don't specify the version parameter, the interface operates in PIM version 2 mode. After enabling PIM on the interface, you must next configure the appropriate PIM mode of operation. The following modes of operation are supported in Cisco IOS:
To configure the PIM mode of operation on a routed interface, you also use the ip pim interface configuration command as follows: Router(config-if)# ip pim {dense-mode | sparse-mode | sparse-dense-mode} TIP If you don't need to explicitly configure the IP PIM version (i.e., you are using PIM version 2), you can use the ip pim dense-mode command to both enable PIM on the interface and configure dense mode operation, without specifying the ip pim command separately. Example 7-5 shows the full configuration required on L3-Switch-A to enable multicast routing and PIM dense mode operation on all routed interfaces (see Figure 7-5 for these interfaces). Example 7-5. Configuring PIM Dense Mode Multicast Routing on Router-AL3-Switch-A# configure terminal L3-Switch-A(config)# ip multicast-routing L3-Switch-A(config)# interface range FastEthernet 0/1 3 L3-Switch-A(config-if-range)# ip pim dense-mode Notice that only a single interface configuration command is required to enable PIM on each interface, because the PIM version being used is the default (version 2) and does not need to be explicitly configured. Example 7-6 shows the full configuration required on L3-Switch-B to enable multicast routing and PIM dense mode operation on all routed interfaces (see Figure 7-6 for these interfaces). Example 7-6. Configuring PIM Dense Mode Multicast Routing on Router-BL3-Switch-B# configure terminal L3-Switch-B(config)# ip multicast-routing L3-Switch-B(config)# interface range FastEthernet 0/1 3 L3-Switch-B(config-if-range)# ip pim dense-mode Example 7-7 shows the full configuration required on L3-Switch-C to enable multicast routing and PIM dense mode operation on all routed interfaces (see Figure 7-6 for these interfaces). Example 7-7. Configuring PIM Dense Mode Multicast Routing on Router-CL3-Switch-C# configure terminal L3-Switch-C(config)# ip multicast-routing L3-Switch-C(config)# interface range FastEthernet 0/1 4 L3-Switch-C(config-if-range)# ip pim dense-mode Example 7-8 shows the full configuration required on L3-Switch-D to enable multicast routing and PIM dense mode operation on all routed interfaces (see Figure 7-6 for these interfaces). Example 7-8. Configuring PIM Dense Mode Multicast Routing on Router-DL3-Switch-D# configure terminal L3-Switch-D(config)# ip multicast-routing L3-Switch-D(config)# interface range FastEthernet 0/1 2 L3-Switch-D(config-if-range)# ip pim dense-mode As you can see from the above examples, configuring PIM dense mode multicast routing is very simple. All of the internal mechanics of PIM, such as pruning, asserting and grafting, are automatically performed by Cisco IOS. Verifying PIM Dense Mode Multicast RoutingOnce you have configured PIM dense mode multicast routing on each multicast router, assuming that the unicast routing topology is in place correctly, you should first verify your interface configuration and then verify that all multicast routers can see each other as PIM neighbors. To list all of the PIM neighbors known to a particular multicast router, use the show ip pim neighbor command, as demonstrated on L3-Switch-B in Example 7-9. Example 7-9. Displaying PIM NeighborsL3-Switch-B# show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 FastEthernet0/1 00:43:50 00:01:35 v2 10.4.1.1 FastEthernet0/2 00:41:33 00:01:19 v2 10.5.1.1 FastEthernet0/3 00:41:33 00:01:31 v2 10.6.1.2 FastEthernet0/4 00:39:07 00:01:29 v2 (DR) Notice on L3-Switch-B that you can see the PIM neighbors for each subnet attached to L3-Switch-B. L3-Switch-B sees L3-Switch-C as a neighbor twice (via the 10.4.0.0/16 and 10.5.0.0/16) because both are connected to these subnets. The mode column indicates whether or not a neighbor is the PIM designated router (DR) for the subnet. NOTE The DR function is applicable only to multi-access networks such as Ethernet. The DR function for a specific multi-access network is performed by the router with the highest IP addressed interface on the network. The DR function is not used by PIM dense mode and is only used in PIM dense mode operation if IGMP version 1 is in use by receivers on a subnet, because IGMPv1 relies on the multicast routing protocol (PIM dense mode) to provide the role of IGMP Query router for the subnet. You can also use the show ip pim interface command to display information about PIM interfaces, the version and mode configuration as well as the DR for multi-access segments. Example 7-10 demonstrates the use of this command on L3-Switch-A. Example 7-10. Displaying PIM Interface InformationL3-Switch-A# show ip pim interface FastEthernet0/1 Address Interface Version/Mode Nbr Query DR Count Intvl 10.3.1.1 FastEthernet0/1 v2/Dense 1 30 10.3.1.2 Once you have verified that all multicast routers can see all neighbors, it is a good idea to verify that RPF checks are going to work correctly when your multicast sources start to transmit traffic. The show ip rpf command can be used to perform an RPF check manually for any source address, allowing you to verify that the correct unicast routing information is in place. Example 7-11 demonstrates the use of this command on L3-Switch-D for the multicast source used in this scenario (10.1.1.10). Example 7-11. Performing an RPF CheckL3-Switch-D# show ip rpf 10.1.1.10 RPF information for ? (10.1.1.10) RPF interface: FastEthernet0/1 RPF neighbor: ? (10.6.1.1) RPF route/mask: 10.1.0.0/16 RPF type: unicast (eigrp 10) RPF recursion count: 0 Doing distance-preferred lookups across tables Notice in Example 7-11, you can see the RPF interface (FastEthernet0/1), the next-hop neighbor (RPF neighbor) to the source (10.6.1.1 or L3-Switch-C), the route used to determine the RPF information (10.1.0.0/16), and the type of routing information used (unicast routing using the EIGRP 10 process). If you refer to Figure 7-6, the RPF check indicates that the routing information on L3-Switch-D matches the actual network topology. Finally, it is good to have a look at the multicast routing table, so that you know what the multicast routing table looks like before any multicast sources are active in the network. To display the multicast routing table, use the show ip mroute command, as shown in Example 7-12 on L3-Switch-A. Example 7-12. Displaying the Multicast Routing TableL3-Switch-A# show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP, 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.40), 01:40:01/00:02:42, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/2, Forward/Dense, 01:39:54/00:00:00 In Example 7-12, you can see a single multicast route entry, which is indicated by the shaded output. You might wonder why there is an entry in the multicast route table when no multicast sources are currently active in the network. The entry represents multicast packets generated by a feature known as Auto-RP, which is used to discover rendezvous points (RPs) in a PIM sparse mode network. The 224.0.1.40 address is used for RP discovery messages. NOTE Because this scenario focuses on PIM dense mode, you don't need to worry about the current multicast route entry, just understand why it is there. Testing PIM Dense Mode OperationOnce the PIM configuration of the network has been verified, the network is ready to begin forwarding multicast traffic. As described previously in this scenario, a number of steps take place during the initial forwarding of multicast traffic for a particular (S,G). These steps are generally completed in a manner of seconds, so once you start generating multicast traffic, you can quickly determine that the appropriate links in the network are pruned to ensure an optimal multicast tree. In this scenario, a single Cisco router (Router-A) with an IP address of 10.1.1.10 is used as the source of multicast traffic for the group address 239.1.1.1, and several Cisco routers (Router-B and Router-C) are configured as multicast receivers for the 239.1.1.1 group address. This configuration means that for Figure 7-6, the (S,G) notation for multicast traffic on the network is (10.1.1.10, 239.1.1.1). To configure Router-A as the source of multicast traffic, you simply need to ensure the router is configured with an appropriate IP address (10.1.1.10) that represents the source of the multicast traffic you want to generate. Once Router-A is configured and attached to the network, you can issue pings (ICMP echo requests) to the multicast group address (e.g., 239.1.1.1), which generates multicast traffic with a source IP address of 10.1.1.10 and a destination IP address of 239.1.1.1. To configure Router-B and Router-C as receivers, you need to ensure that both Router-B and Router-C are attached to the network and also have the necessary routing information to respond to the ICMP echo requests generated by Router-A. Once the base IP configuration is in place, you then use the ip igmp join-group interface configuration command, which configures an interface on the router to become a receiver for a specified multicast group address. NOTE Cisco routers acting as receivers by default use IGMP version 2. Example 7-13 demonstrates configuring Router-B to become a receiver (i.e., join) for the multicast group address of 239.1.1.1. Example 7-13. Joining a Multicast GroupRouter-B# configure terminal Router-B(config)# interface FastEthernet0/0 Router-B(config-if)# ip igmp join-group 239.1.1.1 Example 7-14 demonstrates configuring Router-C to become a receiver (i.e., join) for the multicast group address of 239.1.1.1. Example 7-14. Joining a Multicast GroupRouter-C# configure terminal Router-C(config)# interface FastEthernet0/0 Router-C(config-if)# ip igmp join-group 239.1.1.1 The ip igmp join-group command is very useful because it enables you to use your network devices to test multicast operation without having to implement actual hosts. As soon as you configure this command, Router-B and Router-C immediately multicast an IGMP membership report on the LAN indicating that they are receivers for the 239.1.1.1 group. At this point, any attached multicast routers create a (*,G) entry in the multicast route table for the group address (*,239.1.1.1). The (*,239.1.1.1) entry is like a template route entry; it is created in preparation for actual (S,239.1.1.1) entries, with S being one or more sources. Example 7-15 shows the routing table on L3-Switch-B after Router-B and Router-C have sent IGMP membership reports. Example 7-15. Viewing the Multicast Route Table After Router-B and Router-C Send IGMP Membership ReportsL3-Switch-B# show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP, 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 (*, 239.1.1.1), 01:25:49/00:02:32, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/4, Forward/Dense, 01:09:34/00:00:00 FastEthernet0/3, Forward/Dense, 01:25:49/00:00:00 FastEthernet0/2, Forward/Dense, 01:16:04/00:00:00 FastEthernet0/1, Forward/Dense, 01:25:49/00:00:00 (*, 224.0.1.40), 01:40:01/00:02:42, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/2, Forward/Dense, 01:39:54/00:00:00 The concept of a (*,G) entry can be a little confusing at first, because you might think that it represents a shared tree in a PIM-DM network that doesn't use shared trees. The (*,G) entry simply allows Cisco IOS to build a list of interfaces to which receivers or PIM neighbors are attached, so that when a source does start sending to the group, Cisco IOS simply has to copy this interface list to the new (S,G) entry in the route table. In Example 7-15, because either receivers and/or PIM neighbors are attached to all interfaces on L3-Switch-B, all interfaces are listed in the outgoing interface list. At this point, the network is ready to begin generating multicast traffic. Example 7-16 shows how to start a continuous ping using the extended ping command on Router-A. Example 7-16. Starting a Continuous ping on Router-ARouter-A# ping ip Target IP address: 239.1.1.1 Repeat count [5]: 100000000 Datagram size [100]: 1500 Timeout in seconds [2]: 0 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100000000, 1500-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds: Reply to request 0 from 10.5.1.10, 96 ms Reply to request 0 from 10.6.1.10, 104 ms Reply to request 1 from 10.5.1.10, 88 ms Reply to request 1 from 10.6.1.10, 96 ms Reply to request 2 from 10.5.1.10, 88 ms Reply to request 2 from 10.6.1.10, 96 ms Reply to request 3 from 10.5.1.10, 88 ms Reply to request 3 from 10.6.1.10, 100 ms Reply to request 4 from 10.5.1.10, 88 ms Reply to request 4 from 10.6.1.10, 96 ms Reply to request 5 from 10.6.1.10, 92 ms Reply to request 5 from 10.6.1.10, 100 ms ... ... In Example 7-16, 100,000,000 ping packets are sent to the multicast group address of 239.1.1.1. Because Router-A and Router-B are receivers of this group, they generate replies to these packets, as indicated in Example 7-16. Now that there is active multicast traffic in the network, you should be able to see new multicast routes generated in the multicast routing table on each multicast router. Example 7-17 shows the multicast routing table on L3-Switch-B. Example 7-17. The IP Multicast Route Table on L3-Switch-B After (10.1.1.10,239.1.1.1) Is ActivatedL3-Switch-B# 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.40), 03:21:51/00:00:00, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Dense, 00:39:00/00:00:00 FastEthernet0/2, Forward/Dense, 00:39:00/00:00:00 FastEthernet0/3, Forward/Dense, 00:39:00/00:00:00 FastEthernet0/4, Forward/Dense, 00:39:00/00:00:00 (*, 239.1.1.1), 00:23:05/00:02:59, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Dense, 00:23:05/00:00:00 FastEthernet0/2, Forward/Dense, 00:23:05/00:00:00 FastEthernet0/3, Forward/Dense, 00:23:05/00:00:00 FastEthernet0/4, Forward/Dense, 00:23:05/00:00:00 (10.1.1.10, 239.1.1.1), 00:02:20/00:02:04, flags: CT Incoming interface: FastEthernet0/1, RPF nbr 10.2.1.1 Outgoing interface list: FastEthernet0/2, Prune/Dense, 00:02:20/00:00:00 FastEthernet0/3, Forward/Dense, 00:02:20/00:02:02 FastEthernet0/4, Forward/Dense, 00:02:20/00:02:02 In Example 7-17, you can see a new entry represented as (10.1.1.10, 239.1.1.1). Look at this new multicast route entry while I dissect the various pieces of information that make up the entry. The first piece of information is (10.1.1.10, 239.1.1.1), which represents the (S,G) SPT that has a source of 10.1.1.10 and a group address of 239.1.1.1. The next piece of information is 00:02:20/00:02:04, which represents how long the route has been installed in the route table (i.e., 2 minutes and 20 seconds) and the expiry time on the route, which is currently 2 minutes and 4 seconds in Example 7-17 (the expiry timer is reset to a default value of 3 minutes every time a multicast packet associated with the route is received and forwarded). The next line lists the incoming interface information, which represents the RPF interface associated with the source. Notice that the FastEthernet0/1 interface on L3-Switch-B has been selected as the RPF interface because this represents the closest interface to the source of the multicast traffic. The next-hop address is listed as 10.2.1.1, which is L3-Switch-A, a switch connected directly to the source. The next line lists the outgoing interface list, which describes how multicast traffic associated with the route is forwarded. A key concept demonstrated in Example 7-17 is that the incoming interface is never in the outgoing interface list, which ensures loops do not form in the network. Notice that interface FastEthernet0/2 indicates a state of Prune/Dense. Multicast traffic is not forwarded out this interface because FastEthernet0/2 has no receivers attached to it and L3-Switch-C, which is connected, has another shorter path to the source; hence, FastEthernet0/2 is not considered a downstream multicast router. Interfaces FastEthernet0/3 and FastEthernet0/4 have a state of Forward/Dense, which means that multicast packets arriving on the incoming interface are forwarded out these interfaces. If you refer to Figure 7-9, this output is correct, because interface FastEthernet0/3 on L3-Switch-B is asserted as the forwarding multicast router for the 10.5.0.0/16 subnet, interface FastEthernet0/4 has Router-B (a receiver) connected, and L3-Switch-B represents the closest (and only) multicast router that leads to the source. To view multicast groups that are currently active and sending traffic in your network, you can use the show ip mroute active command, which displays all active multicast groups that are generating greater than 4 kbps of traffic on average. Example 7-18 demonstrates this command on L3-Switch-B. Example 7-18. Using the show ip mroute active CommandL3-Switch-B# show ip mroute active Active IP Multicast Sources - sending >= 4 kbps Group: 239.1.1.1, (?) Source: 10.1.1.10 (?) Rate: 42 pps/323 kbps(1sec), 323 kbps(last 10 secs), 310 kbps(life avg) You can see that the continuous ping is generating 42 packets per second and an average bandwidth consumption of 323 kbps. Because multicast traffic is commonly used for high-bandwidth multimedia applications, this command is useful for determining the effects of the multicast traffic on the network. Debugging PIM Dense Mode OperationCisco IOS provides debugging of IP PIM operation using the debug ip pim command. Example 7-19 demonstrates the use of the debug ip pim command on L3-Switch-C immediately after multicast traffic is generated in Example 7-14. This debug is intended to demonstrate both PIM pruning and asserting. Example 7-19. Debugging PIM Dense Mode Operation L3-Switch-C# debug ip pim PIM debugging is on ! Normal PIM Hellos (sent out every PIM enabled interface every 30 seconds) 03:44:01: PIM: Send v2 Hello on FastEthernet0/1 03:44:01: PIM: Send v2 Hello on FastEthernet0/2 03:44:01: PIM: Send v2 Hello on FastEthernet0/3 ! Multicast Traffic is Received. L3-Switch-C detects ! duplicate multicast packets on ! FastEthernet0/3 and begins the ASSERT process. 03:44:04: PIM: Send v2 Assert on FastEthernet0/3 for 239.1.1.1, source 10.1.1.10, metric [90/30720] 03:44:04: PIM: Assert metric to source 10.1.1.10 is [90/30720] 03:44:04: PIM: We win, our metric [90/30720] 03:44:04: PIM: (10.1.1.10/32, 239.1.1.1) oif FastEthernet0/3 in Forward state ! An ASSERT is received from L3-Switch-B. ! The administrative distance and metrics to the ! source are equal for each router (90/30720), so L3-Switch-B ! wins as it has the highest ! IP address on the subnet. L3-Switch-C then immediately prunes FastEthernet0/3. 03:44:04: PIM: Received v2 Assert on FastEthernet0 from 10.5.1.2 03:44:04: PIM: Assert metric to source 10.1.1.10 is [90/30720] 03:44:04: PIM: We lose, our metric [90/30720] 03:44:04: PIM: Prune FastEthernet0/3/239.1.1.1 from (10.1.1.10/32, 239.1.1.1) 03:44:04: PIM: (10.1.1.10/32, 239.1.1.1) oif FastEthernet0/3 in Prune state ! L3-Switch-C also prunes FastEthernet0/2, as no receivers or ! downstream PIM neighbors ! are connected to this interface 03:44:38: PIM: Prune FastEthernet0/2/239.1.1.1 from (10.1.1.10/32, 239.1.1.1) 03:44:38: PIM: (10.1.1.10/32, 239.1.1.1) oif FastEthernet0/2 in Prune state Example 7-20 demonstrates the use of the debug ip pim command on L3-Switch-D when Host-A attaches to the 10.7.0.0/16 subnet as described in Figure 7-10. This debug output is intended to demonstrate PIM Grafting operation. Example 7-20. Debugging PIM Dense Mode Operation L3-Switch-D# debug ip pim PIM debugging is on ! Host-A attaches and issues an IGMP Membership Report. Because L3-Switch-D has ! previously had all interfaces pruned for the 239.1.1.1 group. ! L3-Switch-D generates a ! PIM-DM Graft message, to indicate to the upstream PIM neighbor (L3-Switch-C) ! that it ! now needs to receive traffic for the group. 04:23:49: PIM: Building Graft message for 239.1.1.1, FastEthernet0/1: no entries 04:23:49: PIM: Building Graft message for 239.1.1.1, FastEthernet0/1: 10.1.1.10/32 04:23:49: PIM: Send v2 Graft to 10.6.1.1 (FastEthernet0/1) ! L3-Switch-C sends a PIM Graft-Ack message, ! to indicate that its interface has been ! added back to the multicast tree. 04:23:49: PIM: Received v2 Graft-Ack on FastEthernet0/1 from 10.2.1.1 04:23:49: Group 239.1.1.1: 10.1.1.10/32 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 135