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

Mon Mar 14 16:11:27 EDT 2011

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.   +33(0)299876472
> Mob. +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.
>
> ********************************************************************************
>
>