[j-nsp] RE : Re: BGP routes processing

[david.roy at orange.com]

Hi

20 mins is not normal. During the outage, did you experience some kernel queues stuck ? Show krt queue

did you check the logs to see if there are some info to help you for troubleshooting.

Enable bgp traceoption to see more info...

what is the bgp peer of the mx?

Regards
David Roy
Sent from my mobile...
-----Message d'origine-----
De : biwa net
Envoyé :  20/11/2011, 22:31
À : OBrien, Will
CC : juniper-nsp at puck.nether.net
Objet : Re: [j-nsp] BGP routes processing

Hi Will

The 20 min is from the box itself,

Basically I have a client directly connected the MX960 and I basically try
to ping /traceroute  BGP prefixes on the internet through the the transit
provider.

As it is new device coming into the network, we are just doing testing (no
production traffic yet) , The configuration is not overly complicated,
currently it only has simple config such as ISIS , BGP routes, NO
RIB-groups, we have some LDP mpls configuration , but really it's no much

Maybe my way of checking is not good, but what I am doing , is
ping/traceroute to prefixes on the Internet (our transit from whome we
receive the full table being our EBGP nexthop )

when doing ping/traceroute, I always get next hop not reachable , as if the
PFE does not know how to reach the destination (ie does not have the route).

After 15-20 min ,the same ping/traceroute is then working fine which make
me believe that somehow the full BGP table route receive from the provider
(RIB-In) is taking 15-20min to go through the Rib Loc and Rib out and
installed in the PFE.

Currently it is not an issue since we usually do test before bringing the
box in production , but as we will go ahead other box will come in
production and cant afford to wait 15-20 min to have the PFE getting the
full table

anyway you can advise on how I can check how long it takes from the Rib-in
to Rib out /PFE (cmds etcc..)?


On 20 November 2011 19:40, OBrien, Will <ObrienH at missouri.edu> wrote:

> 20 mins is not normal.
> Is that from the box or from a downstream client. What are you doing with
> rib groups and how are you advertising internal routes?
>
> Will O'Brien
>
> On Nov 20, 2011, at 1:30 PM, "biwa net" <biwa2go at gmail.com> wrote:
>
> > hi
> >
> > we added in our network a new mx960, with EBGP peering on it
> >
> > We receive full routing table ,
> >
> > when I do "show route receive-protocol bgp x.x.x.x> it took around 2-3
> min
> > for the 380k to be downloaded, which is ok .
> >
> > But It seems that it took around 20min to be able to reach any bgp
> > destination from that BGP full routing table I received, although when I
> do
> > "show rould see the BGP routete ..."I cou .
> >
> > MY thinking is that it took 2-3 min for the full routing to be installed
> in
> > the RIB-IN, however 20min to be process through the RIB-Loc and then the
> > RIB-out to be installed in the PFE.
> >
> > I don't think it is normal for a  device like a MX960 to take that long
> to
> > process and install the routes in the Forwarding Engine
> >
> > Can anyone advise, how I can see (what commands, output, ...) how long it
> > takes for the MX960 to process the BGP routes from the RIB-IN to Rib-LOC,
> > and how long it takes from the RIB-LOc to the RIB-OUT ie:PFE ?
> > _______________________________________________
> > 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.