11-18-2017 07:39 PM - edited 03-05-2019 09:30 AM
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:
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.
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!!
Solved! Go to Solution.
11-19-2017 07:48 AM
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.
11-19-2017 07:48 AM
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.
11-19-2017 09:04 AM
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!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide