Sorry,

Which release ?

Your secondary path is well in Standby mode ?

Could you enable traffic stat for LSP with a short interval ? And check during 
the blackholing where the LSP is broken on the path (by checking LSP stat on 
nodes before and after the failure ) ?



thks
regards
David


David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david....@orange-ftgroup.com<mailto:david....@orange-ftgroup.com>
JNCIE-M/T  #703 ; JNCIS-ENT


________________________________
De : Gökhan Gümüş [mailto:ggu...@gmail.com]
Envoyé : lundi 14 mars 2011 21:11
À : ROY David DTF/DERX
Cc : Keegan Holley; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network

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<mailto: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<tel:%2B33%280%29299876472>
Mob. +33(0)685522213<tel:%2B33%280%29685522213>
Email. david....@orange-ftgroup.com<mailto: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> 
[mailto: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<mailto: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<mailto: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<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<mailto: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.
********************************************************************************



********************************************************************************
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

Reply via email to