12-18-2018 05:17 AM - edited 03-03-2019 08:57 AM
Hi,
I've been troubleshooting this multicast issue for a week now and getting no where!
It is new configuration to get multicast traffic from one side of a firewall to the other using GRE. Devices on both sides of the firewall could be the source of the traffic. One side is a ASR 1001-X, the other is a Cat3650.
To test it, I am running a simple multicast test tool (IC Tester). A server whose gateway is on the ASR is generating multicast traffic to the 239.192.0.11 group on UDP/12345. Wireshark is also running in the background and I can see the multicast packets in the capture.
A server whose gateway is on the Cat3650 is configured to join the 239.192.0.11 group and is listening for the packets. Wireshark is running there also. The capture shows the server is sending regular "Membership Report group 239.192.0.11" packets to the group but no multicast traffic is received - most of the time.
I left the test running when I went to see a colleague earlier and when I returned, one multicast packet had made it through to the listener. It has now been running for about 3.5 hours. The counter on the source is showing it has sent 12898 packets to the group. The listener has received 8 of them.
My question is, how do some get through and most fail? My guess is pruning based on the way the tunnel interface shows as "Prune/dense" the majority of the time when I look at "show ip mroute". Why is a mystery to me. I have recently received a copy of the Cisco Press IP Multicast Vol:1 book which I hoped would contain the answer, or a hint, but I've not found that page yet!
Thanks,
Andrew
Here is some of the configuration (sanitised) which may be useful:
Gateways
lanRtr_theSource#show run int gi0/0/x.xxx
Building configuration...
Current configuration : 341 bytes
!
interface GigabitEthernet0/0/x.xxx
encapsulation dot1Q xxx
ip address 10.x.x.x 255.255.255.192
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim dense-mode
standby version 2
standby x ip 10.x.x.x
standby x timers msec 300 msec 900
standby x priority 254
standby x preempt
end
dmzSwitch_theListener#show run int vlanxxxx
Building configuration...
Current configuration : 274 bytes
!
interface Vlanxxxx
ip address 172.x.x.x 255.255.255.0
ip pim query-interval 15
ip pim dense-mode
standby version 2
standby x ip 172.x.x.x
standby x timers msec 300 msec 900
standby x priority 255
standby x preempt
ip igmp query-interval 15
end
Tunnel config
lanRtr_theSource#show run int tu5
Building configuration...
Current configuration : 245 bytes
!
interface Tunnel5
ip address 172.30.x.xxx 255.255.255.252
ip pim query-interval 15
ip pim dense-mode
ip igmp query-interval 15
tunnel source Loopback5
tunnel destination 172.17.x.x
end
dmzSwitch_theListener#show run int tu5
Building configuration...
Current configuration : 241 bytes
!
interface Tunnel5
ip address 172.30.x.xxx 255.255.255.252
ip pim query-interval 15
ip pim dense-mode
ip igmp query-interval 15
tunnel source Vlanxxx
tunnel destination 172.xx.x.xx
end
show ip igmp groups
lanRtr_theSource#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.192.0.11 GigabitEthernet0/0/X.XXX 03:47:24 00:02:35 0.0.0.0
dmzSwitch_theListener#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.192.0.11 VlanXXX 03:34:45 00:00:22 172.x.x.x
show ip mroute
lanRtr_theSource#show ip mroute 239.192.0.11
(*, 239.192.0.11), 03:55:11/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel5, Forward/Dense, 03:55:11/stopped
Tunnel4, Forward/Dense, 03:55:11/stopped
Tunnel3, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.a, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.b, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.xxx, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.c, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.d, Forward/Dense, 03:55:11/stopped
GigabitEthernet0/0/x.e, Forward/Dense, 03:55:11/stopped
(10.1.238.37, 239.192.0.11), 03:55:11/00:01:40, flags: PT
Incoming interface: GigabitEthernet0/0/x.xxx, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/x.a, Prune/Dense, 03:55:10/00:00:52
GigabitEthernet0/0/x.b, Prune/Dense, 03:55:10/00:00:52
GigabitEthernet0/0/x.c, Prune/Dense, 03:55:09/00:00:53
GigabitEthernet0/0/x.d, Prune/Dense, 03:55:09/00:00:53
GigabitEthernet0/0/x.e, Prune/Dense, 03:55:08/00:00:54
Tunnel3, Prune/Dense, 00:01:49/00:01:29
Tunnel4, Prune/Dense, 00:00:32/00:02:27
Tunnel5, Prune/Dense, 00:01:04/00:01:55
dmzSwitch_theListener#show ip mroute 239.192.0.11
(*, 239.192.0.11), 03:50:04/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
VlanXXX, Forward/Dense, 03:50:04/stopped
TunnelX, Forward/Dense, 03:50:04/stopped
(10.1.238.37, 239.192.0.11), 00:22:51/00:00:59, flags: PT
Incoming interface: Tunnel5, RPF nbr 172.xx.x.xxx, Mroute
Outgoing interface list:
VlanXXX, Prune/Dense, 00:04:59/00:00:56
01-09-2019 09:20 AM
Hello,
Could it be that the tunnel is not the only route between the source and receiver? In other words, the tunnel is one possible path, but the aside from that do you expect other traffic to use the main interfaces for other connectivity. If that is the case, the firewall would block the multicast stream.
Not sure if it would work, but if you route all traffic between the two subnets through the tunnel, possibly with static routes, it may fix the issue. The only caveat there is that now you are tunneling everything through the firewall making it basically useless.
Hope this is of some help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide