Multicast Deploy Error - Layer 3 (UDP-Receiver registration)
-
Server
- FOG Version: 1.3.4-rc-2 (SVN 6063)
- OS: Debian 8 (Jessie)
Description:
The fog works with L2 mc deploy without problems.
If it is to deploy to another broadcast domain, the multicast does not start.The forwarding is via PIM in dense mode and the function has been verified with IC_Tester_Mcast_v02 (MC forwarding no problems!)
The “FOG Multicast error search” (udp-sender … / udp-receiver) does not register the client. With the addition --mcast-rdv-address <IP-FOG>, the FOG reports “problem getting data from Client: Success”
In the log is also not the ip of the client but the gateway.
Forwarding is controlled by a checkpoint SG.
Any idea?
-
Can you clarify?
Multicast is a layer 2 element. We do have the mcast-rdv-address already setup. The “gateway” is because you aren’t sending the traffic to the whole network, you’re making the client request the data from the server. This way you aren’t blasting your entire network infrastructure with multicast packets.
If your network is blocking multicast traffic from passing different broadcast addresses, I don’t know what to do.
Manually running stuff is a whole different ball game because YOU are in full control of the system that’s distributing data around. FOG is more meant as an automated means of distribution, so multicast is not a perfect system. If you know what’s wrong and a way to fix it let us know please.
From the man page of udp-receiver (which the clients use to get the data):
--mcast-rdv-address address Uses a non-standard multicast address for the control connection (which is used by the sender and receivers to "find" each other). This is not the address that is used to transfer the data. By default "mcast-rdv-address" is the Ethernet broadcast address if "ttl" is 1, and 224.0.0.1 otherwise. This setting should not be used except in very special situations, such as when 224.0.0.1 cannot be used for policy reasons. -
Ok i try it
The man page of udp-receiver I know and therefore knows that the L2 registration over the broadcast and had it also verified with my tracker. Because of the, in my network structure necessary multicastforwarding as source IP is displayed not the client IP but the forwarder.I’m wondering how the FOG makes multicast distribution beyond broadcast boundaries. You have in your wikis rudimentary hints to multicast routing (PIM with dense-spars-mode). The real mc works with me yes …
Regardless of my problems - THANKS to the team for your gigantic work!
-
If the readiness of the client would be sent to the server as unicast (TCP) … * sigh *
