Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] Procedure to troubleshoot multicast traffic flow issues

0

0

Article ID: KB21149 KB Last Updated: 05 Jan 2021Version: 3.0
Summary:

This article describes the procedure to troubleshoot multicast traffic flow issues.

 

Symptoms:

Environment

  • Customer wants to pass multicast traffic over the VPN.

  • Customer is using PIM for multicast routing.

Network diagram:

192.168.3.4 (sender and Rp) -----192.168.3.1(trust) (bgroup0)Fw-1(eth0/1)—tun.1---- 10.10.10.194-----11.11.11.34-tun.2--(eth0/1)Fw-2(bgroup0)--192.168.2.1-----192.168.2.3(receiver)

 

Solution:

Perform the following procedure to troubleshoot the multicast traffic flow issues:

  1. Understand the network diagram, which is very important to comprehend the packet flow.

  2. Collect information about the mcast source and receiver, including the zone in which they reside.

  3. Verify the mcast policy (for multicast control traffic), mcast route, clear-text policy, and underlying destination route.

  4. Make sure that PIM and IGMP are enabled on the interfaces according to their functionality.

  5. Make sure that the host is joining the mcast group:

Firewall-2-> get igmp group all
total groups matched: 2
multicast group interface last reporter expire ver
12.12.12.60 bgroup0 192.168.2.3 259s v2 

If the host is not joining the group, then check the IGMP statistics and check how many IGMP membership report messages have been received. See the below output:

Firewall-2-> get igmp stat
Interface bgroup0 IGMP statistics:
IGMP total messages received: 317
IGMP messages received with invalid length: 0
IGMP messages received with invalid checksum: 0
IGMP messages received with invalid TTL: 0
IGMP messages received from different subnet: 0
IGMP messages received with invalid IP router alert option: 0
IGMP total query messages received: 0
IGMP bad query messages received: 0
IGMP total report messages received: 265
IGMP bad report messages received: 10
IGMP report messages for our groups received: 245
IGMP total leave messages received: 10
IGMP total messages sent: 164
IGMP total query messages sent: 164
IGMP total report messages sent: 0
IGMP total leave messages sent: 0

If you do not see the report messages received counter increasing, that means the IGMP packets are not being received. For further checking, apply the snoop filter snoop filter ip ip-proto 2 and confirm whether the IGMP packets are being received or not. The IGMP packets might be getting dropped, if there is a layer-3 device in between the host and the firewall. The IGMP packets will not come to the firewall, as the ttl value for the IGMP packets is 1. The packet will be destined for the multicast group. See the below output:

>253711.0: bgroup0(i) len=175:18a90596b956->01005e7ffffa/0800
192.168.2.3 -> 12.12.12.60/17
vhl=45, tos=00, id=9334, frag=0000, ttl=1 tlen=161
udp:ports 60621->1900, len=141

IGMP total query messages sent: 164-> This entry will increase when the firewall is sending IGMP query packets to the host in the LAN.

Run debug igmp all and see if the host is joining the group:

## 2010-10-05 14:13:19 : received raw igmp pak from 192.168.2.3 through bgroup0
## 2010-10-05 14:13:19 : IGMP traffic on interface bgroup0
## 2010-10-05 14:13:19 : IGMP: bgroup0 receive igmp packet(v2 report, 0, 0x7fd, 12.12.12.60) from 192.168.2.3 to 12.12.12.60
## 2010-10-05 14:13:19 : IGMP: bgroup0 (router mode) receive membership report

## 2010-10-05 14:13:19 : IGMP: bgroup0 add igmp group 12.1.1.60
## 2010-10-05 14:13:19 : IGMP: group 12.12.12.60 was created on bgroup0
## 2010-10-05 14:13:19 : IGMP: mrt trigger group 12.12.12.60 join on bgroup0
  1. If the IGMP host is joining the multicast group, then the next step is to verify the PIM configuration and neighborship.

  2. In the case of PIM-SM (igmp v2), we need to have RP (Rendezvous Point) configured in the firewall.

  3. Make sure that the PIM neighborship is formed with the PIM neighbor.

alloc 225/max 2064, alloc failed 0,
mcast alloc 2637, di alloc failed 0 total reserved 0, free sessions in shared pool 1839
Total 2 sessions according filtering criteria.
if 21(nspflag 800601):10.10.10.194/1->11.11.11.34/1,103,0012f22f6800,sess token 3,vlan 0,tun 0,vsd 0,route 128
if 3(nspflag 2002010):10.10.10.194/1<-11.11.11.34/1,103,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0
id 477301/s**,vsys 0,flag 00001040/4882/0023/0000,policy 320002,time 180, dip 0 module 0
if 38(nspflag 800605):10.10.10.194/1->12.12.12.13/1,103,0016c783647f,sess token 21,vlan 2050,tun 0,vsd 0,route 66
if 3(nspflag 2002010):10.10.10.194/1<-12.12.12.13/1,103,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0

Run debug pim all to check if the pim hello packets are being exchanged:

## 2010-10-05 14:14:16 : trust-vr: PIMSM Hello send on interface trust
## 2010-10-05 14:14:16 : trust-vr: PIMSM Tx'ed PIM pkt 192.168.2.1->12.12.12.13, hello, len=26
## 2010-10-05 14:14:16 : trust-vr: PIMSM Hello send on interface tunnel.2
## 2010-10-05 14:14:16 : trust-vr: PIMSM Tx'ed PIM pkt 11.11.11.34->12.12.12.13, hello, len=26
## 2010-10-05 14:14:16 : trust-vr: PIMSM rx queued src=192.168.2.1 dst=12.12.12.13 ifp=trust
## 2010-10-05 14:14:16 : trust-vr: PIMSM rx queued src=11.11.11.34 dst=12.12.12.13 ifp=tunnel.2
## 2010-10-05 14:14:16 : PIMSM: Control packet enqueued to PIM task
## 2010-10-05 14:14:16 : PIMSM: Control packet Event has been sent to PIM from IP
## 2010-10-05 14:14:16 : PIMSM: Received events 40
## 2010-10-05 14:14:16 : trust-vr: PIMSM Rx'ed PIM pkt 11.11.11.34->12.12.12.13 ver=2, type=hello, len=26
## 2010-10-05 14:14:22 : trust-vr: PIMSM rx queued src=10.10.10.194 dst=12.12.12.13 ifp=tunnel.2
## 2010-10-05 14:14:22 : PIMSM: Control packet enqueued to PIM task
## 2010-10-05 14:14:22 : PIMSM: Control packet Event has been sent to PIM from IP
## 2010-10-05 14:14:22 : PIMSM: Received events 40
## 2010-10-05 14:14:22 : trust-vr: PIMSM Rx'ed PIM pkt 10.10.10.194->12.12.12.13 ver=2, type=hello, len=26
## 2010-10-05 14:14:22 : trust-vr: PIMSM Hello received on tunnel.2 from 10.10.10.194
## 2010-10-05 14:14:22 : NbrTimer restarted for 105 Sec
  1. The next step is to check the PIM route sending and receiving firewall. Once the host joins the mcast group, the (*,G) entry will be updated in the PIM routing table. See the below output:

Firewall-2-> get vr trust protocol pim mroute
trust-vr - PIM-SM routing table
-----------------------------------------------------------------------------
Register - R, Connected members - C, Pruned - P, Pending SPT Alert - G
Forward - F, Null - N , Negative Cache - E, Local Receivers - L
SPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - S
Turnaround Router - K

-----------------------------------------------------------------------------
Total PIM-SM mroutes: 8

(*, 12.12.12.60) RP 192.168.3.1 4d;21:14:59/- Flags: LF
Zone : Untrust
Upstream : tunnel.2 State : Joined
RPF Neighbor : 10.10.10.194 Expires : 00:00:14
Downstream :
trust 4d;21:14:59/- Join 0.0.0.0 FC

Make sure that the state is joined.

Now this mcast route entry will be updated to the Rp (firewall-1) by a pim join-prune message that is sent by the receiver firewall (firewall-2). If in case there are multiple firewalls in between, then each PIM neighbor will update the entry in its own routing table and will update the next neighbor. See the below output of debug pim all:

## 2010-10-05 14:14:19 : trust-vr: PIMSM Sending Periodic (*, G) Join for (192.168.3.1, 12.12.12.60)
## 2010-10-05 14:14:19 : trust-vr: PIMSM Tx'ed PIM pkt 11.11.11.34->12.12.12.13, join-prune, len=54
## 2010-10-05 14:14:19 : trust-vr: PIMSM Send Join-Prune message on tunnel.2 to 10.10.10.194

See the below debugs on firewall-1 side:

## 2010-10-11 15:24:40 : trust-vr: PIMSM Rx'ed PIM pkt 192.168.2.3->12.12.12.13 ver=2, type=join-prune, len=34
## 2010-10-11 15:24:40 : trust-vr: PIMSM Received JP on i/f tunnel.1 From 192.168.2.3
## 2010-10-11 15:24:40 : trust-vr: PIMSM Received JP Msg intended to 192.168.2.1
##2010-10-11 15:24:40 : trust-vr: PIMSM Sparse bit is set in the msg for 192.168.3.4
##2010-10-11 15:24:40 : trust-vr: PIMSM Received (S,G) Join for S=192.168.3.4 and G=12.12.12.60 from 192.168.2.3 ##
2010-10-11 15:24:40 : trust-vr: PIMSM Handle SG Join i/f=tunnel.1, Src=192.168.3.4, Grp=12.12.12.60, Holdtime 210
##2010-10-11 15:24:40 : trust-vr: PIMSM current zone Untrust, incoming zone Untrust
## 2010-10-11 15:24:40 : trust-vr: PIMSM zone Untrust Grp node for Grp 12.12.12.60Found
## 2010-10-11 15:24:40 : trust-vr: PIMSM route found for Src=192.168.3.4, Grp=12.12.12.60 zone=Untrust
## 2010-10-11 15:24:40 : trust-vr: PIMSM Route entry found for this (S,G) Join
## 2010-10-11 15:24:40 : trust-vr: PIMSM Fn params pRtEntry 0x720c010, i/f tunnel.1, OifTmrVal 210
## 2010-10-11 15:24:40 : trust-vr: PIMSM Started the ET 
  1. Now firewall-1 will be able to send multicast traffic, as it has the (*,12.12.12.60) entry updated in its own mcast routing table that is updated by the peer firewalls. Once the source initiates the sending of traffic, the (S,G) entry will be updated in the routing table of both the firewalls.

Point to remember: We cannot create an intra-zone mcast control traffic policy; ScreenOS does not support dense mode or sparse-dense mode.

 

Modification History:

2021-01-05: EOL products removed; minor, non-technical changes made

 

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search