ip pim spt-threshold infinity Scenario.

[sarahr202]

Hi everybody.

Please  conside  the following example:

(5.5.5.5)

Src---- ---R1--s0-----s0-R2--s0/1----s0/1--R3-s0/1----S0/1-R4-f0--Client

client is in group 224.7.7.7,  R2(2.2.2.2) is RP, R2,R3, and R4 are configured with " ip pim spt-threshold infinity"

1)When i issue ping 244.7.7.7 on src, as expected R3 and R4 did not create a ( 5.5.5.5,224.7.7.7) entry but R2 did create a ( 5.5.5.5, 224.7.7.7). Does this command not effect RP?

R2# show ip mr

(5.5.5.15, 224.7.7.7), 00:01:47/00:01:40, flags: T

  Incoming interface: Serial0/0, RPF nbr 200.200.200.1

  Outgoing interface list:

    Serial0/1, Forward/Sparse, 00:01:47/00:03:12

2) Please look at multicast routing table at R2 ( RP) below:

(*, 224.7.7.7), 03:06:59/00:03:29, RP 2.2.2.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 03:06:59/00:03:29

(*, 224.0.1.40), 03:39:24/00:03:11, RP 2.2.2.2, flags: SJCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, Forward/Sparse, 01:06:53/00:03:11
    Serial0/1, Forward/Sparse, 03:27:18/00:02:57

As we can see  no router i.e R3 and R4 show they are interested  in multicast traffic source from 5.5.5.5.

Next i issue the i generate some multicast traffic on SRC  ( 5.5.5.5) for group 224.7.7.7 and issue show ip multicast route on R2.

R2# show ip m rou

( output omitted)

(*, 224.7.7.7), 03:10:47/stopped, RP 2.2.2.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 03:10:47/00:02:38

(5.5.5.15, 224.7.7.7), 00:00:09/00:02:59, flags: T
  Incoming interface: Serial0/0, RPF nbr 200.200.200.1
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 00:00:09/00:02:50

.

2)Why did R2 think it should forward  multicast traffic ( 5.5.5.5, 224.7.7.7) out of s0/0 after all  R3 and R4 never informed Rp that are interested in multicast traffic sourced from 5.5.5.5 and going to 224.7.7.7 ?

3) I removed " ip pim spt threshold infinity" command on R4 while R3 still has this comand configured.

When I generate multicast traffic on source 5.5.5.5 for 224.7.7.7 , R4 creates a ( S,G) entry as shown below:

R4# show ip mr

(5.5.5.15, 224.7.7.7), 00:00:09/00:02:58, flags: JT

  Incoming interface: Serial0/1, RPF nbr 150.150.150.3

  Outgoing interface list:

    FastEthernet0/0, Forward/Sparse, 00:00:09/00:02:50

However, when I check R3, it too created a ( SG) entry eventhough R3 is configured with " ip pim stp-threshold infinity " command.

R3# show ip mr

(5.5.5.15, 224.7.7.7), 00:01:28/00:02:29, flags: T

  Incoming interface: Serial0/0, RPF nbr 199.199.199.2

  Outgoing interface list:

    Serial0/1, Forward/Sparse, 00:01:28/00:03:00

Thanks and have a great weekend.

[Peter Paluch · Accepted solution]

Hi Sarah,

1)When i issue ping 244.7.7.7 on src, as  expected R3 and R4 did not create a ( 5.5.5.5,224.7.7.7) entry but R2  did create a ( 5.5.5.5, 224.7.7.7). Does this command not effect RP?

It does not, just as you saw. In PIM-SM, there always must be a source-based tree between the source and the RP. Otherwise there would be no possibility of multicast data flowing natively (i.e. without being encapsulated into PIM Register messages) from the source to the RP. That is the reason why Bidir-PM was created later - because even with a shared tree from RP downstream to receivers, there are still source-based trees between the senders and the RP. In situations where most or all receivers are also senders, PIM-SM results in creating many source based trees, limiting its scalability.

The ip pim spt-threshold command has effect on last-hop routers towards end receivers only.

2)Why did R2 think it should forward  multicast traffic ( 5.5.5.5,  224.7.7.7) out of s0/0 after all  R3 and R4 never informed Rp that are  interested in multicast traffic sourced from 5.5.5.5 and going to  224.7.7.7 ?

Becase you are not using source-specific multicast here and the client behind R4 merely expressed its membership in the group 224.7.7.7. It did not indicate what source it is interested in. As a result, only a (*, G) tree could be created, rooted at the RP.

3) I removed " ip pim spt threshold infinity" command on R4 while R3 still has this comand configured.
When I generate multicast traffic on source 5.5.5.5 for 224.7.7.7 , R4 creates a ( S,G) entry as shown below: [ ... cut ... ]
However, when I check R3, it too created a ( SG) entry eventhough R3 is  configured with " ip pim stp-threshold infinity " command.

Yes, this is logical. The switchover from the shared tree to the source-based tree is always performed by the last-hop router, in this case, R4. The ip pim spt-threshold infinity prevents R4 from changing over the shared tree to the source-based tree. If, however, R4 is not prevented from performing this switchover then it will send a PIM Join message towards the source of the multicast stream with the WC-bit (wildcard) and RPT-bit (RP tree) cleared, expressing it wants to join a source-based tree. All routers through which this Join flows will also join the source-based tree. This is the result R3 also joined the source-based tree.

One again, the ip pim spt-threshold infinity has effect only on last-hop routers.

Best regards,

Peter

[sarahr202]

Hi Peter. As usual great response.

2)Why did R2 think it should forward multicast traffic ( 5.5.5.5, 224.7.7.7) out of s0/0 after all R3 and R4 never informed Rp that are interested in multicast traffic sourced from 5.5.5.5 and going to 224.7.7.7 ?

Becase you are not using source-specific multicast here and the client behind R4 merely expressed its membership in the group 224.7.7.7. It did not indicate what source it is interested in. As a result, only a (*, G) tree could be created, rooted at the RP.

But R2 ( RP) is not creating only ( *,224.7.7.7) , it is also creating ( 5.5.5.5,224.7.7.7)  as shown below.  R2 should have only ( * ,224.7.7.7) becuase R2 did indeed receive joint group for 224.7..7.7 from R3 which R3 receives from R4.

R2# show ip mr

5.5.5.15, 224.7.7.7), 00:00:09/00:02:59, flags: T

Incoming interface: Serial0/0, RPF nbr 200.200.200.1

Outgoing interface list:

Serial0/1, Forward/Sparse, 00:00:09/00:02:50 5.5.5.15, 224.7.7.7), 00:00:09/00:02:59, flags: T
Incoming interface: Serial0/0, RPF nbr 200.200.200.1
Outgoing interface list:
Serial0/1, Forward/Sparse, 00:00:09/00:02:50

Thanks and have a great evening.

BW ip PIM dense was pretty easy but God IP PIM sparse is way too hard .  The biggest problem  is to find great book.

Unfortunately, most of the books I found were full of errors.

[Peter Paluch · Accepted solution]

Hi Sarah,

But R2 ( RP) is not creating only ( *,224.7.7.7) , it is also creating (  5.5.5.5,224.7.7.7)  as shown below.  R2 should have only ( *  ,224.7.7.7) becuase R2 did indeed receive joint group for 224.7..7.7  from R3 which R3 receives from R4.

Here, the RP is knitting together two trees - the shared tree and the source tree. RP was not initiating the creation of the shared tree, it merely joined it as a result of receiving a Join for (*, 224.7.7.7) from R3. However, as soon as the first packet from the source 5.5.5.15 arrived to RP (thanks to PIM Register messages), RP itself initiated the creation of a source tree from itself towards the source. Otherwise, the PIM Register tunnel would persist indefinitely between the R1 (first-hop router of the source) and the R2 (the RP). So the RP here has the (5.5.5.15, 224.7.7.7) state because it created it iself, not as a result of receiving a source-specific PIM Join but rather as a result of its own activity to initiate the creation the the source tree and joining it as its first router.

BW ip PIM dense was pretty easy but God IP PIM sparse is way too hard

No, it isn't Don't worry. I guess it's just badly presented. Think of PIM-SM in these steps:

1. Don't wait for multicast traffic to arrive to create the tree afterwards. Instead, create a shared tree rooted at the RP as soon as it is clear there is a recipient subscribed via IGMP somewhere in the network
2. If there's a source, have its multicast traffic tunneled as unicast across the network to the RP, where it can be decapsulated and flow down the multicast tree natively (if there is any)
3. To alleviate the burden created by tunneling the multicast traffic as unicast, have the RP initiate the creation of a source tree towards the sender of the multicast traffic
4. When the multicast traffic from the sender arrives at the RP natively, have the first-hop router stop the tunneling process because it's not needed anymore.
5. Now the multicast flow goes from source to the RP where the source tree is stitched to the shared tree and flows down to recipients.
6. If necessary, have each last-hop router individually join the source tree towards the source, and prune off the shared tree afterwards.

Isn't that illogical, is it?

Best regards,

Peter

[sarahr202]

Great explanation..

src--R1---s1-R2-S0---R3---R4--client1.

My problem is source tree . For example  R2 receives  the joint message from R3  about 224.7.7.7 so it creates an entry as

( * ,2244.7.7.)

incoming nul

outgoing int : S0.

Our leaf router R4 is configured with Ip spt-threshhold infinity command. . Now when i generate multicast traffic at src.

R2 creates ( s,G) entry as:

( 5.5.5.5, 224.7.7.7)

incoming s1

outgoing S0

I understand  R2 has to create a source tree from itself to source and therefore it creates ( 5,5,5,5,224.7.7.7) but why does R2 choose " S0" as outgoing interface.  So far all R2 knows that there are some clients in 224.7.7.7 group off its S0 interface.   R2 was not told if anyone of these clients want to receive multicast traffic from 5.5.5.5. 

OR R2 just look at ( *,224.7.7.7) outgoing int s0  and conclude there must be some clients  wishing to receive ( 5.5.5.5,224.7.7.7) traffic and therefore chose" S0" as outgoing int for ( 5.5.5.5,224.7.7.7)

=========================================================================

Below R3 is configured with " ip pim spt-threshold infinity"  All routers are running IP PIM sparse nmode.

R1 is DR.

server---R1-s0------R2 ( RP)
             S1
              |
              |
              |
             R3
             |
             Client ( 224.7.7.7)

Multicast routing table before multicast traffic generated at Server.

R1#show ip mr

(*, 224.7.7.7), 00:03:23/00:03:03, RP 2.2.2.2, flags: S
  Incoming interface: Serial0/0, RPF nbr 200.200.200.2
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 00:03:23/00:03:03

R2#show ip mr

(*, 224.7.7.7), 00:04:15/00:03:11, RP 2.2.2.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, Forward/Sparse, 00:04:15/00:03:11

Now I generate multicast traffic at server for 224.7.7.7 and check routing table again

R1#show ip mr

(*, 224.7.7.7), 00:05:39/stopped, RP 2.2.2.2, flags: SF
  Incoming interface: Serial0/0, RPF nbr 200.200.200.2
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 00:05:39/00:02:46

(5.5.5.5, 224.7.7.7), 00:00:11/00:03:21, flags: FT
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1, Forward/Sparse, 00:00:11/00:02:48

R2#show ip mr

(*, 224.7.7.7), 00:06:24/00:03:00, RP 2.2.2.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, Forward/Sparse, 00:06:24/00:03:00

(5.5.5.5, 224.7.7.7), 00:00:56/00:02:05, flags: PT
  Incoming interface: Serial0/0, RPF nbr 200.200.200.1
  Outgoing interface list: Null

If you look at the last output, R2 shows ( 5.5.5.5,224.7.7.7) outgoing int : null  

What is the logic here? 

, R2 chose " null int" for ( 5.5.5.5,224.7.7.7) because multicast packet with src ip 5.5.5.5 dst ip 224.7.7.7 was received on s0/0 and the ( *,224.7.7.7.7) was pointing towards the same int s0/0

Am i correct?

I really appreciate your help. I have been stuck with this  this topic for over 5 days.

[zenzenzen]

I have same situation. How you resolve it?