Table Of Contents
Multiprotocol BGP Extensions for IP Multicast
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Understanding NLRI Keywords and Address Families
Configuring a Multiprotocol BGP Peer
Configuring a Multiprotocol BGP Peer Group
Advertising Routes into Multiprotocol BGP
Configuring Route Maps for Multiprotocol BGP Prefixes
Redistributing Prefixes into Multiprotocol BGP
Configuring DVMRP Interoperability with Multiprotocol BGP
Redistributing Multiprotocol BGP Routes into DVMRP
Redistributing DVMRP Routes into Multiprotocol BGP
Configuring a Multiprotocol BGP Route Reflector
Configuring Aggregate Multiprotocol BGP Addresses
Verifying Multiprotocol BGP Configuration and Operation
Multiprotocol BGP Peer Examples
Multiprotocol BGP Peer Group Examples
Multiprotocol BGP Network Advertisement Examples
Multiprotocol BGP Route Map Examples
Multiprotocol BGP Route Redistribution Examples
Multiprotocol BGP Route Reflector Examples
Aggregate Multiprotocol BGP Address Examples
neighbor peer-group (creating)
network (BGP and multiprotocol BGP)
show ip bgp ipv4 multicast summary
Multiprotocol BGP Extensions for IP Multicast
This feature module describes the multiprotocol Border Gateway Protocol (BGP) feature and includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
The multiprotocol BGP feature adds capabilities to BGP to enable multicast routing policy throughout the Internet and to connect multicast topologies within and between BGP autonomous systems. That is, multiprotocol BGP is an enhanced BGP that carries IP multicast routes. BGP carries two sets of routes, one set for unicast routing and one set for multicast routing. The routes associated with multicast routing are used by the Protocol Independent Multicast (PIM) to build data distribution trees.
Multiprotocol BGP is useful when you want a link dedicated to multicast traffic, perhaps to limit which resources are used for which traffic. Perhaps you want all multicast traffic exchanged at one network access point (NAP). Multiprotocol BGP allows you to have a unicast routing topology different from a multicast routing topology. Thus, you have more control over your network and resources.
In BGP, the only way to perform interdomain multicast routing was to use the BGP infrastructure that was in place for unicast routing. If those routers were not multicast capable, or there were differing policies where you wanted multicast traffic to flow, multicast routing could not be supported without multiprotocol BGP.
Note
Figure 1 illustrates a simple example of unicast and multicast topologies that are incongruent, and therefore are not be possible without multiprotocol BGP.
Autonomous systems 100, 200, and 300 are each connected to two NAPs that are FDDI rings. One is used for unicast peering (and therefore the exchanging of unicast traffic). The Multicast Friendly Interconnect (MFI) ring is used for multicast peering (and therefore the exchanging of multicast traffic). Each router is unicast- and multicast-capable.
Figure 1 Incongruent Unicast and Multicast Routes
Figure 2 is a topology of unicast-only routers and multicast-only routers. The two routers on the left are unicast-only routers (that is, they do not support or are not configured to perform multicast routing). The two routers on the right are multicast-only routers. Routers A and B support both unicast and multicast routing. The unicast-only and multicast-only routers are connected to a single NAP.
In Figure 2, only unicast traffic can travel from Router A to the unicast routers to Router B and back. Multicast traffic could not flow on that path, so another routing table is required. Multicast traffic uses the path from Router A to the multicast routers to Router B and back.
Figure 2 illustrates a multiprotocol BGP environment with a separate unicast route and multicast route from Router A to Router B. Multiprotocol BGP allows these routes to be noncongruent. Both of the autonomous systems must be configured for internal multiprotocol BGP.
A multicast routing protocol, such as PIM, uses the multicast BGP database to perform Reverse Path Forwarding (RPF) lookups for multicast-capable sources. Thus, packets can be sent and accepted on the multicast topology but not on the unicast topology.
Figure 2 Multicast BGP Environment
Benefits
Multiprotocol BGP offers the following benefits:
•
•
•
•
•
•
Restrictions
You cannot connect multiprotocol BGP clouds with a BGP cloud. That is, you cannot redistribute multiprotocol BGP routes into BGP.
Related Features and Technologies
This feature is related to the existing BGP feature, which is documented in the Cisco IOS IP and IP Routing Configuration Guide and the Cisco IOS IP and IP Routing Command Reference.
Related Documents
•
•
•
Supported Platforms
This feature can run on all Cisco platforms, but it is officially supported on only the following platforms:
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of MIBs supported by platform and Cisco IOS releases and to download MIB modules, go to the Cisco MIB web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
•
Prerequisites
This document assumes you are familiar with BGP and IP multicast routing. For more information, refer to the "Configuring BGP" and "Configuring IP Multicast Routing" chapters of the Cisco IOS IP and IP Routing Configuration Guide.
Configuration Tasks
See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional:
•
•
•
•
•
•
•
•
•
•
Understanding NLRI Keywords and Address Families
Multiprotocol BGP was introduced in Cisco IOS Release 11.1(20)CC and Cisco IOS Release 12.0(2)S prior to it being integrated into Cisco IOS Release 12.0(7)T. In Cisco IOS Release 11.1(20)CC and later releases and Cisco IOS Release 12.0(2)S and later releases, the Cisco IOS software uses NLRI keywords to enable multiprotocol BGP over a BGP session and to populate unicast BGP prefixes in the unicast database and multicast BGP prefixes in the multicast database. In Cisco IOS Release 12.0(7)T, the Cisco IOS software uses separate address families to enable multiprotocol BGP over a BGP session and to populate unicast BGP prefixes in the unicast database and multicast BGP prefixes in the multicast database.
Cisco IOS Release 12.0(7)T does not support the NLRI keywords. However, for backward compatibility, the NLRI keyword configuration of a Cisco router is automatically converted to an address family configuration when a router is upgraded to Cisco IOS Release 12.0(7)T. The following example shows an NLRI keyword configuration for a Cisco router that is running Cisco IOS Release 12.0(8)S:
router bgp 5no synchronizationnetwork 172.16.214.0 mask 255.255.255.0 nlri unicast multicastneighbor 172.16.214.34 remote-as 5neighbor 172.16.214.38 remote-as 2 nlri unicast multicastneighbor 172.16.214.42 remote-as 5neighbor 172.16.214.59 remote-as 5no auto-summaryThe following example shows the resulting address family configuration after the same router is upgraded to Cisco IOS Release 12.0(7)T:
router bgp 5no synchronizationnetwork 172.16.214.0 mask 255.255.255.0neighbor 172.16.214.34 remote-as 5neighbor 172.16.214.38 remote-as 2neighbor 172.16.214.42 remote-as 5neighbor 172.16.214.59 remote-as 5no auto-summary
Note
Configuring a Multiprotocol BGP Peer
To configure multiprotocol BGP between two routers, use the following commands beginning in global configuration mode:
Note
See the "Multiprotocol BGP Peer Examples" section for multiprotocol BGP peer configuration examples.
Configuring a Multiprotocol BGP Peer Group
To configure a peer group to perform multiprotocol BGP routing, use the following commands beginning in global configuration mode:
Note
Note
Members of a peer group automatically inherit the address prefix configuration of the peer group.
Refer to the section "Configure BGP Peer Groups" of the "Configuring BGP" chapter in the Cisco IOS IP and IP Routing Configuration Guide for information and instructions on assigning options to the peer group and making a BGP or multiprotocol BGP neighbor a member of the peer group. See the "Multiprotocol BGP Peer Group Examples" section for multiprotocol BGP peer group configuration examples.
Advertising Routes into Multiprotocol BGP
To advertise (inject) a network number and mask into multiprotocol BGP, use the following commands beginning in global configuration mode:
Note
See the "Multiprotocol BGP Network Advertisement Examples" section for multiprotocol BGP network advertisement configuration examples.
Configuring Route Maps for Multiprotocol BGP Prefixes
To configure a route map for multiprotocol BGP prefixes, use the following commands beginning in global configuration mode:
Note
Note
See the "Multiprotocol BGP Route Map Examples" section for multiprotocol BGP route map configuration examples.
Redistributing Prefixes into Multiprotocol BGP
Redistribution is the process of injecting prefixes from one routing protocol into another routing protocol. The tasks in this section explain how to inject prefixes from a routing protocol into multiprotocol BGP. Specifically, prefixes that are redistributed into multiprotocol BGP using the redistribute command are injected into the unicast database, the multicast database, or both.
To inject prefixes from a routing protocol into multiprotocol BGP, use the following commands beginning in global configuration mode:
Note
See the "Multiprotocol BGP Route Redistribution Examples" section for multiprotocol BGP route redistribution configuration examples.
Configuring DVMRP Interoperability with Multiprotocol BGP
Cisco multicast routers using PIM can interoperate with non-Cisco multicast routers that use the Distance Vector Multicast Routing Protocol (DVMRP).
PIM routers dynamically discover DVMRP multicast routers on attached networks. Once a DVMRP neighbor has been discovered, the router caches DVMRP routes that the neighbor sends. Those routes describe sources in a DVMRP cloud that want their packets to be received by receivers outside of this routing domain. Multiprotocol BGP allows the source prefixes of those sources to be known outside of the routing domain.
The router periodically sends DVMRP Report messages advertising the unicast sources reachable in the PIM domain.
Redistributing Multiprotocol BGP Routes into DVMRP
By default, no multiprotocol BGP routes are redistributed into DVMRP. However, you can configure all multiprotocol BGP routes to be redistributed into DVMRP with a specified metric. Furthermore, to redistribute only certain multiprotocol BGP routes into DVMRP, you can configure the metric and subject it to route map conditions. If you supply a route map, you can specify various match criteria options for the multiprotocol BGP routes. If the route passes the route map, then the route is redistributed into DVMRP.
If there are multicast sources in other routing domains that are known via multiprotocol BGP and there are receivers in a DVMRP cloud, they will want to receive packets from those sources. Therefore, you need to redistribute the multiprotocol BGP prefix routes into DVMRP. This will be the scenario when distributing multiprotocol BGP prefixes into the MBONE.
To redistribute multiprotocol BGP routes into DVMRP, use the following command in interface configuration mode:
Redistributing DVMRP Routes into Multiprotocol BGP
If there are multicast sources in a DVMRP routing domain that need to reach receivers in multiprotocol BGP routing domains, you need to redistribute DVMRP prefixes into multiprotocol BGP. If you supply a route map, you can also use the set commands to specify various BGP attribute settings.
To redistribute DVMRP prefixes into multiprotocol BGP, use the following command in address family configuration mode:
Router(config-router-af)# redistribute dvmrp [route-map map-name]
Redistributes DVMRP routes into multiprotocol BGP.
To redistribute DVMRP prefixes into multiprotocol BGP, use the following command in router configuration mode:
Router(config-router)# redistribute dvmrp [route-map map-name]
Redistributes DVMRP routes into multiprotocol BGP.
See the "Multiprotocol BGP Route Redistribution Examples" section for multiprotocol BGP route redistribution configuration examples.
Configuring a Multiprotocol BGP Route Reflector
To configure a local router as a route reflector of multiprotocol BGP prefixes, use the following commands beginning in global configuration mode:
Note
Note
See the "Multiprotocol BGP Route Reflector Examples" section for multiprotocol BGP route reflector configuration examples.
Configuring Aggregate Multiprotocol BGP Addresses
The tasks in this section explain how to configure an aggregate address for multiprotocol BGP. Specifically, the tasks in this section explain how to inject an aggregate address into the multicast database, the unicast database, or both.
To configure an aggregate address for multiprotocol BGP, use the following commands beginning in global configuration mode:
Note
See the "Aggregate Multiprotocol BGP Address Examples" section for aggregate multiprotocol BGP address configuration examples.
Verifying Multiprotocol BGP Configuration and Operation
The following steps show an example of how to verify multiprotocol BGP configuration and operation:
Step 1
Router# show ip bgp ipv4 multicastMBGP table version is 6, local router ID is 192.168.200.66Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*> 10.0.20.16/28 0.0.0.0 0 0 32768 i*> 10.0.35.16/28 0.0.0.0 0 0 32768 i*> 10.0.36.0/28 0.0.0.0 0 0 32768 i*> 10.0.48.16/28 0.0.0.0 0 0 32768 i*> 10.2.0.0/16 0.0.0.0 0 0 32768 i*> 10.2.1.0/24 0.0.0.0 0 0 32768 i*> 10.2.2.0/24 0.0.0.0 0 0 32768 i*> 10.2.3.0/24 0.0.0.0 0 0 32768 i*> 10.2.7.0/24 0.0.0.0 0 0 32768 i*> 10.2.8.0/24 0.0.0.0 0 0 32768 i*> 10.2.10.0/24 0.0.0.0 0 0 32768 i*> 10.2.11.0/24 0.0.0.0 0 0 32768 i*> 10.2.12.0/24 0.0.0.0 0 0 32768 i*> 10.2.13.0/24 0.0.0.0 0 0 32768 i
Note
Step 2
Router# show ip bgp ipv4 multicast summaryBGP router identifier 10.0.33.34, local AS number 34BGP table version is 5, main routing table version 14 network entries and 6 paths using 604 bytes of memory5 BGP path attribute entries using 260 bytes of memory1 BGP AS-PATH entries using 24 bytes of memory2 BGP community entries using 48 bytes of memory2 BGP route-map cache entries using 32 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP activity 8/28 prefixes, 12/0 paths, scan interval 15 secsNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.0.33.35 4 35 624 624 5 0 0 10:13:46 3Step 3
Router# debug ip mbgp dampeningBGP: charge penalty for 173.19.0.0/16 path 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000BGP: charge penalty for 173.19.0.0/16 path 19 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000Step 4
Router# debug ip mbgp updatesBGP: NEXT_HOP part 1 net 200.10.202.0/24, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 send UPDATE 200.10.202.0/24, next 171.69.233.34, metric 0, path 33 34 19 49 109 65000 297 1239 1800 3597BGP: NEXT_HOP part 1 net 200.10.228.0/22, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 rcv UPDATE about 222.2.2.0/24, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 131.103.0.0/16, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 206.205.242.0/24, next hop 171.69.233.49, path 49 109 metric 0Step 5
Router# show ip mpacket 224.2.163.188 qualityCalculating RTP data quality for 224.2.163.188Session: UO Presents KKNU New CountrySource: 128.223.83.27 (sand.uoregon.edu), Port: 23824Packets received: 83, lost: 5, loss percentage: 5.6%Packets misordered: 7, average loss gap: 0
Configuration Examples
This section provides the following multiprotocol BGP configuration examples:
•
•
•
•
•
•
•
Multiprotocol BGP Peer Examples
The following example shows how to use an address family to configure a neighbor as both unicast and multicast capable:
router bgp 100address-family ipv4 unicastneighbor 10.1.1.1 activaterouter bgp 100address-family ipv4 multicastneighbor 10.1.1.1 activateMultiprotocol BGP Peer Group Examples
The following example shows how to use an address family to configure a peer group so that all members of the peer group are both unicast and multicast capable:
router bgp 100neighbor 10.1.1.1 remote-as 1neighbor 12.2.2.2 remote-as 2address-family ipv4 unicastneighbor mygroup peer-groupneighbor 10.1.1.1 peer-group mygroupneighbor 12.2.2.2 peer-group mygrouprouter bgp 100neighbor 10.1.1.1 remote-as 1neighbor 12.2.2.2 remote-as 2address-family ipv4 multicastneighbor mygroup peer-groupneighbor 10.1.1.1 peer-group mygroupneighbor 12.2.2.2 peer-group mygroupneighbor 10.1.1.1 activateneighbor 12.2.2.2 activateMultiprotocol BGP Network Advertisement Examples
The following examples show how to use an address family to inject a network number and mask into the unicast database and the multicast database:
router bgp 100address-family ipv4 unicastneighbor 10.0.0.0 255.0.0.0router bgp 100address-family ipv4 multicastneighbor 10.0.0.0 255.0.0.0Multiprotocol BGP Route Map Examples
The following example shows how to use an address family to configure BGP so that any unicast and multicast routes from neighbor 10.1.1.1 are accepted if they match access list 1:
router bgp 109neighbor 10.1.1.1 remote-as 1address-family ipv4 unicastneighbor 10.1.1.1 route-map filter-some-multicast inrouter bgp 109neighbor 10.1.1.1 remote-as 1address-family ipv4 multicastneighbor 10.1.1.1 route-map filter-some-multicast inneighbor 10.1.1.1 activateroute-map filter-some-multicastmatch ip address 1Multiprotocol BGP Route Redistribution Examples
The following example shows how to use an address family to redistribute DVMRP routes that match access list 1 into the multicast database and the unicast database of the local router:
router bgp 109address-family ipv4 unicastredistribute dvmrp route-map dvmrp-into-mbgprouter bgp 109address-family ipv4 multicastredistribute dvmrp route-map dvmrp-into-mbgproute-map dvmrp-into-mbgpmatch ip address 1Multiprotocol BGP Route Reflector Examples
The following example show how to use an address family to configure internal BGP peer 10.1.1.1 as a route-reflector client for both unicast and multicast prefixes:
router bgp 109address-family ipv4 unicastneighbor 10.1.1.1 activateneighbor 10.1.1.1 route-reflector-clientrouter bgp 109address-family ipv4 multicastneighbor 10.1.1.1 activateneighbor 10.1.1.1 route-reflector-clientAggregate Multiprotocol BGP Address Examples
The following example show how to use an address family to configure an aggregate multiprotocol BGP address entry in both the unicast database and the multicast database:
router bgp 109address-family ipv4 unicastaggregate-address 172.16.0.0 255.0.0.0 as-setrouter bgp 109address-family ipv4 multicastaggregate-address 172.16.0.0 255.0.0.0 as-setCommand Reference
This section documents new or modified commands. All other commands used with multiprotocol BGP are documented in the Cisco IOS Release 12.1 command reference publications.
•
•
•
Commands in this feature module that have been replaced by new or existing commands are no longer documented. Table 1 maps the old commands with their replacements.
address-family ipv4
To enter address family configuration mode for configuring routing sessions, such as Border Gateway Protocol (BGP), that use standard IPv4 address prefixes, use the address-family ipv4 router configuration command. To disable address family configuration mode, use the no form of this command.
address-family ipv4 [multicast | unicast [vrf vrf-name]
no address-family ipv4 [multicast | unicast | vrf vrf-name]
Syntax Description
Defaults
IPv4 address prefixes are not enabled. Unicast address prefixes are the default when IPv4 address prefixes are configured.
Command Modes
Router configuration
Command History
Usage Guidelines
The address-family ipv4 command places the router in address family configuration mode (prompt: config-router-af), from which you can configure routing sessions that use standard IPv4 address prefixes. To leave address family configuration mode and return to router configuration mode, type exit.
Routing information for address family IPv4 is advertised by default when you configure a BGP routing session using the neighbor remote-as command unless you execute the no bgp default ipv4-unicast command.
The address-family ipv4 command replaces the match nlri and set nlri commands.
Examples
The following example places the router in address family configuration mode for the IPv4 address family:
Router(config)# router bgp 100Router(config-router)# address-family ipv4Router(config-router-af)#The following example places the router in address family configuration mode and specifies multicast address prefixes for the IPv4 address family:
Router(config)# router bgp 100Router(config-router)# address-family ipv4 multicastRouter(config-router-af)#The following example places the router in address family configuration mode and specifies unicast address prefixes for the IPv4 address family:
Router(config)# router bgp 100Router(config-router)# address-family ipv4 unicastRouter(config-router-af)#The following example places the router in address family configuration mode and specifies cisco as the name of the VRF instance to associate with subsequent IPv4 address family configuration mode commands:
Router(config)# router bgp 100Router(config-router)# address-family ipv4 vrf ciscoRouter(config-router-af)#Use this form of the command, which specifies a VRF, only to configure routing exchanges between provider edge (PE) and customer edge (CE) devices.
Related Commands
address-family vpnv4
To enter address family configuration mode for configuring routing sessions, such as Border Gateway Protocol (BGP), that use standard VPNv4 address prefixes, use the address-family vpnv4 router configuration command. To disable address family configuration mode, use the no form of this command.
address-family vpnv4 [unicast]
no address-family vpnv4 [unicast]
Syntax Description
Defaults
VPNv4 address prefixes are not enabled. Unicast address prefixes are the default when VPNv4 address prefixes are configured.
Command Modes
Router configuration
Command History
Usage Guidelines
The address-family vpnv4 command places the router in address family configuration mode (prompt: config-router-af), from which you can configure routing sessions that use VPNv4 address prefixes. To leave address family configuration mode and return to router configuration mode, type exit.
The address-family vpnv4 command replaces the match nlri and set nlri commands.
Examples
The following example places the router in address family configuration mode for the VPNv4 address family:
Router(config)# router bgp 100(config-router)# address-family vpnv4(config-router-af)#The following example places the router in address family configuration mode for the unicast VPNv4 address family:
Router(config)# router bgp 100(config-router)# address-family vpnv4 unicast(config-router-af)#Related Commands
aggregate-address
To create an aggregate entry in a Border Gateway Protocol (BGP) or multicast BGP database, use the aggregate-address command in address family or router configuration mode. To disable this function, use the no form of this command.
aggregate-address address mask [as-set] [summary-only] [suppress-map map-name] [advertise-map map-name] [attribute-map map-name]
no aggregate-address address mask [as-set] [summary-only] [suppress-map map-name] [advertise-map map-name] [attribute-map map-name]
Syntax Description
Defaults
Disabled
Command Modes
Address family configuration
Router configuration
Command History
Usage Guidelines
You can implement aggregate routing in BGP and multiprotocol BGP either by redistributing an aggregate route into BGP or multiprotocol BGP, or by using this conditional aggregate routing feature.
Using the aggregate-address command with no arguments will create an aggregate entry in the BGP or multicast BGP database if there are any more-specific BGP or multiprotocol BGP routes available that fall in the specified range. The aggregate route will be advertised as coming from your autonomous system and will have the atomic aggregate attribute set to show that information might be missing. (By default, the atomic aggregate attribute is set unless you specify the as-set keyword.)
Using the as-set keyword creates an aggregate entry using the same rules that the command follows without this keyword, but the path advertised for this route will be an AS_SET consisting of all elements contained in all paths that are being summarized. Do not use this form of the aggregate-address command when aggregating many paths, because this route must be continually withdrawn and reupdated as autonomous system path reachability information for the summarized routes changes.
Using the summary-only keyword not only creates the aggregate route (for example, 193.*.*.*) but also suppresses advertisements of more-specific routes to all neighbors. If you only want to suppress advertisements to certain neighbors, you may use the neighbor distribute-list command, with caution. If a more-specific route leaks out, all BGP or multiprotocol BGP routers will prefer that route over the less-specific aggregate you are generating (using longest-match routing).
Using the suppress-map keyword creates the aggregate route but suppresses advertisement of specified routes. You can use the match clauses of route maps to selectively suppress some more-specific routes of the aggregate and leave others unsuppressed. IP access lists and autonomous system path access lists match clauses are supported.
Examples
In the following example, a BGP aggregate address is created in router configuration mode. The path advertised for this route will be an AS_SET consisting of all elements contained in all paths that are being summarized.
Router(config)# router bgp 5Router(config-router)# aggregate-address 193.0.0.0 255.0.0.0 as-setIn the following example, a multiprotocol BGP aggregate address is created in address family configuration mode and applied to the multicast database only using an IPv4 address family. More-specific routes are filtered from updates.
Router(config)# router bgp 5Router(config-router)# address-family ipv4 multicastRouter(config-router-af)# aggregate-address 193.0.0.0 255.0.0.0 summary-onlyRelated Commands
distance bgp
To allow the use of external, internal, and local administrative distances that could be a better route than other external, internal, or local routes to a node, use the distance bgp command in address family or router configuration mode. To return to the default values, use the no form of this command.
distance bgp external-distance internal-distance local-distance
no distance bgp
Syntax Description
Defaults
external-distance: 20
internal-distance: 200
local-distance: 200Command Modes
Address family configuration
Router configuration
Command History
10.0
This command was introduced.
12.0(7)T
Address family configuration mode was added.
Usage Guidelines
An administrative distance is a rating of the trustworthiness of a routing information source, such as an individual router or a group of routers. Numerically, an administrative distance is a positive integer from
1 to 255. In general, the higher the value, the lower the trust rating. An administrative distance of 255 means the routing information source cannot be trusted at all and should be ignored.Use this command if another protocol is known to be able to provide a better route to a node than was actually learned via external BGP, or if some internal routes should be preferred by the BGP.
Caution
The distance bgp command replaces the distance mbgp command.
Examples
In the following router configuration mode example, internal routes are known to be preferable to those learned through the Interior Gateway Protocol (IGP), so the administrative distance values are set accordingly:
router bgp 109network 131.108.0.0neighbor 129.140.6.6 remote-as 123neighbor 128.125.1.1 remote-as 47distance bgp 20 20 200In the following address family configuration mode example, internal routes are known to be preferable to those learned through IGP, so the administrative distance values are set accordingly:
router bgp 109neighbor 129.140.6.6 remote-as 123neighbor 128.125.1.1 remote-as 47address family ipv4 multicastnetwork 131.108.0.0distance bgp 20 20 200neighbor 129.140.6.6 activateneighbor 128.125.1.1 activateRelated Commands
distance mbgp
In Cisco IOS Release 12.0(7)T, the distance bgp command replaces the distance mbgp command. See the description of the distance bgp command for more information.
ip dvmrp metric
To configure the metric associated with a set of destinations for Distance Vector Multicast Routing Protocol (DVMRP) reports, use the ip dvmrp metric interface configuration command. (Note that this command has two different syntax possibilities.) To disable this function, use the no form of this command.
ip dvmrp metric metric [route-map map-name] [mbgp] [list access-list-number] [[protocol process-id] | dvmrp]
no ip dvmrp metric metric [route-map map-name] [mbgp] [list access-list-number] [[protocol process-id] | dvmrp]
Syntax Description
Defaults
No metric is preconfigured. Only directly connected subnets and networks are advertised to neighboring DVMRP routers.
Command Modes
Interface configuration
Command History
10.2
This command was introduced.
11.1
The route-map keyword was added.
11.1(20)CC
This mbgp keyword was added.
12.0(7)T
This mbgp keyword was added.
Usage Guidelines
When Protocol Independent Multicast (PIM) is configured on an interface and DVMRP neighbors are discovered, the Cisco IOS software sends DVMRP report messages for directly connected networks. The ip dvmrp metric command enables DVMRP report messages for multicast destinations that match the access list. Usually, the metric for these routes is 1. Under certain circumstances, you might want to tailor the metric used for various unicast routes. This command lets you configure the metric associated with a set of destinations for Report messages sent out this interface.
You can use the access-list-number argument in conjunction with the protocol process-id arguments to selectively list the destinations learned from a given routing protocol.
To display DVMRP activity, use the debug ip dvmrp command.
Examples
The following example connects a PIM cloud to a DVMRP cloud. Access list 1 permits the sending of DVMRP reports to the DVMRP routers advertising all sources in the 198.92.35.0 network with a metric of 1. Access list 2 permits all other destinations, but the metric of 0 means that no DVMRP reports are sent for these destinations.
access-list 1 permit 198.92.35.0 0.0.0.255access-list 1 deny 0.0.0.0 255.255.255.255access-list 2 permit 0.0.0.0 255.255.255.255interface tunnel 0ip dvmrp metric 1 list 1ip dvmrp metric 0 list 2The following example redistributes IPv4 multicast routes into DVMRP neighbors with a metric of 1:
interface tunnel 0ip dvmrp metric 1 mbgpRelated Commands
debug ip dvmrp
Displays information on DVMRP packets received and sent.
ip dvmrp accept-filter
Configures an acceptance filter for incoming DVMRP reports.
ip multicast cache-headers
To allocate a circular buffer to store IPv4 multicast packet headers that the router receives, use the ip multicast cache-headers global configuration command. To disable the buffer, use the no form of this command.
ip multicast cache-headers [rtp]
no ip multicast cache-headers
Syntax Description
Defaults
Disabled
Command Modes
Global configuration
Command History
11.1
This command was introduced.
11.1(20)CC
The rtp keyword was added.
12.0(7)T
The rtp keyword was added.
Usage Guidelines
You can store IPv4 multicast packet headers in a cache and then display them to determine the following:
•
•
•
•
•
•
•
Note
Use the show ip mpacket command to display the buffer.
Examples
The following example allocates a buffer to store IPv4 multicast packet headers:
ip multicast cache-headers
Related Commands
match nlri
In Cisco IOS Release 12.0(7)T, the address-family ipv4 and address-family vpnv4 commands replace the match nlri command. See the descriptions of the address-family ipv4 or address-family vpnv4 command for more information.
neighbor peer-group (creating)
To create a Border Gateway Protocol (BGP) or multiprotocol BGP peer group, use the neighbor peer-group command in address family or router configuration mode. To remove the peer group and all of its members, use the no form of this command.
neighbor peer-group-name peer-group
no neighbor peer-group-name peer-group
Syntax Description
Defaults
There is no BGP peer group.
Command Modes
Address family configuration
Router configuration
Command History
Usage Guidelines
Often in a BGP or multiprotocol BGP speaker, many neighbors are configured with the same update policies (that is, same outbound route maps, distribute lists, filter lists, update source, and so on). Neighbors with the same update policies can be grouped into peer groups to simplify configuration and make update calculation more efficient.
Note
Once a peer group is created with the neighbor peer-group command, it can be configured with the neighbor commands. By default, members of the peer group inherit all the configuration options of the peer group. Members also can be configured to override the options that do not affect outbound updates.
Peer group members will always inherit the following configuration options: remote-as (if configured), version, update-source, out-route-map, out-filter-list, out-dist-list, minimum-advertisement-interval, and next-hop-self. All the peer group members will inherit changes made to the peer group.
If a peer group is not configured with a remote-as, the members can be configured with the neighbor {ip-address | peer-group-name} remote-as command. This command allows you to create peer groups containing Exterior Border Gateway Protocol (EBGP) neighbors.
Examples
The following example configurations show how to create these types of neighbor peer group:
•
•
•
IBGP Peer Group
In the following example, the peer group named internal configures the members of the peer group to be IBGP neighbors. By definition, this is an IBGP peer group because the router bgp command and the neighbor remote-as command indicate the same autonomous system (in this case, autonomous system 100). All the peer group members use loopback 0 as the update source and use set-med as the outbound route map. The neighbor internal filter-list 2 in command shows that, except for 171.69.232.55, all the neighbors have filter-list 2 as the inbound filter list.
router bgp 100neighbor internal peer-groupneighbor internal remote-as 100neighbor internal update-source loopback 0neighbor internal route-map set-med outneighbor internal filter-list 1 outneighbor internal filter-list 2 inneighbor 171.69.232.53 peer-group internalneighbor 171.69.232.54 peer-group internalneighbor 171.69.232.55 peer-group internalneighbor 171.69.232.55 filter-list 3 inEBGP Peer Group
The following example defines the peer group named external-peers without the neighbor remote-as command. By definition, this is an EBGP peer group because each individual member of the peer group is configured with its respective autonomous system number separately. Thus the peer group consists of members from autonomous systems 200, 300, and 400. All the peer group members have the set-metric route map as an outbound route map and filter-list 99 as an outbound filter list. Except for neighbor 171.69.232.110, all of them have 101 as the inbound filter list.
router bgp 100neighbor external-peers peer-groupneighbor external-peers route-map set-metric outneighbor external-peers filter-list 99 outneighbor external-peers filter-list 101 inneighbor 171.69.232.90 remote-as 200neighbor 171.69.232.90 peer-group external-peersneighbor 171.69.232.100 remote-as 300neighbor 171.69.232.100 peer-group external-peersneighbor 171.69.232.110 remote-as 400neighbor 171.69.232.110 peer-group external-peersneighbor 171.69.232.110 filter-list 400 inMultiprotocol BGP Peer Group
In the following example, all members of the peer group are multicast capable:
router bgp 100neighbor 1.1.1.1 remote-as 1neighbor 2.2.2.2 remote-as 2address-family ipv4 multicastneighbor mygroup peer-groupneighbor 1.1.1.1 peer-group mygroupneighbor 2.2.2.2 peer-group mygroupneighbor 1.1.1.1 activateneighbor 2.2.2.2 activateRelated Commands
neighbor remote-as
To add an entry to the Border Gateway Protocol (BGP) or multiprotocol BGP neighbor table, use the neighbor remote-as command in router configuration mode. To remove an entry from the table, use the no form of this command.
neighbor {ip-address | peer-group-name} remote-as autonomous-system-number
no neighbor {ip-address | peer-group-name} remote-as autonomous-system-number
Syntax Description
ip-address
IP address of the neighbor.
peer-group-name
Name of a BGP peer group.
autonomous-system-number
Autonomous system to which the neighbor belongs.
Defaults
There are no BGP or multiprotocol BGP neighbor peers.
Command Modes
Router configuration
Command History
Usage Guidelines
Specifying a neighbor with an autonomous system number that matches the autonomous system number specified in the router bgp global configuration command identifies the neighbor as internal to the local autonomous system. Otherwise, the neighbor is considered external.
If you specify a BGP or multiprotocol BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.
By default, neighbors that are defined using the neighbor remote-as command in router configuration mode exchange only unicast address prefixes. To exchange other address prefix types, such as multicast and VPNv4, neighbors must also be activated using the neighbor activate command in address family configuration mode.
Examples
The following example specifies that a router at the address 131.108.1.2 is a neighbor in autonomous system number 109:
router bgp 110network 131.108.0.0neighbor 131.108.1.2 remote-as 109The following example assigns a BGP router to autonomous system 109, and two networks are listed as originating in the autonomous system. Then the addresses of three remote routers (and their autonomous systems) are listed. The router being configured will share information about networks 131.108.0.0 and 192.31.7.0 with the neighbor routers. The first router listed is in the same Class B network address space, but in a different autonomous system; the second neighbor remote-as command illustrates specification of an internal neighbor (with the same autonomous system number) at address 131.108.234.2; and the last neighbor remote-as command specifies a neighbor on a different network.
router bgp 109network 131.108.0.0network 192.31.7.0neighbor 131.108.200.1 remote-as 167neighbor 131.108.234.2 remote-as 109neighbor 150.136.64.19 remote-as 99The following example configures neighbor 131.108.1.1 in autonomous system 1 to exchange only multicast routes:
router bgp 109neighbor 131.108.1.1 remote-as 1neighbor 131.108 1.2 remote-as 1neighbor 2.2.2.2 remote-as 2address-family ipv4 multicastneighbor 131.108.1.1 activateneighbor 131.108.1.2 activateneighbor 2.2.2.2 activateThe following example configures neighbor 131.108.1.1 in autonomous system 1 to exchange only unicast routes:
router bgp 109neighbor 131.108.1.1 remote-as 1neighbor 131.108 1.2 remote-as 1neighbor 2.2.2.2 remote-as 2Related Commands
neighbor route-map
To apply a route map to incoming or outgoing routes, use the neighbor route-map command in address family or router configuration mode. To remove a route map, use the no form of this command.
neighbor {ip-address | peer-group-name} route-map route-map-name {in | out}
no neighbor {ip-address | peer-group-name} route-map route-map-name {in | out}
Syntax Description
ip-address
IP address of the neighbor.
peer-group-name
Name of a BGP or multiprotocol BGP peer group.
route-map-name
Name of route map.
in
Apply to incoming routes.
out
Apply to outgoing routes.
Defaults
No route maps are applied to a peer.
Command Modes
Address family configuration
Router configuration
Command History
10.0
This command was introduced.
12.0(7)T
Address family configuration mode was added.
Usage Guidelines
When specified in address family configuration mode, this command applies a route map to that particular address family only. When specified in router configuration mode, this command applies a route map to IPv4 unicast routes only.
If an outbound route map is specified, it is proper behavior to only advertise routes that match at least one section of the route map.
If you specify a BGP or multiprotocol BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command. Specifying the command for a neighbor overrides the inbound policy that is inherited from the peer group.
Examples
The following router configuration mode example applies a route map named internal-map to a BGP incoming route from 198.92.70.24:
router bgp 5neighbor 198.92.70.24 route-map internal-map inroute-map internal-mapmatch as-path 1set local-preference 100The following address family configuration mode example applies a route map named internal-map to a multiprotocol BGP incoming route from 198.92.70.24:
router bgp 5address-family ipv4 multicastneighbor 198.92.70.24 route-map internal-map inroute-map internal-mapmatch as-path 1set local-preference 100Related Commands
network (BGP and multiprotocol BGP)
To specify the networks to be advertised by the Border Gateway Protocol (BGP) and multiprotocol BGP routing processes, use the network command in address family or router configuration mode. To remove an entry, use the no form of this command.
network network-number [mask network-mask]
no network network-number [mask network-mask]
Syntax Description
network-number
Network that BGP or multiprotocol BGP will advertise.
mask
(Optional) Network or subnetwork mask.
network-mask
(Optional) Network mask address.
Defaults
No networks are specified.
Command Modes
Address family configuration
Router configuration
Command History
Usage Guidelines
BGP and multiprotocol BGP networks can be learned from connected routes, dynamic routing, and from static route sources.
The maximum number of network commands you can use is determined by the resources of the router, such as the configured NVRAM or RAM.
Examples
The following example sets up network 131.108.0.0 to be included in the BGP updates:
router bgp 120network 131.108.0.0The following example sets up network 131.108.0.0 to be included in the multiprotocol BGP updates:
router bgp 120address family ipv4 multicastnetwork 131.108.0.0Related Commands
redistribute dvmrp
To configure redistribution of Distance Vector Multicast Routing Protocol (DVMRP) routes into multiprotocol Border Gateway Protocol (BGP), use the redistribute dvmrp command in address family or router configuration mode. To stop such redistribution, use the no form of this command.
redistribute dvmrp [route-map map-name]
no redistribute dvmrp [route-map map-name]
Syntax Description
Defaults
DVMRP routes are not redistributed into multiprotocol BGP.
Command Modes
Address family configuration
Router configuration
Command History
11.1(20)CC
This command was introduced.
12.0(7)T
Address family configuration mode was added.
Usage Guidelines
Use this command if you have a subset of DVMRP routes in an autonomous system that you want to take the multiprotocol BGP path. Define a route map to further specify which DVMRP routes get redistributed.
Examples
The following router configuration mode example redistributes DVMRP routes to BGP peers that match access list 1:
router bgp 109redistribute dvmrp route-map dvmrp-into-mbgproute-map dvmrp-into-mbgpmatch ip address 1The following address family configuration mode example redistributes DVMRP routes to multiprotocol BGP peers that match access list 1:
router bgp 109address-family ipv4 multicastredistribute dvmrp route-map dvmrp-into-mbgproute-map dvmrp-into-mbgpmatch ip address 1set nlri
In Cisco IOS Release 12.0(7)T, the address-family ipv4 and address-family vpnv4 commands replace the set nlri command. See the descriptions of the address-family ipv4 or address-family vpnv4 command for more information.
show ip bgp ipv4 multicast
To display IPv4 multicast database-related information, use the show ip bgp ipv4 multicast EXEC command.
show ip bgp ipv4 multicast [command]
Syntax Description
command
(Optional) Any multiprotocol Border Gateway Protocol (BGP) command supported by the show ip bgp ipv4 multicast command.
Command Modes
EXEC
Command History
Usage Guidelines
Use this command in conjunction with the show ip rpf command to determine if IP multicast routing is using multiprotocol BGP routes.
To determine which multiprotocol BGP commands are supported by the show ip bgp ipv4 multicast command, enter the following while in EXEC mode:
Router# show ip bgp ipv4 multicast ?The show ip bgp ipv4 multicast command replaces the show ip mbgp command.
Examples
The following is sample output from the show ip bgp ipv4 multicast command:
Router# show ip bgp ipv4 multicastMBGP table version is 6, local router ID is 192.168.200.66Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*> 10.0.20.16/28 0.0.0.0 0 0 32768 i*> 10.0.35.16/28 0.0.0.0 0 0 32768 i*> 10.0.36.0/28 0.0.0.0 0 0 32768 i*> 10.0.48.16/28 0.0.0.0 0 0 32768 i*> 10.2.0.0/16 0.0.0.0 0 0 32768 i*> 10.2.1.0/24 0.0.0.0 0 0 32768 i*> 10.2.2.0/24 0.0.0.0 0 0 32768 i*> 10.2.3.0/24 0.0.0.0 0 0 32768 i*> 10.2.7.0/24 0.0.0.0 0 0 32768 i*> 10.2.8.0/24 0.0.0.0 0 0 32768 i*> 10.2.10.0/24 0.0.0.0 0 0 32768 i*> 10.2.11.0/24 0.0.0.0 0 0 32768 i*> 10.2.12.0/24 0.0.0.0 0 0 32768 i*> 10.2.13.0/24 0.0.0.0 0 0 32768 iTable 2 describes the significant fields shown in the display.
Related Commands
show ip bgp ipv4 multicast summary
To display a summary of IPv4 multicast database-related information, use the show ip bgp ipv4 multicast summary EXEC command.
show ip bgp ipv4 multicast summary
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
The show ip bgp ipv4 multicast summary command replaces the show ip mbgp summary command.
Examples
The following is sample output from the show ip bgp ipv4 multicast summary command:
Router# show ip bgp ipv4 multicast summaryBGP router identifier 10.0.33.34, local AS number 34BGP table version is 5, main routing table version 14 network entries and 6 paths using 604 bytes of memory5 BGP path attribute entries using 260 bytes of memory1 BGP AS-PATH entries using 24 bytes of memory2 BGP community entries using 48 bytes of memory2 BGP route-map cache entries using 32 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP activity 8/28 prefixes, 12/0 paths, scan interval 15 secsNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.0.33.35 4 35 624 624 5 0 0 10:13:46 3Table 3 describes the significant fields shown in the display.
Related Commands
show ip mbgp
In Cisco IOS Release 12.0(7)T, the show ip bgp ipv4 multicast command replaces the show ip mbgp command. See the description of the show ip bgp ipv4 multicast command for more information.
show ip mbgp summary
In Cisco IOS Release 12.0(7)T, the show ip bgp ipv4 multicast summary command replaces the show ip mbgp summary command. See the description of the show ip bgp ipv4 multicast summary command for more information.
Debug Commands
This section documents new debug commands. All other commands used with multiprotocol Border Gateway Protocol (BGP) are documented in the Cisco IOS Release 12.1 command reference publications.
debug ip mbgp dampening
To log route flap dampening activity related to multiprotocol Border Gateway Protocol (BGP), use the debug ip mbgp dampening privileged EXEC command. To disable debugging output, use the no form of this command.
debug ip mbgp dampening [access-list-number]
no debug ip mbgp dampening [access-list-number]
Syntax Description
access-list-number
(Optional) Number of an access list in the range from 1 to 99. If an access list number is specified, debugging occurs only for the routes permitted by the access list.
Defaults
Logging for route flap dampening activity is not enabled.
Command History
Examples
The following example shows sample debug ip mbgp dampening output:
Router# debug ip mbgp dampeningBGP: charge penalty for 173.19.0.0/16 path 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000BGP: charge penalty for 173.19.0.0/16 path 19 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000debug ip mbgp updates
To log multiprotocol Border Gateway Protocol (BGP) -related information passed in BGP Update messages, use the debug ip mbgp updates privileged EXEC command. To disable debugging output, use the no form of this command.
debug ip mbgp updates
no debug ip mbgp updates
Syntax Description
This command has no arguments or keywords.
Defaults
Logging for multiprotocol BGP-related information in BGP Update messages is not enabled.
Command History
Examples
The following example shows sample debug ip mbgp updates output:
Router# debug ip mbgp updatesBGP: NEXT_HOP part 1 net 200.10.200.0/24, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 send UPDATE 200.10.200.0/24, next 171.69.233.34, metric 0, path 33 34 19 49 109 65000 297 3561 6503BGP: NEXT_HOP part 1 net 200.10.202.0/24, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 send UPDATE 200.10.202.0/24, next 171.69.233.34, metric 0, path 33 34 19 49 109 65000 297 1239 1800 3597BGP: NEXT_HOP part 1 net 200.10.228.0/22, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 rcv UPDATE about 222.2.2.0/24, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 131.103.0.0/16, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 206.205.242.0/24, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 1.0.0.0/8, next hop 171.69.233.49, path 49 19 metric 0BGP: 171.69.233.49 rcv UPDATE about 198.1.2.0/24, next hop 171.69.233.49, path 49 19 metric 0BGP: 171.69.233.49 rcv UPDATE about 171.69.0.0/16, next hop 171.69.233.49, path 49 metric 0BGP: 171.69.233.49 rcv UPDATE about 172.19.0.0/16, next hop 171.69.233.49, path 49 metric 0BGP: nettable_walker 172.19.0.0/255.255.0.0 calling revise_routeBGP: revise route installing 172.19.0.0/255.255.0.0 -> 171.69.233.49BGP: 171.69.233.19 computing updates, neighbor version 267099, table version 267100, starting at 0.0.0.0BGP: NEXT_HOP part 1 net 172.19.0.0/16, neigh 171.69.233.19, next 171.69.233.49BGP: 171.69.233.19 send UPDATE 172.19.0.0/16, next 171.69.233.49, metric 0, path 33 49BGP: 1 updates (average = 46, maximum = 46)BGP: 171.69.233.19 updates replicated for neighbors : 171.69.233.34, 171.69.233.49, 171.69.233.56BGP: 171.69.233.19 1 updates enqueued (average=46, maximum=46)BGP: 171.69.233.19 update run completed, ran for 0ms, neighbor version 267099, start version 267100, throttled to 267100, check point net 0.0.0.0Glossary
Distance Vector Multicast Routing Protocol—See DVMRP.
DVMRP—Distance Vector Multicast Routing Protocol. Internetwork gateway protocol, largely based on RIP, that implements a typical dense mode IP multicast scheme. DVMRP uses IGMP to exchange routing datagrams with its neighbors.
multiprotocol BGP—multiprotocol Border Gateway Protocol. Multiprotocol BGP is an enhancement of BGP that enables the protocol to specify particular NLRI information for IPv4, IP multicast, and VPNv4. The ability to specify particular NLRI information allows the configuration of different routing policies for each network layer family.
multiprotocol Border Gateway Protocol—See multiprotocol BGP.
network layer reachability information—See NLRI.
NLRI—network layer reachability information. An indication, in the form of an IP prefix route, of the networks being advertised. (The IP prefix is an IP network address with an indication of the number of bits (left to right) that constitute the network number.) The NLRI consists of multiple instances of the 2-tuples (length, prefix) where length is the number of masking bits that a particular prefix has. In BGP4, the NLRI is the mechanism that supports classless routing (see RFC 2283, Multiprotocol Extensions for BGP-4).
PIM—Protocol Independent Multicast. Multicast routing architecture that allows the addition of IP multicast routing on existing IP networks. PIM is unicast routing protocol independent and can be operated in two modes: dense and sparse. See also PIM dense mode and PIM sparse mode.
PIM dense mode—See PIM DM.
PIM DM—PIM dense mode. One of the two PIM operational modes. PIM dense mode is data-driven and resembles typical multicast routing protocols. Packets are forwarded on all outgoing interfaces until pruning and truncation occurs. In dense mode, receivers are densely populated, and it is assumed that the downstream networks want to receive and probably will use the datagrams that are forwarded to them. The cost of using dense mode is its default flooding behavior. Sometimes called dense mode PIM. Contrast with PIM sparse mode. See also PIM.
PIM SM—PIM sparse mode. One of the two PIM operational modes. PIM sparse mode tries to constrain data distribution so that a minimal number of routers in the network receive it. Packets are sent only if they are explicitly requested at the rendezvous point (RP). In sparse mode, receivers are widely distributed, and the assumption is that downstream networks will not necessarily use the datagrams that are sent to them. The cost of using sparse mode is its reliance on the periodic refreshing of explicit Join messages and its need for RPs. Sometimes called sparse mode PIM. Contrast with PIM dense mode. See also PIM.
PIM sparse mode—See PIM SM.
Protocol Independent Multicast—See PIM.
Reverse-Path Forwarding—See RPF.
RPF—Reverse Path Forwarding. Multicasting technique in which a multicast datagram is forwarded out of all but the receiving interface if the receiving interface is the one used to forward unicast datagrams to the source of the multicast datagram.
Guest
