![\"image0\"](\"https://assets.ine.com/lab/learningpath/61b1d975398ba4a34d27215c5b2856e298595a0891b131788bfe35ed1b3bed30.png\")
Welcome to the Dynamic Rendezvous Points with Auto-RP lab, where you\u2019ll explore how PIM Sparse-Mode networks dynamically discover and use Rendezvous Points without relying on static configuration. In this hands-on lab, you\u2019ll step through the complete Auto-RP process\u2014preparing the network, configuring RP-Candidates and a Mapping Agent, and observing how RP information is advertised, discovered, and used across the topology. Along the way, you\u2019ll pause to predict behavior, verify control-plane operation, and even use Wireshark to watch Auto-RP messages on the wire, building an intuitive understanding of how modern IOS handles dynamic RP discovery.
", "tasks": "\n\n# Lab Tasks \u2014 Exploring Auto-RP with PIM Sparse-Mode (with Packet Observation)\n\n## Lab Overview\n\nIn this lab, you\u2019ll explore **Auto-RP**, Cisco\u2019s dynamic mechanism for learning Rendezvous Points (RPs) in a PIM Sparse-Mode network.\n\nYou\u2019ll gradually introduce Auto-RP roles, **pause to predict behavior**, and use **Wireshark** at key moments to *see* the control-plane messages that make Auto-RP work.\n\nYou don\u2019t need to decode every field \u2014 focus on **who is talking**, **to whom**, and **why**.\n\n---\n\n## Task 1 \u2014 Take a Look Around (Baseline with No RP)\n\nLet\u2019s get comfortable with the current state of the network.\n\n1. Configure PIM on all appropriate router interfaces (R2 through R9). Do not configure any PIM on routers labeled as \"MCAST-RCVR\".\n\n2. On a few routers of your choice, verify:\n - PIM neighbors are established\n - Multicast routing is enabled\n\n3. On any router, verify whether an RP is currently known.\n\n---\n\n## Task 2 \u2014 How *Should* Auto-RP Work?\n\nBefore touching the configuration, let\u2019s think through Auto-RP itself.\n\n1. Auto-RP relies on two well-known multicast groups.\n\n **Friendly Question:** \n Are these groups link-local, or are they routable across the network? \n What does that imply about how they must be forwarded?\n\n2. Auto-RP messages rely on **Dense-Mode flooding**.\n\n **Prediction Time:** \n What PIM mode did you apply to your router interfaces (R2 through R9)? \n Do you expect Auto-RP messages to propagate successfully in this mode?\n\n\nKeep your answer in mind \u2014 you\u2019ll act on it next.\n\n---\n\n## Task 3 \u2014 Prepare the Network for Auto-RP (Sparse-Dense)\n\nLet\u2019s make the network ready for Auto-RP.\n\n1. On all routers that participate in multicast forwarding, if necessary, update the relevant interfaces to the appropriate PIM mode so they can support Auto-RP message flooding.\n\n2. After making the change, pause for a moment.\n\n **Check-in Question:** \n Why does Auto-RP require this mode, even if the multicast data plane is in Sparse-Mode?\n\nNothing will happen *yet* \u2014 but the stage is now set.\n\n---\n\n### Important Note \u2014 Auto-RP Listener Requirement\n\nIn modern IOS implementations, Auto-RP control messages are **not processed by default**.\n\nTo ensure Auto-RP works, configure the following on **all routers**:\n\n```\nip pim autorp listener\n```\n\nWithout this command, Auto-RP will not function correctly in this lab.\n\n## Task 4 \u2014 Configure the RP Candidate (R2) and Watch It Talk\n\nNow we introduce the first Auto-RP role.\n\n1. Configure **router R2** as an **RP Candidate**:\n - Use its loopback interface as the RP address\n - Advertise support for all multicast groups\n\n2. Before verifying anything, let\u2019s *listen* to the network.\n\n ### Packet Capture\n - In GNS3, **right-click the link between R2 and R3**\n - Select **Start Capture**\n - Wireshark will open automatically\n\n3. Let the capture run for at least one full announcement interval.\n\n **What to Look For (No Deep Dissection Required):**\n - Packets destined to **224.0.1.39**\n - UDP traffic related to Auto-RP\n - The source IP address used by R2\n\n4. Now pause and think.\n\n **Prediction Question:** \n Even though R2 is sending RP announcements, do you expect *any router* to learn an RP yet?\n\n Why might the network still feel incomplete?\n\n---\n\n## Task 5 \u2014 Configure the Mapping Agent (R4) and Observe the Flood\n\nNow let\u2019s complete the Auto-RP system.\n\n1. Configure **router R4** as the **Mapping Agent**.\n\n2. Start a new capture to observe RP discovery behavior.\n\n ### Packet Capture\n - Right-click the link between **R4 and R7**\n - Select **Start Capture**\n - Allow Wireshark to run for at least a minute\n\n3. While the capture runs, verify RP information on a few routers.\n\n **What to Look For:**\n - Packets destined to **224.0.1.40**\n - RP discovery messages being flooded\n - Evidence that routers *other than R2 and R4* are receiving RP information\n\n4. Reflect on what you see.\n\n **Observation Questions:**\n - Which router is selected as the RP?\n - Who made that decision?\n - Are routers learning RP information directly from R2, or from somewhere else?\n\n---\n\n## Task 6 \u2014 Bring Multicast to Life\n\nWith Auto-RP operational, let\u2019s see the data plane respond.\n\n1. Start multicast traffic from the multicast source by copying and pasting the following commands:\n\n ```\n while true; do\n echo \"udp test\" | socat - UDP4-DATAGRAM:225.9.9.9:9999,ip-multicast-ttl=16\n sleep 0.25\n done\n ```\n\n2. Ensure at least one receiver is actively joined by typing the following commands;\n\n ```\n Mcast-Rcvr1#conf t\n Enter configuration commands, one per line. End with CNTL/Z.\n Mcast-Rcvr1(config)#int gig 0/2\n Mcast-Rcvr1(config-if)#ip igmp join-group 225.9.9.9\n Mcast-Rcvr1(config-if)#end\n Mcast-Rcvr1#\n ```\n\n3. Observe multicast routing state on:\n - The source-side router\n - The RP\n - A receiver-side router\n\n **Prediction Question:** \n What type of tree do you expect to form first \u2014 shared tree or shortest-path tree? \n Why does PIM behave this way initially?\n\nYou may optionally keep a packet capture running to correlate control-plane events with state changes.\n\n---\n\n## Task 7 \u2014 Optional Curiosity (If You\u2019d Like)\n\nIf you want to explore further, try one of the following:\n\n- Add a second RP Candidate and watch how R4 advertises the result\n- Capture traffic on a different link and confirm flooding behavior\n- Temporarily remove Sparse-Dense mode and predict what Wireshark will *stop* showing you\n\nBefore verifying, always ask:\n\n> *What do I expect to see on the wire \u2014 and why?*\n\n---\n\n## End of Lab Tasks", "tasks_html": "
In this lab, you\u2019ll explore Auto-RP, Cisco\u2019s dynamic mechanism for learning Rendezvous Points (RPs) in a PIM Sparse-Mode network.
\nYou\u2019ll gradually introduce Auto-RP roles, pause to predict behavior, and use Wireshark at key moments to see the control-plane messages that make Auto-RP work.
\nYou don\u2019t need to decode every field \u2014 focus on who is talking, to whom, and why.
\nLet\u2019s get comfortable with the current state of the network.
\nConfigure PIM on all appropriate router interfaces (R2 through R9). Do not configure any PIM on routers labeled as \"MCAST-RCVR\".
\nOn a few routers of your choice, verify:
\nMulticast routing is enabled
\nOn any router, verify whether an RP is currently known.
\nBefore touching the configuration, let\u2019s think through Auto-RP itself.
\nFriendly Question:
\n Are these groups link-local, or are they routable across the network?
\n What does that imply about how they must be forwarded?
Prediction Time:
\n What PIM mode did you apply to your router interfaces (R2 through R9)? \n Do you expect Auto-RP messages to propagate successfully in this mode?
Keep your answer in mind \u2014 you\u2019ll act on it next.
\nLet\u2019s make the network ready for Auto-RP.
\nOn all routers that participate in multicast forwarding, if necessary, update the relevant interfaces to the appropriate PIM mode so they can support Auto-RP message flooding.
\nAfter making the change, pause for a moment.
\nCheck-in Question:
\n Why does Auto-RP require this mode, even if the multicast data plane is in Sparse-Mode?
Nothing will happen yet \u2014 but the stage is now set.
\nIn modern IOS implementations, Auto-RP control messages are not processed by default.
\nTo ensure Auto-RP works, configure the following on all routers:
\nip pim autorp listenerWithout this command, Auto-RP will not function correctly in this lab.
\nNow we introduce the first Auto-RP role.
\nAdvertise support for all multicast groups
\nBefore verifying anything, let\u2019s listen to the network.
\n### Packet Capture\n - In GNS3, right-click the link between R2 and R3\n - Select Start Capture\n - Wireshark will open automatically
\nWhat to Look For (No Deep Dissection Required):\n - Packets destined to 224.0.1.39\n - UDP traffic related to Auto-RP\n - The source IP address used by R2
\nPrediction Question:
\n Even though R2 is sending RP announcements, do you expect any router to learn an RP yet?
Why might the network still feel incomplete?
\nNow let\u2019s complete the Auto-RP system.
\nConfigure router R4 as the Mapping Agent.
\nStart a new capture to observe RP discovery behavior.
\n### Packet Capture\n - Right-click the link between R4 and R7\n - Select Start Capture\n - Allow Wireshark to run for at least a minute
\nWhat to Look For:\n - Packets destined to 224.0.1.40\n - RP discovery messages being flooded\n - Evidence that routers other than R2 and R4 are receiving RP information
\nObservation Questions:\n - Which router is selected as the RP?\n - Who made that decision?\n - Are routers learning RP information directly from R2, or from somewhere else?
\nWith Auto-RP operational, let\u2019s see the data plane respond.
\nStart multicast traffic from the multicast source by copying and pasting the following commands:
\nwhile true; do\necho \"udp test\" | socat - UDP4-DATAGRAM:225.9.9.9:9999,ip-multicast-ttl=16\nsleep 0.25\ndoneEnsure at least one receiver is actively joined by typing the following commands;
\nMcast-Rcvr1#conf t\nEnter configuration commands, one per line. End with CNTL/Z.\nMcast-Rcvr1(config)#int gig 0/2\nMcast-Rcvr1(config-if)#ip igmp join-group 225.9.9.9\nMcast-Rcvr1(config-if)#end\nMcast-Rcvr1#Observe multicast routing state on:
\nPrediction Question:
\n What type of tree do you expect to form first \u2014 shared tree or shortest-path tree?
\n Why does PIM behave this way initially?
You may optionally keep a packet capture running to correlate control-plane events with state changes.
\nIf you want to explore further, try one of the following:
\nBefore verifying, always ask:
\n\n\nWhat do I expect to see on the wire \u2014 and why?
\n
Take this as a guided walk-through rather than an answer key.
\nIf something you predicted didn\u2019t match reality \u2014 that\u2019s not a mistake, that\u2019s learning doing its job.
R2 through R9\n\nip multicast-routing\n!\ninterface range gigabit0/0 - 3\n ip pim sparse-dense-mode\n exit\n!\nip pim autorp listener\nMulticast Receivers\n\nMCAST-RCVR-1\n\ninterface gig0/2\n ip igmp join-group 225.9.9.9\n end\n\nMCAST-RCVR-2 & MCAST-RCVR-3\n\ninterface gig0/3\n ip igmp join-group 225.9.9.9\n end\nR2 (AutoRP Candidate Router)\n\nconfig t\nip pim send-rp-announce Loopback0 scope 16\nendR4 (AutoRP Mapping Agent)\n\nconfig t\nip pim send-rp-discovery Loopback0 scope 16\nendip multicast-routing is enabled everywhereOn any router, check:
\nshow ip pim rpYou should see output indicating no RP is configured or learned.
\nWith PIM enabled on router interfaces but no RP information available, multicast traffic cannot be forwarded beyond the first-hop router.
\nWhy?
\nYour intuition that \u201csomething important is missing\u201d was exactly right \u2014 that missing piece is RP knowledge.
\nAuto-RP uses two globally scoped multicast addresses:
\n| Purpose | \nMulticast Address | \nTransport | \n
|---|---|---|
| RP-Announce | \n224.0.1.39 | \nUDP 496 | \n
| RP-Discovery | \n224.0.1.40 | \nUDP 496 | \n
These are not link-local (224.0.0.x) addresses.
Because these groups are routable:
\nIf your interfaces had been configured for PIM Sparse-Mode only, Auto-RP messages would not propagate.
\nSparse-Mode requires:\n- A known RP\n- Existing multicast state
\nAuto-RP exists precisely to create RP knowledge \u2014 so it can\u2019t bootstrap itself using Sparse-Mode alone.
\nThis is the classic Auto-RP chicken-and-egg problem.
\nOn all multicast-participating interfaces, if you had initially applied only Sparse-Mode you needed to make a change:
\nip pim sparse-modeto:
\nip pim sparse-dense-modeSparse-Dense mode behaves as follows:
\nAuto-RP messages are flooded using Dense-Mode behavior, which allows:
\nto reach every router before any RP exists.
\nThis is temporary scaffolding \u2014 once the RP is learned, the network naturally behaves like pure Sparse-Mode again.
\nip pim autorp listener Is RequiredIn this lab, Auto-RP did not function until ip pim autorp listener was configured on both the RP (R2) and intermediate routers such as R7. This behavior is expected in modern IOS.
Without the Auto-RP listener enabled:
\nThis is why (if you had neglected to add this command to at least routers R2 and R7) you would have seen in subsequent steps that R2 failed to recognize itself as the RP and subsequently rejected:
\nOnce ip pim autorp listener was enabled on all routers participating in Auto-RP forwarding, RP-Discovery messages propagated correctly and the multicast control plane converged as expected.
Key takeaway:
\nAuto-RP now requires explicit participation from every router involved, not just RP-Candidates or Mapping Agents.
R2 already has Loopback0 at 2.2.2.2/32.
\nConfigure it as the RP Candidate (example scope shown; your lab may choose a different TTL):
\nconf t\n ip pim send-rp-announce Loopback0 scope 16\nendImportant factual behaviors:\n- Announcements are sent about every 60 seconds\n- The advertised holdtime is typically 180 seconds\n- RP-Announce messages are sent to 224.0.1.39 using UDP port 496
\nIn GNS3:\n- Right-click the R2\u2013R3 link\n- Choose Start Capture\n- Wireshark opens
\nWhat you should see:\n- Destination multicast 224.0.1.39\n- UDP traffic (port 496)\n- Source IP matching the interface you used in the RP-Announce command (Loopback0 \u21d2 2.2.2.2)
\n![\"image1\"](\"https://assets.ine.com/lab/learningpath/ad413f1380771548d2a2585306319bf16d63c712e84b3e5c8de37637b718870c.png\")
Even though R2 is announcing itself, no router learns an RP yet.
\nWhy?\n- Only a Mapping Agent actually processes RP-Announce messages.\n- Other routers treat the traffic like \u201cflood this along,\u201d not \u201clearn from this.\u201d
\nSo yes \u2014 it still feels incomplete, because it is incomplete (on purpose!).
\n![\"image2\"](\"https://assets.ine.com/lab/learningpath/c70ea30d10c6393bdad6722890f04b8755011098575a9490e0ac269367d3401e.png\")
R4 already has Loopback0 at 4.4.4.4/32.
\nConfigure Mapping Agent behavior (example scope shown):
\nconf t\n ip pim send-rp-discovery Loopback0 scope 16\nendIn GNS3:\n- Right-click the R4\u2013R7 link\n- Choose Start Capture
\nWhat you should see:\n- Destination multicast 224.0.1.40\n- UDP traffic (port 496)\n- Discovery messages being flooded through the domain
\n![\"image3\"](\"https://assets.ine.com/lab/learningpath/9d63c686133673e17557879e0e0e98b35d00a355828f4fa6ed0807d6b480d933.png\")
On multiple routers, check:
\nshow ip pim rp mapping\nshow ip pim rpYou should see the RP learned via Auto-RP for the group range, with the RP pointing to 2.2.2.2 (R2\u2019s loopback).
\n![\"image4\"](\"https://assets.ine.com/lab/learningpath/1b17c01bc4168fa4cae12a95da25f2932a6523d5d01a607d8defe06b09808084.png\")
With Auto-RP:\n- The Mapping Agent makes the RP decision\n- Other routers learn and follow it\n- Routers do not independently compute an RP choice (that\u2019s a PIM-BSR thing)
\nOnce a receiver joins a group, the last-hop router will begin building state using the RP.
\n\u2705 Shared Tree (RPT) forms first.
\nWhy?\n- In PIM Sparse-Mode, the initial join is (*,G) toward the RP.\n- That creates the shared tree before any shortest-path decisions are made.
\nDepending on platform defaults and traffic conditions, you may later see SPT activity, but the first step is the shared tree.
\nOn relevant routers:
\nshow ip mroute\nshow ip pim rp mapping\nshow ip pim neighborIf Auto-RP feels less \u201cmysterious\u201d now, you did it right.
\nIf you want to deepen intuition next, a fun follow-up is:\n- Add a second RP candidate\n- Watch how the Mapping Agent selects (and how routers react if discovery messages differ)
\n