Re: EIGRP DUAL Variance

Hmmmm....also this Cisco white paper seems to agree with the book and with
how I thought it worked. They have a simplified version of what you are
testing with easier to read numbers.

In the example, the path through D is not chosen because it's metric is not
< variance * FD. However, it also goes on to make this point:

"Also, the reported distance of neighbor D is 25, which is greater than the
feasible distance (FD) of 20 through C. This means that, even if variance
is set to 3, the E-D-A path is not selected for load balancing because
Router D is not a feasible successor."

This seems to certainly be making the case that to be considered for
unequal cost load balancing via variance, a path must first pass the
feasibility condition. Clearly, your lab results show otherwise though.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml#var

On Mon, Oct 7, 2013 at 3:34 AM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> This certainly seems strange to me. Granted, it is like 4AM or something
> here, but if you had asked me I would have thought EIGRP would not consider
> the F1/0 path for anything, given it doesn't meet the feasibility
> condition. I'd certainly be interested to hear if anybody else has an
> answer.
>
>
>
>
> On Sun, Oct 6, 2013 at 2:53 PM, Tony Singh <mothafungla_at_gmail.com> wrote:
>
>> CCNP ROUTE 642-902 Official Certification Guide
>>
>> "Routes that are neither successor nor feasible successor can never be
>> added to the IP routing table, regardless of the variance setting"
>>
>> I did a little lab
>>
>> --- r2 ---
>> r1 ----r3 ---- r5 loopback 5.5.5.5
>> ----r4 ----
>>
>>
>> no variance
>>
>> all-links
>> P 5.5.5.5/32, 1 successors, FD is 158720, serno 55
>> via 10.0.0.1 (158720/156160), FastEthernet0/0
>> via 20.0.0.1 (161536/158976), FastEthernet1/1
>> via 30.0.0.1 (1790976/156160), FastEthernet1/0
>>
>> topology
>> P 5.5.5.5/32, 1 successors, FD is 158720
>> via 10.0.0.1 (158720/156160), FastEthernet0/0
>> via 30.0.0.1 (1790976/156160), FastEthernet1/0
>>
>> global-rib
>> D 5.5.5.5 [90/158720] via 10.0.0.1, 00:00:44, FastEthernet0/0
>>
>>
>> the reason we choose f1/0 path as FS over f1/1 is due to the AD<FD of
>> successor holding true even if it has a worse FD - expected behaviour and
>> end result no load-balancing as no equal cost paths (max 4 equal cost
>> paths
>> by default)
>>
>>
>>
>>
>> if I apply a variance of x2
>>
>>
>>
>> all-links
>> P 5.5.5.5/32, 2 successors, FD is 158720, serno 52
>> via 10.0.0.1 (158720/156160), FastEthernet0/0
>> via 20.0.0.1 (161536/158976), FastEthernet1/1
>> via 30.0.0.1 (1790976/156160), FastEthernet1/0
>>
>> topology
>> P 5.5.5.5/32, 2 successors, FD is 158720
>> via 10.0.0.1 (158720/156160), FastEthernet0/0
>> via 30.0.0.1 (1790976/156160), FastEthernet1/0
>>
>> global-rib
>> D 5.5.5.5 [90/158720] via 10.0.0.1, 00:00:53, FastEthernet0/0
>> [90/161536] via 20.0.0.1, 00:00:53, FastEthernet1/1
>>
>>
>> ok so we're now permitting the f1/1 path being installed as a viable
>> load-balancing destination, this shows me two things, first that dual will
>> permit a non-successor or non-feasible successor into global rib as viable
>> load-balancing paths and second dual compares the end-to-end FD for making
>> a decision on which path it would prefer to load-balance looking at the
>> all-links topology as f1/1 has a lower FD than f1/0
>>
>>
>>
>> this does make the above argument invalid - im wondering if EIGRP has
>> since
>> been enhanced for this DUAL behaviour? if so then I guess the whole point
>> for the statement in the first place was to avoid a loop i.e if you're not
>> a successor or feasible successor then you a loop, what has changed?
>>
>>
>> --
>> BR
>>
>> Tony
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>

-- 
Regards,
Joe Astorino
CCIE #24347
http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net