PIM dense mode fundamental

Hello all,

I was building some basic labs to unserstand PIM DM, and ran into this problem.

This is the topology:

imageR4 has a receiver for group 224.4.4.4 on its loopback interface.

When i send a ping to 224.4.4.4 from R1, ideally one s,g entry is supposed to be created in every downstream router's mroute table, ie, (192.168.12.1,224.4.4.4) in R2, and (192.168.13.1,224.4.4.4) in R3.

 

However, while pinging, the actual contents of sh ip mroute in R2 is :

R2#show ip mroute
IP Multicast Routing Table

(*, 224.4.4.4), 00:00:03/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00
    FastEthernet0/0, Forward/Dense, 00:00:03/00:00:00

(192.168.12.1, 224.4.4.4), 00:00:03/00:02:57, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00

(192.168.13.1, 224.4.4.4), 00:00:03/00:02:56, flags:
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00

(*, 224.0.1.40), 00:01:56/00:02:57, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:01:57/00:00:00
    FastEthernet0/0, Forward/Dense, 00:01:57/00:00:00

 

My question is, why is there an entry for 192.168.13.1,224.4.4.4) in R2?

at first i thought its because R1 sends the packet out its f1/0 int, then to R3, then R4, and finally  to R2. However, the ip routing table of R2 suggests R2 would drop such a packet due to RPF failure:

 

R2:show ip route

C    192.168.12.0/24 is directly connected, FastEthernet0/0
O    192.168.13.0/24 [110/2] via 192.168.12.1, 02:58:07, FastEthernet0/0
C    192.168.24.0/24 is directly connected, FastEthernet1/0
O    192.168.34.0/24 [110/2] via 192.168.24.4, 02:58:07, FastEthernet1/0

 

It doesn't make sense!!

Am i missing something here?

 

 

Comments

  • I don't think there's any issue here. Multicast traffic, regardless of the source address, in dense mode operation will initially be pushed out all multicast(pim) enabled interfaces away from the source; then eventually several/all outgoing interfaces will be pruned if there are no downstream or connected receivers.

     

    In this case, multicast traffic sourced from 192.168.13.1 are pushed out via both f0/0 and f1/0 at R1. R2 receives the multicast traffic from R1 for the (192.168.13.1,244.4.4.4) pair via f0/0 and the RPF check, from R2 point of view, succeeds. It will then forward the multicast traffic "away" from the source (R1), and forwards the multicast traffic via f1/0 towards R4.

  • R2 receives the multicast packets from both interfaces of R1, one packet is forwarded to R4 and the other is not forwarded back to R1.

     

    *Apr 15 18:30:02.055: IP: s=12.12.12.1 (FastEthernet0/0) d=224.4.4.4 (FastEthernet0/1) len 114, mforward

    *Apr 15 18:30:02.099: IP: s=13.13.13.1 (FastEthernet0/1) d=224.4.4.4 len 114, not RPF interface

     

    The same happens in R3:

     

    *Apr 15 18:33:42.979: IP: s=13.13.13.1 (FastEthernet0/1) d=224.4.4.4 (FastEthernet0/0) len 114, mforward

    *Apr 15 18:33:43.047: IP: s=12.12.12.1 (FastEthernet0/0) d=224.4.4.4 len 114, not RPF interface

     

    Regards,

     

    Antonio Soares, CCIE #18473 (R&S/SP)
    [email protected]

    http://www.ccie18473.net

     

     

    From: [email protected] [mailto:[email protected]] On Behalf Of amitesh
    Sent: sexta-feira, 15 de Abril de 2011 11:45
    To: [email protected]
    Subject: [CCIE SP] PIM dense mode fundamental

     

    Hello all,

    I was building some basic labs to unserstand PIM DM, and ran into this problem.

    This is the topology:

    imageR4 has a receiver for group 224.4.4.4 on its loopback interface.

    When i send a ping to 224.4.4.4 from R1, ideally one s,g entry is supposed to be created in every downstream router's mroute table, ie, (192.168.12.1,224.4.4.4) in R2, and (192.168.13.1,224.4.4.4) in R3.

     

    However, while pinging, the actual contents of sh ip mroute in R2 is :

    R2#show ip mroute
    IP Multicast Routing Table

    (*, 224.4.4.4), 00:00:03/stopped, RP 0.0.0.0, flags: D
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list:
        FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00
        FastEthernet0/0, Forward/Dense, 00:00:03/00:00:00

    (192.168.12.1, 224.4.4.4), 00:00:03/00:02:57, flags: T
      Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
      Outgoing interface list:
        FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00

    (192.168.13.1, 224.4.4.4), 00:00:03/00:02:56, flags:
      Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1
      Outgoing interface list:
        FastEthernet1/0, Forward/Dense, 00:00:03/00:00:00

    (*, 224.0.1.40), 00:01:56/00:02:57, RP 0.0.0.0, flags: DCL
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list:
        FastEthernet1/0, Forward/Dense, 00:01:57/00:00:00
        FastEthernet0/0, Forward/Dense, 00:01:57/00:00:00

     

    My question is, why is there an entry for 192.168.13.1,224.4.4.4) in R2?

    at first i thought its because R1 sends the packet out its f1/0 int, then to R3, then R4, and finally  to R2. However, the ip routing table of R2 suggests R2 would drop such a packet due to RPF failure:

     

    R2:show ip route

    C    192.168.12.0/24 is directly connected, FastEthernet0/0
    O    192.168.13.0/24 [110/2] via 192.168.12.1, 02:58:07, FastEthernet0/0
    C    192.168.24.0/24 is directly connected, FastEthernet1/0
    O    192.168.34.0/24 [110/2] via 192.168.24.4, 02:58:07, FastEthernet1/0

     

    It doesn't make sense!!

    Am i missing something here?

     

     




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • Hi Antonio,

    What you're saying is right. However, my confusion is this:

    I had read that, the very first rule that router processes (wrt mcast) is, an RPF check on the pkt. Now that RPF check fails in this case, the packet should be immediately dropped, and no further action taken.

    However, here, going by the data it seems like the entry is first created in the mroute table, and subsequently RPF check is done.

    Is this conclusion right ?

  • First the (S,G) entry is created then based on that entry RPF check is performed.

     

     

    Regards,

     

    Antonio Soares, CCIE #18473 (R&S/SP)
    [email protected]

    http://www.ccie18473.net

     

     

    From: [email protected] [mailto:[email protected]] On Behalf Of amitesh
    Sent: sábado, 16 de Abril de 2011 10:24
    To: [email protected]
    Subject: Re: [CCIE SP] RE: PIM dense mode fundamental

     

    Hi Antonio,

    What you're saying is right. However, my confusion is this:

    I had read that, the very first rule that router processes (wrt mcast) is, an RPF check on the pkt. Now that RPF check fails in this case, the packet should be immediately dropped, and no further action taken.

    However, here, going by the data it seems like the entry is first created in the mroute table, and subsequently RPF check is done.

    Is this conclusion right ?




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

Sign In or Register to comment.