NMC 16.14 Multicast

Multicast receivers

A couple of weeks ago, I blogged about the behavior of a router when acting as a multicast receiver.  I am thinking of the sort of situation where the router has an ip igmp join-group on the interface facing the multicast source, but does not need to forward to anywhere.  the questions are: do you need to enable multicast-routing, and do you need to put PIM on the interface.

At the time, I was doing NMC DOiT Lab 14, which was a sparse-mode scenario.  At the time, I came to the conclusion:

If a router is to respond to a multicast ping, and it has ip igmp join-group on the interface facing the source, then ip multicast-routing must be enabled.  PIM is not needed unless the ip igmp join-group is on an interface not facing the source.  There is an alternative to enabling multicast routing: no ip route-cache cef interface facing the source.

Now lab 16 presents an opportunity for the same sort of experiment in dense-mode.  We have two devices that are acting purely as multicast receivers: FRS and CAT2.  What do we need to configure on those to get a response to the ping from R4 and CAT1?

This time, to get a response out of CAT1, it needs all three parts: multicast routing, the pim dense-mode, and the join-group:

ip multicast-routing
!
interface Vlan10
 ip address 160.60.26.6 255.255.255.0
 ip pim dense-mode
 ip igmp join-group 229.9.9.9

I am puzzled about these differences.  However, it could be simple that an SVI on a Catalyst running 12.1 behaves differently from a FastEthernet on a router running 12.4.

Dense-mode with hub-and-spoke

There is one other thing that worries me about this scenario.  We have a hub-and-spoke topology in dense-mode, with R1 acting as hub, and R2 and R3 acting as spokes.  Normally, this shouts out to me “TUNNEL”.  But in this case, we get away with it because both spokes need the multicast group.  I bet if I removed the join from R3 loopbaack, and PIM from the R3-R5 link, then R3 would prune towards R1, and R2 would stop receiving.  In fact, yes, that is exactly what happens:

R4#ping 229.9.9.9
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 229.9.9.9, timeout is 2 seconds:
Reply to request 0 from 160.60.14.1, 481 ms
Reply to request 0 from 160.60.10.7, 489 ms
R4#

A question for the proctor: Do you require this scenario to work if R3 no longer needs the multicast stream?

 

[OT] Very OT! Traffic regulations.

Someone had to come up with the idea … a one-way cul-de-sac!  To all appearances, we seem to have one here in Luxembourg.  For those who know Luxembourg, (which I know is not many of my readers), it is the new layout at the top of Rue Adolphe Fischer.

It’s a quiet residential one-way street, but in a busy area of town,  and it ends in a sidewalk (“pavement” for English speakers)  across the road, blocking the end.  So which is greater: the fine for reversing on a one-way street, or the fine for driving on the sidewalk?   Which would you do?

Who forgot to inject the default route into the stub area?

 

NMC DOiT 16.5 EIGRP

I did have a momentary panic in the EIGRP section over “16.5.2 Send a summary for the entire Class B range from R2 to CAT2 only.”

For a start, I misinterpreted it as meaning 160.60.0.0/16, the major network of the pod.  So I did an ip summary-address eigrp 1 160.60.0.0 255.255.0.0 on R2-F0/0.  Of course, the summary turned up not only in CAT2, but in R1 and everywhere else as well.  I could have filtered it toward R1, but that seemed like too much work.  What I wanted to do was to get rid of the discard route on R2.  Could I remember how to do it?  No!  So it took some research to remind myself of ip summary-address eigrp 1 160.60.0.0 255.255.0.0 255.  Setting the AD to 255 stops the discard route getting into the routing table, and so stops it getting redistributed into OSPF.

All well.  But futile.  On reconsideration, what they wanted was a range that covered all the Class-B addresses.  In other words, ip summary-address eigrp 1 128.0.0.0 192.0.0.0 255.  Later, I checked it against the SHOWiT, and found they did not put in the AD=255.  So, doesn’t that make the /2 summary route turn up in R1?  Instead of putting AD=255, they take the precaution  of filtering it during the redistribution from EIGRP to OSPF.  The difference my AD=255 makes is whether the discard route gets installed in R2.

 

NMC 6.9 MST

Following a question on the DISCUSiT forum, I loaded my old configs, and there seems to be something amiss with this lab. I could not get 172.16.64.30 to talk to 172.16.64.10. The problem seems to be the MST.

Consider the two lines between CAT3 and CAT4. The Fa0/15 is carrying VLAN 102 and the Po1 line is carrying VLAN 101. But 6.9.1. says that CAT4 must be root. I presumed that must apply to MST0 (which carries VLAN 102) as well as MST 1 (which carries VLAN 101). Thus, on CAT3, my spanning tree looks like this:

CAT3#show spanning-tree

MST00
  Spanning tree enabled protocol mstp
  Root ID    Priority    24576
             Address     0009.b703.7280
             Cost        0
             Port        65 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     0009.43d5.2000
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/15           Altn BLK 200000    128.15   P2p
Po1              Root FWD 100000    128.65   P2p

MST01
  Spanning tree enabled protocol mstp
  Root ID    Priority    24577
             Address     0009.b703.7280
             Cost        100000
             Port        65 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0009.43d5.2000
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1              Root FWD 100000    128.65   P2p

Hey – look! For MST0, F0/15 is blocking. That is obviously because CAT4 is the root, and CAT3 has a best path to the root through Po1. But VLAN 102 is disallowed on link Po1. Clearly something is wrong.

Look at the SHOWiT. We find that CAT 4 is the root for MST1 only. For MST0, CAT3 is the root. So the question 6.9.1. must be questionable.

In fact, comparing the configurations of CAT3, I have spanning-tree mst 0-1 priority 24576, whereas the SHOWiT has spanning-tree mst 1 priority 24576. So I throw up my hands in horror and say “It’s not fair!” I have spent so much time working out what the problem was, that if it had been a real exam, I would have failed it.

So I made CAT3 the root of MsT 0, but I still couldn’t get CAT3 talking to CAT1.  Now Fa0/15 on CAT4 is blocking.  This all serves to illustrate some of the problems you can have if your pruning topology does not reflect you MST topology.

Maybe this time I am in the wrong.  Unfortunately I do not have a 3650 for my CAT4, so I was unable to do the dot1q tunnel between F0/15 and F0/22.  Maybe if I had that tunnel, CAT4 F0/15 would be forwarding.

I give up.  I have more cost-effective ways to spend my study time.

 

This, that, and the other

Added the resolution to my posting a couple of weeks ago about a VTP pruning problem.  I came to the conclusion it was a bug in CatOS.  CatOS will quite happily prune the native VLAN of a trunk if it thinks it is not needed.  However, in doing so, it can screw up the VTP pruning (or more specifically, grafting) mechanisms for other VLANs.  I need to investigate this further to make a more coherent explanation, but I’m sure that it the basis of the problem.  Here is me discussing it on NetPro.

 

 

NMC Lab 15

It is already week 16 and I have not started Lab 15 yet.  But I had a great weekend back in blighty at a retirement party for one of my old school friends who I had not seen for 15 years or so.   So this evening I went for lab 15.  Fortunately I am getting more confident as time goes on.  I am beginning to count the things that delay me rather than the things that don’t.  I got as far as the end of section 10 (of 13) in about 3 hours.  Here are the things that I must revise:

1. I had to look up how to configure a static neighbor in IPv6 OSPF.  (On the interface)
2. When I redistributed connected Lo103 into OSPF on R3 (15.6.3), I was prepared for the other connecteds to stop being injected, so I compensated with a route-map.  This is the sort of issue that I am pleased I can spot in advance now.  They give the game away a bit by putting this requirement in 15.6.3 with the redistribution.  It would have been meaner to put it in as 15.3.5 with the OSPF.
3. I stumbled a bit on the BGP, taking 45 minutes when it should have taken 30 – 40.  My access list for the route filter was not fluent.  At first, I forgot to specify the update-source on the neighbors, so I could have configured much more efficiently if I had thought about it in advnace.
4. I cheated by looking at the answer key for the as_path regular expression, even though it was a very simple one.  I must read that up in Wendell Odom again.
5. When I did the NAT – 15.8 – it took me by surprise when the 11.1.1.0/24 route turned up in R1.  (I keep “ip debug routing” on all the time.)  I should not have been surprised, given my solution to 15.6.3 (see #2 above).
6. I wimped out of 15.9.  I recognise it as EEM, but I did not have the courage to tackle it.  Domani.  Magari.

I have to be in work very early tomorrow, so I shall call it a day now.  I shall try and get round to writing up the solution to my VTP problem tomorrow, once I have got Lab 15 out the way.

Am I really getting faster, or am I just getting used to the NMC format?  Maybe I need to try labs from a variety of different vendors.

 

VTP Pruning : Is this a bug?

I recently introduced VTP pruning on a LAN, and now I have some connectivity problems on certain VLANs.  The more I look at the problems, the more I wonder whether there is some strange behavior in VTP pruning.  The questions I need to answer are:

1. Is pruning based on whether the switch has any downstream clients; that is, whether there are any active access ports or unpruned downstream trunks on the VLAN?  Or is it based on whether there are any downstream CAM entries for the VLAN?
2. Is it possible for a switch to prune a VLAN off a trunk that is the root port for that VLAN?

Here is my apparently anomalous situation.  I have four VLANs, 21-24, that serve as point-to-point links between remote sites to carry server heartbeats.  On each of these VLANs, there are only two hosts: one on each site.  Here is the spanning-tree for VLAN 21:

CC80#show spanning-tree vlan 21
 VLAN0021   Spanning tree enabled protocol rstp
   Root ID    Priority    24576
              Address     0007.4f62.a014
              Cost        15
              Port        72 (Port-channel1)
              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

   Bridge ID  Priority    32789  (priority 32768 sys-id-ext 21)
              Address     001b.2ae8.b280
              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
              Aging Time 300
 Interface        Role Sts Cost      Prio.Nbr Type
 ---------------- ---- --- --------- -------- --------------------------------
 Gi0/16           Desg FWD 4         128.16   Edge P2p
 Po1              Root FWD 3         128.72   P2p
 Po2              Desg FWD 3         128.80   P2p

Notice one or two things about this.  Firstly, Po1 is the root port.  Secondly, that G0/16 is an “up” access port on this VLAN.  Thirdly, I should mention that Po2 is a trunk to another access layer switch at the same level.  But Po2 spends its time in blocking state on the other switch except in an emergency.  That is why this switch prunes most VLANs off Po2, as we will see.

Now let us look at the trunks:

CC80#show int trunk
 Port        Mode         Encapsulation  Status        Native vlan
 Gi0/3       on           802.1q         trunking      2
 Po1         on           802.1q         trunking      12
 Po2         on           802.1q         trunking      12

 Port        Vlans allowed on trunk
 Gi0/3       1,169
 Po1         1-2,5,12,21-26,169
 Po2         1-2,5,12,21-26,169

 Port        Vlans allowed and active in management domain
 Gi0/3       1,169
 Po1         1-2,5,12,21-26,169
 Po2         1-2,5,12,21-26,169

 Port        Vlansin spanning tree forwarding state and not pruned
 Gi0/3       1,169
 Po1         1-2,5,12,22,24-26,169
 Po2         1

As expected, most of the VLANs are pruned off Po2 as te other end of Po2 is on STPblocking state.  Ignore G0/3; this is a server trunk.  The interesting thing is that the switch has pruned VLAN 21 from the root port trunk, Po1.  Why?  This has effectively cut this switch off from VLAN 21.

VLAN21 is pruned from both Po1 and Po2, and yet it has an access port on it.  Now, that access port, G0/16, is apparently not receiving any MAC traffic from its connected host.  There is nothing in the CAM table except the upstream switch.  But it is still isolated, so it cannot see any traffic from the remote part of the VLAN, so it does not respond:

CC80#show mac-address-table dyn vlan 21
           Mac Address Table
 -------------------------------------------
 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
   21    0016.c73d.a22b    DYNAMIC     Po1

 Total Mac Addresses for this criterion: 1

One last possible clue.  We have four VLANs, each with two host connections.  Two of them work, two of them don’t.  The difference is that they take different paths.  Two of them are rooted on a 4506 running IOS 12.2(25)EWA2, and they work; they are not pruned anywhere between the two sites.  The two that do not work are rooted on a 4003 running CatOS 8.4(5)GLX.

Update 19/04/2008:

I think I have sorted it out, and I think it is a bug in the root switch for VLAN 21. Unlike our other VLANs, VLAN 21 is rooted in a CatOS switch. Due to various circumstances in our network, it tripped over a bug.

The bug is related to one I found a couple of years ago. I found that in a CatOS switch, if you manually disallow the native VLAN (in my case VLAN 12) from a trunk, then it stops the trunk passing BPDUs for VLAN1 as well. At the time, that resulted in a 5-minute meltdown of my network.

Here are the notes I have made for this new bug. Sorry about the generalisations … I do not know the VTP protocol very well yet.

Normally, VTP signalling is carried on the native VLAN of each trunk. By default, the native VLAN is VLAN 1, but you are allowed other values. We use VLAN 12 as native, a VLAN that is unused anywhere on the network. Now, an IOS switch will never prune VLAN 1 from a trunk. Nor will it prune the native VLAN. However, CatOS has a bug: if the (non-1) native VLAN is unused, it will prune it from the trunk regardless of the fact that it is the native. Once the native VLAN is pruned, of course, the VTP signal cannot be propagated to other switches.

It happens that we have one CatOS switch in our core loop. That switch is the root for VLANs 21 and 23. (And fortunately only for VLANs 21 and 23.) Because that root switch had pruned the native VLAN from its trunks, it was no longer able to send VTP unprune signals for VLANs 21 and 23 to its neighbors. Its neighbors therefore pruned VLANs 21 and 23 from the trunks to the root. The result was that there was no connectivity in VLANs 21 and 23, and every switch pruned all ports on those VLANs.

I resolved the problem by rolling back the VTP pruning.

Telnet to a specific VTY line

Here is something I keep forgetting, so I am putting it on my blog to remind me.

How do you telnet to a specific VTY line?  The answer is rotary group n in the vty line config, then telnet to port 300n.

Here it is on NetPro.

NMC 14.14 SLA Jitter measurements

Notes:

1. You cannot clear counters on a subinterface, e.g. R1-S0/0.13.  The only way to clear the ip precedence accounting counters on S0/0.13 is to do clear counters S0/0.  Note that clear ip accounting has no effect on precedence accounting.
2. The AK talks about 1 extra packet sent per sample: “think of this as a control-plane packet”.  Monitoring with Ethereal, I see the probe 100 packets and their responses: R5 UDP/56984 to R1 UDP/16387.  These are preceded by a single packet R5 UDP/56984 to R1 UDP/1967 which has 52 bytes of data.  This is presumably the control packet they are talking about, and primes R1 for the burst of test packets.  R1 responds to it with a single packet that has 8 bytes of data.

At the moment, I run Ethereal on an isolated laptop.  I must get it running on the main PC so that I can put Ethereal dumps into my blogs.  Too much text is indigestible.  I would need a second Ethernet card in the PC so I could monitor the lab traffic seperately and have my home network running at the same time.

The AK does not include any samples of the most interesting part of the SLA monitoring, which is the results.  Here are some results:

R5#show ip sla monitor statistics
Round trip time (RTT)   Index 3
        Latest RTT: 19 ms
Latest operation start time: 13:22:10.707 UTC Sun Apr 6 2008
Latest operation return code: OK
RTT Values
        Number Of RTT: 83
        RTT Min/Avg/Max: 13/22/379 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 43
        Source to Destination Latency one way Min/Avg/Max: 0/16/364 ms
        Destination to Source Latency one way Min/Avg/Max: 14/14/18 ms
Jitter time milliseconds
        Number of Jitter Samples: 81
        Source to Destination Jitter Min/Avg/Max: 1/10/365 ms
        Destination to Source Jitter Min/Avg/Max: 1/1/4 ms
Packet Loss Values
        Loss Source to Destination: 17          Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 14
Number of failures: 0
Operation time to live: Forever

Round trip time (RTT)   Index 4
        Latest RTT: 22 ms
Latest operation start time: 13:22:14.188 UTC Sun Apr 6 2008
Latest operation return code: OK
RTT Values
        Number Of RTT: 83
        RTT Min/Avg/Max: 13/27/390 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 45
        Source to Destination Latency one way Min/Avg/Max: 0/15/358 ms
        Destination to Source Latency one way Min/Avg/Max: 14/23/390 ms
Jitter time milliseconds
        Number of Jitter Samples: 81
        Source to Destination Jitter Min/Avg/Max: 1/11/358 ms
        Destination to Source Jitter Min/Avg/Max: 1/31/376 ms
Packet Loss Values
        Loss Source to Destination: 17          Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 14
Number of failures: 0
Operation time to live: Forever

 
I cannot find a way to clear down these statistcs.  I will find it eventually, but at least I cannot be tested on that in the exam!

It is interesting that I seem to have lost 17 packets on their way from source to destination.  This is confirmed by the precedence counters at R1.  I wonder why.  Think back to 14.13, the QoS, where we limited the bandwidth available for precedence 3 and 4 packets. 

R3#show policy-map in
 Serial0/0
  Service-policy output: R3-FR-out
    Class-map: 14.13.1 (match-all)
      4848 packets, 311232 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name from-35.5
      Match: ip precedence 3  4
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
            32000/32000     3000   12000     12000     375       1500
        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         4848      311232    0         0         no
      Service-policy : q-shaper
        Class-map: prec4 (match-all)
          2424 packets, 155616 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 4
          Queueing
            Output Queue: Conversation 25
            Bandwidth 16 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
        Class-map: prec3 (match-all)
          2424 packets, 155616 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 3
          Queueing
            Output Queue: Conversation 26
            Bandwidth 8 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
        Class-map: class-default (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any
    Class-map: class-default (match-any)
      5636 packets, 289891 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R3#

Strange!  That does not explain the lost packets.  It is pretty consistent too – losing 17 packets in each sample for each flow.  Pinged 1000 packets from R5 to 172.16.101.1, and did not lose a single one.  The packet probe rate during each burst is 1 packet every 20 msec.  Try slowing this down to 100 msec.  That reduces the loss on that flow to 5 packets per sample.  I wonder where they are getting lost.  Still looking.

(Subversive thought: This stuff is unlikely to be needed in the exam at this level.  Should I be concentrating rather on the exam?  If I get my digits, will it mean that I will stop labbing this sort of stuff?  That would indeed be a pity.)

 

NMC 14.12 Multicast

This posting is not very much about NMC 14.12, but a lot about some experiments that grew from it.

Using a router as a multicast receiver:

The standard way of using a router to simulate a multicast receiver is to use the command ip igmp join-group group-addr.  So, you have a router on a VLAN, and you want it to simulate a multicast receiver, but not to forward multicast packets.  Is it enough to put the ip igmp join-group command on the Ethernet interface.  Well … yes and no.  There is a gotcha that I discovered during NMC 14.12.  Here are my notes:

I had a problem getting a response from R6 (a receiver only) using the configuration in the SHOWiT.  I got it going, but only by adding ip multicast-routing on R6.

I am using Ethereal and SPAN or RSPAN to monitor the protocols.  I start by trying experiment with the connection between R3 and CAT2, and seeing how much config I need in R3 for CAT2 to get a response.

1. Did no ip multicast-routing on R3 but left ip pim sparse-mode in place on R3-F0/0.   I can still see PIM Hellos (30 seconds) and PIM Bootstraps (60 seconds) from R3.  The bootstraps still carry 172.16.101.1 as the bootstrap router.  Also, and IGMP membership report with 0.0.0.0 every 60 seconds.  However, the show ip mroute on R3 is empty.
2. Removed ip pim sparse-mode from R3-F0/0.  This killed the PIM stone dead, as you might expect.
3. Added ip igmp join-goup 239.10.10.10 on R3-F0/0.  This generates an IGMP Membership report.  BUT, it does not repeat.  Strange!  Removing it produces an “IGMP Leave Group”.
4. With no ip multicast-routing on R3 and no ip pim sparse-mode on R3-F0/0, but ip igmp join-group 239.10.10.10 on R3-F0/0, I can see the ping 239.10.10.10 from CAT2, but R3 does not respond.  So how is R6 supposed to work in the scenario?

So, now I put back the multicast routing stuff in R3 and concentrate on R6.

1. Starting with no multicast config in R6, it is obvious I will see no response form it.  I do not see it in the show ip igmp snooping group on CAT1 (if I use it … the AK has static MAC forwarding for the multicast).  If I ping from CAT2, I see no ping on R6.
2. In the AK, R6 has no ip multicast-routing, has no ip pim sparse-mode on F0/0, and has ip igmp join-group 239.10.10.10 on F0/0.  This does not work for me.  I can see the IGMP Membership report from R6, and I can see CAT1 adding it to the show ip igmp snoop group table. I can see the ping from CAT2.  But I do not get any response form R6.
3. If I add ip multicast-routing on R6, then I get a response.  OTOH, there is no need for any PIM on R6-F0/0.

Conclusion: If a router is to respond to a multicast ping, it must ip igmp join-group on the interface facing the source, AND ip multicast-routing must be enabled.  PIM is not needed unless the ip igmp join-group is on an interface not facing the source.

Follow on:  These is another way to solve this problem, and it is the one in the SHOWiT, and which I had overlooked: no ip route-cache cef on R6-F0/0.  The ip multicast-routing is then not necessary.  Why this makes a difference, I have not the faintest idea.  Just quirky behavior … a magic bullet.  They might at least have mentioned it in the AK!

The first few multicast pings

I know that in a sparse mode scenario you should discard the results of the first two or three pings.  But I want to be able to explain them.  Here are the results from this lab:

CAT2#
CAT2#! =================> First ping
CAT2#
CAT2#ping 239.10.10.10

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:

Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 228 ms
Reply to request 0 from 172.16.124.2, 220 ms
Reply to request 0 from 172.16.124.4, 212 ms
CAT2#
CAT2#
CAT2#! =================> Second ping
CAT2#
CAT2#ping 239.10.10.10

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:

Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 80 ms
Reply to request 0 from 172.16.124.4, 76 ms
Reply to request 0 from 172.16.26.6, 68 ms
Reply to request 0 from 172.16.124.2, 60 ms
Reply to request 0 from 172.16.124.4, 52 ms
Reply to request 0 from 172.16.124.2, 44 ms
Reply to request 0 from 172.16.13.1, 32 ms
CAT2#
CAT2#
CAT2#! =================> Third and subsequent pings
CAT2#
CAT2#ping 239.10.10.10

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:
Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 64 ms
Reply to request 0 from 172.16.124.2, 56 ms
Reply to request 0 from 172.16.124.4, 48 ms
Reply to request 0 from 172.16.13.1, 32 ms
CAT2#
CAT2#

On the first ping, I get no response from R1, althogh it is evidently forwarding the ping to R2 and R4.  I wonder why.

On the second ping, I get duplicate responses from R2, R4, and R6.  This is evidently because of the loop.  R6 has two routes to the source, so it believes the ping from both R2 and R4.  It has not sorted out yet which one it prefers.  So it also forwards each ping to the other.

From the third ping onwards, everything is sorted, and you get one response from each router.