Actually i am using MX960 routers. Did you monitor forwarding database on each PE to check if there is any change (MAC address refresh) after your 41 sec of outage ?
- I need to re-test it. Currently i can not say it. Did you experience the same issue when your primary LSP comes up (and after the revert timout) ? No there is no packet loss during transition from secondary to primary. Thanks and regards, Gokhan 2011/3/14 <david....@orange-ftgroup.com> > Hi, > > Which version and HW do you use ? > > Did you monitor forwarding database on each PE to check if there is any > change (MAC address refresh) after your 41 sec of outage ? > > Did you experience the same issue when your primary LSP comes up (and after > the revert timout) ? > > Regards > David > > > David Roy > Orange - IP Domestic Backbone - TAC > Tel. +33(0)299876472 > Mob. +33(0)685522213 > Email. david....@orange-ftgroup.com > JNCIE-M/T #703 ; JNCIS-ENT > > -----Message d'origine----- > De : juniper-nsp-boun...@puck.nether.net [mailto: > juniper-nsp-boun...@puck.nether.net] De la part de Gökhan Gümüs > Envoyé : lundi 14 mars 2011 20:52 > À : Keegan Holley > Cc : juniper-nsp@puck.nether.net > Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network > > Hi, > > Actually customer BGP session is always up. I requested them to ping from > different servers to the same destination when i shut the interface down.All > of them had no reachability to the remote destinations. > Could it be possible to fix it with BFD? > > Thanks, > Gokhan > > On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley <keegan.hol...@sungard.com > >wrote: > > > 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> 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> > >> > >>> 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] On Behalf Of Keegan Holley > >>> Sent: Monday, March 14, 2011 11:15 AM > >>> To: Diogo Montagner > >>> Cc: 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>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> > >>> 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 > >>> > > 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 > >>> > >> > >> > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ******************************************************************************** > IMPORTANT.Les informations contenues dans ce message electronique y compris > les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, > veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans > ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment > s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout > virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential > and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e-mail > message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not > be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > ******************************************************************************** > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp