Support Support Downloads Knowledge Base Case Manager My Juniper 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 Dec 2012Version: 2.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)
Cause:

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; in which zone 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 firewall. The IGMP packets will not come to 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
  6. If the IGMP host is joining the multicast group, then the next step is to verify the PIM configuration and neighbor ship:

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

  8. Make sure that the PIM neighbor ship is formed with the PIM neighbor:
  9. 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


  10. 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 sending a pim joine-prune message by the 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 the 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


  11. 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 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.

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


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