Re: [j-nsp] EX4550 version

2013-07-23 Thread Mark Tinka 
On Wednesday, July 24, 2013 06:56:03 AM Ben Dale wrote:

> I pulled one out of the box the other day and whatever it
> shipped with wouldn't bring up 10G DAC cables (Cisco
> branded) and the backlight on the LCD panel didn't work
> (?!!) until I upgraded it (12.3R3), which fixed both
> issues.

Interesting.

I didn't have the LCD panel issue.

We'll probably be looking to upgrade next year, when we roll 
out new kit and take advantage of (what I hope will be) 
newer/stable code at the time.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 version

2013-07-23 Thread Ben Dale 
I pulled one out of the box the other day and whatever it shipped with wouldn't 
bring up 10G DAC cables (Cisco branded) and the backlight on the LCD panel 
didn't work (?!!) until I upgraded it (12.3R3), which fixed both issues.

On 24/07/2013, at 2:49 PM, Mark Tinka  wrote:

> On Wednesday, July 24, 2013 03:27:23 AM Luca Salvatore 
> wrote:
> 
>> Just got a couple of new EX4550 switches... current
>> recommended version is 12.2r2.5 But I just saw tha the
>> 12.2 train is up release 5.3.
>> 
>> Just wondering what the rest of you guys are running  and
>> if you have any horror stories. I'm not doing VC with
>> these guys, they are going to be a pretty simple layer 2
>> aggregation type switch.
> 
> We've been running ours since January this year, and back 
> then, only 12.2R2.4 was available for the chassis.
> 
> Nothing major on our end, just pure Layer 2 aggregation in 
> the core. Haven't seen any problems yet, but our deployment 
> isn't that interesting. I use them mostly for the port 
> speed.
> 
> 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] EX4550 version

2013-07-23 Thread Mark Tinka 
On Wednesday, July 24, 2013 03:27:23 AM Luca Salvatore 
wrote:

> Just got a couple of new EX4550 switches... current
> recommended version is 12.2r2.5 But I just saw tha the
> 12.2 train is up release 5.3.
> 
> Just wondering what the rest of you guys are running  and
> if you have any horror stories. I'm not doing VC with
> these guys, they are going to be a pretty simple layer 2
> aggregation type switch.

We've been running ours since January this year, and back 
then, only 12.2R2.4 was available for the chassis.

Nothing major on our end, just pure Layer 2 aggregation in 
the core. Haven't seen any problems yet, but our deployment 
isn't that interesting. I use them mostly for the port 
speed.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Multipath

2013-07-23 Thread Mark Tinka 
On Tuesday, July 23, 2013 04:34:30 PM Pavel Lunin wrote:

> Yep. This consideration implicitly means that an obvious
> (at the first glance) idea to buy a broader link from a
> cheaper and smaller ISP and a narrower one from a larger
> and usually more expensive ISP is apparently wrong. Very
> frequent mistake enterprise network guys tend to make.

Agree.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4550 version

2013-07-23 Thread Luca Salvatore 
Hi All,

Just got a couple of new EX4550 switches... current recommended version is 
12.2r2.5
But I just saw tha the 12.2 train is up release 5.3.

Just wondering what the rest of you guys are running  and if you have any 
horror stories.
I'm not doing VC with these guys, they are going to be a pretty simple layer 2 
aggregation type switch.

Thanks.

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

Re: [j-nsp] limitation to vrrp-group inheritance on MX?

2013-07-23 Thread Clarke Morledge 

Ben,

Thank you for the explanation.   I verified that it works through some 
testing.


I guess I am just accustomed to the Cisco way of doing things, where you 
can have a whole group of IP subnets on one vlan all sharing the same VRRP 
address, including the facilitating of MAC address learning. In that 
approach, there is no need for having a separate VRRP MAC for each subnet 
on the same vlan.


It just seems inefficient and unnecessary on Juniper's part.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187

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

Re: [j-nsp] SRX devices upgraded to 2GB ram

2013-07-23 Thread Ben Dale 

On 24/07/2013, at 12:53 AM, Pavel Lunin  wrote:

> 
> 22.07.2013 19:09, Gavin Henry wrote:
>> This is the info we got from our supplier in UK who is a Juniper Elite
>> partner:
>> 
>> " It's the same functionality and operation, just comes with 2G memory.
>> It's part of a general refresh of the line that Juniper are doing just now
>> to support future applications."
>> 
>> Not sure how close those applications are. Some more UTM apps?
>> 
> 
> That's true, but there is a caveat (apart from the minimal JUNOS version).
> 
> Although I haven't asked local SE, I'm sure the -H2 models won't cluster with 
> the old SRXes. So people planning to upgrade their already installed SRXes to 
> clusters must either speed up or they will need to buy two boxes instead of 
> one. EoL for old models is 31 Dec 2013 but the channels will obviously hold 
> the new models as soon as they get rid of old stocks.
> 

Not even remotely true - I have a 240H and a 240H2 clustered together on my 
desk right beside me - no issues..  

Unscientifically, the H2 does seem to boot faster so make it your primary when 
you can ; )   

This transition isn't that big a deal - it's happened plenty of times in the 
past.  J-Series with 256MB RAM and flash anyone?

Ben


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

[j-nsp] flow sampling: what packets are chosen?

2013-07-23 Thread chris r. 
Hi guys,

I'm using Juniper hardware to sample traffic and dump it to NetFlow
data. In my config, the sampling rate is 1000, run-length is 0.

According to the docs [1], this means that 1 out of 1000 packets per
flow is sampled. Does this mean that *always* the first (1001st, 2001st,
3001st, ...) packet of a flow is included (as the figure in the docs
suggests) or is the sampling more random?

And if sampling is done more random: Can I miss flows due to packet
sampling, e.g., if flows have fewer than 1000 packets?

Thanks a lot for your help,
Chris

[1]:
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-traffic-sampling.html#id-11354799
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX devices upgraded to 2GB ram

2013-07-23 Thread Pavel Lunin 


22.07.2013 19:09, Gavin Henry wrote:

This is the info we got from our supplier in UK who is a Juniper Elite
partner:

" It's the same functionality and operation, just comes with 2G memory.
It's part of a general refresh of the line that Juniper are doing just now
to support future applications."

Not sure how close those applications are. Some more UTM apps?



That's true, but there is a caveat (apart from the minimal JUNOS version).

Although I haven't asked local SE, I'm sure the -H2 models won't cluster 
with the old SRXes. So people planning to upgrade their already 
installed SRXes to clusters must either speed up or they will need to 
buy two boxes instead of one. EoL for old models is 31 Dec 2013 but the 
channels will obviously hold the new models as soon as they get rid of 
old stocks.



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

Re: [j-nsp] BGP Multipath

2013-07-23 Thread Pavel Lunin 


23.07.2013 16:16, Mark Tinka wrote:

I'm afraid this explanation needs to be expanded a bit.
High LP on the ISP side for customers' routes is a
common practice, but this makes the perpended AS-PATH
(and other BGP attributes) ignored only within the ISP
AS.

Yes, this is true.

However, if your upstream handles a large portion of the
Internet, that's is a reasonable amount of traffic,
particularly if your secondary ISP is not as well-connected
as the other ISP.



Yep. This consideration implicitly means that an obvious (at the first 
glance) idea to buy a broader link from a cheaper and smaller ISP and a 
narrower one from a larger and usually more expensive ISP is apparently 
wrong. Very frequent mistake enterprise network guys tend to make.

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

Re: [j-nsp] BGP Multipath

2013-07-23 Thread Aaron Dewell 
It depends how careful you want to be about it. Multipath and adding the
peer as you've described will get you half traffic on each immediately
which is fine assuming the circuit is good, etc.

If it were me, I'd probably bring up the new one with a different policy
(same group, policy under the neighbor for now) that assigns all prefixes a
lower localpref  than the default (which is 100) or a higher MED (either
will do the same) except a few test prefixes. Make sure bgp comes up, test
those prefixes for a few days, then remove the temporary policy and remove
the peer over GE and multipath at that point.

Either approach is fine. It depends what you are concerned about and what
you want to protect against.
On Jul 18, 2013 5:14 PM, "Keith"  wrote:

> We recently just turned up another connection to one of our upstreams, so
> now we have two. One is a GE the other is a 10GE.
>
> We are getting into new territory here.
>
> The GE connection is in use and working fine.
>
> These two connections home to two different routers on our upstream.
>
> As the BGP policy will remain the same, I was just going to add a new
> neighbour statement to that
> particular BGP group for that upstream.
>
> I was told to also add multipath to that as well if I want to use both
> connections for load balancing.
>
> Don't really want to use both as the GE will be going away sometime, but
> to make sure it works I was
> going to add the new neighbor IP address, make sure BGP comes up and
> traffic is there then remove the old neighbor
> IP address.
>
> Would this be a sensible way to do it?
>
> Thanks.
> __**_
> 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: Re: BGP Multipath

2013-07-23 Thread Mark Tinka 
On Sunday, July 21, 2013 09:40:29 AM Saku Ytti wrote:

> For eBGP this is manageable, as there must already be
> system for per-eBGP session configuration.

To clarify my statement, if the sessions terminated on one 
router, then I'm happy to share the password as having two 
groups becomes another issue.

But if they are on different routers (hopefully to different 
locations), then I can use different passwords per session.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Multipath

2013-07-23 Thread Mark Tinka 
On Monday, July 22, 2013 03:36:28 PM Pavel Lunin wrote:

> I'm afraid this explanation needs to be expanded a bit.
> High LP on the ISP side for customers' routes is a
> common practice, but this makes the perpended AS-PATH
> (and other BGP attributes) ignored only within the ISP
> AS.

Yes, this is true.

However, if your upstream handles a large portion of the 
Internet, that's is a reasonable amount of traffic, 
particularly if your secondary ISP is not as well-connected 
as the other ISP.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp