When using PIM Sparse in NBMA environment like Frame Relay you need to make sure you enter the ip pim nbma command to disable the split horizon rule that traffic coming into the interface is not going out that same interface. The IP pim nbma is working only for Sparse Mode Group Candidate RP need to be able to communicate only with the mapping agent and the Routers in the Domain need to be able to communicate with the Mapping agent so from that we can understand that we need to watch our Route to the Mapping Agent. Ok I think I will end it here for now, I hope this was good info.
In that section I would like to talk about Auto-RP, well not until recently I have had little to say about multicasting as it was something I know but like most I didn’t really understand or have struggled to really see how it works, I only know that when you enable it, you basically save bandwidth by using one stream instead of unicasting to each and every station, and on the basic it is true but the how it works is more important for us candidates. So here I will show you how the Auto-RP works and what tools do we have to make it work. Well we should all know that we have today 3 basic operation modes of PIM Sparse Mode – or as it called source tree and it is mostly used today Multicast Networks using a Pull Technology meaning if you do not ask I will not send it Dense Mode – or as it called shared tree and this is the very basic of Multicast using Push Technology meaning I will always send and if you say you do not need it I will Prune back but after a certain time out I will again send to you just so you want miss it if you do need it in some point. Sparse-Dense Mode – well this is a hybrid of the 2 methods meaning that I will Sparse if I have an RP (Rendezvous Point) but if I don’t have one or I loose it then I will fall over to Dense Mode. When we enable PIM Sparse Mode we most have and RP the RP witch is like having a DR in the OSPF, it will be responsible on the Path for the Multicast Group. To have RP in a Sparse Group we have 3 methods: a) Static b) Auto-RP Cisco proprietary c) BSR the industry standard We will talk here about Auto RP: First Step before we start with any multicast config we need to make sure that all our unicasting routing is working so that is the initial step before we even think on Multicast. Why?! Because Multicast is relaying on our Unicast to pass the traffic as we know RPF is done based on the Unicast routing Table and the RPF is basic check of backwards Path between the Sources of the Traffic to the Destination, with that said each time a new group is announced it must go trough the RPF check. To Enable Auto RP we must specify an RP-Candidate and RP-Mapping RP-Candidate is to announce your self as an RP, you can also announce one Router to be RP for certain groups and different Router to be RP for different groups. RP-Mapping the Mapping agent can be the same Router as the Candidate but it also can be a different Router it is simply to send the router in the Multicast Domain the mapping to the RP. When you enable the RP Candidate you Join a Group 22.214.171.124 and when you enable the Mapping you Join Group 126.96.36.199 also you can see that all Routers that you set with multicast join group 188.8.131.52 if you do: R2#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 184.108.40.206), 00:00:00/00:02:59, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:00/00:02:59 On the RP I am setting the announce and the discovery and the listner The listner is actually to enable the pim to send the 220.127.116.11/40 as Dense Mode with out needing to enable sparse-dense mode or other workaround as this 2 groups must be in Dense Mode. ! ! I used a loopback as the source of the groups but you can also enable the source to come ! From a physical interface although if you loose that interface you will loose your RP. ! You must also remember that all Routers in the Multicast Domain must have Unicast ! Connectivity to the RP ! ip pim autorp listener ip pim send-rp-announce 18.104.22.168 scope 255 interval 10 ip pim send-rp-discovery Loopback0 scope 255 interval 10 ! ! Also if you use the loopback as the RP then you must enable on the loopback also PIM After you enable on all the interfaces in your path PIM you should check for neighbor relationship: R1#sh ip pim nei PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 22.214.171.124 Serial1/0 00:24:52/00:01:29 v2 1 / DR S 126.96.36.199 Serial1/0 00:26:37/00:01:38 v2 1 / S Then you should check that you have mapping to the RP: R3#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 188.8.131.52/4 RP 184.108.40.206 (?), v2v1 Info source: 220.127.116.11 (?), elected via Auto-RP Uptime: 00:12:15, expires: 00:00:26 If one of the steps is failing then first check for RPF fail by: R3#sh ip mroute count IP Multicast Statistics 4 routes using 1788 bytes of memory 2 groups, 1.00 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 18.104.22.168, Source count: 1, Packets forwarded: 0, Packets received: 11 Source: 22.214.171.124/32, Forwarding: 0/-1/0/0, Other: 11/0/11 Group: 126.96.36.199, Source count: 1, Packets forwarded: 0, Packets received: 11 Source: 188.8.131.52/32, Forwarding: 0/-1/0/0, Other: 11/0/11 If you had a fail here then the Other: 11/11/0 meaning that the failed would increase. To solve a RPF fail you need to make sure that you pass the RPF check and the RPF check is done using the Unicast routing table meaning that you need to check that the path that the packet is taking is trough the Multicast Domain and not trough a non Multicast interfaces. Also you can pass the RPF by adding a static R3(config)#ip mroute 0.0.0.0 0.0.0.0
# For the exam you must ask if it is allowed.