EIGRP multicast flow control and conditional receive

[kfarrington]

Bit confused,

I have a large number of EIGRP peers on on LAN,

The Mcast exceptions, does this increment, everytime an ACK to an update (or any other RTP packet) is not received, and the update gets retrans in unicast mode?

(If I were to do a show ip eigrp neighbors detail and just count the number of retrans for each neighbor, would this add up?)

Also, Conditional receive packets??? This is to "prepare" the neighbots to expect an EIGRP packet in unicast or multicast mode?

This CR exception, must be more servere than just a normal retransmission of a multicast EIGRP packet, and I have a few of these! Should I be concerned??

Many thx indeed, and Kind regards,

Ken

router>sh ip eigrp int det

IP-EIGRP interfaces for process 1

Xmit Queue Mean Pacing Time Multicast Pending

Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes

Fa0/0 23 0/0 70 0/10 244 0

Next xmit serial <none>

Un/reliable mcasts: 0/58261 Un/reliable ucasts: 1914780/600745

Mcast exceptions: 27435 CR packets: 4470 ACKs suppressed: 288907

Retransmissions sent: 78028 Out-of-sequence rcvd: 4104

[kfarrington]

So, from what I can perceive,

4 routers on a LAN

------------------

Say there are 10 EIGRP update packets to be sent by rtr1.

1. rtr1 sends update packet to2 24.0.0.10

2. EIGRP update is not ACKd by rtr4 but is by rtr2 and rtr3

3. rtr1 sends a sort of hello packet with rtr4 listed in it to 224.0.0.10

4. rtr4 stops listening to mcast updates.

5. rtr2 and rtr3 enters CR mode by the fact they received this "special" hello packet with them not listed in the TLV.

6. rtr1 will still send more mcast updates with CR bit set in the flasgs and rtr2 and rtr3 will receive them.

7. while this is going on, rtr1 will unicast update to the neighbor that did not ack the orig mcast update (rtr4).

8. after rtr4 has caught up, WHAT HAPPENS NEXT?

How does CR mode get turned off, is it by virtue of another "specical" hello packet?

Also, AN IMPORTANT POINT.

The above ONLY happens when there are multiple updates multicast packets to be sent ? correct?

If it was a case of just one update packet, and rtr4 did not ACK the update, there is no need for the routers to go into CR mode, as there are no other multicast updates quesed on the interface to be sent? Please can this point be clarigied.

It's kinda confusing, but I am hoping that someone can clarify this behaviour.

Kind regards,

Ken