Running into a strange issue this evening on the rack.
Streaming multicast MOH from HQ to BR1. Performace counters show the MOH
source active on the server, but PSTN caller into BR1 doesn't get music.
I've done the ip pim sparse-dense on the Loopback, Vlan, and on the
virtual-template interface (this is MLPoFR) for BR1.
On BR1, sh ip mroute returns the info you'd expect:
(*, 239.2.1.1), 00:05:37/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access3, Forward/Dense, 00:05:37/00:00:00
(10.21.201.1, 239.2.1.1), 00:05:36/00:00:24, flags: T
Incoming interface: Vlan410, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access3, Forward/Dense, 00:02:32/00:00:00
(172.21.101.1, 239.2.1.1), 00:05:37/00:00:32, flags: T
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access3, Forward/Dense, 00:02:33/00:00:00
(*, 224.0.1.40), 01:19:01/00:02:24, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access1, Forward/Dense, 01:19:01/00:00:00
Virtual-Access3, Forward/Dense, 01:19:12/00:00:00
So the router KNOWS about it. But when the call goes on hold, the stream isn't
coming across. I'm really not seeing any packets across the WAN while the
caller is on hold, so I don't think it's actually sending it across. But
callers into HQ DO get multicast MOH, but of course, they are on the same VLAN
so it's easy.
So I start wondering....where the heck is it getting stuck? I've got the BR1
router set up with the
no mgcp timer receive-rtcp
ip pim-dense
no ip igmp snooping
I'm thinking....this isn't the problem. So, I back up and start looking at HQ
router. It also sees the PIM info...:
Pod21-HQ-RTR#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.2.1.1), 00:04:33/00:01:26, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access3, Forward/Dense, 00:04:33/00:00:00
(*, 239.2.1.3), 00:00:16/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access3, Forward/Dense, 00:00:16/00:00:00
(162.21.101.2, 239.2.1.3), 00:00:17/00:02:42, flags: PT
Incoming interface: Virtual-Access3, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.0.1.40), 05:50:11/00:02:45, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
So...I wonder....it couldn't be that simple....
I go in and apply the following command onto the fas 0/0.410 interface:
ip pim dense
Make a test call....and we have audio.
While this allows it to flow correctly, I'm still not clear on how it could
KNOW it was there but not flow...but at least I won't get killed by this
situation again.
Cliff
