I'm trying to get PIM SM working throug an ASA. All works as expected on the side of the firewall where the source (IPTV Server) resides
but am getting nothing on the inside interface. The traffic originated on a lower security interface.
I have the source connected to a 6500 on the lower security interface which also acts as the RP.
The 6500 on the inside points to the same RP on the lower security interface.
Multicast routing is enabled on the ASA and the relevant interfaces have PIM enabled with the ASA also pointing to the same RP.
I had this working in dense mode but wanted to change to sparse. Are there any NAT/Access-list issues I may have overlooked on the ASA ?
I did see an issue where the firewall was complaining the the rpf route was not from a PIM neighbour but that was because the route back was via an HSRP address. I changed that to a physical address and that issue cleared.
The first test is to pick up a stream on group 184.108.40.206 which advertises available TV channels. I never see the channel list on the inside stations.
I have no IGMP rules in the firewall. I have PIM running on the relevant interfaces. My understanding is IGMP stops at the 1st router and the join is relayed in PIM messages. I'm sure I have the relevant PIM rules in place. In fact as a test I have allowed pim any any through both interfaces.
On the more secure side I do see the (*,G) entry and it is marked as being forwarded out the proper interface and incoming on the proper interface.
Likewise on the RP is see an entry for the 2 sources of the stream I need to get.
The firewall sees the (*,G) entry on the proper interface and forwards it on the proper interface.
If I do a packet capture on the incoming interface to see if the stream hits it I don't see anything. Does a capture show packets even if the appliance would drop them ? So is the fact I am not seeing them that they are not getting there or is it possible the appliance drops them and doesn't show them ?
The RP can more often than not just be a temporary step as the client host, once set up, finds a better path to the source and prunes the "longer" route via the RP.
Reading your posts again it seems like the 6500 that is configured as the RP is the shortest (only) route anyway so isn't going to get pruned. Just ignore me !
In short it sounds like the registration side of things is working but that you aren't getting any flow when it comes to the media.
Anyhoo - it sounds like you can't see packets getting dropped at the outside interface?
From the top of my head - I don't think that you see packets against the implicit deny all so what I have done before is (temporarily) make my own explicit "deny any any" and add it at the end of the rule table for that interface. You can then investigate the packets dropped and some of thse should be the multicast stream that is trying to get through.
Furthermore if you go into the logging pane and look for your multicast IP address you should now see your stream getting dropped if there isn't an explicit rule to let it through.
The latest I have found is when I do a packet trace from the RP to the 239 group address the ASA drops it with the following error.
Drop-reason: (security-failed) Early security checks failed
The explanation for this doesn't help much
This counter is incremented and the packet is dropped when the security appliance:
•Receives an IPv4 multicast packet when the packet multicast MAC address does not match the packet multicast destination IP address
•Receives an IPv6 or IPv4 teardrop fragment containing either small offset or fragment overlapping
•Receives an IPv4 packet that matches an IP audit signature
Recommendation: Contact the remote peer administrator or escalate this issue according to your security policy. For detailed description and System log messages for IP audit attack checks please refer the ip audit signature command.
System log messages: 106020, 400xx in case of IP audit checks
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...