HP 5500 Ei 5500 Si Switch Series Configuration Guide
Have a look at the manual HP 5500 Ei 5500 Si Switch Series Configuration Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 1114 HP manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
125
To solve the issues, PIM-SM allows an RP or the DR at the receiver side to initiate an SPT switchover
process.
1. The RP initiates an SPT switchover process.
The RP can periodically check the passing-by IPv4 mu lticast packets. If it finds that the traffic rate
exceeds a configurable threshold, the RP sends an (S, G) join message hop by hop toward the
multicast source to establish an SPT between the DR at the source side and the RP. Subsequent
multicast data travels along the established SPT to the RP.
For more information about the SPT switchover initiated by the RP, see Multicast source
regi
stration .
2. The receiver-side DR initiates an SPT switchover process.
After receiving the first multicast packet, the receiv er-side DR initiates an SPT switchover process,
as follows:
{ The receiver-side DR sends an (S, G) join message hop by hop toward the multicast source.
When the join message reaches the source-side DR, all the routers on the path have installed
the (S, G) entry in their forwarding table, and thus an SPT branch is established.
{ When the multicast packets travel to the router where the RPT and the SPT deviate, the router
drops the multicast packets received from the RPT and sends an RP-bit prune message hop by
hop to the RP. After receiving this prune mess age, the RP sends a prune message toward the
multicast source (suppose only one receiver exists). Thus, SPT switchover is completed.
{ Multicast data is directly sent from the source to the receivers along the SPT.
PIM-SM builds SPTs through SPT switchover more economically than PIM-DM does through the
flood-and-prune mechanism.
Assert
PIM-SM uses a similar assert mechanism as PIM-DM does. For more information, see Assert.
BIDIR-PIM overview
In some many-to-many applications, such as multi-side video conference, there might be multiple
receivers interested in multiple multicast sources simultaneously. With PIM-DM or PIM-SM, each router
along the SPT must create an (S, G) entry for each multicast source, consuming a lot of system resources.
BIDIR-PIM addresses the problem. Derived from PIM-SM, BIDIR-PIM builds and maintains bidirectional
RPTs, each of which is rooted at an RP and connects multiple multicast sources with multiple receivers.
Traffic from the multicast sources is forwarded through the RPs to the receivers along the bidirectional RPTs.
Each router needs to maintain only one (*, G) mu lticast routing entry, saving system resources.
BIDIR-PIM is suitable for networks with dense multicast sources and dense receivers.
The working mechanism of BIDIR-PIM is summarized as follows:
• Neighbor discovery
• RP discovery
• DF election
• Bidirectional RPT building
Neighbor discovery
BIDIR-PIM uses the same neighbor discovery mechanism as PIM-SM does. For more information, see
Neighbor discovery .
126 RP discovery BIDIR-PIM uses the same RP discovery mechanism as PIM-SM does. For more information, see RP dis covery . In PIM-SM, an RP must be specified with a real IP address. In BIDIR-PIM, however, an RP can be specified with a virtual IP address, which is called the rendez vous point address (RPA). The link corresponding to the RPA’s subnet is called the rendezvous point link (R PL). All interfaces connected to the RPL can act as the RP, and they back up one another. NOTE: In BIDIR-PIM, an RPF interf ace is the interface pointin g to an RP, and an RPF neighbor is the address of the next hop to the RP. DF election On a network segment with multiple multicast routers, the same multicast packets might be forwarded to the RP repeatedly. To address this issue, BIDIR-PIM uses a DF election mechanism to elect a unique designated forwarder (DF) for each RP on every network segment within the BIDIR-PIM domain, and allows only the DF to forward multicast data to the RP. NOTE: DF election is not necessary for an RPL. Figure 44 DF election As shown in Figure 44, without the DF election mechanism, both Router B and Router C can receive multicast packets from Route A, and they might both forward the packets to downstream routers on the local subnet. As a result, the RP (Router E) receives duplicate multicast packets. With the DF election mechanism, once receiving the RP information, Router B and Router C initiate a DF election process for the RP: 1. Router B and Router C multicast DF election messa ges to all PIM routers (224.0.0.13). The election messages carry the RP’s address, and the priority and metric of the unicast route, MBGP route, or multicast static route to the RP. 2. The router with a route of the highest priority becomes the DF. 3. In the case of a tie, the router with the route with the lowest metric wins the DF election.
127 4. In the case of a tie in the metric, the router with the highest IP address wins. Bidirectional RPT building A bidirectional RPT comprises a receiver-side RPT and a source-side RPT. The receiver-side RPT is rooted at the RP and takes the routers directly connected to the receivers as leaves. The source-side RPT is also rooted at the RP but takes the routers directly connected to the sources as leaves. The processes for building these two parts are different. Figure 45 RPT building at the receiver side As shown in Figure 45, the process for building a receiver-side RPT is similar to that for building an RPT in PIM-SM: 1. When a receiver joins multicast group G, it us es an IGMP message to inform the directly connected router. 2. After getting the receiver information, the router sends a join message, which is forwarded hop by hop to the RP of the multicast group. 3. The routers along the path from the receiver’s directly connected router to the RP form an RPT branch, and each router on this branch adds a (* , G) entry to its forwarding table. The * means any multicast source. W h e n a re c e ive r i s n o l o n g e r i n t e re s t e d i n t h e m u l t icast data addressed to multicast group G, the directly connected router sends a prune message, which goes hop by hop along the reverse direction of the RPT to the RP. After receiving the prune message, each upstream node deletes the interface connected to the downstream node from the outgoing interface list an d checks whether it has receivers in that multicast group. If not, the router continues to forw ard the prune message to its upstream router. Source Server A Server B Host B Host C ReceiverReceiver Multicast packets Receiver-side RPTJoin message RP Source Host A Receiver
128 Figure 46 RPT building at the multicast source side As shown in Figure 46, the pr ocess for building a source-side RPT is relatively simple: 4. When a multicast source sends multicast packets to multicast group G, the DF in each network segment unconditionally forwards the packets to the RP. 5. The routers along the path from the source’s directly c o n n e c t e d r o u t e r t o t h e R P f o r m a n R P T b r a n c h . Each router on this branch adds a (*, G) entry to its forwarding table. The * means any multicast source. After a bidirectional RPT is built, multicast traffic is forwarded along the source-side RPT and receiver-side RPT from sources to receivers. NOTE: If a receiver and a multicast source are at the same side of the RP, the source-side RPT and the receiver-side RPT might meet at a node before reaching the RP. In this case, multicast packets from the multicast source to the receiver are directly forwarded by the node to the receiver, instead of by the RP. Administrative scoping overview Division of PIM-SM domains Typically, a PIM-SM domain or BIDIR-PIM domain contains only one BSR, which is responsible for advertising RP-set information within the entire PIM-SM/BIDIR-PIM domain. The information for all multicast groups is forwarded within the network sc ope that the BSR administers. This is called the non-scoped BSR mechanism. To implement refined management, you can divide a PIM-SM domain or BIDIR-PIM domain into one global scope zone and multiple administratively scoped zones (admin-scope zones). This is called the administrative scoping mechanism. The administrative scoping mechanism effectively rele ases stress on the management in a single-BSR domain and enables provision of zone-specific services through private group addresses. Source Server A Server B Host B Host C ReceiverReceiver Multicast packets Source-side RPT RP Source Host A Receiver
129 Admin-scope zones are divided specific to multicast groups. Zone border routers (ZBRs) form the boundary of the admin-scope zone. Each admin-scope zone maintains one BSR, which serves multicast groups within a specific range. Multicast protocol packets, such as assert messages and bootstrap messages, for a specific group range cannot cros s the admin-scope zone boundary. Multicast group ranges that different admin-scope zones serve can be overlapped. A multicast group is valid only within its local admin-scope zone, and functions as a private group address. The global scope zone maintains a BSR, which serves the multicast groups that do not belong to any admin-scope zone. Relationship between admin-scope zones and the global scope zone The global scope zone and each admin-scope zone have their own C-RPs and BSRs. These devices are effective only in their respective zones. That is, BSR election and RP election are implemented independently within each admin-scope zone. Each admin-scope zone has its own boundary. The multicast information cannot cross this boundary in eith er direction. A better understanding of the global scope zone and admin-scope zones should be base d on geographical space and group address range. 1. Geographical space Admin-scope zones are logical zones specific to particular multicast groups. The multicast packets of these multicast groups are confined within the local admin-scope zone and cannot cross the boundary of the zone. Figure 47 Relationship between admin-scope zones and the global scope zone in geographic space As shown in Figure 47, for multicast groups in the same address range, admin-scope zones must be geographically separated from one another. Namely, a router must not serve different admin-scope zones. In other wo rds, different admin-scope zones contain different routers, whereas the global scope zone covers all routers in the PIM-SM/BIDIR-PIM domain. Multicast packets that do not belong to any admin-scope zones can be transmitted in the entire PIM-SM/BIDIR-PIM domain. 2. Multicast group address ranges Each admin-scope zone serves specific mult icast groups. Usually, these addresses have no intersections. However, they might overlap one another.
130 Figure 48 Relationship between admin-scope zones and the global scope zone in group address ranges In Figure 48 , the grou p address ranges of admin-scope 1 and 2 have no intersection, whereas the group address range of admin-scope 3 is a subset of the address range of admin-scope 1. The group address range of the global scope zone cove rs all the group addresses other than those of all the admin-scope zones. That is, the group addre ss range of the global scope zone is G-G1-G2. In other words, a supplementary relationship ex ists between the global scope zone and all the admin-scope zones in terms of group address ranges. PIM-SSM overview The source-specific multicast (SSM) model and the any-source multicast (ASM) model are opposites. Presently, the ASM model includes the PIM-DM and PIM-SM modes. You can implement the SSM model by leveraging part of the PIM-SM technique. It is also called PIM-SSM. The SSM model provides a solution for source-specific multicast. It maintains the relationships between hosts and routers through IGMPv3. In actual application, part of IGMPv3 or PIM-SM technique is adopted to implement the SSM model. In the SSM model, receivers locate a multicast source by means of advertisements, consultancy, and so on. No RP is needed, no RPT is required, no source registration process exists, and the multicast source discovery protocol (MSDP) is not needed for discovering sources in other PIM domains. In PIM-SSM, the term channel refers to a multicast group, and the term channel subscription refers to a join message. The working mechanism of PIM-SSM is summarized as follows: • Neighbor discovery • DR election • SPT building Neighbor discovery PIM-SSM uses the same neighbor discovery mechanism as in PIM-DM and PIM-SM. See Neighbor dis covery . DR election PIM-SSM uses the same DR election mechanism as in PIM-SM. See DR election. Admin-scope 3 G3 address Admin-scope 2 G2 address Admin-scope 1 G1 address Global-scope G −G1−G2 address
131 SPT building The decision to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether the multicast group the receiver will join falls into the SSM group range (SSM group range reserved by IANA is 232.0.0.0/8). Figure 49 SPT building in PIM-SSM As shown in Figure 49, Host B and Host C are multicast information receivers. They send IGMPv3 report messages to the respective DRs to express their interest in the information about the specific multicast source S. After receiving a report message, the DR first determ ines whether the group address in this message falls into the SSM group range and then does the following: • If the group address in the message does fall into the SSM group range, the DR sends a subscribe message for channel subscription hop by hop toward the multicast source S. An (S, G) entry is created on all routers on the path from the DR to the source. An SPT is thereby built in the network, with the source S as its root and receivers as its leaves. This SPT is the transmission channel in PIM-SSM. • If the group address in the message does not fall into the SSM group range, the receiver-side DR follows the PIM-SM process. The receiver-side DR sends a (*, G) join message to the RP, and the source-side DR registers the multicast source. Relationships among PIM protocols In a PIM net work, PIM-DM cannot run together with PIM-SM, BI DI R-PIM, or PIM-SSM. However, PIM-SM, BIDIR-PIM, and PIM-SSM can run together. When they run together, which one is chosen for a receiver trying to join a group depends, as shown in Figure 50.
132 Figure 50 Relationships among PIM protocols For more information about IGMP SSM mapping, see Configuring IGMP (available only on the HP 5 500 EI). PIM support for VPNs To support PIM for VPNs, a multicast router that runs PIM maintains an independent set of PIM neighbor table, multicast routing table, BSR information, and RP-set information for each VPN. After receiving a multicast data packet, the multicas t router checks which VPN the data packet belongs to, and then forwards the packet according to the multicast routing table for that VPN or creates a multicast routing entry for that VPN. Protocols and standards • RFC 3973, Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification(Revised) • RFC 4601, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised) • RFC 5015, Bidirectional Protocol Independent Multicast (BIDIR-PIM) • RFC 5059, Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) • RFC 4607, Source-Specific Multicast for IP • Draft-ietf-ssm-overview-05, An Overview of Source-Specific Multicast (SSM) Configuring PIM-DM PIM-DM configuration task list
133 Task Remarks Enabling PIM-DM Required Enabling state-refresh capability Optional Configuring state-refresh parameters Optional Configuring PIM-DM graft retry period Optional Configuring PIM common features Optional Configuration prerequisites Before you configure PIM-DM, complete the following tasks: • Configure any unicast routing protocol so that a ll devices in the domain are interoperable at the network layer. • Determine the interval between state-refresh messages. • Determine the minimum time to wait before receiving a new refresh message. • Determine the TTL value of state-refresh messages. • Determine the graft retry period. Enabling PIM-DM With PIM-DM enabled, a router sends hello messag es periodically to discover PIM neighbors and processes messages from the PIM neighbors. When you deploy a PIM-DM domain, enable PIM-DM on all non-border interfaces of the routers. IMPORTANT: • All the interfaces in the same VPN instance on the same device must operate in the same PIM mode. • PIM-DM does not work with multicast groups in the SSM group range. Enabling PIM-DM globally on the public network Step Command Remarks 1. Enter system view. system-view N/A 2. Enable IP multicast routing. multicast routing-enable Disabled by default. 3. Enter interface view. interface interface-type interface-number N/A 4. Enable PIM-DM. pim dm Disabled by default. Enabling PIM-DM in a VPN instance Step Command Description 1. Enter system view. system-view N/A 2. Create a VPN instance and enter VPN instance view. ip vpn-instance vpn-instance-name N/A
134 Step Command Description 3. Configure an RD for the VPN instance. route-distinguisher route-distinguisher Not configured by default. 4. Enable IP multicast routing. multicast routing-enable Disabled by default. 5. Enter interface view. interface interface-type interface-number N/A 6. Bind the interface with a VPN instance. ip binding vpn-instance vpn-instance-name By default, an interface belongs to the public network, and is not bound with any VPN instance. 7. Enable PIM-DM. pim dm Disabled by default. For more information about the ip vpn-instance, route-distinguisher , and ip binding vpn-instance commands, see IP Routing Command Referenc e. For more information about the multicast routing-enable command, see IP Multicast Command Reference . Enabling state-refresh capability Pruned interfaces resume multicast forwarding when the pruned state times out. To prevent this, the router with the multicast source attached periodically sends an (S, G) state-refresh message, which is forwarded hop by hop along the initial multicast flooding path of the PIM-DM domain, to refresh the prune timer state of all the routers on the path. A multi-access subnet can have the st ate-refresh capability only if the state-refresh capability is enabled on all PIM routers on the subnet. To enable the state-refresh capability: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the state-refresh capability. pim state-refresh-capable Optional Enabled by default Configuring state-refresh parameters The router directly connected with the multicast source periodically sends state-refresh messages. You can configure the interval for sending such messages. A router might receive multiple state -refresh messages within a short time, and some of them might be duplicated messages. To keep a router from receiv ing such duplicated messages, you can configure the time that the router must wait before it receives next state-refresh message. If the router receives a new state-refresh message within the waiting time, it discar ds the message. If this timer times out, the router will accept a new state-refresh message, refresh its own PIM-DM state, and reset the waiting timer. The TTL value of a state-refresh message decrements by 1 whenever it passes a router before it is forwarded to the downstream node until the TTL value comes down to 0. In a small network, a state-refresh message might cycle in the network. To effectively control the propagation scope of state-refresh messages, configure an appropri ate TTL value based on the network size.