Re: [j-nsp] Fwd: router recommendation

2010-10-25 Thread Julien Goodwin
On 26/10/10 08:54, Gabriel Blanchard wrote:
> We in fact use a J-6350 at our office and we couldn't even get it to handle a 
> full routing table. (at least not very well).

They handle a full routing table just fine. With the old packet-mode
software they could do a full table (as of January) in 1g of ram.

With flow-mode I've had to up ours to 3GB (above Juniper spec) at which
point they handle three full tables with plenty to spare.

-- 
Julien Goodwin
Studio442
"Blue Sky Solutioneering"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Fwd: router recommendation

2010-10-25 Thread Gabriel Blanchard

On 2010-10-25, at 5:05 PM, Richard Zheng wrote:

> Hi,
> 
> A juniper reseller came back with a suggestion of J-4350. The price is
> similar to a used M7i. I was surprised by this option first. Then
> considering that the application is for a small ISP, it might not be bad.
> The DRAM may be upgraded to 2G which should hold several whole Internet
> tables for quite a while.

Not nearly enough, a J-4350 can handle according to their web site

Firewall and Routing PPS (64 Byte): 225,000 pps
Firewall Performance (Large Packets): 1.6 Gbps

So I wouldn't recommend it.

We in fact use a J-6350 at our office and we couldn't even get it to handle a 
full routing table. (at least not very well).

M7is are probably your best bet which we also have and I recommend in your case.

-Gabe


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


Re: [j-nsp] Fwd: router recommendation

2010-10-25 Thread Joe Hamelin
The big difference is that the J series routes everything through the
Intel CPU.  They do some trick daemon scheduling to get the best
packet rate out of them but it's still a software router.
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474



On Mon, Oct 25, 2010 at 2:42 PM, Keegan Holley
 wrote:
> I've always thought of the J-Series as an enterprise/remote site router and
> not a service provider device.  Strangely enough I can't find the throughput
> ratings on the data sheet, but I'm sure it's lower than the M/MX and the
> like.  I'm not sure if it can handle 2-3G of traffic, you should ask the
> reseller for specs or search juniper.net.  The other thing I noticed was
> that it only supports a max  of 400k BGP routes.  If the full table is 340
> or so that doesn't leave much for L2/L3 vrf's.  Just my 2c.
>
>
> On Mon, Oct 25, 2010 at 5:05 PM, Richard Zheng  wrote:
>
>> Hi,
>>
>> A juniper reseller came back with a suggestion of J-4350. The price is
>> similar to a used M7i. I was surprised by this option first. Then
>> considering that the application is for a small ISP, it might not be bad.
>> The DRAM may be upgraded to 2G which should hold several whole Internet
>> tables for quite a while.
>>
>> Any comment?
>>
>> Thanks,
>>
>>
>>
>> -- Forwarded message --
>> From: Richard Zheng 
>> Date: Thu, Oct 14, 2010 at 8:09 AM
>> Subject: router recommendation
>> To: juniper-nsp@puck.nether.net
>>
>>
>> Hi,
>>
>> I'd like to have some recommendation of a router model. It is for a small
>> ISP. There are 2 or 3 upstreams which feeds the whole Internet routing
>> table. Total about 20 peering sessions. The traffic is about 2-3G in 12
>> months. Right now we only care about Internet. But if it can scale to
>> support layer 2 and/or layer 3 VPN services, that's a big plus.
>>
>> We have dealt with M20 about 4-5 years ago. I am looking at M7i or M10i.
>> Not
>> sure if I am on the right path.
>>
>> Thanks in advance,
>>
>> Richard
>> ___
>> 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] Fwd: router recommendation

2010-10-25 Thread Keegan Holley
I've always thought of the J-Series as an enterprise/remote site router and
not a service provider device.  Strangely enough I can't find the throughput
ratings on the data sheet, but I'm sure it's lower than the M/MX and the
like.  I'm not sure if it can handle 2-3G of traffic, you should ask the
reseller for specs or search juniper.net.  The other thing I noticed was
that it only supports a max  of 400k BGP routes.  If the full table is 340
or so that doesn't leave much for L2/L3 vrf's.  Just my 2c.


On Mon, Oct 25, 2010 at 5:05 PM, Richard Zheng  wrote:

> Hi,
>
> A juniper reseller came back with a suggestion of J-4350. The price is
> similar to a used M7i. I was surprised by this option first. Then
> considering that the application is for a small ISP, it might not be bad.
> The DRAM may be upgraded to 2G which should hold several whole Internet
> tables for quite a while.
>
> Any comment?
>
> Thanks,
>
>
>
> -- Forwarded message --
> From: Richard Zheng 
> Date: Thu, Oct 14, 2010 at 8:09 AM
> Subject: router recommendation
> To: juniper-nsp@puck.nether.net
>
>
> Hi,
>
> I'd like to have some recommendation of a router model. It is for a small
> ISP. There are 2 or 3 upstreams which feeds the whole Internet routing
> table. Total about 20 peering sessions. The traffic is about 2-3G in 12
> months. Right now we only care about Internet. But if it can scale to
> support layer 2 and/or layer 3 VPN services, that's a big plus.
>
> We have dealt with M20 about 4-5 years ago. I am looking at M7i or M10i.
> Not
> sure if I am on the right path.
>
> Thanks in advance,
>
> Richard
> ___
> 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


[j-nsp] Fwd: router recommendation

2010-10-25 Thread Richard Zheng
Hi,

A juniper reseller came back with a suggestion of J-4350. The price is
similar to a used M7i. I was surprised by this option first. Then
considering that the application is for a small ISP, it might not be bad.
The DRAM may be upgraded to 2G which should hold several whole Internet
tables for quite a while.

Any comment?

Thanks,



-- Forwarded message --
From: Richard Zheng 
Date: Thu, Oct 14, 2010 at 8:09 AM
Subject: router recommendation
To: juniper-nsp@puck.nether.net


Hi,

I'd like to have some recommendation of a router model. It is for a small
ISP. There are 2 or 3 upstreams which feeds the whole Internet routing
table. Total about 20 peering sessions. The traffic is about 2-3G in 12
months. Right now we only care about Internet. But if it can scale to
support layer 2 and/or layer 3 VPN services, that's a big plus.

We have dealt with M20 about 4-5 years ago. I am looking at M7i or M10i. Not
sure if I am on the right path.

Thanks in advance,

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


Re: [j-nsp] EX4200: VC "incremental upgrade" ?

2010-10-25 Thread Joe Hamelin
>From what I've seen you might be able to upgrade a VC member but once
it reboots with the new and different image it will no longer be part
of the VC.  So yeah, you can kinda do it but it's not much help over
just pulling the member and doing a stand alone upgrade.  The code has
to match on a VC.
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474



On Mon, Oct 25, 2010 at 6:31 AM, Philipp Geschke  wrote:
> On Mon, 25 Oct 2010 17:10:46 +0400, Alexandre Snarskii 
> wrote:
>> Hi!
>>
>> Silly question: is it possible to perform "incremental upgrade"
>> on ex-series virtual-chassis ? I.e., upgrade some switches
>> (using 'request system software add member NN'), switchover
>> master to 'upgraded' part, then upgrade remaining switches ?
>
> Hi,
>
> no, that is currently not possible.
> You can always take single switches out of the stack and upgrade them
> outside of the stack, however, a hitless upgrade is not really possible.
>
>
> --
> Philipp
>
>
> ___
> 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] EX4200: VC "incremental upgrade" ?

2010-10-25 Thread Philipp Geschke
On Mon, 25 Oct 2010 17:10:46 +0400, Alexandre Snarskii 
wrote:
> Hi!
> 
> Silly question: is it possible to perform "incremental upgrade"
> on ex-series virtual-chassis ? I.e., upgrade some switches
> (using 'request system software add member NN'), switchover
> master to 'upgraded' part, then upgrade remaining switches ? 

Hi,

no, that is currently not possible.
You can always take single switches out of the stack and upgrade them
outside of the stack, however, a hitless upgrade is not really possible.


--
Philipp


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


[j-nsp] EX4200: VC "incremental upgrade" ?

2010-10-25 Thread Alexandre Snarskii

Hi!

Silly question: is it possible to perform "incremental upgrade"
on ex-series virtual-chassis ? I.e., upgrade some switches
(using 'request system software add member NN'), switchover
master to 'upgraded' part, then upgrade remaining switches ? 

Juniper documentation is not so clear on this topic - on one hand we 
have command that allows upgrade of selected chassis member and KB10840 
suggests that "Virtual Chassis software can be upgraded for the entire VC 
or you can upgrade one individual member of the VC", on other - KB16756 
suggests that "for a standalone EX4200 switch to join an existing Virtual 
Chassis configuration, it had to be running the same version of software 
that was running on the Virtual Chassis master" and that since 10.0 master 
switch has ability to "ability to automatically update the software on a new 
member switch so that it can join the Virtual Chassis configuration"
(i.e., in this application fresh upgraded switch will be automatically
downgraded back to the version master running).

Or am I missing something ? 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

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


Re: [j-nsp] SRX for MPLS

2010-10-25 Thread Miroslav Georgiev
I tested everything from mpls, ldp, rsvp, l2vpns, l3vpns, vpls and other 
routing protocols.
There are some limitations for mtu, encapsulations, fragmentation and 
other small but pain in the ass things.
Best thing is to get some (2 or more srx210 or better) and to do your 
tests . After that you will consider buying them.
About security things - if you still need them you can separate the box 
in 2 virtual-routers or something else.


On 10/22/2010 05:54 PM, Paul Stewart wrote:

Has anyone done much l2vpn on them?  I know that's related for sure..;)

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Miroslav Georgiev
Sent: Friday, October 22, 2010 10:05 AM
To: Will McLendon
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX for MPLS

Unfortunately there are some vpls limitations on SRX and J-series
routers. You should check them first.
Besides that everything works.

On 10/22/2010 04:28 PM, Will McLendon wrote:
   

you can definitely do MPLS on J-series and SRX gateways.  It even says so
 

on the datasheet -- however, as was mentioned, you must put the device in
packet-based mode, and thus lose ALL security features (everything that is
configured under [edit security] -- so Zones, Stateful Policies, NAT, etc.
are all not available)
   

to add-on to Tim's comment, you will want to use the command 'delete
 

security' to wipe out that hierarchy, and then enable the packet-based mode:
   

set security forwarding-options family mpls mode packet-based.

there are other statements in that hierarchy to enable packet-based for
 

inet6 etc, but i've never turned that on...just the MPLS statement will turn
it into a regular router..  My main fear for your deployment would be the
environmental conditions.  I don't believe the SRX is specifically hardened
for that kind of environment (that isn't to say it wouldn't work, though).
   

Also, you aren't planning to put an entire BGP table into them are you?
 

I'm not sure how well that would work on the smaller boxes.  I think i've
heard of it being done, but never done it myself so I can't speak to the
stability of such a scenario.
   

Good luck,

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



 

--
Regards,,,
Miroslav Georgiev
SpectrumNet Jsc.
+(359 2)4890604
+(359 2)4890619


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