EIGRP Multicast flow timer

[yaroneis]

Does anyone knows what is EIGRP default multicast flow timer?

Can it be changed via CLI?

Thanks!

[ruwhite · Accepted solution]

Easy question--hard answer. :-)

The Multicast flow timer is used to determine when the next mulicast packet will be transmitted on an interface. The RTO actually determines when a packet will be retransmitted to a given peer--these are two separate timers, although they are interrelated.

Start with the SRTT, which is caclulated based on a weighted average of the actual response times of a set of peers on an interface. The average is weighted so the most recent response times have more of an impact on the SRTT than older response times, with response from about 5 or 6 packets ago having no impact at all.

The Multicast Flow Timer is the greater of:

o 50ms

o the SRTT multiplied by 4, with a "fudge factor" for NBMA interfaces, based on the number of neighbors reachable through the interface and the pacing timer

The RTO is similar. It is:

200ms < max((SRTT * 6),(Pacing Timer * 6)) < 5s

There's no way to set any of these manually/permanently on the router.

:-)

Russ.W

[yaroneis]

It’s a great answer :-) thanks!

Few clarifications, though:

I did not understand the "fudge factor", and 'pacing timer' parameter. Can you explain or give an example?

Also, in the RTO definition:

What is the meaning of 'Pacing Timer * 6' in the RTO?

Thanks again Russ.

Yaron

[ruwhite · Accepted solution]

The "pacing timer" is the rate at which eigrp will put packets on the wire; this is the timer that keeps EIGRP from using more than the "bandwidth percentage" of the bandwidth (by default 50%) on less than T1 speed point-to-multipoint links.

Normally the pacing timer is calculated for each packet--compute how long it will take to send the specific packet on the queue on the specific link (given the link bandwidth), and then multiply that by two.

The "fudge factor" I mentioned above is based on multiplying the pacing timer for a 1500 byte packet by the number of adjacent neighbors. The more neighbors there are, the slower we will transmit, and also the slower we will expect those neighbors to reply before we time them out.

This math is pretty dynamic, and EIGRP rounds and orders things in a specific way, so replicating the router's calculations is pretty much impossible. It's actually the same with the EIGRP metric--you have to calculate it in the same order, and make the same rounding decisions, as the router does, to get the same answer as the router. Min bandwidth/10^7, round down, multiply by the sum of the delays, then multiply by 256. It's similar to the four interface timers, where the SRTT is calc'd in real time, the pacing is based on the configured bandwidth, and the RTO and Multicast Flow timers are based on the SRTT and pacing timers.

:-)

Russ.W

P.S. And now you know why I always tell people not to mess with the bandwidth to engineer traffic--it messes with your EIGRP packet pacing and reliable transmission, which can have a ton of unexpected cascading effects in the network on slower speed point-to-multipoints.... :-)