chapter 11 configuring ip multicast protocols (9300 series...

Chapter 11 Configuring IP Multicast Protocols

(9300 Series Only)

This chapter describes how to configure ProCurve Routing Switches for Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP). ProCurve Routing Switches support the following IP multicast versions:

• Internet Group Management Protocol (IGMP) V1 and V2

• Internet Group Management Protocol (IGMP) V3

• PIM Dense mode (PIM DM) V1 (draft-ietf-pim-dm-05) and V2 (draft-ietf-pim-v2-dm-03)

• PIM Sparse mode (PIM SM) V2 (RFC 2362)

• DVMRP V2 (RFC 1075)

NOTE: Each of the multicast protocols uses IGMP. IGMP is automatically enabled on an interface when you configure PIM or DVMRP on an interface and is disabled on the interface if you disable PIM or DVMRP on the interface.

Overview of IP Multicasting Multicast protocols allow a group or channel to be accessed over different networks by multiple stations (clients) for the receipt and transmit of multicast data.

Distribution of stock quotes, video transmissions such as news services and remote classrooms, and video conferencing are all examples of applications that use multicast routing.

ProCurve Routing Switches support two different multicast routing protocols—Distance Vector Multicast Routing Protocol (DVMRP) and Protocol-Independent Multicast (PIM) protocol along with the Internet Group Membership Protocol (IGMP).

PIM and DVMRP are broadcast and pruning multicast protocols that deliver IP multicast datagrams. The protocols employ reverse path lookup check and pruning to allow source-specific multicast delivery trees to reach all group members. DVMRP and PIM build a different multicast tree for each source and destination host group.

NOTE: Both DVMRP and PIM can concurrently operate on different ports of a ProCurve Routing Switch.

Multicast Terms The following are commonly used terms in discussing multicast-capable routers. These terms are used throughout this chapter:

June 2005 11 - 1

Advanced Configuration and Management Guide for ProCurve 9300/9400 Series Routing Switches

Node: Refers to a router or Routing Switch.

Root Node: The node that initiates the tree building process. It is also the router that sends the multicast packets down the multicast delivery tree.

Upstream: Represents the direction from which a router receives multicast data packets. An upstream router is a node that sends multicast packets.

Downstream: Represents the direction to which a router forwards multicast data packets. A downstream routeris a node that receives multicast packets from upstream transmissions.

Group Presence: Means that a multicast group has been learned from one of the directly connected interfaces. Members of the multicast group are present on the router.

Intermediate nodes: Routers that are in the path between source routers and leaf routers.

Leaf nodes: Routers that do not have any downstream routers.

Multicast Tree: A unique tree is built for each source group (S,G) pair. A multicast tree is comprised of a rootnode and one or more nodes that are leaf or intermediate nodes.

Changing Global IP Multicast Parameters The following configurable parameters apply to PIM-DM, PIM-SM, and DVMRP.

• Maximum number of PIM or DVMRP groups – You can change the maximum number of groups of each type for which the software will allocate memory.

• Internet Group Membership Protocol (IGMP) V1 and V2 parameters – You can change the query interval, group membership time, and maximum response time.

• Hardware forwarding of fragmented IP multicast packets – You can enable the Routing Switch to forward all fragments of fragmented IP multicast packets in hardware.

Changing Dynamic Memory Allocation for IP Multicast Groups Routing Switches support up to 1024 PIM groups and 1024 DVMRP groups by default. Memory for the groups is allocated dynamically as needed. For each protocol, previous releases support a maximum of 255 groups and 255 IGMP memberships.

NOTE: Beginning with software release 07.6.04, the number of interface groups you can configure for DVMRP and PIM is unlimited; therefore, the system-max dvmrp-max-int-group and the system-max pim-max-int-group commands that define their maximum table sizes have been removed.

The software allocates memory globally for each group, and also allocates memory separately for each interface’s IGMP membership in a multicast group. An interface becomes a member of a multicast group when the interface receives an IGMP group membership report. For example, if the Routing Switch learns about one multicast group, global memory for one group is used. In addition, if three interfaces on the device receive IGMP group membership reports for the group, interface memory for three IGMP memberships also is used.

Since the same group can use multiple allocations of memory (one for the group itself and one for each interface’s membership in the group), you can increase the maximum number of IGMP memberships, up to 8192.

NOTE: The total for IGMP memberships applies to the device, not to individual interfaces. You can have up to 8192 IGMP memberships on all the individual interfaces, not up to 8192 IGMP memberships on each interface.

Increasing the Number of IGMP Membership

To increase the number of IGMP membership interfaces you can have for PIM, enter commands such as the following:

ProCurveRS(config)# system-max pim-max-int-group 4000

11 - 2 June 2005

Configuring IP Multicast Protocols (9300 Series Only)

ProCurveRS(config)# write memory

This command enables the device to have up to 4000 IGMP memberships for PIM.

NOTE: The system-max pim-max-int-group command is no longer available beginning with software release 07.6.04 since you can configure an unlimited number of PIM interface groups for DVMRP.

Syntax: [no] system-max pim-max-int-group <num>

The <num> parameter specifies the maximum number of IGMP memberships for PIM, and can be from 256 – 8192.

To increase the number of IGMP memberships interfaces you can have for DVMRP, enter commands such as the following:

ProCurveRS(config)# system-max dvmrp-max-int-group 3000 ProCurveRS(config)# write memory

NOTE: The system-max dvmrp-max-int-group command is no longer available beginning with software release 07.6.04 since you can configure an unlimited number of DVMRP interface groups.

Syntax: [no] system-max dvmrp-max-int-group <num>

The <num> parameter specifies the maximum number of IGMP memberships for DVMRP, and can be from 256 – 8192.

NOTE: You do not need to reload the software to place these changes into effect.

Defining the Maximum Number of Multicast Flows

The Multicast Flow table is shared by PIM and DVMRP. It defines the maximum number of flows for a PIM or DVMRP multicast switching that can be written in hardware (CAM). To define the maximum number of entries for the Multicast Flow table, enter a command such as the following:

ProCurveRS(config)# system-max multicast-flow 2048

Syntax: system-max multicast-flow <num>

The <num> parameter specifies the maximum number of PIM and DVMRP multicast cache flows that can be stored in the CAM. Enter a number from 512 – 2048. The default is 1024.

NOTE: Do not set this maximum too high since you may run out of resources in the CAM.

Defining the Maximum Number of DVMRP Cache Entries

The DVMRP cache system parameter defines the maximum number of repeated DVMRP traffic being sent from the same source address and being received by the same destination address. To define this maximum, enter a command such as the following:

ProCurveRS(config)# system-max dvmrp-mcache 500

Syntax: system-max dvmrp-mcache <num>

The <num> parameter specifies the maximum number of multicast cache entries for DVMRP. Enter a number from 128 – 2048. The default is 512.

Defining the Maximum Number of PIM Cache Entries

The PIM cache system parameter defines the maximum number of repeated PIM traffic being sent from the same source address and being received by the same destination address. To define this maximum, enter a command such as the following:

ProCurveRS(config)# system-max pim-mcache 999

Syntax: system-max pim-mcache <num>

June 2005 11 - 3


The <num> parameter specifies the maximum number of multicast cache entries for PIM. Enter a number from 256 – 4096. The default is 1024.

Changing IGMP V1 and V2 Parameters IGMP allows HP routers to limit the multicast of IGMP packets to only those ports on the router that are identified as IP Multicast members. This section applies to HP devices that support IGMP versions 1 and 2.

The router actively sends out host queries to identify IP Multicast groups on the network, inserts the group information in an IGMP packet, and forwards the packet to IP Multicast neighbors.

The following IGMP V1 and V2 parameters apply to PIM and DVMRP:

• IGMP query interval – Specifies how often the Routing Switch queries an interface for group membership. Possible values are 1 – 3600. The default is 60.

• IGMP group membership time – Specifies how many seconds an IP Multicast group can remain on a Routing Switch interface in the absence of a group report. Possible values are 1 – 7200. The default is 60.

• IGMP maximum response time – Specifies how many seconds the Routing Switch will wait for an IGMP response from an interface before concluding that the group member on that interface is down and removing the interface from the group. Possible values are 1 – 10. The default is 5.

To change these parameters, you must first enable IP multicast routing by entering the following CLI command at the global CLI level:

ProCurveRS(config)# ip multicast-routing

Syntax: [no] ip multicast-routing

NOTE: You must enter the ip multicast-routing command before changing the global IP Multicast parameters. Otherwise, the changes do not take effect and the software uses the default values.

Modifying IGMP (V1 and V2) Query Interval Period

The IGMP query interval period defines how often a router will query an interface for group membership. Possible values are 1 – 3,600 seconds and the default value is 60 seconds.

USING THE CLI

To modify the default value for the IGMP (V1 and V2) query interval, enter the following:

ProCurveRS(config)# ip igmp query 120

Syntax: ip igmp query-interval <1-3600>

USING THE WEB MANAGEMENT INTERFACE

To modify the default value for the IGMP query interval:

1. Log on to the device using a valid user name and password for read-write access. The System configuration panel is displayed.

2. Click on the plus sign next to Configure in the tree view to display the configuration options.

3. Click on the plus sign next to DVMRP in the tree view to display the DVMRP configuration options.

4. Select the IGMP link to display the IGMP configuration panel.

5. Enter a value from 1 – 3600 in the Query Interval field.

6. Click the Apply button to save the change to the device’s running-config file.

7. Select the Save link at the bottom of the dialog. Select Yes when prompted to save the configuration change to the startup-config file on the device’s flash memory.

Modifying IGMP (V1 and V2) Membership Time

Group membership time defines how long a group will remain active on an interface in the absence of a group report. Possible values are from 1 – 7200 seconds and the default value is 140 seconds.

11 - 4 June 2005


USING THE CLI

To define an IGMP (V1 and V2) membership time of 240 seconds, enter the following:

ProCurveRS(config)# ip igmp group-membership-time 240

Syntax: ip igmp group-membership-time <1-7200>


To modify the default value for the IGMP (V1 and V2) membership time, you would do the following:

1. Log on to the device using a valid user name and password for read-write access. The System configuration panel is displayed.

2. Click on the plus sign next to Configure in the tree view to display the configuration options.

3. Click on the plus sign next to DVMRP in the tree view to display the DVMRP configuration options.

4. Select the IGMP link to display the IGMP configuration panel.

5. Enter a value from 1 – 7200 in the Group Membership Time field.



Modifying IGMP (V1 and V2) Maximum Response Time

Maximum response time defines how long the Routing Switch will wait for an IGMP (V1 and V2) response from an interface before concluding that the group member on that interface is down and removing the interface from the group. Possible values are 1 – 10. The default is 5.

USING THE CLI

To change the IGMP (V1 and V2) maximum response time, enter a command such as the following at the global CONFIG level of the CLI:

ProCurveRS(config)# ip igmp max-response-time 8

Syntax: [no] ip igmp max-response-time <num>

The <num> parameter specifies the number of seconds and can be a value from 1 – 10. The default is 5.


You cannot change this parameter using the Web management interface.

Enabling Hardware Forwarding of Multicast Traffic On Tagged Ports (EP only) Software release 07.6.04 and later supports IPC and IGC versions that can forward multicast traffic on tagged ports in hardware instead of sending the traffic to the CPU for forwarding. When you use these versions, multicast traffic that needs to be forwarded on a tagged port is forwarded in hardware.

NOTE: This enhancement applies to Layer 3 multicast traffic on EP Routing Switches only. All Layer 2 multicast traffic on EP or Standard devices is forwarded by the CPU.

Previous releases and the current release already provide hardware forwarding of multicast traffic on untagged ports.

• If all multicast traffic is on untagged ports, the traffic is forwarded in hardware on EP or Standard.

• If any of the ports forwarding multicast traffic is a tagged port, a Standard device forwards all the multicast traffic in software. An EP device forwards the traffic in hardware if the device contains the required IGC and IPC versions and the support is enabled.

IPC and IGC Requirements

Multicast hardware forwarding for tagged ports requires at least the following IPC and IGC versions:

June 2005 11 - 5


• IPC version 300 (ASIC version 0x48) or later

• IGC version 400 (ASIC version 0x49) or later

To determine the IPC and IGC versions in your device, enter the show version command. Here is an example. The version information is shown in bold type. In this example, the IPCs on the module in slot 13 are the required version but the IGCs on the module in slot 1 are earlier than the required version.

ProCurveRS# show version SW: Version 07.6.04b1T53 Copyright (c) 1996-2002 Hewlett-Packard.

Compiled on Sep 05 2002 at 16:00:44 labeled as B2R07506b1(3849519 bytes) from Secondary 07506r.bin

HW: 9315M Router, SYSIF version 21==========================================================================SL 1: J-BxGMR4 EP Management Module, SYSIF 2 (Mini GBIC), M4, ACTIVE

Serial #: PR15021840 4096 KB BRAM, EP ASIC IGC version 47, BIA version 8832768 KB PRAM and 2M-Bit*1 CAM for IGC 0, version 044732768 KB PRAM and 2M-Bit*1 CAM for IGC 1, version 0447==========================================================================SL 13: J-B48E EP Copper E Module, SYSIF 2

Serial #: SA26020347 4096 KB BRAM, EP ASIC IPC version 48, BIA version 89 8192 KB PRAM and 2M-Bit*1 CAM for IPC 48, version 1848 8192 KB PRAM and 2M-Bit*1 CAM for IPC 49, version 1848==========================================================================Active management module: 466 MHz Power PC processor 750 (version 8/8302) 65 MHz bus

512 KB boot flash memory 16384 KB code flash memory 256 KB SRAM 512 MB DRAMThe system uptime is 3 minutes 42 secondsThe system : started=warm start reloaded=by "reload"=========================================================

NOTE: All IPCs and IGCs on the device must have at least the versions listed above. Otherwise, the hardware forwarding is disabled and the device uses the CPU to forward multicast traffic.

Disabling or Re-Enabling Hardware Multicast Forwarding For Tagged Ports

If PIM or DVMRP is enabled on the device, and all the IPCs and IGCs in the device are at least the versions listed in “IPC and IGC Requirements” , hardware multicast forwarding for tagged ports is enabled by default. However, if the device will be forwarding multicast traffic on untagged ports only or will not be forwarding any multicast traffic at all, HP recommends that you disable the hardware multicast forwarding for tagged ports. The feature uses CAM resources even if none of the tagged ports are actually forwarding multicast traffic.

NOTE: EP and Standard devices still forward all multicast traffic on untagged ports in hardware, regardless of whether multicast hardware forwarding for tagged ports is enabled or disabled.

To disable hardware multicast forwarding for tagged ports, enter the following command at the global CONFIG level of the CLI:

ProCurveRS(config)# mcast-hw-replic-disable ProCurveRS(config)# write memory ProCurveRS(config)# end ProCurveRS# reload

Syntax: [no] mcast-hw-replic-disable

11 - 6 June 2005


NOTE: You must save the configuration change and reload the software to place the change into effect.

The feature is enabled by default if PIM or DVMRP is enabled and all IPCs and IGCs are the required versions. You also can manually re-enable the feature by entering the following command:

ProCurveRS(config)# no mcast-hw-replic-disable

NOTE: If the device does not contain the required version for all IPCs and IGCs, entering the command to enable the feature does not result in the feature being enabled.

Enabling Hardware Forwarding of Multicast Traffic in One-Armed-Router Configurations As described above, EP devices running software releases later than 07.6.04 forward multicast traffic destined to multiple VLANs on tagged ports, without the need to send the traffic to the CPU for forwarding. This support is described in “Enabling Hardware Forwarding of Multicast Traffic On Tagged Ports (EP only)” on page 11-5. However, this default behavior does not apply to one-armed-router configurations, in which traffic received on a port is destined to another VLAN on the same port.

For example, assume that ports 1/1 and 1/2 are members of two port-based VLANs (10 and 20), and each VLAN has a virtual routing interface. If port 1/1 receives multicast traffic from VLAN 10 and needs to forward the traffic to the virtual routing interface on VLAN 20, the device forwards the traffic to port 1/2 in hardware but uses the CPU to process the same traffic for forwarding back onto port 1/1.

You can enable the device to forward multicast traffic in hardware even in one-armed-router configurations. When you enable this support, the devices still forward multicast traffic between ports in hardware.

NOTE: You cannot use sFlow or port monitoring and hardware forwarding of multicast traffic in one-armed-router configurations on the same device. If you plan to enable hardware forwarding of multicast traffic in one-armed-router configurations, you must first make sure that sFlow and port monitoring are disabled on all ports. If either of these features is enabled when you enable multicast traffic in one-armed-router configurations, you may get unexpected results.

To enable hardware forwarding of multicast traffic in one-armed-router configurations, enter the following commands:

ProCurveRS(config)# mcast-hw-replic-oar ProCurveRS(config)# write memory ProCurveRS(config)# end ProCurveRS# reload

Syntax: [no] mcast-hw-replic-oar


NOTE: For hardware forwarding of multicast traffic in one-armed-router configurations to take effect, hardware forwarding of multicast traffic on tagged ports must be enabled. If you disable hardware forwarding of multicast traffic on tagged ports (by entering the mcast-hw-replic-disable command), the mcast-hw-replic-oar command does not take effect.

Displaying the State of Hardware Multicast Forwarding

To determine whether hardware multicast forwarding is enabled, enter either of the following commands:

• show ip pim resource

• show ip dvmrp resource

June 2005 11 - 7


The last line of the display shows the state of hardware multicast forwarding. Here is an example.

ProCurveRS# show ip pim resource allocated in-use available alloc-fail upper-limit

flow 1022 0 1022 0 PIM mcache 1024 0 1023 0 NBR list 64 0 64 0 64 interface group global group timer

256 256 256

0 0 0

256 256 256

0 0 0

2048 1024 1024

prune nbr prunejoin/prune elem pimsm OIF IGMP group

1024 128

12240 256 256

0 0 0 0 0

1024 128

12240 256 256

0 0 0 0 0

4096 256 48960

no-limit 1024

HW tagged replication enabled

Enabling Hardware Forwarding for all Fragments of IP Multicast Packets

NOTE: For EP devices running software release 07.6.04 or later, refer to the section “EP Hardware Forwarding of Multicast Traffic on Tagged and Untagged Ports” on page 11-8 for details about configuring hardware forwarding of multicast traffic.

By default, a ProCurve Routing Switch forwards the first fragment of a fragmented IP multicast packet through hardware, but forwards the remaining fragments through the software. You can enable the device to forward all the fragments of fragmented IP multicast packet through hardware.

To enable hardware forwarding of all the IP multicast fragments, use the following CLI method.

NOTE: You must save the configuration and reload the software to place the change into effect.

USING THE CLI

To enable hardware forwarding of all IP multicast fragments, enter the following commands:

ProCurveRS(config)# ip multicast-perf ProCurveRS(config)# write memory ProCurveRS(config)# end ProCurveRS# reload

Syntax: [no] ip multicast-perf


You cannot configure this feature using the Web management interface.

EP Hardware Forwarding of Multicast Traffic on Tagged and Untagged Ports Software release 07.6.04 adds support for EP devices to perform hardware forwarding of Layer 2 multicast forwarding on tagged and untagged ports. Previous releases sent this traffic to the CPU for forwarding (that is, forwarded it in software).

4The following table summarizes these enhancements.

Table 11.1: Multicast forwarding on EP devices

Layer 2 Traffic Layer 3 Traffic

Tagged Hardware, starting in Hardware, starting in Release 07.6.04 Release 07.6.04

11 - 8 June 2005


Table 11.1: Multicast forwarding on EP devices

Layer 2 Traffic Layer 3 Traffic

Untagged Hardware, starting in Hardware Release 07.6.04

Hardware forwarding for multicast traffic on EP devices is automatically enabled if the following requirements are met:

• PIM or DVMRP is enabled on the EP device.

• The hardware multicast replication feature has not been disabled on the EP device. See “Disabling or Re-Enabling Hardware Multicast Forwarding” on page 11-9.

NOTE: If you plan to use hardware forwarding for multicast traffic on an EP device, contact your HP account representative for additional requirements that may apply to your installation.

When hardware forwarding of multicast traffic is enabled, multicast traffic may still be forwarded in software if one of the following occurs:

• Registration packets in PIM Sparse mode are sent or received.

• Packets are coming from or going to a tunnel. (PIM Dense mode and DVMRP support tunnels.)

• The PIM flow multicast cache is not available. The PIM flow multicast cache is created after two packets for the same group and source address are received by the hardware. You can check if a PIM flow multicast cache is available by using the show ip pim flow command.

• The one-armed-router feature is being used, but this feature is not enabled.

NOTE: The time-to-live value in the IP header of a Layer 3 routed packet is not decremented if the packet is also Layer 2-switched in the EP hardware.

Disabling or Re-Enabling Hardware Multicast Forwarding

If PIM or DVMRP is enabled on the device, hardware multicast forwarding is enabled by default. However, if the device will be forwarding multicast traffic on untagged ports only or will not be forwarding any multicast traffic at all, HP recommends that you disable the hardware multicast forwarding for tagged ports. The feature uses CAM resources even if none of the tagged ports are actually forwarding multicast traffic.

NOTE: EP and Standard devices still forward all multicast traffic on untagged ports in hardware, regardless of whether multicast hardware forwarding for tagged ports is enabled or disabled.

To disable hardware multicast forwarding for tagged ports, enter the following command at the global CONFIG level of the CLI:

ProCurveRS(config)# mcast-hw-replic-disable

Syntax: [no] mcast-hw-replic-disable

The feature is enabled by default if PIM or DVMRP is enabled on the EP device. You also can manually re-enable the feature by entering the following command:

ProCurveRS(config)# no mcast-hw-replic-disable

Enabling Hardware Forwarding of Multicast Traffic in One-Armed-Router Configurations EP devices running software release 07.6.04 or later forward multicast traffic destined to multiple VLANs on tagged ports in hardware by default, without the need to send the traffic to the CPU for forwarding. However, this default behavior does not apply to one-armed-router configurations, in which traffic received on a port is destined to another VLAN on the same port.

For example, assume that ports 1/1 and 1/2 are members of two port-based VLANs (10 and 20), and each VLAN has a virtual routing interface. If port 1/1 receives multicast traffic from VLAN 10 and needs to forward the traffic to

June 2005 11 - 9


the virtual routing interface on VLAN 20, the device forwards the traffic to port 1/2 in hardware but uses the CPU to process the same traffic for forwarding back onto port 1/1.

You can enable the device to forward multicast traffic in hardware even in one-armed-router configurations. When you enable this support, the devices still forward multicast traffic between ports in hardware.

NOTE: You cannot use sFlow or port monitoring and hardware forwarding of multicast traffic in one-armed-router configurations on the same device. If you plan to enable hardware forwarding of multicast traffic in one-armed-router configurations, you must first make sure that sFlow and port monitoring are disabled on all ports. If either of these features is enabled when you enable multicast traffic in one-armed-router configurations, you may get unexpected results.

To enable hardware forwarding of multicast traffic in one-armed-router configurations, enter the following commands:

ProCurveRS(config)# mcast-hw-replic-oar ProCurveRS(config)# write memory ProCurveRS(config)# end ProCurveRS# reload

Syntax: [no] mcast-hw-replic-oar


NOTE: For hardware forwarding of multicast traffic in one-armed-router configurations to take effect, hardware forwarding of multicast traffic on tagged ports must be enabled. If you disable hardware forwarding of multicast traffic on tagged ports (by entering the mcast-hw-replic-disable command), the mcast-hw-replic-oar command does not take effect.

Displaying the State of Hardware Multicast Forwarding

To determine whether hardware multicast forwarding is enabled, enter either of the following commands:

• show ip pim resource

• show ip dvmrp resource

The last line of the display shows the state of hardware multicast forwarding. Here is an example.

ProCurveRS# show ip pim resource allocated in-use available alloc-fail upper-limit

flow 1022 0 1022 0 PIM mcache 1024 0 1023 0 NBR list 64 0 64 0 64 interface group 256 0 256 0 2048 global group 256 0 256 0 1024 timer 256 0 256 0 1024 prune nbr 1024 0 1024 0 4096 prune 128 0 128 0 256 join/prune elem 12240 0 12240 0 48960 pimsm OIF 256 0 256 0 no-limit IGMP group 256 0 256 0 1024 HW tagged replication enabled

Adding an Interface to a Multicast Group You can manually add an interface to a multicast group. This is useful in the following cases:

• Hosts attached to the interface are unable to add themselves as members of the group using IGMP.

11 - 10 June 2005


• There are no members for the group attached to the interface.

When you manually add an interface to a multicast group, the HP device forwards multicast packets for the group but does not itself accept packets for the group.

You can manually add a multicast group to individual ports only. If the port is a member of a virtual routing interface, you must add the ports to the group individually.

To manually add a port to a multicast group, enter a command such as the following at the configuration level for the port:

ProCurveRS(config-if-1/1)# ip igmp static-group 224.2.2.2

This command adds port 1/1 to multicast group 224.2.2.2.

To add a port that is a member of a virtual routing interface to a multicast group, enter a command such as the following at the configuration level for the virtual routing interface:

ProCurveRS(config-vif-1)# ip igmp static-group 224.2.2.2 ethernet 5/2

This command adds port 5/2 in virtual routing interface 1 to multicast group 224.2.2.2.

Syntax: [no] ip igmp static-group <ip-addr> [ethernet <portnum>]

The <ip-addr> parameter specifies the group number.

The ethernet <portnum> parameter specifies the port number. Use this parameter if the port is a member of a virtual routing interface, and you are entering this command at the configuration level for the virtual routing interface.

Manually added groups are included in the group information displayed by the following commands:

• show ip igmp group

• show ip pim group

PIM Dense

NOTE: This section describes the “dense” mode of PIM, described in RFC 1075. See “PIM Sparse” on page 1122 for information about PIM Sparse.

PIM was introduced to simplify some of the complexity of the routing protocol at the cost of additional overhead tied with a greater replication of forwarded multicast packets. PIM is similar to DVMRP in that PIM builds sourcerouted multicast delivery trees and employs reverse path check when forwarding multicast packets.

There are two modes in which PIM operates: Dense and Sparse. The Dense Mode is suitable for densely populated multicast groups, primarily in the LAN environment. The Sparse Mode is suitable for sparsely populated multicast groups with the focus on WAN.

PIM primarily differs from DVMRP by using the IP routing table instead of maintaining its own, thereby being routing protocol independent.

Initiating PIM Multicasts on a Network Once PIM is enabled on each router, a network user can begin a video conference multicast from the server on R1 as shown in Figure 11.1. When a multicast packet is received on a PIM-capable router interface, the interface checks its IP routing table to determine whether the interface that received the message provides the shortest path back to the source. If the interface does provide the shortest path back to the source, the multicast packet is then forwarded to all neighboring PIM routers. Otherwise, the multicast packet is discarded and a prune message is sent back upstream.

In Figure 11.1, the root node (R1) is forwarding multicast packets for group 229.225.0.1, which it receives from the server, to its downstream nodes, R2, R3, and R4. Router R4 is an intermediate router with R5 and R6 as its downstream routers. Because R5 and R6 have no downstream interfaces, they are leaf nodes. The receivers in this example are those workstations that are resident on routers R2, R3, and R6.

June 2005 11 - 11


Pruning a Multicast Tree As multicast packets reach these leaf routers, the routers check their IGMP databases for the group. If the group is not in a router’s IGMP database, the router discards the packet and sends a prune message to the upstream router. The router that discarded the packet also maintains the prune state for the source, group (S,G) pair. The branch is then pruned (removed) from the multicast tree. No further multicast packets for that specific (S,G) pair will be received from that upstream router until the prune state expires. You can configure the PIM Prune Timer (the length of time that a prune state is considered valid).

For example, in Figure 11.1 the sender with address 207.95.5.1 is sending multicast packets to the group 229.225.0.1. If a PIM router receives any groups other than that group, the router discards the group and sends a prune message to the upstream PIM router.

In Figure 11.2, Router R5 is a leaf node with no group members in its IGMP database. Therefore, the router must be pruned from the multicast tree. R5 sends a prune message upstream to its neighbor router R4 to remove itself from the multicast delivery tree and install a prune state, as seen in Figure 11.2. Router 5 will not receive any further multicast traffic until the prune age interval expires.

When a node on the multicast delivery tree has all of its downstream branches (downstream interfaces) in the prune state, a prune message is sent upstream. In the case of R4, if both R5 and R6 are in a prune state at the same time, R4 becomes a leaf node with no downstream interfaces and sends a prune message to R1. With R4 in a prune state, the resulting multicast delivery tree would consist only of leaf nodes R2 and R3.

Figure 11.1 Transmission of multicast packets from the source to host group members

11 - 12 June 2005


Figure 11.2 Pruning leaf nodes from a multicast tree

Group Member

Group Member

Leaf Node (No Group Members)

R5

R3

R4

R6

R1R2

Leaf Node

Leaf Node

(207.95.5.1, 229.225.0.1)

...

Group Member

Group Member

Group Member

...

...

sent to upstream router (R4)

(No Group Members)

229.225.0.1 229.225.0.1

Video Conferencing Server

(Source, Group)

Prune Message

Interrmediate Node

Group Group Group Member Member Member

229.225.0.1

Grafts to a Multicast Tree A PIM router restores pruned branches to a multicast tree by sending graft messages towards the upstream router. Graft messages start at the leaf node and travel up the tree, first sending the message to its neighbor upstream router.

In the example above, if a new 229.255.0.1 group member joins on router R6, which was previously pruned, a graft is sent upstream to R4. Since the forwarding state for this entry is in a prune state, R4 sends a graft to R1. Once R4 has joined the tree, R4 along with R6 once again receive multicast packets.

Prune and graft messages are continuously used to maintain the multicast delivery tree. No configuration is required on your part.

PIM DM Versions Software release 07.5.xx and higher supports PIM DM V1 and V2. Previous versions support V1 only. The default in previous releases is V1. The default in release 07.2.05 and higher is V2. You can specify the version on an individual interface basis.

The primary difference between PIM DM V1 and V2 is the methods the protocols use for messaging:

• PIM DM V1 – uses the Internet Group Management Protocol (IGMP) to send messages

• PIM DM V2 – sends messages to the multicast address 224.0.0.13 (ALL-PIM-ROUTERS) with protocol number 103

The CLI commands for configuring and managing PIM DM are the same for V1 and V2. The only difference is the command you use to enable the protocol on an interface.

June 2005 11 - 13


NOTE: Version 2 is the default PIM DM version in software release 07.2.05 and higher. Previous releases support only version 1. The only difference between version 1 and version 2 is the way the protocol sends messages. The change is not apparent in most configurations. You can use version 2 instead of version 1 with no impact to your network. However, if you want to continue to use PIM DM V1 on an interface, you must change the version, then save the configuration.

NOTE: The note above doesn’t mean you can run different PIM versions on devices that are connected to each other. The devices must run the same version of PIM. If you want to connect a Routing Switch running software release 07.2.05 or higher and also running PIM to a device that is running PIM V1, you must change the version on the Routing Switch to V1 (or change the version on the device to V2, if supported).

Configuring PIM DM

NOTE: This section describes how to configure the “dense” mode of PIM, described in RFC 1075. See “Configuring PIM Sparse” on page 11-23 for information about configuring PIM Sparse.

Enabling PIM on the Router and an Interface

By default, PIM is disabled. To enable PIM:

• Enable the feature globally.

• Configure the IP interfaces that will use PIM.

• Enable PIM locally on the ports that have the IP interfaces you configured for PIM.

• Reload the software to place PIM into effect.

Suppose you want to initiate the use of desktop video for fellow users on a sprawling campus network. All destination workstations have the appropriate hardware and software but the HP routers that connect the various buildings need to be configured to support PIM multicasts from the designated video conference server as shown in Figure 11.1 on page 11-12.

PIM is enabled on each of the HP routers shown in Figure 11.1, on which multicasts are expected. You can enable PIM on each router independently or remotely from one of the routers with a Telnet connection. Follow the same steps for each router. A reset of the router is required when PIM is first enabled. Thereafter, all changes are dynamic.

Globally Enabling and Disabling PIM To globally enable PIM, enter the following command:

ProCurveRS(config)# router pim

Syntax: [no] router pim

NOTE: When PIM routing is enabled on an EP device, the line rate for receive traffic is reduced by about 5%. The reduction occurs due to overhead from the VLAN multicasting feature, which PIM routing uses. This behavior is normal and does not indicate a problem with the device.

In software releases prior to software release 07.8.00, the behavior of the [no] router pim command was as follows:

• ProCurve Routing Switches required a software reload whenever you enabled PIM using the router pim command.

• Entering a no router pim command removed all configuration for PIM multicast on a Routing Switch (router pim level) and all PIM and PIM-Sparse (ip pim and ip pim-sparse) configuration on all interfaces.

Beginning with software release 0 7.8.00:

• Entering router pim command to enable PIM does not require a software reload.

11 - 14 June 2005


• Entering a no router pim command removes all configuration for PIM multicast on a Routing Switch (router pim level) only.

Globally Enabling and Disabling PIM without Deleting Multicast Configuration As stated above entering a no router pim command deletes PIM configuration. If you want to disable PIM without deleting any PIM configuration, enter the following command:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# disable-pim

Syntax: [no] disable-pim

Use the [no] version of the command to re-enable PIM.

Enabling a PIM version USING THE CLI

To enable PIM on an interface, globally enable PIM, then enable PIM on interface 3, enter the following commands:

ProCurveRS(config)# router pim ProCurveRS(config)# int e 3 ProCurveRS(config-if-3)# ip address 207.95.5.1/24 ProCurveRS(config-if-3)# ip pim ProCurveRS(config-if-3)# write memory ProCurveRS(config-if-3)# end ProCurveRS# reload

Syntax: [no] ip pim [version 1 | 2]

The version 1 | 2 parameter specifies the PIM DM version. The default version is 2.

If you have enabled PIM version 1 but need to enable version 2 instead, enter either of the following commands at the configuration level for the interface:

ProCurveRS(config-if-1/1)# ip pim version 2

ProCurveRS(config-if-1/1)# no ip pim version 1

To disable PIM DM on the interface, enter the following command:

ProCurveRS(config-if-1/1)# no ip pim


1. Log on to the device using a valid user name and password for read-write access.

2. If you have not already enabled PIM, enable it by clicking on the Enable radio button next to PIM on the System configuration panel, then clicking Apply to apply the change.

3. Click on the plus sign next to Configure in the tree view to expand the list of configuration options.

4. Click on the plus sign next to PIM in the tree view to expand the list of PIM option links.

5. Click on the Virtual Interface link to display the PIM Interface configuration panel.

NOTE: If the device already has PIM interfaces, a table listing the interfaces is displayed. Click the Modify button to the right of the row describing an interface to change its configuration, or click the Add Virtual Interface link to display the PIM Interface configuration panel.

6. Select the interface type. You can select Subnet or Tunnel.

7. Select the IP address of the interface being configured from the Local Address pulldown menu.

8. If you are configuring an IP Tunnel, enter the IP address of the destination interface, the end point of the IP Tunnel, in the Remote Address field. IP tunneling must also be enabled and defined on the destination router interface as well.

June 2005 11 - 15


NOTE: The Remote Address field applies only to tunnel interfaces, not to sub-net interfaces.

9. Modify the time to live threshold (TTL) if necessary. The TTL defines the minimum value required in a packet in order for the packet to be forwarded out the interface.

NOTE: For example, if the TTL for an interface is set at 10, it means that only those packets with a TTL value of 10 or more will be forwarded. Likewise, if an interface is configured with a TTL Threshold value of 1, all packets received on that interface will be forwarded. Possible values are 1 – 64. The default value is 1.

10. Click the Add button to save the change to the device’s running-config file.


12. Click on the plus sign next to Command in the tree view to list the command options.

13. Select the Reload link and select Yes when prompted to reload the software. You must reload after enabling PIM to place the change into effect. If PIM was already enabled when you added the interface, you do not need to reload.

Modifying PIM Global Parameters

PIM global parameters come with preset values. The defaults work well in most networks, but you can modify the following parameters if you need to:

• Neighbor timeout

• Hello timer

• Prune timer

• Prune wait timer

• Graft retransmit timer

• Inactivity timer

Modifying Neighbor Timeout Neighbor timeout is the interval after which a PIM router will consider a neighbor to be absent. Absence of PIM hello messages from a neighboring router indicates that a neighbor is not present.

The default value is 180 seconds.

USING THE CLI

To apply a PIM neighbor timeout value of 360 seconds to all ports on the router operating with PIM, enter the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# nbr-timeout 360

Syntax: nbr-timeout <60-8000>

The default is 180 seconds.





11 - 16 June 2005


4. Click on the General link to display the PIM configuration panel, as shown in the following example.

5. Enter a value from 10 – 3600 into the Neighbor Router Timeout field.



Modifying Hello Timer This parameter defines the interval at which periodic hellos are sent out PIM interfaces. Routers use hello messages to inform neighboring routers of their presence. The default rate is 60 seconds.

USING THE CLI

To apply a PIM hello timer of 120 seconds to all ports on the router operating with PIM, enter the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# hello-timer 120

Syntax: hello-timer <10-3600>







5. Click on the General link to display the PIM configuration panel

6. Enter a value from 10 – 3600 into the Prune Time field.



Modifying Prune Timer This parameter defines how long an HP PIM router will maintain a prune state for a forwarding entry.

The first received multicast interface is forwarded to all other PIM interfaces on the router. If there is no presence of groups on that interface, the leaf node sends a prune message upstream and stores a prune state. This prune state travels up the tree and installs a prune state.

June 2005 11 - 17


A prune state is maintained until the prune timer expires or a graft message is received for the forwarding entry. The default value is 180 seconds.

USING THE CLI

To set the PIM prune timer to 90, enter the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# prune-timer 90

Syntax: prune-timer <10-3600>








6. Enter a value from 10 – 3600 in the Hello Time field.



Modifying the Prune Wait Timer Beginning with software release 07.6.04, a new CLI command, prune-wait, allows you to configure the amount of time a PIM router will wait before stopping traffic to neighbor routers that do not want the traffic. The value can be from zero to three seconds. The default is three seconds. A smaller prune wait value reduces flooding of unwanted traffic.

A prune wait value of zero causes the PIM router to stop traffic immediately upon receiving a prune message. If there are two or more neighbors on the physical port, then the prune-wait command should not be used because one neighbor may send a prune message while the other sends a join message at the during time or in less than three seconds.

To set the prune wait time to zero, enter the following commands:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# prune-wait 0

Syntax: prune-wait <time>

where <time> can be 0 - 3 seconds. A value of 0 causes the PIM router to stop traffic immediately upon receiving a prune message. The default is 3 seconds.

Viewing the Prune Wait Time To view the prune wait time, enter the following command at any level of the CLI:

9300 series(config)#show ip pim dense

Global PIM Dense Mode Settings Hello interval: 60, Neighbor timeout: 180 Graft Retransmit interval: 180, Inactivity interval: 180 Route Expire interval: 200, Route Discard interval: 340 Prune age: 180, Prune wait: 3

Modifying Graft Retransmit Timer The Graft Retransmit Timer defines the interval between the transmission of graft messages.

11 - 18 June 2005


A graft message is sent by a router to cancel a prune state. When a router receives a graft message, the router responds with a Graft Ack (acknowledge) message. If this Graft Ack message is lost, the router that sent the graft message will resend it.

USING THE CLI

To change the graft retransmit timer from the default of 180 to 90 seconds, enter the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# graft-retransmit-timer 90

Syntax: graft-retransmit-timer <10-3600>








6. Enter a value from 10 – 3600 into the Graft Retransmit Time field.



Modifying Inactivity Timer The router deletes a forwarding entry if the entry is not used to send multicast packets. The PIM inactivity timer defines how long a forwarding entry can remain unused before the router deletes it.

USING THE CLI

To apply a PIM inactivity timer of 90 seconds to all PIM interfaces, enter the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# inactivity-timer 90

Syntax: inactivity-timer <10-3600>








6. Enter a value from 10 – 3600 into the Inactivity field.



June 2005 11 - 19


Selection of Shortest Path Back to Source By default, when a multicast packet is received on a PIM-capable router interface in a multi-path topology, the interface checks its IP routing table to determine the shortest path back to the source. If the alternate paths have the same cost, the first alternate path in the table is picked as the path back to the source. For example, in the table below, the first four routes have the same cost back to the source. However, 137.80.127.3 will be chosen as the path to the source since it is the first one on the list. The router rejects traffic from any port other than Port V11 on which 137.80.127.3 resides.

Total number of IP routes: 19 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default

Type Destination NetMask Gateway Port Cost

.. 9 172.17.41.4 255.255.255.252*137.80.127.3 v11 2

O 172.17.41.4 255.255.255.252 137.80.126.3 v10 2

O 172.17.41.4 255.255.255.252 137.80.129.1 v13 2

O 172.17.41.4 255.255.255.252 137.80.128.3 v12 2

O

D 10 172.17.41.8 255.255.255.252 0.0.0.0 1/2 1

The Highest IP RPF feature was introduced in Enterprise software release 07.6.06. When this feature is enabled, the selection of the shortest path back to the source is based on which Reverse Path Forwarding (RPF) neighbor in the IP routing table has the highest IP address, if the cost of the routes are the same. For example, in the table above, Gateway 137.80.129.1 will be chosen as the shortest path to the source because it is the RPF neighbor with the highest IP address.

When choosing the RPF, the router first checks the Multicast Routing Table. If the table is not available, it chooses an RPF from the IP Routing Table. Multicast route is configured using the ip mroute command.

To enable the Highest IP RPF feature, enter commands such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# highest-ip-rpf

The command immediately enables the Highest IP RPF feature; there is no need to reboot the device.

Syntax: [no] highest-ip-rpf

Entering the no version of the command disables the feature; the shortest path back to the source will be based on the first entry in the IP routing table. If some PIM traffic paths were selected based on the highest IP RPF, these paths are changed immediately to use the first RPF in the routing table.


You cannot configure this feature using the Web management interface.

Failover Time in a Multi-Path Topology Previously, when a port in a multi-path topology fails, multicast routers could take up to one minute to establish a new path, if the failed port is the input port of the downstream router. Enterprise software release 07.6.06 and later reduces this time. A new path is re-established within a few seconds, depending on the routing protocol being used.

No configuration is required for this feature.

11 - 20 June 2005


Modifying the TTL The TTL defines the minimum value required in a packet for it to be forwarded out of the interface.

For example, if the TTL for an interface is set at 10, it means that only those packets with a TTL value of 10 or more will be forwarded. Likewise, if an interface is configured with a TTL Threshold value of 1, all packets received on that interface will be forwarded. Possible TTL values are 1 to 64. The default TTL value is 1.

USING THE CLI

To configure a TTL of 45, enter the following:

ProCurveRS(config-if-3/24)# ip pim ttl 45

Syntax: ip pim ttl <1-64>


To modify the PIM parameter (TTL) for an interface:




4. Select the Virtual Interface link to display a table listing the configured PIM Interfaces.

5. Click on the Modify button next to the interface you want to modify. The PIM Interface configuration panel is displayed.

6. Modify the parameters as needed.

7. Click the Add button to save the changes to the device’s running-config file.


Dropping PIM Traffic in Hardware Beginning with software release 07.8.00, unwanted PIM Dense or PIM Sparse multicast traffic can be dropped in hardware on Routing Switches. This feature does not apply to DVMRP traffic. Also, this feature applies only to devices with EP modules; Standard modules cannot drop tagged multicast packets in hardware.

When a multicast stream has no output interfaces, the Routing Switch can drop packets in hardware if the multicast traffic meets either of the following conditions:

• The input port of the traffic has no neighbor, so it is not necessary to send a prune message.

• The input port has neighbors and the traffic is Layer 2 with a source IP address that is on the same subnet as the input port. HP PIM Dense ignores prune message from a Routing Switch which is on the same subnet as the source.

USING THE CLI

To configure the device to drop PIM traffic in hardware, enter the following command at the router pim level:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# hardware-drop

Syntax: hardware-drop

June 2005 11 - 21


1

When you enable the hardware-drop feature, the show ip pim mcache command includes “drop” in the flag field if a CAM is installed for the purpose of the drop. For example,

ProCurveRS# show ip pim mcache (110.110.110.10 224.1.11.1) in v110 (e4/6), cnt=72 Source is directly connected Sparse Mode, RPT=0 SPT=1 Reg=0 fast=1 slow=0 pru=0 swL2=0 hwL2=0 drop age=60s up-time=183m fid=08ac, cam=3818,



PIM Sparse Software release 06.5.00 and higher contain support for Protocol Independent Multicast (PIM) Sparse version 2. PIM Sparse provides multicasting that is especially suitable for widely distributed multicast environments. The HP implementation is based on RFC 2362.

In a PIM Sparse network, a PIM Sparse router that is connected to a host that wants to receive information for a multicast group must explicitly send a join request on behalf of the receiver (host).

PIM Sparse routers are organized into domains. A PIM Sparse domain is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary. Figure 11.3 shows a simple example of a PIM Sparse domain. This example shows three Routing Switches configured as PIM Sparse routers. The configuration is described in detail following the figure.

Figure 11.3 Example PIM Sparse domain

PIM Sparse router B This interface is also the

PIM Sparse router C

VE 1 207.95.6.1

209.157.24.162

207.95.7.2

VE 1 207.95.6.2

this PIM Sparse domain, and

207.95.8.1

207.95.8.10 207.95.7.1

PIM Sparse router A Shortest Path Tree (SPT) path

Port 3/8

Rendezvous Point (RP) path

Bootstrap Router (BR) for

the Rendezvous Point (RP) for the PIM Sparse groups in this domain.

Port 3/8

Port 2/1 Port 2/2

Source for Group Receiver for Group 239.255.162.1 239.255.162.1

11 - 22 June 2005


PIM Sparse Router Types Routers that are configured with PIM Sparse interfaces also can be configured to fill one or more of the following roles:

• PMBR – A PIM router that has some interfaces within the PIM domain and other interface outside the PIM domain. PBMRs connect the PIM domain to the Internet.

NOTE: You cannot configure an HP routing interface as a PMBR interface for PIM Sparse in the current software release.

• BSR – The Bootstrap Router (BSR) distributes RP information to the other PIM Sparse routers within the domain. Each PIM Sparse domain has one active BSR. For redundancy, you can configure ports on multiple routers as candidate BSRs. The PIM Sparse protocol uses an election process to select one of the candidate BSRs as the BSR for the domain. The BSR with the highest BSR priority (a user-configurable parameter) is elected. If the priorities result in a tie, then the candidate BSR interface with the highest IP address is elected. In the example in Figure 11.3, PIM Sparse router B is the BSR. Port 2/2 is configured as a candidate BSR.

• RP – The RP is the meeting point for PIM Sparse sources and receivers. A PIM Sparse domain can have multiple RPs, but each PIM Sparse multicast group address can have only one active RP. PIM Sparse routers learn the addresses of RPs and the groups for which they are responsible from messages that the BSR sends to each of the PIM Sparse routers. In the example in Figure 11.3, PIM Sparse router B is the RP. Port 2/2 is configured as a candidate Rendezvous Point (RP).

To enhance overall network performance, ProCurve Routing Switches use the RP to forward only the first packet from a group source to the group’s receivers. After the first packet, the Routing Switch calculates the shortest path between the receiver and source (the Shortest Path Tree, or SPT) and uses the SPT for subsequent packets from the source to the receiver. The Routing Switch calculates a separate SPT for each source-receiver pair.

NOTE: Hewlett-Packard recommends that you configure the same ports as candidate BSRs and RPs.

RP Paths and SPT Paths Figure 11.3 shows two paths for packets from the source for group 239.255.162.1 and a receiver for the group. The source is attached to PIM Sparse router A and the recipient is attached to PIM Sparse router C. PIM Sparse router B in is the RP for this multicast group. As a result, the default path for packets from the source to the receiver is through the RP. However, the path through the RP sometimes is not the shortest path. In this case, the shortest path between the source and the receiver is over the direct link between router A and router C, which bypasses the RP (router B).

To optimize PIM traffic, the protocol contains a mechanism for calculating the Shortest Path Tree (SPT) between a given source and receiver. PIM Sparse routers can use the SPT as an alternative to using the RP for forwarding traffic from a source to a receiver. By default, ProCurve Routing Switches forward the first packet they receive from a given source to a given receiver using the RP path, but forward subsequent packets from that source to that receiver through the SPT. In Figure 11.3, Routing Switch A forwards the first packet from group 239.255.162.1’s source to the destination by sending the packet to router B, which is the RP. Router B then sends the packet to router C. For the second and all future packets that router A receives from the source for the receiver, router A forwards them directly to router C using the SPT path.

Configuring PIM Sparse To configure a ProCurve Routing Switch for PIM Sparse, perform the following tasks:

• Configure the following global parameter:

• Enable the PIM Sparse mode of multicast routing.

• Configure the following interface parameters:

• Configure an IP address on the interface

June 2005 11 - 23


• Enable PIM Sparse.

• Identify the interface as a PIM Sparse border, if applicable.


• Configure the following PIM Sparse global parameters:

• Identify the Routing Switch as a candidate PIM Sparse Bootstrap Router (BSR), if applicable.

• Identify the Routing Switch as a candidate PIM Sparse Rendezvous Point (RP), if applicable.

• Specify the IP address of the RP (if you want to statically select the RP).

NOTE: Hewlett-Packard recommends that you configure the same Routing Switch as both the BSR and the RP.

Limitations in this Release

The implementation of PIM Sparse in the current softwsare release has the following limitations:

• PIM Border Routers (PMBRs) are not supported. Thus, you cannot configure an HP routing interface as a PMBR interface for PIM Sparse.

• PIM Sparse and regular PIM (dense mode) cannot be used on the same interface.

• You cannot configure or display PIM Sparse information using the Web management interface. (You can display some general PIM information, but not specific PIM Sparse information.)

Configuring Global PIM Sparse Parameters

To configure the PIM Sparse global parameters, use either of the following methods.

NOTE: When PIM routing is enabled on an EP device, the line rate for receive traffic is reduced by about 5%. The reduction occurs due to overhead from the VLAN multicasting feature, which PIM routing uses. This behavior is normal and does not indicate a problem with the device.

USING THE CLI

To configure basic global PIM Sparse parameters, enter commands such as the following on each Routing Switch within the PIM Sparse domain:


Syntax: [no] router pim

NOTE: You do not need to globally enable IP multicast routing when configuring PIM Sparse.

The command in this example enables IP multicast routing, and enables the PIM Sparse mode of IP multicast routing. The command does not configure the Routing Switch as a candidate PIM Sparse Bootstrap Router (BSR) and candidate Rendezvous Point (RP). You can configure a ProCurve Routing Switch as a PIM Sparse router without configuring the Routing Switch as a candidate BSR and RP. However, if you do configure the Routing Switch as one of these, Hewlett-Packard recommends that you configure the Routing Switch as both of these. See “Configuring BSRs” on page 11-25.

In software releases prior to software release 07.8.00, the behavior of the [no] router pim command was as follows:

• ProCurve Routing Switches required a software reload whenever you enable or disable PIM using the no router pim command.

• Entering a no router pim command removed all configuration for PIM multicast on a Routing Switch (router pim level) and all PIM and PIM-Sparse (ip pim and ip pim-sparse) configuration on all interfaces.

11 - 24 June 2005


Beginning with software release 07.8.00:

• Entering no router pim command to disable PIM or DVMRP does not require a software reload.

• Entering a no router pim command removes all configuration for PIM multicast on a Routing Switch (router pim level) only.


You cannot configure PIM Sparse parameters using the Web management interface.

Globally Enabling and Disabling PIM without Deleting Multicast Configuration

As stated above entering a no router pim command deletes PIM configuration. If you want to disable PIM without deleting any PIM configuration, enter the following command:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# disable-pim

Syntax: [no] disable-pim

Use the [no] version of the command to re-enable PIM.

Configuring PIM Interface Parameters

After you enable IP multicast routing and PIM Sparse at the global level, you must enable it on the individual interfaces connected to the PIM Sparse network. To do so, use the following CLI method.

USING THE CLI

To enable PIM Sparse mode on an interface, enter commands such as the following:

ProCurveRS(config)# interface ethernet 2/2 ProCurveRS(config-if-2/2)# ip address 207.95.7.1 255.255.255.0 ProCurveRS(config-if-2/2)# ip pim-sparse

Syntax: [no] ip pim-sparse

The commands in this example add an IP interface to port 2/2, then enable PIM Sparse on the interface.

If the interface is on the border of the PIM Sparse domain, you also must enter the following command:

ProCurveRS(config-if-2/2)# ip pim border

Syntax: [no] ip pim border




Configuring BSRs

In addition to the global and interface parameters in the sections above, you need to identify an interface on at least one Routing Switch as a candidate PIM Sparse Bootstrap router (BSR) and candidate PIM Sparse Rendezvous Point (RP).

NOTE: It is possible to configure the Routing Switch as only a candidate BSR or RP, but Hewlett-Packard recommends that you configure the same interface on the same Routing Switch as both a BSR and an RP.

This section presents how to configure BSRs. Refer to “Configuring RPs” on page 11-26 for instructions on how to configure RPs.

To configure the Routing Switch as a candidate BSR and RP, use the following CLI method.

June 2005 11 - 25


USING THE CLI

To configure the Routing Switch as a candidate BSR, enter commands such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# bsr-candidate ethernet 2/2 30 255 BSR address: 207.95.7.1, hash mask length: 30, priority: 255

This command configures the PIM Sparse interface on port 2/2 as a BSR candidate, with a hash mask length of 30 and a priority of 255. The information shown in italics above is displayed by the CLI after you enter the candidate BSR configuration command.

Syntax: [no] bsr-candidate ethernet <portnum> | loopback <num> | ve <num> <hash-mask-length> [<priority>]

The ethernet <portnum> | loopback <num> | ve <num> parameter specifies the interface. The Routing Switch will advertise the specified interface’s IP address as a candidate BSR.

• Enter ethernet <portnum> for a physical interface (port).

• Enter ve <num> for a virtual interface.

• Enter loopback <num> for a loopback interface.

The <hash-mask-length> parameter specifies the number of bits in a group address that are significant when calculating the group-to-RP mapping. You can specify a value from 1 – 32.

The <priority> specifies the BSR priority. You can specify a value from 0 – 255. When the election process for BSR takes place, the candidate BSR with the highest priority becomes the BSR. The default is 0.

Configuring RPs

Enter a command such as the following to configure the Routing Switch as a candidate RP:

ProCurveRS(config-pim-router)# rp-candidate ethernet 2/2

Syntax: [no] rp-candidate ethernet <portnum> | loopback <num> | ve <num>

The ethernet <portnum> | loopback <num> | ve <num> parameter specifies the interface. The Routing Switch will advertise the specified interface’s IP address as a candidate RP.




By default, this command configures the Routing Switch as a candidate RP for all group numbers beginning with 224. As a result, the Routing Switch is a candidate RP for all valid PIM Sparse group numbers. You can change this by adding or deleting specific address ranges. The following example narrows the group number range for which the Routing Switch is a candidate RP by explicitly adding a range.

ProCurveRS(config-pim-router)# rp-candidate add 224.126.0.0 16

Syntax: [no] rp-candidate add <group-addr> <mask-bits>

The <group-addr> <mask-bits> specifies the group address and the number of significant bits in the sub-net mask. In this example, the Routing Switch is a candidate RP for all groups that begin with 224.126. When you add a range, you override the default. The Routing Switch then becomes a candidate RP only for the group address range(s) you add.

You also can change the group numbers for which the Routing Switch is a candidate RP by deleting address ranges. For example, to delete all addresses from 224.126.22.0 – 224.126.22.255, enter the following command:

ProCurveRS(config-pim-router)# rp-candidate delete 224.126.22.0 24

Syntax: [no] rp-candidate delete <group-addr> <mask-bits>

The usage of the <group-addr> <mask-bits> parameter is the same as for the rp-candidate add command.

11 - 26 June 2005


If you enter both commands shown in the example above, the net effect is that the Routing Switch becomes a candidate RP for groups 224.126.0.0 – 224.126.21.255 and groups 224.126.23.0 – 224.126.255.255.



Updating PIM-Sparse Forwarding Entries with New RP Configuration If you make changes to your static RP configuration, the entries in the PIM-Sparse multicast forwarding table continue to use the old RP configuration until they are aged out.

In release 07.6.04, the clear pim rp-map command was added to allow you to update the entries in the static multicast forwarding table immediately after making RP configuration changes. This command is meant to be used with rp-address command.

To update the entries in a PIM sparse static multicast forwarding table with new RP configuration, enter the following command at the privileged EXEC level of the CLI:

ProCurveRS(config)# clear pim rp-map

Syntax: clear pim rp-map

Statically Specifying the RP Hewlett-Packard recommends that you use the PIM Sparse protocol’s RP election process so that a backup RP can automatically take over if the active RP router becomes unavailable. However, if you do not want the RP to be selected by the RP election process but instead you want to explicitly identify the RP by its IP address, you can do using the following CLI method.

If you explicitly specify the RP, the Routing Switch uses the specified RP for all group-to-RP mappings and overrides the set of candidate RPs supplied by the BSR.

NOTE: Specify the same IP address as the RP on all PIM Sparse routers within the PIM Sparse domain. Make sure the router is on the backbone or is otherwise well connected to the rest of the network.

USING THE CLI

To specify the IP address of the RP, enter commands such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# rp-address 207.95.7.1

Syntax: [no] rp-address <ip-addr>

The <ip-addr> parameter specifies the IP address of the RP.

The command in the example above identifies the router interface at IP address 207.95.7.1 as the RP for the PIM Sparse domain. The Routing Switch will use the specified RP and ignore group-to-RP mappings received from the BSR.



Changing the Shortest Path Tree (SPT) Threshold

In a typical PIM Sparse domain, there may be two or more paths from a DR (designated router) for a multicast source to a PIM group receiver.

• Path through the RP – This is the path the Routing Switch uses the first time it receives traffic for a PIM group. However, the path through the RP may not be the shortest path from the Routing Switch to the receiver.

June 2005 11 - 27


• Shortest Path – Each PIM Sparse router that is a DR for a multicast source calculates a shortest path tree (SPT) to all the PIM Sparse group receivers within the domain, with the Routing Switch itself as the root of the tree. The first time a ProCurve Routing Switch configured as a PIM router receives a packet for a PIM receiver, the Routing Switch sends the packet to the RP for the group. The Routing Switch also calculates the SPT from itself to the receiver. The next time the Routing Switch receives a PIM Sparse packet for the receiver, the Routing Switch sends the packet toward the receiver using the shortest route, which may not pass through the RP.

By default, the device switches from the RP to the SPT after receiving the first packet for a given PIM Sparse group. The Routing Switch maintains a separate counter for each PIM Sparse source-group pair.

After the Routing Switch receives a packet for a given source-group pair, the Routing Switch starts a PIM data timer for that source-group pair. If the Routing Switch does not receive another packet for the source-group pair before the timer expires, it reverts to using the RP for the next packet received for the source-group pair. In accordance with the PIM Sparse RFC’s recommendation, the timer is 210 seconds and is not configurable. The counter is reset to zero each time the Routing Switch receives a packet for the source-group pair.

You can change the number of packets that the Routing Switch sends using the RP before switching to using the SPT. To do so, use the following CLI method.

USING THE CLI

To change the number of packets the Routing Switch sends using the RP before switching to the SPT, enter commands such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# spt-threshold 1000

Syntax: [no] spt-threshold infinity | <num>

The infinity | <num> parameter specifies the number of packets. If you specify infinity, the Routing Switch sends packets using the RP indefinitely and does not switch over to the SPT. If you enter a specific number of packets, the Routing Switch does not switch over to using the SPT until it has sent the number of packets you specify using the RP.



Changing the PIM Join and Prune Message Interval

By default, the Routing Switch sends PIM Sparse Join/Prune messages every 60 seconds. These messages inform other PIM Sparse routers about clients who want to become receivers (Join) or stop being receivers (Prune) for PIM Sparse groups.

You can change the Join/Prune message interval using the following CLI method.

NOTE: Use the same Join/Prune message interval on all the PIM Sparse routers in the PIM Sparse domain. If the routers do not all use the same timer interval, the performance of PIM Sparse can be adversely affected.

USING THE CLI

To change the Join/Prune interval, enter commands such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# message-interval 30

Syntax: [no] message-interval <num>

The <num> parameter specifies the number of seconds and can from 1 – 65535. The default is 60.



11 - 28 June 2005


Dropping PIM Traffic in Hardware Beginning with software release 07.8.00, unwanted PIM Dense or PIM Sparse multicast traffic can be dropped in hardware on Routing Switches. This feature does not apply to DVMRP traffic. Refer to “Dropping PIM Traffic in Hardware” on page 11-21.

Displaying PIM Sparse Configuration Information and Statistics You can display the following PIM Sparse information:

• Basic PIM Sparse configuration information

• Group information

• BSR information

• Candidate RP information

• RP-to-group mappings

• RP information for a PIM Sparse group

• RP set list

• PIM Neighbor information

• The PIM flow cache

• The PIM multicast cache

• PIM traffic statistics

Displaying Basic PIM Sparse Configuration Information

To display basic configuration information for PIM Sparse, use the following CLI method.

USING THE CLI

To display PIM Sparse configuration information, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim sparse

Global PIM Sparse Mode Settings Hello interval: 60, Neighbor timeout: 180 Bootstrap Msg interval: 130, Candidate-RP Advertisement interval: 60 Join/Prune interval: 60, SPT Threshold: 1

Interface Ethernet e3/8TTL Threshold: 1, EnabledLocal Address: 207.95.8.1

Interface Ve 1TTL Threshold: 1, EnabledLocal Address: 207.95.6.1

Syntax: show ip pim sparse

This example shows the PIM Sparse configuration information on PIM Sparse router A in Figure 11.3.

This display shows the following information.

June 2005 11 - 29


This Field... Displays...

Global PIM Sparse mode settings

Hello interval How frequently the Routing Switch sends PIM Sparse hello messages to its PIM Sparse neighbors. This field show the number of seconds between hello messages. PIM Sparse routers use hello messages to discover one another.

Neighbor timeout

Bootstrap Msg interval

Candidate-RP Advertisement interval

Join/Prune interval

SPT Threshold

How many seconds the Routing Switch will wait for a hello message from a neighbor before determining that the neighbor is no longer present and removing cached PIM Sparse forwarding entries for the neighbor.

How frequently the BSR configured on the Routing Switch sends the RP set to the RPs within the PIM Sparse domain. The RP set is a list of candidate RPs and their group prefixes. A candidate RP’s group prefix indicates the range of PIM Sparse group numbers for which it can be an RP.

Note: This field contains a value only if an interface on the Routing Switch is elected to be the BSR. Otherwise, the field is blank.

How frequently the candidate PR configured on the Routing Switch sends candidate RP advertisement messages to the BSR.

Note: This field contains a value only if an interface on the Routing Switch is configured as a candidate RP. Otherwise, the field is blank.

How frequently the Routing Switch sends PIM Sparse Join/Prune messages for the multicast groups it is forwarding. This field show the number of seconds between Join/Prune messages.

The Routing Switch sends Join/Prune messages on behalf of multicast receivers who want to join or leave a PIM Sparse group. When forwarding packets from PIM Sparse sources, the Routing Switch sends the packets only on the interfaces on which it has received join requests in Join/Prune messages for the source’s group.

You can change the Join/Prune interval if needed. See “Changing the PIM Join and Prune Message Interval” on page 11-28.

The number of packets the Routing Switch sends using the path through the RP before switching to using the SPT path.

PIM Sparse interface information

Note: You also can display IP multicast interface information using the show ip pim interface command. However, this command lists all IP multicast interfaces, including regular PIM (dense mode) and DVMRP interfaces. The show ip pim sparse command lists only the PIM Sparse interfaces.

Interface The type of interface and the interface number. The interface type can be one of the following:

• Ethernet

• VE

The number is either a port number (and slot number if applicable) or the virtual interface (VE) number.

11 - 30 June 2005


This Field...

TTL Threshold

Local Address

Displays...

Following the TTL threshold value, the interface state is listed. The interface state can be one of the following:

• Disabled

• Enabled

Indicates the IP address configured on the port or virtual interface.


You cannot display PIM Sparse information using the Web management interface.

Displaying a List of Multicast Groups

To display a list of the IP multicast groups the Routing Switch is forwarding, use the following CLI method.

USING THE CLI

To display PIM Sparse configuration information, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim group

Total number of Groups: 2 Index 1 Group 239.255.162.1 Ports e3/11

Syntax: show ip pim group


This Field...

Total number of Groups

Index

Group

Ports

Displays...

Lists the total number of IP multicast groups the Routing Switch is forwarding.

Note: This list can include groups that are not PIM Sparse groups. If interfaces on the Routing Switch are configured for regular PIM (dense mode) or DVMRP, these groups are listed too.

The index number of the table entry in the display.

The multicast group address

The Routing Switch ports connected to the receivers of the groups.



Displaying BSR Information

To display information about the BSR, use the following CLI method.

June 2005 11 - 31


USING THE CLI

To display BSR information, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim bsr

PIMv2 Bootstrap information

This system is the elected Bootstrap Router (BSR) BSR address: 207.95.7.1 Uptime: 00:33:52, BSR priority: 5, Hash mask length: 32 Next bootstrap message in 00:00:20

Next Candidate-RP-advertisement in 00:00:10 RP: 207.95.7.1 group prefixes: 224.0.0.0 / 4Candidate-RP-advertisement period: 60

This example show information displayed on a Routing Switch that has been elected as the BSR. The following example shows information displayed on a Routing Switch that is not the BSR. Notice that some fields shown in the example above do not appear in the example below.

ProCurveRS(config-pim-router)# show ip pim bsr

PIMv2 Bootstrap information local BSR address = 207.95.7.1 local BSR priority = 5

Syntax: show ip pim bsr


This Field...

BSR address

or

local BSR address

Uptime

BSR priority

or

local BSR priority

Displays...

The IP address of the interface configured as the PIM Sparse Bootstrap Router (BSR).

Note: If the word “local” does not appear in the field, this Routing Switch is the BSR. If the word “local” does appear, this Routing Switch is not the BSR.

The amount of time the BSR has been running.

Note: This field appears only if this Routing Switch is the BSR.

The priority assigned to the interface for use during the BSR election process. During BSR election, the priorities of the candidate BSRs are compared and the interface with the highest BSR priority becomes the BSR.

Note: If the word “local” does not appear in the field, this Routing Switch is the BSR. If the word “local” does appear, this Routing Switch is not the BSR.

11 - 32 June 2005


This Field...

Hash mask length

Next bootstrap message in

Next Candidate-PR-advertisement message in

RP

group prefixes

Candidate-RP-advertisement period

Displays...

The number of significant bits in the IP multicast group comparison mask. This mask determines the IP multicast group numbers for which the Routing Switch can be a BSR. The default is 32 bits, which allows the Routing Switch to be a BSR for any valid IP multicast group number.


Indicates how many seconds will pass before the BSR sends its next Bootstrap message.


Indicates how many seconds will pass before the BSR sends its next candidate PR advertisement message.


Indicates the IP address of the Rendezvous Point (RP).


Indicates the multicast groups for which the RP listed by the previous field is a candidate RP.


Indicates how frequently the BSR sends candidate RP advertisement messages.




Displaying Candidate RP Information

To display candidate RP information, use the following CLI method.

USING THE CLI

To display candidate RP information, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim rp-candidate

Next Candidate-RP-advertisement in 00:00:10 RP: 207.95.7.1 group prefixes: 224.0.0.0 / 4

Candidate-RP-advertisement period: 60

This example show information displayed on a Routing Switch that is a candidate RP. The following example shows the message displayed on a Routing Switch that is not a candidate RP.

ProCurveRS(config-pim-router)# show ip pim rp-candidate

This system is not a Candidate-RP.

Syntax: show ip pim rp-candidate

June 2005 11 - 33


-------------------------------


This Field...

Candidate-RP-advertisement in

RP

group prefixes

Candidate-RP-advertisement period

Displays...

Indicates how many seconds will pass before the BSR sends its next RP message.

Note: This field appears only if this Routing Switch is a candidate RP.

Indicates the IP address of the Rendezvous Point (RP).




Indicates how frequently the BSR sends candidate RP advertisement messages.




Displaying RP-to-Group Mappings

To display RP-to-group mappings, use the following CLI method.

USING THE CLI

To display RP-to-group-mappings, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim rp-map Number of group-to-RP mappings: 6

Group address RP address

1 239.255.163.1 99.99.99.5 2 239.255.163.2 99.99.99.5 3 239.255.163.3 99.99.99.5 4 239.255.162.1 99.99.99.5 5 239.255.162.2 43.43.43.1 6 239.255.162.3 99.99.99.5

Syntax: show ip pim rp-map



Group address Indicates the PIM Sparse multicast group address using the listed RP.

RP address Indicates the IP address of the Rendezvous Point (RP) for the listed PIM Sparse group.



11 - 34 June 2005


---------------------------------------------------

Displaying RP Information for a PIM Sparse Group

To display RP information for a specific PIM Sparse group, use the following CLI method.

USING THE CLI

To display RP information for a PIM Sparse group, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim rp-hash 239.255.162.1

RP: 207.95.7.1, v2 Info source: 207.95.7.1, via bootstrap

Syntax: show ip pim rp-hash <group-addr>

The <group-addr> parameter is the address of a PIM Sparse IP multicast group.


This Field...

RP

Info source

Displays...

Indicates the IP address of the Rendezvous Point (RP) for the specified PIM Sparse group.

Following the IP address is the port or virtual interface through which this Routing Switch learned the identity of the RP.

Indicates the IP address on which the RP information was received.

Following the IP address is the method through which this Routing Switch learned the identity of the RP.



Displaying the RP Set List

To display the RP set list, use the following CLI method.

USING THE CLI

To display the RP set list, enter the following command at any CLI level:

ProCurveRS(config)#show ip pim rp-set Group address Static-RP-address Override

Access-List 44 99.99.99.5 On Number of group prefixes Learnt from BSR: 1 Group prefix = 239.255.162.0/24 # RPs expected: 1 # RPs received: 1 RP 1: 43.43.43.1 priority=0 age=0

Syntax: show ip pim rp-set

June 2005 11 - 35



This Field...

Number of group prefixes

Group prefix

RPs expected/received

RP <num>

priority

age

Displays...

The number f PIM Sparse group prefixes for which the RP is responsible.


Indicates how many RPs were expected and received in the latest Bootstrap message.

Indicates the RP number. If there are multiple RPs in the PIM Sparse domain, a line of information for each of them is listed, and they are numbered in ascending numerical order.

The RP priority of the candidate RP. During the election process, the candidate RP with the highest priority is elected as the RP.

The age (in seconds) of this RP-set.

Note: If this Routing Switch is not a BSR, this field contains zero. Only the BSR ages the RP-set.



Displaying Multicast Neighbor Information

To display information about the Routing Switch’s IP Multicast neighbors, use either of the following methods.

USING THE CLI

To display information about the Routing Switch’s PIM neighbors, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim nbr

Port Neighbor Holdtime Age UpTime sec sec sec

e3/8 207.95.8.10 Port Neighbor

180 60 Holdtime Age

900 UpTime

sec sec sec v1 207.95.6.2 180 60 900

Syntax: show ip pim nbr



Port The interface through which the Routing Switch is connected to the neighbor.

Neighbor The IP interface of the PIM neighbor interface.

11 - 36 June 2005


This Field...

Holdtime sec

Age sec

UpTime sec

Displays...

Indicates how many seconds the neighbor wants this Routing Switch to hold the entry for this neighbor in memory. The neighbor sends the Hold Time in its Hello packets.

• If the Routing Switch receives a new Hello packet before the Hold Time received in the previous packet expires, the Routing Switch updates its table entry for the neighbor.

• If the Routing Switch does not receive a new Hello packet from the neighbor before the Hold time expires, the Routing Switch assumes the neighbor is no longer available and removes the entry for the neighbor.

The number of seconds since the Routing Switch received the last hello message from the neighbor.

The number of seconds the PIM neighbor has been up. This timer starts when the Routing Switch receives the first Hello messages from the neighbor.


1. Log on to the device using a valid user name and password for read-only or read-write access. The System configuration panel is displayed.

2. Click on the plus sign next to Monitor in the tree view.


4. Click on the Neighbor link to display the IP interface table.

Displaying Information About an Upstream Neighbor Device

Beginning in software release 07.7.00, you can view information about the upstream neighbor device for a given source IP address for IP Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP) packets. For PIM, the software uses the IP route table or multicast route table to lookup the upstream neighbor device. For DVMRP, the software uses the DVMRP route table to locate the upstream neighbor device.

Enter the following command at the Privileged EXEC level of the CLI:

ProCurveRS# show ip pim rpf 1.1.20.2

directly connected or via an L2 neighbor

NOTE: If there are multiple equal cost paths to the source, the show ip pim rpf command output may not be accurate. If your system has multiple equal cost paths, use the command sh ip pim mcache to view information about the upstream neighbor. For more information about this command, see the Command Line Interface Reference for ProCurve 9300/9400 Series Routing Switches.

The following example outputs show other messages that the Routing Switch display with this command.


no route


upstream neighbor=1.1.20.1 on v21 using ip route

Syntax: show ip pim | dvmrp rpf <IP address>

where <IP address> is a valid source IP address

June 2005 11 - 37


Displaying the PIM Flow Cache

To display the PIM flow cache, use the following CLI method.

USING THE CLI

To display the PIM flow cache, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim flowcache

1 Source

209.157.24.162 Group

239.255.162.1 Parent CamFlags CamIndex

v2 00000700 2023 Fid Flags00004411 F

2 209.157.24.162 239.255.162.1 v2 00000700 201b 00004411 F 3 209.157.24.162 239.255.162.1 v2 00000700 201d 00004411 F 4 209.157.24.162 239.255.162.1 v2 00000700 201e 00004411 F

Syntax: show ip pim flowcache



Source Indicates the source of the PIM Sparse group.

Group Indicates the PIM Sparse group.

Parent Indicates the port or virtual interface from which the Routing Switch receives packets from the group’s source.

CamFlags This field is used by HP technical support for troubleshooting.

CamIndex This field is used by HP technical support for troubleshooting.

Fid This field is used by HP technical support for troubleshooting.

Flags This field is used by HP technical support for troubleshooting.


You cannot display the PIM flow cache using the Web management interface.

Displaying the PIM Multicast Cache

To display the PIM multicast cache, use the following CLI method.

11 - 38 June 2005


USING THE CLI

To display the PIM multicast cache, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim mcache

1 (*,239.255.162.1) RP207.95.7.1 forward port v1, Count 2 member ports ethe 3/3 virtual ports v2 prune ports virtual prune ports

2 (209.157.24.162,239.255.162.4) forward port v2, flags 00004900 Count 130 member ports virtual ports prune ports virtual prune ports

3 (209.157.24.162,239.255.162.1) forward port v2, flags 00005a01 Count 12 member ports ethe 3/8 virtual ports prune ports virtual prune ports

Syntax: show ip pim mcache


This Field...

(<source>, <group>)

RP<ip-addr>

forward port

Count

Sparse Mode

Displays...

The comma-separated values in parentheses is a source-group pair.

The <source> is the PIM source for the multicast <group>. For example, the following entry means source 209.157.24.162 for group 239.255.162.1: (209.157.24.162,239.255.162.1)

If the <source> value is * (asterisk), this cache entry uses the RP path. The * value means “all sources”.

If the <source> is a specific source address, this cache entry uses the SPT path.

Indicates the RP for the group for this cache entry.

Note: The RP address appears only if the RPT flag is set to 1 and the SPT flag is set to 0 (see below).

The port through which the Routing Switch reaches the source.

The number of packets forwarded using this cache entry.

Indicates whether the cache entry is for regular PIM (dense mode) or PIM Sparse. This flag can have one of the following values:

• 0 – The entry is not for PIM Sparse (and is therefore for the dense mode of PIM).

• 1– The entry is for PIM Sparse.

June 2005 11 - 39


This Field...

RPT

SPT

Register Suppress

member ports

virtual ports

prune ports

virtual prune ports

Displays...

Indicates whether the cache entry uses the RP path or the SPT path. The RPT flag can have one of the following values:

• 0 – The SPT path is used instead of the RP path.

• 1– The RP path is used instead of the SPT path.

Note: The values of the RP and SPT flags are always opposite (one is set to 0 and the other is set to 1).

Indicates whether the cache entry uses the RP path or the SPT path. The SP flag can have one of the following values:

• 0 – The RP path is used instead of the SPT path.

• 1– The SPT path is used instead of the RP path.

Note: The values of the RP and SPT flags are always opposite (one is set to 0 and the other is set to 1).

Indicates whether the Register Suppress timer is running. This field can have one of the following values:

• 0 – The timer is not running.

• 1 – The timer is running.

Indicates the Routing Switch physical ports to which the receivers for the source and group are attached. The receivers can be directly attached or indirectly attached through other PIM Sparse routers.

Indicates the virtual interfaces to which the receivers for the source and group are attached. The receivers can be directly attached or indirectly attached through other PIM Sparse routers.

Indicates the physical ports on which the Routing Switch has received a prune notification (in a Join/Prune message) to remove the receiver from the list of recipients for the group.

Indicates the virtual interfaces ports on which the Routing Switch has received a prune notification (in a Join/Prune message) to remove the receiver from the list of recipients for the group.


You cannot display the PIM multicast cache using the Web management interface.

Displaying PIM Traffic Statistics

To display PIM traffic statistics, use the following CLI method.

11 - 40 June 2005


USING THE CLI

To display PIM traffic statistics, enter the following command at any CLI level:

ProCurveRS(config-pim-router)# show ip pim traffic

Port Hello [Rx Tx] e3/8 19 19

J/P[Rx Tx] 32 0

Register [Rx Tx]

0 0

RegStop [Rx Tx]

37 0

Assert [Rx Tx]

0 0

Port Hello [Rx Tx] v1 18 19

J/P[Rx Tx] 0 20

Register [Rx Tx]

0 0

RegStop [Rx Tx]

0 0

Assert [Rx Tx]

0 0

Port Hello [Rx Tx] v2 0 19

J/P[Rx Tx] 0 0

Register [Rx Tx]

0 16

RegStop [Rx Tx]

0 0

Assert [Rx Tx]

0 0

Total 37 57 32 0 0 0 0 0 0 0 IGMP Statistics: Total Recv/Xmit 85/110 Total Discard/chksum 0/0

Syntax: show ip pim traffic

NOTE: If you have configured interfaces for standard PIM (dense mode) on the Routing Switch, statistics for these interfaces are listed first by the display.


This Field...

Port

Hello

J/P

Register The number of Register messages sent or received on the interface.

RegStop The number of Register Stop messages sent or received on the interface.

Assert

Total Recv/Xmit

Total Discard/chksum

Displays...

The port or virtual interface on which the PIM interface is configured.

The number of PIM Hello messages sent or received on the interface.

The number of Join/Prune messages sent or received on the interface.

Note: Unlike PIM dense, PIM Sparse uses the same messages for Joins and Prunes.

The number of Assert messages sent or received on the interface.

The total number of IGMP messages sent and received by the Routing Switch.

The total number of IGMP messages discarded, including a separate counter for those that failed the checksum comparison.


You cannot display PIM statistics using the Web management interface.

June 2005 11 - 41


Displaying and Clearing PIM Errors

USING THE CLI

If you want to determine how many PIM errors there are on the device, enter the following command:

ProCurveRS# show ip pim error**** Warning counter pim route change = 1HW tagged replication enabled, SW processed pkts 0

Syntax: show ip pim error

This command displays the number of warnings and non-zero PIM errors on the device. This count can increase during transition periods such as reboots and topology changes; however, if the device is stable, the number of errors should not increase. If warnings keep increasing in a stable topology, then there may be a configuration error or problems on the device.

To clear the counter for PIM errors, enter the following command:

ProCurveRS# clear pim counters

Syntax: clear pim counters



Configuring Multicast Source Discovery Protocol (MSDP) The Multicast Source Discovery Protocol (MSDP) is used by Protocol Independent Multicast (PIM) Sparse routers to exchange routing information for PIM Sparse multicast groups across PIM Sparse domains. Routers running MSDP can discover PIM Sparse sources that are in other PIM Sparse domains.

PIM Sparse routers use MSDP to register PIM Sparse multicast sources in a domain with the Rendezvous Point (RP) for that domain.

Figure 11.4 shows an example of some PIM Sparse domains. For simplicity, this example show only one Designated Router (DR), one group source, and one receiver for the group. Only one PIM Sparse router within each domain needs to run MSDP.

11 - 42 June 2005


Figure 11.4 PIM Sparse domains joined by MSDP routers

PIM Sparse Domain 3

Group 232.1.0.95

PIM Sparse Domain 4

PIM Sparse Domain 2

Group 232.1.0.95

PIM Sparse Domain 1

Designated Router (DR)

206.251.14.22

and registers source with RP.

through MSDP to its MSDP peers in other PIM Sparse

the RP immediately responds to

floods the SA to all its MSDP

the SA.

206.251.17.41

Rendezvous Point (RP)


Receiver for


Source for

Source Advertisement message

1. DR receives traffic from source

2. RP sends SA message

domains.

4. When SA caching is enabled,

Join messages from receivers.

Otherwise, the RP and receiver must wait for the next SA message for the group.

3. RP that receives the SA

peers, except the one that sent


In this example, the source for PIM Sparse multicast group 232.0.1.95 is in PIM Sparse domain 1. The source sends a packet for the group to its directly attached DR. The DR sends a Group Advertisement message for the group to the domain’s RP. The RP is configured for MSDP, which enables the RP to exchange source information with other PIM Sparse domains by communicating with RPs in other domains that are running MSDP.

The RP sends the source information to each of its peers by sending a Source Active message. The message contains the IP address of the source, the group address to which the source is sending, and the IP address of the RP interface with its peer. By default, the IP address included in the RP address field of the SA message is the IP address of the originating RP. Beginning with software release 07.7.00, an SA message can use the IP address of any interface on the originating RP. (The interface is usually a loopback interface.)

In this example, the Source Active message contains the following information:

• Source address: 206.251.14.22

• Group address: 232.1.0.95

• RP address: 206.251.17.41

Figure 11.4 shows only one peer for the MSDP router (which is also the RP here) in domain 1, so the Source Active message goes to only that peer. When an MSDP router has multiple peers, it sends a Source Active message to each of those peers. Each peer sends the Source Advertisement to its other MSDP peers. The RP that receives the Source Active message also sends a Join message for the group if the RP that received the message has receivers for the group.

June 2005 11 - 43


Peer Reverse Path Forwarding (RPF) Flooding When the MSDP router (also the RP) in domain 2 receives the Source Active message from its peer in domain 1, the MSDP router in domain 2 forwards the message to all its other peers. The propagation process is sometimes called “peer Reverse Path Forwarding (RPF) flooding”. This term refers to the fact that the MSDP router uses its PIM Sparse RPF tree to send the message to its peers within the tree. In Figure 11.4, the MSDP router floods the Source Active message it receives from its peer in domain 1 to its other peers, in domains 3 and 4.

Note that the MSDP router in domain 2 does not forward the Source Active back to its peer in domain 1, because that is the peer from which the router received the message. An MSDP router never sends a Source Active message back to the peer that sent it. The peer that sent the message is sometimes called the “RPF peer”. The MSDP router uses the unicast routing table for its Exterior Gateway Protocol (EGP) to identify the RPF peer by looking for the route entry that is the next hop toward the source. Often, the EGP protocol is Border Gateway Protocol (BGP) version 4.

NOTE: MSDP depends on BGP and MBGP for interdomain operations.

The MSDP routers in domains 3 and 4 also forward the Source Active message to all their peers except the ones that sent them the message. Figure 11.4 does not show additional peers.

Source Active Caching When an MSDP router that is also an RP receives a Source Active message, the RP checks its PIM Sparse multicast group table for receivers for the group. If the DR has a receiver for the group being advertised in the Source Active message, the DR sends a Join message for that receiver back to the DR in the domain from which the Source Active message came. Usually, the DR is also the MSDP router that sent the Source Active message.

In Figure 11.4, if the MSDP router and RP in domain 4 has a table entry for the receiver, the RP sends a Join message on behalf of the receiver back through the RPF tree to the RP for the source, in this case the RP in domain 1.

Some MSDP routers that are also RPs can cache Source Active messages. If the RP is not caching Source Active messages, the RP does not send a Join message unless it already has a receiver that wants to join the group. Otherwise, the RP does not send a Join message and does not remember the information in the Source Active message after forwarding it. If the RP receives a request from a receiver for the group, the RP and receiver must wait for the next Source Active message for that group before the RP can send a Join message for the receiver.

However, if Source Active caching is enabled on the MSDP and RP router, the RP caches the Source Active messages it receives. In this case, even if the RP does not have a receiver for a group when the RP receives the Source Active message for the group, the RP can immediately send a Join for a new receiver that wants to join the group, without waiting for the next Source Active message from the RP in the source’s domain.

Configuring MSDP To configure MSDP on a Routing Switch, perform the following tasks:

• Enable MSDP.

• Configure the MSDP peers.

NOTE: The PIM Sparse Rendezvous Point (RP) is also an MSDP peer.

NOTE: Routers that run MSDP must also run BGP. Also, the source address used by the MSDP router must be the same source address used by BGP.

Enabling MSDP

Use the following CLI method to enable MSDP.

11 - 44 June 2005


NOTE: You must save the configuration and reload the software to place the change into effect.

USING THE CLI

To enable MSDP, enter the following commands.

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# write memory ProCurveRS(config-msdp-router)# end ProCurveRS# reload

Syntax: [no] router msdp


You cannot configure MSDP using the Web management interface.

Configuring MSDP Peers

Use the following CLI method to configure an MSDP peer.

USING THE CLI

To configure an MSDP peer, enter a command such as the following at the MSDP configuration level.

ProCurveRS(config-msdp-router)# msdp-peer 205.216.162.1

Syntax: [no] msdp-peer <ip-addr> [connect-source loopback <num>]

The <ip-addr> parameter specifies the IP address of the neighbor.

The connect-source loopback <num> parameter specifies the loopback interface you want to use as the source for sessions with the neighbor.

NOTE: It is strongly recommended that you use the connect-source loopback <num> parameter when issuing the msdp-peer command. If you do not use this parameter, the Routing Switch uses the sub-net interface configured on the port.

Also, make sure the IP address of the connect-source loopback is the same as the source IP address used by the MSDP router, the PIM-RP, and the BGP router.

The commands in the following example add an MSDP neighbor and specify a loopback interface as the source interface for sessions with the neighbor. By default, the Routing Switch uses the sub-net address configured on the physical interface where you configure the neighbor as the source address for sessions with the neighbor.

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 9.9.9.9/32 ProCurveRS(config-lbif-1)# interface ethernet 3/1 ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.99 connect-source loopback 1


You cannot configure MSDP using the Web management interface.

Designating an Interface’s IP Address as the RP’s IP Address When an RP receives a Source Active message, it checks its PIM Sparse multicast group table for receivers for the group. If it finds a receiver, the RP sends a Join message for that receiver back to the RP that originated the Source Active message. The originator RP is identified by its RP address.

By default, the IP address included in the RP address field of the SA message is the IP address of the originating RP. Beginning with this release, an SA message can use the IP address of any interface on the originating RP. (The interface is usually a loopback interface.)

June 2005 11 - 45


To designate an interface’s IP address to be the IP address of the RP, enter commands such as the following:

ProCurveRS(config)# interface loopback 2 ProCurveRS(config-lbif-2)# ip address 2.2.1.99/32

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# originator-id loopback 2 ProCurveRS(config-msdp-router)# exit

Syntax: [no] originator-id <type> <number>

The originator-id parameter instructs MSDP to use the specified address as the IP address of the RP in an SA message. This address must be the address of the interface used to connect the RP to the source. There are no default originator-ids.

The <type> parameter indicates the type of interface used by the RP. Ethernet, loopback and virtual routing interfaces (ve) can be used.

The <number> parameter specifies the interface number (for example: loopback number, port number or virtual routing interface number.)

Filtering MSDP Source-Group Pairs Software release 07.6.04 and later allows you to filter individual source-group pairs in MSDP Source-Active messages.

• sa-filter in – Filters source-group pairs received in Source-Active messages from an MSDP neighbor

• sa-filter originate – Filters source-group pairs in Source-Active messages in advertisements to an MSDP neighbor

Filtering Incoming Source-Active Messages

The following example configures filters for incoming Source-Active messages from three MSDP neighbors:

• For peer 2.2.2.99, all source-group pairs in Source-Active messages from the neighbor are filtered out (dropped).

• For peer 2.2.2.97, all source-group pairs except those with 10.x.x.x as the source are permitted.

• For peer 2.2.2.96, all source-group pairs except those associated with RP 2.2.42.3 are permitted.

Example The following commands configure an IP address on port 3/1. This is the port on which the MSDP neighbors will be configured.

ProCurveRS(config)# interface ethernet 3/1 ProCurveRS(config-if-3/1)# ip address 2.2.2.98/24 ProCurveRS(config-if-3/1)# exit

The following commands configure a loopback interface. The Routing Switch will use this interface as the source address for communicating with the MSDP neighbors.

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 9.9.9.8/32 ProCurveRS(config-lbif-1)# exit

The following commands configure extended ACLs. The ACLs will be used in route maps, which will be used by the Source-Active filters.

ProCurveRS(config)# access-list 123 permit 10.0.0.0 0.255.255.255 any ProCurveRS(config)# access-list 124 permit 2.2.42.3 0.0.0.0 any ProCurveRS(config)# access-list 125 permit any any

11 - 46 June 2005


The following commands configure the route maps.

ProCurveRS(config)# route-map msdp_map deny 1ProCurveRS(config-routemap msdp_map)# match ip address 123ProCurveRS(config-routemap msdp_map)# exitProCurveRS(config)# route-map msdp2_map permit 1ProCurveRS(config-routemap msdp2_map)# match ip address 125ProCurveRS(config-routemap msdp2_map)# exitProCurveRS(config)# route-map msdp2_rp_map deny 1ProCurveRS(config-routemap msdp2_rp_map)# match ip route-source 124ProCurveRS(config-routemap msdp2_rp_map)# exit

The following commands enable MSDP and configure the MSDP neighbors on port 3/1.

ProCurveRS(config)# router msdpProCurveRS(config-msdp-router)# exitProCurveRS(config)# interface ethernet 3/1ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.99 connect-source loopback 1ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.97 connect-source loopback 1ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.96 connect-source loopback 1ProCurveRS(config-if-3/1)# exit

The following commands configure the Source-Active filters.

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# sa-filter in 2.2.2.99 ProCurveRS(config-msdp-router)# sa-filter in 2.2.2.97 route-map msdp_map ProCurveRS(config-msdp-router)# sa-filter in 2.2.2.96 route-map msdp2_map rp-route-map msdp2_rp_map

The sa-filter commands configure the following filters:

• sa-filter in 2.2.2.99 – This command drops all source-group pairs received from neighbor 2.2.2.99.

NOTE: The default action is to deny all source-group pairs from the specified neighbor. If you want to permit some pairs, use route maps.

• sa-filter in 2.2.2.97 route-map msdp_map – This command drops source-group pairs received from neighbor 2.2.2.97 if the pairs have source address 10.x.x.x and any group address.

• sa-filter in 2.2.2.96 route-map msdp2_map rp-route-map msdp2_rp_map – This command accepts all source-group pairs except those associated with RP 2.2.42.3.

CLI Syntax Syntax: [no] sa-filter in <ip-addr> [route-map <map-tag>] [rp-route-map <rp-map-tag>]

The <ip-addr> parameter specifies the IP address of the MSDP neighbor. The filter applies to Active-Source messages received from this neighbor.

The route-map <map-tag> parameter specifies a route map. The Routing Switch applies the filter to sourcegroup pairs that match the route map. Use the match ip address <acl-id> command in the route map to specify an extended ACL that contains the source and group addresses.

The rp-route-map <rp-map-tag> parameter specifies a route map to use for filtering based on Rendezvous Point (RP) address. Use this parameter if you want to filter Source-Active messages based on their origin. If you use the route-map parameter instead, messages are filtered based on source-group pairs but not based on origin. Use the match ip route-source <acl-id> command in the route map to specify the RP address.

June 2005 11 - 47


NOTE: The default filter action is deny. If you want to permit some source-group pairs, use a route map. A permit action in the route map allows the Routing Switch to receive the matching source-group pairs. A deny action in the route map drops the matching source-group pairs.

Filtering Advertised Source-Active Messages

The following example configures the Routing Switch to advertise all source-group pairs except the ones that have source address 10.x.x.x.

Example The following commands configure an IP address on port 3/1. This is the port on which the MSDP neighbors will be configured.

ProCurveRS(config)# interface ethernet 3/1 ProCurveRS(config-if-3/1)# ip address 2.2.2.98/24 ProCurveRS(config-if-3/1)# exit

The following commands configure a loopback interface. The Routing Switch will use this interface as the source address for communicating with the MSDP neighbors.

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 9.9.9.8/32 ProCurveRS(config-lbif-1)# exit

The following command configures an extended ACL to specify the source and group addresses you want to filter.

ProCurveRS(config)# access-list 123 permit 10.0.0.0 0.255.255.255 any

The following commands configure a route map. The map matches on source address 10.x.x.x and any group address. Since the action is deny, the Source-Active filter that uses this route map will remove the source-group pairs that match this route map from the Source-Active messages to the neighbor.

ProCurveRS(config)# route-map msdp_map deny 1 ProCurveRS(config-routemap msdp_map)# match ip address 123 ProCurveRS(config-routemap msdp_map)# exit

The following commands enable MSDP and configure MSDP neighbors on port 3/1.

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# exit ProCurveRS(config)# interface ethernet 3/1 ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.99 connect-source loopback 1 ProCurveRS(config-if-3/1)# msdp-peer 2.2.2.97 connect-source loopback 1 ProCurveRS(config-if-3/1)# exit

The following commands configure the Source-Active filter.

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# sa-filter originate route-map msdp_map

This filter removes source-group pairs that match route map msdp_map from Source-Active messages before sending them to MSDP neighbors.

CLI Syntax Syntax: [no] sa-filter originate [route-map <map-tag>]

The route-map <map-tag> parameter specifies a route map. The Routing Switch applies the filter to sourcegroup pairs that match the route map. Use the match ip address <acl-id> command in the route map to specify an extended ACL that contains the source and group addresses.

NOTE: The default filter action is deny. If you want to permit some source-group pairs, use a route map. A permit action in the route map allows the Routing Switch to receive the matching source-group pairs. A deny action in the route map drops the matching source-group pairs.

11 - 48 June 2005


Configuring MSDP Mesh Groups A PIM Sparse domain can have several RPs that are connected to each other to form an MSDP mesh group. To qualify as a mesh group, the RPs have to be fully meshed; that is, each RP must be connected to all peer RPs in a domain. (See Figure 11.5.)

A mesh group reduces the forwarding of SA messages within a domain. Instead of having every RP in a domain forward SA messages to all the RPs within that domain, only one RP forwards the SA message. Since an MSDP mesh group is fully meshed, peers do not forward SA messages received in a domain from one member to every member of the group. The RP that originated the SA or the first RP in a domain that receives the SA message is the only one that can forward the message to the members of a mesh group. An RP can forward an SA message to any MSRP router as long as that peer is farther away from the originating RP than the current MSRP router.

Figure 11.5 shows an example of an MSDP mesh group. In a PIM-SM mesh group the RPs are configured to be peers of each other. They can also be peers of RPs in other domains.

Figure 11.5 Example of MSDP mesh group

PIM Sparse Domain 1 Mesh GroupA

RP 206.251.18.31

RP 206.251.19.31

RP 206.251.21.31

RP PIM Sparse Domain 4

232.1.0.95

Designated Router (DR)

206.251.14.22

PIM Sparse Domain 2

from source and registers source with RP

to its peers within the domain

the SA message and floods the SA message to its peers in other PIM Sparse domains

RP PIM Sparse Domain 3

RP 206.251.20.31

RP

Source for Group

1. DR receives traffic

2. RP sends an SA message

3. RPs within the domain receive

PIM Sparse Domain 1 in Figure 11.5 contains a mesh group with four RPs. When the first RP, for example, RP 206.251.21.41 (which is also the originating RP), receives an SA message from the source, it sends the SA message to its peers within the domain, but the peers do not send the message back to the originator RP or to each other. The RPs then send the SA message to their peers in other domains.The process continues until all RPs within the network receive the SA message. RPs send join and prune messages to appropriate points on the multicast tree towards the originating RP.

June 2005 11 - 49


Configuring MSDP Mesh Group

To configure an MSDP mesh group, enter commands such as the following on each device that will be included in the mesh group:

ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# msdp-peer 163.5.34.10 connect-source loopback 2 ProCurveRS(config-msdp-router)# msdp-peer 206.251.21.31 connect-source loopback 2 ProCurveRS(config-msdp-router)# msdp-peer 206.251.17.31 connect-source loopback 2 ProCurveRS(config-msdp-router)# msdp-peer 206.251.13.31 connect-source loopback 2 ProCurveRS(config-msdp-router)# mesh-group GroupA 206.251.21.31 ProCurveRS(config-msdp-router)# mesh-group GroupA 206.251.17.31 ProCurveRS(config-msdp-router)# mesh-group GroupA 206.251.13.31 ProCurveRS(config-msdp-router)# exit

Syntax: [no] mesh-group <group-name> <peer-address>

The sample configuration above reflects the configuration in Figure 11.5. On RP 206.251.21.31 you specify its peers within the same domain (206.251.21.31, 206.251.17.31, and 206.251.13.31).

You first configure the MSDP peers using the msdp-peer command to assign their IP addresses and the loopback interfaces. This information will be used as the source for sessions with the neighbor.

Next, place the MSDP peers within a domain into a mesh group. Use the mesh-group command. There are no default mesh groups.

The group-name parameter identifies the group. Enter up to 31 characters for group-name. You can have up to 4 mesh groups within a multicast network. Each mesh group can include up to 32 peers.

The peer-address parameter specifies the IP address of the MSDP peer that is being placed in the group.

NOTE: On each of the device that will be part of the mesh-group, there must be a mesh-group definition for all the peers in the mesh-group.

Up to 32 MSDP peers can be configured per mesh group.

Example Configuration In Figure 11.6, devices A, B, C, and D are in Mesh Group 1234. The example configuration following the figure shows how the devices are configured to be part of the MSDP mesh group. The example also shows the features that need to be enabled for the MSDP mesh group to work.

11 - 50 June 2005


Figure 11.6 MSDP Mesh Group 1234

1.1.4.1

1.1.2.1

1.1.3.1

PIM Sparse Domain 20 PIM Sparse Domain 40

1.1.1.1

PIM Sparse Domain 10 MSDP Mesh Group 1234

48.48.48.817.17.17.7

PIM Sparse Domain 60

134.134.134.13

PIM Sparse Domain 50

35.35.35.5 Device D

Device B

Device C

Device A

Configuration for Device A

The following set of commands configure the MSDP peers of Device A (1.1.1.1) that are inside and outside MSDP mesh group 1234. Device A’s peers inside the mesh group 1234 are 1.1.2.1, 1.1.3.1, and 1.1.4.1. Device 17.17.17.7 is a peer of Device A, but is outside mesh group 1234. Multicast is enabled on Device A’s interfaces. PIM and BGP are also enabled.


ProCurveRS(config)# ip multicast-perf


ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# msdp-peer 1.1.3.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.4.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.2.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 17.17.17.7 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.4.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.3.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.2.1 ProCurveRS(config-msdp-router)# exit

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)#ip address 1.1.1.1 255.255.255.0 ProCurveRS(config-lbif-1)# ip pim-sparse ProCurveRS(config-lbif-1)# exit

ProCurveRS(config)# interface ethernet 1/1 ProCurveRS(config-if-1/1)# ip address 14.14.14.1 255.255.255.0

June 2005 11 - 51


ProCurveRS(config-if-1/1)# ip pim-sparse ProCurveRS(config-if-1/1)# exit

ProCurveRS(config)# interface ethernet 2/1 ProCurveRS(config-if-2/1)# ip address 12.12.12.1 255.255.255.0 ProCurveRS(config-if-2/1)# ip pim-sparse ProCurveRS(config-if-2/1)# exit



ProCurveRS(config)# interface ethernet 4/8 ProCurveRS(config-if-4/8)# ip address 17.17.17.1 255.255.255.0 ProCurveRS(config-if-4/8)# ip pim-sparse ProCurveRS(config-if-4/8)# ip pim border ProCurveRS(config-if-4/8)# exit

ProCurveRS(config)# router pim ProCurveRS(config-router-pim)# bsr-candidate loopback 1 1 31 ProCurveRS(config-router-pim)# rp-candidate loopback 1 ProCurveRS(config-router-pim)# exit

ProCurveRS(config)# router bgp ProCurveRS(config-bgp-router)# local-as 111 ProCurveRS(config-bgp-router)# neighbor 31.31.31.3 remote-as 333 ProCurveRS(config-bgp-router)# neighbor 31.31.31.3 next-hop-self ProCurveRS(config-bgp-router)# neighbor 12.12.12.2 remote-as 222 ProCurveRS(config-bgp-router)# neighbor 12.12.12.2 next-hop-self ProCurveRS(config-bgp-router)# neighbor 14.14.14.4 remote-as 444 ProCurveRS(config-bgp-router)# neighbor 14.14.14.4 next-hop-self ProCurveRS(config-bgp-router)# neighbor 17.17.17.7 remote-as 777 ProCurveRS(config-bgp-router)# neighbor 17.17.17.7 next-hop-self ProCurveRS(config-bgp-router)# redistribute connected ProCurveRS(config-bgp-router)# write memory

Configuration for Device B

The following set of commands configure the MSDP peers of Device B. All Device B’s peers (1.1.1.1, 1.1.3.1, and 1.1.4.1) are in the MSDP mesh group 1234. Multicast is enabled on Device B’s interfaces. PIM and BGP are also enabled.




ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# msdp-peer 1.1.3.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.1.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.4.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.1.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.3.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.4.1 ProCurveRS(config-msdp-router)# exit

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 1.1.2.1 255.255.255.0

11 - 52 June 2005


ProCurveRS(config-lbif-1)# ip pim-sparse ProCurveRS(config-lbif-1)# exit



ProCurveRS(config)# interface ethernet 1/24 ProCurveRS(config-if-1/24)# ip address 168.72.2.2 255.255.255.0 ProCurveRS(config-if-1/24)# exit




ProCurveRS(config)# router bgp ProCurveRS(config-router-bgp)# local-as 222 ProCurveRS(config-router-bgp)# neighbor 32.32.32.3 remote-as 333 ProCurveRS(config-router-bgp)# neighbor 32.32.32.3 next-hop-self ProCurveRS(config-router-bgp)# neighbor 24.24.24.4 remote-as 444 ProCurveRS(config-router-bgp)# neighbor 24.24.24.4 next-hop-self ProCurveRS(config-router-bgp)# neighbor 12.12.12.1 remote-as 111 ProCurveRS(config-router-bgp)# neighbor 12.12.12.1 next-hop-self ProCurveRS(config-router-bgp)# redistribute connected ProCurveRS(config-router-bgp)# write memory

Configuration for Device C

The following set of commands configure the MSDP peers of Device C (1.1.3.1) that are inside and outside MSDP mesh group 1234. Device C’s peers inside the mesh group 1234 are 1.1.1.1, 1.1.2.1, and 1.1.4.1. Device 35.35.35.5 is a peer of Device C, but is outside mesh group 1234. . Multicast is enabled on Device C’s interfaces. PIM and BGP are also enabled.




ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# msdp-peer 35.35.35.5 ProCurveRS(config-msdp-router)# msdp-peer 1.1.2.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.4.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.1.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.2.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.1.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.4.1 ProCurveRS(config-msdp-router)# exit

June 2005 11 - 53


ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 1.1.3.1 255.255.255.0 ProCurveRS(config-lbif-1)# ip pim-sparse ProCurveRS(config-lbif-1)# exit



ProCurveRS(config)# interface ethernet 10/8 ProCurveRS(config-if-10/8)# ip address 35.35.35.3 255.255.255.0 ProCurveRS(config-if-10/8)# ip pim-sparse ProCurveRS(config-if-10/8)# ip pim border ProCurveRS(config-if-10/8)# exit




ProCurveRS(config)# router bgp ProCurveRS(config-router-bsr)# local-as 333 ProCurveRS(config-router-bsr)# neighbor 35.35.35.5 remote-as 555 ProCurveRS(config-router-bsr)# neighbor 35.35.35.5 next-hop-self ProCurveRS(config-router-bsr)# neighbor 32.32.32.2 remote-as 222 ProCurveRS(config-router-bsr)# neighbor 32.32.32.2 next-hop-self ProCurveRS(config-router-bsr)# neighbor 34.34.34.4 remote-as 444 ProCurveRS(config-router-bsr)# neighbor 34.34.34.4 next-hop-self ProCurveRS(config-router-bsr)# neighbor 31.31.31.1 remote-as 111 ProCurveRS(config-router-bsr)# neighbor 31.31.31.1 next-hop-self ProCurveRS(config-router-bsr)# redistribute connected ProCurveRS(config-router-bsr)# write memory

Configuration for Device D

The following set of commands configure the MSDP peers of Device D (1.1.4.1) that are inside and outside MSDP mesh group 1234. Device D’s peers inside the mesh group 1234 are 1.1.1.1, 1.1.2.1, and 1.1.3.1. Device 48.48.48.8 and 134.134.134.13 are also peers of Device D, but are outside mesh group 1234. . Multicast is enabled on Device D’s interfaces. PIM and BGP are also enabled.




ProCurveRS(config)# router msdp ProCurveRS(config-msdp-router)# msdp-peer 1.1.3.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 1.1.1.1 connect-source loopback 1

11 - 54 June 2005


ProCurveRS(config-msdp-router)# msdp-peer 1.1.2.1 connect-source loopback 1 ProCurveRS(config-msdp-router)# msdp-peer 48.48.48.8 ProCurveRS(config-msdp-router)# msdp-peer 134.134.134.13 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.1.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.3.1 ProCurveRS(config-msdp-router)# mesh-group 1234 1.1.2.1 ProCurveRS(config-msdp-router)# exit

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-)# ip address 1.1.4.1 255.255.255.0 ProCurveRS(config-lbif-)# ip pim-sparse ProCurveRS(config-lbif-)# exit

ProCurveRS(config)# interface ethernet 1/1 ProCurveRS(config-if-)# ip address 24.24.24.4 255.255.255.0 ProCurveRS(config-if-)# ip pim-sparse ProCurveRS(config-if-)# exit




ProCurveRS(config)# interface ethernet 7/7 ProCurveRS(config-if-)# ip address 48.48.48.4 255.255.255.0 ProCurveRS(config-if-)# ip pim-sparse ProCurveRS(config-if-)# ip pim border ProCurveRS(config-if-)# exit

ProCurveRS(config)# interface ethernet 7/8 ProCurveRS(config-if-)# ip address 134.134.134.4 255.255.255.0 ProCurveRS(config-if-)# ip pim-sparse ProCurveRS(config-if-)# ip pim border ProCurveRS(config-if-)# exit


ProCurveRS(config)# router bgp ProCurveRS(config-router-bsr)# local-as 444 ProCurveRS(config-router-bsr)# neighbor 34.34.34.3 remote-as 333 ProCurveRS(config-router-bsr)# neighbor 34.34.34.3 next-hop-self ProCurveRS(config-router-bsr)# neighbor 14.14.14.1 remote-as 111 ProCurveRS(config-router-bsr)# neighbor 14.14.14.1 next-hop-self ProCurveRS(config-router-bsr)# neighbor 24.24.24.2 remote-as 222 ProCurveRS(config-router-bsr)# neighbor 24.24.24.2 next-hop-self ProCurveRS(config-router-bsr)# neighbor 48.48.48.8 remote-as 888 ProCurveRS(config-router-bsr)# neighbor 48.48.48.8 next-hop-self ProCurveRS(config-router-bsr)# neighbor 134.134.134.13 remote-as 1313 ProCurveRS(config-router-bsr)# neighbor 134.134.134.13 next-hop-self ProCurveRS(config-router-bsr)# redistribute connected

June 2005 11 - 55


ProCurveRS(config-router-bsr)# write memory

Displaying MSDP Information You can display the following MSDP information:

• Summary information – the IP addresses of the peers, the state of the Routing Switch’s MSDP session with each peer, and statistics for Keepalive, Source Active, and Notification messages sent to and received from each of the peers

• Peer information – the IP address of the peer, along with detailed MSDP and TCP statistics

• Source Active cache entries – the Source Active messages cached by the Routing Switch

Displaying Summary Information

To display summary MSDP information, use the following CLI method.

USING THE CLI

To display summary MSDP information, enter the following command at any level of the CLI:

ProCurveRS(config-msdp-router)# show ip msdp summary

MSDP Peer Status Summary KA: Keepalive SA:Source-Active NOT: Notification Peer Address State KA SA NOT

In Out In Out In Out 206.251.17.30 ESTABLISH 3 3 0 640 0 0 206.251.17.41 ESTABLISH 0 3 651 0 0 0

Syntax: show ip msdp summary


Table 11.2: MSDP Summary Information

This Field...

Peer Address

State

KA In

KA Out

SA In

SA Out

Displays...

The IP address of the peer’s interface with the Routing Switch

The state of the MSDP router’s connection with the peer. The state can be one of the following:

• CONNECTING – The session is in the active open state.

• ESTABLISHED – The MSDP session is fully up.

• INACTIVE – The session is idle.

• LISTENING – The session is in the passive open state.

The number of MSDP Keepalive messages the MSDP router has received from the peer

The number of MSDP Keepalive messages the MSDP router has sent to the peer

The number of Source Active messages the MSDP router has received from the peer

The number of Source Active messages the MSDP router has sent to the peer

11 - 56 June 2005


1

Table 11.2: MSDP Summary Information (Continued)

This Field...

NOT In

NOT Out

Displays...

The number of Notification messages the MSDP router has received from the peer

The number of Notification messages the MSDP router has sent to the peer


You cannot display MSDP information using the Web management interface.

Displaying Peer Information

To display summary MSDP peer information, use the following CLI method.

USING THE CLI

To display MSDP peer information, use the following CLI method.

ProCurveRS(config-msdp-router)# show ip msdp peer

Total number of MSDP Peers: 2

IP Address 206.251.17.30 Keep Alive Time

60

State ESTABLISHED

Hold Time 90

Message Sent Message Received Keep Alive 2 3 Notifications 0 0 Source-Active 0 640 Last Connection Reset Reason:Reason Unknown Notification Message Error Code Received:Unspecified Notification Message Error SubCode Received:Not Applicable Notification Message Error Code Transmitted:Unspecified Notification Message Error SubCode Transmitted:Not Applicable TCP Connection state: ESTABLISHED Local host: 206.251.17.29, Local Port: 8270 Remote host: 206.251.17.30, Remote Port: 639 ISentSeq: 16927 SendNext: 685654 TotUnAck: 0 SendWnd: 16384 TotSent: 668727 ReTrans: 1 IRcvSeq: 45252428 RcvNext: 45252438 RcvWnd: 16384 TotalRcv: 10 RcvQue: 0 SendQue: 0

Syntax: show ip msdp peer


Table 11.3: MSDP Peer Information


Total number of MSDP peers The number of MSDP peers configured on the Routing Switch

June 2005 11 - 57


Table 11.3: MSDP Peer Information (Continued)

This Field...

IP Address

State

Keep Alive Time

Hold Time

Keep Alive Message Sent

Keep Alive Message Received

Notifications Sent

Notifications Received

Source-Active Sent

Source-Active Received

Last Connection Reset Reason

Displays...

The IP address of the peer’s interface with the Routing Switch

The state of the MSDP router’s connection with the peer. The state can be one of the following:

• CONNECTING – The session is in the active open state.

• ESTABLISHED – The MSDP session is fully up.

• INACTIVE – The session is idle.

• LISTENING – The session is in the passive open state.

The keep alive time, which specifies how often this MSDP router sends keep alive messages to the neighbor. The keep alive time is 60 seconds and is not configurable.

The hold time, which specifies how many seconds the MSDP router will wait for a KEEPALIVE or UPDATE message from an MSDP neighbor before deciding that the neighbor is dead. The hold time is 90 seconds and is not configurable.

The number of Keep Alive messages the MSDP router has sent to the peer.

The number of Keep Alive messages the MSDP router has received from the peer.

The number of Notification messages the MSDP router has sent to the peer.

The number of Notification messages the MSDP router has received from the peer.

The number of Source Active messages the MSDP router has sent to the peer.

The number of Source Active messages the MSDP router has received from the peer.

The reason the previous session with this neighbor ended.

11 - 58 June 2005



This Field...

Notification Message Error Code Received

Notification Message Error SubCode Received

Notification Message Error Code Transmitted

Notification Message Error SubCode Transmitted

TCP Statistics

Displays...

If the MSDP router receives a NOTIFICATION messages from the neighbor, the message contains an error code corresponding to one of the following errors. Some errors have subcodes that clarify the reason for the error. Where applicable, the subcode messages are listed underneath the error code messages.

• 1 – Message Header Error

• 2 – SA-Request Error

• 3 – SA-Message/SA-Response Error

• 4 – Hold Timer Expired

• 5 – Finite State Machine Error

• 6 – Notification

• 7 – Cease

For information about these error codes, see section 17 in the Internet draft describing MSDP, “draft-ietf-msdp-spec”.

See above.

The error message corresponding to the error code in the NOTIFICATION message this MSDP router sent to the neighbor. See the description for the Notification Message Error Code Received field for a list of possible codes.

See above.

June 2005 11 - 59



This Field...

TCP connection state

Local host

Local port

Remote host

Remote port

ISentSeq

SendNext

TotUnAck

SendWnd

TotSent

ReTrans

Displays...

The state of the connection with the neighbor. The connection can have one of the following states:

• LISTEN – Waiting for a connection request.

• SYN-SENT – Waiting for a matching connection request after having sent a connection request.

• SYN-RECEIVED – Waiting for a confirming connection request acknowledgment after having both received and sent a connection request.

• ESTABLISHED – Data can be sent and received over the connection. This is the normal operational state of the connection.

• FIN-WAIT-1 – Waiting for a connection termination request from the remote TCP, or an acknowledgment of the connection termination request previously sent.

• FIN-WAIT-2 – Waiting for a connection termination request from the remote TCP.

• CLOSE-WAIT – Waiting for a connection termination request from the local user.

• CLOSING – Waiting for a connection termination request acknowledgment from the remote TCP.

• LAST-ACK – Waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request).

• TIME-WAIT – Waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.

• CLOSED – There is no connection state.

The IP address of the MSDP router’s interface with the peer.

The TCP port the MSDP router is using for the BGP4 TCP session with the neighbor.

The IP address of the neighbor.

The TCP port number of the peer end of the connection.

The initial send sequence number for the session.

The next sequence number to be sent.

The number of sequence numbers sent by the MSDP router that have not been acknowledged by the neighbor.

The size of the send window.

The number of sequence numbers sent to the neighbor.

The number of sequence numbers that the MSDP router retransmitted because they were not acknowledged.

11 - 60 June 2005




IRcvSeq The initial receive sequence number for the session.

RcvNext The next sequence number expected from the neighbor.

RcvWnd The size of the receive window.

TotalRcv The number of sequence numbers received from the neighbor.

RcvQue The number of sequence numbers in the receive queue.

SendQue The number of sequence numbers in the send queue.



Displaying Source Active Cache Information

To display the Source Actives in the MSDP cache, use the following CLI method.

ProCurveRS(config-msdp-router)# show ip msdp sa-cache

Total Entry 4096, Used 1800 Free 2296 Index SourceAddr GroupAddr Age1 (100.100.1.254, 232.1.0.95), RP:206.251.17.41, Age:0 2 (100.100.1.254, 237.1.0.98), RP:206.251.17.41, Age:30 3 (100.100.1.254, 234.1.0.48), RP:206.251.17.41, Age:30 4 (100.100.1.254, 239.1.0.51), RP:206.251.17.41, Age:30 5 (100.100.1.254, 234.1.0.154), RP:206.251.17.41, Age:30 6 (100.100.1.254, 236.1.0.1), RP:206.251.17.41, Age:30 7 (100.100.1.254, 231.1.0.104), RP:206.251.17.41, Age:90 8 (100.100.1.254, 239.1.0.157), RP:206.251.17.41, Age:30 9 (100.100.1.254, 236.1.0.107), RP:206.251.17.41, Age:30 10 (100.100.1.254, 233.1.0.57), RP:206.251.17.41, Age:90

Syntax: show ip msdp sa-cache


Table 11.4: MSDP Source Active Cache

This Field...

Total Entry

Used

Free

Index

SourceAddr

GroupAddr

Displays...

The total number of entries the cache can hold.

The number of entries the cache currently contains.

The number of additional entries for which the cache has room.

The cache entry number.

The IP address of the multicast source.

The IP multicast group to which the source is sending information.

June 2005 11 - 61


Table 11.4: MSDP Source Active Cache (Continued)


RP The RP through which receivers can access the group traffic from the source

Age The number of seconds the entry has been in the cache



Clearing MSDP Information You can clear the following MSDP information:

• Peer information

• Source Active cache

• MSDP statistics

Clearing Peer Information

To clear MSDP peer information, enter the following command at the Privileged EXEC level of the CLI:

ProCurveRS# clear ip msdp peer 205.216.162.1Remote connection closed

Syntax: clear ip msdp peer <ip-addr>

The command in this example clears the MSDP peer connection with MSDP router 205.216.162.1. The CLI displays a message to indicate when the connection has been successfully closed.

Clearing the Source Active Cache

To clear the entries from the Source Active cache, enter the following command at the Privileged EXEC level of the CLI:

ProCurveRS# clear ip msdp sa-cache

Syntax: clear ip msdp sa-cache [<source-addr> | <group-addr>]

The command in this example clears all the cache entries. Use the <source-addr> parameter to clear only the entries for a specified course. Use the <group-addr> parameter to clear only the entries for a specific group.

Clearing MSDP Statistics

To clear MSDP statistics, enter the following command at the Privileged EXEC level of the CLI:

ProCurveRS# clear ip msdp statistics

Syntax: clear ip msdp statistics [<ip-addr>]

The command in this example clears statistics for all the peers. To clear statistics for only a specific peer, enter the peer’s IP address.

DVMRP Overview HP routers provide multicast routing with the Distance Vector Multicast Routing Protocol (DVMRP) routing protocol. DVMRP uses Internet Group Membership Protocol (IGMP) to manage the IP multicast groups.

DVMRP is a broadcast and pruning multicast protocol that delivers IP multicast datagrams to its intended receivers. The receiver registers the interested groups using IGMP. DVMRP builds a multicast delivery tree with the sender forming the root. Initially, multicast datagrams are delivered to all nodes on the tree. Those leaves that do not have any group members send prune messages to the upstream router, noting the absence of a

11 - 62 June 2005


group. The upstream router maintains a prune state for this group for the given sender. A prune state is aged out after a given configurable interval, allowing multicasts to resume.

DVMRP employs reverse path forwarding and pruning to keep source specific multicast delivery trees with the minimum number of branches required to reach all group members. DVMRP builds a multicast tree for each source and destination host group.

Initiating DVMRP Multicasts on a Network Once DVMRP is enabled on each router, a network user can begin a video conference multicast from the server on R1. Multicast Delivery Trees are initially formed by source-originated multicast packets that are propagated to downstream interfaces as seen in Figure 11.7. When a multicast packet is received on a DVMRP-capable router interface, the interface checks its DVMRP routing table to determine whether the interface that received the message provides the shortest path back to the source. If the interface does provide the shortest path, the interface forwards the multicast packet to adjacent peer DVMRP routers, except for the router interface that originated the packet. Otherwise, the interface discards the multicast packet and sends a prune message back upstream. This process is known as reverse path forwarding.

In Figure 11.7, the root node (R1) is forwarding multicast packets for group 229.225.0.2 that it receives from the server to its downstream nodes, R2, R3, and R4. Router R4 is an intermediate router with R5 and R6 as its downstream routers. Because R5 and R6 have no downstream interfaces, they are leaf nodes.

The receivers in this example are those workstations that are resident on routers R2, R3, and R6.

Pruning a Multicast Tree After the multicast tree is constructed, pruning of the tree will occur after IP multicast packets begin to traverse the tree.

As multicast packets reach leaf networks (sub-nets with no downstream interfaces), the local IGMP database checks for the recently arrived IP multicast packet address. If the local database does not contain the address (the address has not been learned), the router prunes (removes) the address from the multicast tree and no longer receives multicasts until the prune age expires.

In Figure 11.8, Router 5 is a leaf node with no group members in its local database. Consequently, Router 5 sends a prune message to its upstream router. This router will not receive any further multicast traffic until the prune age interval expires.

June 2005 11 - 63


Figure 11.7 Downstream broadcast of IP multicast packets from source host

11 - 64 June 2005


Figure 11.8 Pruning leaf nodes from a multicast tree

Group Member

Group Member

Leaf Node (No Group Members)

R5

R3

R4

R6

R1R2

Leaf Node

Leaf Node

(207.95.5.1, 229.225.0.1)

...

Group Member

Group Member

Group Member

...

...

sent to upstream router (R4)

(No Group Members)

229.225.0.1 229.225.0.1

Video Conferencing Server

(Source, Group)

Prune Message

Interrmediate Node

Group Group Group Member Member Member

229.225.0.1

Grafts to a Multicast Tree A DVMRP router restores pruned branches to a multicast tree by sending graft messages towards the upstream router. Graft messages start at the leaf node and travel up the tree, first sending the message to its neighbor upstream router.

In the example above, if a new 229.255.0.1 group member joins on router R6, which had been pruned previously, a graft will be sent upstream to R4. Since the forwarding state for this entry is in a prune state, R4 sends a graft to R1. Once R4 has joined the tree, it along with R6 will once again receive multicast packets.

You do not need to perform any configuration to maintain the multicast delivery tree. The prune and graft messages automatically maintain the tree.

Configuring DVMRP

Enabling DVMRP on the Routing Switch and Interface Suppose you want to initiate the use of desktop video for fellow users on a sprawling campus network. All destination workstations have the appropriate hardware and software but the Routing Switches that connect the various buildings need to be configured to support DVMRP multicasts from the designated video conference server as seen in Figure 11.7.

DVMRP is enabled on each of the ProCurve Routing Switches shown in Figure 11.7, on which multicasts are expected. You can enable DVMRP on each Routing Switch independently or remotely from one Routing Switch by a Telnet connection. Follow the same steps for each router.

June 2005 11 - 65


Globally Enabling and Disabling DVMRP

To globally enable DVMRP, enter the following command:

Router1(config)# router dvmrp

Syntax: [no] router dvmrp

Prior to software release 07.8.00, the behavior of the [no] router dvmrp command was as follows:

• ProCurve Routing Switches required a software reload whenever you enabled DVMRP using the router dvmrp command.

• Entering a no router dvmrp command removed all configuration for PIM multicast on a Routing Switch (router pim level) and all PIM and PIM-Sparse (ip pim and ip pim-sparse) configuration on all interfaces.

Beginning with software release 07.8.00:

• Entering a router dvmrp command to enable DVMRP does not require a software reload.

• Entering a no router dvmrp command removes all configuration for PIM multicast on a Routing Switch (router pim level) only.

Globally Enabling or Disabling DVMRP without Deleting Multicast Configuration

As stated above enter no router dvmrp removed PIM configuration. If you want to disable or enable DVMRP without removing PIM configuration, enter the following command:

ProCurveRS(config)# router dvmrp ProCurveRS(config-pim-router)# disable-dvmrp

Syntax: [no] disable-dvmrp

Use the [no] version of the command to re-enable DVMRP.

Enabling DVMRP on an Interface

After globally enabling DVMRP on a Routing Switch, enable it on each interface that will support the protocol.

USING THE CLI

To enable DVMRP on Router 1 and interface 3, enter the following:

Router1(config)# router dvmrp Router1(config-dvmrp-router)# int e 3 Router1(config-if-3)# ip dvmrp


To enable DVMRP on Router 1 and interface 3, enter the following:


2. If you have not already enabled DVMRP, enable it by clicking on the Enable radio button next to DVMRP on the System configuration panel, then clicking Apply to apply the change.


4. Click on the plus sign next to DVMRP in the tree view to expand the list of DVMRP option links.

5. Click on the Virtual Interface link to display the DVMRP Interface configuration panel.

NOTE: If the device already has DVMRP interfaces, a table listing the interfaces is displayed. Click the Modify button to the right of the row describing an interface to change its configuration, or click the Add Virtual Interface link to display the DVMRP Interface configuration panel.

6. Select the interface type. You can select Subnet or Tunnel.


11 - 66 June 2005


8. If you are configuring an IP Tunnel, enter the IP address of the destination interface, the end point of the IP Tunnel, in the Remote Address field. IP tunneling must also be enabled and defined on the destination router interface as well.

NOTE: The Remote Address field applies only to tunnel interfaces, not to sub-net interfaces.



10. Click Enable or Disable next to Advertise Local to enable or disable the feature.

11. Click Enable or Disable next to Encapsulation to enable or disable the feature.



14. Click on the plus sign next to Command in the tree view to list the command options.

15. Select the Reload link and select Yes when prompted to reload the software. You must reload after enabling DVMRP to place the change into effect. If DVMRP was already enabled when you added the interface, you do not need to reload.

Modifying DVMRP Global Parameters DVMRP global parameters come with preset values. The defaults work well in most networks, but you can modify the following global parameters if you need to:

• Neighbor timeout

• Route expire time

• Route discard time

• Prune age

• Graft retransmit time

• Probe interval

• Report interval

• Trigger interval

• Default route

Modifying Neighbor Timeout

The neighbor timeout specifies the period of time that a router will wait before it defines an attached DVMRP neighbor router as down. Possible values are 40 – 8000 seconds. The default value is 180 seconds.

USING THE CLI

To modify the neighbor timeout value to 100, enter the following:

ProCurveRS(config-dvmrp-router)# nbr 100

Syntax: nbr-timeout <40-8000>




June 2005 11 - 67




4. Click on the General link to display the DVMRP configuration panel, as shown in the following example.

5. Enter a value from 40 – 8000 into the Neighbor Router Timeout field.



Modifying Route Expires Time

The Route Expire Time defines how long a route is considered valid in the absence of the next route update. Possible values are from 20 – 4000 seconds. The default value is 200 seconds.

USING THE CLI

To modify the route expire setting to 50, enter the following:

ProCurveRS(config-dvmrp-router)# route-expire-timeout 50

Syntax: route-expire-timeout <20-4000>





4. Click on the General link to display the DVMRP configuration panel.

5. Enter a value from 20 – 4000 in the Route Expire Time field.



11 - 68 June 2005


Modifying Route Discard Time

The Route Discard Time defines the period of time before a route is deleted. Possible values are from 40 – 8000 seconds. The default value is 340 seconds.

USING THE CLI

To modify the route discard setting to 150, enter the following:

ProCurveRS(config-dvmrp-router)# route-discard-timeout 150

Syntax: route-discard-timeout <40-8000>






5. Enter a value from 40 – 8000 in the Route Discard Time field.



Modifying Prune Age

The Prune Age defines how long a prune state will remain in effect for a source-routed multicast tree. After the prune age period expires, flooding will resume. Possible values are from 20 – 3600 seconds. The default value is 180 seconds.

USING THE CLI

To modify the prune age setting to 150, enter the following:

ProCurveRS(config-dvmrp-router)# prune 25

Syntax: prune-age <20-3600>






5. Enter a value from 20 – 3600 in the Prune Age field.



Modifying Graft Retransmit Time

The Graft Retransmit Time defines the initial period of time that a router sending a graft message will wait for a graft acknowledgement from an upstream router before re-transmitting that message.

Subsequent retransmissions are sent at an interval twice that of the preceding interval. Possible values are from 5 – 3600 seconds. The default value is 10 seconds.

USING THE CLI

To modify the setting for graft retransmit time to 120, enter the following:

ProCurveRS(config-dvmrp-router)# graft 120

June 2005 11 - 69


Syntax: graft-retransmit-time <5-3600>






5. Enter a value from 5 – 3600 in the Graft Retransmit Time field.



Modifying Probe Interval

The Probe Interval defines how often neighbor probe messages are sent to the ALL-DVMRP-ROUTERS IP multicast group address. A router’s probe message lists those neighbor DVMRP routers from which it has received probes. Possible values are from 5 – 30 seconds. The default value is 10 seconds.

USING THE CLI

To modify the probe interval setting to 10, enter the following:

ProCurveRS(config-dvmrp-router)# probe 10

Syntax: probe-interval <5-30>






5. Enter a value from 5 – 30 in the Probe Interval field.



Modifying Report Interval

The Report Interval defines how often routers propagate their complete routing tables to other neighbor DVMRP routers. Possible values are from 10 – 2000 seconds. The default value is 60 seconds.

USING THE CLI

To support propagation of DVMRP routing information to the network every 90 seconds, enter the following:

ProCurveRS(config-dvmrp-router)# report 90

Syntax: report-interval <10-2000>






5. Enter a value from 10 – 2000 in the Report Interval field.

11 - 70 June 2005




Modifying Trigger Interval

The Trigger Interval defines how often trigger updates, which reflect changes in the network topology, are sent. Example changes in a network topology include router up or down or changes in the metric. Possible values are from 5 – 30 seconds. The default value is 5 seconds.

USING THE CLI

To support the sending of trigger updates every 20 seconds, enter the following:

ProCurveRS(config-dvmrp-router)# trigger-interval 20

Syntax: trigger-interval <5-30>






5. Enter a value from 5 – 30 in the Trigger Interval field.



Modifying Default Route

This defines the default gateway for IP multicast routing.

USING THE CLI

To define the default gateway for DVMRP, enter the following:

ProCurveRS(config-dvmrp-router)# default-gateway 192.35.4.1

Syntax: default-gateway <ip-addr>






5. Enter the IP address of the default gateway in the Default Route field.



Modifying DVMRP Interface Parameters DVMRP global parameters come with preset values. The defaults work well in most networks, but you can modify the following interface parameters if you need to:

• TTL

• Metric

June 2005 11 - 71


• Advertising

Modifying the TTL

The TTL defines the minimum value required in a packet in order for the packet to be forwarded out the interface. For example, if the TTL for an interface is set at 10 it means that only those packets with a TTL value of 10 or more are forwarded. Likewise, if an interface is configured with a TTL Threshold value of 1, all packets received on that interface are forwarded. Possible values are from 1 – 64. The default value is 1.

USING THE CLI

To set a TTL of 64, enter the following:

ProCurveRS(config)# int e 1/4 ProCurveRS(config-if-1/4)# ip dvmrp ttl 60

Syntax: ttl-threshold <1-64>


To modify a DVMRP interface’s TTL:




4. Select the Virtual Interface link to display a table listing the configured DVMRP Interfaces.

5. Click on the Modify button next to the interface you want to modify. The DVMRP Interface configuration panel is displayed.

6. Enter a value from 1 – 64 in the Time To Live Threshold (TTL) field.



Modifying the Metric

The router uses the metric when establishing reverse paths to some networks on directly attached interfaces. Possible values are from 1 – 31 hops. The default is 1.

USING THE CLI

To set a metric of 15 for a DVMRP interface, enter the following:

ProCurveRS(config)# interface 3/5 ProCurveRS(config-if-3/5)# ip dvmrp metric 15

Syntax: ip dvmrp metric <1-31>


To modify a DVMRP interface’s metric:






6. Enter a value from 1 – 31 in the Metric field.


11 - 72 June 2005



NOTE: You also can access the dialog for saving configuration changes by clicking on Command in the tree view, then clicking on Save to Flash.

Enabling Advertising

You can turn the advertisement of a local route on (enable) or off (disable) on the interface. By default, advertising is enabled.

USING THE CLI

To enable advertising on an interface, enter the following:

ProCurveRS(config-if-1/4)# ip dvmrp advertise-local on

Syntax: advertise-local on | off


To enable local advertising on a DVMRP interface:






6. Select Enable next to Advertise Local.



Displaying Information About an Upstream Neighbor Device In software release 07.7.00 and later, you can view information about the upstream neighbor device for a given source IP address for IP PIM packets. The software uses the IP route table or multicast route table to lookup the upstream neighbor device.

The following shows example messages that the HP device can display with this command.

ProCurveRS# show ip dvmrp rpf 1.1.20.2

directly connected or via an L2 neighbor


no route


upstream neighbor=1.1.20.1 on v21 using ip route

Syntax: show ip dvmrp rpf <IP address>

where <IP address> is a valid source IP address

June 2005 11 - 73


NOTE: If there are multiple equal cost paths to the source, the show ip dvmrp rpf command output may not be accurate. If your system has multiple equal cost paths, use the command sh ip dvmrp mcache to view information about the upstream neighbor. For more information about this command, see the Command Line Interface Reference for ProCurve 9300/9400 Series Routing Switches.

Configuring an IP Tunnel IP tunnels are used to send traffic through routers that do not support IP multicasting. IP Multicast datagrams are encapsulated within an IP packet and then sent to the remote address. Routers that are not configured for IP Multicast route that packet as a normal IP packet. When the IP Multicast router at the remote end of the tunnel receives the packet, the router strips off the IP encapsulation and forwards the packet as an IP Multicast packet.

NOTE: An IP tunnel must have a remote IP interface at each end. Also, for IP tunneling to work, the remote routers must be reachable by an IP routing protocol.

NOTE: Multiple tunnels configured on a router cannot share the same remote address.

NOTE: IP tunnels are supported for DVMRP only in software release 07.6.04 and later.

EXAMPLE:

To configure an IP tunnel as seen in Figure 11.9, enter the IP tunnel destination address on an interface of the router.

USING THE CLI

To configure an IP address on Router A, enter the following:

ProCurveRS(config)# int e1 ProCurveRS(config-if-1)# ip tunnel 192.3.45.6

NOTE: The IP tunnel address represents the configured IP tunnel address of the destination router. In the case of Router A, its destination router is Router B. Router A is the destination router of Router B.

For router B, enter the following:

ProCurveRS(config-if-1)# ip tunnel 192.58.4.1

Figure 11.9 IP in IP tunneling on multicast packets in a unicast network

Router A Non-Multicast Capable Router B HP 9308M Routers HP 9308M Mulitcast Capable Router Mulitcast Capable Router

Router

Router

RouterRouter IP TunnelIP Tunnel IP Tunnel192.58.4.1 192.3.45.6

...

Group Member

Group Member

Group Member

...

Group Member

Group Member

Group Member



11 - 74 June 2005




4. Click on the Virtual Interface link to display the PIM Interface configuration panel.

NOTE: If the device already has PIM interfaces, a table listing the interfaces is displayed. Click the Modify button to the right of the row describing an interface to change its configuration, or click the Add Virtual Interface link to display the PIM Interface configuration panel.

5. Select the interface type. You can select Subnet or Tunnel. In this case, select Tunnel.


7. Enter the IP address of the destination interface, the end point of the IP Tunnel, in the Remote Address field. IP tunneling must also be enabled and defined on the destination router interface as well.



9. Click Enable or Disable next to Advertise Local to enable or disable the feature.

10. Click Enable or Disable next to Encapsulation to enable or disable the feature.



13. Repeat the steps above on the router that has the interface on the remote end of the IP tunnel.

Using ACLs to Control Multicast Features Starting with Release 07.6.04, you can use ACLs to control the following multicast features:

• Limit the number of multicast groups that are covered by a static rendezvous point (RP)

• Control which multicast groups for which candidate RPs sends advertisement messages to bootstrap routers

• Identify which multicast group packets will be forwarded or blocked on an interface

Using ACLs to Limit Static RP Groups Starting with software release 07.6.04, you can limit the number of multicast groups covered by a static RP using standard ACLs. In the ACL, you specify the group to which the RP address applies. The following examples set the RP address to be applied to multicast groups with some minor variations.

To configure an RP that covers multicast groups in 239.255.162.x, enter commands such as the following:

ProCurveRS(config)# access-list 2 permit 239.255.162.0 0.0.0.255

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# rp-address 43.43.43.1 2

To configure an RP that covers multicast groups in the 239.255.162.x range, except the 239.255.162.2 group, enter commands such as the following:

ProCurveRS(config)# access-list 5 deny host 239.255.162.2



June 2005 11 - 75


---------------------------------------------------

ProCurveRS(config-pim-router)# bsr-candidate ve 43 32 100 ProCurveRS(config-pim-router)# rp-candidate ve 43 ProCurveRS(config-pim-router)# rp-address 99.99.99.5 5

To configure an RP for multicast groups using the override switch, enter commands such as the following:


ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# rp-address 43.43.43.1 ProCurveRS(config-pim-router)# rp-address 99.99.99.5 44 override

Syntax: [no] rp-address <ip-address> [ <access-list-num> ] [ override ]

The access-list-num parameter is the number of the standard ACL that will filter the multicast group.

NOTE: Extended ACLs cannot be used to limit static RP groups.

The override parameter directs the Routing Switch to ignore the information learned by a BSR if there is a conflict between the RP configured in this command and the information that is learned by the BSR. In previous releases, static RP configuration precedes the RP address learned from the PIM Bootstrap protocol. With this enhancement, an RP address learned dynamically from PIM Bootstrap protocol takes precedence over static RP configuration unless the override parameter is used.

You can use the show ip pim rp-set command to display the ACLs used to filter the static RP groups. For example,

ProCurveRS(config) #show ip pim rp-set

Group address Static-RP-address Override

Access-List 44 99.99.99.5 On

Number of group prefixes Learnt from BSR: 1

Group prefix = 224.0.0.0/4 # RPs: 1 RP 1: 43.43.43.1 priority=0 age=0

In the example above, the display shows the following information:

• The Group Address table shows the static RP address that is covered by the access list, and whether or not the override parameter has been enabled.

• The Group prefix line shows the multicast group prefix for the static RP.

• The RP # line shows the configured IP address of the RP candidate.

11 - 76 June 2005


-------------------------------

The show ip pim rp-map to show the group-to-RP mapping.

ProCurveRS(config)# show ip pim rp-map

Number of group-to-RP mappings: 6

Group address RP address

1 239.255.163.1 43.43.43.1 2 239.255.163.2 43.43.43.1 3 239.255.163.3 43.43.43.1 4 239.255.162.1 99.99.99.5 5 239.255.162.2 99.99.99.5 6 239.255.162.3 99.99.99.5

The display shows the multicast group addresses covered by the RP candidate and the IP address of the RP for the listed multicast group. In the example above, you see the following:

• The first three lines show the multicast group addresses that are covered by the RP candidate.

• The last three lines show the multicast group addresses covered by the static RP.

Using ACLs to Limit PIM RP Candidate Advertisement You can use standard ACLs to control the groups for which the candidate RP will send advertisement messages to the bootstrap router. For example, ACL 5 can be configured to be applied to the multicast groups within the IP address 239.x.x.x range. You can configure the Routing Switch to advertise itself as a candidate RP to the bootstrap router only for groups in the range of 239.x.x.x. Enter commands such as the following:


ProCurveRS(config)# access-list 5 deny host 239.255.162.2 ProCurveRS(config)# access-list 5 permit 239.0.0.0 0.0.255.255

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# bsr-candidate ethernet 1/1 32 100 ProCurveRS(config-pim-router)# rp-candidate ethernet 1/1 group-list 5

The example above shows a configuration for an Ethernet interface. To configure ACLs that are applied to a virtual routing interface, enter commands such as the following:

ProCurveRS(config)# interface ve 16 ProCurveRS(config-vif-16)# ip address 16.16.16.1 255.255.255.0 ProCurveRS(config-vif-16)# ip pim-sparse ProCurveRS(config-vif-16)# exit


ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# bsr-candidate ve 16 32 100 ProCurveRS(config-pim-router)# rp-candidate ve 16 group-list 5

To configure ACLs that are applied to a loopback interface, enter commands such as the following:

ProCurveRS(config)# interface loopback 1 ProCurveRS(config-lbif-1)# ip address 88.88.88.8 255.255.255.0 ProCurveRS(config-lbif-1)# ip pim-sparse ProCurveRS(config-lbif-1)# exit

June 2005 11 - 77



ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# bsr-candidate loopback 1 32 100 ProCurveRS(config-pim-router)# rp-candidate loopback 1 group-list 5

Syntax: [no] rp-candidate ethernet <portnum> | loopback <num> | ve <num> [ group-list <access-list-num> ]

The ethernet <portnum> | loopback <num> | ve <num> parameter specifies the interface. The Routing Switch will advertise the specified interface’s IP address as a candidate RP.




The group-list <access-list-num> indicates that a standard ACL is used to filter for which multicast group the advertisement will be made.

NOTE: Extended ACLs cannot be used for group-list.

Using ACLs to Control Multicast Traffic Boundaries You can create ACLs that determine which multicast traffic packets can be forwarded on an interface in a PIM or DVMRP domain. The ACLs can be create to be applied to a range of multicast group addresses. If an ACL denies the specified multicast group addresses, incoming or outgoing packets from those addresses will not be allowed to flow across the interface.

For example, to set up a boundary, which will deny all multicast group addresses within the 239.x.x.x IP address range, enter commands such as the following:

ProCurveRS(config)# access-list 1 deny 239.0.0.0 0.255.255.255 ProCurveRS (config)# access-list 1 permit 234.0.0.0 0.255.255.255

ProCurveRS(config)# interface ethernet 1/1 ProCurveRS(config-if-1/1)# ip pim-sparse ProCurveRS(config-if-1/1)# ip multicast boundary 1

Syntax: [no] ip multicast boundary <access-list-num>

The <access-list-num> parameter defines the ACLs used to set-up the boundaries for multicast traffic packets.

NOTE: Extended ACLs cannot be used in this feature.

Configuring a Static Multicast Route Static multicast routes allow you to control the network path used by multicast traffic. Static multicast routes are especially useful when the unicast and multicast topologies of a network are different. You can avoid the need to make the topologies similar by instead configuring static multicast routes.

NOTE: This feature is not supported for DVMRP.

You can configure more than one static multicast route. The Routing Switch always uses the most specific route that matches a multicast source address. Thus, if you want to configure a multicast static route for a specific multicast source and also configure another multicast static route for all other sources, you can configure two static routes as shown in the examples below.

To add a static route for a multicast source network, use one of the following methods.

11 - 78 June 2005


USING THE CLI

To add static routes to multicast router A (see Figure 11.10), enter commands such as the following:

PIMRouterA(config)# ip mroute 1 207.95.10.0 255.255.255.0 interface ethernet 1/2 distance 1 PIMRouterA(config)# ip mroute 2 0.0.0.0 0.0.0.0 interface ethernet 2/3 distance 1 PIMRouterA(config)# write memory

Syntax: mroute <route-num> <ip-addr> interface ethernet <portnum> | ve <num> [distance <num>]

Or

Syntax: mroute <route-num> <ip-addr> rpf_address <rpf-num>

The <route-num> parameter specifies the route number.

The <ip-addr> command specifies the PIM source for the route.

NOTE: In IP multicasting, a route is handled in terms of its source, rather than its destination.

You can use the ethernet <portnum> parameter to specify a physical port or the ve <num> parameter to specify a virtual interface.

NOTE: The ethernet <portnum> parameter does not apply to PIM SM.

The distance <num> parameter sets the administrative distance for the route. When comparing multiple paths for a route, the Routing Switch prefers the path with the lower administrative distance.

NOTE: Regardless of the administrative distances, the Routing Switch always prefers directly connected routes over other routes.

The rpf_address <rpf-num> parameter specifies an RPF number.

The example above configures two static multicast routes. The first route is for a specific source network, 207.95.10.0/24. If the Routing Switch receives multicast traffic for network 207.95.10.0/24, the traffic must arrive on port 1/2. The second route is for all other multicast traffic. Traffic from multicast sources other than 207.95.10.0/24 must arrive on port 2/3.

Figure 11.10 shows an example of an IP Multicast network. The two static routes configured in the example above apply to this network. The commands in the example above configure PIM router A to accept PIM packets from 207.95.10.0/24 when they use the path that arrives at port 1/2, and accept all other PIM packets only when they use the path that arrives at port 2/3.

The distance parameter sets the administrative distance. This parameter is used by the software to determine the best path for the route. Thus, to ensure that the Routing Switch uses the default static route, assign a low administrative distance value. When comparing multiple paths for a route, the Routing Switch prefers the path with the lower administrative distance.

June 2005 11 - 79


Figure 11.10 Example multicast static routes

PIM router D

e3/19

Client

e1/4 207.95.7.1

e1/5 207.95.8.10

207.95.6.1

PIM router C

e1/8 207.95.8.1

PIM router B

e2/3 207.95.7.2

e1/2 207.95.6.2

Client 9.9.9.101

239.255.162.1

8.8.8.164 209.157.24.62

e6/14

Server

e4/11

e3/11

PIM router A

Multicast group

Multicast group Multicast group 239.255.162.1 239.255.162.1

To add a static route to a virtual interface, enter commands such as the following:

ProCurveRS(config)# mroute 3 0.0.0.0 0.0.0.0 int ve 1 distance 1 ProCurveRS(config)# write memory


You cannot configure a static multicast route using the Web management interface.

Tracing a Multicast Route The HP implementation of Mtrace is based on “A ‘traceroute’ facility for IP Multicast”, an Internet draft by S. Casner and B. Fenner. To trace a PIM route, use the following CLI method.


11 - 80 June 2005


USING THE CLI

To trace a PIM route to PIM source 209.157.24.62 in group 239.255.162.1, enter a command such as the following:

ProCurveRS# mtrace source 209.157.24.62 group 239.255.162.1

Type Control-c to abort Tracing the route for tree 209.157.23.188

0 207.95.7.2 0 207.95.7.2 Thresh 0 1 207.95.7.1 Thresh 0 2 207.95.8.1 Thresh 0 3 207.157.24.62

Syntax: mtrace source <ip-addr> group <multicast-group>

The source <ip-addr> parameter specifies the address of the route’s source.

NOTE: In IP multicasting, a route is handled in terms of its source, rather than its destination. When you trace an IP route, you specify its destination, but when you trace a PIM route, you specify its source.

The group <multicast-group> parameter specifies the PIM group the source IP address is in.

Figure 11.11 shows an example of an IP multicast group. The command example shown above is entered on PIM router A.

Figure 11.11 Example PIM Group

PIM router A PIM router B PIM router C

e3/19

Client

e1/4 207.95.7.1

e1/5 207.95.8.10

e3/11

e1/8 207.95.8.1

e2/3 207.95.7.2

8.8.8.164 209.157.24.62

Server

Multicast group Multicast group 239.255.162.1 239.255.162.1

The command example above indicates that the source address 209.157.24.62 is three hops (three PIM routers) away from PIM router A. In PIM terms, each of the three routers has a forwarding state for the specified source address and multicast group. The value following “Thresh” in some of the lines indicates the TTL threshold. The threshold 0 means that all multicast packets are forwarded on the interface. If an administrator has set the TTL threshold to a higher value, only packets whose TTL is higher than the threshold are forwarded on the interface. The threshold is listed only for the PIM router hops between the source and destination.


You cannot trace a PIM route using the Web management interface.

June 2005 11 - 81


Displaying Another Multicast Router’s Multicast Configuration The HP implementation of Mrinfo is based on the DVMRP Internet draft by T. Pusateri, but applies to PIM and not to DVMRP. To display the PIM configuration of another PIM router, use the following CLI method.


USING THE CLI

To display another PIM router’s PIM configuration, enter a command such as the following:

ProCurveRS# mrinfo 207.95.8.1207.95.8.1 -> 207.95.8.10 [PIM/0 /1 ]207.95.10.2 -> 0.0.0.0 [PIM/0 /1 /leaf]209.157.25.1 -> 0.0.0.0 [PIM/0 /1 /leaf]209.157.24.1 -> 0.0.0.0 [PIM/0 /1 /leaf]207.95.6.1 -> 0.0.0.0 [PIM/0 /1 /leaf]128.2.0.1 -> 0.0.0.0 [PIM/0 /1 /leaf]

Syntax: mrinfo <ip-addr>

The <ip-addr> parameter specifies the IP address of the PIM router.

The output in this example is based on the PIM group shown in Figure 11.11 on page 11-81. The output shows the PIM interfaces configured on PIM router C (207.95.8.1). In this example, the PIM router has six PIM interfaces. One of the interfaces goes to PIM router B. The other interfaces go to leaf nodes, which are multicast end nodes attached to the router’s PIM interfaces. (For simplicity, the figure shows only one leaf node.)

When the arrow following an interface in the display points to a router address, this is the address of the next hop PIM router on that interface. In this example, PIM interface 207.95.8.1 on PIM router 207.95.8.1 is connected to PIM router 207.95.8.10. The connection can be a direct one or can take place through non-PIM routers. In this example, the PIM routers are directly connected.

When the arrow following an interface address points to zeros (0.0.0.0), the interface is not connected to a PIM router. The interface is instead connected to a leaf node.

NOTE: This display shows the PIM interface configuration information, but does not show the link states for the interfaces.

The information in brackets indicates the following:

• The multicast interface type (always PIM; this display is not supported for DVMRP)

• The Time-to-Live (TTL) for the interface.

• The metric for the interface

• Whether the interface is connected to a leaf node (“leaf” indicates a leaf node and blank indicates another PIM router)

For example, the information for the first interface listed in the display is “PIM/0 /1”. This information indicates that the interface is a PIM interface, has a TTL of 0, and a metric of 1. The interface is not a leaf node interface and thus is an interface to another PIM router.

The information for the second interface in the display is “PIM/0 /1/leaf”. This information indicates that the interface is a PIM interface, has a TTL of 0 and a metric of 1, and is connected to a leaf node.


You cannot display another router’s PIM configuration using the Web management interface.

11 - 82 June 2005


IGMP V3 The Internet Group Management Protocol (IGMP) allows an IPV4 interface to communicate IP Multicast group membership information to its neighboring routers. The routers in turn limit the multicast of IP packets with multicast destination addresses to only those interfaces on the router that are identified as IP Multicast group members. This release introduces the support of IGMP version 3 (IGMP V3) on Routing Switches.

In IGMP V2, when a router sent a query to the interfaces, the clients on the interfaces respond with a membership report of multicast groups to the router. The router can then send traffic to these groups, regardless of the traffic source. When an interface no longer needs to receive traffic from a group, it sends a leave message to the router which in turn sends a group-specific query to that interface to see if any other clients on the same interface is still active.

In contrast, IGMP V3 provides selective filtering of traffic based on traffic source. A router running IGMP V3 sends queries to every multicast enabled interface at the specified interval. These queries determine if any interface wants to receive traffic from the router. The queries include the IP address of the traffic source (S) and/or the ID of the multicast group (G).

The interfaces respond to these queries by sending a membership report that contains one or more of the following records that are associated with a specific group:

• Current-State Record that indicates from which sources the interface wants to receive and not receive traffic. The record contains source address of interfaces and whether or not traffic will be received or included (IS_IN) or not received or excluded (IS_EX) from that source.

• Filter-mode-change record. If the interface changes its current state from IS_IN to IS_EX, a TO_EX record is included in the membership report. Likewise, if an interface’s current state changes from IS_EX to IS_IN, a TO_IN record appears in the membership report.

IGMP V2 Leave report is equivalent to a TO_IN(empty) record in IGMP V3. This record means that no traffic from this group will be received regardless of the source.

An IGMP V2 group report is equivalent to an IS_EX(empty) record in IGMP V3. This record means that all traffic from this group will be received regardless of source.

• Source-List-Change Record. If the interface wants to add or remove traffic sources from its membership report, the membership report can have an ALLOW record, which contains a list of new sources from which the interface wishes to receive traffic. It can also contains a BLOCK record, which lists current traffic sources from which the interfaces wants to stop receiving traffic.

In response to membership reports from the interfaces, the router sends a Group-Specific or a Group-and-Source Specific query to the multicast interfaces. Each query is sent three times with a one-second interval in between each transmission to ensure the interfaces receive the query. For example, a router receives a membership report with a Source-List-Change record to block old sources from an interface. The router sends Group-and-Source Specific Queries to the source and group (S,G) identified in the record. If none of the interfaces is interested in the (S,G), it is removed from (S,G) list for that interface on the router.

Each IGMP V3-enabled router maintains a record of the state of each group and each physical port within a virtual routing interface. This record contains the group, group-timer, filter mode, and source records information for the group or interface. Source records contain information on the source address of the packet and source timer. If the source timer expires when the state of the group or interface is in Include mode, the record is removed.

Default IGMP Version IGMP V3 is available on devices running software release 07.8.00; however, HP devices are shipped with IGMP V2-enabled. You must enable IGMP V3 globally or per interface.

Also, you must specify what version of IGMP you want to run on a device globally, on each interface (physical port or virtual routing interface), and on each physical port within a virtual routing interface. If you do not specify an IGMP version, IGMP V2 will be used.

June 2005 11 - 83


Compatibility with IGMP V1 and V2 Different multicast groups, interfaces, and routers can run their own version of IGMP. Their version of IGMP is reflected in the membership reports that the interfaces send to the router. Routers and interfaces must be configured to recognized the version of IGMP you want them to process.

An interface or router sends the queries and reports that include its IGMP version specified on it. It may recognize a query or report that has a different version, but it may not process them. For example, an interface running IGMP V2 can recognize IGMP V3 packets, but cannot process them. Also, a router running IGMP V3 can recognize and process IGMP V2 packet, but when that router sends queries to an IGMP V2 interface, the host on that interface may not recognize the IGMP V3 queries. The interface or router does not automatically downgrade the IGMP version running on them to avoid version deadlock.

If an interface continuously receives queries from routers that are running versions of IGMP that are different from what is on the interface, the interface logs warning messages in the syslog every five minutes. Reports sent by interfaces to routers that contain different versions of IGMP do not trigger warning messages; however, you can see the versions of the packets using the show ip igmp traffic command.

The version of IGMP can be specified globally, per interface (physical port or virtual routing interface), and per physical port within a virtual routing interface. The IGMP version set on a physical port within a virtual routing interface supersedes the version set on a physical or virtual routing interface. Likewise, the version on a physical or virtual routing interface supersedes the version set globally on the device. The sections below present how to set the version of IGMP.

Globally Enabling the IGMP Version Using the CLI

To globally identify the IGMP version on an HP device, enter the following command:

ProCurveRS(config)# ip igmp version 3

Syntax: ip igmp version <version-number>

Enter 1, 2, or 3 for <version-number>. Version 2 is the default version.

Using the Web Management Interface You cannot set the IGMP version using the Web management interface.

Enabling the IGMP Version Per Interface Setting Using the CLI

To specify the IGMP version for a physical port, enter a command such as the following:

ProCurveRS(config)# interface eth 1/5 ProCurveRS(config-if-1/5)# ip igmp version 3

To specify the IGMP version for a virtual routing interface on a physical port, enter a command such as the following:

ProCurveRS(config)# interface ve 3 ProCurveRS(config-vif-1) ip igmp version 3

Syntax: [no] ip igmp version <version-number>

Enter 1, 2, or 3 for <version-number>. Version 2 is the default version.

Using the Web Management Interface

You cannot set the IGMP version using the Web management interface.

11 - 84 June 2005


Enabling the IGMP Version on a Physical Port Within a Virtual Routing Interface Using the CLI

To specify the IGMP version recognized by a physical port that is a member of a virtual routing interface, enter a command such as the following:

ProCurveRS(config)# interface ve 3 ProCurveRS(config-vif-3)# ip igmp version 2 ProCurveRS(config-vif-3)# ip igmp port-version 3 e1/3-e1/7 e2/9

In this example, the second line sets IGMP V2 on virtual routing interface 3. However, the third line set IGMP V3 on ports 1/3 through 1/7 and port e2/9. All other ports in this virtual routing interface are configured with IGMP V2.

Syntax: ip igmp port-version <version-number> ethernet <port-number>

Enter 1, 2, or 3 for <version-number>. IGMP V2 is the default version.

The ethernet <port-number> parameter specifies which physical port within a virtual routing interface is being configured.

Using the Web Management Interface

You cannot set the IGMP version using the Web management interface.

Enabling Membership Tracking and Fast Leave IGMP V3 provides membership tracking and fast leave to clients. In IGMP V2, only one client on an interface needs to respond to a router’s queries; therefore, some of the clients may be invisible to the router, making it impossible for the router to track the membership of all clients in a group. Also, when a client leaves the group, the router sends group specific queries to the interface to see if other clients on that interface need the data stream of the client who is leaving. If no client responds, the router waits three seconds before it stops the traffic.

IGMP V3 contains the tracking and fast leave feature that you enable on virtual routing interfaces. Once enabled, all physical ports on that virtual routing interface will have the feature enabled. IGMP V3 requires all clients to respond to general and group specific queries so that all clients on an interface can be tracked. Fast leave allows clients to leave the group without the three second waiting period, if the following conditions are met:

• If the interface, to which the client belongs, has IGMP V3 clients only. Therefore, all physical ports on a virtual routing interface must have IGMP V3 enabled and no IGMP V1 or V2 clients can be on the interface. (Although IGMP V3 can handle V1 and V2 clients, these two clients cannot be on the interface in order for fast leave to take effect.)

• No other client on the interface is receiving traffic from the group to which the client belongs.

Every group on the physical interface of a virtual routing interface keeps its own tracking record. However, it can track group membership only; it cannot track by (source, group).

For example, two clients (Client A and Client B) belong to group1 but each is receiving traffic streams from different sources. Client A receives a stream from (source_1, group1) and Client B receives it from (source_2, group1). The router still waits for three seconds before it stops the traffic because the two clients are in the same group. If the clients are in different groups, then the three second waiting period is not applied and traffic is stopped immediately. The show ip igmp group tracking command displays that clients in a group that are being tracked.

If a client sends a leave message, the client is immediately removed from the group. If a client does not send a report during the the specified group membership time (the default is 140 seconds), that client is removed from the tracking list.

USING THE CLI

To enable the tracking and fast leave feature, enter commands such as the following:

ProCurveRS(config)# interface ve 13 ProCurveRS(config-vif-13)# ip igmp tracking

Syntax: ip igmp tracking

June 2005 11 - 85




Setting the Query Interval The IGMP query interval period defines how often a router will query an interface for group membership. Possible values are 10 – 3,600 seconds and the default value is 60 seconds, but the value you enter must be a little more than twice the group membership time.

USING THE CLI

To modify the default value for the IGMP query interval, enter the following:

ProCurveRS(config)# ip igmp query-interval 120

Syntax: ip igmp query-interval <10-3600>

The interval must be a little more than two times the group membership time.


If available, you can use the Web management interface to configure query interval. For example, on 9300 series Chassis devices, log in to the Web management interface and go to the Configure -> DVMRP -> IGMP panel. Enter a value from 10 – 3600 in the Query Interval field. Refer to the Advanced Configuration and Management Guide for ProCurve 9300/9400 Series Routing Switches for details.

Setting the Group Membership Time Group membership time defines how long a group will remain active on an interface in the absence of a group report. Possible values are from 20 – 7200 seconds and the default value is 140 seconds.

USING THE CLI

To define an IGMP membership time of 240 seconds, enter the following:

ProCurveRS(config)# ip igmp group-membership-time 240

Syntax: ip igmp group-membership-time <20-7200>


If available, you can use the Web management interface to configure group membership time. For example, on 9300 series Chassis devices, log in to the Web management interface and go to the Configure -> DVMRP -> IGMP panel. Enter a value from 20 – 7200 in the Group Membership Time field. Refer to the Advanced Configuration and Management Guide for ProCurve 9300/9400 Series Routing Switches for details.

Setting the Maximum Response Time The maximum response time defines the maximum number of seconds that a client can wait before it replies to the query sent by the router. Possible values are 1 – 10. The default is 5.

USING THE CLI

To change the IGMP maximum response time, enter a command such as the following at the global CONFIG level of the CLI:

ProCurveRS(config)# ip igmp max-response-time 8

Syntax: [no] ip igmp max-response-time <num>

The <num> parameter specifies the maximum number of seconds for the response time. Enter a value from 1 –10. The default is 5.



11 - 86 June 2005


IGMP V3 and Source Specific Multicast Protocols Enabling IGMP V3 enables source specific multicast (SSM) filtering for DVMRP and PIM Dense (PIM-DM) for multicast group addresses in the 224.0.1.0 through 239.255.255.255 address range. However, if PIM Sparse is used as the multicast protocol, the SSM protocol should be enabled if you want to filter unwanted traffic before the Shortest Path Tree protocol switchover occurs for groups in the 232/8 range. Not configuring the SSM protocol in PIM Sparse may cause the switch or router to leak unwanted packets with the same group, but containing undesired sources, to clients. After SPT switch over, the leak stops and source specific multicast works correctly even without configuring the SSM protocol.

If the SSM protocol is not enabled and before the SPT switchover, the multicast router creates one (*, G) entry for the entire multicast group, which can have many sources. If the SSM protocol is enabled, one (S,G) entry is created for every member of the multicast group, even for members with non-existent traffic. For example, if there are 1,000 members in the group, 1,000 (S,G) entries will be created. Therefore, enabling the SSM protocol for PIM-SM requires more resources than leaving the protocol disabled.

Enabling SSM

USING THE CLI

To enable the SSM protocol on an HP device running PIM-SM, enter a command such as the following:

ProCurveRS(config)# router pim ProCurveRS(config-pim-router)# ssm-enable

Syntax: [no] ssm-enable

Enter the ssm-enable command under the router pim level to globally enable the SSM protocol on a Routing Switch.



Displaying IGMP V3 Information The sections below present the show commands available for IGMP V3.

Displaying IGMP Group Status

NOTE: This report is available on Routing Switches.

You can display the status of all IGMP multicast groups on a device by entering the following command:

ProCurveRS(config)# show ip igmp group Interface v18 : 1 groups

group phy-port static querier life mode #_src 1 239.0.0.1 e4/20 no yes include 19 Interface v110 : 3 groups

group phy-port static querier life mode #_src 2 239.0.0.1 e4/5 no yes include 10 3 239.0.0.1 e4/6 no yes 100 exclude 13 4 224.1.10.1 e4/5 no yes include 1

June 2005 11 - 87


To display the status of one IGMP multicast group, enter a command such as the following:

ProCurveRS(config)# show ip igmp group 239.0.0.1 detailDisplay group 239.0.0.1 in all interfaces.Interface v18 : 1 groups

group phy-port static querier life mode #_src 1 239.0.0.1 e4/20 no yes include 19 group: 239.0.0.1, include, permit 19 (source, life):

(3.3.3.1 40) (3.3.3.2 40) (3.3.3.3 40) (3.3.3.4 40) (3.3.3.5 40) (3.3.3.6 40) (3.3.3.7 40) (3.3.3.8 40) (3.3.3.9 40) (3.3.3.10 40) (3.3.3.11 40) (3.3.3.12 40) (3.3.3.13 40) (3.3.3.14 40) (3.3.3.15 40) (3.3.3.16 40) (3.3.3.17 40) (3.3.3.18 40) (3.3.3.19 40)

Interface v110 : 1 groups group phy-port static querier life mode #_src

2 239.0.0.1 e4/5 no yes include 10 group: 239.0.0.1, include, permit 10 (source, life):

(2.2.3.0 80) (2.2.3.1 80) (2.2.3.2 80) (2.2.3.3 80) (2.2.3.4 80) (2.2.3.5 80) (2.2.3.6 80) (2.2.3.7 80) (2.2.3.8 80) (2.2.3.9 80)

If the tracking and fast leave feature is enabled, you can display the list of clients that belong to a particular group by entering commands such as the following:

ProCurveRS(config)# show ip igmp group 224.1.10.1 tracking Display group 224.1.10.1 in all interfaces with tracking enabled. Interface v13 : 1 groups, tracking_enabled

group phy-port static querier life mode #_src 1 224.1.10.1 e4/15 no yes include 3

receive reports from 3 clients: 110.110.110.7 110.110.110.8 110.110.110.9

Syntax: show ip igmp group [ <group-address> [detail] [tracking] ]

If you want a report for a specific multicast group, enter that group’s address for <group-address>. Omit the <group-address> if you want a report for all multicast groups.

Enter detail if you want to display the source list of the multicast group.

Enter tracking if you want information on interfaces that have tracking enabled.

IGMP V2 and V3 statistics displayed on the report for each interface.

This Field

Group

Phy-port

Static

Querier

Displays

The address of the multicast group

The physical port on which the multicast group was received.

A “yes” entry in this column indicates that the multicast group was configured as a static group; “No” means it was not. Static multicast groups can be configured in IGMP V2 using the ip igmp static command. In IGMP V3, static sources cannot be configured in static groups.

“Yes” means that the port is a querier port; “No” means it is not. A port becomes a non-querier port when it receives a query from a source with a lower source IP address than the port.

11 - 88 June 2005


This Field

Life

Mode

#_src

Group:

Displays

Shows the number of seconds the interface can remain in exclude mode. An exclude mode changes to include mode if it does not receive an "IS_EX" or "TO_EX" message during a certain period of time. The default is 140 seconds. There is no "life" displayed in include mode.

Indicates current mode of the interface: Include or Exclude. If the interface is in Include mode, it admits traffic only from the source list. If an interface is in Exclude mode, it denies traffic from the source list and accepts the rest.

Identifies the source list that will be included or excluded on the interface.

If IGMP V2 group is in Exclude mode with a #_src of 0, the group excludes traffic from 0 (zero) source list, which means that all traffic sources are included.

If you requested a detailed report, the following information is displayed:

• The multicast group address

• The mode of the group

• A list of sources from which traffic will be admitted (include) or denied (exclude) on the interface is listed.

• The life of each source list.

If you requested a tracking report, the clients from which reports were received are identified.

Displaying the IGMP Status of an Interface


You can display the status of a multicast enabled port by entering a command such as the following:

ProCurveRS(config)# show ip igmp interface query interval = 60, max response time= 3, group membership time=140 v5: default V2, PIM dense, addr=1.1.1.2 e4/12 has 0 groups, non-Querier (age=40), default V2 v18: default V2, DVMRP, addr=2.2.2.1 e4/20 has 0 groups, Querier, default V2 v20: configured V3, PIM dense (port down), addr=1.1.20.1 v110: configured V3, PIM dense, addr=110.110.110.1 e4/6 has 2 groups, Querier, default V3

group: 239.0.0.1, exclude, life=100, deny 13group: 224.1.10.1, include, permit 2

e4/5 has 3 groups, Querier, default V3group: 224.2.2.2, include, permit 100group: 239.0.0.1, include, permit 10group: 224.1.10.1, include, permit 1

Syntax: show ip igmp interface [ ve | ethernet <number> <group-address>]

June 2005 11 - 89


Enter ve and its <number> or ethernet and its <number> to display information for a specific virtual routing interface or ethernet interface.

Entering an address for <group-address> displays information for a specified group on the specified interface.

The report shows the following information:

This Field

Query interval Displays how often a querier sends a general query on the interface.

Max response The maximum number of seconds a client can wait before it replies to the query.

Group membership time

(details)

Displaying IGMP Traffic Status

Displays

The number of seconds multicast groups can be members of this group before aging out.

The following is displayed for each interface:

• The ID of the interface

• The IGMP version that it is running (default IGMP V2 or configured IGMP V3)

• The multicast protocol it is running: DVMRP, PIM-DM, PIM-SM

• Address of the multicast group on the interface

• If the interface is a virtual routing interface, the physical port to which that interface belongs, the number of groups on that physical port, whether or not the port is a querier or a non-querier port, the age of the port, and other multicast information for the port are displayed.


To display the traffic status on each virtual routing interface, enter the following command:

ProCurveRS(config)# show ip igmp traffic Recvv5

QryV2 QryV3 G-Qry GSQry MbrV2 MbrV3 Leave 29 0 0 0 0 0 0

IsIN0 IsEX ToIN ToEX ALLOW BLK

0 0 0 0 0 v18 15 0 0 0 0 30 0 60 0 0 0 0 0 v110 0 0 0 0 0 97 0 142 37 2 2 3 2 Send QryV1 QryV2 QryV3 G-Qry GSQry v5 0 2 0 0 0 v18 0 0 30 30 0 v110 0 0 30 44 11

Syntax: show ip igmp traffic

The report shows the following information:

11 - 90 June 2005


This Field Displays

QryV2 Number of general IGMP V2 query received or sent by the virtual routing interface.

QryV3 Number of general IGMP V3 query received or sent by the virtual routing interface.

G-Qry Number of group specific query received or sent by the virtual routing interface.

GSQry Number of source specific query received or sent by the virtual routing interface.

MbrV2 The IGMP V2 membership report.

MbrV3 The IGMP V3 membership report.

Leave Number of IGMP V2 “leave” messages on the interface. (See ToEx for IGMP V3.)

IsIN Number of source addresses that were included in the traffic.

IsEX Number of source addresses that were excluded in the traffic.

ToIN Number of times the interface mode changed from exclude to include.

ToEX Number of times the interface mode changed from include to exclude.

ALLOW Number of times that additional source addresses were allowed or denied on the interface:

BLK Number of times that sources were removed from an interface.

Clearing IGMP Statistics To clear statistics for IGMP traffic, enter the following command:

ProCurveRS# clear igmp traffic

Syntax: clear igmp traffic

This command clears all the multicast traffic information on all interfaces on the device.

June 2005 11 - 91


11 - 92 June 2005

chapter 11 configuring ip multicast protocols (9300 series...

Documents