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

Question on simplest multicast routing setup

Given these:

- a multicast source, connected in vlan V1 to a switch with igmp snooping enabled

- a router with two interfaces connected to the same switch (one in vlan V1 and one in vlan V2), with ip pim sparse-mode enabled on both

- a receiver, connected in vlan V2 to the same switch

 

my question is:  in order for the receiver to be able to access whatever the source is transmitting, is it mandatory that the receiver and the corresponding router interface (the one in vlan V2) have IP addresses belonging to the same subnet?

 

Thank you.

5 REPLIES
Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

No.

 

[edit]

"No" is not correct for the actual asked question.  (I thought question was, basically, are source and receiver required to be within same subnet/VLAN.)

Let's complicate the matter a

Let's complicate the matter a little bit - maybe I'll finally get to the bottom of an issue that's been bothering me for a long time.  In the attached drawing we have as follows:

- SRC1 and R1 are not under my control

- R2 has sparse-mode multicast routing enabled on both interfaces and RP "statically" declared as itself (no matter what IP address I use, I get the same results)

- the RECeiver has access to what SRC1 outputs (224.4.4.4), but doesn't have access to what SRC2 outputs (225.5.5.5)

- if I turn SRC2 into a receiver and connect it to Vlan111, it has access to 224.4.4.4

The question is why the RECeiver doesn't get 225.5.5.5 through R2.  When R2 was a Cisco, "show ip mroute count" would increment "Other drops";  right now R2 is a Mikrotik which logs something like "pim,warning RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.2 to 225.5.5.5 on vif G0: source must be directly connected" (but SRC2 is directly connected to R2, and you said that REC doesn't have to be in the same subnet with R2).

Thank you.
 

Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of   the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Six months for a follow-up question?  Ok - laugh - but that's not a problem.

Taking you last question first, when I said multicast receiver doesn't have to be in the same subnet; well is REC in the same subnet as SRC1?  If not, that's an example that the multicast source and mutlicast receiver can be in different subnets.

In your newly posted drawing, your topology add issues not noted in your original question.

For starters, although R2 shows its G0 connected to VLAN 111, it also shows that interface being in a different subnet than used by REC.  So, yes, there's a physical connection, but it's logically different, and explains, I believe, the message that G0 is receiving membership reports from 10.10.10.2 but it's not connected.  I.e. G0 only expects membership reports from hosts within the 11.11.11.0/24 subnet.

If you reassign REC an 11.11.11.0/24 IP, you may start to obtain SRC2's multicast, although you'll then lose multicast from SRC1.

My guess, your next question would be, is it possible for REC to obtain multicast from both SRC1 and SRC2, concurrently.  The answer is yes, but how to accomplish that can become complicated since R1 is not under your control.

Normally, R1 and R2 would "cooperate" as multicast routers.  But if they don't, you can make R2 to appear to be a host (10.10.10.2) always wanting the 224.4.4.4 multicast stream.  Once it pulls the stream, you can multicast it to wherever you want.  For example, you could reassign REC to the 11.11.11.0/24 subnet, and then you could obtain both the 224.4.4.4 and 225.5.5.5 multicast streams.

REC is not in the same subnet

REC is not in the same subnet as SRC1, but my initial question was about the receiver being in the same subnet as the router, not the source...

The setup in production is like in the picture, but without R2 and with SRC2 in VLAN 111.  The thing is, more and more SRCs will be deployed in several places in our network, and I'm trying to avoid mixing them all in the same VLAN.  I'm not really interested in R2 "cooperating" with R1 either (although I could talk to the people in charge of R1 and work things out) - basically what I need is REC taking SRC1 from R1 and SRC2 (and others in the future) from R2.

I'm also going to try bringing R1, REC and R2-G0 in the same subnet but, given the answer to my initial question (about direct connectivity between the receiver and the router), I'm wondering why my goal isn't achievable with the current (pictured) IP setup...

Another thing that I don't understand is that, when I enable pim on R1-G0, G0 immediately shows input traffic equal to the cumulated bandwidth of all multicast groups in VLAN 111.

Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of   the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Ah, I did misread your question about receiver and router interface!  Since no one else countered my original response, I may have not been alone in misreading your question; so sorry!

In answer to your original question (now understood, I hope), I'm not really sure, but certainly it would be unusual.  I can see it possibly causing issues, especially with "pull" kinds of multicast and IGMP.

Another solution might be to have R2 with IP for multiple subnets for VLAN 111, but an issue with that is REC is a host on a /30.  So, as I wrote in my prior reply, you might have R2 take REC's IP, move REC to another IP, and multicast to it.

BTW, again, things can become complex if R1 and R2 don't cooperate.  Multicast expects a single IGMP querier, and PIM too normally expects just one router on a shared subnet to deliver the same multicast stream.  (Or, as you mentioned SM's RP, that too is normally known/shared/same across all the multicast routers within the same multicast topology/domain.)

So, although you don't desire to "cooperate" with R1, not doing so, I believe, will make desired multicast more complicated.  Besides the approach making R2 appear as "REC" to R1, multicast also has options for sharing between multicast topologies/domains, but I don't have any first hand experience with that.

Again, so sorry for having misread your original question and providing you an incorrect answer.

368
Views
0
Helpful
5
Replies
CreatePlease to create content