Darren's Blog

Sparse mode:

• When user joins, connected router will have *,G entry, as it knows the group joined by the user, but not the source of that feed yet. This is the SHARED tree.
• The RP WILL have an S,G entry. Once the router connects it will stay on the *,G shared tree at first, then switch over to the S,G source tree.
• While on the shared tree, the RPF check will be towards the RP, NOT the source! This will change to the source once the router connects to the source tree
• ip pim spt threshold controls when the router will switch from the *,G to the S,G tree. A value of infinity means it’ll NEVER switch to the S,G tree

Dense mode:

• In dense mode you’ll always see S,G entries as the source has been flooded through the network. i.e. all PIM routers will already have the feed, and hence will know the source

Sparse-Dense mode:

• Sparse-dense mode is mainly like sparse mode, but any group that cannot be registered with the RP becomes dense mode
• This is good for Auto-RP, but it also means that mis-configurations on the RP could cause lots of groups to be dense mode instead of sparse mode

Rendezvous point:

All modes:

• You need to run PIM on the interface that you are advertising as the RP. i.e if you’re running it on a loopback interface, run PIM on that loopback!
• Auto assignments OVERRIDE static assignments! You can use ip pim rp-address (rp_address) (acl) override to override this default behaviour

Static RP:

• Easiest to configure, pretty much like a static route
• ip pim rp-address (rp_address) (acl)
• (acl) determines what groups the router will be the RP for
• The RP router ALSO needs to have the above configured. i.e the RP does not automatically know it is the RP, you need to tell the router that it is!

Auto-RP (Cisco proprietary):

• Auto-RP is made up of 1 or more routers announcing themselves as candidate RPs using the command: ip pim send-rp-announce (acl) as well as a mapping agent using the command: ip pim send-rp-discovery
• Only the mapping agent listens to the RP announcements
• The MA then determines which RP to use for which groups and advertises that to all other PIM routers
• The auto-rp process uses the 224.0.1.39 and 224.0.1.40 groups
• In sparse-dense mode the 2 groups above are automatically in dense mode
• If running sparse mode only, you need to configure ip pim auto-rp listener on transit PIM interfaces which will ensure that ONLY 224.0.1.39 and 224.0.1.40 are in dense mode
• If the MA receives 2 announcements from candidate RPs for the same groups, the MA will choose the one with the highest IP address
• The RP and MA can be the same device if needs be
• Auto-RP IS supported by a number of Non Cisco devices. Confirm with proctor is question is not clear
• When specifying an ACL with a RP announcement, the deny statements will create negative entries for groups. However a deny any at the end of the ACL will effectively make ALL groups negative, and hence dense mode, regardless of what’s configured. As an example:

ip pim send-rp-announce Loopback0 scope 15 group-list 12 interval 1
access-list 12 deny 224.110.110.110
access-list 12 permit 224.0.0.0 15.255.255.255
access-list 12 deny any

If you check the mapping agent you see this:

Group(s) (-)224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Once the deny statement at the end of the ACL is removed, you see this:

Group(s) 224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Bootstrap router – BSR (Open standard)

• BSR uses the group 224.0.0.13, but it does NOT need to be in dense mode, unlike auto-rp
• 224.0.0.13 is the link-local ALL PIM ROUTERS address as well
• The Bootstrap router is the Mapping Agent in auto-rp, configured using: ip pim bsr-candidate (int) (hash) (pri)
• The RP uses the same name as in auto-rp, configured using: ip pim rp-candidate (int) (ttl) (pri) (acl)
• The hash field will allow you to load balance groups over your RPs – A hash value of 31 ensures all even groups are with on RP and odds are with another, if you have 2 RPs
• You can see which group is mapped to which RP with show ip pim rp-hash (group)
• BSR has priority fields so you can choose which router does what without having to rely on the high IP taking over
• If priority is the same, then highest IP will be chosen like auto-rp
• ip pim bsr-border will allow you to run PIM on an edge interface, but not to share bsr messages

Multicast on Frame-Relay:

• By default, multicast traffic is process switched over frame-relay. Multicast frames also have the pak-priority set so have the highest priority
• If you have a hub router connected to 2 spokes over the same interface, you’ll have problem with RPF checks as you are going in and out the same interface. You can also have problem where a spoke says it no longer wants to receive a feed, this would make the hun stop sending to ALL spokes.
• ip pim nbma-mode fixes both of the above issues. When configuring nbma mode on sparse-dense and dense mode interfaces you’ll get a warning, but it’ll still work.

Multicast Boundry:

• int# ip multicast-boundry will stop multicast packets getting through an interface.
• Any address ALLOWED through the acl is ALLOWED through the interface
• The boundry is bidirectional by default. If you specify the IN option it will prevent multicast control traffic coming into the interface. If you specify the OUT option it will prevent the interface from being added to the OIL

Stub Multicast:

• Prevent routers from fully participating in PIM. Consider the diagram:

• R2 has users on the Fa0/0 interface that want to join the multicast feed. However you do not want R2 to fully run PIM. In order to do so, you need to have R1 configured to prevent R2 from becoming a PIM neighbour. You need then to configure R2 to forward IGMP join messages to R1. Note that dense mode is configured on R2 as it needs to flood multicast traffic over to fa0/0 when it gets an igmp join.

R1:
access-list 1 deny 192.168.1.2
!
int s0/0
ip pim sparse-mode
ip pim neighbor-filter 1

R2:
int s0/0
ip pim dense-mode
!
int fa0/0
ip pim dense-mode
ip igmp helper-address 192.168.1.1

Multicast/Broadcast conversion:

• You can convert multicast to broadcast, and from broadcast to multicast. You can also do this multiple times backwards and forwards if you need to. Consider the following example:

• We have a server with the IP of 172.16.1.25 that is sending out a udp broadcast to port 5000. For whatever reason we need that same frame to be broadcasted onto the 10.50.50.0/24 network.
• To convert from broadcast to multicast you configure like so:

R1:
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
ip forward-protocol udp 5000
!
int fa0/1
ip multicast helper-map broadcast 224.10.10.10 100

• Then back from multicast to broadcast like so:

R3:
ip forward-protocol udp 5000
!
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
int fa0/0
ip multicast helper-map 224.10.10.10 10.50.50.255 100
!
int fa0/1
ip directed-broadcast

MSDP:

• MSDP is used for inter-domain multicasting as well as to allow RPs in a single AS to share source information if running anycast RP. All you need to configure on the RPs is:

ip msdp peer (peer_unique_address) connect-source (local_unique_interface)

ip msdp originator-id (unique_address_interface)

Bidirectional PIM:

• You need to configure ip pim bidir-enable on ALL PIM interfaces. Most RP commands will then have the bidir switch added to the end of commands.

IPv6 Multicast:

• Sparse mode only
• Enabled using Ipv6 multicast-routing
• When enabled, Pim will run automatically on all ipv6 interfaces. Need to run no ipv6 pim on the interface to remove
• Multicast listener discovery (MLD), part of ICMPv6, replaces igmp
• Mldv1 is equivalent to IGMPv2. Same timers and so on
• Mldv2 equivalent to IGMP3 for ssm
• BSR and Static RP only. No auto-rp. You can also use embedded RP which encodes the RP address in the group address
• sh ipv6 Pim range-list will show you the rp mapping
• ipv6 mld join-group will join a group on an interface
• IPv6 mroute is created using ipv6 route (address/prefix) (next_hop) multicast, NOT ipv6 mroute
• Pretty much everything else is the same as ipv4

Miscellaneous:

• PIM assert will take the Administrative Distance into account first, and then metric if that AD matches. So in order to force a router to be the PIM assert router, you may need to adjust the AD
• ip pim accept-rp (acl) will ensure the RP only accepts *,G joins for groups defined in the ACL. In theory you only need to put this on the RP, but it’s more efficient to put it on all routers so they drop the requests before it even gets to the RP
• int#ip igmp (acl) is used to allow only joins to certain groups through an interface. This interface is pointing towards the receivers as the control packet is igmp
• int#ip igmp limit is used to limit the amount of igmp states on an interface. Can also configure this globally
• When configuring source specific multicast, you are required to configure ip pim ssm default or ip pim ssm (acl) on all PIM routers to ensure they do not create *,G entries. SSM does not actually need an RP as they do not connect to shared trees, only source trees.
• On an ethernet segment a DR will be chosen between the PIM neighbours. By default, the priority is 1. If the priority is the same, the highest IP wins. This can be changed with the int#ip pim dr-priority command. Note that not all switches support this command!
• If your IGP is load-balancing certain paths, you can load-balanse multicast as well with the ip multicast multipath command. This is essential so that your rpf checks don’t fail.