Disabling an interface or yanking fibers is certainly quicker....you can speed up convergence following a deactivate if you add BFD and maybe some LFA, but the loss of light on an interface has been faster than a deactivate in every case I've ever tested.
David 2011/3/14 Keegan Holley <keegan.hol...@sungard.com>: > Deactivating the interface should remove the IP address which should cause > the IGP to converge immediately. > > On Mon, Mar 14, 2011 at 5:59 PM, Matthew Tighe > <matthew.e.ti...@gmail.com>wrote: > >> You can *disable *the interface rather than *deactivate *it. That should >> show it as down immediately. >> >> set interface fe-x/y/z disable >> commit >> >> >> >> On Mon, Mar 14, 2011 at 2:21 PM, Gökhan Gümüş <ggu...@gmail.com> wrote: >> >> > It might make sense...I have been always thinking on it. >> > Which way would be useful to test such behaviour? >> > To disable circuit or? >> > >> > Thanks, >> > Gokhan >> > >> > On Mon, Mar 14, 2011 at 10:15 PM, Amos Rosenboim <a...@oasis-tech.net >> > >wrote: >> > >> > > As far as I remember deactivating the interface will not take the link >> > > down, so we are relying on igp hold times to detect the failure. >> > > If so, does the 45 seconds make any sense ? >> > > Can you correlate igp adjacency loss to lsp switchover to customer >> pings >> > ? >> > > >> > > Amos >> > > >> > > Sent from my iPhone >> > > >> > > On 14 Mar 2011, at 21:55, "Doug Hanks" <dha...@juniper.net> wrote: >> > > >> > > > If it’s VPLS, the customer wouldn’t be using BGP though. That’s why >> I >> > > mentioned STP. >> > > > >> > > > From: Keegan Holley [mailto:keegan.hol...@sungard.com] >> > > > Sent: Monday, March 14, 2011 12:47 PM >> > > > To: Gökhan Gümüş >> > > > Cc: Doug Hanks; Diogo Montagner; juniper-nsp@puck.nether.net >> > > > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS >> > > network >> > > > >> > > > Another to way to check would be to figure out when you start seeing >> > > mac-addresses from the customer in the vpls tables. That will mean the >> > > network has failed over properly. Do you know what the customer >> topology >> > > looks like? They could be waiting for BGP to fail over or something >> else >> > > that inherently slow. I doubt this is a problem with your mpls config, >> > > especially if you see your lsp switch. It's hard to guess without >> > knowing >> > > your's or the customer's topology though. >> > > > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş <ggu...@gmail.com >> > <mailto: >> > > ggu...@gmail.com>> wrote: >> > > > No, they are not using rapid ping, i can confirm it. >> > > > >> > > > I do not agree with Spanning tree issue. >> > > > Just for note, i am just de-activating one circuit via CLI to trigger >> > > transition from primary to secondary. >> > > > >> > > > Gokhan >> > > > >> > > > >> > > > 2011/3/14 Doug Hanks <dha...@juniper.net<mailto:dha...@juniper.net>> >> > > > I'm sure they were using a rapid ping, so it didn't take anywhere >> near >> > 45 >> > > seconds. If they were using a regular ping, however, it maybe a STP >> > issue. >> > > > >> > > > Also are you using pre-signaled LSPs? >> > > > >> > > > -----Original Message----- >> > > > From: juniper-nsp-boun...@puck.nether.net<mailto: >> > > juniper-nsp-boun...@puck.nether.net> [mailto: >> > > juniper-nsp-boun...@puck.nether.net<mailto: >> > > juniper-nsp-boun...@puck.nether.net>] On Behalf Of Keegan Holley >> > > > Sent: Monday, March 14, 2011 11:15 AM >> > > > To: Diogo Montagner >> > > > Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>; >> > > Gökhan Gümüş >> > > > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS >> > > network >> > > > >> > > > On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner >> > > > <diogo.montag...@gmail.com<mailto:diogo.montag...@gmail.com>>wrote: >> > > > >> > > >> Do you have FRR enabled on the LSPs ? >> > > >> >> > > > >> > > > Node protection and link-protection is the same thing as fast >> re-route. >> > > > >> > > > Is it configured correctly though? You have to configure a secondary >> > > path >> > > > under protocols mpls and then enable it for FRR/node protection. You >> > > can't >> > > > just enable it and have it work. >> > > > Also, what does the topology look like? Could you just be waiting >> for >> > > > customer routing/spanning tree? Even without FRR your lsp's failover >> > at >> > > the >> > > > speed of your IGP when a link is shut down. None of them take 41 >> > > seconds. >> > > > >> > > >> >> > > >> >> > > >> On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş <ggu...@gmail.com >> > > <mailto:ggu...@gmail.com>> wrote: >> > > >>> Dear all, >> > > >>> >> > > >>> I have a problem with one of our customer. >> > > >>> >> > > >>> Customer has been deployed with VPLS. We are using primary path and >> > > >>> secondary path ( standby ) to handle VPLS traffic between sites. >> > > >>> >> > > >>> Within a maintenance window, we made a failover test. Customer was >> > > >> pinging >> > > >>> remote site continuosly and we would like to test how many packets >> > are >> > > >> being >> > > >>> lost during switchover. When i triggered transition from primary to >> > > >>> secondary, customer lost 41 packets during ping test. Then i >> > > implemented >> > > >>> node-link-protection and link protection in case they help but >> > customer >> > > >>> experienced same amount of packet loss during transition. >> > > >>> >> > > >>> My question, is it a normal behaviour? From my perspective it is >> not >> > a >> > > >>> normal behaviour. >> > > >>> >> > > >>> Has anybody such an experince? >> > > >>> >> > > >>> Thanks and regards, >> > > >>> >> > > >>> Gokhan >> > > >>> _______________________________________________ >> > > >>> juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto: >> > > juniper-nsp@puck.nether.net> >> > > >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > >>> >> > > >> >> > > >> _______________________________________________ >> > > >> juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto: >> > > juniper-nsp@puck.nether.net> >> > > >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > >> >> > > > _______________________________________________ >> > > > juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto: >> > > 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 >> > > >> > _______________________________________________ >> > juniper-nsp mailing list juniper-nsp@puck.nether.net >> > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> >> >> >> -- >> Matthew Tighe >> matthew.e.ti...@gmail.com >> _______________________________________________ >> 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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp