cool, you have been a help so far.
I will do some testing and packet dumping 
(what can I say? I got curious)
This also gives you a few clues about the typical behavior of multicast traffic.
Basically, the allow rules should allow inbound IP packets from Internet with src=any, or specific multicast sources as needed and dst=group (e.g. 231.1.0.12) I suppose that outbound multicast traffic would just get the SRC natted to the ASA.
the path from the inside via the asa to first hop is not natted. so no issue there I believe !
Thinking ahead to possible future issues in the full solution - all of your âpairedâ routers, such as Y1 and Y2 - are they using HSRP/VRRP on the networks, or are you using dynamic routing? Apparently that can cause issues since the unicast route to the RP will point through a gateway that does not exist in multicast (because the individual routers use their actual address when speaking PIM)
If youâre using OSPF to balance / redundancy the various links, then PIM shouldnât get confused.
Oh, vrrp on non-wan link and no-vrrp on wan link.
Okay next step of testing.
I have 233.71.185.130 available via the first hop router
I have a client on ybostaffsup registering 233.71.185.130 on the interface with the DR router
[admin@ybortr2] /routing pim> igmp-group print detail where group =233.71.185.130
Flags: v1 - IGMPv1, v2 - IGMPv2, v3 - IGMPv3, I - include, E - exclude, F - forward, D - don't forward
v2E interface=yboStaffSup group=233.71.185.130 source=0.0.0.0 last-reported=10.172.208.220 timeout=4m10s
and
[admin@ybortr2] /routing pim> join print detail where group =233.71.185.130
Flags: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt)
SG group=233.71.185.130 source=0.0.0.0 join-state=joined timeout=52s local-receivers=yboStaffSup i-am-designated-router=yboStaff,yboStaffSup
joined-rp="" joined-wc="" joined="" pruned="" prune-pending="" assert-winner="" assert-loser="" assert-winner-wc="" assert-loser-wc=""
assert-tracking-wc=yboStaffSup could-assert-wc=yboStaffSup immediate-rp="" immediate-wc=yboStaffSup immediate-sg-rpt=yboStaffSup
So now ybortr2 (y2) doesnât know how to get to 233.71.185.130. Do I need to add in a rp entry on each rtr ?
add group=233.71.185.0/24 comment="ASX Itch" address=10.43.200.6
[admin@ybortr2] /routing pim> join print detail where group =233.71.185.130
Flags: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt)
SG group=233.71.185.130 source=0.0.0.0 rp=10.43.200.6 upsteam-interface-rp=GSYBO upsteam-pim-nexthop=10.31.17.3 join-state=joined timeout=37s
local-receivers=yboStaffSup i-am-designated-router=yboStaff,yboStaffSup joined-rp="" joined-wc="" joined="" pruned="" prune-pending=""
assert-winner="" assert-loser="" assert-winner-wc="" assert-loser-wc="" assert-tracking-wc=GSYBO,yboStaffSup could-assert-wc=yboStaffSup
immediate-rp="" immediate-wc=yboStaffSup immediate-sg-rpt=yboStaffSup include-wc=yboStaffSup
Bit better
But when i jump onto g2 (10.31.17.3) i see nothing
So add the same static rp
[admin@gsrtr2] /routing pim> join print detail where group =233.71.185.130
Flags: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt)
SG group=233.71.185.130 source=0.0.0.0 rp=10.43.200.6 upsteam-interface-rp=MAN upsteam-pim-nexthop=10.31.19.1 join-state=joined timeout=18s
local-receivers="" i-am-designated-router=GSYBO,Management joined-rp="" joined-wc="" joined=GSYBO pruned="" prune-pending="" assert-winner=""
assert-loser="" assert-winner-wc="" assert-loser-wc="" assert-tracking-wc=MAN,GSYBO could-assert-wc=GSYBO immediate-rp="" immediate-wc=GSYBO
immediate-sg-rpt=GSYBO include-wc=""
now connected - so I have to add the static rp info to all my routers
I can even see the join request on the ASA5520 ⌠but its not forwarding it on 
But good so far
The ASA needs to know the RP address also.
According to the Cisco document I linked earlier:
Complete these steps:
! Enable multicast routing (global configuration mode).
ASA(config)#multicast-routing! Configure static RP address
ASA(config)#pim rp-address 10.43.200.6! Allow multicast group 224.1.2.3 from outside:
ASA(config)#access-list 105 extended permit ip any host 224.1.2.3
ASA(config)#access-group 105 in interface outside
(i would not paste the access-list commands into ASA - just use them as a reference for how the ASA sees the multicast streams themselves.)
You may need to enable pim sparse mode on the individual interfaces, but that wasnât in this particular âlook how easy it isâ list of commands.
EDIT: I saw you wondering aloud âshould I add the RP on every router?â - I thought I had said that, but yes, it is needed unless youâre using auto-RP.
Now I want to see you post âSUCCESS!!!â
Go the access list
added the rp-address already
But on the first hop router I dont see the join .. going to try and add a static igmp command
Cisco recommends pim-sparse mode on each interface. I somehow sense from reading the document I found that this is the default - look at the configs of the ethernet interfaces and make sure they donât have âno pimâ in their settings.
Okay getting into cisco territory.
! this is the outside
interface GigabitEthernet0/2.11
pim dr-priority 100
igmp join-group 233.71.185.130 !! Added this to force the IGMP
interface GigabitEthernet0/3.19
pim dr-priority 100
IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,
RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,
RR - Register Received, SR - Sending Registers, E - MSDP External,
DCC - Don't Check Connected
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Disinterest,
II - Internal Interest, ID - Internal Disinterest,
LH - Last Hop, AS - Assert, AB - Admin Boundary
(*,233.71.185.130) SM Up: 00:49:51 RP: 10.43.200.6
JP: Join(now) RPF: premium,10.43.200.6* Flags:
premium 00:16:25 off LI II
ybman19 00:49:51 fwd Join(00:02:39)
I can see input on show pim join stat
dcfw1/sec/act# show pim traffic
PIM Traffic Counters
Elapsed time since counters cleared: 6d15h
Received Sent
Valid PIM Packets 101866 42241
Hello 57581 38708
Join-Prune 15032 59
Register 3474 0
Register Stop 0 3474
Assert 0 0
Bidir DF Election 0 0
Register stop ⌠not sure what that mean.
access-list premium_in line 13 extended permit udp host 203.6.253.212 host 233.71.185.130 eq 31003 (hitcnt=1415) 0xaf8474d0
I can see thats the packets are making in..
but not out !
The priority 100 part on the outside interface might be the problem. next-hop router should probably be highest priority on that segment.
Also - forcing join on outside interface is not a real solution. (pretty sure you know that, though)
Is there an output rule on the inside interface that could be blocking the traffic?
I had the ROS VM at dr-priority 200, but remove the 100 from the ASA
no outbound filter.
The force join to is just to show it working.
But interestingly even though the asa is getting the MC stream on the outside interface and getting a request for it on the inside it doesnât match the 2 together ! very annoying.
I have a acl to allow the MC in on the outside.
So progressed a bit further.
I now have a join coming from source through 2 ros servers to a cisco ASA and now onto the first hop router.
This is where the issue is
15:15:20 pim,debug RX PIM_JOIN_PRUNE from 10.43.200.1 to 224.0.0.13: (*,G) Join/Prune entry for group 233.71.185.130 RP address does not match: router RP = 203.0.119.247, message RP = 10.43.200.6
I have been given an RP to use which I have setup for my first hop rtr, but I was using the first hop rtr as the RP for my network .
and it seems like it doesnât like it
do I have to setup all of my internet routers to point to the providers RP ?
So I have made the changes to all the test rtrs so they point to the providers RP for the MC group I am after.
Now I have registered and I can see MC udp packets come to me on my vendors interface, but they are not being sent to the cisco firewall
/ip route> /ip route print where 233.71.185.130 in dst-address
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 0.0.0.0/0 10.43.200.1 110
1 S 0.0.0.0/0 10.43.200.1 250
2 ADo 224.0.0.0/4 10.43.200.1 110
I think line 2 is the issue, it wants to send it via 10.43.200.1, when I was testing last time I had to add a 224/4 via interface..
This could be because I have OSPF picking up 224/4 I will have to track that down
The multicast RIB/FIB tables will override the unicast ones, plus a join to a group adds a â/32â destination, so I wouldnât think the routing table is to blame. (but it could be, I am by no means anywhere near being a mcast expert - Iâm just trying to be a âsecond pair of eyesâ with you). The ânext hopâ of the 224.0.0.0/4 ospf route is definitely not true for your network, though. If you simply want to override that one route for test purposes, create the same route with a static route, but set next hop to be the ASA.
I will say that it sounds like youâre on the right track with the RP address - all members of a particular group must use the same RP. If your external source is being sent to external RP, then your network must go there too. (at least for this one group).
So for 233.71.185.130, RP should be 203.0.119.247 in all of your routers.