Another reason for migrating classful protocols such as RIP or IGRP involves support for VLSM As the network grows, administrators begin to realize that wasting address space merely to accommodate the protocol becomes a serious issue RIP and IGRP not support VLSM, so all the interfaces included in the same major network should have the same mask When connecting a large number of hosts in broadcast media for a class B network, you would mask with 24 For point-to-point connections, you might use a 30-bit mask to use the same subnet for 64 point-to-point connections Another reason for migrating to another protocol is faster convergence Again, the older classful protocols are periodic, which means that you must put the route in holddown and flush states In the worst case, this could take minutes to converge Because of the rapid pace of the Internet, this sluggish convergence is unacceptable Classful protocols also lack the capability to summarize within the network The administrator, for example, might want to summarize some routes within a region to diminish the size of the routing table NOTE Essentially, migration of routing protocols is carried out to improve classfulness; and to provide support for VLSM, support for discontiguous networks, scaling, and faster convergence The third situation relates to the scaling protocols, but more in terms of the ISP space rather than the enterprise space ISPs often mistakenly advertise customer routes into the IGP because ISPs usually undergo tremendous growth When the ISP begins redistribution, its customer base is modest in size However, the customer routes increase as the business expands Before long, an ISP could have 5,000 to 6,000 customer routes floating in its IGP, so if a problem occurs on the customer networks, it can wreak havoc on the ISP networks These issues are discussed in detail in the next section Migration of Routing Protocols Routing-protocol migration can be divided into three categories: • • • Migrating from a classful distance-vector protocol, such as RIP or IGRP, to a classless link-state protocol, such as OSPF or IS-IS Migrating a classful distance vector to a classless advanced distance vector, such as Enhanced IGRP Migrating customer routes from the IGP of an ISP to BGP Each of these migration scenarios is discussed fully in the following sections Classful Distance-Vector to Link-State Protocol For the sake of this discussion, imagine you are migrating from IGRP, which is the classful distance-vector protocol, to a link-state protocol, OSPF Remember that both OSPF and IS-IS require hierarchy The network in Figure 12-2 shows that no hierarchy exists in the network in question, so you must change not only the network protocol, but also the physical circuit to accommodate the hierarchical structure 296 Figure 12-2 Non-Hierarchical Network Architecture While attempting to implement a new protocol to accommodate the defective architecture that you are currently using, you encounter difficulty in fitting them together This complication prevents you from achieving your goal of improving the network so that it will scale to the next level NOTE When dealing with large network outages caused by routing protocols, these obstacles are almost always related to incorrect design decisions For example, administrators may have forced a protocol to accommodate their network design, rather than modifying the network to accommodate the routing protocol If you tried to implement OSPF on the network shown in Figure 12-2 merely to accommodate the defective design, you would encounter serious difficulty You may even blame the protocol for your own mistakes! To ensure that your network scales properly, you should consider making drastic changes to the physical topology to accommodate OSPF The first and foremost step in accommodating OSPF is to define the backbone As mentioned in the OSPF discussion in Chapter 9, "Open Shortest Path First," all traffic outside an area must pass through a backbone area, also called area Consider the network in Figure 12-2 and select the backbone routers Backbone routers are chosen on the basis of CPU power, memory, and the points in the network that the backbone connects The chosen routers should be capable of dividing the network into areas without relocating many of the circuits 297 The second step is to examine the backdoor connections between routers that destroy the hierarchy of the network, such as connections between R14 and R13 In some cases, the redundancy must be adjusted for the network to scale properly Migration of this network is a three-step process: First, prepare the router for OSPF Recall from Chapter that OSPF builds the database in addition to the routing table, unlike traditional distance vectors Ensure that the routers already running with borderline memory are upgraded to accommodate the OSPF database Next, determine how soon you can move circuits to accommodate the OSPF hierarchy If the wait is long, you can begin planning the OSPF configurations and allow it to run parallel to IGRP By running OSPF parallel to IGRP, the network's current routing policies will not be affected—even if the OSPF is not configured according to the protocol requirements The network does not see changes in the routing table because of the administrative distance of IGRP (100) and OSPF (110) In addition, unlike distance-vector protocols, link-state protocols not receive information from the routing table Therefore, if the information is not contained in the table, it would not be sent to the neighbors Link-state protocols build the routing table with information from the database This allows you to run the link-state protocol and all the necessary information in the database When you decide to change the routing protocol, the distance vector can be removed This way, the information in the database is the only information included in the routing table Changes to European Routers Try the first step listed previously, and begin identifying your backbone routers Decide which circuits you must relocate For example, as in Figure 12-3, if you are reconfiguring a network in Europe, router R1 is a perfect candidate for use as a backbone router because it has a connection to the United States and a connection to most of the routers in Europe Also, if R1 is the area border router ( ABR), you can summarize all the specific routes at R1 and send a single route to the United States, provided that you have a solid addressing scheme Figure 12-3 Area Border Routers after Moving Circuits 298 NOTE By configuring router R1 as the only backbone router, you will remove the redundancy and create a single point of failure Remember that all traffic must pass through the backbone area for destinations outside the area If you retain R1 as the backbone router, therefore, Europe would be disconnected when R1 fails For this reason, you should maintain at least two area border routers in the network for redundancy The next step is to choose another ABR There are three candidates—R13, R11, and R9 These are possible choices because they have links to other regions For example, R9 is linked to the United States, and both R13 and R11 have connections to Asia If you must choose between them, R13 is a better choice, because it has higher-speed connections within its own area—R11 is only connected via the Frame Relay to one hub router Now that you have selected the ABRs, you need to move only one circuit, which is the one from R14 to R11 to R14 to R9, as shown in Figure 12-3 In this new setup, the circuit was moved from R11 to R9, so now you have three ABRs in Europe (R9, R1, and R13) If possible, move the high speed circuit on R12 to R13 so that both ABRs R1 and R13 have a direct connection Modifying U.S Routers To modify U.S routers, configure R2, R3, and R4 as the backbone routers because they are connected to the backbone routers defined in Europe At this point, it is a good idea to move one of the three U.S circuits from R1 to R13, so that it has a connection to the United States If R1 goes down, there is only one connection to the United States left, via R9 The link between R9 and R2 is slow, so losing R1 means that all high-speed links to the United States are lost If 299 possible, move the high-speed circuits from R4 to R13 instead of R1, so that all three ABRs have a high-speed connection to the United States Now, examine the routers in Figure 12-3 that connect the United States and Asia: R7, R8, and R4 Because these have connections to Asia, they could be used as the ABRs However, selecting these routers as the ABRs creates the problem of having to relocate all the connections on R14 and R15 into Europe to these routers If R7 and R8, for example, become the ABRs, and if R14 and R17 become pure area routes, R17, R14, and R18 cannot connect to multiple areas because they would have to become area border routers For this reason, it is better to choose R14, R18, and R17 as the ABRs for Asia Next, create a non-zero area within the United States as well, assigning R5 and R7 as ABRs You define R7 as an ABR because it is able to specifically define multiple areas This way, you can clearly mark the area boundaries, as shown in Figure 12-4 If you choose not to make R7 an ABR, you have to move its circuits to Asia, to any of the area routers Figure 12-4 Area Border Routers and Backbone Routers Defined The reason you should select R5 as an ABR is its location—it lies in the path between R8 and R7 If R7 goes down, routers R19, R20, and R21 are cut off Now, the backbone area would be similar to the network shown in Figure 12-4 At this point, you might ask: Why not configure the routers in the United States to be the backbone (area 0) routers, and use the routers in Europe and Asia only as regular area routers? The answer is that you would need to sever the connections between routers in Europe and Asia because these now have become pure area routers All traffic between Europe and Asia will have to pass through the United States and cannot reach each other directly This causes the core to become U.S.-centric 300 Therefore, each region includes its own ABRs, minimizing the number of routing protocol packets The ABR from each region then will summarize all the regional routes into one or two routes As a result, regional flaps are not sent across, which reduces routing traffic Modifying Asian Routers Now, you can focus your attention on the router s in Asia Except for one remaining circuit that should be relocated from R15 to R17 or R18, everything else is well-defined The circuit could be moved from R17 to R1, but you not want to move this circuit to R14 because it already has a high-speed link from Europe to Asia Losing R14 would mean that Asia loses all its high-speed links to Europe If you move the R15 circuit to R17, it is beneficial to move an R14 circuit to R18 for complete redundancy on area border routers The ABRs for Asia are now R14, R17, and R18; and the circuit is moved from R15 to R17 This new topology is shown in Figure 12-5 This network is now ready for OSPF without significantly altering the existing network Figure 12-5 Area Border Routes and Backbone Routers Defined for Each Region These regional routers have selected ABRs that will accommodate growth in each of the three regions: Asia, Europe, and the United States If a local area within each region grows increasingly larger, a new area could be created that would simply need to connect to each regional ABR It should be noted, however, that in practice, the selection of routers for an ABR is not as rigid as we have presented it in the examples We have illustrated it this way for the expediency of accommodating the links illustrated in the figure Configuration Changes 301 When migrating from IGRP to OSPF, you should be aware of configuration changes One of the benefits of migrating from distance-vector to link-state protocols in the Cisco environment is that you can make use of the administrative distance feature Administrative distance (AD) establishes the believability of a route between routing protocols If the same route is learned via OSPF and via IGRP, the router compares the administrative distances and installs the route with the lower administrative distance In rating AD, the higher the value, the lower its believability status The default administrative distance for IGRP in Cisco is 100; for OSPF, it is 110 Link-state protocols, unlike distance-vector protocols, not build routing information from routing tables Instead, they build routing tables from the database, which is built on the information received from the neighbor In a link -state advertisement, a router sends information about its connected interfaces so that all the routers within an area have complete information about the entire topology If a situation occurs in which the router runs multiple routing protocols simultaneously, such as IGRP and OSPF, and the router installs the IGRP route in the routing table because of its lower administrative distance, the router will continue to maintain information about that route in its linkstate database Therefore, after you have configured OSPF on the routers, you can verify whether all the routes are located in the database, even if that route already exists in the routing table via IGRP During OSPF configuration, the network continues to function properly because the current routing protocol (IGRP) has not been changed It is unnecessary to change the administrative distance because IGRP already has the lower AD After you are satisfied with the network's setup and you have ensured that all routes have been added to the OSPF database, you can easily remove IGRP from the routers, and allow OSPF to install the same routes in the routing table without disrupting service Consider router R1 for this example The router configurations are shown prior to the OSPF changes: Current configuration: ! version 11.1 ! hostname C7000-2B ! clock timezone utc enable password cisco ! ip subnet-zero ! interface Serial2/0 description Connection to R12 ip address 10.11.4.2 255.255.255.0 bandwidth 4500000 ! interface Serial2/1 description Connection to R2 ip address 10.32.1.5 255.255.255.0 bandwidth 4500000 302 ! interface Serial2/2 no ip address encapsulation frame-relay no cdp enable ! interface Serial2/2.1 point-to-point description Connection to R9 ip address 10.11.1.1 255.255.255.0 bandwidth 150000 no cdp enable frame-relay interface-dlci 100 ! interface Serial2/2.2 point-to-point description Connection to R10 ip address 10.11.2.5 255.255.255.0 bandwidth 150000 no cdp enable frame-relay interface-dlci 101 ! interface Serial2/2.3 point-to-point description Connection to R11 ip address 10.11.3.1 255.255.255.0 bandwidth 150000 no cdp enable frame-relay interface-dlci 102 interface Serial2/3 description Connection to R3 ip address 10.32.2.1 255.255.255.0 bandwidth 4500000 interface Serial 4/1 description Connection to R17 ip address 10.32.4.1 255.255.255.0 bandwidth 4500000 ! interface Fddi5/0 ip address 10.11.5.1 255.255.255.0 ip accounting output-packets no keepalive ! router igrp network 10.0.0.0 ! logging buffered logging console warnings snmp-server community public RO line exec-timeout 0 line aux line vty password ww 303 login ! ntp clock-period 17180006 ntp server 30.1.1.2 prefer ntp server 10.1.1.2 end You can now enable OSPF without altering the addressing and topology The important point to remember is that OSPF requires area addressing, and that each interface must be defined in a particular area TIP One common mistake that is often committed when OSPF is defined in an area is to simply configure all other interfaces into area by defining the 0.0.0.0 255.255.255.255 area command This is unwise—this configuration results in misdirected interfaces New interfaces added to this router will automatically enter area 0, even if you want them in another area Any OSPF statement added after the 0.0.0.0 255.255.255.255 command will not take effect For this reason, always be sure to enable OSPF with specific commands rather than general ones The OSPF configuration is the following: route ospf network 10.11.2.0 network 10.11.5.0 network 10.11.1.0 network 10.11.4.0 0.0.1.255 0.0.0.255 0.0.0.255 0.0.0.255 area area area area 1 network 10.32.1.0 0.0.0.255 area network 10.32.2.0 0.0.1.255 area network 10.32.4.0 0.0.0.255 area The first network statement places interface serial 2/2.2 and serial 2/2.3 into area The FDDI interface is also in area All other interfaces are in area Configurations should follow the same process throughout the network After OSPF is properly configured, the OSPF network should resemble the one shown in Figure 12-6 Figure 12-6 Area Set Up with OSPF 304 Now, the areas are well-defined, and each region will be able to grow After you have introduced OSPF, you can configure VLSM and send one summary from each region When the configurations for each region are complete, you can determine whether the LSAs for each route have been included in the database VLSM routes would be seen as OSPF routes only You can accomplish this by adding a show ip routecommand, and then add a sh ip ospf data {router, network, summary} command The sh ip ospf data router command should be used in an area in which the database can be viewed, and loopback addresses or point-to-point links can be located Next, examine the network LSA for all the broadcast networks within the area Finally, search for summary LSAs for all the interarea routes The following shows a sample output of the sh ip ospf data router 10.11.25.1 This command was initiated on R1 for R3: Router Link States (Area 1) Routing Bit Set on this LSA LS age: 950 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 10.11.25.1 Advertising Router: 10.11.25.1 LS Seq Number: 8000102E Checksum: 0×FB69 Length: 120 Area Border Router Number of Links: 305 HELLO messages, shown in Figure 13-8, are sent periodically by the router on all multicastenabled interfaces These messages essentially establish and maintain multicast router neighbor relationships The HELLO message may contain a number of options, but RFC 2362 specifies only option type 1, which is a two-byte holdtime in seconds Figure 13-8 PIM HELLO Message If the holdtime expires without receiving a HELLO, a multicast router declares its neighbor "dead" and times out any associated multicast routing information If the holdtime is set to 0xffff, the session is never timed out (useful for dial-on-demand circuits); if it is set to zero, the routing information is immediately timed out Option types to 16 are reserved by RFC 2362 1: REGISTER The REGISTER message, shown in Figure 13-9, is used only in PIM sparse mode (PIM -SM) When a DR initially receives a multicast packet from a directly connected source (or PIM domain in the case of a PMBR, which is discussed following: packets received from other domains are treated as directly connected sources by the PMBR), this packet is encapsulated in a REGISTER message and is unicast to the RP Figure 13-9 PIM REGISTER Message 330 The source address of the unicast REGISTER message is the DR, and the destination is the rendezvous point (RP) The RP subsequently de-encapsulates the packet and forwards it down the multicast shared tree This continues until a shortest-path tree is built from the RP to the source, and the RP sends a REGISTER-STOP message to the DR The B bit is set to if the router is a PMBR (PIM Multicast Border Router) for the source A PMBR connects a dense mode PIM domain to a local sparse domain The B bit is set to zero if the sending router is a DR for a source directly connected to one of its interfaces The N (null register) bit is set to if the DR is probing the RP prior to unsuppressing registers This helps prevent unnecessary bursts of traffic being sent to the RP between receiving REGISTER STOP messages (a weakness in PIM V1) The Multicast Data Packet field is empty in a null register Note that the checksum is performed only on the PIM header, not over the entire encapsulated multicast data 2: REGISTER STOP The REGISTER STOP message, shown in Figure 13-10, is used only in PIM -SIM This message is sent in response to a received REGISTER MESSAGE after the RP has established a shortest-path tree for a particular source/group pair Figure 13-10 PIM REGISTER STOP Message After the DR receives the REGISTER STOP message, it suppresses REGISTERs for the group and source address pairs encoded in the REGISTER STOP message This encoding is shown in Figure 13-11 Figure 13-11 PIM Encoded Address Formats (from RFC 2362) 331 332 3: JOIN/PRUNE The JOIN/PRUNE message, shown in Figure 13-12, is used in both dense and sparse modes The message is sent by routers to upstream routers and RPs Figure 13-12 PIM JOIN/PRUNE Message 333 The Encoded-Unicast-Upstream Neighbor Address is the IP address of the upstream (RPF) neighbor that performs the join or prune 334 Holdtime instructs the recipient how long, in seconds, to maintain the requested join/prune states 0xffff is used to signify "forever," and is used to signify immediate timeout of the state Number of groups indicates the number of multicast group sets in the message Each set consists of an Encoded Multicast Group Address, followed by a list of encoded source addresses to join or prune Figure 13-11 shows the format of the encoded source address and the meaning of the S, W, and R bits 4: BOOTSTRAP The BOOTSTRAP MESSAGE, shown in Figure 13-13, is used in PIM sparse mode only BOOTSTRAP messages are originated by the BootStrap Router (BSR) in a domain and distribute information about all RPs in the domain As in the case of multiple DRs, an election mechanism selects the BSRs from the set of candidate BSRs for the domain This election mechanism is supported by the BOOTSTRAP messages Figure 13-13 PIM BOOTSTRAP Message 335 336 BOOTSTRAP messages are sent to the ALL-PIM -ROUTERS group (224.0.0.13) with a TTL of Every router forwards such messages from every interface, except the one on which the message is received This effectively forms a spanning tree If BOOTSTRAP messages exceed the maximum packet size, they are fragmented Fragments from the same message are identified by their common Fragment Tag The Hash Mask Len indicates the length of hash-mask to use for mapping group addresses to RP For IP, the recommended value is 30, and can be set via the ip pim bsr -candidate global command The hash-mask is such that consecutive group addresses tend to map to the same RP If associated data streams use consecutive group addresses, a high probability exists that they will share the same RP, and therefore share the same path through the network, resulting in similar delay and bandwidth characteristics The BSR Priority field is used to elect the BSR for a PIM domain RFC 2362 describes a finitestate machine However, for this discussion, only the ultimate outcome is important: the candidate BSR with the highest IP address (carried in the Encoded-Unicast-BSR-Address field) and Priority field is chosen as the BSR The remainder of the BOOTSTRAP message consists of group address/candidate RP sets Each set begins with an RP-Count for that set, which indicates the number of candidate RPs for this group address in the entire BOOTSTRAP message Frag RP-Cnt indicates the number of candidate RPs contained in this message fragment For unfragmented messages, RP-Count and Frag RP-Cnt are the same Finally, there is a list of Encoded-Unicast-RP-Addresses (encoding is shown in Figure 13-11), together with an associated holdtime, in seconds, for the RP state and an RP-Priority The lower the value of the RP-Priority field, the higher the priority: is, therefore, the highest priority 5: ASSERT The ASSERT MESSAGE, shown in Figure 13-14, is used in both dense and sparse modes PIM routers maintain an outgoing interface list for all multicast group addresses If an interface is in the outgoing list for group X, the router multicasts the packets it receives for group X to all interfaces in the list Therefore, under loop-free conditions, the router would not expect to receive any packets for group X on any interface in X's outgoing interface list If it does, the router generates an ASSERT message Figure 13-14 PIM ASSERT Message 337 The ASSERT message includes the encoded group/source addresses of the offending packet, together with the preference of the unicast protocol that provides a route to the source and the unicast metric of that route The preference is equivalent to the administrative distance of the routing protocol in the Cisco implementation; the metric varies between protocols For example, in RIP, it is hop count; in OSPF, it is cost-based 6: GRAFT The GRAFT message is used in dense mode only The message is sent upstream by a PIM router to request that a previously pruned group be reinstated The format of this message is identical to the JOIN/PRUNE message (See Figure 13-12.) GRAFTs help reduce the join latency for groups that already have been pruned This is desirable because the default prune timer is typically set to three minutes The default prune time could be reduced, but this must be balanced against the amount of traffic generated due to the periodic flood/prune paradigm of dense mode PIM 7: GRAFT-ACK The GRAFT-ACK message is also used only in dense mode Upon receiving a GRAFT message, a PIM router typically updates its PRUNE state in accordance with the message, and then unicasts it back to the source, changing the message type from to 8: CANDIDATE-RP -ADVERTISEMENT The CANDIDATE-RP-ADVERTISEMENT message is used only in sparse mode These messages are unicast by candidate RPs to the elected BSR The message has the format shown in Figure 13-15 Figure 13-15 CANDIDATE-RP-ADVERTISEMENT Message The Prefix-Cnt indicates the number of group addresses in the message; the Priority is that of the included RP for this group address (the lower the value, the higher the priority), and the holdtime 338 is the amount of time the information in this message is valid Finally, the Encoded-Unicast-RPAddress is the address of the RP that should be advertised by the BSR as the candidate RP for this group address Multicast Scalability Features Techniques for large-scale deployment of multicast are still evolving This section examines two major issues: RP discovery and operating networks in sparse-dense mode Bootstrap Routers and Candidate RPs BSRs and RPs are a critical part of the scalability of PIM V2 This section discusses the process of BSR election and RP determination in more detail This discussion is included for completeness; however, it is recommended that you use auto-RP instead of BSR You will learn about auto-RP in the next section A large sparse mode network should have multiple candidate RPs, which should be placed in the backbone Candidate RPs are configured via the ip pim rp-candidate global configuration command An interface can be specified as the RP's address; as usual, you should use a Loopback interface The set of group addresses that a candidate RP will service also can be specified via a basic access list For large networks, let every RP be a candidate for all group addresses The BSR then uses a pure hash function to arbitrate which RP services which group This effectively handles load sharing of the RP functionality across the candidate RPs A network should contain multiple BSRs, preferably located on highly reliable routers in the backbone BSRs are configured via the ip pim bsr-candidate global configuration command This command enables the source IP address of the bootstrap messages to be set, and, once again, a loopback interface is recommended A hash length also can be configured This roughly determines the number of consecutiv groups e that will be mapped to a single RP As a rule, 30 is recommended Finally, the priority of an individual BSR can be set, and the BSR with the highest preference wins the BSR election process Therefore, you should set the priorities in descending order of desirability for each BSR Auto-RP The mechanisms of BSR and candidate RPs are quite complicated Cisco offers an elegant and simple alternative called auto-RP To enable auto-RP, configure all RP routers to advertise active groups via the ip pim send-rpannounce global configuration command, as follows: ip pim send-rp-announce loopback scope 16 These announcements are sent to the well-known group address CISCO-RP -ANNOUNCE (224.0.1.39) 339 Loopback is an RP address advertised in the announcements You should configure it to be the same for all RPs PIM DRs then send traffic for their RP to the address of loopback Therefore, the packet will be "swallowed" and processed by the closest functioning RP, in the context of IP routing, to the DR Rather than a per-group basis, load sharing across RPs occurs on a geographical basis, which is more logical for large WANs Scope is the IP TTL set in the announcements For most networks, 16 is suitable, although you might have to increase this for networks with very deep hierarchy Auto-RP also requires a router to be configured as an RP mapping agent Its role is to listen to the CISCO-RP-ANNOUNCE group and resolve conflicts between two RPs that announce the same or overlapping groups For example, if two RPs advertise the same group, the RP with the highest IP address is accepted If all RPs use the same address and are advertising all active groups, the RP mapper function is irrelevant However, it still must be configured You will most likely want to this on the RP router itself: ip pim send-rp-discover scope 16 The RP mapper announces the selected RP for each group on the CISCO-RP-DISCOVERY group (224.0.1.40) All PIM DRs listen on the CISCO-RP-DISCOVERY group to learn the RPs to use for each group Multiple RP mappers also may be configured All RP mappers listen on the RP-DISCOVER group and may suppress their own mapping output if they hear mappings from another RP mapper with a higher IP address PIM Sparse-Dense Mode For large networks, most groups will operate in sparse mode However, for certain groups—for example, auto-RP announcements—operating in dense mode is more appropriate To achieve the best of both, Cisco routers enable interfaces to be configured in sparse-dense mode Operation in this mode is simple: If the router learns or has a configured RP for a group, the group operates in sparse mode Otherwise, it operates in dense mode The mode of any group can be observed via the show ip mroute command Although any combination of dense mode, sparse mode, and sparse-dense mode can be used on a Cisco router, it is recommended that you configure all interfaces in sparse-dense mode as standard practice Explicitly configure dense or sparse mode only when you have a very specific need: for example, on a very low-bandwidth link where you not want the overhead of any dense mode traffic 340 Deploying Multicast in a Large Network In this case study, you will examine the multicast architecture in a large network corresponding to an Internet service provider, ISPnet The large network encapsulates many regional networks, each with the architecture shown in Figure 13-16 The overall network multicast architecture is shown in Figure 13-17 For simplicity, you can enable ip pim-sparse-dense-mode on all interfaces within the network and on customer interfaces, as requested by the customer Therefore, if the customer wants multicast service, IP PIM sparse-dense mode is enabled on the interface leading to that customer At least one core router in every regional network is configured as both an RP and an RP mapper A full mesh of IMSDP and IMBGP peering is maintained among all backbone routers EMSDP peering is enabled for customers running their own RP and for peer ISPs at the regional public NAP For non-MSDP customers, auto-RP advises routers in the customer's network of available RPs in the provider's network The regional NAP includes two peering infrastructures: one optimized for multicast and another for unicast MBGP is enabled on the multicast infrastructure and enables interdomain multicast routing that is incongruent to unicast MBGP is also used in instances in which customers want separate links for unicast and multicast traffic Figure 13-16 Multicast Architecture within an ISPnet Regional Network 341 Figure 13-17 ISP Multicast Architecture 342 Summary In this chapter, you have explored the various protocols used for implementing multicast in a large network Specifically, the text has explored the use of IGMP and PIM for intradomain routing, and MBGP and MSDP for interdomain routing IGMP is used by hosts to communicate their interest in particular groups to their local router, which runs PIM PIM itself operates in two modes: sparse and dense In most circumstances, however, it is best to configure your network in sparse-dense mode and let PIM decide how to handle each group Dense mode PIM is more suited to groups with densely populated members; sparse mode is for sparsely distributed members Dense mode uses a bandwidth consumptive flood-and-prune algorithm, whereas sparse mode uses explicit joins, and moves from a shared to a source-based tree with the assistance of a rendezvous point MSDP enables RPs to advertise the presence of local sources to RPs in other domains, which often correspond to autonomous systems This facilitates joins across domain boundaries MBGP offers a solution for cases in which the unicast and multicast routing is incongruent at the interdomain level, such as where different links are used for each type of traffic The deployment of multicast on a very large scale is still an evolving practice PIM sparse-dense mode, auto-RP, and MSDP are some of the methods with which the configuration and segmentation of large multicast networks are being made simpler and more scalable Review Questions 1: Which multicast routing protocols does Cisco support? 2: How are PIM messages encapsulated for transmission on a network? 3: Do hosts or routers run IGMP? 4: PIM dense mode is a very simple protocol, yet it is not suitable for all applications Why not? 5: Should you configure sparse mode or dense mode PIM on routers in your network? 6: What is the deployment/standards status of MBGP and MSDP? 7: Why might multicast and unicast topologies be incongruent? 8: What are the benefits of auto-RP over PIM V2's BSR mechanisms? 9: What are possible configuration options for obtaining multicast from your ISP? Address the cases in which you have an RP and the cases in which you not 343 Answers: 1: Which multicast routing protocols does Cisco support? A: Cisco does not provide implementations of either MOSPF or DVRMP PIM performs the functions of both However, Cisco routers can interoperate with DVMRP, by which they can connect to the MBONE 2: How are PIM messages encapsulated for transmission on a network? A: PIM V1 was encapsulated in IGMP (protocol number 102) PIM V2 messages are assigned protocol number 103 3: Do hosts or routers run IGMP? A: Both Hosts use IGMP to indicate their interest in particular groups Routers use IGMP to query and learn about interested hosts 4: PIM dense mode is a very simple protocol, yet it is not suitable for all applications Why not? A: As a flood-and-prune protocol, PIM dense mode periodically consumes high amounts of network bandwidth PIM sparse mode avoids this by having an explicit join mechanism 5: Should you configure sparse mode or dense mode PIM on routers in your network? A: Use sparse-dense mode everywhere, unless you want to administratively forbid either mode for a particular reason 6: What is the deployment/standards status of MBGP and MSDP? A: MBGP is standardized in RFC 2283 and has been deployed for some time As of this writing, MSDP was still in beta trials and at Internet Draft status However, extremely positive early feedback means that the protocol will probably be widely deployed and standardized very soon 7: Why might multicast and unicast topologies be incongruent? A: Often, a particular LAN infrastructure does not support Layer multicast, and, therefore, a separate infrastructure that does is supplied On other occasions, it may be desirable to put multicast traffic on a separate physical infrastructure for billing or providing differentiated service In the longer term, it is quite possible that unicast and multicast topologies will become congruent and the need for MBGP will diminish 8: What are the benefits of auto-RP over PIM V2's BSR mechanisms? A: Auto-RP is simpler, serves the same purpose, and has had far more field exposure 9: What are possible configuration options for obtaining multicast from your ISP? Address the cases in which you have an RP and the cases in which you not 344 ... should be sent to the external peers The static routes on A1 are the following: ip ip ip ip ip ip ip ip ip ip ip route route route route route route route route route route route 194.1.1.0 255.255.255.0... redistributed into RIP with a default metric of two As shown in Figure 12 -7, the network has a physical loop R7 relearns its own advertised Enhanced IGRP network from R18 and R 17 via RIP R7 had originally... description Connection to R 17 ip address 10.32.4.1 255.255.255.0 bandwidth 4500000 ! interface Fddi5/0 ip address 10.11.5.1 255.255.255.0 ip accounting output-packets no keepalive ! router igrp network