[j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960

[Richard A Steenbergen]

On Fri, Sep 25, 2009 at 04:30:30PM -0400, Stefan Fouant wrote:
> I thought this was the whole idea behind the introduction of the
> indirect next-hop.  Basically abstracting a level of recursion so that
> when underlying next-hop paths changed, all they needed to do was to
> do a KRT change for the indirect-next-hop pointer to the new path. 
> Any routes that referenced the indirect-next-hop then automatically
> utilized the new path via this mechanism, without having to do a KRT
> update for thousands of routes...
> 
> Am I missing something or did this behavior change at some point?

I believe indirect next-hop only helps when the path to a given next-hop
changes, not when the route or the next-hop itself changes. For example
lets say you have router A with an eBGP full transit feed to next-hop
1.1.1.1, and a router B somewhere else in the network with 300k routes
pointing to that transit feed on router A. If the path between A and B
changes, indirect next-hops lets router B update a single structure for
the route to the next-hop 1.1.1.1, rather than touch all 300k routes
that have a next-hop of 1.1.1.1. But if transit provider 1.1.1.1 goes
down and transit provider 2.2.2.2 becomes the new best path, you still
have to completely reselect and reinstall all of the routes on both
devices.

At any rate indirect next-hop was no help for us on this issue, though
we never saw it internally even before indirect next-hop was added. We
only saw it on the edge, when one eBGP route would go change and a new
eBGP path would be selected. This might have just been hidden by MPLS in
our core though, I'm not sure.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)