All things related to multicast

[Peter John Hill <>]

Totally been there and done that. We just got everything stable a few 
weeks ago. Give me a call if you want to discuss it

412.268.4932

I hope that the information below is helpful, and correct. If anyone 
sees any errors, please correct me. Look below for the ALL CAPS part 
for an important thing to check.


We are using auto-rp with anycast and sparse mode. It is #10 as 
described in:
http://www.cisco.com/warp/public/cc/pd/iosw/tech/rppim_rg.htm

Here is our setup:

We are mbgp peered with our provider:
router bgp 9

<snip>
 !
 address-family ipv4 multicast
 neighbor 192.88.115.185 activate
 network 128.2.0.0
 network 128.237.0.0
 exit-address-family

We then MSDP Peer with our two core routers: (all this config is on our 
border router)

ip pim rp-address 128.2.1.130 30   (this is the anycast rp address 
described below)
ip msdp peer 192.88.115.185 connect-source Vlan3
ip msdp sa-filter in 192.88.115.185 list 111
ip msdp sa-filter out 192.88.115.185 list 111
ip msdp peer 128.2.4.249 connect-source Loopback0
ip msdp peer 128.2.4.250 connect-source Loopback0
!
!  We have an internal msdp mesh group of our border router and two 
core routers
!  MSDP is used to synchronize mulitcast SA information (i think)
!  We are using the MBGP to exchange multicast routing information, 
this is a separate
!  function from MSDP. I believe the MBGP is used in case you want to 
have your multicast
! come in a different path than your normal unicast traffic. (I think 
this is correct, but I could be wrong)
!
ip msdp mesh-group CMU-MSDP 128.2.4.249
ip msdp mesh-group CMU-MSDP 128.2.4.250
ip msdp cache-sa-state


So On our core routers we are doing the following:
We create a anycast loopback on both of our core routers:
interface Loopback1
 description Anycast RP Interface
 ip address 128.2.1.130 255.255.255.255
 ip pim sparse-mode

Then

ip pim rp-address 128.2.1.130 30
ip pim rp-candidate Loopback0 group-list 11
ip pim send-rp-announce Loopback0 scope 32 group-list 11
ip pim send-rp-discovery Loopback0 scope 32
ip msdp peer 128.2.4.248 connect-source Loopback0 remote-as 9
ip msdp peer 128.2.4.250 connect-source Loopback0 remote-as 9
ip msdp mesh-group CMU-MSDP 128.2.4.248
ip msdp mesh-group CMU-MSDP 128.2.4.250
ip msdp cache-sa-state
ip msdp originator-id Loopback0

So because we are operating in sparse mode, we are using the anycast rp 
address to allow the leaf routers to locate the rp. This allows us not 
to run dense mode, or sparse-dense-mode.

If I do:
[6509]core0.gw #show ip pim rp map in
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is a candidate RP (v2)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4       (<------------   These are the rps for all 
multicast)
  RP 128.2.4.250 (CORE255.GW.CMU.NET), v2v1
    Info source: 128.2.4.250 (CORE255.GW.CMU.NET), via Auto-RP
         Uptime: 1w4d, expires: 00:02:29
  RP 128.2.4.249 (CORE0.GW.CMU.NET), v2v1
    Info source: 128.2.4.249 (CORE0.GW.CMU.NET), via Auto-RP
         Uptime: 1w5d, expires: 00:02:22
Group(s) (-)224.0.1.39/32   (<----------These two are for getting the 
rp address to the leaf routers, notice the minus sign next to them, 
indicating that they will not be used, due to an access list we have)
  RP 128.2.4.250 (CORE255.GW.CMU.NET), v2v1
    Info source: 128.2.4.250 (CORE255.GW.CMU.NET), via Auto-RP
         Uptime: 1w4d, expires: never
  RP 128.2.4.249 (CORE0.GW.CMU.NET), v2v1
    Info source: 128.2.4.249 (CORE0.GW.CMU.NET), via Auto-RP
         Uptime: 1w5d, expires: never
Group(s) (-)224.0.1.40/32
  RP 128.2.4.250 (CORE255.GW.CMU.NET), v2v1
    Info source: 128.2.4.250 (CORE255.GW.CMU.NET), via Auto-RP
         Uptime: 1w4d, expires: never
  RP 128.2.4.249 (CORE0.GW.CMU.NET), v2v1
    Info source: 128.2.4.249 (CORE0.GW.CMU.NET), via Auto-RP
         Uptime: 1w5d, expires: never
Acl: 30, Static
    RP: 128.2.1.130 (ANYCAST-RP.net.cmu.edu)

RPs in Auto-RP cache that are in use:
Group(s): 224.0.0.0/4,   RP: 128.2.4.250
Group(s): (-)224.0.1.39/32,   RP: 128.2.4.250
Group(s): (-)224.0.1.40/32,   RP: 128.2.4.250

Here is the access list that prevents the 224.0.1.39 and 40 from 
becoming rps ( I think):
Standard IP access list 10
    deny   224.0.1.39
    deny   224.0.1.40
    permit 224.0.0.0, wildcard bits 15.255.255.255


So on the leaf routers, this is what we have:
[6509]sysdev.gw #show ip pim rp map in
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 128.2.4.250 (CORE255.GW.CMU.NET), v2v1
    Info source: 128.2.4.249 (CORE0.GW.CMU.NET), via Auto-RP
         Uptime: 1w1d, expires: 00:02:48
Acl: 30, Static
    RP: 128.2.1.130 (ANYCAST-RP.net.cmu.edu)

RPs in Auto-RP cache that are in use:
Group(s): 224.0.0.0/4,   RP: 128.2.4.250

And here are config bits:
ip multicast-routing
ip pim rp-address 128.2.1.130 30
access-list 30 permit 224.0.1.39
access-list 30 permit 224.0.1.40

Each interface has:
interface VlanX
 ip pim sparse-mode
 ip cgmp
----------------------------------

One thing to check for that we missed... We have a layer two core (two 
actually) and we had inadvertently turned on igmp snooping on the 
switch side of our cores. That totally messed up our entire multicast 
network. MAKE SURE THAT YOU DO NOT HAVE IGMP SNOOPING TURNED ON IN YOUR 
CORE!!!!!!!! ONLY WHERE YOU HAVE HOSTS

So here is a glossary:
RP  rendezvous point  It is like a bar where a multicast stream and 
multicast clients go to meet. Once the meet, then the intermediate 
routers start to build a shortest path tree (as opposed to the shared 
tree that they start out using).

MSDP  multicast session discovery protocol   it is a way for your rp to 
find out about multicast streams.

PIM   this is a way for leaf routers to learn about multicast streams 
from the RP

auto-rp  this is a way for leaf routers to discover who the RP is

MBGP  is the multicast extensions to bgp that allow for exchanging info 
on multicast routes.

sparse mode   vs dense mode:  Dense mode floods then prunes, whereas 
sparse mode only starts sending traffic when a leaf router tells it to.

leaf router   a router that is not an rp, but knows about the rp (or 
can find out about it)


Like I said, others, please correct my errors, and Richard, call me if 
you have questions, or email me.

Peter Hill
Network Engineer
Carnegie Mellon University



On Tuesday, September 3, 2002, at 11:25  PM, Richard Murphy wrote:

> I have followed the Abilene cookbook on setting up multicasting and all
> looks OK on my border router. However, machines on a router connected 
> to
> the border router cannot join any multicast groups. The border router 
> is
> logging these PIM-INVALID_RP_JOIN messages. I have read the cisco note
> on fixing this issue and it leads to this question:
>
> How does auto-rp work if the Abilene recommended filter for multicast
> groups
> includes 224.0.1.39 and 224.0.1.40 as denies? Are RPs something that is
> used in lieu of MSDP or alone with MSDP? Both routers have pim
> sparse-mode set, but the second router uses some static routes, not 
> iBGP
> and does not use MSDP either.
>
> Thanks to those who have been down this path already!
>
> Richard Murphy