Ok, it's obvious whoever wrote this part of the workbook wasn't paying close attention to subnet masks. There are several mistakes here.
To filter, from the mapping agent side, which RPs will be announced for a particular group, use the ip pim rp-announce-filter. The tricky part here is that, the only part is not that an entry required for each RP and its associated groups that should be allowed. An extra entry explicitly denying remaining RPs and groups must be added as well, to prevent rouge RPs.
Showing posts with label auto-rp. Show all posts
Showing posts with label auto-rp. Show all posts
Sunday, January 18, 2009
IE Vol 1 Multiple Candidate RPs Complete
In this lab, two candidate RPs are created, which only advertise a portion of the multicast addresses. This requires the group-list option of the ip pim send-rp-announce command. Not much to it, just configure the access list to only allow the multicast groups that the router wants to be an RP for.
There is one thing to keep in mind on this command. Typically, whenever creating a multicast access-list, you want to use the destination address, since a multicast group can only be a destination, and not a source. But we are not filtering here, we are telling the RP which groups to advertise. Therefore, the groups to be advertised are configred as the source of the access-list. Perhaps more easily, a standard ip access-list can be used.
On a minor irritating note, the lab specifies a /4 address, when it should have used a /5. /1 is a class A, /2 is a class B, /3 is a class C, therefore /4 would be the entire class D. To split a class D down the middle, a /5 is required.
There is one thing to keep in mind on this command. Typically, whenever creating a multicast access-list, you want to use the destination address, since a multicast group can only be a destination, and not a source. But we are not filtering here, we are telling the RP which groups to advertise. Therefore, the groups to be advertised are configred as the source of the access-list. Perhaps more easily, a standard ip access-list can be used.
On a minor irritating note, the lab specifies a /4 address, when it should have used a /5. /1 is a class A, /2 is a class B, /3 is a class C, therefore /4 would be the entire class D. To split a class D down the middle, a /5 is required.
IE Vol 1 Auto-RP Complete
Again, nothing fancy here. First the interfaces are configured for sparse-dense mode. Once configured this way, the multicast flow works, since it falls back to dense mode when an RP is not known for a flow.
So the trick is to get that RP learned dynamically. There are two dynamic RP protocols: Auto-RP and bootstrap RP. This exercise uses auto-rp, but they are both very similar.
Two things are required for the dynamic registration to happen. First, at least one router must advertise one of its interfaces as a candidate rp, using ip pim send-rp-announce. This advertisement happens via multicast group 224.0.1.39. Since there is no rp for this group, it uses dense mode and will get flooded/pruned.
Next, a router must be configured to listen for 224.0.1.39 messages. This is done via the ip pim send-rp-discovery command, and this router is called a mapping agent. It can be on the same or a different router. Once added, the mapping agent acts as a receiver on 224.0.1.39. Therefore, the routers must graft this receiver on to be a listener for this group. This means any RPF checks must be successful on the 224.0.1.39 group to ensure messages from the candidate rp(s) are being received by the mapping agent.
The mapping agent decides on a candidate rp and advertises its selection out via dense mode to group 224.0.1.40. Through this group, all routers learn the RP for the group, and can the flow can use sparse mode.
So the trick is to get that RP learned dynamically. There are two dynamic RP protocols: Auto-RP and bootstrap RP. This exercise uses auto-rp, but they are both very similar.
Two things are required for the dynamic registration to happen. First, at least one router must advertise one of its interfaces as a candidate rp, using ip pim send-rp-announce. This advertisement happens via multicast group 224.0.1.39. Since there is no rp for this group, it uses dense mode and will get flooded/pruned.
Next, a router must be configured to listen for 224.0.1.39 messages. This is done via the ip pim send-rp-discovery command, and this router is called a mapping agent. It can be on the same or a different router. Once added, the mapping agent acts as a receiver on 224.0.1.39. Therefore, the routers must graft this receiver on to be a listener for this group. This means any RPF checks must be successful on the 224.0.1.39 group to ensure messages from the candidate rp(s) are being received by the mapping agent.
The mapping agent decides on a candidate rp and advertises its selection out via dense mode to group 224.0.1.40. Through this group, all routers learn the RP for the group, and can the flow can use sparse mode.
Subscribe to:
Posts (Atom)
Posts
