Using different cluster-ids you end up with multiple copies of all the
prefixes but done correctly it works just fine and provides better
redundancy at the cost of higher "path" count.
If you are running single cluster-id and pushing router memory limits it
would be a bad idea.
If you have the
> On 15 January 2016 at 03:13, Christopher E. Brown
>> <chris.br...@acsalaska.net> wrote:
>>> When the same folks were asked about the 16XGE card and the 120G (and
>>> later 160G) performance it was indicated that there was an additional
>>> layer of lo
On 1/14/2016 1:48 PM, Jeff wrote:
> Am 14.01.2016 um 23:19 schrieb Christopher E. Brown:
>>
>>
>> Agree, mixing DPC and MPC is a terrible idea. Don't like DPC to begin
>> with, but nobody in their right mind mixes DPCs and MPCs.
>>
>
> Why is that? The
then it'll give 13.33Gbps of grands to
> each SCB.
> However as DPCE won't use the third one, DPCE could only send at
> 26.66Gbps towards that 40Gbps trio. While MPC would happily send
> 40Gbps to MPC.
>
--
---
Bs, and all DPC linecards. Would these all be
> able to run at
> line rate?
>
> On Thu, Jan 14, 2016 at 4:19 PM, Christopher E. Brown
> <chris.br...@acsalaska.net
> <mailto:chris.br...@acsalaska.net>> wrote:
>
>
> It is 120Gbit agg in a SCB system a
/14/2016 2:13 PM, Adam Vitkovsky wrote:
>> Christopher E. Brown
>> Sent: Thursday, January 14, 2016 10:20 PM
>> To: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] MX960 with 3 RE's?
>>
>>
>> It is 120Gbit agg in a SCB system as the limit is 120G/slo
40G duplex after jcell/etc overhead.
On 1/14/2016 3:27 PM, Saku Ytti wrote:
> On 15 January 2016 at 01:39, Christopher E. Brown
> <chris.br...@acsalaska.net> wrote:
>> The 30Gbit nominal (actual 31.7 or greater) limit per trio applies to the
>> MPC1 and 2 cards
>>
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
___
juniper-nsp mailing list
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
___
juniper-nsp mailing
.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
/juniper-nsp
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
in slot 1 of a 960, just tipped on
its side.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
back to out of band modem.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
amount at minimum right?
What determines what is dropped when there is contention on the bus?
Are there any commands I could use to see whether a bus is/was
congested and how much of what was dropped?
On Sat, Feb 23, 2013 at 9:37 PM, Christopher E. Brown
chris.br...@acsalaska.net
!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
23, 2013 at 8:13 PM, Christopher E. Brown
chris.br...@acsalaska.net mailto:chris.br...@acsalaska.net wrote:
With the std cfeb after internal overhead per bus capacity is 3.2Gbit of
traffic, this is worst case minimum small packets, etc.
Raw bus capacity is IIRC ~ 4Gbit
as same class. If you have a ipv4 rewrite in place it would kick in.
On 2/5/13 12:31 AM, Alexandre Snarskii wrote:
On Mon, Feb 04, 2013 at 09:36:10AM -0900, Christopher E. Brown wrote:
The packet is classified on input.
*UNLESS* you use table-label in a l3vpn, then it gets re-classified
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
instances.
I just opened a case and cited the closed PR and bogus/unsolved.
On 11/14/2012 11:08 AM, Christopher E. Brown wrote:
Except I am running network-services ip not enhanced-ip, and 10.4R10 now
R11 (PR lists R9 as fixed) and am seeing shared policers.
On 11/14/12 8:19 AM, Addy Mathur
On 12/6/12 8:14 AM, Saku Ytti wrote:
On (2012-12-06 09:00 -0800), Michael Loftis wrote:
The biggest thing I miss over Cisco is VTP. Managing VLAN's is a huge pain
without it when you've got dozens of switches that all need the same VLAN
VTP has ups and downs. Many people have broken
=prcontentid=PR674408
Regards,
Addy.
On Fri, Nov 9, 2012 at 2:57 PM, Christopher E. Brown
chris.br...@acsalaska.net mailto:chris.br...@acsalaska.net wrote:
Please share case #, I have same complaints in discussion with our SE
and up that chain.
Personally I think they need to add
in 10.4 (which
is what I want for IP options). And VPLS policer I want not-shared, as in
11.4.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
On 11/6/12 3:43 AM, Sebastian Wiesinger wrote:
* Christopher E. Brown chris.br...@acsalaska.net [2012-11-06 10:41]:
And I have tested and seen exactly the opposite with 10.4R10 in both
MX80 and all trio MX960.
Create a policer and a vpls filter that matches unknown ucast, bcast and
mcast
scheduling.
That is correct, xe-0/0/0 through xe-0/0/3 are port mode only. It is
the MIC interfaces that have per-unit shaping.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
to make the 10.4-series to support MX5/10/40s
unless someone else has done it already.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907
Is mapping multiple forwarding classes per queue even possible on a J series?
forwarding-class class and restricted queue don't even seem to be avail in the
CLI but I
cannot find any docs that cover it one way or the other.
___
juniper-nsp mailing
iperf counts payload, not total L3. The policer is counting total L3.
10Mbit bits/sec of total L3 is 9.8Mbit of payload in this case.
There is _always_ noise in the system.
Unless you are using a calibrated test device doing the work in hardware
(or well written software in a RealTime
On 7/20/10 10:54 PM, Leigh Porter wrote:
I thought that as soon as you turn MPLS on the flow mode was diabled and
you were back to good old packet mode?
--
Leigh
Is puts things in packet mode, but all of the memory pre-allocs to
support flow mode remain in play.
if there are any other side
effects.
The process is required for forwarding. It can be disabled in the config, but
then all
routing stops.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
On 7/21/2010 12:34 PM, Smith W. Stacy wrote:
On Jul 21, 2010, at 12:35 PM, Christopher E. Brown wrote:
On 7/20/10 10:54 PM, Leigh Porter wrote:
I thought that as soon as you turn MPLS on the flow mode was diabled and
you were
back to good old packet mode?
-- Leigh
Is puts things
On 7/21/2010 6:09 AM, Jay Hanke wrote:
After implementing the procedure did you see a drop in memory utilization?
If so, how much?
jay
No reduction *AT ALL*, that is the issue.
Turning off flow mode does not free the pre-alloced memory used to support flow
functions.
On 7/21/2010 1:23 PM, Heath Jones wrote:
Chris - Sorry I didnt realise the process had changed names and we are
actually talking about the forwarding process itself. In that case, the
only other thing I can think of right now is:
When the forwarding process starts, it allocates the 400Mb+ for
On 7/21/2010 2:28 PM, Nilesh Khambal wrote:
I am not a J-Series person and don't know much about flowd operation but
does the memory utilization come down when you reboot the router after
disabling the flow mode?
How does the flowd memory stats looks like in show system processes
extensive
On 7/21/2010 3:47 PM, Heath Jones wrote:
Chris - Is the current situation: that Juniper have said there is no
workaround / configuration change that can be made to stop the
allocation of memory for the flow forwarding information?
The current response is that this memory consumption is by
I know alot of us here have been bitten by this, and the fact that disabling
flow mode and
reverting to packet does not free up any of the ~ 460MB or so being eaten by
fwdd/flowd is
insane.
I am currently having the This is a design feature, the pre-alloc is planned
argument
with a SE.
I
41 matches
Mail list logo
