[j-nsp] ECMP vs LAG and OAM vs BFD

[Stefan Fouant]

On 7/22/2011 7:18 AM, Rafael Rodriguez wrote:
> Hello list,
>
> I'm looking at options on how to do all of the following:
> 1) Increase bandwidth capacity by adding multiple links with 'flow' based
> hashing
> 2) Sub-second detection mechanism of a indirect link failure that is
> distributed to hardware (i.e. PFE handles)
> 3) Above two must work with NSR and GRES + GR (NSR and GRES + GR and
> mutually exclusive, will only use one of the two)

If you run NSR/GRES you *CANNOT* run GR.  There are no platforms or 
combinations which will allow you to run these simultaneously.  GRES/NSR 
is a natural replacement for GRES and so it is not needed.

> So far here are the possible combinations I've come across (not sure if
> these are NSR and GRES + GR friendly):
> 1) LAG + BFD (this doesn't sound like a good idea b/c you have
> no grantee that hashing on each side will use the same link for BFD packets)

If you were to run BFD, since these are control packets they will always 
take the lowest numbered interface in the LAG; in other words the normal 
hashing doesn't come into play for any control packets running across a LAG.

Regardless, BFD runs between Layer 3 peers using the PPMD (Periodic 
Packet Management Daemon), so it doesn't matter which link is used for 
BFD packets as it won't be used to verify reachability of individual 
member links.

> 2) LAG + OAM (presume OAM will be for each physical interface and not entire
> the LAG)

This is a better approach if you want to verify your end to end 
connectivity across Layer 2... look into Link Fault Management for 
segment isolation/verification and Connectivity Fault Management for 
end-to-end isolation/verification.

> 3) ECMP + BFD
> 4) ECMP + OAM

Why run ECMP? If all you want to do is connect a few hosts via multiple 
paths LAGs should do the trick.  Why would you want to waste address 
space unnecessarily, not to mention have to deal with forwarding-table 
load-balance policies?

Stefan Fouant
JNCIE-ER #70, JNCIE-M #513, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant