Re: [j-nsp] QFX5100 System Process SNMP monitor

[Dale Shaw]

Hi Chris,

On Sun, 20 May 2018 at 1:01 pm, Chris Lee via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
> Hi all,
>
> We recently hit a jdhcpd bug in our QFX5100 VC (14.1X53-D30 release) which
> looks to be from the number of defunct zombie processes increasing over
> time leading up to an ungraceful failover of the routing engines.
>
> I have LibreNMS monitoring the QFX and it automagically graphs the running
> process count, but I'm struggling to figure out an SNMP MIB object number
> that gives me the same process count, as I'd like to monitor the same
value
> in our existing PRTG installation to send email/SMS alerts when certain
> thresholds are reached until we can follow JTAC's recommendation to
upgrade
> the QFX release to D46.
>
> I've downloaded the MIB pack from Juniper and tried grepping the files for
> "process" and "processes" but can't seem to find anything relevant.
>
> Anyone familiar with the SNMP on the QFX know where I might find total
> system process count ?

Junos implements HOST-RESOURCES-MIB, so you should be able to poll the
"hrSystemProcesses" object (gauge). Maybe that's how LibreNMS is doing it?

admin@gw> show snmp mib walk hrSystemProcesses
hrSystemProcesses.0 = 125

admin@gw> show system processes summary
last pid: 40910;  load averages:  0.20,  0.19,  0.17  up 29+08:45:43
08:45:48
126 processes: 18 running, 95 sleeping, 1 zombie, 12 waiting
[...]

Cheers
Dale


>
>
> Thanks,
> Chris
> ___
> 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] cheapest juniper router capable of lsys

[Dale Shaw]

Hi Vincent,

On Wed, Jun 28, 2017 at 2:46 AM, Vincent Bernat  wrote:
> The downside of the vMX for experimentation is that it is very CPU
> hungry. The dataplane VMs are using a busy loop to catch packets and
> they will use 100% of the CPU you allocate to them. They also need a lot
> of memory.

For vMX, there is a "lite" flavour of the PFE image that uses DPDK in
interrupt mode instead of poll mode.

See:
https://www.juniper.net/documentation/en_US/vmx15.1f6/topics/task/configuration/vmx-chassis-flow-caching-enabling.html

This option doesn't exist for vSRX yet, AFAIK, but I heard it - or
something similar - is coming.

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

Re: [j-nsp] Reset DSCP on ingress (again)

[Dale Shaw]

Hi Victor,

On Mon, May 29, 2017 at 3:12 PM, Victor Sudakov  wrote:
>
> Dear Colleagues,
>
> Sorry for repeating the question.
>
> What is the easiest method of resetting the dscp value in incoming
> packets when the incoming port is configured for "family
ethernet-switching"?
>
> If the port were in "family inet", I would use the firewall, but the
> "family ethernet-switching" firewall does not seem to have a means to
> set dscp.
>
> Thanks a lot in advance.
>
> The device is EX4200-24T, 12.3R6.6
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> AS43859

Ingress DSCP marking isn't supported on EX4200.

You need to classify (into a FC) on ingress, and rewrite on egress. You can
use a simple fixed classifier on ingress but packet marking/rewrite is only
performed on egress.

Example of a fixed classifier:

# set class-of-service interfaces ge-0/1/0 unit 0 forwarding-class
best-effort

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

Re: [j-nsp] EX4600 : Ping problem

[Dale Shaw]

G'day Doug,

On 29 November 2016 at 11:02, Doug McIntyre <mer...@geeks.org> wrote:
>
> On Tue, Nov 29, 2016 at 10:32:15AM +1100, Dale Shaw wrote:
> >
> > EX4600 runs Enhanced Layer 2 Software (ELS), so it's correct to use
"irb.n"
> > vs. "vlan.n"
> ...
>
> As of JunOS 13.2X51-D25.. If you run the JTAC suggested 12.3 on this
> platform it does not yet use ELS...

13.2X51-D25 was the first Junos release to support EX4600 and as you point
out, it runs ELS. There is no release of Junos 12.3 that supports the
EX4600 platform.

Also, the JTAC recommended release for EX4600 is currently 14.1X53-D35.

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

Re: [j-nsp] EX4600 : Ping problem

[Dale Shaw]

Hi Eduardo,

On 29 November 2016 at 08:35, Eduardo Schoedler  wrote:
>
> Here on EX2200 I put ip address directly in the vlan.
>
> Try this:
>
> set interfaces vlan unit xxx family inet address 10.x.x.x/24
> set vlans vlan-RESEAUX l3-interface vlan.xxx
> set interfaces ge-0/x/x unit 0 family ethernet-switching vlan members
> vlan-RESEAUX

EX4600 runs Enhanced Layer 2 Software (ELS), so it's correct to use "irb.n"
vs. "vlan.n"

I assume Deloin's config was hand-typed because it should be "l3-interface"
rather than "l3.interface". As someone else pointed out, if the link is
point-to-point, only .4 and .5 will be reachable.

xe-0/0/1 is the 2nd (bottom left) interface.

We need some more "show" outputs and/or a complete config to figure out
what's going on.

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

Re: [j-nsp] Recommended firmware for QFX5100-48T

[Dale Shaw]

Hi all,

On 11 Oct 2016 6:23 AM, "Graham Brown"  wrote:
>
> Hi Paul,
>
> Correct, just use 'replace pattern xe-0/0/0 with ge-0/0/0' etc and you
> should be fine.

I don't think that's how it works on qfx5100-48**T**

It's more like copper based EX, where the interfaces are configured as
ge-x/x/x even if they're plugged into something capable of only 10 or
100BASE-T operation.

I seem to recall that there is a trick to making it work that involves
autoneg but I'm currently using a tiny screen and an imaginary keyboard so
digging up the details isn't possible right now.

I'm certain that JTAC could help but I'll try to find something when I'm
properly online.

Cheers,
Dale

> On 11 October 2016 at 07:05, Paul S.  wrote:
>
> > Hi Joel,
> >
> > Thanks for replying.
> >
> > What are the steps to configure the ports as "ge." Do I just get rid of
xe
> > from the config and replace it with ge for that port, that's all?
> >
> >
> > On 10/11/2016 12:21 AM, joel jaeggli wrote:
> >
> >> On 10/10/16 7:34 AM, Paul S. wrote:
> >>
> >>> Hi folks,
> >>>
> >>> Are everyone running the JTAC recommended 14.1X53-D35.3 or have you
> >>> found better stability at some newer revision?
> >>>
> >>> My problem is that the "tri state" 10g ports (copper) don't seem to
> >>> want to run at anything less than 10g. It links up when connected to a
> >>> 1g device, but still claims that the port is operating in 10g mode.
> >>>
> >>> The biggest issue I have is that if I assign a /30 to the p2p
> >>> interfaces (between the qfx and any copper 1g device), my p2p latency
> >>> is somewhere from 10 to 40ms.
> >>>
> >>> I asked around to see if there's any way to force the ports into 1g
> >>> mode, but the "speed" knob is missing. I deliberately turned on
> >>> auto-negotiation, does not seem to help.
> >>>
> >>> 802.3ad LAGs created using any of these links also claim to have
> >>> speeds of 20g/40g when there's in reality only 4g of capacity.
> >>>
> >>> Can someone hit me with a clue stick? Thanks!
> >>>
> >> I presume that you're specifing the port config as ge-0/0/foo rather
> >> than xe-0/0/foo
> >>
> >> joel@ show interfaces ge-0/0/46
> >> Physical interface: ge-0/0/46, Enabled, Physical link is Up
> >>Interface index: 701, SNMP ifIndex: 616
> >>Description:
> >>Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error:
> >> None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
> >> Disabled, Flow control: Disabled, Auto-negotiation: Enabled,
> >>Remote fault: Online, Media type: Copper
> >>Device flags   : Present Running
> >>Interface flags: SNMP-Traps Internal: 0x4000
> >>Link flags : None
> >>CoS queues : 12 supported, 12 maximum usable queues
> >>Current address:
> >>Last flapped   : 2016-08-26 03:31:56 UTC (6w3d 19:46 ago)
> >>Input rate : 0 bps (0 pps)
> >>Output rate: 0 bps (0 pps)
> >>Active alarms  : None
> >>Active defects : None
> >>Interface transmit statistics: Disabled
> >>
> >>Logical interface ge-0/0/46.0 (Index 563) (SNMP ifIndex 617)
> >>  Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2
> >>  Input packets : 146287
> >>  Output packets: 292513
> >>  Protocol inet, MTU: 1500
> >>Flags: Sendbcast-pkt-to-re
> >>Addresses, Flags: Is-Preferred Is-Primary
> >>  Destination:
> >>
> >> joel@> show chassis hardware
> >> Hardware inventory:
> >> Item Version  Part number  Serial number Description
> >> Chassis QFX5100-48S-6Q
> >> Pseudo CB 0
> >> Routing Engine 0  BUILTIN  BUILTIN   QFX Routing
> >> Engine
> >> FPC 0REV 05
 QFX5100-48S-6Q
> >>
> >>  Xcvr 46   NON-JNPR  SFP-T
> >>
> >> joel@> show version
> >> fpc0:
> >> 
> >> --
> >> Hostname:
> >> Model: qfx5100-48s-6q
> >> JUNOS Base OS Software Suite [13.2X51-D38]
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper routing and switch lab support required

[Dale Shaw]

Hi Hitesh,

On 25 August 2016 at 13:40, Hitesh Kumar  wrote:
>
> I am struggling for preparing a Juniper lab for Juniper Routing and
> Switching.
>
> I am using juniper vSRX on VMWare workstation. I am not able to practise
> ethernet switching commands. Need support to get the proper ova file for
> pracising it at home.
>
> I am preparing for JNCIP-ENT exam, which essentially require to get
> practise on box. Please guide me for the same. It would be great help if I
> get some material in any form to prepare for the certification.

The only virtual instantiation of a Juniper switching product is the
vQFX10K:

See: https://github.com/Juniper/vqfx10k-vagrant

You'll need to contact your friendly Juniper SE for a copy of the images,
and right now only VirtualBox is supported.

You could also play with a trial of vMX. Be aware that with both vQFX10K
and vMX, the config syntax does differ slightly to, say, EX4200.

Part (all?) of the reason you won't find anything else is that the other
switching platforms are based on Marvell or Broadcom PFEs, and Juniper is
not as free to distribute virtual editions of those technologies.

Your other option is to pick up a 2nd hand EX-series switch or, depending
on how far you want to go with it, use the Ethernet switching capabilities
of SRX branch series (again, these can be picked up cheaply on the 2nd hand
market). If you have a relationship with Juniper, you might be able to
borrow some gear from your SE until you pass the exam.

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

Re: [j-nsp] 100mbps bandwidth on a logical interface

[Dale Shaw]

Hi Jonathan,

On 3 August 2016 at 16:23, Jonathan Call  wrote:
>
> I have a  Gigabit Ethernet port on an EX4200 that is performing very
poorly. It maxes out at about 120Mbps under heavy load. During that heavy
load I see MAC pause frame values increasing as well as dropped packets in
the queue counters. All of this points to the server being the culprit.
[...]

What output do you see with "show class-of-service interface ge-0/0/27" ?

I assume based on the existence of "ge-0/0/27" that it's a EX4200-48T/P.
Which Junos release are you running? (might help folks match a PR, if there
is one)

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

Re: [j-nsp] vSRX Policy-based VPNs - unsupported platform

[Dale Shaw]

Hi Jed,

On 15 July 2016 at 17:28, Jed Laundry  wrote:
>
[...]
> ##
> ## Warning: configuration block ignored:
> unsupported platform (vsrx)
> ##
> tunnel {
> ipsec-vpn vpn-remote;
[...]
>
> This is vSRX 15.1X49-D40.6 on VMware. It's just the trial version, I
> haven't bought a licence yet.

According to the release notes, policy-based VPN support was
(re-)introduced from 15.1X49-D50.

See:
http://www.juniper.net/techpubs/en_US/junos15.1x49-d50/information-products/topic-collections/release-notes/15.1x49-d50/junos-release-notes-15.1X49-D50.pdf

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

Re: [j-nsp] SRX 1500

[Dale Shaw]

Hi,

On Saturday, 28 May 2016, Timothy Creswick  wrote:

>
> We've been talking to Juniper about the explosion of part numbers that you
> now have to order to get a SRX1500. Apparently there will be some bundles
> coming out later in the year which make this simpler, but right now you'd
> need to order the main SKU, plus a rack mount kit, plus power supplies,
> plus support for the chassis, JUNOS software and then support for the
> software.
>
> We could 6 part numbers as the minimum to get a working box (i.e. these
> are required). As noted above, the list price for the basic JUNOS software
> (SRX1500-JSE) is the same as for the box itself (SRX1500-AC).


To get the hardware (incl. rack kit and one PSU), you order SRX1500-AC. To
get Junos (currently only one option, "JSE") you order SRX1500-JSE.

Yes, there are now separate support SKUs for hardware and software.

It'd be 5 line items if you wanted a redundant PSU.

Partners can use solutionbuilder.juniper.net to build bills of materials.

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

Re: [j-nsp] SRX 1500

[Dale Shaw]

Hi,

On Friday, 20 May 2016, Maxwell Cole  wrote:
>
>
> Has anyone used box yet?

[...]


> It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
> and 86x running Junos 15 at 11k msrp.


srx1500 uses the new disaggregated software model, so it's $11K for
hardware only; you still need to buy software (Junos).

It's a really nice box to use -- really snappy RE. I didn't get to use it
"in anger" but the form factor is great.

Xeon + crypto co-pro + FPGA

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Dale Shaw]

Hi James,

On 28 Apr 2016 1:46 AM, "James Bensley"  wrote:
[...]
> Any info and help with getting all interfaces returned when polling
> from within a routing instance would be appreciated.

My memory's a bit hazy on this, but do you see everything you want to see
if you prefix the community string with a "@" in your cacti config?

(e.g. if the string is "public", try configuring cacti to use "@public")

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

Re: [j-nsp] EX series questions

[Dale Shaw]

Hi Joe,

On 23 Apr 2016 10:36, "joe mcguckin"  wrote:
>
> Do Ex2200, EX3300, etc run the same image? Can I use a 3300 snapshot to
recover a 2200 that won’t boot?

No, EX2200 and EX3300 use different images.

What's the problem with your switch(es)?

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

Re: [j-nsp] vMX for ESXi

[Dale Shaw]

Hi again,

On Tuesday, 5 January 2016, Robert Hass  wrote:

But still TGZ package doesn't have files which I'm looking and above guide
> referring them - *.vmdk files :(


Please check again -- the ESXi packages have now been posted.

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

Re: [j-nsp] vMX for ESXi

[Dale Shaw]

Hi Robert,

On Tuesday, 5 January 2016, Robert Hass  wrote:

> Hi
>
> I'm looking for any scheduled release date for vMX (Virtual MX) for VMware
> ESXi platform ?


ESXi support was introduced in vMX release 15.1F4.

http://www.juniper.net/techpubs/en_US/vmx15.1f4/information-products/topic-collections/release-notes/jd0e52.html#jd0e52

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

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Dale Shaw]

Hi Chuck,

On Sat, Dec 12, 2015 at 4:16 AM, Chuck Anderson  wrote:
>
> Here are some commercial NMS products that we've looked at that we
> would like to get working with our Juniper gear:
>
[...]
> Statseeker's MAC/IP/Switch Port Table report
[...]

This works already, from v3.7.x or possibly v3.8 and newer, if memory
serves.

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

Re: [j-nsp] SNMP OID for CPU temperature

[Dale Shaw]

Hi Rajendra,

On Tue, Dec 1, 2015 at 5:20 PM, Rajendra Maharjan <
rajendra.mahar...@subisu.net.np> wrote:
>
> Is there any SNMP oid that can return value of CPU temperature rather
than RE temperature. I know there is an oid for RE temperature but it would
be very beneficial if I could get CPU temperature value too. Searching
through juniper docs didn't help me either. We may workout with script too
but getting direct OID would be gorgeous.
[...]

I don't have an EX Virtual Chassis handy to test these commands on but
maybe this helps?

dale@ex2200> show snmp mib walk jnxOperatingDescr
jnxOperatingDescr.1.1.0.0
jnxOperatingDescr.2.1.1.0 = Power Supply: Power Supply 0 @ 0/0/*
jnxOperatingDescr.4.1.1.1 = FAN: Fan 1 @ 0/0/0
jnxOperatingDescr.4.1.1.2 = FAN: Fan 2 @ 0/0/1
jnxOperatingDescr.7.1.0.0 = FPC: EX2200-24T-4G @ 0/*/*
jnxOperatingDescr.8.1.1.0 = PIC: 24x 10/100/1000 Base-T @ 0/0/*
jnxOperatingDescr.8.1.2.0 = PIC: 4x GE SFP @ 0/1/*
jnxOperatingDescr.9.1.0.0 = Routing Engine 0

{master:0}
dale@ex2200> show snmp mib walk jnxOperatingTemp
jnxOperatingTemp.1.1.0.0 = 0
jnxOperatingTemp.2.1.1.0 = 0
jnxOperatingTemp.4.1.1.1 = 0
jnxOperatingTemp.4.1.1.2 = 0
jnxOperatingTemp.7.1.0.0 = 31 <-- temperature of FPC
jnxOperatingTemp.8.1.1.0 = 0
jnxOperatingTemp.8.1.2.0 = 0
jnxOperatingTemp.9.1.0.0 = 31 <-- temperature of RE

jnxOperatingTemp.7.1.0.0 == .1.3.6.1.4.1.2636.3.1.13.1.7.7.1.0.0

In a VC, you should see jnxOperatingTemp.7..0.0 being populated
with the per-FPC temperature value.

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

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Dale Shaw]

Hi Aaron,

On Tue, Nov 24, 2015 at 6:58 AM, Aaron  wrote:
>
[...]
> p.s. besides, bringing up l2vpn AF on the 5048 and 104 , as I understand
it, SHOULD NOT, cause any other PE's to renegotiate capabilities and AF's
on their bgp neighbor sessions with the RR.

What is your RR platform?

The outage sounded .. painful .. but the common denominator is the RR.

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

Re: [j-nsp] hw support by upcoming Junos

[Dale Shaw]

Hi James,

Junos 15.1X49 and newer isn't supported on an SRX5K with the modules you
have.

You should try to move up to Junos 12.3X48 to give you more support runway.

Cheers,
Dale

On Tuesday, 8 September 2015, james list  wrote:

> Hi folks,
> my customer has the following SRX HE box with Junos 12.1x44
>
>
> SRX5800BASE-AC
> SRX5800-PWR-AC
> SRX5K-IDP
> SRX5K-SCB
> SRX5K-RE-13-20
> SRX5K-SPC-2-10-40
> SRX5K-FPC-IOC
> SRX-IOC-16GE-TX
>
>
>
> I'm wondering if there is a way to be sure everything will be supported
> until 2020 when our contract expires...
>
> I see 12.1x44 has EOL in 7/2016, but I miss how to be sure all the
> mentioned hw is supported with Junos 12.3/15.1 and following...
>
> In the release notes I see:
>
> "Hardware Compatibility - To obtain information about the components that
> are supported on the device, and special compatibility guidelines with the
> release, see the SRX Series Hardware Guide."
>
> On the Hardware Guide is basically writter "support starting from 9.2/10 or
> later" nothing more detailed.
>
> Any help is 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] Log Message

[Dale Shaw]

Hi Mohammad,

On Thu, Jun 11, 2015 at 4:32 PM, Mohammad Khalil eng.m...@gmail.com wrote:

 I have mx480 in place and I am having the below log messages

 Jun  8 18:23:10  CR01-A fpc5 NH: Failed to find nh (1657) for deletion
 Jun  8 18:23:10  CR01-A fpc5 NH: Failed to find nh (1629) for deletion
[...]

Please tell us which Junos you are running and what type of card is in FPC
slot 5.

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

Re: [j-nsp] JTAC Recommended Junos Software Versions Old?

[Dale Shaw]

Hi Colton,


On Tue, May 12, 2015 at 10:35 AM, Colton Conor colton.co...@gmail.com
wrote:

 So what is going to be the next recommended JTAC version after 12.3R8.7?

The recommended release for most MX platforms changed the other day, to
13.3R6.

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

Re: [j-nsp] SRX1400 packet mode ?

[Dale Shaw]

Hi Brijesh,

On Tue, Apr 28, 2015 at 8:49 PM, Brijesh Patel brju.pa...@gmail.com wrote:

 *Can SRX1400 work as packet mode ? *

No, it can't -- not for IPv4, and MPLS is not supported at all.

See also:
https://puck.nether.net/pipermail/juniper-nsp/2014-December/029776.html

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

Re: [j-nsp] SRX High-end Packet mode

[Dale Shaw]

Hi Mahmoud,

On Thu, Dec 18, 2014 at 4:34 AM, M Abdeljawad via juniper-nsp 
juniper-nsp@puck.nether.net wrote:

 I have three questions about packet mode on high-end SRX firewalls
 - Is it supported on SRX high-end firewalls to switch the firewall to
packet mode altogether using the below command which supported on branch
firewalls;(set security forwarding-options family mpls mode packet-based)
 - Is it supported on SRX high-end firewalls to partially convert some
traffic to packet mode (selective packet forwarding using filters)?
 - Is it possible to operate MPLS on SRX high-end firewalls without
enabling packet-mode?

Packet mode is not supported on HE SRX at all. Neither is MPLS.

Comparison of features supported on SRX650 with SRX5600:
http://pathfinder.juniper.net/feature-explorer/compare-platforms.html?swName=Junos+OStyp=1#bm=cmphwpl1=SRX650pl2=SRX5600rel=12.1X46-D25

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

Re: [j-nsp] Limitations of MPLS support on EX4200

[Dale Shaw]

Hi Victor,

On Thu, May 1, 2014 at 5:15 PM, Victor Sudakov v...@mpeks.tomsk.su wrote:

 Is MPLS support on EX4200 not complete? It is not a router after all,
 it is an L3 switch, so I expect there to be limitations.
 Where can I read more about EX4200 MPLS limitations and supported
features?

This may help; see:

http://www.juniper.net/techpubs/en_US/release-independent/nce/information-products/topic-collections/nce/nce0115-mpls-switching-faq/mpls-switching-frequently-asked-questions.pdf

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

Re: [j-nsp] Does EX4200 support changing TCP-MSS on transit packets?

[Dale Shaw]

Hi Mark, all,

On Mon, Feb 24, 2014 at 11:37 PM, Mark Tinka mark.ti...@seacom.mu wrote:

 On Monday, February 24, 2014 02:18:35 PM Saku Ytti wrote:

  I think you're mixing system level setting and interface
  level setting. When configured in interface it indeed
  mangles transit packets. When in system level it affects
  local when interface it affects transit. IIRC JunOS does
  not support interface-level 'stateless' mangling, but
  will only do it in FW via flows.

 Yes, that's what I meant - a la Cisco's ip tcp adjust-mss,
 which is, as you say, normally used fix-up weird MTU
 problems that are native to tunnels.

 I haven't heard of Junos having this on interfaces. But yes,
 agree Trio should be able to. Possibly worth someone
 submitting and ER for this.

It's possible to manipulate TCP MSS on M/MX with a services card.

e.g.
[MX] How to modify the TCP MSS on the CE facing interface
http://kb.juniper.net/InfoCenter/index?page=contentid=KB24352

On SRX (branch), it's much like ip tcp adust-mss (set under '[edit
security flow]') but it's a global setting and AFAIK the adjustment takes
place only on SYNs and only on *ingress* - fine for all native IP
interfaces but not as useful when traffic is landing on an interface
encapsulated/labeled.

OP: There is no such knob on EX-series to the best of my knowledge.

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

[j-nsp] Steel-Belted RADIUS backups

[Dale Shaw]

Hi all,

Does anyone out there use SBR?

We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux.

I'm putting something in place to back up SBR itself; currently we
just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's
occurred to me that we have never tested a recovery using this method.

JTAC are telling me there is no automated way to perform the XML
export function normally performed in the GUI. The product docs don't
make it clear whether taking a copy of everything in
/opt/JNPRsbr/radius/ is enough, or whether the XML export is also
required.

Looking at what the supplied install/upgrade scripts do, it's just a
recursive 'cp' with some unnecessary folders excluded.

We also take backups of the VM guest that's running SBR but I'm not
familiar enough with SBR's back-end databases to know whether that
results in a recoverable data set; there'll be open files for sure
(hence the stop;tar;start method described above).

What do you do?  use FreeRADIUS instead is a valid but unwelcome response :-))

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

[j-nsp] Filter-based VLAN membership

[Dale Shaw]

Hi all,

I'm exploring the possibility of using filter-based VLAN membership on
our EX4200 edge switches.

The desktop/end-user folks are looking at using Microsoft's MED-V
platform to support legacy apps on a new Windows 7-based SOE. From
what I can tell, MED-V is basically an instance of Windows XP running
in Virtual PC.

The desktop guys are telling me that dot1q-tagging the traffic from
the VM isn't supported, nor can they cope operationally with NAT
between the guest and host, so I'm looking at other options for
separating this traffic, if for no other reason than to avoid the need
to re-design the IP addressing plan to support larger subnets.

There doesn't seem to be a lot of documentation out there about this
feature but in playing around in the lab I have encountered a
constraint that may be a showstopper for me. It doesn't seem as though
a L2 VLAN can be defined with both a mapping policy statement and an
RVI attached (l3-interface).

Does that mean that filter-based VLAN membership can only be
configured on L2-only switches? We have a number of offices where
individual floors/levels are fed via L3/routed uplinks, so there are
lots of RVIs defined on edge switches.

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

Re: [j-nsp] J/SRX ICMP handling

[Dale Shaw]

Hi all,

Just tying up a loose end here --

After lots of to-and-fro with the JTAC (partially due to me getting
sidetracked with other things), I confirmed with them that the SRX
will drop ICMP response packets if the SRX did not forward the packet
that ultimately triggered the ICMP response. This behaviour can not be
influenced by security policy.

Reference PRs:

PR881586 (not public; relates to the set security idp
sensor-configuration flow allow-icmp-without-flow command)
PR818695

There is a VTY command that can influence this behaviour:

 start shell user root
 vty fwdd
 set usp flow allow-embed-icmp enable

I'm told that the command can apply on J-series, SRX branch and SRX
high-end but I'm assuming the syntax might be different in some cases.
Requires JUNOS 10.4R13, 11.4R7, 12.1R5, or 12.1X44-D10

I did not test the workaround as it is not persistent across reboots
and therefore isn't really manageable in my environment. As a result,
I didn't push the JTAC for a thorough explanation of what the command
actually does.

JTAC suggested working with my SE to get an Enhancement Request (ER)
raised, if we decided we really needed a config knob for this. I must
say I find it strange that commands like set security flow
allow-dns-reply exist while similar commands for ICMP handling do
not.

Cheers,
Dale

On Thu, Apr 25, 2013 at 3:23 PM, Dale Shaw dale.shaw+j-...@gmail.com wrote:

 Hi all,

 This post relates to a previous post of mine on asymmetrically routed
 UDP traffic:
 https://puck.nether.net/pipermail/juniper-nsp/2012-December/024878.html

 It seems as though a J/SRX in flow mode will drop ICMP packets such as
 unreachable and ttl-exceeded if, after consulting the session table,
 an entry corresponding to the header embedded in the ICMP packet is
 not found. In other words, I'm gonna drop any ICMP packets[1] I see
 if I didn't handle the associated conversation.

 Assume I send a UDP packet between hosts A and D and it's routed
 outbound via SRX B, and for whatever reason an ICMP unreachable or
 ttl-exceeded is generated (think traceroute). If that ICMP packet is
 sent towards host D not via SRX B but via SRX C, SRX C drops
 it:

 (src/dst IPs replaced with A and D)
 Jan 23 14:53:45 14:53:44.938394:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
 st0.1033:D-A, icmp, (3/3)
 Jan 23 14:53:45 14:53:44.938424:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
 find flow: table 0x63ce7688, hash 494060(0x7), sa D, da A, sp
 33438, dp 47488, proto 17, tok 7
 Jan 23 14:53:45 14:53:44.938483:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
 packet dropped, no session found for embedded icmp pak
 Jan 23 14:53:45 14:53:44.938495:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
 flow find session returns error.

 Seems like perfectly reasonable behaviour for a firewall, right?
 Right, except when it's not :-)

 Can this behaviour be modified without fully or selectively running in
 packet mode? I'm running JUNOS 10.4R11.

 Cheers,
 Dale

 [1] Well, any ICMP packets that include a copy of the original
 datagram's header: echo request/reply are forwarded (subject to being
 permitted by security policy, of course).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper EX4550

[Dale Shaw]

Hi Suginto,

On Mon, May 13, 2013 at 1:19 PM, Suginto Hung suginto.h...@gmail.com wrote:

 For juniper EX4550-32F, Does it support mix port between 1g and 10g?
 Or we must choose 10g or 1g?

 I have difficulty to find about this information.

If you insert a 1g transceiver, a ge interface will appear. If you
insert a 10g transceiver, a xe interface will appear.

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

[j-nsp] Maximum IPsec (st0) tunnels for SRX-series

[Dale Shaw]

Hi all,

Just looking for some real-world experience with the maximum practical
number of IPsec tunnel (st0) interfaces supported on SRX-series --
everything from low end/branch up to high end.

The data sheets say:

SRX100: 128
SRX110: 128
SRX210: 256
SRX220: 512
SRX240: 1,000
SRX550: 2,000
SRX650: 3,000
SRX1400: ?
SRX3x00: 7,500
SRX5x00: 15,000

Those are some pretty hefty numbers as you move up the product family
but as we all know, sometimes data sheets are pure fantasy, dreamt up
by sales/marketing types after lavish and expensive liquid lunches.

I just wanted to know if anyone's seen control planes turn into molten
goop trying to wrangle, say, 100-150 tunnels.

(I'm not worried about forwarding performance as all I'm looking at
doing is fully-meshing an existing enterprise WAN where the SRX boxen
are doing a great job shuffling packets (er, I mean flows) around.)

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

Re: [j-nsp] Maximum IPsec (st0) tunnels for SRX-series

[Dale Shaw]

Hi Ben,

On Mon, May 6, 2013 at 10:33 AM, Ben Dale bd...@comlinx.com.au wrote:
 As long as your tunnels don't breach the IPSEC Throughput numbers, you should 
 be right™.

 I have a few SRX240s out there with upwards of 500 tunnels on them, some 
 dynamic routing (3 core sites only), and they're sitting at around 50% CPU.  
 They're all running DPD with intervals of 10 and 3 (which I think is as low 
 as you can go).

That's a good point. I'll want to run OSPF over all tunnels, so it's
not just IPsec/IKE that'll be wanting control plane resources.

The biggest branch SRX I've currently got with the most tunnels is a
pair of SRX650s with 40 tunnels each (all w/OSPF p2p adjacencies,
albeit with default timers). Control plane CPU sits steady at 20% all
day. An SRX240 with only 12 tunnels sits at 40% but I recall this
being normal due to some strange control plane utilisation metric
due to the way flowd works on these boxes.

Cheers,
Dale

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

Re: [j-nsp] J/SRX ICMP handling

[Dale Shaw]

Hi Klaus,

On Thu, Apr 25, 2013 at 4:44 PM, Klaus Groeger kla...@gmail.com wrote:

 set security flow allow-icmp-without-flow

This doesn't seem to be a valid command - at least not on 10.4R11. I
couldn't find a reference in the documentation either.

The closest I can find is security idp sensor-configuration flow
allow-icmp-without-flow, but I'm not using IDP.

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

[j-nsp] J/SRX ICMP handling

[Dale Shaw]

Hi all,

This post relates to a previous post of mine on asymmetrically routed
UDP traffic:
https://puck.nether.net/pipermail/juniper-nsp/2012-December/024878.html

It seems as though a J/SRX in flow mode will drop ICMP packets such as
unreachable and ttl-exceeded if, after consulting the session table,
an entry corresponding to the header embedded in the ICMP packet is
not found. In other words, I'm gonna drop any ICMP packets[1] I see
if I didn't handle the associated conversation.

Assume I send a UDP packet between hosts A and D and it's routed
outbound via SRX B, and for whatever reason an ICMP unreachable or
ttl-exceeded is generated (think traceroute). If that ICMP packet is
sent towards host D not via SRX B but via SRX C, SRX C drops
it:

(src/dst IPs replaced with A and D)
Jan 23 14:53:45 14:53:44.938394:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
st0.1033:D-A, icmp, (3/3)
Jan 23 14:53:45 14:53:44.938424:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
find flow: table 0x63ce7688, hash 494060(0x7), sa D, da A, sp
33438, dp 47488, proto 17, tok 7
Jan 23 14:53:45 14:53:44.938483:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
packet dropped, no session found for embedded icmp pak
Jan 23 14:53:45 14:53:44.938495:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
flow find session returns error.

Seems like perfectly reasonable behaviour for a firewall, right?
Right, except when it's not :-)

Can this behaviour be modified without fully or selectively running in
packet mode? I'm running JUNOS 10.4R11.

Cheers,
Dale

[1] Well, any ICMP packets that include a copy of the original
datagram's header: echo request/reply are forwarded (subject to being
permitted by security policy, of course).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Directed/targeted broadcast on EX-series

[Dale Shaw]

Hi all,

I'm looking at enabling targeted broadcasts on specific edge VLANs to
support Wake-on-LAN.

It looks like there aren't any knobs to control the behaviour:

admin@switch# set interfaces vlan unit 100 family inet targeted-broadcast ?
Possible completions:
  [Enter]Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  |Pipe through a command
{master:0}[edit]

Is there any way to control which source IPs can send targeted
broadcasts, or is it as it seems -- i.e. that it's all or nothing?

The forward-and-send-to-re and forward-only knobs to control
forwarding aren't there on my JUNOS EX boxes. Does anyone know what
the behaviour is on EX-series?

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

Re: [j-nsp] port mirror on EX causing crash

[Dale Shaw]

Hi Luca,

On Wed, Apr 10, 2013 at 2:50 PM, Luca Salvatore l...@ninefold.com wrote:

[...]
 I have an EX4200 10.4r5.5, a few hours after turning on port mirroring  the 
 switch crashed.  It threw some memory parity errors which JTAC tells me means 
 the switch is faulty and should be replaced.

 The switch in question has been running fine for 3 years, but turning on a 
 ingress and egress port mirror (on a single port) seems to make the switch 
 have a bad day.  The switch isn't busy, and the port that I'm mirroring has 
 about 80 to 100Mb of traffic.  I'm mirroring the port to an IDS and would 
 like to keep it running for the foreseeable future.
[...]

FWIW, I have lots of EX4200s with analyzers running 10.4R6 (not R5)
and have never seen this problem. Sounds like a hardware thing.

Cheers,
Dale

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

Re: [j-nsp] single ip on two interfaces

[Dale Shaw]

Hi Mark,

On Wed, Mar 6, 2013 at 8:09 AM, Mark Jones mjo...@mnsi.net wrote:
 Is it possible to have the same ip accessible via two interfaces the same
 way you would on a server.  This is on an mx series router.

What do you mean when you say ..the same way you would on a server ?

Assigning the same IP address to separate interfaces (logical or
physical) is usually wrong, unless each interface is in a separate
routing instance/VRF.

Can you describe your scenario?

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

[j-nsp] EX-series POWER-ETHERNET-MIB traps - which category?

[Dale Shaw]

Hi all,

I feel like I should have been able to find the answer to this myself
but I haven't been able to dig anything up.

Which SNMP trap *category* in JUNOS includes the three
POWER-ETHERNET-MIB (RFC3621) traps?

[1] pethPsePortOnOffNotification
[2] pethMainPowerUsageOnNotification
[3] pethMainPowerUsageOffNotification

References/pointers welcome!

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

Re: [j-nsp] EX-series POWER-ETHERNET-MIB traps - which category?

[Dale Shaw]

Hi Ben,

On Thu, Feb 21, 2013 at 1:00 PM, Ben Dale bd...@comlinx.com.au wrote:

 Which SNMP trap *category* in JUNOS includes the three
 POWER-ETHERNET-MIB (RFC3621) traps?

 [1] pethPsePortOnOffNotification
 [2] pethMainPowerUsageOnNotification
 [3] pethMainPowerUsageOffNotification

 Couldn't find any doco, but a quick test in the lab shows that category 
 chassis picks up all three.

 Just make sure you've got PoE notification enabled:

 set poe notification-control fpc 0

 or you won't see anything.

You are a gentleman and a scholar! Thanks.

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

Re: [j-nsp] Junos 12.3 Release Date

[Dale Shaw]

On Thu, Feb 7, 2013 at 12:03 PM, Rajesh Narang nar...@juniper.net wrote:

 It is a documentation error that is being corrected and link will be updated 
 soon.

Updated:
http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series-software-licenses-overview.html

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

Re: [j-nsp] [SRX650] show pfe statistics weirdness

[Dale Shaw]

Hi Graham,

On Wed, Nov 14, 2012 at 11:16 PM, Graham Brown
juniper-...@grahambrown.info wrote:

 This is where the SRX platform differs from that of the M/T/MX etc. BFD
 processing is NOT offloaded to the PFEs - this is all done by the RE. This
 has caused one of my customers many problems and unfortunately is by design
 - this relates to the SRX 3600.

Hmmm, this sounds .. a bit crap. Did you find any docs on this? I'm
having trouble finding useful references.

I have a network of J and SRX boxes -- everything from J2320 up to
SRX5800 -- and I'd like to run BFD for OSPF (on IPsec tunnels). Our
data centre routers (the srx5ks) have about 100 tunnels each, so I'd
need 100 BFD sessions.

How many BFD sessions was your customer running, and was it actually
causing a problem? (high RE/control plane processor utilisation, I
guess?)  Did you end up using BFD anyway, or tuning the IGP, or .. ?

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

Re: [j-nsp] juniper cisco switch interconnection

[Dale Shaw]

Hi Patrick,

On Tue, Dec 11, 2012 at 8:20 AM, Patrick Dickey dickeypj...@yahoo.com wrote:
 Just a quick note: if you need multiple vlan STP (like what PVST+ has...),
 use VSTP on the Juniper. Ensure that VLAN 1 is on any trunk line between the
 Cisco and the Juniper. You don't need to have traffic there, but PVST+ uses
 VLAN 1 and VSTP will listen on VLAN 1 for STP information. If it's not
 configured, all kinds of strangeness occurs.

Your comment reminded me of some VSTP strangeness I'd seen previously.

Do you know if VSTP wants VLAN 1 even in a pure Juniper environment?
Or is this only required for Cisco PVST+ interop?

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

[j-nsp] SRX, UDP traffic, routing asymmetry

[Dale Shaw]

Hi all,

I'm at the start of troubleshooting a strange problem we've
experienced recently with voice signalling (UNIStim) traffic.

Our WAN is based upon a carrier L3VPN but we build IPsec tunnels
(st0.x) over the top and we do not have a full mesh. The end result is
that traffic between branch sites needs to hair-pin on an
intermediate device (a J or SRX box).

Sometimes (due to OSPF's route selection process when presented with
equal cost routes) the path traffic takes from A to B is not the
same as the path from B to A -- the intermediate device to
hair-pin on (for A-B and B-A) is different. In performance terms,
the difference is insignificant. Most of the time the intermediate
devices are sitting next to each other in a rack (e.g. primary and
secondary routers).

Does the SRX do something special with asymmetric UDP flows? When I
say UDP I mean UDP generically, because I'm aware of special cases
like set security flow allow-dns-reply. I have an ever-growing
suspicion that we are throwing packets on the floor in certain
circumstances.

cheers,
Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Ethernet switching/bridging on SRX High-End

[Dale Shaw]

Hi all,

I'm trying to find a way to use an srx3400 as an intermediate box to
provide L2 connectivity between a couple of EX switches and a J2320.
This is just a short-term arrangement to get me out of a bind. If I
can't do it, it's not a big deal, I'll dig up a 3rd switch.

Essentially I want to use the srx3400 as a basic switch, so that the
two EX switches' uplinks and the J's LAN-facing port are in the same
broadcast domain. I want to use three ge- interfaces to accomplish the
task.

[SRX]--[J2320]
/   \
   / \
  |   |
[EX1]   [EX2]


The obvious feature seems to be bridge-domains (as
ethernet-switching isn't supported on SRX-HE) but it doesn't look
like I can run it if the SRX is in 'route mode'.

I'm running JUNOS 10.0R4 on the SRX.

Clues?

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

[j-nsp] Analyser output interfaces - drops, CoS, loss-priority etc.

[Dale Shaw]

Hi all,

Has anyone found a solid config for EX-series analyser output
interfaces to reduce the likelihood of drops?

We have a bunch of network performance probes attached to our network
and slowly but surely I'm fine-tuning the EX interface and analyser
configs in an attempt to eliminate unnecessary drops. A couple of
questions:

- Is there a 'best practice' for CoS config (scheduler-map, mainly)
for analyser output interfaces? I don't really want any fancy queueing
on these ports.
- In the context of an analyser session, is loss-priority low (the
default) the best bet? Or high? I can't find any good references on
this - any KB articles either talk about VLANs as outputs (not
physical interfaces) or loss-priority is set to high in the example
without any explanation.

More generally, has anyone gone to the trouble of tuning NICs in
probes/analyser targets? I would be grateful for any advice there,
too. Flow control seems to be an obvious one to disable in the 'send'
direction (from the probe's perspective).

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

Re: [j-nsp] EX4500 - 3rd party DAC/Twinax cable support - link-up at 1g instead of 10g

[Dale Shaw]

Hi all,

Just following up on this post from April. My customer followed
through with JTAC and eventually it was determined that, while active
DAC cable support was planned for introduction in JUNOS 12.1, it
didn't actually make it.

References to active DAC cable support disappeared from various
documents in late May (12.1 release notes, etc.)

JTAC said: The Active DACs that are coming for EX's will be first
supported on the EX8200's and could be coming next release.

cheers,
Dale

On Sun, Apr 29, 2012 at 12:43 PM, Dale Shaw dale.shaw+j-...@gmail.com wrote:
 Hi all,

 I have a customer that is trying to connect some ESX hosts at 10g to a
 recently commissioned EX4500 VC.

 Their ESX hosts are IBM servers, and they were supplied with the
 following DAC cables:

 Cable: IBM Twin-ax Active Cable 5M, PN: 45W3039
 Cable labelled as: Brocade 10G Active 5M FCoE, 58-123-01

 The (two-member) EX4500 VC is running JUNOS 12.1R1 (mostly due to this
 release being the first to officially support active DAC cables).

 The EX4500 detects the interface when plugged into an SFP+ slot but
 the line speed/link-up speed is 1g (ge-*), not 10g (xe-*). Note there
 are no uplink modules installed; we're going directly into the
 built-in ports.

 Other info:
 ESX Version: ESX 4.1.0 Build 582267
 Adapter Model: IBM 42C1801
 ESX networking driver: qlgc-qlge-1.0.0.45-100.27-offline_bundle-418618

 Has anyone experienced this before? JTAC didn't provide much insight,
 other than to try a Juniper branded cable (e.g. EX-SFP-10GE-DAC-5m or
 EX-SFP-10GE-ACT-5M). So, that's our next step.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] JUNOS/EX-series gripe - mirror/analyse before rewrite

[Dale Shaw]

Hi,

whine mode: on

Why oh why, in the name of the gods of Junos, is mirror/analyse done
before DSCP rewrite?
(aka why oh why is DSCP rewrite done on egress?)

..there's probably a really good architectural reason but jeez, it
doesn't help when you have some brain-dead endpoints that can't make
their own traffic and your network performance probe (attached to the
same switch) reports on packet marking/QoS.

whine mode: off

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

[j-nsp] IPv6 protocol support for SRX ADSL2 PIC

[Dale Shaw]

Hi all,

The last time this came up on the list[1], almost a year ago, JTAC was
quoted as saying 'family inet6' support isn't coming to JUNOS until
13.2R1.

In the past ~11 months, has anyone received any different (read: better) advice?

cheers,
Dale

[1] https://puck.nether.net/pipermail/juniper-nsp/2011-July/020574.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] IPv6 protocol support for SRX ADSL2 PIC

[Dale Shaw]

Argh..

On Sat, May 26, 2012 at 12:30 PM, Dale Shaw dale.shaw+j-...@gmail.com wrote:

 The last time this came up on the list[1], almost a year ago, JTAC was
 quoted as saying 'family inet6' support isn't coming to JUNOS until
 13.2R1.

This is meant to say ..'family inet6' support isn't coming for the
ADSL2/2+ mini-PIM (SRX-MP-1ADSL2-A) for SRX2x0 until JUNOS 13.2R1.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Document Update - EX Features

[Dale Shaw]

Hi Skeeve,

On May 4, 2012 2:24 PM, Skeeve Stevens skeeve+juniper...@eintellego.net
wrote:

 Does anyone know who we hassle to get a document updated?

 Specifically:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html

 With the EX2500's in it.

What update are you after?

The EX2500 doesn't run JUNOS, if that's why you were suggesting the doc
needed an update.

Cheers,
Dale

 *Skeeve Stevens, CEO*
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4500 - 3rd party DAC/Twinax cable support - link-up at 1g instead of 10g

[Dale Shaw]

Hi all,

I have a customer that is trying to connect some ESX hosts at 10g to a
recently commissioned EX4500 VC.

Their ESX hosts are IBM servers, and they were supplied with the
following DAC cables:

Cable: IBM Twin-ax Active Cable 5M, PN: 45W3039
Cable labelled as: Brocade 10G Active 5M FCoE, 58-123-01

The (two-member) EX4500 VC is running JUNOS 12.1R1 (mostly due to this
release being the first to officially support active DAC cables).

The EX4500 detects the interface when plugged into an SFP+ slot but
the line speed/link-up speed is 1g (ge-*), not 10g (xe-*). Note there
are no uplink modules installed; we're going directly into the
built-in ports.

Other info:
ESX Version: ESX 4.1.0 Build 582267
Adapter Model: IBM 42C1801
ESX networking driver: qlgc-qlge-1.0.0.45-100.27-offline_bundle-418618

Has anyone experienced this before? JTAC didn't provide much insight,
other than to try a Juniper branded cable (e.g. EX-SFP-10GE-DAC-5m or
EX-SFP-10GE-ACT-5M). So, that's our next step.

Any other tips?

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

Re: [j-nsp] WAN-PHY support for EX-series 10g interfaces

[Dale Shaw]

Hi again,

On Wed, Feb 15, 2012 at 4:53 PM, Dale Shaw dale.shaw+j-...@gmail.com wrote:

 Potentially odd question here but does anyone know, from 1st hand
 experience, whether WAN-PHY mode is supported on 10g interfaces in
 EX-series devices? Specifically EX4200 and/or EX4500?

..thanks for the replies thus far. Nothing definitive but it seems
unlikely that WAN-PHY really works on EX4200, even though JUNOS
auto-completes the 'framing wan-phy' command.

(I know, it wouldn't be the first time the JUNOS CLI auto-completes an
unsupported command. I got nailed, hard, by LLDP on SRX High End a bit
over a year ago.)

*gulp*  I might give the JTAC a try..

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

[j-nsp] JUNOS - RADIUS attributes sent in Access-Request for CLI access

[Dale Shaw]

Hi,

I think I know the answer to this (no.) but here goes nuthin' --

Is there a way that the IP address of the client workstation
connecting via SSH to a JUNOS-based device (e.g. EX4200) can be
captured and sent in the RADIUS Access-Request packet?

I can see the following attributes being sent from the EX to the RADIUS server:

User-Name (1)
User-Password (2)
NAS-Identifier (32)
NAS-IP-Address (4)

I'd like to include the IP address of the connecting SSH client (i.e.
the network administrator's workstation IP).

Is this possible somehow?

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

[j-nsp] WAN-PHY support for EX-series 10g interfaces

[Dale Shaw]

Hi,

Potentially odd question here but does anyone know, from 1st hand
experience, whether WAN-PHY mode is supported on 10g interfaces in
EX-series devices? Specifically EX4200 and/or EX4500?

I ask because we have a new carrier circuit being delivered in the
not-too-distant future and we need to plug something into it to test
it. Eventually we'll jam a SRX5800 with a 4x10GE DPC onto the end of
it but in the meantime it would be handy to terminate and test with
something .. smaller.

The existing interfaces we have (provisioned before my time)
apparently needed to be configured with the framing wan-phy and
optics-options wavelength 1550.12 configuration options. The framing
command auto-completes on an EX-series box but the optics-options
command is hidden.

Couldn't find any definitive references in the product docs.

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

[j-nsp] Time-of-day based traffic conditioning

[Dale Shaw]

Hi all,

Does anyone know of a way to enforce traffic policing or shaping based on
time of day?

Platforms available to us: EX-series (EX4200 predominantly), J-series
(J2320/J6350) and SRX-series (SRX240, SRX650, SRX3K, SRX5K).

I'm looking for a way -- preferably a built-in way (avoiding scripts if
possible) -- to limit a particular application's throughput during business
hours.

The application is NetApp SnapMirror. I suspect a far better option would
be to control transmission rates at the source but I'd like to investigate
JUNOS-based controls as well.

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

Re: [j-nsp] Time-of-day based traffic conditioning

[Dale Shaw]

Hi Misha,

On Tue, Jan 10, 2012 at 4:05 PM, Misha Gzirishvili
misha.gzirishv...@gmail.com wrote:

 Hi there, on SRX/J series you can use schedulers and apply schedulers to 
 security policies.
 On EX there are stateless filters and do not know if they support such thing.
 Regards,
 Misha

Yes but the actions available within a security policy (count, deny,
log, permit, reject) do not seem to include anything that can trigger
a policer or any other kind of traffic conditioner.

Similarly, stateless filters don't seem to include any hooks back into
the time-of-day scheduler definitions.

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

[j-nsp] End host mapping tool

[Dale Shaw]

Hi all,

Is anyone aware of open source or COTS software that provides MAC
address to switch port to IP address (and vice versa) mapping and
discovery? aka end user / end station tracking.

There are lots of them out there ('netdisco' being a popular open
source choice) but I haven't stumbled across one yet that properly
understands Juniper (JUNOS) bridging MIB(s) supported on EX-series
such that the MAC/L2 to IP/L3 resolution works properly.

I've personally tried the cacti 'MacTrack' plugin, as well as the
relevant module within Statseeker -- neither work as intended. In the
latter case, there is a product enhancement request logged but I'm
looking for something in the short term.

What are you using in your environment to do this?

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

Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks

[Dale Shaw]

Hi,

On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk juniperd...@gmail.com wrote:
 I don't want to make a giant vlan and put all the devices loopbacks in it, 
 one for
 scalability issues but also for broadcast related issues.

 Could you achieve what you want using RVIs rather than loopback interfaces?

 I think that's precisely what he's trying to avoid. =)

Yeah, OK, I guess I missed that bit.

But is it really an unscalable solution?
Is it really going to suffer from broadcast related issues?

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

Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks

[Dale Shaw]

Hi,

On Wed, Aug 31, 2011 at 4:12 PM, Morgan McLean wrx...@gmail.com wrote:
 Well, part of good design is trying to avoid as many issues (whether likely
 or unlikely) wherever reasonably possible, right?

Sure.

There's also the KISS principle, and the assumption is the mother
of all ... screw-ups concept :-)

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

[j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

[Dale Shaw]

Hi all,

So, --sigh--, it looks like there are still severe bugs being
discovered in JUNOS 10.4:

http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2011-08-348actionBtn=Search

Does anyone know more about PR/676826 and what the various
conditions that trigger it might be? Anyone know when the defect was
introduced?

I've opened a JTAC case in an attempt to find out more because we've
just embarked on an upgrade to 10.4R6; if the bug can/will bite us I
need to decide whether to stick with 10.4R6, go to 10.4S6, or wait for
10.4R7.

Cheers,
Dale
(..trying to avoid running [S]ervice releases after being on 10.0S1
for ~12 months.)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

[Dale Shaw]

Hi,

On Wed, Aug 31, 2011 at 8:46 AM, Richard A Steenbergen r...@e-gerbil.net 
wrote:
 We hit this bug on several MX devices running junos 64 at the 49 day
 mark. 10.4R7 isn't due until October, so if you're running the new REs
 you probably want to go with S6.6 for the fix.

Hmmm.. interesting. The PR notes only talk about ex8200; it bites on
MX-series too?

(FWIW we don't have any MXs -- only J, SRX and EX.)

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

Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks

[Dale Shaw]

Hi Morgan,

On Wed, Aug 31, 2011 at 12:55 PM, Morgan McLean wrx...@gmail.com wrote:
 So for example, if I have a meshed layer 2 network with switches and I would
 like to be able to maintain device reachability using something like OSPF,
 how would I go about doing this? Everything already had two connections to
 its upstream etc, but they are in the form of trunks. Junos won't let me add
 a unit when there is already a unit set as ethernet switching and port mode
 trunk.

OK..

 Is there any way I can create an addressable interface just for point to
 point ospf neighbor relationships, and maintain my ethernet trunks? What I
 don't want to do is run additional cables between everything. I already run
 two uplinks from every access switch into my core switches. I don't want to
 make a giant vlan and put all the devices loopbacks in it, one for
 scalability issues but also for broadcast related issues. I could maybe make
 private vlans between each link, but again thats bad because I'll eventually
 run out of tags! This is just me getting creative at this point, lol.

Could you achieve what you want using RVIs rather than loopback interfaces?

i.e. on your dot1q trunks, carry an extra management VLAN and attach
a family inet RVI to it?

You wouldn't necessarily need to run OSPF on the RVIs on the edge
switches - depending on your topology. This is how we manage
edge/access switches in L2-only campuses; we have a VLAN 800 carried
on uplinks/trunks with a vlan.800 RVI defined on both the core and
access switches.

On the core side, the vlan.800 interface is part of the OSPF topology
but the interface itself is passive. On the access side, OSPF
doesn't run at all and the vlan.800 interface in effect makes the
switch appear as an IP-enabled end node/station in VLAN 800.

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

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

[Dale Shaw]

Hi,

On Wed, Aug 31, 2011 at 1:28 PM, Jackson Jacobson
jackson.j.jacob...@gmail.com wrote:
 I am curious about what version of junos people on the list run. If you're
 sticking way behind, why?

 j.j.j.

Diff'rent strokes for diff'rent folks!

We run 10.0S1 on our EX-series boxes (apart from EX2200s and EX4500s
which have higher minimum release requirements) because 10.0S1 fixed
most of the horrible bugs we encountered with the original code we
ran; 10.0R2.

We're now moving to 10.4 on EX-series because of the dual-root
partitioning / resilient filesystem changes introduced in 10.4R3
(although I must say I am a bit underwhelmed by the implementation of
this!)  Within 10.4, based on the premise that between releases, the
only changes are bug fixes, it seems newer is better.

On our J and SRX boxes, we're running 10.0R4 due to the security
evaluation status of that specific release. We'll move to 10.4 on
these platforms once 10.4 has been evaluated (est. late 2011).

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

[j-nsp] J/SRX-series IPsec - changing SA lifetimes

[Dale Shaw]

Hi all,

This is something I thought would be really easy to research but I've
come up empty. I got kinda bogged in a sea of RFCs, draft proposals
and JUNOS documentation.

We have about 110 WAN routers configured in a partial mesh of IPsec
tunnels. I want to modify the SA lifetime value in both the IKE (phase
1) and IPsec (phase 2) proposals.

I'll be automating the config push to make this happen - so it should
roll out fairly quickly - but what happens if, by chance, a SA needs
to be renegotiated *during* my change window, and peer A has the new
lifetime value and peer B has the old lifetime value?

I'm trying to understand the behaviour for both phases. We're running
JUNOS 10.0 (R3 and R4, if it matters).

I'm hoping for an answer along the lines of the peers will negotiate
seamlessly and without tearing down SAs :-)   If it's inconclusive, I
guess I'll lab it up.

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

Re: [j-nsp] best practices for cleaning the router for new deployment

[Dale Shaw]

Hi Martin,

On Mon, Aug 22, 2011 at 9:45 AM, Martin T m4rtn...@gmail.com wrote:

 What are the best practices for cleaning the router in order to deploy
 it in some other site?

We usually go with request system zeroize

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

[j-nsp] JUNIPER-COS-MIB support in open source monitoring tools

[Dale Shaw]

Hi all,

Is anyone aware of any effort to wrangle JUNIPER-COS-MIB support into
open source monitoring tools such as MRTG, cacti etc.?

Are there any commercial network monitoring/management packages that
understand this MIB?

I'm looking for something to allow us to graph/present things like
utilisation, bps, pps, and drop rates *per forwarding-class*.

If you've done this in your shop, could you please let me know? I'm
willing to have a go at getting something happening, preferably with
cacti.

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

Re: [j-nsp] EX-4200 Virtual Chassis Pbm

[Dale Shaw]

Hi Roland,

On Thu, Jul 7, 2011 at 7:44 PM, roland DROUAL
roland.dro...@paris.iufm.fr wrote:
 I'm a beginner with Junos.
 I'm trying to do a Virtual Chassis with two EX4200-24F.
 All seem right.
 In cli mode, I can see the interfaces from the master, but I can't see the
 interfaces from the backup switch, starting from ge-1/0/0 until ge-1/0/24 .
 Is somebody can help me ?
[...]

Your interfaces are almost certainly there; they're just not configured yet.

It's a bit confusing -- by default, the interfaces from the first
switch only in the VC appear in the configuration explicitly. On
SFP-based interfaces, JUNOS only creates the interface upon insertion
of a transceiver.

If you run 'show interfaces terse' you should see ge-1/0/0 through
ge-1/0/23  **as long as those ports have SFPs inserted **. Just go
ahead and apply configuration to them. JUNOS isn't like IOS in the way
that physical interfaces are always visible in the configuration.

I usually do a 'wildcard delete ge-*' on a new switch, then set up
interface-range statements or apply configuration only to interfaces
that need it.

Cheers,
Dale
PS: you've got a ge-0/0/24 in your configuration which doesn't actually exist.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX210 IPv6 on ADSL2+ PIM

[Dale Shaw]

On Wed, Jul 6, 2011 at 1:58 AM, Bruce Buchanan bbuch...@nexicom.net wrote:

 I'm trying to get IPv6 up and running on an ADSL2+ pim in an SRX210 without
 much luck.  Hopefully someone has run across this (good or bad).  I'm also
 living life on the edge and am running 11.1R3.5.  I was running 10.4R4.5 and
 can go back to it if anyone thinks that will help.

 I keep getting family INET6 not allowed with this encapsulation on a
 commit check.

 I've tried two different encapsulations and the configs look like this:
[...]

 Has anyone experienced similar behavior?  I'd hate to have to go to an
 external modem to get this to work, or have to use PPPoE.

Disclaimer: I don't think IPv6 actually works over PPP on SRX -
certainly no DHCPv6-PD

I'm running 10.4R5 on srx210h-poe w/ADSL2+ PIM

Here's my interface config --

admin@router show configuration interfaces at-1/0/0
per-unit-scheduler;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
description ISP;
encapsulation atm-ppp-llc;
vci 8.35;
ppp-options {
chap {
default-chap-secret removed; ## SECRET-DATA
local-name usern...@isp.net;
passive;
}
}
family inet {
negotiate-address;
}
family inet6;
}

Once PPP has done its thing, I can ping the remote interface ID (link local) --

admin@router ping fe80::0221:a0ff:febb:3200 interface at-1/0/0.0 count 5
PING6(56=40+8+8 bytes) fe80::b2c6:9a10:7d:5dc0 -- fe80::221:a0ff:febb:3200
16 bytes from fe80::221:a0ff:febb:3200, icmp_seq=0 hlim=64 time=107.031 ms
16 bytes from fe80::221:a0ff:febb:3200, icmp_seq=1 hlim=64 time=108.289 ms
16 bytes from fe80::221:a0ff:febb:3200, icmp_seq=2 hlim=64 time=131.740 ms
16 bytes from fe80::221:a0ff:febb:3200, icmp_seq=3 hlim=64 time=123.717 ms
16 bytes from fe80::221:a0ff:febb:3200, icmp_seq=4 hlim=64 time=119.417 ms

--- fe80::0221:a0ff:febb:3200 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 107.031/118.039/131.740/9.360 ms

..but that's about it.

cheers,
Dale

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

[j-nsp] JUNOS major releases - differences between revisions

[Dale Shaw]

Hi all,

I feel like a bit of a newbie asking this (and, relatively speaking, I
am!) because it feels like something that should be fairly
straight-forward. And maybe it is.

Q: Is there a way to determine what has changed between two revisions
of a major JUNOS release?

For argument's sake, how do I find out precisely what changed between
10.4R3 and 10.4R4?

The release notes for 10.4 don't spell it out very clearly. I suppose
I could look just at the outstanding and resolved issues sections of
the release notes but I'm not even sure how I can go back and look at
the 10.4 release notes at the time the previous revision was released.
A 'single' 10.4 release note exists and is simply revised when a new
revision to the major release goes out.

I know (in theory) there shouldn't be any new features between
revisions -- just bug fixes. I'm more familiar navigating cisco IOS
release notes where, even between maintenance releases, it's made
fairly clear what has changed.

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

Re: [j-nsp] snmp fan bug? and are environmental thresholds configurable?

[Dale Shaw]

Hi again,

On Wed, Mar 23, 2011 at 8:20 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:

 I've noticed on EX-series, the fans go from 'spinning at normal speed'
 to 'spinning at high speed' on a regular schedule even when the
 ambient temperature hasn't significantly changed and the box isn't
 doing much in particular.

 We've got some EX2200 switches in physical spaces where the jet
 engine-like noise the EX4200 generates isn't desirable. Unfortunately
 the EX2200s make quite a racket when their fans spin at high speed as
 well.

FWIW, this seems to have stopped happening since upgrading to 10.4R3.

Can anyone confirm whether a change was made? The switch I hear most
often was previously running 10.0R4.

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

Re: [j-nsp] about 10.4R3 on EX

[Dale Shaw]

Hi,

On Wed, Mar 23, 2011 at 7:48 AM, Kaj Niemi kaj...@a51.org wrote:
 It took 838 seconds on a 2 member EX4200 VC bundle. Yes, I did time it. ;-)

That does sound a bit painful, but not as painful as the file system
corruption this feature aims to fix.

I wonder what happened to the idea of implementing NANDFS?

Cheers,
Dale
(..looking forward to putting 10.4R3 in the lab.)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] snmp fan bug? and are environmental thresholds configurable?

[Dale Shaw]

Hi,

On Sun, Mar 20, 2011 at 9:50 PM, bas kilo...@gmail.com wrote:

 We have a bunch of mx480's running either 10.3r3 and 10.4r2
 About 20 times a day the fans in these boxes switch from normal speed
 to intermediate speed.

Sorry for hijacking your thread, but do you (or does anyone) know why
the fan speed changes like this?

I've noticed on EX-series, the fans go from 'spinning at normal speed'
to 'spinning at high speed' on a regular schedule even when the
ambient temperature hasn't significantly changed and the box isn't
doing much in particular.

We've got some EX2200 switches in physical spaces where the jet
engine-like noise the EX4200 generates isn't desirable. Unfortunately
the EX2200s make quite a racket when their fans spin at high speed as
well.

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

Re: [j-nsp] 10.0 or 10.4?

[Dale Shaw]

Hi,

On Tue, Mar 15, 2011 at 8:37 PM, Bjørn Tore b...@paulen.net wrote:
 Den 15.03.2011 09:43, skrev Chris Kawchuk:

 I'd like to standardize all the other devices in my network to 10.4; once
 the suggest JTAC releases goes past 10.2R3 for things like SRX platforms.

 Second that. We tried 10.4R2.7 on SRX. I guess Juniper didn't think anybody
 still were using DHCP relay and stuff..

Ouch.

I'm pinning some (but not all) hopes on 10.4R3. I'm told it's due to
be released on the 21st of this month.

10.4 is also significant for us as it's the release undergoing Common
Criteria evaluation (for J, SRX and LN1000-V) in Canada. It's the
release train we'll be allowed to operate in (Australian) Government
networks once certified locally.

For our EX fleet (which aren't subject to the same Government
guidelines/recommendations as they don't do crypto), I'm eagerly
awaiting 10.4 to be stable as like Chris said, running EEOL code is
nice.

Cheers,
Dale

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

Re: [j-nsp] virtual router, M or J?

[Dale Shaw]

Hi Richard,

On Thu, Mar 10, 2011 at 6:42 PM, Richard Zheng rzh...@gmail.com wrote:

 SRX seems to be a really good candidate. It looks like all models have
 almost identical features, the only difference is performance. I will buy a
 SRX100, maybe even 2 to test high availability.

I can only speak for J and SRX as I have no first hand experience with M ...

I recently did some performance testing of SRX240, J6350 and SRX650 --
in terms of pps, they come out in that order; SRX240 is out-performed
by J6350 which is out-performed by SRX650. That might seem obvious as
it's the same sequence dollars-wise but just because J is an older
platform doesn't mean everything SRX is 'better'.

If the SRX240 meets your pps needs, it's a great box; dirt cheap for
what it can do. It's a big leap price-wise from SRX240 to SRX650.

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

[j-nsp] Monitoring interface counters on J/SRX

[Dale Shaw]

Hi,

[ disclaimer: I don't claim to be a network management expert but I
can spell SMTP* ]

In our network, we capture, graph and report on the usual set of
interface counters - errors and discards in/out, octets in/out,
packets in/out and so on. Most of the in-house skills are with Cisco
products but we're getting a lot better with J.

I'm trying to come to terms with the difference between the physical
(ifd) counters and the logical (ifl) counters for both 'family inet'
and 'family ethernet-switching' interfaces.

I'm facing a few dilemmas;
1) on Ethernet interfaces shaped to sub line rate, only logical units
report the 'correct' bandwidth so in order for our graphs to scale
correctly we either have to perform interface utilisation reporting
against the logical unit(s), or manually configure our NMS with the
shaped/provisioned bandwidth value. In most cases we're only using one
logical unit (unit 0).
2) I noticed recently that our NMS is collecting error/discard
counters from logical interfaces, and these appear to be always zero.
A few CLI checks around the network seem to prove the theory -
error/discard counters must be collected from the physical interface.

What's the right thing to do here? If there is no right/wrong, what
works for you?

Anyway, I suppose what I'm really looking for is some generic advice
on how to monitor interfaces in Juniper routers and switches -- are
the standard MIBs OK? I just noticed there appear to be interface
counters in jnxMibs. Do you grab interface error/discard counters from
the physical only? Is there a way to populate logical interface
error/discard counters with the underlying physical interface's
counters? (it seems the logical interface does not track
errors/discards, which I guess makes sense).

More than happy to be pointed at good documentation.

Cheers,
Dale

* That was a hilarious joke.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] LLDP-MED support on EX-series - dot1q trunks

[Dale Shaw]

Hi all,

I'm a bit confused about LLDP-MED on dot1q trunks.

We have cases where we need to support interfaces connecting to PCs
via an IP phone (typical setup) however the PC is running VMware
Player and the 'guest' operating system's frames are tagged in order
to differentiate them from the host's (it's a software developer
image). We usually use LLDP-MED on access ports when it's just the
phone (tagged) + PC (untagged), and that works well. Aside from
configuring the developer ports as trunks, I'm not aware of a way to
support 2 x tagged + 1 x untagged.

I've observed that LLDP-MED network policy TLVs are not transmitted on
interfaces configured as trunks.

Without having a mad scientist-level understanding of LLDP-MED, I'm
unsure if this is due to lack of support in the protocol itself, a
limitation on EX-series specifically, or what. Couldn't find the
answer in any J or C documentation.

Basic LLDP functionality continues to work fine - we still see the
phones as adjacent - but we need to instruct the phone on which VLAN
ID to use via another mechanism (DHCP in this case).

We're running RSTP and limit the VLANs permitted on such interfaces
but it's still not as elegant as the access+LLDP-MED method.

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

Re: [j-nsp] LLDP-MED support on EX-series - dot1q trunks

[Dale Shaw]

Hi Doug,

On Sun, Feb 6, 2011 at 7:29 PM, Doug Hanks dha...@juniper.net wrote:
 From what I understand LLDP don't support the 4-byte tag field in an Ethernet 
 frame.  It should be expecting the EtherType of 0x88cc instead.

Thanks for replying.

This still doesn't answer (for me, anyway) why LLDP-MED optional TLVs
couldn't be transmitted untagged (i.e. in the native VLAN). In theory
this will still allow devices like IP phones to consume the advertised
information (VLAN tag, DSCP value etc.)

(I'm not sure if the equivalent function of Cisco's CDP on a Catalyst
switch works on a dot1q trunk but if I get time I will give it a go in
the lab.)

Cheers,
Dale

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

[j-nsp] ex8200 errors - sntl_f_check_dest_errors: Fabric request time out

[Dale Shaw]

Hi all,

I'm seeing these messages spewing from one of our ex8208s --

(FPC Slot 0) chas[85]: %DAEMON-3: sntl_f_check_dest_errors: Fabric
request time out for plane 2 dest 1 pfe 1
(FPC Slot 0) chas[85]: %DAEMON-3: sntl_f_check_dest_errors: Fabric
request time out for plane 2 dest 4 pfe 1
(FPC Slot 0) chas[85]: %DAEMON-3: sntl_f_check_dest_errors: Fabric
request time out for plane 2 dest 5 pfe 1
(FPC Slot 0) chas[85]: %DAEMON-3: sntl_f_check_dest_errors: Fabric
request time out for plane 2 dest 65 pfe 1

It's always in this sequence (dest 1, 4, 5, 65) and the sequence is
repeated constantly -- ~15-20 messages per second.

Anyone seen this before? We're working through it with the JTAC but
it's slow-going (our fault) and I hoped someone else might've been
there, done that.

ex8208, JUNOS 10.0S1.

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

Re: [j-nsp] Re-write rule for GRE interface

[Dale Shaw]

Hi Shiva,

On Monday, January 17, 2011, Shiva Shankar shanka...@gmail.com wrote:
 Hi All, Thanks for the reply. Platform is M7i, and the junos is 9.3

[...]

How are you classifying traffic into the forwarding classes in the
first place? The rewrite-rule assumes traffic has been classified
already. For example, for the 'ef' rewrite-rule to work, you must have
already mapped your voice RTP traffic into the 'ef' forwarding-class.

You need a Behaviour Aggregate (BA) classifier, Multi-Field (MF)
classifier or static classifier applied on the ingress interface(s)
under the class-of-service stanza.

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

Re: [j-nsp] EX4200 Problem - Bad Switch?

[Dale Shaw]

Hi Paul,

On Tue, Jan 11, 2011 at 7:53 AM, Paul Stewart p...@paulstewart.org wrote:

 Ran across a weird issue today on a new EX4200-48T switch.  Switch boots up
 and during so I see this (sorry for the length of the post):

[...]

 So I thought that perhaps the JunOS install is corrupt and rebooted with my
 USB drive connected.  Ran through the installation and it won’t complete:

[...]

 Is this a bad switch??

Probably no worse than every other EX4200 out there :-)  They're a bit
sensitive and emotional.

Looks like the file system is corrupted. Re-installing JUNOS should
fix it but you've tried that. In some cases when this has happened to
us, we've needed to attempt the re-install a couple of times. If you
haven't already, try re-installing from the loader prompt again.

If/when you get it back online, open a JTAC case and ask for the
'automatic file system mirroring and recovery script'.

Cheers,
Dale

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

Re: [j-nsp] RE accessories

[Dale Shaw]

Hi,

On Fri, Dec 24, 2010 at 5:43 PM, Richard A Steenbergen r...@e-gerbil.net 
wrote:

 http://cluepon.net/ras/juniper-accessory.wmv

Does it work on SRX5800 or just MX960?

I've got a broken one that needs .. fixing.

Hot pluggable?

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

Re: [j-nsp] Microsoft NLB cluster with EX-series

[Dale Shaw]

Hi all,

For the record, we ended up putting the server interfaces
participating in NLB in dedicated VLANs. We have 4 NLB clusters across
4 physical servers so we ended up with 4 new VLANs each with 2 member
switch ports.

This seems to be a fairly common workaround to limit the spread of
flooded traffic (which, of course, is expected with NLB).

There still seems to be a bad NLB/EX-series interaction which could be
caused by one of the many multicast bugs fixed in 10.0S10 but I
haven't yet had time to confirm. IGMP snooping shouldn't have to be
disabled to make this work.

Cheers,
Dale

On Mon, Nov 15, 2010 at 10:33 PM, Dale Shaw dale.s...@gmail.com wrote:
 Hi all,

 Has anyone been given the torturous task of supporting Windows servers
 running NLB? (in multicast mode w/IGMP). Horrible things. Ptooey!

 It's wreaking havoc at L2, flooding traffic all over the VLAN because
 I haven't been able to make it work at all with IGMP snooping enabled.
 I'm doing my best to isolate the badness.

 I've got the static ARP entries in to support the *unicast* IP to
 multicast MAC mapping. I couldn't find a way to set a static
 ethernet-switching table entry using a multicast MAC.

 With IGMP snooping enabled, show igmp-snooping member creates the
 right entries but for the multicast group address reverse-derived from
 the multicast MAC.

 The problem seems to be forwarding L2 multicast traffic across a dot1q
 trunk. I've tried 'set protocols igmp-snooping vlan BLAH interface
 trunk multicast-router-interface' to no avail -- it helps with the
 IGMP snooping entries on the far side but traffic just doesn't seem to
 make it.

 EX4200 running 10.0R4 (same end result as with 10.0S1 but there are
 known problems with IGMP snooping fixed in 10.0R4 so I upgraded)

 I've got a case open with the JTAC but it's moving fairly slowly.

 cheers,
 Dale

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

Re: [j-nsp] EX 10.0S10.1

[Dale Shaw]

Hi Bill,

On Wed, Nov 17, 2010 at 8:44 AM, Bill Blackford
bblackf...@nwresd.k12.or.us wrote:
 So I recently updated almost everything to 10.0R4.7 (I still have some stuff 
 on 10.0S1.1). I'm not experiencing any issues, that I'm aware of. I would 
 like to see the IGMP snooping issues ironed out, but for the most part, I'm 
 content.

 My question is should I wait 'til the next recommended release, or is there a 
 compelling reason I should update everything again, now? I am a little 
 concerned about the [PR/546674 EX4200 Virtual Chassis problem not passing 
 traffic] issue.

We're in a similar boat. We're running 10.0S1 almost exclusively and
just started to play with 10.0R4. I saw the PSN bulletin for 10.0S10
yesterday and saw all the multicast PRs. *sigh*

I suspect we're being bitten by the
VLAN-tag-gets-mangled-when-multicast-flooded-over-dot1q-trunk bug. I'm
waiting for some advice back from the JTAC about whether any of the
PRs fixed in 10.0S10 could be a factor in one or two open cases.

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

[j-nsp] Good practice for EX-series interface config management

[Dale Shaw]

Hi all,

I'm curious about what people have found is the best way to manage
interface configurations on EX-series devices. There are a number of
ways to apply configuration to interfaces -- direct to each interface,
using interface-ranges etc.

We've been burnt a couple of times with people making adjustments to
interface-ranges and not paying close enough attention to the net
effect of their change (e.g. leaving out all interfaces on a switch).
Direct application of config to interfaces, while precise, kind of
feels 'wrong' as JUNOS provides more elegant ways to achieve the same
end result. Maybe in carefully planned, static environments where
access port VLAN assignments and other port specific configs rarely
change, interface-ranges are more workable. Or maybe we're just doing
it wrong.

I'm hoping that this sparks some discussion. What works best for you?

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

Re: [j-nsp] JunOS on EX-4200 stack corruption

[Dale Shaw]

Hi Tim,

On Thu, Oct 7, 2010 at 10:09 AM, TiM t...@muppetz.com wrote:
 Has anyone seen an issues where, once a stack looses power (all at once,
 sadly), some members of the stack come up with corrupt JunOS on them?

 We have a stack of 6 EX4200's.  Due to a power issue, all 6 lost power at
 the same time.  When power was restored, the Master, the Backup and one
 linecard mode switch came up fine.  The 3 other linecard mode switches
 didn't.  On powerup they all reported shared libaries not being found and
 similar file not found type errors.

 Reinstalling JunOS from the boot prompt has fixed the problem.

 Has anyone else encountered corrupt JunOS problems on EX4200's,
 specifically in a stack configuration, before?

Yes, it's been a serious, ongoing problem for us. We have ~1200
switches across ~360 VCs. We're running JUNOS 10.0S1.

There is a PR for the problem - it's PR/543776. There is no permanent
fix as yet but there is a workaround available in 10.0R4, 10.1R4,
10.2R3, 10.3R2, 10.4R1 or later. It's called 'Automatic File System
Mirroring and Automatic Recovery' and at this stage you'll need to
talk to JTAC about it.

cheers,
Dale

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

Re: [j-nsp] Subrate speed on GigE requiring CoS / Policer configuration

[Dale Shaw]

Hi Chris,

On Wed, Oct 6, 2010 at 1:44 PM, Chris Evans chrisccnpsp...@gmail.com wrote:
 As this is a lab we want to limit the bandwidth that comes out of
 the LAB to 15megabits, but using GigE for the physical connection on an m7i.

I have no hands-on experience with M-series but is there any reason
you can't use traffic shaping to limit the transmit rate? ('set
interfaces ... shaping-rate 15m')  It can't be tuned as much as the
equivalent function in IOS but unless you're trying to interoperate
with a particularly aggressive intermediate device, it should do the
job. We use it instead of egress policers on J and SRX, and we use it
in conjunction with schedulers, including a priority queue for voice.

My understanding is that it (the shaper) should introduce back
pressure/congestion when the interface reaches the specified transmit
rate.

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

Re: [j-nsp] SRX5800 HA over 40 KM

[Dale Shaw]

Hi,

On Thu, Sep 30, 2010 at 3:36 PM, Fahad Khan fahad.k...@gmail.com wrote:
 I am unable to access this link. Can you please attach the file or provide
 exact URL?

Start here:

http://kb.juniper.net/index?page=contentid=TN21actp=LIST

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

[j-nsp] MPLSoMPLS - horrible?

[Dale Shaw]

Hi all,

I'm pondering my first production use of MPLS and I'm looking for some
free advice.

I'm looking at building a new 'enterprise' network - an extranet of
sorts - *on top of* a NSP's L3VPN service. It's all Ethernet. I'd like
to be able to build my own pseudowires and create my own L3VPNs on top
of the NSP's platform and without their involvement. In effect, my CE
routers (from the NSP's perspective) become PE routers to *my*
customers (3rd parties, e.g. business partners and suppliers).

I suppose this means doing MPLSoMPLS, and actually depending on the
upper layers in the protocol stack, it could end up looking pretty
scary if you looked at what was being shifted around in the NSP's core
:-)  (over and above MPLS, I'm thinking about how the stack looks when
further encapsulation, such as IPSec, is used.)

So, noting the protocol stack size and potential MTU issues, is anyone
doing this? How are you distributing labels?

Is it too horrible to even contemplate?

I'd be looking at using J and/or SRX as the CE-pseudo-PE devices.

Any pointers would be appreciated. I've only just embarked on this
little adventure and I'm still relative new to Juniper platforms.

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

Re: [j-nsp] MPLSoMPLS - horrible?

[Dale Shaw]

Hi Alexandre,

On Thu, Sep 30, 2010 at 7:17 PM, Alexandre Snarskii s...@snar.spb.ru wrote:

 Right question would be 'How do you exchange labels with your NSP?'.
 Because if there are no such exchange your NSP will not know what to
 do with MPLS packet entering his network and will just drop it at
 ingress.

 Is it too horrible to even contemplate?

 It's hardly possible without setting CsC with your NSP.

Right. Yes, I hadn't appreciated that the carrier's PE would need to
handle labelled packets. It seems obvious now :-)

 With L3VPN all you have is IP[v6] connectivity between your CE routers,
 so the only way to run MPLS without NSP support is to run GRE tunnels
 between your CE's and then run MPLS over these GRE tunnels. And, yes,
 it is horrible: ethernet frame passing your pseudowire will become
 ethernet over MPLS over GRE over IP over MPLS over ethernet with terrific
 overhead and lots of MTU issues :)

OK, yeah. It sounds .. sub-optimal .. but now that I have some more
key words / concepts to search for, I'm getting the impression it's
not an uncommon configuration, especially as it seems J does not
support L2TPv3.

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

Re: [j-nsp] MPLSoMPLS - horrible?

[Dale Shaw]

Hi Heath,

On Thu, Sep 30, 2010 at 9:14 PM, Heath Jones hj1...@gmail.com wrote:
 So they are routing IP?
 Or are they are switching ethernet?

Sorry, I can see how it wasn't clear.

All of the CE-PE access links are Ethernet, or at least have an
Ethernet hand-off. It's probably not relevant.

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

Re: [j-nsp] Juniper RANCID

[Dale Shaw]

Hi Stefan,

On Fri, Jul 16, 2010 at 9:53 AM, Stefan Schlesinger s...@ono.at wrote:

 I'm trying to get RANCID to work with jlogin on my SRX100. [...]

 The following happens when i run the command line from above:

 $ bin/jlogin -f .cloginrc 192.168.0.13
        spawn ssh -c 3des -x -l rancid 192.168.0.13
        ran...@192.168.0.13's password:
        --- JUNOS 10.1R3.7 built 2010-07-10 08:32:02 UTC
        ran...@juniper-01

Looks like 'jlogin' is working just fine. 'jlogin' automates logins
and (optionally) allows you to execute commands (using -c or -x).
'jrancid' does the work to collect and store command output in CVS,
but typically it is not executed directly.

Have you run rancid-cvs and then rancid-run? Have you set up rancid.conf?

Follow some of the links from: http://www.shrubbery.net/rancid/#started

cheers,
Dale

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

Re: [j-nsp] IPSEC VPN tunnel is not accepting only SMTP traffic

[Dale Shaw]

Hi,

On Fri, Jul 2, 2010 at 11:27 PM, Fahad Khan fahad.k...@gmail.com wrote:

 I am facing an issue regarding an IPSEC tunnel between ISG1000 and Cisco
 box, The VPN is up, all traffic is going through it but only SMTP traffic is
 some how not being flowing through the tunnel, no SMTP connection is being
 made with mail server.

There are so many variables and you've provided such little detail
(again) that it's going to be difficult for people to help you.

Things that are missing from your post:

- Details of the 'Cisco box'
- Details of the IPSec tunnel configuration on the peers
- Details of the network infrastructure between the peers and between
the endpoints
- Software revisions running on the relevant nodes
- How you have verified that the tunnel is 'up'
- How you have verified that non-SMTP traffic is flowing
- How you have verified that SMTP traffic is not flowing
- What troubleshooting (if any) you've already done

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

[j-nsp] EX4200 Notprsnt VC members after reboot (filesystem corruption)

[Dale Shaw]

Hi all,

Not much technical detail to provide at this stage but I wanted to
know if anyone else has experienced the same/similar problem --

We've just been through a programme of upgrading ~400 EX4200s (some
single switches, most multiple switch/VC) from JUNOS 10.0R2 to 10.0S1.
This process, of course, involved lots of reboots.

In a small number of cases, upon rebooting the VC, we have member
switches 'disappear' -- from the VC master they show up as 'NotPrsnt'
(not present). I haven't been involved first hand with the recovery
process but from what I understand, the console log entries indicate
that the member switch doesn't appear to have unmounted its
filesystems cleanly and upon rebooting, filesystem corruption is
detected on da0s1a and badness ensues. The end result is a switch that
doesn't boot and doesn't join the VC. It's effectively orphaned,
unmanageable and an on-site visit is required to recover it.

Has anyone had problems with EX4200s and filesystem corruption
relating to ungraceful power-downs, routine reboots (i.e. for JUNOS
upgrades or whatever), or anything else? Does anyone know of any
tricks to access a switch in this state remotely? (unfortunately there
is no out-of-band management path available).

A re-install of JUNOS (from a JUNOS tgz located in a USB flash disk)
typically 'fixes' the problem. A power cycle is not enough.

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

[j-nsp] Setting forwarding-class in firewall filter, non-match behaviour

[Dale Shaw]

Hi all,

Re: setting the forwarding-class of a packet through a firewall filter.

Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...

Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?

Using this input filter example:
(stolen from 
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)

firewall {
 filter filter1 {
  term 1 {
   from {
dscp 2;
   }
   then {
dscp 0;
forwarding-class best-effort;
   }
  }
  term 2 {
   from {
dscp 3;
   }
   then {
forwarding-class best-effort;
   }
  }
 }
}

I read this as:

- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets

Am I missing something?

I think what I really want, to avoid dropping traffic, is something like:

firewall {
 filter FILTER1 {
  term TERM1 {
   from {
dscp ef;
   }
   then forwarding-class expedited-forwarding;
  }
  term DEFAULT {
   then forwarding-class best-effort;
   accept;
  }
 }
}

...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).

(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)

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

Re: [j-nsp] Traffic shaping on J and SRX

[Dale Shaw]

Hi Michel,

On Fri, Jun 4, 2010 at 11:29 AM, Michel de Nostredame
d.nos...@gmail.com wrote:

 Try this config. I am not sure if it could resolve your problem, but you can
 give it a try.

[.. config with 'shaping-rate' snipped ..]

That's essentially what we're running with today. Sure, shaping is
active, but how is it *really* operating?  How is the transmit rate
measured? (over what interval?)  How long can the interface transmit
for and how many bits/bytes are sent before it backs off?

On a Cisco, we have the (relatively) clearly defined concepts of 'Bc',
'Tc' and 'Be' and once one understands the formulas and how the three
values interact, one knows exactly how the shaper should behave --
i.e. how many bits are sent (Bc) per time interval (Tc) and whether
bursting above the committed rate (Bc) is possible at all, and if so,
by how much (Be).

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

[j-nsp] Traffic shaping on J and SRX

[Dale Shaw]

Hi all,

I need to shape on egress from CE to PE to match the service
provider's 'PVC' speed. The physical interface is gigabit Ethernet. We
have a variety of J and SRX boxes running JUNOS 10.0R3.

We have the following access/service speed combos (all on J/SRX
ge-x/x/x or SRX xe-x/x/x): 100m/10m, 1g/50m, 1g/100m, 1g/150m,
1g/200m, 10g/1g.

I have a JTAC case running on this but I haven't been making good progress.

The carrier's EoSDH access network throws away traffic when bursts
fill up the relatively small buffers (~130K) in their Alcatel
equipment. I need to tune the shaper to control/buffer bursts.

Through the JTAC case (which I have just asked to be escalated), I
have NOT been able to determine:

1. how the burst size is calculated when (for example) 'shaping-rate
150m' is used without any other configuration on a logical unit.
2. how, if at all, the burst size can be tuned. I need to ensure I
drive the burst size (in bytes) down to =130K for all of the
access/speed combinations above

How is everyone doing this in the real world?

Lastly, through my investigations with Juniper folks outside the JTAC,
I have become aware of two things:

- The default burst size on J-series cannot be configured and
(whatever it is,) is too high
- PR/511498. The shaper burst-size was calculated based on
interface-bandwidth instead of the shaping-rate. Fixed in
10.0-20100326.0 daily SR or later, apparently. No more info.

I hate to draw the comparison but detailed information about how the
shaper works and can be tuned is readily available in vendor C land
:-/

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

Re: [j-nsp] Ewwwww/ ww

[Dale Shaw]

Hi Mike,

On Tue, Jun 1, 2010 at 4:36 AM, Mike Teeman mike.tee...@gmail.com wrote:
 Wwrwweqqqqqakwwxjkkkjajjkvkkpokllgzi

That feature is currently scheduled for inclusion in in JUNOS 10.4.

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

[j-nsp] EX-series monitoring - useful/meaningful box utilisation counters

[Dale Shaw]

Hi all,

Just curious what you are all doing to monitor your EX-series boxes.

I'm still learning about the architecture of EX4200 and EX8200 series
devices but apart from the generic RE utilisation counters defined in
JUNIPER-MIB, what else is worth keeping an eye on?

I don't see much of note in JUNIPER-VIRTUALCHASSIS-MIB, apart from the
VC port admin/oper status.

Apart from the network-facing Ethernet interfaces, is there anything
else we should be monitoring for capacity management purposes?

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

Re: [j-nsp] EX 8200 deployment

[Dale Shaw]

Hi,

..straying a bit off topic..

On Sun, Mar 21, 2010 at 6:08 PM, Julien Goodwin
jgood...@studio442.com.au wrote:
 So the EX (4200) bits from my personal list:
 * EX4200 - bootp relay doesn't work when configured inside a
 routing-instance, works when configured at top to use an instance

Got bitten by this one a couple of weekends ago, during a big roll-out.

Very counter-intuitive 'fix'.

We had:

set routing-instances blah-vr forwarding-options helpers bootp
interface vlan.600 server 172.13.40.9

We actually needed:

set forwarding-options helpers bootp interface vlan.600 server
172.13.40.9 routing-instance blah-vr

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

Re: [j-nsp] Juniper EX, HP server NIC teaming

[Dale Shaw]

Hi again all,

On Tue, Jan 12, 2010 at 11:30 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:

 I'm operating in a bit of an information vacuum here, but I'm trying
 to help out some colleagues with a server NIC teaming / EX switch
 problem.

Here's an update:

My colleagues revisited the problem last night and disabling IGMP
snooping has 'fixed' the problem.

My question is, why is the switch doing anything but flood non-IP L2
multicasts and why is this traffic subject to the rules of IGMP
snooping? :-)

(The NIC team member interfaces won't be sending IGMP joins -- it's
not IP multicast.)

The previously referenced PR (PR/492704) sounded promising -- does
anyone have any insight into how the fix for that has been/is being
implemented?

If disabling IGMP snooping is indeed the 'best' fix, what does the
list consider the most elegant / least intrusive way of disabling it?
They disabled it for the whole VLAN (set protocols igmp-snooping vlan
server disable) but I'm guessing this means IP multicast traffic will
be flooded to all stations in the VLAN whether they're interested in
the traffic, or not.

The second link (PDF) below seems to indicate IGMP snooping can be
disabled explicitly on individual interfaces like so:

protocols {
  igmp {
interface interface-name;
disable;
  }
}

Other useful references:
 http://kb.juniper.net/index?page=contentid=KB15316actp=LIST
 http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/8010061-EN.PDF

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

Re: [j-nsp] Juniper EX, HP server NIC teaming

[Dale Shaw]

Sorry for the followup on my own post, but..

On Thu, Jan 14, 2010 at 10:59 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:
 The second link (PDF) below seems to indicate IGMP snooping can be
 disabled explicitly on individual interfaces like so:

 protocols {
  igmp {
    interface interface-name;
    disable;
  }
 }

I didn't read this properly. This is for IGMP, not IGMP snooping.

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