Refer to the exhibit.
R3 is failing to join the multicast group 224.1.1.1 that is sourcing from R1. Which two actions can you
take to allow multicast traffic to flow correctly? (Choose two.)
A.
Remove the static multicast route on R1.
B.
Configure OSPF on R1 and R3 to include the tunnel interfaces.
C.
Add an additional static multicast route on R2 for multicast group 224.1.1.1 toward R3.
D.
Replace the static multicast route on R1 to send traffic toward R2.
E.
Remove the static unicast route on R1.
F.
Add an additional static unicast route on R2 toward the loopback interface of R3.
Since the tunnel interfaces are not part of OSPF, the best path to the multicast source of R1 from
R3 would be over the Gi0/0 path via OSPF. However, the static mroute is configured to use the
tunnel, so this causes an RPF failure used in Sparse Mode. Best fix is to add the tunnel interfaces
into OSPF and remove the static mroute so that that the RPF check no longer fails
0
0
My problem with this is it sounds like they want to put the tunnel interfaces in the same ospf process with the tunnel sources and destinations. This causes tunnel flapping as the router learns the route to the interface the tunnel builds on through the tunnel itself and sees it as a better path. Yes there are things you can do to alleviate this, either through front door vrf or by other means but that’s a lot to “assume”. It certainly doesn’t sound like best practice.
0
0
C sounds better than B.
Wouldnt you also have to adjust cost on the tunnel to get the route to be preferred that way to the source? Assuming you also solve flapping issues…
0
0