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

[Rafael Rodriguez]

On Fri, Jul 22, 2011 at 12:22 PM, Stefan Fouant <
sfouant at shortestpathfirst.net> wrote:

> 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.


Yep, understand that NSR/GRES and GRES/GR are mutually exclusive - the box
is going to run in either mode.  Just looking for a solution that'll work
with both modes (throw logical-systems into the mix and certain things don't
work any more).


>
>
>  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.
>

Interesting, did not know that control packets were always sent on the
lowest numbered interface in a LAG.  Are you aware of any Juniper
documentation mentioning this?  I found KB10926 but this is specific to EX
and not MX. So LAG + BFD will do nothing in determining if individual links
in the LAG are actually 'up'.  Thanks.


>
> 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.


Are individual links in the LAG able to detect failures with OAM?


>
>
>  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?
>

Agree, the extra address is a waste.  Listed as an option b/c of not knowing
of the possibility of individual members in a LAG detecting indirect link
failures on the order of milliseconds.

Thanks Stefan.


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