Subnetting Made Easy And Other Cisco Tidbits

CCIE - Warm Up Phase - Multicast
Tuesday, 3 May 2011

Some general notes from the ATC -

(*,G) = I know what group I want to join but I don't know who is sourcing that traffic

Shared Tree uses shortest path to the RP and all traffic passes through the RP

Source tree uses shortest path to the source and traffic may or may not pass through the RP

Bi-directional PIM uses Shared Trees only

Multicast Source Discovery Protocol (MSDP) is a logical peering between RPs in order to exchange Source Active (SA) information. RPF checks are used to prevent loops. Additionally, able to limit or filter SAs. Specifiy the MSDP peer using "ip msdp peer "

Anycast RP - RPs use same IP address. The IGP determines which RP is "closest". If one RP fails, the other RP will be used once IGP reconverges. Used in conjunction with MSDP for exchanging information.

Useful commands:

show ip pim neighbor
show ip pim interface
show ip pim rp mapping
show ip mroute
debug ip mpacket (may need to use "no ip mroute-cache" to see thru-traffic)
debug ip pim

Auto-RP, by default, will not work in a pure Sparse Mode domain as router will not join 224.0.1.39 and 224.0.1.40 as it doesn't know of an RP. However, without joining those groups it won't know what the RP is. There are three workarounds:

a. Default RP assignment where you assign a static RP for 224.0.1.39 and 224.0.1.40 but this defeats the purpose of Auto-RP

b. Configure sparse-dense-mode. This acts as dense mode for those groups with no RP (e.g. 224.0.1.39 and 224.0.1.40).

c. Configure ip pim autorp listener which automatically goes in dense mode for 224.0.1.39 and 224.0.1.40.

Sample Network
--------------

R1--R2--R3--R4--R5--R6

R3 is RP on Lo0 interface. All devices configured with "ip pim rp-address 150.1.3.3" including R3 itself.

All interfaces connected to another router confogured for PIM Sparse Mode.

On R1 configure "ip igmp join-group 224.101.101.101".

R3 should now have a (*,224.101.101.101) as will all routers in the path between R1 and R3.

On R6 try pinging 224.101.101.101 which effectively makes R6 a source for the 224.101.101.101 group.

R3 should now have a (S,G) entry (assume R6 interface is 155.1.146.6) the entry will be (155,1,146,6, 224.101.101.101).

You could use the "ip igmp static-group" command but this will not respond t pings, however, traffic is still processed the normal way and you ought to be able to see the (*,G) and (S,G) entries associated with the static group.



8.1 - A 3560 requires "ip multicast-routing distributed" to be configured.

To test a configuration make an interface join a group and try to ping that group from another router. that interface must also be configured for PIM. What happens here is the interface acts as a host which is listening to a multicast group and the router that is pinging that group address is acting as the multicast source. Example:

int lo0
ip pim dense-mode
ip igmp join-group 224.10.10.10

8.2 If the RPF check fails (i.e. the IGP prefers a path to a source via a different interface, maybe because PIM is not enabled on that interface) then you could always add a static route to the mroute table.

ip mroute 155.1.146.0 255.255.255.0 155.1.0.4

In this example on R5, the IGP preferred a route in EIGRP via the point-to-point serial link to R4. However, PIM was not enabled on that interface but instead on the frame Relay cloud between R4 and R5. Hence, multicast traffic was attempting to go over the Frame Relay cloud but was failing the RPF check (e.g. 155.1.146.6 is meant to be reachable via the point-to-point link and not the Frame Realy cloud).

To change how often a router checks RPF use the "ip multicast rpf interval" command.

To configure a router to perform triggered RPF checks after a topology change and specify a maximum delay use "ip multicast rpf backoff "

8.3 - There is a nother RPF failure but that is because R5's Lo0 interface was being advertised as a /32 by OSPF and therefore was the longest match when compared to the /24 advertised by EIGRP. By changing the OSPF network type to point-to-point under the Lo0 interface of R5, the RPF check passed and traffic flowed.

To specify a traffic limit when the Shortest Path Tree (SPT) is used (switched over to) use the "ip pim spt-threshold" command.

8.4 - note that Dense Mode uses (*,G) tuples and Sparse Mode uses (S,G) tuples. to specify which groups an RP can be an RP for, create an access-list and apply that to the rp-address command:

ip access-list standard ACL_ALLOWED_GROUPS
permit 224.0.0.0 0.0.0.255
!
ip pim rp-address 150.1.5.5 ACL_ALLOWED_GROUPS

8.5 - the PIM Assert message tells a shared segment which router should be forwarding on that segment for that particular group. The tiebreak on this is the administrative distance used to reach the source. So, for example, you had a device using EIGRP and one using OSPF, the one using EIGRP would win the assertion due to the lower AD (90 versus 110). To change this you would need to alter the AD of the routing protocol.

8.6 - The Accept RP tells a router to only accept specific groups from trying to join an RP.

For example, if R5 Lo0 is the RP (150.1.5.5) and you only wanted groups 224.10.10.10 and 224.110.110.110 to be able to reach that RP use the following:

ip access-list standard ACL_ACCEPT_RP
permit 224.10.10.10
permit 224.110.110.110
!
ip pim accept-rp 150.1.5.5 ACL_ACCEPT_RP

8.7 - The PIM DR Election process is pre-emptive, unlike OSPF DR election. The winner is the router with the highest priority (default of 1) and if they are tied then the router with the highest IP address will be the PIM DR.

ip pim dr-priority

The "show ip pim interface detail" command will tell you whether the interface is PIM DR.

8.8. The PIM Accept Register is configured on a RP and tells the RP which sources can register with it. If a source tries to register with the RP that is not on the register you will see Register-Stop messages (assuming "debug ip pim" is configured).

8.9 Multicast tunnelling is straightforward. Try using ip unnumbered on the tunnel as its IP address. Must ensure PIM is configured on tunnel interface and make the tunnel interface passive under the routing process. May also need a static mroute to ensure that the RPF checks do not fail.

Posted byChris Bloomfield at 16:59 0 comments  

Labels: CCIE, ine, multicast, pim, rpf, shared tree, source tree, spt