Hey Stefan, no, in normal conditions the weight/metric of the bypass is poisoned/set high o traffic will always take the primary.
At time of repair the loss of primary makes for "any port in a storm" and now traffic flows on the bypass. Possible the metric is updated/lowered, but given there is no primary not sure it would matter. Regards -----Original Message----- From: Stefan Fouant [mailto:[email protected]] Sent: Thursday, July 07, 2011 9:48 AM To: Harry Reynolds Cc: David Ball; Phil Bedard; Juniper-Nsp Subject: Re: [j-nsp] Bypass LSP functionality question On 7/7/2011 12:26 PM, Harry Reynolds wrote: > Do you have a per-packet lb policy applied to the forwarding table at the > point of local repair? > > AFAIK, any fast reroute/bypass needs this for optimal switchover as it allows > the detour/bypass to be preinstalled in the pfe waiting for its day in the > sun. > > As I recollect, the ingress will continue to use the bypass until it can > signal a new path (MBB). You may want to set the ingress lsp to adaptive to > better chances of the new path being established so the lsp can get of the > bypass. Harry is right. This is covered in the 'Junos MPLS and VPNs' course. Only the Active LSP's next-hop is installed in the PFE by default. During the time that it takes for the RE to install the detour or bypass next-hop in the forwarding table, it is not unusual to see a small amount of dropped traffic. Harry, I've always wondered about this however, since the recommended solution is to apply a forwarding-table load-balance policy, does this mean that traffic will *always* use both the Primary path as well as any Detours or Bypasses under normal working conditions? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
