Re: [j-nsp] SRX firewall virtualization

[james list]

Thanks Damien
very good explaination.

Regards
James

2015-10-02 14:56 GMT+02:00 Damien DeVille :

> In my opinion, Lsys has one distinct use case and one only.  That use case
> is when you have a requirement for multiple different groups to have
> administrative control over thier own distinct security policies.
>
> Lsys comes with a lengthy list of caveats and limitations (this is not an
> all inclusive list, but here are a few items that come to mind - some of
> this may have changed, my information is about a 1-2 years old)
>
>- You're limited to 32 Lsys instances.  That's unlikely to change
>moving forward.
>- Intra-Lsys communication can increase the session count
>significantly and dramatically reduce the overall performance of the
>device.  Each Lsys has to keep state on the same session.
>- Some HA features are not supported (NSR, NSB, ISSU)
>- Multiple traffic selectors (multiple proxy ids) are not supported
>- ALGs can only be configured at the root level and apply to all Lsys
>instances.
>- IDP DB and Policy can only be updated at the root level and applies
>to all instances
>- LT interfaces are required for Intra-Lsys communications.
>- CoS can't be applied to an LT interface.
>- You can set the bandwidth on an LT interface up to 40g (1g, 10g,
>40g), but you're limited by the speed of the back-plane (determined by the
>SCB or SRE depending on your HE box)
>- Trace and debug are only supported at the root level
>- Commit rollback is only supported at the root level
>
> With all that in mind, if you don't have a requirement for separation of
> policy administration, I would recommend you investigate VR's and Zones as
> your mechanism for vitalization on the SRX.
>
> With VR's you would likely use Rib Groups for intra-vr communications - ,
> though you could also use an LT interface (if you wanted to hamstring
> yourself).
>
>
>
>
> - Damien
>
> On Fri, Oct 2, 2015 at 3:08 AM, james list  wrote:
>
>> Dear experts,
>>
>> I’d like to know your opinion about firewall virtualization inside SRX
>> boxes (high-end).
>>
>>
>> As far as I understand there are a couple of way: Logical Systems (LSys)
>> and Virtual routers (VR).
>>
>>
>>
>> From your point of view:
>>
>>
>> 1)  Which are the main differences among Lsys and VR ?
>>
>> 2)  Which are pro and cons of LSys and VR ?
>>
>> 3)  If I need to put in communication two LSys in the same box which
>> is
>> the maximum throughtput I can get ? Should I use lt- interface ?
>>
>> 4)  If I need to put in communication two VR  in the same boz which is
>> the maximum throughtput I can get ? Should I use import/export ?
>>
>>
>>
>> If  inside the feedbacks you can provide any reference URL it will be
>> appreciated.
>>
>>
>>
>> Cheers
>>
>> James
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX firewall virtualization

[Youssef Bengelloun-Zahr]

Hello,

My comments inline.

BR.



2015-10-02 14:44 GMT+02:00 james list :

> Hi Youssef
> so you use LSYS since quite time, is there a reason why you have decided
> for that and not for VR ?
>

==> I never said that, we use them both. As stated before by Chris Jones,
L-SYS is a higher a higher level of abstraction and multitenancy that
allows to create virtual boxes with dedicated ressources, etc. You can
always create multiple VRs inside L-SYS as much as you need. These are two
very different things.


>
> LSYS as far as I understand is limited to 32, right ?
>

==> IIRC, I think the actual maximum is 32 L-SYS, submitted to licensing of
course.


>
> Which is the throughput you get among LSYS ?
>

==> I don't know, we never tested that. If I were to make a wild guess, I'd
say pretty high because it's purely internal forwarding using logical
interfaces. What kind of throughput are you looking for ?


>
>
> As far as I see now the only benefit of LSYS against VR is the separate
> management... nothing more...
> Less scalability, less features, etc...
>

==> Not true at all. Exception made for some specific limitations, you keep
the exact some set of features and all. Ressources are just split over the
multiple L-SYS plus you get seperte management.



>
> Cheers
>
> 2015-10-02 14:36 GMT+02:00 Youssef Bengelloun-Zahr :
>
>> Hello,
>>
>> We've been using those in an 5600 cluster for quite some time now, no
>> major worries. As usual, you will of course run into certain limitations /
>> caveats of the technology. But hey, what did you expect ?  ;-)
>>
>> Number of L-SYS supported have increased over time with newer versions of
>> Junos. Communications between L-SYS need to use lt-interfaces and L-SYS
>> must be meshed using those in a hub-and-spoke fashion since 12.1X47.
>>
>> HTH and BR.
>>
>>
>>
>> 2015-10-02 11:22 GMT+02:00 james list :
>>
>>> Well indeed with SRX you can also associate zones+policies to the
>>> interface
>>> in the specific routing table
>>> I guess it's something more from my point of view
>>>
>>> and I see also some benefit against lsys, I understand that SRX high end
>>> for example supoprt a few number of lsys...
>>> isn,'t it ?
>>>
>>>
>>>
>>> 2015-10-02 10:56 GMT+02:00 Chris Jones :
>>>
>>> > VR is multiple routing tables.
>>> >
>>> > Lsys is logical systems... basically one step deeper in logical
>>> > segmentation. Essentially multiple full routers in each box.
>>> >
>>> > On Fri, Oct 2, 2015 at 9:08 AM, james list 
>>> wrote:
>>> >
>>> >> Dear experts,
>>> >>
>>> >> I’d like to know your opinion about firewall virtualization inside SRX
>>> >> boxes (high-end).
>>> >>
>>> >>
>>> >> As far as I understand there are a couple of way: Logical Systems
>>> (LSys)
>>> >> and Virtual routers (VR).
>>> >>
>>> >>
>>> >>
>>> >> From your point of view:
>>> >>
>>> >>
>>> >> 1)  Which are the main differences among Lsys and VR ?
>>> >>
>>> >> 2)  Which are pro and cons of LSys and VR ?
>>> >>
>>> >> 3)  If I need to put in communication two LSys in the same box
>>> which
>>> >> is
>>> >> the maximum throughtput I can get ? Should I use lt- interface ?
>>> >>
>>> >> 4)  If I need to put in communication two VR  in the same boz
>>> which is
>>> >> the maximum throughtput I can get ? Should I use import/export ?
>>> >>
>>> >>
>>> >>
>>> >> If  inside the feedbacks you can provide any reference URL it will be
>>> >> appreciated.
>>> >>
>>> >>
>>> >>
>>> >> Cheers
>>> >>
>>> >> James
>>> >> ___
>>> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Chris Jones
>>> > JNCIE-ENT #272
>>> > CCIE# 25655 (R)
>>> >
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>>
>
>


-- 
Youssef BENGELLOUN-ZAHR
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understand the DRAM usage on CFEB(FEB-M10i-M7i-S)

[Martin T]

This makes sense. Thanks!


regards,
Martin

On 10/1/15, Michael Loftis  wrote:
> It's not quite the FIB, it's a representation of it (J-Tree) for
> lookups.  I don't recall much of the specifics past that on the
> FEB/CFEB of the M7i/M10i because there's the other memories involved
> too and I can't recall how they're used.  But yes the microkernel is
> given a digest of the FIB as a j-tree which it keeps a copy of.
>
> On Thu, Oct 1, 2015 at 5:51 AM, Martin T  wrote:
>> One last question- am I correct that copy of FIB is kept on this
>> microkernel SDRAM? I mean there seems to be a clear correlation
>> between amount of routes in router and CFEB microkernel memory
>> utilization. The reason I assume this is because if I upgrade the
>> SDRAM SODIMM on CFEB(i.e. upgrade the memory for microkernel), then
>> total amount of "heap" memory on CFEB increases and if router has more
>> routes, then the usage of "heap" memory increases.
>>
>>
>> thanks,
>> Martin
>>
>> On 9/30/15, Martin T  wrote:
>>> Ok, thanks! I had never seen a solution where parity information is
>>> stored in additional individual SDRAM chips. So in conclusion 128MiB
>>> of on-board SDRAM is used for packet memory, 64MiB of on-board SDRAM
>>> is used for packet memory parity information and replaceable DDR SDRAM
>>> SODIMM is used solely for the PFE microkernel.
>>>
>>>
>>> regards,
>>> Martin
>>>
>>> On 9/29/15, Michael Loftis  wrote:
 The "extra" SDRAM chips.  The packet memory has parity or ECC bits, I
 actually do not recall for sure which, but the "extra" is for those
 extra bits.

 On Tue, Sep 29, 2015 at 12:45 PM, Martin T  wrote:
> What do you mean?
>
>
> thanks,
> Martin
>
> On Tue, Sep 29, 2015 at 8:45 PM, Michael Loftis 
> wrote:
>> Parity/ECC.
>>
>> On Tue, Sep 29, 2015 at 7:32 AM, Martin T  wrote:
>>> Hi,
>>>
>>> according to Juniper M10i Compact Forwarding Engine
>>> Board(http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/cfeb-m10i-description.html)
>>> documentation it has 128 MiB SDRAM for packet memory and 128 MiB
>>> SDRAM
>>> for the microkernel. If I visually inspect the CFEB, then it has
>>> twelve "MT 46V8M16" DDR SDRAM chips which means 12x 134217728 bits,
>>> i.e. 192MiB of on-board soldered DDR SDRAM. Questions:
>>>
>>> 1) Are four "MT 46V8M16" DDR SDRAM chips actually not in use? If
>>> they
>>> are in use, then what for?
>>>
>>> 2) Am I correct that on-board soldered DRAM is used for shared
>>> packet
>>> buffer and installable DDR SDRAM SODIMM is used for the microkernel?
>>>
>>>
>>> thanks,
>>> Martin
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>> --
>>
>> "Genius might be described as a supreme capacity for getting its
>> possessors
>> into trouble of all kinds."
>> -- Samuel Butler



 --

 "Genius might be described as a supreme capacity for getting its
 possessors
 into trouble of all kinds."
 -- Samuel Butler

>>>
>
>
>
> --
>
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX firewall virtualization

[james list]

Hi Youssef
so you use LSYS since quite time, is there a reason why you have decided
for that and not for VR ?

LSYS as far as I understand is limited to 32, right ?

Which is the throughput you get among LSYS ?


As far as I see now the only benefit of LSYS against VR is the separate
management... nothing more...
Less scalability, less features, etc...

Cheers

2015-10-02 14:36 GMT+02:00 Youssef Bengelloun-Zahr :

> Hello,
>
> We've been using those in an 5600 cluster for quite some time now, no
> major worries. As usual, you will of course run into certain limitations /
> caveats of the technology. But hey, what did you expect ?  ;-)
>
> Number of L-SYS supported have increased over time with newer versions of
> Junos. Communications between L-SYS need to use lt-interfaces and L-SYS
> must be meshed using those in a hub-and-spoke fashion since 12.1X47.
>
> HTH and BR.
>
>
>
> 2015-10-02 11:22 GMT+02:00 james list :
>
>> Well indeed with SRX you can also associate zones+policies to the
>> interface
>> in the specific routing table
>> I guess it's something more from my point of view
>>
>> and I see also some benefit against lsys, I understand that SRX high end
>> for example supoprt a few number of lsys...
>> isn,'t it ?
>>
>>
>>
>> 2015-10-02 10:56 GMT+02:00 Chris Jones :
>>
>> > VR is multiple routing tables.
>> >
>> > Lsys is logical systems... basically one step deeper in logical
>> > segmentation. Essentially multiple full routers in each box.
>> >
>> > On Fri, Oct 2, 2015 at 9:08 AM, james list 
>> wrote:
>> >
>> >> Dear experts,
>> >>
>> >> I’d like to know your opinion about firewall virtualization inside SRX
>> >> boxes (high-end).
>> >>
>> >>
>> >> As far as I understand there are a couple of way: Logical Systems
>> (LSys)
>> >> and Virtual routers (VR).
>> >>
>> >>
>> >>
>> >> From your point of view:
>> >>
>> >>
>> >> 1)  Which are the main differences among Lsys and VR ?
>> >>
>> >> 2)  Which are pro and cons of LSys and VR ?
>> >>
>> >> 3)  If I need to put in communication two LSys in the same box
>> which
>> >> is
>> >> the maximum throughtput I can get ? Should I use lt- interface ?
>> >>
>> >> 4)  If I need to put in communication two VR  in the same boz
>> which is
>> >> the maximum throughtput I can get ? Should I use import/export ?
>> >>
>> >>
>> >>
>> >> If  inside the feedbacks you can provide any reference URL it will be
>> >> appreciated.
>> >>
>> >>
>> >>
>> >> Cheers
>> >>
>> >> James
>> >> ___
>> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>> >
>> >
>> >
>> > --
>> > Chris Jones
>> > JNCIE-ENT #272
>> > CCIE# 25655 (R)
>> >
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX firewall virtualization

[james list]

Well indeed with SRX you can also associate zones+policies to the interface
in the specific routing table
I guess it's something more from my point of view

and I see also some benefit against lsys, I understand that SRX high end
for example supoprt a few number of lsys...
isn,'t it ?



2015-10-02 10:56 GMT+02:00 Chris Jones :

> VR is multiple routing tables.
>
> Lsys is logical systems... basically one step deeper in logical
> segmentation. Essentially multiple full routers in each box.
>
> On Fri, Oct 2, 2015 at 9:08 AM, james list  wrote:
>
>> Dear experts,
>>
>> I’d like to know your opinion about firewall virtualization inside SRX
>> boxes (high-end).
>>
>>
>> As far as I understand there are a couple of way: Logical Systems (LSys)
>> and Virtual routers (VR).
>>
>>
>>
>> From your point of view:
>>
>>
>> 1)  Which are the main differences among Lsys and VR ?
>>
>> 2)  Which are pro and cons of LSys and VR ?
>>
>> 3)  If I need to put in communication two LSys in the same box which
>> is
>> the maximum throughtput I can get ? Should I use lt- interface ?
>>
>> 4)  If I need to put in communication two VR  in the same boz which is
>> the maximum throughtput I can get ? Should I use import/export ?
>>
>>
>>
>> If  inside the feedbacks you can provide any reference URL it will be
>> appreciated.
>>
>>
>>
>> Cheers
>>
>> James
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
> --
> Chris Jones
> JNCIE-ENT #272
> CCIE# 25655 (R)
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] convert config from m120 to mx480

[Chuck Anderson]

On Fri, Oct 02, 2015 at 12:08:34PM -0500, David B Funk wrote:
> We have a venerable m120 that's being used as an edge router in our
> department on campus. We've recently acquired an mx480 as a replacement.
> 
> I'm trying to decide the best way to port the m120 config to the mx480;
> Either a pretty much straight up port (strictly a L3 device) or try
> to convert it to a L2/L3 config that can utilize some of the switching
> features of the mx480.
> 
> Anybody have suggestions or advice for this scenario?

Keep it strictly as a L3 device.  Eliminate as much L2 as possible
from your network :-)

Some recommended blog posts:

http://blog.ipspace.net/2011/10/l2-or-l3-switching-in-campus-networks.html

http://blog.ipspace.net/2015/04/what-is-layer-2-and-why-do-we-need-it.html

http://blog.ipspace.net/2015/04/more-layer-2-misconceptions.html

http://blog.ipspace.net/2015/04/rearchitecting-l3-only-networks.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] convert config from m120 to mx480

[David B Funk]

We have a venerable m120 that's being used as an edge router in our
department on campus. We've recently acquired an mx480 as a replacement.

I'm trying to decide the best way to port the m120 config to the mx480;
Either a pretty much straight up port (strictly a L3 device) or try
to convert it to a L2/L3 config that can utilize some of the switching
features of the mx480.

Anybody have suggestions or advice for this scenario?

Thanks,
Dave

--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] convert config from m120 to mx480

[Michael Still]

Agree completely. Layer-2 should be kept as close to the access edge as
possible and not span anything that could be done via Layer-3.


On Fri, Oct 2, 2015 at 1:31 PM, Chuck Anderson  wrote:

> On Fri, Oct 02, 2015 at 12:08:34PM -0500, David B Funk wrote:
> > We have a venerable m120 that's being used as an edge router in our
> > department on campus. We've recently acquired an mx480 as a replacement.
> >
> > I'm trying to decide the best way to port the m120 config to the mx480;
> > Either a pretty much straight up port (strictly a L3 device) or try
> > to convert it to a L2/L3 config that can utilize some of the switching
> > features of the mx480.
> >
> > Anybody have suggestions or advice for this scenario?
>
> Keep it strictly as a L3 device.  Eliminate as much L2 as possible
> from your network :-)
>
> Some recommended blog posts:
>
> http://blog.ipspace.net/2011/10/l2-or-l3-switching-in-campus-networks.html
>
> http://blog.ipspace.net/2015/04/what-is-layer-2-and-why-do-we-need-it.html
>
> http://blog.ipspace.net/2015/04/more-layer-2-misconceptions.html
>
> http://blog.ipspace.net/2015/04/rearchitecting-l3-only-networks.html
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] convert config from m120 to mx480

[Justin M. Streiner]

On Fri, 2 Oct 2015, David B Funk wrote:


We have a venerable m120 that's being used as an edge router in our
department on campus. We've recently acquired an mx480 as a replacement.

I'm trying to decide the best way to port the m120 config to the mx480;
Either a pretty much straight up port (strictly a L3 device) or try
to convert it to a L2/L3 config that can utilize some of the switching
features of the mx480.

Anybody have suggestions or advice for this scenario?


We replaced a pair of M120s at our border with MX480s a little over a year 
ago.  Large chunks of the config will port over cleanly, but there are 
some gotchas:


1. slot/card/interface naming and numbering might be different, depending
on the type of cards you have and how things are physically laid out.
2. The sampling configuration is completely different going from the M 
series to the MX series.  This can also change on the MX platform, 
depending on which version of code you're running.
3. There are some licensing differences to take into account as well, if 
this hasn't been done already.


The preparation for the cutover took a long time, but the actual cut was 
relatively painless, other than a sampling bug we triggered in the version 
of code that we were recommended to use at that time (12.3R6.6 I think - 
we have since upgraded).


jms
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Colton Conor]

Does anyone have an update on when Juniper will release SMP (symmetrical
multi processor) aka the ability to use multiple cores? Do you think the
second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
MX240/480 have one or 2 cores?

On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:

>
>
> On 11/May/15 13:27, Olivier Benghozi wrote:
> >
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> <
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > "Statement introduced in Junos OS Release 13.3 R4"
>
> We decided not to enable this now because I understand the plan is for
> 64-bit mode to become the default in later versions of Junos.
>
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[joel jaeggli]

On 10/2/15 2:33 PM, Phil Rosenthal wrote:
>> On Oct 2, 2015, at 5:11 PM, Colton Conor  wrote:
>>
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?

afaik the re2000 was a single core pentium-m the re4x1800 is a bit more
robust.

> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>>
>>>
>>>
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html


 "Statement introduced in Junos OS Release 13.3 R4"
>>>
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>>
>>> Mark.
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Rosenthal]

> On Oct 2, 2015, at 5:11 PM, Colton Conor  wrote:
>
> Does anyone have an update on when Juniper will release SMP (symmetrical
> multi processor) aka the ability to use multiple cores? Do you think the
> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
> MX240/480 have one or 2 cores?
>

I have heard that this is planned for Junos 15.

-Phil
>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>
>>
>>
>>> On 11/May/15 13:27, Olivier Benghozi wrote:
>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>> <
>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>>
>>>
>>> "Statement introduced in Junos OS Release 13.3 R4"
>>
>> We decided not to enable this now because I understand the plan is for
>> 64-bit mode to become the default in later versions of Junos.
>>
>> Mark.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Olivier Benghozi]

I have heard that:
1) forget it about PowerPC CPUs (MX 80/104).
2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP 
activated; but I guess that as long as rpd won't be recoded accordingly, it 
won't be any faster.

> Le 2 oct. 2015 à 23:33, Phil Rosenthal  a écrit :
> 
>> On Oct 2, 2015, at 5:11 PM, Colton Conor > > wrote:
>> 
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?
>> 
> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>> 
>>> 
>>> 
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
 
 
 "Statement introduced in Junos OS Release 13.3 R4"
>>> 
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>> 
>>> Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX firewall virtualization

[james list]

Dear experts,

I’d like to know your opinion about firewall virtualization inside SRX
boxes (high-end).


As far as I understand there are a couple of way: Logical Systems (LSys)
and Virtual routers (VR).



From your point of view:


1)  Which are the main differences among Lsys and VR ?

2)  Which are pro and cons of LSys and VR ?

3)  If I need to put in communication two LSys in the same box which is
the maximum throughtput I can get ? Should I use lt- interface ?

4)  If I need to put in communication two VR  in the same boz which is
the maximum throughtput I can get ? Should I use import/export ?



If  inside the feedbacks you can provide any reference URL it will be
appreciated.



Cheers

James
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Bedard]

I thought I saw a roadmap blurb about multi-core RPD in 16.x.  I think its a 
considerable amount of work.  

Phil

-Original Message-
From: "Olivier Benghozi" 
Sent: ‎10/‎2/‎2015 8:41 PM
To: "juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] Multi Core on JUNOS?

I have heard that:
1) forget it about PowerPC CPUs (MX 80/104).
2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP 
activated; but I guess that as long as rpd won't be recoded accordingly, it 
won't be any faster.

> Le 2 oct. 2015 à 23:33, Phil Rosenthal  a écrit :
> 
>> On Oct 2, 2015, at 5:11 PM, Colton Conor > > wrote:
>> 
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?
>> 
> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>> 
>>> 
>>> 
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
 
 
 "Statement introduced in Junos OS Release 13.3 R4"
>>> 
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>> 
>>> Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp