Hey Richard, I had raised 101569 for the bypass bouncing after bandwidth related resignal, and was told by DE this was expected behavior. At the time the explanation made sense. If a bypass m is protecting lsp n, and lsp n is torn down, for any reason and in any manner (make before break or not), then the bypass shares the same fate, as for some time there is no lsp n for bypass m to protect.
I also see the ~ 60 second delay to resignal the bypass, and also felt that was per design as we want to make sure the new lsp is up/stable before we go though the bypass bother. Perhaps an er can be filed if you feel this is unacceptable. Regards -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard A Steenbergen Sent: Sunday, September 28, 2008 6:54 PM To: Mark Tinka Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] LDP/RSVP interop On Mon, Sep 29, 2008 at 07:34:20AM +0800, Mark Tinka wrote: > On Monday 29 September 2008 04:08:49 David Ball wrote: > > > You can certainly use both LDP and RSVP on the Juniper box with no > > problems. RSVP routes in inet3 are preferred over LDP routes, so > > LDP can actually act as a bit of a backup in case you had a massive > > RSVP failure. I'm doing this in my network. > > Can't speak for the Cisco. > > Inter-op for LDP and RSVP between C and J works fine. > > Do take some time to look through these threads on the subject, > though: > > http://puck.nether.net/pipermail/juniper-nsp/2008-June/010549.html > http://puck.nether.net/pipermail/juniper-nsp/2008-May/010395.html > http://puck.nether.net/pipermail/juniper-nsp/2008-April/010247.html > > On the Cisco side, note that it is generally recommended to tunnel LDP > within RSVP, particularly if you're deploying l3vpn's. This is done by > configuring 'mpls ip' on the RSVP Another one to add to the list of things you should consider when working with mixed Juniper/Cisco MPLS is: set protocols <isis|ospf> traffic-engineering ignore-lsp-metrics For an LSP with the head on Juniper and tail on Cisco, this works around Cisco's inability to set an igp cost of 0 on its loopback interface. If you ever wondered why the #$%^& your lsp cost was 1 higher than your igp cost, now you know. :) On the subject of Juniper MPLS, has anyone else noticed that every time you resignal an LSP, even with make-before-break, any associated bypass LSPs are also torn down and take around 50 secs to come back up? I specifically noticed this when auto-bandwidth runs and upates the bw reservation in rsvp, which triggers a resignaling. If you have quick auto-bw timers, this leaves a fairly substantial amount of time that a noticable percentage of your LSPs are not protected, which I consider a bad thing. Since in the case above, where your path isn't actually changing (and the only reason you're resignaling is a bw update), and the bypass LSP is 0 bandwidth anyways, shouldn't it be possible to detect this and not teardown the bypass? The 50 sec delay seems a little excessive too, and I can't find a cause or knob to speed it up. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp