cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
855
Views
5
Helpful
2
Replies

PIM SPARSE DENSE MODE CONCEPT VERIFICATION

sarahr202
Level 5
Level 5

Hi everyone

 

I am using GNS3 which has shown so much varied behavior for PIM, I have no idea what else to believe, so here is my question .

 

Please consider the following set up:

CISCO -QUESTION.PNG

Above we are using SPARSE-DENSE MODE on R3/R4,  R4 is RP ( 34.34.34.4) and has a loopback4 with group 235.1.1.1

R2 is PIM DENSE MODE

 

I am trying to understand if there is NO  ( S.G) tree built up . i.e we have only ( *235,1,1,1) tree built up, if R3 receives a multicast stream how it will behave?   R3 can see it is not  the FHR because it has PIM Neighbor relationship with R2 but yet receives Stream for which no S,G tree built initiated by RP;

In order to simulate this, I generated multicast stream from R2 to 235.1.1.1, this is what I see:

 

1) R3 actually  acts like a FHR and send REGISTER Message to RP

Even though it is not FHR as R2 can see R3 as PIM Neighbor. is it normal? or I am seeing some GNS3 bug.

 

Additional info:

Current state of the PIM TREE:

 

R4 ( RP)

(*, 235.1.1.1), 00:28:09/00:02:08, RP 34.34.34.4, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback4, Forward/Sparse-Dense, 00:28:09/00:02:08

 

(*, 224.0.1.40), 00:28:09/00:02:38, RP 34.34.34.4, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:28:09/00:02:41

 

 

 

R3:

 

(*, 224.0.1.40), 00:28:50/00:02:26, RP 34.34.34.4, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 34.34.34.4
Outgoing interface list:
FastEthernet1/0, Forward/Sparse-Dense, 00:28:50/00:02:48

 

Generating Multicast Stream from R2 ( 23.23,23,2, 235.1.1.1)

 

R3 sends REGISTER MESSAGE ( 23.23.23.2, 235.1.1.1) to RP  upon receiving Multicast stream 23.23.23.2 , 235.1.1.1 from R2 dense mode router.

 

CISCO-QUESTION.PNGCISCO-QUESTION-1.PNGCAP-1.PNG

 

Above R2 is sending MULTICAST STREAM which is received by R3, which then sends REGISTER Message  as shown above.

 

 

Thanks and have a nice weekend!!

1 Accepted Solution

Accepted Solutions

Hi sarahr202,

 

"I am trying to understand if there is NO ( S.G) tree built up . i.e we have only ( *235,1,1,1) tree built up, if R3 receives a multicast stream how it will behave?

1) R3 actually acts like a FHR and send REGISTER Message to RP

Even though it is not FHR as R2 can see R3 as PIM Neighbor. is it normal? or I am seeing some GNS3 bug."

 

Answer:

When you generate Multicast traffic on the R2-R3 subnet, one of those Routers will act as FHR (the one who generates and sends the PIM Register to the RP). Notice that the election will be based on who is the PIM DR for that segment. In your case, R3 is going to be the PIM DR (use "show ip pim interface" to confirm). If you change the PIM DR Priority and makes R2 the PIM DR for the R2-R3 segment, then R2 Router should be the one responsible of sending the PIM Register.

In your lab, since R2 is configured with PIM Dense-Mode and most importantly probably has no RP configured, it will not be sending any PIM Register packet.

Lastly, when you do "ping 235.1.1.1" on IOS, by default the Router sends the Multicast traffic out all available interfaces. This is just an observation since it could mislead you. You can use "ping" command to get access to the ping command parameters to make the Multicast traffic be sent out a single interface.

 

HTH.

View solution in original post

2 Replies 2

Hi sarahr202,

 

"I am trying to understand if there is NO ( S.G) tree built up . i.e we have only ( *235,1,1,1) tree built up, if R3 receives a multicast stream how it will behave?

1) R3 actually acts like a FHR and send REGISTER Message to RP

Even though it is not FHR as R2 can see R3 as PIM Neighbor. is it normal? or I am seeing some GNS3 bug."

 

Answer:

When you generate Multicast traffic on the R2-R3 subnet, one of those Routers will act as FHR (the one who generates and sends the PIM Register to the RP). Notice that the election will be based on who is the PIM DR for that segment. In your case, R3 is going to be the PIM DR (use "show ip pim interface" to confirm). If you change the PIM DR Priority and makes R2 the PIM DR for the R2-R3 segment, then R2 Router should be the one responsible of sending the PIM Register.

In your lab, since R2 is configured with PIM Dense-Mode and most importantly probably has no RP configured, it will not be sending any PIM Register packet.

Lastly, when you do "ping 235.1.1.1" on IOS, by default the Router sends the Multicast traffic out all available interfaces. This is just an observation since it could mislead you. You can use "ping" command to get access to the ping command parameters to make the Multicast traffic be sent out a single interface.

 

HTH.

Hi Hector.

 

I must admit I was not expecting to work as  PIM DENSE router does not care about Register as there is no RP to send REGISTER message to. However, DR election is still held.  What ever you says is 100 percent correct as demonstrated below:  

In BW, all my GNS3 varied behavior can now be explained thanks to you.

 

When R2 is DR:

 

R2(config-if)#ip pim dr-priority ?
<0-4294967294> DR priority, preference given to larger value

R2(config-if)#ip pim dr-priority 4294967294

 

R2#show ip pim interface f0/0

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
23.23.23.2 FastEthernet0/0 v2/D 1 30 4294967294 23.23.23.2
R2#

 

 

Below we can see R2 is elected DR but it can not send REGISTER Message as it is in Dense mode.

On RP ( R4) we can see no REGISTER Message is received:

 

We generate traffic from R2:

R2#ping 235.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 235.1.1.1, timeout is 2 seconds:
......

 

R4 shows no Register message ( though R2 is DR but it has no info about RP as R2 is PIM DENSE Mode)

 

R4#debug ip pim
PIM debugging is on
R4#
*Nov 19 09:56:26.615: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
*Nov 19 09:56:26.815: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 235.1.1.1
R4#

 

 

When R3 is DR

R2(config)#int f0/0
R2(config-if)#ip pim dr-priority 0

 

R3 is DR now:

R2#show ip pim interface f0/0

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
23.23.23.2 FastEthernet0/0 v2/D 1 30 0 23.23.23.3

Generating stream from R2:

 

R2#ping 235.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 235.1.1.1, timeout is 2 seconds:

 

R4 :

Below we see REGISTER MESSAGE from R3.

 

*Nov 19 09:53:42.635: PIM(0): Received v2 Register on FastEthernet0/0 from 34.34.34.3
*Nov 19 09:53:42.635: for 23.23.23.2, group 235.1.1.1
*Nov 19 09:53:42.639: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (23.23.23.2, 235.1.1.1).

 

################################

 

Thanks for educating me about the DR aspect in mixed Dense Sparse mode scenario.

 

Have a nice weekend!!

 

 

 

 

 

 

 

Review Cisco Networking products for a $25 gift card