PIM DM Lab another question

Hello experts,

I have simulated the PIM DM lab (Multicast : vol 1 v4.1)

Everything seems to be working fine step by step :

  > Configured PIM DM on all interfaces
  > Generate multicast traffic from SW1 using rtr object
  > All routers learn about this mroute and prune as there is no receiver of this group
  > Add the command 'ip igmp join-group 224.1.1.1' on SW2
  > I can then see the Graft message being generated and all the upstream routers
     change thier respective statuses from pruned to forwarding and I can see the traffic
     flowing from R6 towards SW2
Right !! this is what the task requires but the problem is that it only works for 3 minutes once
the igmp membership is configured on SW2 and after 3 mintues, R6 generates a prune message
which is relayed to all upstream routers and all the links are then pruned.

Is this expected behaviour ?

What I am suspecting is that, although we have IGMP membership command configured on SW1,
its not actually simulating a multicast host presence untill a real host joins the group. Only then,
IGMP on SW1 will continuously send IGMP membership messages to R6. Othwise, both
R6 and SW2 will assume that there is no host to receive the traffic.

Please confirm if my understanding is correct ?
If this is correct, then I am wondering what would happen in the real exam ? Will they accept
the solution in 'pruned' situation ?

 

Thanks in advance...
Jabran Zahid

 

Comments

  • IGMP leave group timer is 3 minutes with some extra latency of about < 3 seconds (Devoloping IP Multicast Networks book page 72)

    I tried replicating the task and here is what i see

    R6#sh ip mroute 225.1.1.1
    <omitted>

    (*, 225.1.1.1), 00:03:13/stopped, RP 0.0.0.0, flags: DC
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list:
        FastEthernet0/0, Forward/Dense, 00:03:13/00:00:00
        FastEthernet0/1, Forward/Dense, 00:03:13/00:00:00

    (10.1.37.7, 225.1.1.1), 00:03:13/00:00:20, flags: T
      Incoming interface: FastEthernet0/0, RPF nbr 150.1.56.5
      Outgoing interface list:
        FastEthernet0/1, Forward/Dense, 00:03:14/00:00:00

    R6#

    *Mar  1 15:34:59.015: PIM(0): Insert (150.1.4.4,224.0.1.39) prune in nbr 150.1.56.5's queue

    *Mar  1 15:34:59.015: PIM(0): Building Join/Prune packet for nbr 150.1.56.5

    *Mar  1 15:34:59.015: PIM(0): Adding v2 (150.1.4.4/32, 224.0.1.39) Prune

    *Mar  1 15:34:59.015: PIM(0): Send v2 join/prune to 150.1.56.5 (FastEthernet0/0)

    *Mar  1 15:35:00.611: IGMP(0): Send v2 general Query on FastEthernet0/1

    *Mar  1 15:35:01.143: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 225.1.1.1

    *Mar  1 15:35:01.143: IGMP(0): Received Group record for group 225.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    *Mar  1 15:35:01.143: IGMP(0): Updating EXCLUDE group timer for 225.1.1.1

    *Mar  1 15:35:01.143: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,225.1.1.1) by 0

    R6#

     

    there are no sources for this traffic (ping from SW1 was stopped to stop the feed).

     

    R6#sh ip mroute 225.1.1.1

    IP Multicast Routing Table

    <omitted>

     

    (*, 225.1.1.1), 00:03:34/00:02:59, RP 0.0.0.0, flags: DC

      Incoming interface: Null, RPF nbr 0.0.0.0

      Outgoing interface list:

        FastEthernet0/0, Forward/Dense, 00:03:34/00:00:00

        FastEthernet0/1, Forward/Dense, 00:03:34/00:00:00

     

    Since no traffic, incoming interface is Null.

     

    As soon as multicast traffic is pushed again via ping from SW1, R5 updates its routing table:

     

    R5#sh ip mroute 225.1.1.1

    <omitted>

     

    (*, 225.1.1.1), 00:00:12/stopped, RP 0.0.0.0, flags: D

      Incoming interface: Null, RPF nbr 0.0.0.0

      Outgoing interface list:

        FastEthernet0/1, Forward/Dense, 00:00:12/00:00:00

        Serial0/0.1, Forward/Dense, 00:00:12/00:00:00

        FastEthernet0/0, Forward/Dense, 00:00:12/00:00:00

     

    (10.1.37.7, 225.1.1.1), 00:00:12/00:02:53, flags: T

      Incoming interface: FastEthernet0/1, RPF nbr 150.1.15.1

      Outgoing interface list:

        FastEthernet0/0, Forward/Dense, 00:00:14/00:00:00

        Serial0/0.1, Prune/Dense, 00:00:11/00:02:48

     

    R5#

     

    Now again after ping was stopped, and R6 removed (S,G) entry from its routing table:

     

    BEFORE

    R6#sh ip mroute 225.1.1.1

    <omitted>

     

    (*, 225.1.1.1), 00:04:08/stopped, RP 0.0.0.0, flags: DC

      Incoming interface: Null, RPF nbr 0.0.0.0

      Outgoing interface list:

        FastEthernet0/0, Forward/Dense, 00:04:08/00:00:00

        FastEthernet0/1, Forward/Dense, 00:04:08/00:00:00

     

    (10.1.37.7, 225.1.1.1), 00:04:08/00:00:54, flags: T

      Incoming interface: FastEthernet0/0, RPF nbr 150.1.56.5

      Outgoing interface list:

        FastEthernet0/1, Forward/Dense, 00:04:09/00:00:00

     

    R6#

    03:35:04: IGMP(0): Send v2 general Query on FastEthernet0/1

    03:35:09: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 225.1.1.1

    03:35:09: IGMP(0): Received Group record for group 225.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    03:35:09: IGMP(0): Updating EXCLUDE group timer for 225.1.1.1

    03:35:09: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,225.1.1.1) by 0

    R6#

    #Received query about 0 sources for group 225.1.1.1 at 03:35:04

     

    UPDATED MROUTE TABLE ON R6

    R6#

    R6#sh ip mroute 225.1.1.1

    IP Multicast Routing Table

    <omitted>

     

    (*, 225.1.1.1), 00:05:25/00:02:37, RP 0.0.0.0, flags: DC

      Incoming interface: Null, RPF nbr 0.0.0.0

      Outgoing interface list:

        FastEthernet0/0, Forward/Dense, 00:05:25/00:00:00

        FastEthernet0/1, Forward/Dense, 00:05:25/00:00:00

     

    R6#

    03:36:04: IGMP(0): Send v2 general Query on FastEthernet0/1

    R6#

    03:36:07: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 225.1.1.1

    03:36:07: IGMP(0): Received Group record for group 225.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    03:36:07: IGMP(0): Updating EXCLUDE group timer for 225.1.1.1

    03:36:07: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,225.1.1.1) by 0

    03:36:10: IGMP(0): Received v2 Query on FastEthernet0/0 from 150.1.56.5

    R6#

    IN 60 SECONDS WE RECEIVE ANOTHER V2 REPORT FROM 10.1.68.10 INDICATING THERE ARE NO SOURCES FOR GROUP 225.1.1.1

    R6#

    R6#

    03:37:04: IGMP(0): Send v2 general Query on FastEthernet0/1

    03:37:10: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 225.1.1.1

    03:37:10: IGMP(0): Received Group record for group 225.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    03:37:10: IGMP(0): Updating EXCLUDE group timer for 225.1.1.1

    03:37:10: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,225.1.1.1) by 0

    03:37:11: IGMP(0): Received v2 Query on FastEthernet0/0 from 150.1.56.5

     

    Another report in 60 seconds.

    03:38:04: IGMP(0): Send v2 general Query on FastEthernet0/1

    03:38:05: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 225.1.1.1

    03:38:05: IGMP(0): Received Group record for group 225.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    03:38:05: IGMP(0): Updating EXCLUDE group timer for 225.1.1.1

    03:38:05: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,225.1.1.1) by 0

    03:38:11: IGMP(0): Received v2 Query on FastEthernet0/0 from 150.1.56.5

     

    To my understanding, as long as you have IP IGMP JOIN command configured, switch will be sending IGMP reports every 60 seconds indicating that wants to receive traffic for group 225.1.1.1

    Sorry for the long response, hope this helps....

    Dmitriy

  • Hi Dmitriy

    Thanks for the reply...

    >To
    my understanding, as long as you have IP IGMP JOIN command configured,
    switch will be sending IGMP reports every 60 seconds indicating that
    wants to >receive traffic for group 225.1.1.1

    This is exactly what I would have expected as well.
    In my case, I had rtr configured on SW1 which means we have continuous stream of multicast traffic and an IP IGMP Join command
    on sw2 but it seems that, as soon as you turn on this command, it joins the group but only stays active for exactly 3 minutes and then prune messages (sourced from R6 all the way upto R3.

  • I think i see what you talking about, i build lab based on another task but was debugging 2 switches and got different results .... see bellow:

    Task configured as Auto-RP with Default RP placement.

    Generating mcast traffic on R4 using ip sla feature and debuggin on R3 and R6 ...

     

    R3

    Jan 12 21:13:54.579: IP(0): s=150.1.24.4 (Serial1/2) d=224.1.1.1 (FastEthernet0/0) id=0, ttl=252, prot=17, len=44(44), mforward

    Jan 12 21:14:17.231: IGMP(0): Switching to INCLUDE mode for 224.1.1.1 on FastEthernet0/0

    Jan 12 21:14:17.231: IGMP(0): MRT delete FastEthernet0/0 for (*,224.1.1.1) by 0

    Jan 12 21:14:17.231: IGMP(0): Deleting FastEthernet0/0 from (150.1.24.4,224.1.1.1) olist (no PIM joins active)

     

    Even though join command still on interface and nothing changed, SW1 is not sending report to R3 for group 224.1.1.1

     

    R6

     

    00:57:06: IGMP(0): Received v2 Report on FastEthernet0/1 from 10.1.68.10 for 224.1.1.1

    00:57:06: IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 10.1.68.10 for 0 sources

    00:57:06: IGMP(0): Updating EXCLUDE group timer for 224.1.1.1

    00:57:06: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,224.1.1.1) by 0

     

    Ignore the timestamp …. I was trying to setup on both routers to be the same and didn’t notice that R6 didn’t take clock set command. Aside from that I see that SW4 (in my case) is sending v2 Report to R6 to refresh timers for group 224.1.1.1

    The strange thing is that it works on SW4 to R6 and doesnt on SW1 to R3 ... found one forum asking same question but didnt find answer yet ....

  • hi,

    it's a caveat or something, it took me quite a while to discover the issue actually and learned something of it. ;)

    Anyway, what i did to keep it actively joining is by adding ip pim configuration under the same interface as the ip igmp-join group command. Then it wont stop sending igmp joins and works as you would expect.

Sign In or Register to comment.