Multicasting RPF question from a troublemaker

[CriscoSystems]

Here I am a-studying multicasting for my BSCI exam.

With RPF, the router looks at an incoming multicast-destined packet and examines its source IP address. If the router has a route to that source that goes out via the same interface the packet arrived on, then all is well and the packet is taking the route it ought to.

But then (heh heh), the claim is made that if the packet's source is not reachable out the same interface, then that means the packet is headed "back to its source; back toward the root of the multicast tree."

I have chosen to argue with this. I will allow that it is a good idea to make sure the packet is arriving on the interface where all traffic from that source is expected, and frankly I also have no objection to dropping multicast packets that don't meet that criterion.

But I don't 100% accept that the packet arriving on an unexpected interface is proof that it's headed SPECIFICALLY back to its source. What if the link out that interface really IS part of a route back to the multicast source, and the router just doesn't know about that route because it wasn't statically configured or because it's known by routing protocols other than that router is running?

I suppose that's why it's called protocol-independent multicasting. I haven't yet learned how routing protocols take care of multicast packets. Still, I think it's confusing and even misleading to assume and tell us earnest students that a renegade packet is headed back to its source when there's a chance that it isn't.

Or is there in fact no such chance, and I'm missing something?

[Jon Marshall]

Seth

I think it's better to think of it in terms of the multicast packet is heading away from the source.

So unless the packet arrives on the interface that the router uses to get to the source the RPF check fails and the packet is dropped. So it doesn't matter then which other interface it arrives on, if it isn't the interface that leads back to the source then it isn't the right interface.

Edit - it's called protocol independant because it will use whatever routing protocol is in use ie. it doesn't have it's own.

Jon

[CriscoSystems]

Yeah I understand how RPF works and why it requires the arrival interface to be the same as the source-bound one.

I just don't accept the second assumption, that the surprise packet is headed toward its source. I think it could be headed anywhere.

Like maybe say Milwaukee. Milwaukee's actually quite nice and the Milwaukee Repertory Theater can't be beat.

[Jon Marshall · Accepted solution]

That's why i said it helps to think of multicast in terms of packets routing away from the source.

If you think of multicast in the same terms of unicast ie. the packet is routed TO a destination then this sort of confusion arises. But multicast doesn't route TO a deatination it routes AWAY from a source.

So the second assumption that the surprise packet is headed towards the source is just misleading. What the book should be saying is that the surprise packet is not headed away from the source because it was not received on the interface that has a route to the source.

Jeff Doyle - CCIE Routing & Switching VolII may be a better book than the one you are using as i saw your other post in LAN R&S about IGMP querier.

Never been to Milwaukee but i'll take your word for it that it has a great theater :-)

Jon

[CriscoSystems]

Thanks Jon.

As I said I'm quite comfortable understanding all these concepts, I just wanted an amen that the assumption in the Hucaby book (CCNP BCMSN Exam Certification Guide 642-811, Chapter 15) was in fact misleading.

Now go to Milwaukee.

[cisco_lad2004]

Dear all

I have actually a strange behavior few days ago on 7600 based network.

I had equal path to the source in terms of both hops as well as metrics (running IS-IS + MPLS). after a slight glitch on of the links traffic re routed and I lost a bunch IPTV channels, which started gradually coming back while I was troubleshooting.

I expected Multicast to have same path as Unicast back to source, this was not the case...yest packets were still being forwarded for few channels. I had to use metrics to switch traffic unicast on one path and only then all TV channels were correctly streamed.

During my troubleshooting I used both sh ip route as well as sh ip cef, and Multicast incoming source was always different from RPF to source. sh ip RPF source showed a next hop different from incoming interface from sh ip mroute.

Any thoughts ??

TIA

Sam