* Stacy W. Smith [2013-02-21 15:57]:
> Sebastian,
>
> PR 836197 is a problem that some customers are seeing, but it is not
> the problem that you reported in this thread. Your issue appears to
> be (primarily) an issue with sampled.
Yes, but the underlying issue seems to be RIB/FIB sync time. An
On Feb 21, 2013, at 2:31 AM, Sebastian Wiesinger
wrote:
> * Sebastian Wiesinger [2013-02-19 13:57]:
>> Yes, I agree. But that's a design "decision" so ATAC is not
>> interested. I'll try to get this to Juniper trough my SE but I don't
>> know if that'll do any good.
>
> So Juniper is aware that
: [j-nsp] MX80 BGP performance after reboot
* Sebastian Wiesinger [2013-02-19 13:57]:
> Yes, I agree. But that's a design "decision" so ATAC is not
> interested. I'll try to get this to Juniper trough my SE but I don't
> know if that'll do any good.
So Juni
* Sebastian Wiesinger [2013-02-21 10:31]:
> There is also a NANOG discussion regarding this:
>
> http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html
Sorry I just glanced at that. That's actually a post from this list.
Regards
Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E
* Sebastian Wiesinger [2013-02-19 13:57]:
> Yes, I agree. But that's a design "decision" so ATAC is not
> interested. I'll try to get this to Juniper trough my SE but I don't
> know if that'll do any good.
So Juniper is aware that this is a problem (at least for some people)
and there are people
is not possible to run junos 64 bits on mx80 ?
PPC dual core supports it ?
why not to use 8 GB dram instead of 2 only ?
Sent from my iPhone
On 19/02/2013, at 12:59, David Miller wrote:
> On 2/19/2013 6:22 AM, Robert Hass wrote:
>> On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger
>> wrot
On 2/19/2013 6:22 AM, Robert Hass wrote:
> On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger
> wrote:
>> This is really frustrating and limits the scope where we can put the
>> MX80 platform. Would it have been so much more expensive to put a
>> faster CPU/RE into that thing? Or is this just a
* Saku Ytti [2013-02-19 13:09]:
> On (2013-02-19 10:54 +0100), Sebastian Wiesinger wrote:
>
> > Okay, so ATAC says that the NANOG PR has nothing to do with this case.
> > This is a hardware limitation on MX and cannot be improved according
> > to them.
>
> I think they are missing the point com
On (2013-02-19 10:54 +0100), Sebastian Wiesinger wrote:
> Okay, so ATAC says that the NANOG PR has nothing to do with this case.
> This is a hardware limitation on MX and cannot be improved according
> to them.
I think they are missing the point completely. There is no excuse to
blackhole, poorl
On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger
wrote:
> This is really frustrating and limits the scope where we can put the
> MX80 platform. Would it have been so much more expensive to put a
> faster CPU/RE into that thing? Or is this just a case of diversifying
> the product line?
It's
* Sebastian Wiesinger [2013-02-19 10:20]:
> So... ATAC says this is expected behavior for this platform. Nothing
> wrong with the router.
>
> He even sent me lab tests that he did which proved that it takes them
> the same time in the lab.
>
> I now sent him the NANOG slides and PR mentioned he
* Sebastian Wiesinger [2013-02-15 00:55]:
> I just tested this after talking to JTAC. Just for reference:
>
> I had ~70k routes from 40 peers that I deactivated. I then turned them
> up again and measured with inline-jflow disabled and enabled.
>
> With inline-jflow ON: around 10-12 minutes unti
* Brandon Ross [2013-02-14 04:57]:
> On Mon, 11 Feb 2013, Jeff Wheeler wrote:
>
> >I am sorry I missed Richard Steenbergen's lightning talk at NANOG,
> >which was something like "if you want your routers to install routes,
> >call Juniper and reference PR# because they do not want to
> >fix this
* Sebastian Wiesinger [2013-02-14 08:06]:
> * Stacy W. Smith [2013-02-12 01:18]:
>
> > Do the KRT error messages go away if you unconfigure sampling? Any
> > change in the KRT installation time with sampling turned off?
>
> I'll test that. I assume I will need to completely disable the
> sampli
On 14/02/13 18:55, joel jaeggli wrote:
> When we're doing a maintence we generally let the router converge with
> our route-reflectors prior to bringing up the transit/peer neighbors. so
> that routes learned from the transits are replacing existing fib routes.
> that also has a salubrious interact
> I'll test that. I assume I will need to completely disable the
> sampling instance?
>
> This is the only MX80 where we use inline-jflow at the moment so it
> could very well be the problem. I also misread the output. I didn't
> identify "sampled" as a daemon but as a message that the pfe is
> sa
rt
Sent: Tuesday, 12 February 2013 12:43 PM
To: 'Juniper NSP'
Subject: Re: [j-nsp] MX80 BGP performance after reboot
I was there for that lightning talk (and very recently seen that
"feature"
actually happening) but what's getting described here by the OP doesn't
seem to
#x27;s FIB is lagging behind its RIB), no?
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Tuesday, 12 February 2013 12:43 PM
To: 'Juniper NSP'
Subject: Re: [j-nsp] MX80 BGP performance after
r.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler
Sent: February-11-13 6:59 PM
To: Juniper NSP
Subject: Re: [j-nsp] MX80 BGP performance after reboot
On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
wrote:
> I noticed that a MX80 takes quite a long time after reboot t
On Mon, 11 Feb 2013, Jeff Wheeler wrote:
I am sorry I missed Richard Steenbergen's lightning talk at NANOG,
which was something like "if you want your routers to install routes,
call Juniper and reference PR# because they do not want to
fix this bug."
It looks like I've beaten him to reply. I
cribe...
Paul
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian
Wiesinger
Sent: February-11-13 6:50 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 BGP performance after reboot
* Paul Stewart [2013-
The PR number is 836197. The PDF is also online for anyone to view it.
http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning2.steenbergen.juniper-slowfib.pdf
Liam Hynes
On Feb 11, 2013, at 6:59 PM, Jeff Wheeler wrote:
> On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
>
* Stacy W. Smith [2013-02-12 01:18]:
> Do the KRT error messages go away if you unconfigure sampling? Any
> change in the KRT installation time with sampling turned off?
I'll test that. I assume I will need to completely disable the
sampling instance?
This is the only MX80 where we use inline-j
* Jeff Wheeler [2013-02-12 01:03]:
> On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
> wrote:
> > I noticed that a MX80 takes quite a long time after reboot to put all
> > routes into the KRT. Is that normal for that box? It takes around 10
> > minutes after BGP is established to get all the
Do the KRT error messages go away if you unconfigure sampling? Any change in
the KRT installation time with sampling turned off?
--Stacy
On Feb 11, 2013, at 4:15 PM, Sebastian Wiesinger
wrote:
> Hi,
>
> I noticed that a MX80 takes quite a long time after reboot to put all
> routes into the K
On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
wrote:
> I noticed that a MX80 takes quite a long time after reboot to put all
> routes into the KRT. Is that normal for that box? It takes around 10
> minutes after BGP is established to get all the routes into the KRT
Yes, the routes taking a
* Paul Stewart [2013-02-12 00:36]:
> What version of JunOS? Just one full table or many?
11.4R6-S1
Combined Full-Table from a few iBGP peers and around 70k routes from an
IXP. Approx. 700k Routes in RIB.
Regards
Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A
Sent: February-11-13 6:16 PM
To: Juniper NSP
Subject: [j-nsp] MX80 BGP performance after reboot
Hi,
I noticed that a MX80 takes quite a long time after reboot to put all routes
into the KRT. Is that normal for that box? It takes around 10 minutes after
BGP is established to get all the routes int
Hi,
I noticed that a MX80 takes quite a long time after reboot to put all
routes into the KRT. Is that normal for that box? It takes around 10
minutes after BGP is established to get all the routes into the KRT
and in the meantime we get messages like that every few seconds:
/kernel: rt_pfe_veto:
29 matches
Mail list logo
