[j-nsp] Too much packet loss during switchover on MPLS network

Mon Mar 14 16:19:09 EDT 2011

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.roy at orange-ftgroup.com<mailto:david.roy at orange-ftgroup.com>
JNCIE-M/T  #703 ; JNCIS-ENT

________________________________
De : Gökhan Gümüş [mailto:ggumus at gmail.com]
Envoyé : lundi 14 mars 2011 21:11
À : ROY David DTF/DERX
Cc : Keegan Holley; juniper-nsp at 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.roy at orange-ftgroup.com<mailto:david.roy at 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.roy at orange-ftgroup.com<mailto:david.roy at orange-ftgroup.com>
JNCIE-M/T  #703 ; JNCIS-ENT

-----Message d'origine-----
De : juniper-nsp-bounces at puck.nether.net<mailto:juniper-nsp-bounces at puck.nether.net> [mailto:juniper-nsp-bounces at puck.nether.net<mailto:juniper-nsp-bounces at puck.nether.net>] De la part de Gökhan Gümüs
Envoyé : lundi 14 mars 2011 20:52
À : Keegan Holley
Cc : juniper-nsp at puck.nether.net<mailto:juniper-nsp at 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.holley at sungard.com<mailto:keegan.holley at 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üş <ggumus at gmail.com<mailto:ggumus at 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 <dhanks at juniper.net<mailto:dhanks at 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-bounces at puck.nether.net<mailto:juniper-nsp-bounces at puck.nether.net> [mailto:
>>> juniper-nsp-bounces at puck.nether.net<mailto:juniper-nsp-bounces at puck.nether.net>] On Behalf Of Keegan Holley
>>> Sent: Monday, March 14, 2011 11:15 AM
>>> To: Diogo Montagner
>>> Cc: juniper-nsp at puck.nether.net<mailto:juniper-nsp at 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.montagner at gmail.com<mailto:diogo.montagner at 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üş <ggumus at gmail.com<mailto:ggumus at 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 at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
>>> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> > >
>>> >
>>> > _______________________________________________
>>> > juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at 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.
********************************************************************************