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)
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
