Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Multicasting RPF question from a troublemaker

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?

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Blue

Re: Multicasting RPF question from a troublemaker

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

5 REPLIES
Hall of Fame Super Blue

Re: Multicasting RPF question from a troublemaker

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

Re: Multicasting RPF question from a troublemaker

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.

Hall of Fame Super Blue

Re: Multicasting RPF question from a troublemaker

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

Re: Multicasting RPF question from a troublemaker

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.

Re: Multicasting RPF question from a troublemaker

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

118
Views
0
Helpful
5
Replies
CreatePlease to create content