Hi Rene,
is this correct? i think its a mistake, its should as in the output of the command 192.168.32.2 not 192.168.23.2…
(192.168.12.1, 239.1.1.1), 00:04:42/00:02:59, flags: LT
Incoming interface: Serial0/0, RPF nbr **192.168.32.2**, Mroute
Outgoing interface list:
Loopback0, Forward/Dense, 00:04:42/00:00:00
See the RPF neighbor above? It now says 192.168.23.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:
Hello Samer
You are correct. The text should read:
See the RPF neighbor above? It now says 192.168.32.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:
I will let @ReneMolenaar know.
Thanks again!
Laz
Thanks for reporting this Samer, I just fixed it.
Rene
Hi Rene,
Thanks for this RPF failure lesson, it was useful. if possible can you explain what do you mean by DataPlane and control place RPF failures . Sorry i could not differentiate both the scenarios that you have posted in the topic
Hello Vinod
The whole concept revolves around the fact that multicast packets received on an interface will be dropped if the source of those multicast packets cannot be reached via that interface (based on the routing table. In other words, if the routing table indicates another exit interface to reach the source, then the packets will be dropped.
Now this is a principle that is valid both for the data plane and the control plane.
In the first example, we have multicast packets arriving on the serial interface of R3, but the routing table says that R1 can be reached via the Ethernet interface, thus the traffic is dropped. Notice that R3 has successfully joined the 239.1.1.1 multicast group. Now this failure occurs on the data plane. In other words, it is actual user traffic that is being blocked by the RPF situation.
In the second example, we see a situation where R2 tries to join the RP for the specific multicast group, but due to the RPF failure, it cannot join the group. So here the failure is in the actual joining of the group which is accomplished using the control plane, that is, packets and communication that takes place between the routers to negotiate multicast groups and parameters. The major difference here is that the failure is due to the fact that R2 failed to join the group, contrary to what happened in the first case, where the router successfully joined the group. So the RPF failure here affected the control plane.
I hope this has been helpful!
Laz
A thing that I noticed is that in the data plane failure we are using Dense mode. You can’t reach the source via the rpf interface. The difference in the control plane failure is we are using sparse mode and we can’t contact the RP via the rpf interface.
Hello Justin
Yes, you’ve noticed this difference and that’s great. You can see here that RPF is actually something that is useful for both dense and sparse mode, albeit in particular circumstances. Both modes are susceptible to RPF failures, even though dense-mode is more susceptible because, by default, it sends multicast traffic everywhere (until it is requested to stop). But sparse-mode topologies can also experience an RPF failure if enough devices request multicast traffic to be forwarded to them.
I hope this has been helpful!
Laz
Hi Rene/Laz,
I’m trying to lab the 1st part of this lesson using the latest VIRL images but it seems disabling of ip mroute-cache is no longer allowed in IOS. I’ve tried setting no mfib cef input and output, but I don’t get any debug output. I managed to add the static route and get the ping working though so all good.
R3(config-if)#no ip mroute-cache
The above command is deprecated. Use MFIB commands instead.
Also for me, prior to adding the static mroute, R3 does not show RPF neighbor 192.168.23.2. I would expect this as I’ve not enabled PIM on that Ethernet interface. In the lesson config you do not enable PIM on R3 Fa0/0, but in the final configs it is there.
Just wanted to confirm this is this the reason you see RPF nbr 192.168.23.2 on R3? This is prior to adding the static mroute btw.
R3#show ip mroute 239.1.1.1 | begin 239
(*, 239.1.1.1), 00:02:27/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Dense, 00:02:27/stopped
Loopback0, Forward/Dense, 00:02:27/stopped
(192.168.12.1, 239.1.1.1), 00:00:04/00:02:55, flags: L
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Dense, 00:00:04/stopped
Serial1/0, Prune/Dense, 00:00:04/00:02:55, A
I also found that show ip rpf is a nice command to use to check RPF failure
R3#show ip rpf 192.168.12.1
failed, no route exists
Thanks
Hi,
Why you said the first rpf failure on data plane and second example is on control plane
Thanks
Hello Bhawandeep
Thanks for this input. Indeed as things change with IOS, some things will also change with the commands in the lessons. I’ll let @ReneMolenaar know to make any adjustments to the lesson to bring it up to date with changes to the commands.
As for the RPF nbr, I have gone into the lab and find that I have the same results as you. I will let Rene know to take a look and clarify this point in the lesson.
Thanks for your suggestions, and I hope this has been helpful!
Laz
Hello Sims
Remember that the term data plane is used to refer to the transmission of data that is generated by hosts, that is, end devices that are connected to the network. The data plane carries user data such as emails, web pages, voice packets, etc.
The term control plane refers to the transmission of data between network devices such as routers, where the source and destination of the packets are the network devices themselves. This kind of data does not contain user data, but control data such as that used when exchanging routing information, CDP, DTP, VTP, link aggregation, STP, and other protocols. Control data is solely for the purpose of allowing the network to function correctly.
In the first example in the lesson, the problem introduced by the RPF failure affected user data, that is, data that was to be sent to multicast clients. In this topology, L0 of R3 with an IP address of 3.3.3.3 plays the role of the host, and the pings being sent represent the multicast data plane user traffic to this host that was affected.
In the second example, the RPF error has affected the way that R2 tries to reach the RP. Using the check, the unicast table is indicating that the serial link cannot be used. However, this affects the way that R2 reaches the RP (a strictly control plane operation since no hosts are involved, and communication is taking place between network devices). When R2 tries to find the RP and fails due to RFP failure, this is a failure of the internal workings of multicast and PIM, therefore it is a failure on the control plane.
I hope this has been helpful!
Laz
Thanks for taking the time to lab this aswell Laz. Appreciate it.
Hi
I couldn’t get expected result. Why?
R2#sh ip mroute
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:03:25/00:02:34, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/0, Forward/Dense, 00:03:25/stopped
Ethernet0/0, Forward/Dense, 00:03:25/stopped
(*, 224.0.1.40), 00:08:30/00:02:17, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/0, Forward/Dense, 00:08:01/stopped
Ethernet0/0, Forward/Dense, 00:08:30/stopped
R2#sh ver
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.4(2)T4, DEVELOPMENT TEST SOFTWARE
・・・
regards
Yoichi
Hello Yoichi
Without seeing more of your configuration, I’m not sure I can help you completely resolve your issue. However, looking at the output you shared, what I can tell you is that you are currently running PIM sparse mode. How do I know this? Because I see the 224.0.1.40 group in the multicast routing table, and that is a group used for PIM Auto RP, which is a protocol used to automatically elect an RP when employing sparse mode.
Dense mode, on the other hand, does not use an RP. The lesson for multicast RPF specifically uses dense mode. I suggest you take a look at your configs once again and verify that they are as described in the lesson.
If you encounter any other problems with this lesson, feel free to ask further questions!
I hope this has been helpful!
Laz
Hello Laz
Thank you for your reply.
I am not currently running PIM Sparse Mode. I use IOL, EVE-NG. Is that the cause? I don’t understand that why 224.0.1.40 group is displayed, despite running in dence-mode…
R1#sh ver
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.4(2)T4, DEVELOPMENT TEST SOFTWARE......
I understand that Ping Command need to keep going at the same time. If I do not do so, the source tree (192.168.12.1, 239.1.1.1) will not be displayed in Multicast Routing Table.
my configuration is below.
R1
ip multicast-routing
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip pim dense-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
R2
ip multicast-routing
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
ip pim dense-mode
!
interface Ethernet0/1
ip address 192.168.23.2 255.255.255.0
!
interface Serial2/0
ip address 192.168.32.2 255.255.255.0
ip pim dense-mode
serial restart-delay 0
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
R3
ip multicast-routing
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.1
!
interface Ethernet0/0
ip address 192.168.23.3 255.255.255.0
!
interface Serial2/0
ip address 192.168.32.3 255.255.255.0
ip pim dense-mode
no ip mfib cef input
no ip mfib cef output
serial restart-delay 0
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
Hello Yoichi
Ah, I apologize, that was my mistake. I had forgotten that the (*, 224.0.1.40) multicast route entry always appears when you enable PIM even if the dense mode is activated. more on this can be found at the Multicast Routing section of the Multicast PIM Dense Mode lesson. Specifically, it states:
PIM dense mode doesn’t use RPs so there is no reason at all for our routers to listen to the 224.0.1.40 group address. For whatever reason, as soon as you enable PIM then autoRP is also enabled and the router will listen to this group address. You can ignore this entry completely when you are working with PIM dense mode.
Back to your specific configuration, you mentioned the following:
I labbed this up and I see that I am getting the same results as the lesson. Indeed, what you describe is true. Unless there is multicast traffic generated, there will be no mroutes installed in the multicast routing table. Once you ping, you will see the source tree displayed.
When you complete the rest of the lab, do you find that you are able to get the same results as well? Let us know!
I hope this has been helpful!
Laz
Hello Laz
Thank you for your reply.
I was able to get same results as well!!
I understood very well!!
Regards
Yoichi.
Hi,
In your example, what if PIM was enabled on both the serial and fast ethernet links, but there was a static route on R3 to direct unicast traffic to the source (192.168.12.1) via the serial link? In that case, the RPF check should fail because multicast traffic comes down via fast ethernet but the return to the traffic to the source is via serial. But it doesn’t seem to fail according to a lab I’ve set up.
So would I be right in saying the RPF check only fails if the reverse path doesn’t have PIM enabled AND it is not the same as the forward path?
Thanks,
Sam
Hello Samir
That would seem to be the conclusion from your particular lab experiment. I suggest you also try to use the static route to R3 to direct unicast traffic via the serial link, but keep PIM disabled on the ethernet link. Then see if there is an RPF failure or not. Most likely that would be the case.
If you do try it out, can you share your results with us!
I hope this has been helpful!
Laz