Re: EIGRP best path selection with multiple successors

From: Joe Astorino <joeastorino1982_at_gmail.com>
Date: Mon, 23 Dec 2013 10:54:20 -0500

So one of the people with access to EIGRP code for the last 15 years
contacted me on twitter - The answer is that it is not predictable. The
first one to be marked as successor is sent by default.

On Thu, Dec 12, 2013 at 2:43 PM, Tony Singh <mothafungla_at_gmail.com> wrote:

>
>
> A complete wild guess but does the H age timer matter here i.e peer that's
> been up the longest then prefer the route from him, a la OSPF LSA type1
>
> I guess bouncing the peers would disprove this theory..
>
> --
> BR
>
> Tony
>
> Sent from my iPad
>
> > On 11 Dec 2013, at 23:07, Joe Astorino <joeastorino1982_at_gmail.com>
> wrote:
> >
> > Just to expand a bit - Let's say you have a simplified version of the
> DMVPN
> > network in this documentation. Say you have a single hub and 3 spokes,
> S1,
> > S2 and S3 and your network is a DMVPN phase 2 design running EIGRP. We
> > know that in Phase 2 design on the hub, we would both disable
> split-horizon
> > and we would use "no next-hop-self eigrp" on the hub. This allows the
> DMVPN
> > hub to learn spoke routes on the tunnel interface, then turn around and
> > advertise them back out the same multipoint tunnel to other spokes with
> the
> > original next-hop intact. Thus, we can allow dynamic spoke to spoke
> > tunnels.
> >
> > Now, say S1 and S2 are both connected to the same LAN segment and both
> > advertise this subnet with the same composite metric to the hub. The hub
> > will have 2 successors to this network, but as the article states, by
> > default will only advertise one of them to S3. The question is which one
> > and why? The article only mentions that EIGRP will select one but does
> not
> > go into detail as to how this happens. At S3, is the next-hop of the LAN
> > subnet going to be S1 or S2 and why?
> >
> >
> > On Wed, Dec 11, 2013 at 5:24 PM, Joe Astorino <joeastorino1982_at_gmail.com
> >wrote:
> >
> >> So, the new EIGRP "add-path" feature is intriguing to me as documented
> >> here
> >>
> http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-add-path.html
> >>
> >> As we know, EIGRP can indeed have multiple equal cost paths. In that
> >> case, we will see more than one successor in the EIGRP topology table.
> >> However, only one is actually sent to EIGRP neighbors by default, as the
> >> article points out.
> >>
> >> In certain DMVPN situations, this does not allow spoke to spoke load
> >> balancing, hence the point of the add-path feature as explained.
> >>
> >> All that is well and good, but I couldn't help asking myself as I was
> >> reading "wait a minute, by default without all this, which successor
> would
> >> it send?"
> >>
> >> I have spent some time googling around and such and have labbed some
> >> things up, but have not got a definitive answer. Anybody know?
> >>
> >> In my lab test I had frame-relay hub and spoke network setup. The
> spokes
> >> are both connected to the same ethernet segment and I had them
> redistribute
> >> that ethernet segment into EIGRP with the same metric, but using
> different
> >> route tags. My initial experiments seemed to indicate that the
> successor
> >> sourced from the neighbor with the lowest IP address were sent upstream
> to
> >> other EIGRP neighbors.
> >>
> >> --
> >> 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
> >
> > _______________________________________________________________________
> > 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
Blogs and organic groups at http://www.ccie.net
Received on Mon Dec 23 2013 - 10:54:20 ART

This archive was generated by hypermail 2.2.0 : Wed Jan 01 2014 - 20:26:19 ART