Replies: 4 comments 12 replies
-
|
Hi Erik, I also work with healthcare multicast. |
Beta Was this translation helpful? Give feedback.
-
|
Hi cmongolong, The situation that I am trying now is like this (with various variations):
I configured the switch to have a static RP (which resides in the firewall), I tried both two RP's (each per VRF) or one RP, but it doesn't matter. At the moment I am trying "BSR" mode where the firewall advertises itself and the switch has it's BSR role "disabled". This all works, they can see each other, but the end result is still the same. FWIW my current configuration of pimd: I am not sure if the "altnet" is required. Formerly I also used instead of "bsr-candidate" and "rp-candidate". The configuration on the switch (VRF 19): The configuration on the switch (VRF 16): I also tried (but no difference) (two RP's): And I tried (one RP, change the pimd config accordingly): |
Beta Was this translation helpful? Give feedback.
-
|
This is interesting, the debug output says this, but ip mroute show nothing: |
Beta Was this translation helpful? Give feedback.
-
|
When routing multicast you need to ensure the TTL is > 1. It's actually more complicated than that, but lets start there since it's the most common problem. And yeah, sure you can use SMCRoute (I maintain that too), or igmpproxy and similar. Each have their advantages, I personally like pimd-dense since it "just works", basically, and you don't need much logi c except working unicast routing, which people seem to be more comfortable to set up. With SMCRoute you need to know the IP and group that the multicast sender use to really leverage the static nature of that daemon. But only you know the requirements that matters to your use-case. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thank you for your information. The TTL I actually already took care of in the previous setup, as it still would have been routed by the firewall, I set the TTL to 4 which, I think, should be enough in this situation? I think the problem i am running into is that my switch does not understand static multicast routes. So one way or another it needs to be instructed to forward the traffic that is coming into ge-0/0/26 (eos) to the firewall. I was hoping pimd would take care of that using the pim protocol, but there are never going pim join/prune requests for this group to the switch, the switch does not know of the group and the packets coming in into ge-0/0/26 are not forwarded. So how do I get the switch to add entries into it's multicast route table? I guess when not using pim, this could be achieved with IGMP. Would smcroute also send IGMP join packets? I do not really care if the remaining setup is static, dynamic, configuration per group or all, I'm already happy if I get it working. The fact that there is little information about pim and igmp on JunOS doesn't really help too. E.g. I can enable "IGMP" on an interface but what does it do? Would that also be required when using PIM or would it interfere? The interfaces having "PIM" enabled would that only be the interfaces that have a peer PIM router or also the ones having clients only? So you see, a lot of unknown variables :-( In the meantime I will have a look at igmp proxy, pimdd and compile pimd myself (I am now using a distribution version, which seems a bit old). |
Beta Was this translation helpful? Give feedback.
-
|
I am getting pretty desperate now. Nothing with either smcroute or pimdd too. Simple question, if multicast traffic enters a router (in this case ge-0/0/26) and there is no multicast routing active (or a dense one), it should simply forward/flood the traffic to all other interfaces, right? I am not seeing anything, no traffic at all. Maybe it has to do with that face that the firewall is connected through an L3 vlan interface, who knows. I think it should make no difference, there are only two hosts in it. |
Beta Was this translation helpful? Give feedback.
-
|
Only dense mode multicast routing protocols are flood-and-prune. PIM-SM/SSM are sparse mode and do not have this behavior. In PIM-SM incoming multicast is forwarded to the rendez-vous point (RP) for that group. An IGMP join on the receiver LAN is translated to a PIM Join towards that RP. If you want to run something else on your Linux firewall, e.g. SMCRoute, you need to send an IGMP join towards the Juniper on the source LAN. This you seem to have done above with the |
Beta Was this translation helpful? Give feedback.
-
|
Yes I see, I already feared this. I have spend quite a few hours now and whatever I do, the multicast traffic never gets forwarded (including pim dense mode). I am going to have one last go at trying to arrange it all statically and if that doesn't work, I'll have to leave this project until I find someone very knowledgeable on Juniper. Thanks for you help! |
Beta Was this translation helpful? Give feedback.
-
|
One other point, if you disable igmp snooping on the switch, it should treat the multicast as broadcast within the single VLAN. |
Beta Was this translation helpful? Give feedback.
-
|
igmp snooping is off, because I don't have any L2 domains on the switch. It's acting purely as a router. I have a few vlan interfaces configured because:
So there is never the situation where two clients are in the same vlan, which would call for the use of igmp snooping. What I want to do is that the switch forwards (as in: routing, not as in bridging) all non-link-scope (224/24) multicast to another interface (which happens to be a vlan interface, but is purely L3). Apparently Juniper does not facilitate this is in any way. It should be possible with pim (dense/sparse) or even igmp proxying, but nothing is happening, the multicast traffic is simply dropped. |
Beta Was this translation helpful? Give feedback.
-
|
This is the packet I am sending to the switch (ge-0/0/26): |
Beta Was this translation helpful? Give feedback.
-
Hello all,
I trying to send simple multicast traffic from my PC to my (ESP8266) microcontrollers. In the past this has worked so I am fairly confident neither the sending client nor the microcontrollers are the problem.
Now some time ago I changed my network to be fully layer 3. This has been working quite like expected, no problems there. But the multicast, I can't get it working. Formerly I had "smclient" running on the firewall which would forward all respective multicast traffic from the "intern" vlan to the "esp" vlan, works.
Now I can't do this anymore, because the switch interfaces need to be instructed to forward the multicast traffic to the firewall and the receiving client on the switch.
Please see the current situation in the drawing below:
For the time being I have enabled pim on both the firewall (pimd) and the switch VRF's (2x). I don't particularly want to use pim, but I cannot seem to add static multicast routes on the switch... I configured pimd in a very simple way on the firewall, and by golly, all instances seem to see and recognise each other. But it doesn't work.
A software client on computer eos is sending traffic to 239.19.255.1. For some reason it understands that it should be send towards the default gateway and it sends up at the link to ge-0/0/26 of the switch. The switch simply drops the traffic. It also doesn't mention a multicast route in that vrf. It doesn't even look like pimd is sending to the VRF 16 instance it likes to receive this traffic.
From the other side, the receiving clients, the igmp table at the switch shows the multicast group 239.19.255.1 does exist and is requested by one or more clients in vlan 219. Pimd also mentions this fact in the debug output, but no multicast route is created (ip mroute) and no request is made to the VRF 16 switch to deliver the traffic.
Can someone please help me get this on the rails? Unfortunately there is an overwhelming lack of documentation on this subject internet, so I am almost completely in the dark, even though I think I have a basic grasp of the subject.
Please note that although a firewall is present in the path, none of the respective traffic is dropped or rejected (checked the logging very frequently).
Note: I now see there is also a pim-dense-daemon, would that be a better option (because no pruning would be required, the "route" is static and always known in advance, I just need to get my switch to do the forwarding, based on either pim or igmp instructions).
Two of my most prominent questions:
Thank you all very much for any, just any input!
Beta Was this translation helpful? Give feedback.
All reactions