Multicast BGP

Feature Summary

Platforms

Prerequisites

Supported MIBs and RFCs

Configuration Tasks

Configuration Examples

Command Reference

Debug Commands

It is possible to configure BGP peers that exchange both unicast and multicast network layer reachability information (NLRI).

MBGP 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). MBGP allows you to have a unicast routing topology different from a multicast routing topology. Thus, you have more control over your network and resources.

Prior to MBGP, the only way to do interdomain multicast routing was to use the BGP infrastructure that was in place for unicast routing. If those routers were not multicast capable, or you had differing policies where you wanted multicast traffic to flow, you could not support it.

• An internet can support incongruent unicast and multicast topologies.

• An internet can support congruent unicast and multicast topologies that have different policies (BGP filtering configurations).

• All of the routing policy capabilities of BGP can be applied to MBGP.

• All of the BGP commands can be used with MBGP.

IP multicast routing needs to know which route to use if a multicast source is found in any of the following:

• A unicast routing table (which includes tables for IP routing protocols, including BGP external, internal, and local routes)

• An MBGP routing table (which includes external, internal, and local routes)

• A DVMRP routing table

• A static mroute table

The administrative distance allows you to control which routing table you prefer, so keep all of these tables in mind. You can change the administrative distance of MBGP routes, thus making the MBGP routing table preferred over any other table the router is maintaining. If you are running a router with both unicast BGP and MBGP, you should set distances to prefer MBGP.

To change the administrative distances, perform the following task in router configuration mode. Changing the administrative distance of MBGP internal routes is not recommended. One problem that can arise is the accumulation of routing table inconsistencies, which can break routing.

Change any of the MBGP administrative distances (external distance, internal distance, local distance).

distance mbgp external-distance internal-distance local-distance

Syntax Description

Default

Disabled

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 10.0. The nlri keywords first appeared in Cisco IOS Release 11.1(20)CC.

You can implement aggregate routing in BGP either by redistributing an aggregate route into 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 routing table if there are any more-specific BGP routes available that fall in the specified range. The aggregate route will be advertised as coming from your autonomous system and has 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 aggregate-address when aggregating many paths, because this route must be continually withdrawn and re-updated 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 will also suppress 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 speakers 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, an aggregate address is created. The path advertised for this route will be an AS_SET consisting of all elements contained in all paths that are being summarized.

router bgp 5

  aggregate-address 193.0.0.0 255.0.0.0 as-set

In the following MBGP example, an aggregate address is created and applied to the multicast RIB only. More-specific routes are filtered from updates.

router bgp 5

  aggregate-address 193.0.0.0 255.0.0.0 summary-only nlri multicast

Related Commands

match as-path
match ip address
route-map

Syntax Description

Default

external-distance: 20
internal-distance: 200
local-distance: 200

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

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 an integer between 0 and 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 when one router is running both unicast BGP and MBGP. 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 MBGP, or if some internal routes should really be preferred by MBGP.

Caution Changing the administrative distance of MBGP internal routes should be done with caution. One problem that can arise is the accumulation of routing table inconsistencies, which can break routing.

The three distance arguments in the command syntax are position dependent; therefore, you must specify a value for all three, even if two of them are the default values.

Example

The following example configures the router to prefer MBGP routes (external, internal, and local) over BGP routes.

router bgp 109
  distance bgp 200 200 200
  distance mbgp 0 0 0

Related Commands

distance bgp

Syntax Description

Default

No metric is preconfigured. Only directly connected subnets and networks are advertised to neighboring DVMRP routers.

Command Mode

Interface configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 10.2. The route-map keyword first appeared in Cisco IOS Release 11.1. The mbgp keyword first appeared in Cisco IOS Release 11.1(20)CC.

When 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.255
access-list 1 deny 0.0.0.0 255.255.255.255
access-list 2 permit 0.0.0.0 255.255.255.255
interface tunnel 0
  ip dvmrp metric 1 list 1
  ip dvmrp metric 0 list 2

The following example redistributes MBGP routes to DVMRP neighbors with a metric of 1:

interface tunnel 0
  ip dvmrp metric 1 mbgp

Related Commands

debug ip dvmrp
ip dvmrp accept-filter

Syntax Description

Default

Disabled

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1. The rtp keyword was added in Release 11.1(20)CC.

You can store IP multicast packet headers in a cache and then display them to determine the following:

• Who is sending IP multicast packets to what groups

• Inter-packet delay

• Duplicate IP multicast packets (if any)

• Multicast forwarding loops in your network (if any)

• Scope of the group

• UDP port numbers

• Packet length

Use the show ip mpacket command to display the buffer.

Example

The following example allocates a buffer to store IP multicast packet headers:

ip multicast cache-headers

Related Commands

Syntax Description

Default

The default is unicast multicast, meaning that either a unicast or multicast RIB entry will match.

Command Mode

Route-map configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

This command can be used in conjunction with the neighbor route-map in command so you can use one route-map reference to describe filtering policies for different NLRI types.

After stating the match criteria, use any of the set commands in the "Configuring BGP" chapter or the "Configuring IP Routing Protocol-Independent Features" chapter of the Cisco IOS Release 11.3 Network Protocols Configuration Guide, Part 1.

Example

In the following example, any multicast routes (because of the match nlri multicast command) from neighbor 1.1.1.1 will be accepted if they match access list 1:

router bgp 109
  neighbor 1.1.1.1 remote-as 1 nlri unicast multicast
  neighbor 1.1.1.1 route-map in filter-some-multicast
route-map filter-some-multicast
  match nlri multicast
  match ip address 1

Related Commands

route-map

Syntax Description

Default

There is no BGP peer group. If a peer group is identified, but no NLRI designation is specified, the default is nlri unicast.

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.0. The nlri {unicast | multicast | unicast multicast} keywords first appeared in Release 11.1(20)CC.

Often in a BGP speaker, there are many neighbors 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.

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 can also 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 EBGP neighbors.

Use the nlri keyword with either unicast, multicast, or unicast multicast to specify what type of traffic the peer group can support.

Example for an 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, AS 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 100
  neighbor internal peer-group
  neighbor internal remote-as 100
  neighbor internal update-source loopback 0
  neighbor internal route-map set-med out
  neighbor internal filter-list 1 out
  neighbor internal filter-list 2 in
  neighbor 171.69.232.53 peer-group internal
  neighbor 171.69.232.54 peer-group internal
  neighbor 171.69.232.55 peer-group internal
  neighbor 171.69.232.55 filter-list 3 in

Example for an EBGP Peer Group

In the following example, the peer group external-peers is defined without the neighbor remote-as command. This is what makes it an EBGP peer group. Each individual member of the peer group is configured with its respective AS-number separately. Thus the peer group consists of members from autonomous systems 200, 300, and 400. All the peer group members have 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 100
  neighbor external-peers peer-group
  neighbor external-peers route-map set-metric out
  neighbor external-peers filter-list 99 out
  neighbor external-peers filter-list 101 in
  neighbor 171.69.232.90 remote-as 200
  neighbor 171.69.232.90 peer-group external-peers
  neighbor 171.69.232.100 remote-as 300
  neighbor 171.69.232.100 peer-group external-peers
  neighbor 171.69.232.110 remote-as 400
  neighbor 171.69.232.110 peer-group external-peers
  neighbor 171.69.232.110 filter-list 400 in

Example for an MBGP Peer Group

In the following example, all members of the peer group are both unicast and multicast NLRI-capable.

router bgp 100
  neighbor mygroup peer-group nlri unicast multicast
  neighbor 1.1.1.1 remote-as 1
  neighbor 1.1.1.1 peer-group mygroup
  neighbor 2.2.2.2 remote-as 2
  neighbor 2.2.2.2 peer-group mygroup

Related Commands

clear ip bgp peer-group
neighbor peer-group (assigning members)
show ip bgp peer-group

Syntax Description

Default

There are no BGP neighbor peers. If a neighbor is identified, but no NLRI designation is specified, the default is nlri unicast.

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 10.0. The peer-group-name argument first appeared in Cisco IOS Release 11.0. The nlri {unicast | multicast | unicast multicast} keywords first appeared in Release 11.1(20)CC.

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 peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

If multicast BGP is configured, multicast NLRI is sent in the MP_REACH and MP_UNREACH path attributes. MBP negotiates NLRI in the Capabilities Option of the Open message. Both sides of the BGP connection don't have to be configured consistently. If one side is unicast and multicast, and the other side is multicast only, the session will come up in multicast-only mode.

The only time the connection won't come up is when one side is multicast-only and the other is unicast-only.

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 110
  network 131.108.0.0
  neighbor 131.108.1.2 remote-as 109

In the following example, a BGP router is assigned 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 command illustrates specification of an internal neighbor (with the same autonomous system number) at address 131.108.234.2; and the last neighbor command specifies a neighbor on a different network.

router bgp 109
  network 131.108.0.0
  network 192.31.7.0
  neighbor 131.108.200.1  remote-as 167
  neighbor 131.108.234.2  remote-as 109
  neighbor 150.136.64.19  remote-as  99

The following example configures neighbor 131.108.1.1 in AS 1 to exchange only multicast routes. It configures neighbor 131.108.1.2 in AS 1 to exchange both multicast and unicast routes.

router bgp 109
  neighbor 131.108.1.1 remote-as 1 nlri multicast
  neighbor 131.108 1.2 remote-as 1 nlri multicast unicast
  neighbor 2.2.2.2 remote-as 2 nlri multicast

Related Commands

Syntax Description

Default

No networks are specified.

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 10.0. The nlri {unicast | multicast | unicast multicast} keywords first appeared in Release 11.1(20)CC.

These types of networks can be learned from connected routes, dynamic routing, and from static route sources.

A maximum of 200 network commands may be specified for a single BGP process.

Examples

The following example sets up network 131.108.0.0 to be included in the BGP updates:

router bgp 120
  network 131.108.0.0

The following example advertises neighbor 131.108.0.0 with the mask to its multicast peers with a local origin attribute. It advertises neighbor 131.140.0.0 with the mask to multicast and unicast peers with a local origin attribute.

router bgp 120
  network 131.108.0.0 mask 255.255.0.0 nlri multicast
  network 131.140.0.0 mask 255.255.0.0 nlri multicast unicast
  neighbor 131.150 0.0 mask 255.255.0.0

Related Commands

network backdoor
network mask
network weight
router bgp

Syntax Description

Default

DVMRP routes are not redistributed into MBGP.

Command Mode

Router configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

Use this command if you have a subset of DVMRP routes in an autonomous system that you want to have take the multicast BGP path. Define a route-map to further specify which DVMRP routes get redistributed.

Example

The following example redistributes DVMRP routes to BGP peers that match access list 1:

router bgp 109
  redistribute dvmrp route-map dvmrp-into-mbgp
route-map dvmrp-into-mbgp
  match ip address 1
  set nlri multicast

Syntax Description

Default

unicast

Command Mode

Route-map configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

If both unicast and multicast are specified, the route is injected into both RIBs and advertised as separate NLRI in a BGP Update message. This command is used when referencing a route-map by various router configuration commands, such as redistribute, aggregate-address, and neighbor route-map out references.

This command can be used in conjunction with the neighbor default-originate route-map command. If the set nlri is supplied in the route-map referenced by the neighbor command, the multicast default route can be generated independent of the unicast default route.

Example

The following example redistributes OSPF routes to MBGP peers (because of the set nlri multicast command) that match access list 1:

router bgp 109
  redistribute ospf 109 route-map ospf-into-mbgp
route-map ospf-into-mbgp
  match ip address 1
  set nlri multicast

Related Commands

route-map

Syntax Description

Command Mode

EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20) CC.

Use this command in conjunction with the show ip rpf command to determine if IP multicast routing is using MBGP routes.

Sample Display

The following is sample output from the show ip mbgp command:

Router# show ip mbgp

MBGP table version is 605299, local router ID is 198.9.200.66
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop          Metric LocPrf Weight Path
*> 4.0.20.16/28     0.0.0.0                0      0      0 i
*> 4.0.35.16/28     0.0.0.0                0      0      0 i
*> 4.0.36.0/28      0.0.0.0                0      0      0 i
*> 4.0.48.16/28     0.0.0.0                0      0      0 i
*> 9.2.0.0/16       0.0.0.0                0      0      0 i
*> 9.2.1.0/24       0.0.0.0                0      0      0 i
*> 9.2.2.0/24       0.0.0.0                0      0      0 i
*> 9.2.3.0/24       0.0.0.0                0      0      0 i
*> 9.2.7.0/24       0.0.0.0                0      0      0 i
*> 9.2.8.0/24       0.0.0.0                0      0      0 i
*> 9.2.10.0/24      0.0.0.0                0      0      0 i
*> 9.2.11.0/24      0.0.0.0                0      0      0 i
*> 9.2.12.0/24      0.0.0.0                0      0      0 i
*> 9.2.13.0/24      0.0.0.0                0      0      0 i

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

Sample Display

The following is sample output from the show ip mbgp summary command.

Router# show ip mbgp summary

MBGP table version is 605471
6521 network entries (6522/19563 paths) using 1458596 bytes of memory
9 BGP path attribute entries using 1048 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
0 prefixes revised.
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
198.9.200.65    4 10888   44088  110375   605471    0    0 3d00h           7
198.9.201.2     4    24   41919  119758   605471    0    0 4d07h           8

Syntax Description

Command Mode

EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.1(20)CC.

Use this command to monitor loss characteristics of a multimedia stream. Note the following restrictions:

• This command is available only if the ip multicast cache-headers rtp command is configured to capture RTP headers.

• Only non-encrypted multimedia streams can be monitored.

Sample Display

The following is sample output from the show ip mpacket quality command:

Router# show ip mpacket 224.2.163.188 quality

Calculating RTP data quality for 224.2.163.188
  Session: UO Presents KKNU New Country
  Source: 128.223.83.27 (sand.uoregon.edu), Port: 23824
    Packets received: 83, lost: 5, loss percentage: 5.6%
    Packets misordered: 7, average loss gap: 0

Syntax Description

Sample Display

Router# debug ip mbgp dampening

BGP: charge penalty for 173.19.0.0/16 path 49 with halflife-time 15 reuse/suppress 
750/2000
BGP: flapped 1 times since 00:00:00. New penalty is 1000
BGP: charge penalty for 173.19.0.0/16 path 19 49 with halflife-time 15 reuse/suppress 
750/2000
BGP: flapped 1 times since 00:00:00. New penalty is 1000

Sample Display

Router# debug ip mbgp updates

BGP: NEXT_HOP part 1 net 200.10.200.0/24, neigh 171.69.233.49, next 171.69.233.34
BGP: 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 6503
BGP: NEXT_HOP part 1 net 200.10.202.0/24, neigh 171.69.233.49, next 171.69.233.34
BGP: 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 3597
BGP: NEXT_HOP part 1 net 200.10.228.0/22, neigh 171.69.233.49, next 171.69.233.34
BGP: 171.69.233.49 rcv UPDATE about 222.2.2.0/24, next hop 171.69.233.49, path 49 109 
metric 0
BGP: 171.69.233.49 rcv UPDATE about 131.103.0.0/16, next hop 171.69.233.49, path 49 109 
metric 0
BGP: 171.69.233.49 rcv UPDATE about 206.205.242.0/24, next hop 171.69.233.49, path 49 
109 metric 0
BGP: 171.69.233.49 rcv UPDATE about 1.0.0.0/8, next hop 171.69.233.49, path 49 19 
metric 0
BGP: 171.69.233.49 rcv UPDATE about 198.1.2.0/24, next hop 171.69.233.49, path 49 19 
metric 0
BGP: 171.69.233.49 rcv UPDATE about 171.69.0.0/16, next hop 171.69.233.49, path 49 
metric 0
BGP: 171.69.233.49 rcv UPDATE about 172.19.0.0/16, next hop 171.69.233.49, path 49 
metric 0
BGP: nettable_walker 172.19.0.0/255.255.0.0 calling revise_route
BGP: revise route installing 172.19.0.0/255.255.0.0 -> 171.69.233.49
BGP: 171.69.233.19 computing updates, neighbor version 267099, table version 267100, 
starting at 0.0.0.0
BGP: NEXT_HOP part 1 net 172.19.0.0/16, neigh 171.69.233.19, next 171.69.233.49
BGP: 171.69.233.19 send UPDATE 172.19.0.0/16, next 171.69.233.49, metric 0, path 33 49
BGP: 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.56
BGP: 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.0