05-22-2012 07:32 PM
05-22-2012 11:49 PM
Neither VLANs&trunking no PIM&ospf are required for this. IGMP proxy functionality of ScreenOS solves the problem. Configure the port on the multicast source site as an IGMP proxy in the host mode and the port on the listener site as an IGMP proxy in the router mode. Configure a bidirectional multicast policy that enables IGMP transfer between both zones and an access policy for the multicast stream. You can read more on this in C&E, Vol. Routing.
05-23-2012 08:56 AM
Thank you Edouard for responding. From what I am reading about the igmp proxy, it takes an igmp request and forwards it onto the host. The problem is the host cannot handle igmp requests. Also, we have other ports being used on the firewall with igmp enabled. Some of them were getting some sort of traffic from the multicast streams apparently, but none of them should have been sending any igmp requests. I was seeing this in the mroute summary for my vr. Any thoughts would be much appreciated.
05-24-2012 12:12 AM
IGMP Proxy accepts IGMP join requests from the the hosts interested in the multicast on its interface(s) configured in the route mode and generates its own join requests on behalf of these hosts. These requests are forwarded to the multicast source(s) through the interface(s) configured in the host mode. The multicast sender (source) accepts IGMP requests from the Firewall and initiates the multicast stream which is udp, as a rule. Sure, this is a very simplified description.
As soon as there is at least one active multicast sender the FW sees these multicasts on its inetrface(s) independend on the interface configuration. The multicast packets are not forwarded to another interface if no IGMP proxy and policies are configured. With other words, if you see the multicasts on an interface this does not mean that the FW participates at the multicast transport. The packets are simply dropped. To disable ennoying logging of the dropped multicast one can use the command set firewall log-self exclude multicast.
The IGMP/multicast realization in ScreenOS is just excellent. So you can configure the tunnel interfaces as IGMP proxies and transport multicasts over a longer chain of SSGs and routed networks using IPSec. You can encapsulate the multicast in GRE and transport it to a third party devices, you can use NAT on the multicast etc, etc.
06-01-2012 11:27 AM
TI am sorry for the late response. hank you echidov for your response. Based off of your description of the IGMP proxy, I cannot implement this. The multicast source cannot handle igmp requests. The firewall is supposed to handle this. This is the line I am referring to:
" These requests are forwarded to the multicast source(s) through the interface(s) configured in the host mode."
Any other suggestions would be helpful, unless you know how to still get IGMP proxy to work.
Thank you for your help so far!
06-03-2012 11:58 PM
If the multicast sources cannot handle igmp requests and are sending the multicast stream permanently you can try to configure the static multicast routes for the MC groups and MC sources that are used. Igmp proxy is not required in this case. I never used the static MC routes but this should work.
06-04-2012 08:36 AM
I have tried using mcast routing to set up static routes. There is one problem right now with it. The mulitcast address will change. The source address will always be in the same subnet. With this in mind, I have been trying to use OSPF routes with PIM-SM to accomplish this. Another issue is it seems to dump the multicast stream over the physical port that you are telling it as the outbound port. I think this has caused my routers to crash when trying to handle a minimal of 5 multicast streams, plus everything else on that subnet. It is a suspicion that I have yet to confirm. If you have a better solution, I will try it. Thanks for your help!
06-05-2012 12:28 AM
You can create a static route for multiple (all) multicast addresses. If you have the sources that are not allowed to forward MC through the firewall you can easiely block them witha restrictive access policy (one source only). If you have very havy allowed MC traffic, that cannot be processed by the firewall and the routers, neither of the soultions will solve the problem. You a need faster devices in this case.
If the routers are supposed to crash because of the MC you can enable bandwidth management in the policy and try to reproduce this situation using varying bandwidth values. The firewall and routers performance values, fragmentation, other statistics etc. should also be analyzed.