[c-nsp] ip Multicast MoH with zone Based Firewalls?

[Phil Mayers]

On 14/03/12 17:56, Scott Voll wrote:
> I have a Voice deployment with a remote site that has multicast Music on
> hold.  The 2821 that it goes through also has Zone based Firewalls so I can
> do GRE over IPSec.(which is not the interface that the Multicast Moh is
> using)
>
> my problem is that my Music on hold is not working.
>
> sh ip mroute shows:
>
> (*, 239.1.1.1), 00:50:22/00:02:58, RP x.y.1.252, flags: SJC
>    Incoming interface: GigabitEthernet0/1.902, RPF nbr x.z.9.254<  == WAN
> Metro E
>    Outgoing interface list:
>      GigabitEthernet0/0.1026, Forward/Sparse-Dense, 00:00:01/00:02:58
> <==Phone network
>
> 239.1.1.1 is my Multicast MoH
>
> The RP is correct.
>
> both interfaces .902 and 1026 are in the INSIDE zone with a Zone policy of
> class default pass
>
> I'm running 15.1(3)T2,
>
> Is this a zone based FW issue?  a Multicast issue?  or a Bug?  I'm not sure
> which way to go..... other then drive to the remote site and do a packet
> capture.  Other ideas?  I'm trying not to drive =)

Disclaimer: I know nothing about ZBFw.

There isn't really enough information here. You'd need to specify the 
topology in a bit more detail. Where is the source of the MoH? Have you 
traced the PIM join state from the source to the RP, and from source to 
receiver, and from RP to receiver?

Since you don't have an (s,g) entry, I'm guessing the RP is either not 
receiving the Register packet, or the packet isn't being sent down the 
shared-tree to the edge router, thus an (s,g) join isn't working.

MTU might be an issue here, if the MoH packets are "large". This is a 
bit of a pain with PIM registers, and whether the inner or outer packet 
is fragmented varies by IOS version IIRC.

More details, please ;o)