Current IP Multicast Commands ----------------------------- Change history 04/19/05 RFC3618 MSDP support, "ip "ip msdp rpf rfc3618", "show ip msdp rpf-peer" [CSCdx68618, 12.0(27)S, 12.2(25)S, 12.3(4)T] 11/30/04 "no ip pim dm-fallback" [CSCdw60902, 12.0(28)S, 12.3(4)T, 12.2(25)S] "show ip multicast" [CSCdy63575, 12.0(27)S, 12.0(20)S, 12.3(4)T] ip multicast rpf backoff ip multicast rpf backoff disable ip multicast rpf interval [CSCdv60125, 12.0(22)S, 12.2(13)E, 12.2(11)S, 12.2(15)T] 04/14/04 Alphabetical reordering of comands 03/10/03 Added description for the "threshold" argument to "ip multicast route-limit" [12.0(23)S, 12.2(13)T, 12.2(14)S, CSCdy16803]. 03/02/03 Subsecond convergence feature: Added description for "msec" option to "ip pim query-interval" and "debug ip pim hello". Updated description of "ip pim version". 01/03/03 Added description for commands introduced or modified by the SSM mapping feature: "ip igmp ssm-map enable", "ip igmp ssm-map query dns", "ip domain multicast ", "ip igmp ssm-map static ", "ip igmp static-group [ ... source ssm-map ]", "show ip igmp ssm-mapping [ ]" 10/13/02 Added desription for "priority " option for the "ip pim rp-candidate" command. See notes below for version numbering. [CSCdx59801, 12.0(23)S, 12.2S, 12.2(PI5)T] 10/13/02 Added desription on AutoRP and BSR interworking in Cisco IOS. See description of "ip pim bsr-candidate" and "ip pim send-rp-discovery". 08/16/02 Added description for "ip multicast route-limit " [12.1(2), 12.0(11)S, CSCdm84653] 08/05/02 Added description for CISCO-PIM-MIB feature, "snmp-server enable traps pim ...", "snmp-server host ..." [CSCdr38615, 12.0(15)S, 12.2(4)T] 08/05/02 Added description for IP multicast heartbeat feature, "ip multicast heartbeat", "debug ip mhbeat", and "snmp-server enable traps ipmulticast"[CSCdr40842, 12.1(3)T, 12.2]. 07/22/02 - Added "ip pim bidir-neighbor-filter" [CSCdx11884, 12.2(10) 12.2(10)S 12.2(10)T] 07/02/02 - Added "filter-autorp" to "ip multicast boundary" command and "debug ip pim autorp" [12.0(22)S, 12.2(8)] 05/23/02 - Added "show ip msdp sa-cache [rejected-sa [detail] [read-only]]" / "ip msdp cache-rejected-sa" (CSCdv13858) 05/03/02 - Added "ip pim sparse-mode-register" 10/06/01 - Added pointer to configuration note for "ip pim rp-announce-filter" 10/10/01 - Added description for IGMP immediate-leave (CSCdk29405, CSCdr27925) ip igmp immediate-leave (global, interface) 09/20/01 - Added description for CSCdm73649 commands: ip pim dense-mode proxy-register ip pim bsr-border 09/17/01 - Added description for "ip msdp sa-limit", updated documentation for "show ip msdp count", "show ip msdp peer", "show ip msdp count" [CSCdt19258]. 09/17/01 - Updated information on "ip msdp cache-sa-state" - mandatory now [CSCdr93446]. 08/29/01 - Added description about UDP/IGMPv3lite port number change 659 -> 465 due to CSCdr53615. 07/12/01 - Added documentation for "ip pim register-source", added notes 06/29/01 - Corrected documentation for ip multicast multipath 06/27/01 - Added documentation for ip pim bidir-enable 05/28/01 - Added documentation for ip pim dr-priority 05/28/01 - Added documentation for Bidir-PIM commands ip pim rp-address ... bidir ip pim send-rp-announce ... bidir ip pim rp-candidate ... bidir 05/17/01 - Added description for ip msdp sa-filter RP matching options 05/09/01 - Added documentation for source option to "ip igmp static-group" 05/09/01 - ip pim spt-threshold note added. 05/09/01 - Added SSM / IGMP version 3 feature documentation: ip igmp version 3, ip pim ssm, ip urd, ip igmp v3lite, show ip igmp group detail, debug ip urd Notes: The text in brackets after the description of a command details the releases and sometimes also the ddts number in which this command appeared. The versions shown are only those where a command was explicitly added to the code, but in addition to that, the command will also be available on all further IOS version that inherit from one one the shown IOS versions: 12.0S, 12.0T inherits from 12.0 12.1 inherits from 12.0T 12.1E, 12.1T inherits from 12.1 12.2 inherits from 12.1T 12.2T inherits from 12.2 12.2T inherits from 12.2 12.2S inherits from 12.2 and 12.1E 12.3 inherits from 12.2T For features documented here before they are released on CCO (in support of EFT testers), the final CCO version numbers are not always known. The following abbreviations are used: 12.X(PIy)T - the y'th maintenance release of Cisco IOS 12.XT on CCO Example: 12.2(PI5)T is the fifth maintenance release of 12.2T after the first four which are 12.2(2), 12.2(4)T, 12.2(8)T, 12.2(11)T) 12.2S - Release numbers for 12.2S images will be added later. ------------------------------------------------------------------------ Global commands ------------------------------------------------------------------------ [no] ip domain multicast Configure this command to change the domain prefix used by IOS for the DNS based SSM mapping. By default this prefix is "in-addr.arpa". When a Cisco IOS router tries to do DNS based SSM mapping for an IP group address G = G1.G2.G3.G4, it queries the name server for IP address ressource records ("IP A" RR's) for the following fully qualified domain name: G4.G3.G2.G1. See also ftp://ftpeng.cisco.com/ipmulticast/config-notes/ssm-map.txt for more information. [CSCdx32173, 12.3(1)T]. [no] ip dvmrp distance Configures the default adminstrative distance for received DVMRP routes. This command should be used so routes advertised from the unicast routing table that are reflected back through DVMRP cause the original unicast routes to continue to be advertised. The "ip dvmrp accept-filter" command may override this value when specified on an interface. [11.2] [no] ip dvmrp route-limit This command limits the number of DVMRP routes advertised over an interface enabled to run DVMRP. That is a DVMRP tunnel, an interface where a DVMRP neighbor has been discovered, or an interface configured to run "ip dvmrp unicast-routing". The default value is 7000. This command will be automatically generated to the configuration file when at least one interface is enabled for multicast routing. This command is necessary so misconfigured "ip dvmrp metric" commands don't cause massive route injection into the MBONE. The "no" version of the command configures no limit. [11.0] [no] ip dvmrp routehog-notification This configures the number of routes allowed within an approximate one minute interval before a syslog message is isssued warning that there maybe a route surge going on in the MBONE. This is typically used to detect quickly when someone has misconfigured their routers to inject a large number of routes into the MBONE. The default value is 10,000. You can find a running count in the "show ip igmp interface" display. When the count is exceeded, you'll see an "*** ALERT ***" string appended to the line. [10.2] ip igmp immediate-leave group-list no ip igmp immediate-leave Use this command to reduce the leave latency of IGMP memberships to zero when IGMP version 2 is in use and only a single receiver host is connected to each interface: If this command is not configured, the router will operate the normal IGMP version 2 leave process: It will send out a group specific query upon receipt of an IGMP version 2 leave message to learn if more hosts are interested in receiving this group. The router can then only stop forwarding traffic for the group if no host replies within the timeout resulting in a leave latency of around 2 to 3 seconds. If this command is configured, then the router assumes that only one host was joined to the group and stops forwarding the groups traffic immediately. Forwarding for only those groups is affected by this commands which are allowed by the standard or named standard access list . Use to limit the effect of this command to group ranges known to be receivable by only one host on each interface even if there may be multiple hosts. This command does not change the leave latency if IGMP version 3 is in effect for the group. To reduce the the leave latency with IGMP version 3, use the explicit tracking support for IGMP version 3. This command will take no effect on interfaces where IGMPv1 hosts are present. The global version of the immediate-leave command can not be used together with the per-interface immediate-leave command. You must either use one global configuration command or per-interface commands. When the global command is configured, the per-interface immediate-leave commands will be removed from the configuration and newly entered interface immediate-leave commands will silently be ignored. [CSCdr27925, 12.2(4)] This command was available in pre-IOS 12.2 versions as a hidden command and is thus unsupported in those releases. [CSCdk29405, 12.0(4)] [no] ip igmp ssm-map enable Configuring this global command enables the SSM mapping feature for groups in the configured SSM range. By default, this command is not enabled. SSM mapping is a feature that takes IGMP version 1 or IGMP version 2 membership reports for a group G and converts them into IGMP version 3 (S,G) membership reports by looking up one or more sources associated with the group G via DNS or static configured entries. Default is to use DNS. SSM mapping is compatible with the other two Cisco IOS SSM transition solutions URD and IGMP v3lite. See also ftp://ftpeng.cisco.com/ipmulticast/config-notes/ssm-map.txt for more information. [CSCdx32173, 12.3(1)T]. [no] ip igmp ssm-map query dns This global configuration command enabled DNS based SSM mapping. It is by default enabled whenever "ip igmp ssm-map enable" is configured. Disable this command to inhibit DNS based SSM mapping If disabled, only statically mapped SSM sources via "ip igmp ssm-map static" will be determined. The domain used to look up mappings is determined by the command "ip domain multicast ". See also ftp://ftpeng.cisco.com/ipmulticast/config-notes/ssm-map.txt for more information. [CSCdx32173, 12.3(1)T]. [no] ip igmp ssm-map static Use this command to configure static SSM mappings. If SSM mapping is globally enabled via the "ip igmp ssm-map enable" command and the router receives an IGMP membership for group G in the SSM range, it will try to determine the source address(es) associated with G by walking the configured "ip igmp ssm-map static commands". If G is permitted by , then is taken. If multiple configured "ip igmp ssm-map static" lines are configured and G is permitted by multiple , then the arguments of all matching will be used (up to a limit of 20). Only if no matching "ip igmp ssm-map static" lines matched, will SSM mapping query the DNS for address mapping (see "ip domain multicast" and "ip igmp ssm-map query dns"). See also ftp://ftpeng.cisco.com/ipmulticast/config-notes/ssm-map.txt for more information. [CSCdx32173, 12.3(1)T]. [no] ip multicast cache-headers [rtp] [] Allocates a circular buffer to store IP multicast packet headers that are received by the router. This command will allocate approximately a 32 kilobyte buffer. If you are low on memory, this command should not be used. Use the "show ip mpacket" command to display this buffer. This feature is used to determine 1) who is sending to what groups, 2) what the inter-packet delay and 3) if there are any duplicates or multicast forwarding loops in your network. [11.1] When the keyword "rtp" is used, RTP headers will also be saved. This is used in conjuction with the "show ip mpacket quality" command. [11.1(20)CC] is the power-of-2 number of cache entries maintained in the circular buffer. Valid values are 10 through 20. Use caution when setting this value greater than 10 because you can use up all the memory in the router. The default value is 10, which means 1024 entry circular buffer is maintained. [11.1(22)CC, 12.0S] ip multicast heartbeat [no] ip multicast heartbeat This featurette allows you to monitor existing ip multicast traffic via SNMP traps. It command is a simple but effective alternative to MRM. ionfigure this command to receive an SNMP traps when ip multicast group has not been forwarding traffic during at least out of the last intervals of length should be set to multiple of 10 seconds on platforms that use MDFS because on those platforms, the packet counters are only updated once every 10 seconds (Cisco-7500, Cisco-12000). Other platforms may have other increments (Cisco-6500). This command will not create a heartbeat if no multicast forwarding state exists for at all in the router. This command will not create state in the router. Use "ip igmp static-group" on this or a downstream router to force forwarding of ip multicast traffic. You need to enable trap generation for ip multicast globally via the "snmp-server enable traps ipmulticast" for this command to be effective. Use the "snmp-server host ... ipmulticast" command to enable sending of ipmulticast traps to specific receiver hosts. Use "debug ip mhbeat" to debug operations of this command. Example: snmp-server enable traps ipmulticast ip multicast heartbeat 224.0.1.53 2 5 10 The router will sample the packets forwarded for group 224.0.1.53 in intervals of 10 seconds. If at least one packet was forwarded during 2 out of the last 5 intervals, no trap will be generated. Only if the router did not see packets being forwarded during 3 or more of these 10 second intervals will a trap be generated. Note: Multicast heartbeat considers the counter on both the (*,G) and all (S,G) state of a group being tracked. An increment in the counters of any such state is considered to constitute forwarding for the group in the interval. The SNMP trap triggered by this command is ciscoIpMRouteMissingHeartBeats defined in CISCO-IPMROUTE-MIB. See ftp://ftpeng.cisco.com/ipmulticast/config-notes/mib-info.txt for more information about the MIB. See ftp://ftpeng.cisco.com/ipmulticast/mibs for the MIBs themselves. [CSCdr40842, 12.1(3)T, 12.2] [no] ip multicast multipath By default, this command is not enabled, and the RPF neighbor for all (*,Gi) with a certain RP and all (Si,G) with a certain Si is the PIM neihgbor with the highest IP address if there are multiple equal-cost alternatives for RP or Si. If this command is enabled, then the RPF neighbor will be selected pseudo-randomnly from the available equal-cost RPF neighbors, resulting in load splitting of traffic from different sources amongst the available equal cost paths (or neighbors). All traffic from a single source is still received from a single neighbor [12.0, 12.0S, 12.0T] [no] ip multicast route-limit [] Configure this command to limit the total number of (*,G) and (S,G) multicast routing table entries as shown in "show ip mroute" to . Use this command to limit the impact of Denial of Service attacks based on creating useless IP multicast routing state. Valid arguments are 1... 2,147,483,646. "no ip multicast route-limit" establishes a multicast route-limit of 2,147,483,647 (the maximum 32-bit integer value). This is also the default configuration and it will not show up in the configuration. If the router needs to create a new multicast routing table entry but has exceeded the number of configured , a warning level log messae will be emitted: " routes exceeded multicast route-limit of " can be larger than if you configured "ip multicast route-limit " when he router already had more routes than installed. In that case the router will not remove already existing routes (you can force deletion of routes with "clear ip mroute"). The currently configured value is also displayed in the "show ip mroute count" command. [12.1(2), 12.0(11)S, CSCdm84653] If the optional argmument is configured, Cisco IOS will start emitting warning messages as soon as at least mroutes are established: "multicast route-limit warning (curr threshold ) - VRF ", Establishing a lower threshold than limit allows for the network operator to be alerted before the actual user will see any limitation [12.0(23)S, 12.2(13)T, 12.2(14)S, CSCdy16803]. [no] ip multicast-routing [distributed] Enables IP multicast forwarding. If disabled, group addressed IP packets that the router is not a member will be discarded. The default value is IP multicast routing disabled. [10.2] The distributed keyword will enable distributed fastswitching for the router. The interface command described below will enable individual interfaces for distributed fastswitching. [11.1(20)CC]. ip multicast rpf [vrf ] backoff [no] ip multicast rpf [vrf ] backoff disable [no] ip multicast rpf [vrf ] interval [ list | route-map ] When a route (unicast routing table, static-mroute, MBGP, BGP, DVMRP) towards a source or RP changes, PIM must join towards the new best RPF neighbor. In the past, PIM periodically polled the routing tables for changes every 5 seconds. In IOS releases where this command is supported, PIM RPF failover is instead triggered by changes in the routing tables. Once triggered, PIM will back off for a minimum of msec. If the the back-off period expires without further routing table changes, PIM will then scan for routing changes and accordingly establish multicast RPF changes. If instead more routing changes happen during the back-off period, PIM will double the back-off period to avoid thrashing the router with PIM RPF changes while the routing table is still converging. The maximum back-off period is configured via the parameter (also in milliseconds). The back-off time will be reset to if an entire back-off period has expired without routing changes. If not configured, then defaults to 50 msec and defaults to 5000 msec. With the default, the new RPF change behavior will thus be backward compatible (5 second RPF check interval) in the worst case (frequent route-changes) and down to 50 msec in stable networks with only unplanned routing changes. You normally do not need to change this commands defaults unless you have frequent route changes in your router (for example on a dial-in router), and you either want to reduce the maximum rpf check interval (for faster availability of ip multicast on newly established routes) or you want to increase the maximum rpf-check interval (to reduce CPU load introduced by the RPF check). [CSCdv60125, 12.0(22)S, 12.2(13)E, 12.2(11)S, 12.2(15)T] [no] ip pim accept-register list | route-map Configures where Register messages are accepted from. This command is used only in candidate RPs. If "list " is used, you can configure an extended access-list which determines which (source, group) pairs will be permitted or denied when seen in a Register message. If "route-map " is used, you can apply typical route-map operations on the route for the source address which appears in a Register message. Both keywords "list" and "route-map" are not allowed together. When a Register message is denied, an immediate Register-Stop is sent back to the originator of the Register. [12.0, 12.0S, 12.0T] [no] ip pim accept-rp {
| auto-rp} [] When this command is entered, the router will only accept (*,G) Joins with an RP address of
if G is in the group range specified by . When this command is entered with an address equal to one of the system's addresses, the system will be the RP only for the specified group range specified in . When not in the group range, the RP will not accept Joins or Register messages and will respond immediately to Registers with Register-Stop messages. There is no default setting for this command. [10.2] When the keyword "auto-rp" is specified, Join and Register messages will only be accepted for RPs that are in the Auto-RP cache. [11.1] If
is 0.0.0.0, the filter will accept any RP for any group accepted by , and deny any RP rejected by . When multiple "ip pim accept-rp" filters are configured, they must be configured in the following order (in 11.3(4.5), 12.0(1) and newer images the following order is guaranteed by the IOS, irrespective of the configuration sequence): ip pim accept-rp ip pim accept-rp auto-rp ip pim accept-rp 0.0.0.0 The following example will accept 171.69.58.88 as the RP for groups in 239.0.0.0/8, and RPs for groups in the Auto-RP cache. If the RP and group don't match the first two filters, the 3rd filter is in effect, i.e. any RP is accepted for groups permitted by ACL 2, and no RP for 224.0.1.39 and 224.0.1.40 is accepted. ip pim accept-rp 171.69.58.88 1 ip pim accept-rp auto-rp ip pim accept-rp 0.0.0.0 2 access-list 1 permit 239.0.0.0 0.255.255.255 access-list 2 deny 224.0.1.39 access-list 2 deny 224.0.1.40 access-list 2 permit any [no] ip pim bidir-enable This global configuration command enables support for Bidir PIM on the router. If not enabled, then The router will behave like a legacy IOS router that does not support Bidir-PIM: The PIM Hello messages will not contain the Bidir option, the bidir options to the rp configuration commands will not be allowed, no Bidir-PIM DF election messages will be sent and received messages will be ignored, CLI commands for bidir will not work. This command exists to avoid potential issues when upgrading routers to images supporting Bidir-PIM. The default for this command in 12.0ST is "no ip pim bidir-enable", the default for 12.2 and 12.2T is "ip pim bidir-enable". [CSCdu53264, 12.0(18)ST, 12.2(2), 12.2(3)T] [no] ip pim bsr-candidate [] Configures the router to send bootstrap messages with 's address as the bootstrap-router (BSR) address, if no better bootstrap router is found. must be a PIM enabled interface. is the mask length used by the PIMv2 hash function. This hash mask length is accepted by all routers within the same PIM domain when selecting an RP. is an integer whose value is between 0 and 255. It is 0 by default. BSRs with larger preference values are preferred over those with smaller values. This command should only be used in "backbone" routers with good connectivities to all parts of the PIM region. E.g. a stub router that relies on an on-demand dial-up link to connect to the rest of the PIM domain is not a good candidate BSR. [11.3T] The BSR mechanism is specified in RFC2362. Candidate RP routers unicast C-RP-Advertisement packets to the BSR. The BSR aggregates these advertisements into Bootstrap messages which it regularily multicasts. Multicasting of these messages is special, they are hop-by-hop RPF-flooded, so they do not require any pre-existing IP multicast routing setup (unlike AutoRP). The BSR does not preselect the designated RP for a particular group range (unlike AutoRP), but instead, each router receiving Bootstrap messages will elect RPs for group ranges based on the information in the Bootstrap messages. Cisco IOS routers (12.0 and later) always accept and process Bootstrap messages. There is no command to disable this function. Cisco IOS routers perform the following steps to determine which RP for a group is actually to be used: 1. Longest match lookup on the C-RPs announced group prefix (This is incompatible with RFC2362 but in compliance with the new PIM v2 spec, eg: draft-ietf-pim-sm-v2-new-05, 4.8.1 (p100)) 2. If there are both AutoRP and a BSR learned C-RPs for the prefix found in 1., prefer the AutoRP learned C-RP. The following steps will then not be exercised as they are specific to BSR C-RPs. 3. If more than one BSR-learned C-RP are found in 1., prefer the one with the highest priority (lowest numerical configured via "ip pim rp-candidate ... priority "). 3. If more than one BSR learned C-RP have the same priority, use the BSR hash function to select the RP for a group. 4. If more than one BSR learned C-RP return the same hash value from 3., use the C-RP with the highest IP address from them. Note: Step 3. was defect before CSCdx59801. See description of "ip pim rp-candidate" below. A Cisco IOS BSR router will redistribute AutoRP learned prefixes in Bootstrap messages. If the BSR router knows for a given group prefix both AutoRP and BSR C-RPs, then it will only announce the (best) AutoRP RP via Bootstrap messages but not any BSR learned C-RPs (for this group prefix). In result, the router consistenly announces via BSR the same C-RPs that it also uses for itself (as explained in the previous paragraph). This behavior is independent of wether or not the BSR router is also an AutoRP mapping agent. no ip pim [vrf ] dm-fallback By default, multicast groups in Cisco IOS IPv4 multicast do revert from Sparse Mode or Bidir Mode to Dense-Mode when all RP information is lost - eg: when there is no AutoRP nor BSR announcement for the group and no static RP configured. Configure this global configuration command to change this behavior so that groups revert to Sparse Mode with an RP-address of 0.0.0.0 if RP information is lost. This configuration will also be automatically created by Cisco IOS automatically if all interface in a VRF are configured for "ip pim sparse-mode" because then the router would not route traffic for Dense Mode groups anyhow. When groups revert to an RP-address of 0.0.0.0, the RPF interface of the (*,G) is set to Null, which inhibits any traffic forwarding for the (*,G) (RPF failure). Existing (S,G) state for the group is still maintained and forwarding, but traffic for new sources is not forwarded. In addition to avoiding Dense Mode fallback you can thus also use this command easily to inhibit forwarding of traffic for any groups that are not explicitly configured to be in Sparse-Mode, Bidir-Mode or SSM. Notes: - This command does not affect the behavior of groups configured for SSM. - To maintain the AutoRP groups 224.0.1.39/224.0.1.40 in Dense-Mode, use the global configuration command "ip pim autorp listener" - Because Bidir PIM groups will revert either to Dense Mode (default) or Sparse Mode (with this command configured) upon loss of all RP information, it is recommended to always use static-RP configuration (with or without redundancy) if business critical Bidir-PIM support is required. See http://www.cisco.com/warp/public/732/Tech/multicast/docs/bidirdeployment.pdf - Use "show ip multicast" to see whether no dm-fallback is configured or auto-enabled. See also: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_4/gtautorp.htm [CSCdw60902, 12.0(28)S, 12.3(4)T, 12.2(25)S] [no] ip pim register-rate-limit Sets a limit on the maximum number of data registers/second sent for each (S,G). If this is configured on a PIM domain border, a recommended is 2. [11.3T, 11.1(20)CC] [no] ip pim register-source By default this command is not configured and routers who are DR and need to send PIM sparse mode register messages will use the ip address of the interface towards the RP as the source address for these register messages. If that interface address is one that the RP can not reach (scoped or anycast address), then the PIM sparse mode registration process will malfunction because the RPs register-stop messages will not reach the DR. Configure ip pim register-source in global configuration command to make this router use the ip address of as the source address of PIM sparse-mode register messages if you need to avoid such problem. [CSCdm95268, 12.1(1)] [no] ip pim rp-address [] [override] [bidir] Configures the PIM Rendezvous Point (RP) address for a particular group. The RP address is used by first-hop routers to send Register packets on behalf of source multicast hosts. The RP address is also used by routers on behalf of multicast hosts that want to become members of a group. These routers send Join and Prune messages toward the RP. A single RP can be configured for multiple groups described by the access-list pointer. [10.2] If keyword "bidir" is supplied, the group range will be used for bidirectional shared-tree forwarding otherwise it will be used for sparse mode forwarding. A single can only be configured to be RP for either bidir or sparse mode group ranges. [12.1(2)T, 12.2] If there is no RP configured for a group, the router will treat the group as dense using the dense-mode PIM techniques. If the RP for a group is learned through a dynamic mechanism, such as Auto-RP, then this command may not be required. If there is a conflict between the RP configured with this command and one learned by Auto-RP, the Auto-RP information is used. Unless, the "override" keyword is specified. [11.1] [no] ip pim rp-announce-filter rp-list group-list This command is entered in the PIM RP-mapping agent. This command configures an incoming filter for RP announcement messages. Parameter "rp-list " configures an access-list of RP addresses that, if permitted, will be filtered for the group ranges denies by the parameter "group-list ". If this command is not configured, all RP announcements are accepted. If you are going to use more than one RP-mapping agent, the filters should be consistent among them so there is no conflicts between different mapping agents. [11.1] For more detailed explanations and examples see: ftp://ftpeng.cisco.com/ipmulticast/config-notes/rp-announce-filter.txt [no] ip pim rp-candidate [group-list ] [priority ] [bidir] Configures to send pim version 2 candidate RP advertisement to the bootstrap RP. The IP address associated with will be advertised as the candidate RP address. The group prefixes defined by simple access-list will also be advertised in association with the RP address. RP-candidates should also be placed in the well-connected "backbone" part of the PIM domain. [11.3T] If the keyword "bidir" is supplied, the group range will be used for bidirectional shared-tree forwarding otherwise it will be used for sparse mode forwarding. A single interface can only be RP for one type of groups, bidir or sparse mode. Use different arguments if you want to use a single router as an RP for both bidir-PIM and sparse mode group ranges. [12.1(2)T, 12.2] If the option "priority " is used, then the router will announce himself to be a candidate RP with priority . The default for is 0 and is not NVgened. For this option to work, the candidate BSRs must also run a Cisco IOS version supporting this option. BSR routers running previous Cisco IOS versions ignored the priority field in candidate RP announcements and forwarded a priority of 0 for all candidate RPs in their Bootstrap messages. 0 is the highest priority, 255 is the lowest priority. See "ip pim bsr-candidate" for a description of the selection process on the BSR. [CSCdx59801, 12.0(23)S, 12.2(PI5)T, 12.2S]. [no] ip pim send-rp-announce scope group-list [interval ] [bidir] This command sends an Auto-RP RP annoucement message to the well known group CISCO-RP-ANNOUNCE (224.0.1.39). This command should be used in a router you want to be the RP. The RP address field inside the announcement message will contain the IP address from the . is the time-to-live in the IP header which is set. This allows for the announcements to stay inside a ttl scoped boundary. is an access-list describing the group ranges this system is willing to be the RP for. Note that the deny clauses in the are ignored. [11.1] If keyword "bidir" is supplied, the group range will be used for bidirectional shared-tree forwarding otherwise it will be used for sparse mode forwarding. In AutoRP, a single IP address can only be RP for one type of groups, bidir or sparse mode. Use different arguments if you want to use a single router as an RP for both bidir-PIM and sparse mode group ranges and want to use Auto-RP to announce these mappings. [12.1(2)T, 12.2] Starting with IOS versions [12.0(1.1)], if the access-list contains a "deny" entry, auto-rp will maintain a negative entry for those group ranges. This will make it easier to configure group ranges to be dense-mode only groups. An RP announcement with a denied group prefix overrides any positive announcements for the same prefix from other RPs. However, IOS versions prior to this required a deny clause. The access-list must be changed to remove these deny clauses to obtain the correct RP map. When "interval" is specified, the interval between RP announcements is set to . The total holdtime of the RP announcements is automaticly set to 3 times . The default interval is 60 seconds. Tuning this interval down can reduce the time required to fail over to a secondary RP, at the expense of generating more Auto-RP messages through the entire region covered by the ttl scope. [11.2(18), 11.3(8), 12.0(3.1)] [no] ip pim send-rp-discovery [] scope By entering this command, an AutoRP RP-mapping agent is started on the router. The RP-mapping agent listens on well-known group address CISCO-RP-ANNOUNCE for announcements from candidate RPs. The RP-mapping agent will send RP-to-group mappings in an Auto-RP RP discovery message to the well known group CISCO-RP-DISCOVERY (224.0.1.40). PIM DRs will listen to this group and use the RPs they learn from the RP discovery message. is the time-to-live in the IP header which is set. This allows for the discovery messages to stay inside a ttl scoped boundary. [11.1] When is specified, RP discovery messages will be sourced from the IP address assigned to , otherwise the source address will be that of the outgoing interface from which the packet is sourced. If you do not specify this option and the mapping agent has multiple interfaces, and in addition, the network is also redundant then DR routers will see mappipng agent messages from multiple different interface addresses of the mapping agent - which can be confusing in troubleshooting (but is otherwise uncritical) [12.0] Am AutoRP RP mapping agent will only sends out announcements from RPs learned via announcements from routers using AutoRP (eg: with "ip pim send-rp-announce" discovered). It will not redistribute BSR learned candidate RP information. On the other hand, a Cisco IOS router configured as a BSR will redistribute AutoRP learned information (see description of "ip pim bsr-candidate"). We do only redistribute learned mappings in one direction (AutoRP to BSR) to avoid otherwise endlessly looping C-RP announcements between AutoRP and BSR. [no] ip pim spt-threshold | infinity [group-list ] Configures when a PIM leaf router should join the shortest path source-tree for the specified group. is the traffic rate in kilobits per second. If a source sends at a rate greater than or equal to , a PIM Join message is triggered towards the source to construct a source-tree. If "infinity" is used, all sources for the specified group will use the shared-tree. Specifying a "group-list" indicates what groups the spt-threshold applies to. is a reference to a simple IP access-list. When a value of 0 is specified or the group-list parameter is not used, the threshold applies to all groups. The default setting (when this command is not used), is to join the shortest path tree immediately after the first packet arrives from a new source. [11.1] The ability to define an spt threshold value other than 0 or infinity is deprecated. It should not be used and may not be supported in further releases [05/01]. [no] ip pim ssm [ default | range ] Configure the SSM-range. If the argument default is configured, then the range 232.0.0.0...232.255.255.255 will be used as the SSM-range. If range is configured than must be a numeric or named standard ip access list defining the SSM-range - all ip addresses permitted by will be considered to be within the SSM-range. The SSM-range is the range of addresses, in which the router will support Source Specific Multicast (SSM) operations: Receiver hosts use IGMP version 3, URD or IGMP v3lite to explicitly join to an (S,G) channel to receive traffic directly via the shortest path from the source. [12.1(5)T, 12.2, 12.0(15)S, 12.1(8)E] [no] ip pim state-refresh disable Disables PIM-DM State-Refresh message processing and forwarding. A router configured with this command will behave like a non-State Refresh capable router and will not advertise the SR-capability in PIM Hello messages. By default, State-Refresh processing and forwarding is enabled. [12.1(3)T] [no] ip mroute [] [route-map ] | [] Configures a multicast static route (called a "static mroute"). When a source range is specified, the mroute applies only to those sources. When is specified, the mroute applies to those sources that have been learned by the corresponding routing process. If route-map is specified, further classification can be accomplished by the match clauses from . If the mroute is selected, the address dictates the incoming interface for the source that matches the mroute. If the is a PIM neighbor, PIM Joins, Grafts, and Prunes will be sent to it. The can be a host address of a directly connected router or a route. When it is a route, a recursive lookup is done from the unicast routing table to find a directly connected neighbor. If is not specified, is used as the incoming interface. is used to decide if a unicast route, a DVMRP route, or a static mroute should be used for the RPF lookup. The lower distances have better preference. If the static mroute has the same distance as the other two RPF sources, the static mroute will take precedence. There are only two exceptions to this rule, directly connected routes and the default unicast route. Default is 0. Static mroutes are local to the router and are not redistributed by any dynamic routing protocol. [11.0] [no] ip sdr cache-timeout The amount of time an sdr cache entry stays active in the cache. A value a 0 indicates the entry will never timeout. The default value is 24 hours. [11.2] [no] snmp-server enable traps ipmulticast Configure this command globally to enable generation of SNMP traps for ip multicast. Currently, this is only qassociated with the traps generated by the "ip multicast heartbeat" command. [CSCdr40842, 12.1(3)T, 12.2]. [no] snmp-server enable traps pim [ { neighbor-change | rp-mapping-change | invalid-pim-message }] Configure this command globally to enable generation of SNMP traps for the CISCO-PIM-MIB. If the "neighbor-change" option is included, traps will be generated when a PIM interface is enabled or disabled or when a PIM neighbor adjacency expires or is established. If the "rp-mapping-change" option is included, traps will be generated if changes in the RP mapping state happen due to AutoRP or BSR messages. If the "invalid-pim-message" option is included, traps will be generated if invalid PIM messages are received. Use the "snmp-server host ... pim" command to enable sending of PIM traps to specific receiver hosts. See CISCO-PIM-MIB.my definition file for the format of the traps. ftp://ftpeng.cisco.com/ipmulticast/config-notes/mib-info.txt. [CSCdr38615, 12.0(15)S, 12.2(4)T] [no] snmp-server host traps [...] [ipmulticast | pim | ... ] Use this command to configure which host will receive which type of SNMP traps. [CSCdr40842, 12.1(3)T, 12.2], [CSCdr38615, 12.0(15)S, 12.2(4)T] ------------------------------------------------------------------------ IS-IS and OSPF Router commands ------------------------------------------------------------------------ [no] mpls traffic-eng multicast-intact MPLS TE (traffic engineering) tunnels can not be used to convey PIM protocol traffic because theses tunnels are unidirectional in nature. This command allows for coexistance of PIM and MPLS TE tunnels by using native hop-by-hop transport for PIM protocol packets, even though the unicast routing is using MPLS TE tunnels. Configure this command under router IS-IS or router OSPF to enable the MPLS TE and PIM interworking for routes of the appropriate routing protocol (OSPF and/or IS-IS). By default, this command is disabled. [12.0(7)S,12.1(2)T, 12.1(2) via CSCdm63234] ------------------------------------------------------------------------ Interface subcommands: ip igmp immediate-leave group-list no ip igmp immediate-leave Use this command to reduce the leave latency of IGMP memberships to zero when IGMP version 2 is in use and only a single receiver host is connected to each interface. Please refer to the documentation for the global configuration command "ip igmp immediate-leave" for more details [no] ip igmp join-group Informs the router to join group on the interface. IP packets that are addressed to this group address will be passed up to the IP client process in the router as well forwarded out the interface. If you do not want packets forwarded out the interface, join the group on a loopback interface. Packets are not sent on the loopback interface. [10.2] [no] ip igmp [vrf ] static-group [ source | source ssm-map ] [no] ip igmp [vrf ] static-group "*" Use this interface configuration command to statically forward traffic for the multicast group onto this interface. Using this commands, packets to the group will get fastswitched or hardware switched (whatever is available on the platform), unlike the "ip igmp join-group" command which will cause packets for the group to become process switched. [11.2] If the "*" keyword is present, then the interface will be placed by default into all newly created mroute entries. It will not create new state where there was none before. Note that this means that prunes will be ignored when received on the interface. This option is mostly meant to flood triffc to certain interfaces without join signalling like on a satellite headend router. [12.0T] The "source " option is in support of SSM. It allows to statically forward a (,) channel out of the interface. This option does require for to be within the configured SSM range. [12.0(15)S, 12.2(1)]. The "source ssm-map" option was introduced for the SSM mapping feature. If configured, then SSM mapping will be used to determine the source(s) associated with this group and the resulting (, ) channels will then statically be forwarded. Like "source " this option also requires to be n the configured SSM range. Use this command if you want to statically forward SSM traffic for certain group(s), but you want to let the DNS based SSM mapping determine the source addresse(s) of the channels. [CSCdx32173, 12.3(1)T] [no] ip igmp query-interval Configures the frequency of IGMP Host-Query packets transmitted. A designated router for a LAN is the only router that transmits queries. For IGMPv1, the designated router is elected according to the multicast routing protocol that runs on the LAN. For IGMPv2, the designated querier is the lowest IP addressed multicast router on the subnet. The default value is 60 seconds. [10.2] [no] ip igmp last-member-query-interval Configures the "last member query interval" to be , in milliseconds. The default value is 1000 ms, or 1 second. A value below 1 second can result in faster IGMP leave actions. [12.0] [no] ip igmp access-group Configures what groups are allowed on the interface. The default is all groups are allowed. [10.2] [no] ip igmp version 3 | 2 | 1 Interface subcommand to change IGMP version. Default is version 2. [11.1] IGMP version 3 enabled receiver applications to signal (S,G) channel membership in support of SSM. Enable IGMP version 3 on all interfaces connected to receivers, if SSM is needed [12.1(5)T, 12.0(15)S, 12.2] [no] ip igmp v3lite Configure this command on interfaces connected to receiver hosts if you are using SSM and users may run applications on older host operating systems that do not yet support IGMP version 3 directly. IGMP v3lite enables the router to accept UDP (port 659) encapsulated IGMP version 3 application specifically compiled to support older operating systems (like IP/TV 3.2 and later). [12.1(5)T, 12.0(15)S, 12.2]. See the following URL for library needed to compile applications for IGMPv3lite. This is called the HSIL (Host Side IGMP Library): http://www.talarian.com/products/multicastlite/index.shtml The port used by igmp v3lite was changed to UDP port 465 via CSCdt68756 (See Release Notes for the ddts on CCO for more explanations). The HSIL will default to this new port in version 1.1 and later [12.2(4)M/B/T, 12.0(19)S/ST, 12.1(8a)E02]. [no] ip urd [proxy] Configure this command on interfaces connected to receiver hosts if you are using SSM and users may run applications that by themselves do not support IGMP version 3 yet. URD is a mechanism that allows web-started applications (like typical streaming media players) to be SSM augmented from an appropriately written web page. With URD enabled, the router will intercept TCP connections to port 659, act like a HTTP server on that port and interpret URLs requested from the clients browser to contain SSM channel information: http://arbitrary:659/arbitrary?group=&source=& If the router intercepts such a URL, it will join to the (,) SSM channel as soon if or as soon as it also sees that the legacy application is simply trying to join to the group . In the URL, and can either be IP addresses or fully qualified domain names (you need to have domain name resolution enabled on the router to support domain names). [12.1(5)T, 12.0(15)S, 12.2(1)] If the proxy option is not given, intercepted TCP connections are only considered to be valid, if they originate from directly connected hosts. If the proxy option is given, requests will be honored from any TCP connection arriving on this interface. Never enable the proxy option on a backbone interface because this would allow people from the backbone to create URD state in your router. This option is meant to be used with unnumbered interfaces towards users or stub networks with IGMP proxy routers downstream of your router. [12.2(1), 12.0(16)S] The port used by URD was changed to TCP port 465 via CSCdt68756 (See Release Notes for the ddts on CCO for more explanations). [12.2(4)M/B/T, 12.0(19)S/ST, 12.1(8a)E02]. [no] ip igmp query-timeout [timeout value in secs] This command is valid when IGMP v2 is running. This command specifies the timeout for the router to take over as the querier for the interface, after the previous querier has stopped querying. The default value is 2 * query-interval. If the router hears no queries for the "timeout" period, it becomes the querier. [11.1] [no] ip igmp query-max-response-time [secs] This command is valid when IGMP v2 is running. This command specifies the maximum query response time advertised in the IGMP queries. Default value is 10 secs. Configuring a value less than 10 seconds enables the router to prune groups faster. [11.1] [no] ip igmp helper-address This command causes all IGMP host report and leave message received on the interface to be forwarded toward the given ip-address. The reports are resent out the next-hop interface towards the ip-address with that interface's source address. This command can enable a sort of "dense-mode" join, allowing stub sites not participating in PIM to indicate membership in multicast groups. [11.3] [no] ip cgmp Enables the Cisco Group Management Protocol (CGMP) for IP multicast on a LAN. The command triggers a CGMP Join message. This should only be enabled on 802 media (i.e. Ethernet, Fddi, and Token Ring) or ATM. When a "no" is issued, a triggered CGMP Leave message is sent for the router's MAC address on the interface for group 0000.0000.0000. CGMP can only run on an interface if PIM is configured on the same interface. [11.1] A cisco will send CGMP Join messages in response to receiving IGMP reports from multicast capable members. Only the IGMP querier cisco router sends these CGMP Join messages on behalf of hosts. [no] ip cgmp proxy Enables CGMP for IP multicast as well as a proxy function. Initially supported is DVMRP proxying. If a DVMRP Report is received from a router that is not a PIM router, a cisco IGMP querier will advertise the MAC address of the DVMRP router in a CGMP Join with group address 0000.0000.0000. [11.1] To perform CGMP proxy, a cisco must be the IGMP querier. An IGMPv2 querier is selected based on the lowest IP addressed router on the interface. An IGMPv1 querier is selected based on the multicast routing protocol used on the interface. When multiple cisco routers are connected to a switched network and "ip cgmp [proxy]" is needed, it is recommended that all of them are configured 1) with the same CGMP option and 2) to have precedence of becoming IGMP querier over non-cisco routers. [no] ip pim version 1 By default, this command is not configured on an interface and the router uses PIM version 2 but will automatically fall back using PIM version 1 if it detects PIM version 1 routers. If you configure this command, the router will only use PIM version 1 on an interface. You should never need to configure this command, it was only introduced to allow disabling PIM version 2 to troubleshoot PIM version 2 problems in early IOS images (around 1998). Note: There is no specific command to disable PIM version 1 backward compatibility in Cisco IOS, but you can inhibit recognizing individual routers via the "ip pim neighbor-filter" command. See description under "ip pim query-interval" for further information about automatic PIM version 1 backward compatibility. [11.3T, 12.0]. Cisco IOS images prior to 11.3T, 12.0 do only support PIM version 1. [no] ip pim dr-priority Configures the neighbor priority used for PIM Designated Router (DR) election. The router with the largest on an interface will become the PIM DR. If multiple routers have the same priority, then the largest IP addressed system on the interface becomes DR. If a router doesn't include the DR-Priority Option in it's Hello messages, the router is regarded highest priority router and will become DR. If multiple of such routers exist, the largest IP addressed router will become DR. This allows interoperation with older systems. [12.1(2)T, 12.2, feature available in IOS images with Bidir-PIM] [no] ip pim [dense-mode | sparse-mode] Enables the PIM multicast routing protocol on the interface. Configures the interface to operate in dense or sparse mode. The default mode is dense-mode. A dense-mode interface is subject to multicast flooding by default. A sparse-mode interface is only used for multicast forwarding if a join is received from a downstream router or their are directly connected members on the interface. When "no ip pim" is entered, it disables PIM on the interface. [10.2] [no] ip pim sparse-dense-mode Enables the PIM multicast routing protocol on the interface. In this mode, the interface will be treated as dense-mode if the group is in dense-mode. If the group is in sparse-mode, the interface will be treated in sparse-mode. When an interface is treated in dense-mode, it will be populated in a multicast routing table's outgoing interface list when 1) there are members or DVMRP neighbors on the interface, or 2) any of the PIM neighbors on the interface have not pruned for the group. When an interface is treated in sparse-mode, it will be populated in a multicast routing table's outgoing interface list when 1) there are members or DVMRP neighbors on the interface or 2) an explicit Join has been received by a PIM neighbor on the interface. [11.1] [no] ip pim dense-mode proxy-register [list | route-map ] Enable this command on an interface connecting to a dense-mode region to enable registering for sources in that dense-mode region. For multicast groups in PIM sparse mode, the router will normally do the PIM sparse mode registering if it is the first-hop DR, directly connected to the source. If the router receives a packet from a non-directly connected source on an interface it will only register for this if either a DVMRP neighbor is active on an interface, or if this command is configured. Configuring this command will thus allow to get traffic from a source in a PIM dense-mode region to be correctly received by a receiver in the sparse mode region. In addition to a dense mode border, this command also needs to be configured on interfaces connecting to a stub region with IGMP proxying routers to allow for sources from that region to be correctly registered for when sending to PIM sparse mode groups. Because the "proxy-register" option is only supported together with the "ip pim dense-mode" interface mode, one should avoid putting further PIM or DVMRP routers on that interface (only IGMP proxy routers) to avoid that the border router starts to flood traffic (as long as there is no DVMRP or PIM router connected, a dense-mode interface does not behave different from a sparse-mode or sparse-dense-mode interface). Use the "list " or "route-map " options to limit the (S,G) packets arriving at this interface for which the router will do registering. These filtering options will only affect (S,G) for which S is not directly connected. [12.0(7), CSCdm73649] [no] ip pim query-interval