Re: PIM Sparse FHR packet duplication in Register Message and Natively

sarahr202 · ‎11-17-2017

Hi everyone,

I have decided to tackle multicast that I have been avoiding for many years.

Here is my first thread :

Scenario#1 PIM SPARSE MODE

Please consider the following design for PIM SPARSE MODE:

Source is not sending any STREAM at 235.1.1.1 at the moment, we can see (*,235.1.1.1) has been built at RP:

R3#show ip mroute

(*, 235.1.1.1), 00:02:20/00:03:07, RP 23.23.23.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:02:20/00:03:07

This is what i noticed:

1)FHR takes multicast packet received from SOURCE , (10.10.10.10 235.1.1.1and make two copies of the packet. It sends one in REGISTER MESSAGE, and the other natively i.e without any tunnel encapsulation towards RP.

Below Capture is taken between FHR and R2 to demonstrate Multicast Stream are transmitted in REGISTER Message and NATIVELY

1)Focusing only on this natively transmitted packet , why does FHR make copy and transmit the packet natively?

I mean, FHR can continue to transmit in REGISTER message only until it receives REGISTER STOP and (S,G) Join from down stream PIM router R2 .

I also noticed:

2) When PIM neighbor relationship establishes, PIM enabed router does not know if its neighbor is running SPARSE or DENSE mode, as I I do not see any such INFO communicated in PIM Hello.

Thoughts?

Have a nice weekend!!

Hector Gustavo Serrano Gutierrez · ‎11-19-2017

Hi sarahr202,

"1)FHR takes multicast packet received from SOURCE , (10.10.10.10 235.1.1.1and make two copies of the packet. It sends one in REGISTER MESSAGE, and the other natively i.e without any tunnel encapsulation towards RP."

"1)Focusing only on this natively transmitted packet , why does FHR make copy and transmit the packet natively?

I mean, FHR can continue to transmit in REGISTER message only until it receives REGISTER STOP and (S,G) Join from down stream PIM router R2 ."

Answer.

Your description about the PIM Multicast process is not completely accurate. Let me help you with the right steps.

Starting from the (*,G) already in the Mroute table of the RP Router (Receiver has already requested to get the Multicast traffic), the order of operations is as follows:

1) The "Source" starts generating traffic destined to a Multicast IP address (TTL value in the IP header should be different than 1 of course).

2) Upon reception of this Multicast traffic at the the PIM DR Router located in the same network segment (aka the FHR), this Router originates a PIM Register (Unicast packet) to the RP. This and sequent (if necessary) PIM Register packets include the original IP Multicast traffic as payload. At this exact point no Multicast traffic is natively forwarded by the FHR.

3) When the RP receives this PIM Register packet, since it already has the (*,G) in the Mroute table, two things happen next:

The RP decapsulates the original Multicast traffic from the PIM Register and forwards this traffic natively down the Multicast tree (towards the Receiver).
The RP almost simultaneously sends a PIM Join towards the FHR. Since the RP now knows the IP address of the "Source", the PIM Join will be sent in the correct direction.

4) Again, remember that in the previous step the RP sent a PIM Join towards the FHR. Upon reception of this PIM Join at the FHR is when the FHR starts sending the Multicast traffic natively and not before.

IMPORTANT: If we manage to keep this exact state in the network, we will see the FHR keeps sending both, the PIM Register packets including the Multicast traffic as paylod and the native Multicast packets towards the RP.

5) However, the state described in the previous step does not last long (unless you manage to configure your lab as I did) since the RP will start receiving the Multicast traffic natively and will finally send a PIM Register STOP to the FHR. The result of this state is that upon reception of the PIM Register STOP, the FHR will only send the Multicast traffic natively and not in the PIM Register any more.

Since this all happens so fast in real time, it can be confusing to deduce the real order of operations.

Nice weekend!

sarahr202 · ‎11-19-2017

Thanks Hector for your response and help.

I am using GNS3 so not sure what I am observing is normal or GNS3 bug.

I

) Upon reception of this Multicast traffic at the the PIM DR Router located in the same network segment (aka the FHR), this Router originates a PIM Register (Unicast packet) to the RP. This and sequent (if necessary) PIM Register packets include the original IP Multicast traffic as payload. At this exact point no Multicast traffic is natively forwarded by the FHR.

Not sure If this GNS3 bug or this is expected behavior.

I see FHR makes two copies, for each packet. as shown demonstrated below:

Below R2,R3,R4 are configured PIM SAPRSE -DENSE mode.

( *,235.1.1.1) has been built with RP as the root and Source ( 199.199.199.1) has not issued any STREAM yet

Current State of the Network:

R3#show ip mroute

(*, 235.1.1.1), 00:04:32/00:02:53, RP 23.23.23.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:04:32/00:02:53

We issue one multicast packet from source 199.199.199.10 to 235.1.1.1

We issue single ping but get two respnse for same ICMP echo (Note " 0" next to request below)

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

Reply to request 0 from 4.4.4.4, 112 ms
Reply to request 0 from 4.4.4.4, 120 ms

On the capture between R2---R3, we see R2 ( FHR) makes two copies of the same packets, place one in REGISTER MESSAGE and the other is transmitted natively.

The reason we can say it is same packet is because Sequence number of ping is zero and we see two responses for the same sequence , same thing verified when we look at the capture below:

Note Register payload has the same original ping which is also sent natively right after REGISTER,

Note there is no Capture filter, we only see NATIVE packet right after REGISTER , we do not see any

( S,G) Join for ( 199.199.199.1, 235.1.1.1) and REGISTER STOP YET.

Note sequence number in ICMP ECHO. Below , I have expanded capture showing same ICMP ECHO sequence number, showing it is the same PING packet being transmitted natively:

Not sure if this is GNS3 bug or expected behavior:

4) Again, remember that in the previous step the RP sent a PIM Join towards the FHR. Upon reception of this PIM Join at the FHR is when the FHR starts sending the Multicast traffic natively and not before.

I see the only thing that stops FHR not to use REGISTER MESSAGE is PIM REGISTER STOP not PIM JOIIN ( S,G) alone.

Some thing that can be demonstrated by blocking REGISITER STOP MESSAGE by ACL so it never reach FHR.

(S,G) treee will be built between Rp and FHR and eventually between LHR anf FHR , but FHR contiue to send REGISTER and NATIVE PACKET on S,G tree.

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

Same behavior i.e payload is copied in REGISTER and Transmitted natively by FHR,was observed when R2 is PIM DENSE with RP configured:

REGISTER PAYLOAD:

NATIVE:

Much appreciated!!!

Thanks for all the help, have a nice evening!!

Hector Gustavo Serrano Gutierrez · ‎11-20-2017

Hi sarahr202,

Not sure if you are configuring the interfaces on the FHR with "PIM Dense-Mode", "PIM Dense-Mode with RP", "PIM Sparse-Dense-Mode" or "PIM Sparse-Dense-Mode with RP", etc.

I would suggest you to test only with "PIM Sparse-Mode with RP".

Regards.

sarahr202 · ‎11-20-2017

Hi Hector.

yes, I checked for both when R2 is IP PIM DENSE-SPARSE and IP PIM DENSE mode

Moreover, I also see same behavior on Juniper SRX as well.

I will paste the config when I get off work.

sarahr202 · ‎11-20-2017

Below are the config, now I see the behavior you mentioned: FHR sends packet in REGISTER only, I do not see NATIVELY Transmitted packet right after REGISTER. But earlier in screenshot posted before, we see FHR sends REGISTER and right after that NATIVELY TRANSMITTED packet. This is the behavior which led me to post this question so I can find what is expected behavior or what is not.

Thanks for your time ,

R1 ( FHR):

Current configuration : 1556 bytes
hostname R1

ip multicast-routing

router ospf 1
network 0.0.0.0 255.255.255.255 area 0

interface FastEthernet0/0
ip address 199.199.199.1 255.255.255.0
ip pim sparse-dense-mode
duplex full

interface FastEthernet1/0
ip address 200.200.200.1 255.255.255.0
ip pim sparse-dense-mode
speed auto
duplex auto

ip pim rp-address 22.22.22.2

R2 ( RP):

Building configuration...
hostname R2

interface FastEthernet0/0
ip address 22.22.22.2 255.255.255.0
ip pim sparse-dense-mode
duplex full
!
interface FastEthernet1/0
ip address 200.200.200.2 255.255.255.0
ip pim sparse-dense-mode
speed auto
duplex auto

router ospf 1
network 0.0.0.0 255.255.255.255 area 0

ip pim rp-address 22.22.22.2

R3 ( LHR):

Building configuration...

hostname R3

ip multicast-routing

interface Loopback3
ip address 3.3.3.3 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 235.1.1.1

interface FastEthernet0/0
ip address 22.22.22.3 255.255.255.0
ip pim sparse-dense-mode
duplex full

router ospf 1
network 0.0.0.0 255.255.255.255 area 0

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

mtable:

R1#show ip mroute
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:28:41/00:02:26, RP 22.22.22.2, flags: SJPL
Incoming interface: FastEthernet1/0, RPF nbr 200.200.200.2
Outgoing interface list: Null

R2#show ip mroute
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 235.1.1.1), 00:29:07/00:02:57, RP 22.22.22.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:29:07/00:02:57

(*, 224.0.1.40), 00:29:29/00:02:54, RP 22.22.22.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:29:06/00:02:56
FastEthernet1/0, Forward/Sparse-Dense, 00:29:29/00:02:30

R3#show ip mroute
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 235.1.1.1), 00:40:47/00:02:44, RP 22.22.22.2, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 22.22.22.2
Outgoing interface list:
Loopback3, Forward/Sparse-Dense, 00:40:47/00:02:44

(*, 224.0.1.40), 00:40:47/00:02:03, RP 22.22.22.2, flags: SJPCL
Incoming interface: FastEthernet0/0, RPF nbr 22.22.22.2
Outgoing interface list: Null

##### GENERATING STREAM ( 199.199.199.10 , 235.1.1.1.)########################

RAndrew · ‎11-21-2017

Hi, sarahr202!

RP was on R3 in topic starting post. And you posted configs for modified network with RP on R2.

However, with posted configs, RP on R2 and testing client on R3 all should be fine. Do you still see duplicating starting packet?

sarahr202 · ‎11-21-2017

yes, it is GNS3 as I doubted , in my first case when R3 is RP I see FHR creating two sets of ecah multicast packet received from Source, one is sent in REGISTER and one is sent natively something that we we see in my capture and that is happening when no PIM JOIN from RP was received yet.. However, when I did the lab again when Rp is R2, I just see REGISTER message no more NATIVELY transmitted packet from FHR ( when ( S,G) tee is not built between Rp and FHR)

RAndrew · ‎11-21-2017

Hi, sarahr202!

RP was on R3 in topic starting post. And you posted configs for modified network with RP on R2.

However, with posted configs, RP on R2 and testing client on R3 all should be fine. Do you still see duplicating starting packet?

RAndrew · ‎11-20-2017

Hi sarahr202,

I think you are confused yourself and tries to confuse readers. :)

All that you posted might be normal behavior or might be a bug. It might be wrong configured devices or wrong network engineering or bug (I doubt in it) or all works just as supposed to work.

Yes, REGISTER message must encapsulate multicast packet as a payload and even DR router might send copy of same packet directly to the interface (for local subscribers, for example). Also there are pim-sm protocol design problem when receivers could get duplicating packets for a short period of time mostly when source starts casting.

I think `show ip mroute` on R2 will answer why R2 sends 2 copy of a packet. R3 mroute table shows that there are subscribers on interface 23.23.23.3.

sarahr202 · ‎11-21-2017

All that you posted might be normal behavior or might be a bug. It might be wrong configured devices or wrong network engineering or bug (I doubt in it) or all works just as supposed to work.

Yes, REGISTER message must encapsulate multicast packet as a payload and even DR router might send copy of same packet directly to the interface (for local subscribers, for example). Also there are pim-sm protocol design problem when receivers could get duplicating packets for a short period of time mostly when source starts casting.

First of all I am not confused i was very clear what I was look into, your big " might" bolded above is what I observed and wanted to eliminate as it is normal or not.

I ran into GNS3 bug issue but i learned a lot :)

Thanks for your response, have a nice day!!