[cisco-voip] ip Multicast MoH with zone Based Firewalls?

[Scott Voll]

As a follow up to the thread:

Worked with TAC.

unfortunately had to stop Troubleshooting as TAC caused me two network
outages :-(

But what we did figure out is that the "packet routing is failing" , the
packets are not being processed.

And we can see that the counter stops at 249 every time we clear it on the
sh ip mroute 239.1.1.1 count.

Kind of sounds like a bug to me,  But need to schedule some more time with
TAC during non business hours.

Scott



On Thu, Mar 15, 2012 at 9:13 AM, <James.Brown at barclayswealth.com> wrote:

> Scott,
>
> I wasn't sure from your description whether your problem is that MMOH
> isn't being received by IP Phone holdee's, or by callers on a PSTN gateway.
>
> Assuming it's the IP Phones that don't hear it, you may find it easier to
> start the troubleshooting close to the phones. When you place one of the
> phones on hold (perhaps you can use Auto-Answer), check the webpage to
> ensure the Stream local address gets programmed to "239.1.1.1".
>
> If it does, you know the signalling is working correctly. Next step would
> be a "sho mac-address-table multicast | in 0100.5e" on the switch closest
> to the phone to make sure the CAM table is ready to deliver multicast
> packets. Then move up to the phone's router and run "sho ip igmp
> membership" to ensure there is an IGMP membership report (i.e. a join
> request). A "show ip mroute 239.1.1.1" should then give a *,g entry for
> packets coming from the RP and (at least in sparse mode), you would get an
> s,g entry for the gateway/CM that is publishing the MMOH packets. This may
> depend on the router's setting for "ip pim spt-threshold", because if this
> is set to infinity, you won't cut over to the shortest path.
>
> How do you avoid travelling to site!? If you've got the Cat65k platform,
> you could always try an elam capture. The only other option I can think of
> is "sho ip mroute 239.1.1.1 count" which lists the number of packets
> received from hosts publishing MMOH packets to the Mcast address. You
> mentioned sending MMOH over a GRE tunnel and I guess you should also check
> that "ip pim" is configured on the tunnel interfaces.
>
> Hope this helps
>
> James.
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] On Behalf Of Wes Sisk
> Sent: 14 March 2012 18:07
> To: Scott Voll
> Cc: cisco-voip at puck.nether.net; cisco-nsp at puck.nether.net
> Subject: Re: [cisco-voip] ip Multicast MoH with zone Based Firewalls?
>
> wild guess: is the multicast time to live expiring before it reaches that
> site?
>
> On Mar 14, 2012, at 1:56 PM, 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 =)
>
> TIA
>
> Scott
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> Barclays Wealth is the wealth management division of Barclays Bank PLC.
> This email may relate to or be sent from other members of the Barclays
> Group.
>
> The availability of products and services may be limited by the applicable
> laws and regulations in certain jurisdictions. The Barclays Group does not
> normally accept or offer business instructions via internet email. Any
> action that you might take upon this message might be at your own risk.
>
> This email and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this email
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this email or
> its attachments.
>
> Internet communications are not guaranteed to be secure or without
> viruses. The Barclays Group does not accept responsibility for any loss
> arising from unauthorised access to, or interference with, any Internet
> communications by any third party, or from the transmission of any viruses.
> Replies to this email may be monitored by the Barclays Group for
> operational or business reasons.
>
> Any opinion or other information in this email or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
>
> Barclays Bank PLC. Registered in England and Wales (registered no.
> 1026167).
> Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
>
> Barclays Bank PLC is authorised and regulated by the Financial Services
> Authority.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120315/280eb257/attachment.html>