On Fri, Jul 22, 2011 at 12:22 PM, Stefan Fouant < [email protected]> 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 > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
