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

Mon Mar 14 16:31:28 EDT 2011

Hi,

I will tell you tomorrow as i have currently no access to the routers.
My secondary path is in standby mode and always up.
I will arrange a new maintenance window with customer to test those all
recommendations.
Btw, could it be a rellay software problem?

Gokhan

2011/3/14 <david.roy at orange-ftgroup.com>

>  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
> 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>
>
>> 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.   <%2B33%280%29299876472>+33(0)299876472
>> Mob. <%2B33%280%29685522213>+33(0)685522213
>> Email. 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] 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
>> 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
>> >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> 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>
>> >>
>> >>> 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] On Behalf Of Keegan Holley
>> >>> Sent: Monday, March 14, 2011 11:15 AM
>> >>> To: Diogo Montagner
>> >>> Cc: 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>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>
>> >>> 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
>> >>> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>> > >
>> >>> >
>> >>> > _______________________________________________
>> >>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>> >
>> >>> _______________________________________________
>> >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>>
>> >>
>> >>
>> >
>> _______________________________________________
>> juniper-nsp mailing list 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.
> ********************************************************************************
>
>