Re: [j-nsp] MX MTBF

[Graham Brown]

Hey Mohammad,

This is tucked away behind NDAs:
https://kb.juniper.net/InfoCenter/index?page=content=KB11145=M_SERIES=LIST

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>


On Fri, 26 Feb 2021 at 10:40, Mohammad Khalil  wrote:

> Hi all
> I have accessed the partner portal looking for MTBF for MX routers as my
> customer requester but cannot find any clue.
>
> Anyone can help?
>
> Thanks
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Micro-segmentation

[Graham Brown]

Hey James,

I’ve thought about this before and I looked at PVLANs, single VLAN made up
of multiple /31s and also VM-based FWs and handing over control to NSX etc.

PVLANs would be easiest, NSX-T w/automation looks great but no personal
experience to elaborate further.

On Sun, 2 Aug 2020 at 20:41, james list  wrote:

> Dear all,
> Many times my security team requires to have in place layer2 segregation in
> order to create dmz on the firewall as security measure to prevent lateral
> movement in case of different vlan management or to respect standards (pci,
> nist, etc).
>
> The result is in having hundreds or thousands vlans also if in each vlan
> there are very few systems ( 3 o 4 servers, etc).
>
> My question is: how did you manage the issue in case you faced it?
> Private vlans?
>
> Keep in mind we need to have a non stop environment and hence any possible
> way forward must forecast it.
>
> Cheers
> James
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 
-sent from my iPhone; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 MACsec

[Graham Brown]

Hi Mohammad,

The following link displays specific elements pertaining to MACSec support
on various Juniper platforms, MX204 included:
https://apps.juniper.net/feature-explorer/parent-feature-info.html?pFName=Media%20Access%20Control%20Security%20(MACsec)


Review the link and ask the customer for clarification on what they require
to be supported from the equipment. Depending on what the requirements are,
the MX204 may be able to secure the L2 elements for your customer.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>


On Wed, 27 Nov 2019 at 08:39, Mohammad Khalil  wrote:

> Dears
> I am working with a customer and MX204 is in play.
> The customer concern is MACsec feature support , I have read around
> that MX204 doesn’t Support a real MACSEC, but offers unicast MAC DA for
> MACsec and MACsec with fallback PSK are which related to allow exchanging
> and establishing Macsec connections.
> So frankly MX204 does not support MACsec or am I missing something?
>
> Thanks
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 or QFX5110

[Graham Brown]

Hi Alex,

Just to add a little extra to what Charles has already said; The EX4600 has
been around for quite some time, whereas the QFX5110 is a much newer
product, so the suggestion for the QFX over EX could have been down to
this.

Have a look at the datasheets for any additional benefits that may suit one
over the over, table sizes / port counts / protocol support etc etc. If in
doubt between the two, quote out the solution for each variant and see how
they best fit in terms of features and CAPEX/OPEX for your needs.

Just to echo Charles, remember that a VC / VCF is one logical switch from a
control plane perspective, so if you have two ToR per-rack, ensure that the
two are not part of the same VC or VCF. Then you can afford to lose a ToR /
series of ToRs for maintenance without breaking a sweat.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>


On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R  wrote:

> Spanning Tree is rather frowned upon for new designs (for good reasons).
> Usually, if you have the ability to do stright L2 bridging, you can always
> do L3 on top of that.  A routed Spine/Leaf design with EVPN-VXLAN overly
> for L2 extension might be a good candidate and is typically the answer
> given these days.
>
> I'm not a fan of proprietary fabric designs like VCF or MC-LAG.  VC is
> okay, but I wouldn't use it across your entire set of racks because you are
> creating a single management/control plane as a single point of failure
> with shared fate for the entire 6 racks.  If you must avoid L3 for some
> reason, I would create a L2 distribution layer VC out of a couple QFX5110s
> and dual-home independent Top Of Rack switches to that VC so each rack
> switch is separate.  I've used 2-member VCs with QFX5100 without issue.
> Just be sure to enable "no-split-detection" if and only if you have exactly
> 2 members.  Then interconnect the distribution VCs at each site with
> regular LAGs.
>
> On Tue, Mar 12, 2019 at 06:36:49PM +, Alex Martino via juniper-nsp
> wrote:
> > Hi,
> >
> > I am seeking advices.
> >
> > I am working on a L2/L3 DC setup. I have six racks spread across two
> locations. I need about 20 ports of 10 Gbps (*2 for redundancy) ports per
> rack and a low bandwidth between the two locations c.a. 1 Gbps. Nothing
> special here.
> >
> > At first sight, the EX4600 seems like a perfect fit with Virtual Chassis
> feature in each rack to avoid spanning tree across all racks. Essentially,
> I would imagine one VC cluster of 6 switches per location and running
> spanning-tree for the two remote locations, where L3 is not possible.
> >
> > I have been told to check the QFX5110 without much context, other than
> not do VC but only VCF with QFXs. As such and after doing my searches, my
> findings would suggest that the EX4600 is a good candidate for VC but does
> not support VCF, where the QFX5110 would be a good candidate for VCF but
> not for VC (although the feature seems to be supported). And I have been
> told to either use VC or VCF rather than MC-LAG.
> >
> > Any suggestions?
> >
> > Thanks,
> > Alex
> ___
> 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] Access to junos downloads

[Graham Brown]

Hi Alex,

The official answer is that you can’t. If you require devices of this spec,
then I’d highly recommend a support contract.

The cheapest option would be support only, no hardware RMA etc. But if it
goes pop...

Others may be able to assist you in just getting hold of software but you
may need more down the line for new features, PR fixes etc so best this in
mind from an OPEX point of view you may have to wait a while during an
outage.

Cheers,
Graham


On Fri, 3 Aug 2018 at 08:30, Alex Martino via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Good evening,
>
> I have recently acquired a Juniper MX80 and MX240, both refurbished. I am
> now looking for a cheap and effective way to get access to junos downloads
> without having a j-care on all of it, so I can apply patches to my devices.
>
> Is there a "smart way" to get access to the downloads without breaking the
> bank? I welcome any feedback in private email as well.
>
> Many thanks,
> Alex
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 
-sent from my iPhone; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and copper SFP?

[Graham Brown]

Quite timely, I saw a tweet around forcing the interface name via a CLI
command.

https://twitter.com/mohsinulmalik/status/983190461513744385?s=21

Apologies but I have not tested this myself, but may be of interest to
those of you on this list.

Cheers,
Graham

On Sat, 7 Apr 2018 at 07:49, Niall Donaghy  wrote:

> You're exactly right Saku, those are the questions to ask, the design
> decisions to be made. I posit that as Juniper break this up into
> type-fpc/pic/port, and there is some indication of speed in the type name,
> they would do well to standardise, or abandon the idea. Currently even the
> documentation states the type indicates speed, for some types, then lists
> exceptions to this. My only complaint is if you have to remember
> exceptions, best not to use it as an indicator at all.
>
> I am certainly immersed in Ethernet interfaces more than any other, so
> accustomed to ge, xe, et denoting one speed, as per the deployment I work
> on every day. A little biased indeed. :)
>
> I categorically wouldn't want a single 'type' prefix. Agree on the dynamic
> update on linerate OID being an ideal feature to have.
>
> Get Outlook for Android
>
>
>
> From: Saku Ytti
> Sent: Friday, 6 April, 19:55
> Subject: Re: [j-nsp] MX204 and copper SFP?
> To: Niall Donaghy
> Cc: Chuck Anderson, juniper-nsp@puck.nether.net
>
>
> Maybe you're right. Maybe you're suffering status quo bias. If interface
> name should give some indication, but provably unreliable indication of
> interface rate. Is that the idea amount of information encoded to interface
> name? Or should we code more information in the name? Or less? Should
> interface name include encapsulation type, why not? Why is rate special? We
> have field for bandwidth in SNMP MIB and interface CLI configuration, this
> could be automatically set to linerate of interface, so we would offer
> dynamic and accurate data about linerate, as opposed to interface name.
> Unless we want interface name to change once we change the speed?. On 6
> April 2018 at 21:07, Niall Donaghy wrote: > Indeed, encapsulating a port
> speed in its name offers some convenience in > show commands, configuration
> groups, and interface-ranges; I would say the > value there is non-zero. >
> > Going beyond that, how about logical tunnels (lt-), GRE interfaces(gr-
> and > gre), loopback interfaces (lo), Multis
>  ervices (ms-), SONET/SDH (so-) and the > various assortment? > Ref: >
> https://www.juniper.net/documentation/en_US/junos/topics/concept/interfaces-
> > interface-naming-overview.html > This page seems to say that aside from
> PTX routers, where et- can be > 10/40/100GE, et- == 100GE. > We know that's
> not the case as on MX204 and MX10k3, et- can be 40/100GE. I > guess they
> might update this page sometime.. > > Consider operators whose interface
> descriptions don't encapsulate the > relevant information, or worse still -
> whose operational interfaces may not > have interface descriptions at all.
> > In those cases it is *incredibly* useful to identify interface type by >
> interface name. > I would say identifying speed by name is an extension of
> that. > > I don't see that moving to a generic prefix such as inf- is for
> the greater > good. > > So now we have ge-, xe-, and et- meaning physical
> Ethernet interfaces - and > depending on your hardware, optics, and config
> - *likely* 1GE/10GE/100GE, > r
>  espectively ... but, maybe not. > Now with the speed variances, at least
> we can still say they're physical > interfaces. > > > Br, > Niall > > >
> -Original Message- > From: juniper-nsp [mailto:
> juniper-nsp-boun...@puck.nether.net] On Behalf Of > Chuck Anderson >
> Sent: 05 April 2018 20:31 > To: juniper-nsp@puck.nether.net > Subject:
> Re: [j-nsp] MX204 and copper SFP? > > Back-in-the-day we had fe-x/x/x for
> 10/100 Mbps ports. Now we have ge-x/x/x > that can take a 100 Mbps SFP, but
> the name doesn't change to fe-x/x/x AFAIK. > So there is precedent for the
> names not changing when the speed changes. > > But I do like having the
> ability to match ports based on speed, e.g. find > all "uplink" ports by
> assuming ge-* are access ports and xe-* are uplinks. > Patterns can be used
> within configuration groups and interface-ranges. > > On Thu, Apr 05, 2018
> at 01:38:46PM +, Nelson, Brian wrote: >> Port-foo is so archaic. >>
> It's an interface, inf-x/x/x would be more germane. >> >> Brian
>  >> >> -Original Message- >> From: juniper-nsp [mailto:
> juniper-nsp-boun...@puck.nether.net] On >> Behalf Of Ola Thoresen >>
> Sent: Thursday, April 05, 2018 3:59 AM >> To: juniper-nsp@puck.nether.net
> >> Subject: Re: [j-nsp] MX204 and copper SFP? >> >> On 05. april 2018
> 10:44, Saku Ytti wrote: >> >> > Since of the fathers. >> > >> > 'Cisco did
> it'. >> > >> > I also see no value in it. >> >> Don't we all love that
> "linux" changed from eth0, eth1, eth2... to > beautiful stuff like
> wwp0s20u4 and 

Re: [j-nsp] mx960 crashed

[Graham Brown]

Hi Aaron,

Looks like you have a core file there, raise a TAC case and they’ll be able
to determine the root cause for you.

Also see if there is anything readable in
/dev/mapper/jvg_P-jlvmrootrw/var/crash/override_reboot_reason that may
point you to the root cause.

HTH,
Graham

On Thu, 5 Apr 2018 at 01:13, Aaron Gould  wrote:

> Still in the process of turning up this new 5-node mx960 100 gig ring, and
> I
> went to the backup re console and went to login and saw this happen.
>
>
>
> Any idea why this happened and how do I tshoot cause ?
>
>
>
>
>
>
>
> FreeBSD/amd64 (mx960) (ttyu0)
>
>
>
> login: root
>
> Password:SysRq : Trigger a crash
>
> dmar: DRHD: handling fault status reg 2
>
> dmar: DMAR:[DMA Write] Request device [02:10.1] fault addr 151d9000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: DRHD: handling fault status reg 102
>
> dmar: DMAR:[DMA Write] Request device [02:10.1] fault addr 1540c000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: DRHD: handling fault status reg 202
>
> dmar: DMAR:[DMA Write] Request device [02:10.1] fault addr 152fc000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: DRHD: handling fault status reg 302
>
> dmar: DMAR:[DMA Write] Request device [06:0a.0] fault addr 1ed10d000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: DRHD: handling fault status reg 402
>
> dmar: DMAR:[DMA Read] Request device [06:0a.0] fault addr ad4a000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: INTR-REMAP: Request device [[05:00.1] fault index 40
>
> INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear
>
> dmar: DRHD: handling fault status reg 602
>
> dmar: DMAR:[DMA Read] Request device [06:0a.0] fault addr ad4a000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
> dmar: DRHD: handling fault status reg 702
>
> dmar: DMAR:[DMA Read] Request device [06:0a.0] fault addr ad4a000
>
> DMAR:[fault reason 01] Present bit in root entry is clear
>
>   4 logical volume(s) in volume group "jvg_S" now active
>
>   4 logical volume(s) in volume group "jvg_P" now active
>
> Override SW Exception reboot reason saved to
> /dev/mapper/jvg_P-jlvmrootrw/var/crash/override_reboot_reason
>
> Compressed level 31 vmhost kernel core will be dumped to jvg_P-jlvmrootrw.
>
> Please use crash utility to analyze the core
>
> Copying data   : [ 13 %]
>
> .
>
> .
>
> .
>
> Copying data   : [100 %]
>
>
>
> The dumpfile is saved to vmcore-0-compressed-201804041305.
>
>
>
> makedumpfile Completed.
>
>
>
>
>
> (many more boot messages seen)
>
>
>
>
>
> -Aaron
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 
-sent from my iPhone; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] layer 2 sp services

[Graham Brown]

+1 for both books.

On Fri, 28 Jul 2017 at 19:16, Pavel Lunin  wrote:

> Aaron, just open "MPLS Enabled Applications" or/and "MPLS in the SDN era".
> Both are fantastic books. It's all there :)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 
-sent from my iPhone; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2300 issues

[Graham Brown]

Hi Lucio,

I have checked the EoL notices for the EX2200 and there is nothing there -
so that means you have at least five years before it would become end of
support.

As for the supply issues, this should have been resolved for all affected
EX series switches. Were you after a PoE model? You're local SE, or
distributer should be able to provide a current shipping timeframe,
including a delta against the target time.

Hopefully you can get an EX2300, but if not the EX2200 has been a solid
performer over the years.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 15 November 2016 at 05:01, Valentini, Lucio <lucio.valent...@siag.it>
wrote:

> Hi folks,
>
> back in August there was a post about EX2300 supply delays; now we are in
> November, but there seems to be still some issues with shipment. I called
> Juniper a couple of weeks ago, to see if there are plans to phase out the
> EX2200, which could be supplied instead, but I am still waiting for an
> answer. Does any of you guys have some more info about the EX2300
> availability?
>
> Thanks
>
> Best regards
>
> Lucio
>
> ___
> 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] Infranet controller solution

[Graham Brown]

Hi Michael / Bill,

I've just re-read the D60 release notes and Dynamic VPNs are back in the
code:

"Dynamic VPN remote access for Secure Pulse clients to SRX300, SRX320,
SRX340, SRX345, and SRX550M devices—Starting with Junos OS Release
15.1X49-D60, dynamic VPN simplifies remote access by enabling Pulse Secure
clients to establish IPsec VPN tunnels to SRX services gateways without
having to manually configure VPN settings on their PCs or laptops. User
authentication is supported through a RADIUS server or a local IP address
pool."

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

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 30 October 2016 at 21:36, Michael Gehrmann <mgehrm...@atlassian.com>
wrote:

> Good to know. Makes sense as this feature got sold off and the solution was
> never fully accepted by enterprise.
>
> Cheers
> Mike
>
> On 29 October 2016 at 01:49, Bill Blackford <bblackf...@gmail.com> wrote:
>
> > I was told by our SE that the newer models of SRX will no longer support
> > Pulse Secure. I've also had to downgrade code to get older models to
> > support it as well.
> >
> > Sent from my iPhone
> >
> > > On Oct 28, 2016, at 00:59, Michael Gehrmann <mgehrm...@atlassian.com>
> > wrote:
> > >
> > > Hi James,
> > >
> > > I'm only aware of Palo Alto and Juniper supporting this function. The
> > next
> > > generation SRX (300 and 1500) have some pretty good pricing from what I
> > > have experienced.
> > >
> > > https://www.pulsesecure.net/download/document/988/
> > PulseSecure_Solution_Brief_PAN_PPS_d1v5.fin.pdf
> > >
> > > I have experienced the Juniper integration with NAC and it works very
> > well.
> > >
> > > Cheers
> > > Mike
> > >
> > >> On 28 October 2016 at 18:52, james list <jameslis...@gmail.com>
> wrote:
> > >>
> > >> Hi Mike
> > >> here the functionality I'm looking for in the firewall device:
> > >>
> > >> - integration with MAG Pulse Secure
> > >> - policy enforcement using at least destination ip address, port and
> > >> protocol
> > >> - policy enforcement with action at least like allow, deny, reject
> > >> - policy enforcement based on user role
> > >>
> > >> Cheers
> > >> James
> > >>
> > >>
> > >> -
> > >>
> > >> 2016-10-28 7:21 GMT+02:00 Michael Gehrmann <mgehrm...@atlassian.com>:
> > >>
> > >>> Hi James,
> > >>>
> > >>> Might be useful if you describe what functionality you are trying to
> > >>> achieve. i.e. SRX as an enforcer
> > >>>
> > >>> Also you may not find many 'cheaper' alternatives in the TNC space:
> > >>> https://en.wikipedia.org/wiki/Trusted_Network_Connect
> > >>>
> > >>> Cheers
> > >>> Mike
> > >>>
> > >>>> On 28 October 2016 at 01:36, james list <jameslis...@gmail.com>
> > wrote:
> > >>>>
> > >>>> Hi experts,
> > >>>>
> > >>>> has anybody ever configured an infranet controller solution using
> MAG
> > >>>> (today Pulse Secure) other than using SRX firewall ?
> > >>>>
> > >>>>
> > >>>> I looking to find an alternative solution to SRX and as far as I’ve
> > >>>> searched till now, seems that only Palo Alto could do something. I’m
> > >>>> wondering if there are (cheaper) alternative…
> > >>>>
> > >>>>
> > >>>> Thanks in advance
> > >>>>
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> James
> > >>>> ___
> > >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Michael Gehrmann
> > >>> Senior Network Engineer - Atlassian
> > >>> m: +61 407 570 658
> > >
> > >
> > > --
> > > Michael Gehrmann
> > > Senior Network Engineer - Atlassian
> > > m: +61 407 570 658
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> --
> Michael Gehrmann
> Senior Network Engineer - Atlassian
> m: +61 407 570 658
> ___
> 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] Recommended firmware for QFX5100-48T

[Graham Brown]

Hi Paul,

Correct, just use 'replace pattern xe-0/0/0 with ge-0/0/0' etc and you
should be fine.

Cheers,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 11 October 2016 at 07:05, Paul S. <cont...@winterei.se> 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
>>>
>>>
>>
> ___
> 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] Etherchannel Cisco - Juniper and firewall filter

[Graham Brown]

+1 for the last suggestion. Keep it simple; EIGRP not running on those
links is the answer - same for CDP, UDLD etc etc

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 10 September 2016 at 08:44, Niall Donaghy <niall.dona...@geant.org>
wrote:

> Hi Lucio,
>
> A few thoughts that occur to me:
>
> - Your configuration looks 100% correct; I am equally surprised it
> dropped traffic.
> - Is the Junos code in production and in lab the same?
> - Perhaps try the same filter in production but without the
> discard action. Check if the counter is working as expected.
> - You could try filtering out destination-address 224.0.0.10/32.
>
> - But ... why not just set EIGRP to passive on that interface, eg:
>
> C3750(config)#router eigrp 
> C3750(config-router)#passive-interface 
>
> Kind regards,
> Niall
>
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf Of Valentini, Lucio
> > Sent: 09 September 2016 15:37
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Etherchannel Cisco - Juniper and firewall filter
> >
> > Hi there,
> >
> > I  have a Juniper EX4200 connected through an etherchannel with a Cisco
> C3750; I noticed (with the "monitor traffic interface ae1"
> > command)
> > the interface on the Juniper was receiving EIGRP Hello packets,  I
> applied this filter on the input in order to stop/drop these
> packets,
> > because as far as I know there is no EIGRP-speaking router on the other
> side of the Juniper switch.
> >
> > set firewall family ethernet-switching filter block-Eigrp term
> block-Eigrp from destination-mac-address 01:00:5e:00:00:0a/48
> > set firewall family ethernet-switching filter block-Eigrp term
> block-Eigrp then discard
> > set firewall family ethernet-switching filter block-Eigrp term
> block-Eigrp then count eigrp-count
> > set firewall family ethernet-switching filter block-Eigrp term
> traffic-allow then accept
> >
> > information was taken from: https://kb.juniper.net/
> InfoCenter/index?page=content=KB14893=search
> >
> > where they say that the  mac-address 01:00:5e:00:00:0a/48 is used by
> EIGRP.
> >
> > But instead of dropping only the EIGRP packets, the filter dropped
> traffic as well and the result was really bad.
> >
> > Strangely enough, I tried to replicate the problem in the lab: I
> connected a Cisco router´s EIGRP Hello-generating interface to an
> EX4200,
> > configured the IP addresses and the ping worked fine both ways.
> >
> > Any ideas about how to drop only Hello packets without causing
> disruption ?
> > Thanks
> >
> > Cheers
> >
> > Lucio
> >
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Interfaces with copper SFPs not getting torn down when partner is disabled (not correctly recognizing Media type?)

[Graham Brown]

Hi Jason,

What your SE has told you is perfectly true, that third party transceivers
are supported - however, not all transceivers are created equally, nor
encoded correctly.

From your experience above, I would stick to Finistar for production and
earmark the rest for lab use only.

Once you find a good supplier, stick with them and if you find any issues,
they will generally work with you to assist.

Cheers,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 20 July 2016 at 03:59, Jason Lixfeld <jason-j...@lixfeld.ca> wrote:

> Hi Brian,
>
> A couple of OEM and one Finisar.  All show up as Media type: Fiber
>
> ario@lab01.juniper# run show chassis pic fpc-slot 0 pic-slot 1
> FPC slot 0, PIC slot 1 information:
>   Type 10x 1GE SFP
>   StateOnline
>   PIC version  2.4
>   Uptime 3 days, 18 hours, 11 minutes, 58 seconds
>
> PIC port information:
>  FiberXcvr vendor   Wave-
>   Xcvr
>   Port Cable typetype  Xcvr vendorpart number
>  length   Firmware
>   0GIGE 1000Tn/a   OEMGLC-T-BF
> UNKNOWN WAVELENGTH1 nm - UNKNOWN WAVELENGTH2 nm 0.0
>   1GIGE 1000Tn/a   FINISAR CORP.  FCLF-8521-3   n/a
>   0.0
>
> [edit]
> ario@lab01.juniper# run show chassis pic fpc-slot 0 pic-slot 3
> FPC slot 0, PIC slot 3 information:
>   Type 10x 1GE SFP
>   StateOnline
>   PIC version  2.4
>   Uptime 3 days, 18 hours, 12 minutes, 10 seconds
>
> PIC port information:
>  FiberXcvr vendor   Wave-
>   Xcvr
>   Port Cable typetype  Xcvr vendorpart number
>  length   Firmware
>   0GIGE 1000Tn/a   OEMGLC-T-BF
> UNKNOWN WAVELENGTH1 nm - UNKNOWN WAVELENGTH2 nm 0.0
>
> [edit]
> ario@lab01.juniper#
>
> I did some further testing Intra-9204 OEM to OEM, Intra-9204 OEM to
> Finisar, 9204 OEM to Cisco built-in copper and 9204 Finisar to Cisco built
> in copper:
>
> Intra-9204 Finisar to OEM:
> Finisar shut down, OEM does not respond.
> OEM shut down, Finisar responds.
>
> Intra-9204 OEM to OEM:
> OEM1 shut down, OEM2 does not respond.
>
> 9204 OEM to Cisco built-in copper:
> 9204 shut down, Cisco responds.
> Cisco shut down, 9204 does not respond.
>
> 9204 Finisar to Cisco built-in copper:
> 9204 shut down, Cisco responds.
> Cisco shut down, 9204 responds.
>
> So based on these results, the Finisar seems to behave correctly, and if I
> physically disconnect the cable between the two Intra-9204 OEMs, the both
> sides in fact stay up.  So it looks like this is yet another case of what
> Graham reported below.
>
> > On Jul 19, 2016, at 10:28 AM, Brian Ross <br...@brains-lans.com> wrote:
> >
> > Jason,
> >
> > What Vendor do your transceivers show up as in 'show chassis pic
> > fpc-slot  pic-slot 
> >
> > Ive had bad experiences with 3rd party copper trispeed spfs that don't
> > show up as 'Methode Electric.'
> >
> > Brian
> >
> >
> > On 19 July 2016 at 15:15, Jason Lixfeld <jason-j...@lixfeld.ca> wrote:
> >> Hi Graham,
> >>
> >> These are 3rd party.  I was told that by my SE that the platform fully
> supports 3rd party optics... not that that really means anything :)
> >>
> >>> On Jul 18, 2016, at 4:38 PM, Graham Brown <
> juniper-...@grahambrown.info> wrote:
> >>>
> >>> Hi Jason,
> >>>
> >>> Are these SFPs Juniper supplied or third party? Over the years there
> have been many documented issues with Base-T SFPs, where you lose physical
> and they report as being up.
> >>>
> >>> IIRC, the Juniper supplied SFPs are ok and I have tested third party
> ones that do work, but it's a little hit and miss.
> >>>
> >>> NB: I have not tested the EX9200.
> >>>
> >>> HTH,
> >>> Graham
> >>>
> >>> Graham Brown
> >>> Twitter - @mountainrescuer
> >>> LinkedIn
> >>>
> >>> On 19 July 2016 at 08:04, Jason Lixfeld <jason-j...@lixfeld.ca> wrote:
> >>> Hey there,
> >>>
> >>> I’m messing around with a lab EX9204 with a EX9200-40x1G-SFP running
> 14.2R4.9
> >>>
> >>> I’ve got two ports (on the same box) connected together with
> 10/100/1000T SFPs in eac

Re: [j-nsp] Interfaces with copper SFPs not getting torn down when partner is disabled (not correctly recognizing Media type?)

[Graham Brown]

Hi Jason,

Are these SFPs Juniper supplied or third party? Over the years there have
been many documented issues with Base-T SFPs, where you lose physical and
they report as being up.

IIRC, the Juniper supplied SFPs are ok and I have tested third party ones
that do work, but it's a little hit and miss.

NB: I have not tested the EX9200.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 19 July 2016 at 08:04, Jason Lixfeld <jason-j...@lixfeld.ca> wrote:

> Hey there,
>
> I’m messing around with a lab EX9204 with a EX9200-40x1G-SFP running
> 14.2R4.9
>
> I’ve got two ports (on the same box) connected together with 10/100/1000T
> SFPs in each.
>
> ario@lab01.juniper# show interfaces | display set
> set interfaces ge-0/1/0 unit 0
> set interfaces ge-0/3/0 unit 0
>
> ario@lab01.juniper# run show lldp neighbors
> Local InterfaceParent InterfaceChassis Id  Port info
> System Name
> ge-0/1/0   -   30:7c:5e:96:ac:80   ge-0/3/0
>lab01.juniper
> ge-0/3/0   -   30:7c:5e:96:ac:80   ge-0/1/0
>lab01.juniper
>
> [edit]
> ario@lab01.juniper#
>
> I’m noticing that if I disable either interface, it’s partner interface
> does not go down.  I’m not talking about Ethernet OAM, just simple layer 1
> link detection with copper SFPs.  In my past experiences with various Cisco
> platforms, this works with no special configuration required.  One thing of
> interest is that the box thinks the media type is Fiber.
>
> ario@lab01.juniper# set interfaces ge-0/1/0 disable
>
> [edit]
> ario@lab01.juniper# commit
> commit complete
>
> [edit]
> ario@lab01.juniper# Jul 18 15:56:42.333 2016  lab01.juniper mib2d[2006]:
> %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 558, ifAdminStatus down(2),
> ifOperStatus down(2), ifName ge-0/1/0
>
>
> [edit]
> ario@lab01.juniper# run show interfaces ge-0/1/0
> Physical interface: ge-0/1/0, Administratively down, Physical link is Down
>   Interface index: 149, SNMP ifIndex: 558
>   Link-level type: Ethernet, MTU: 1514, MRU: 0, LAN-PHY mode, Speed:
> 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
> Source filtering: Disabled,
>   Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online,
> Media type: Fiber
>   Device flags   : Present Running Down
>   Interface flags: Hardware-Down Down SNMP-Traps Internal: 0x4000
>   Link flags : None
>   CoS queues : 8 supported, 8 maximum usable queues
>   Current address: 30:7c:5e:96:a5:65, Hardware address: 30:7c:5e:96:a5:65
>   Last flapped   : 2016-07-18 15:56:42 EDT (00:00:11 ago)
>   Input rate : 0 bps (0 pps)
>   Output rate: 0 bps (0 pps)
>   Active alarms  : LINK
>   Active defects : LINK
>   Interface transmit statistics: Disabled
>
>   Logical interface ge-0/1/0.0 (Index 345) (SNMP ifIndex 570)
> Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2
> Input packets : 3
> Output packets: 4
> Protocol multiservice, MTU: Unlimited
>
> [edit]
> ario@lab01.juniper# run show interfaces ge-0/3/0
> Physical interface: ge-0/3/0, Enabled, Physical link is Up
>   Interface index: 169, SNMP ifIndex: 526
>   Link-level type: Ethernet, MTU: 1514, MRU: 0, LAN-PHY mode, Speed:
> 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
> Source filtering: Disabled,
>   Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online,
> Media type: Fiber
>   Device flags   : Present Running
>   Interface flags: SNMP-Traps Internal: 0x4000
>   Link flags : None
>   CoS queues : 8 supported, 8 maximum usable queues
>   Current address: 30:7c:5e:96:a6:af, Hardware address: 30:7c:5e:96:a6:af
>   Last flapped   : 2016-07-18 14:52:35 EDT (01:04:23 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/3/0.0 (Index 348) (SNMP ifIndex 544)
> Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
> Input packets : 4
> Output packets: 4
> Protocol multiservice, MTU: Unlimited
>
> [edit]
> ario@lab01.juniper#
>
> Am I missing something somewhere?
>
> Thanks in advance.
> ___
> 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] Questions about T640

[Graham Brown]

I'm sorry, but I'd agree with the others in that I'd replace an M series
with an MX or a T series with the PTX.

As Jimmy has shown, the vast majority of parts have been EOL'd and if I
were investing in a new device it would be the MX or PTX.

I'm very surprised that the T Series works out cheaper, although I'm not
sure what discounts you have been quoted so this may have a significant
impact.

If it were my network, I'd go with the MX480 or 960 as PE.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 11 April 2016 at 19:10, Jimmy <hngji...@gmail.com> wrote:

> resend
>
> I'm sorry,
> For T640, How about this announcement ?
> https://gallery.mailchimp.com/1466897c24c515e6739f14c9e/files/TSB16819.pdf
>
> On Mon, Apr 11, 2016 at 2:55 PM, Alireza Soltanian <soltan...@gmail.com>
> wrote:
>
> > No T640 and T4000 are still manufactured. Anyway is there anybody who can
> > provide answer?
> > On Apr 11, 2016 11:24 AM, "Fredrik Korsbäck" <hu...@nordu.net> wrote:
> >
> > > You do realize that most of T-series is EOL?
> > >
> > > Hugge@ as2603
> > >
> > > > 11 Apr 2016 kl. 07:02 skrev Alireza Soltanian <soltan...@gmail.com>:
> > > >
> > > > Hi
> > > >
> > > > Yes the price of MX Series is much higher.
> > > >
> > > >
> > > >
> > > > From: Josh Reynolds [mailto:j...@kyneticwifi.com]
> > > > Sent: Monday, April 11, 2016 9:27 AM
> > > > To: Alireza Soltanian <soltan...@gmail.com>
> > > > Cc: Juniper List <juniper-nsp@puck.nether.net>
> > > > Subject: Re: [j-nsp] Questions about T640
> > > >
> > > >
> > > >
> > > > Any reason to not go with the MX line here?
> > > >
> > > > On Apr 10, 2016 11:55 PM, "Alireza Soltanian" <soltan...@gmail.com
> > > <mailto:soltan...@gmail.com> > wrote:
> > > >
> > > > Hi everybody
> > > >
> > > > We are going to change our M320 router with T640. There are some
> > concerns
> > > > about supported features on T640. We need to have following features
> on
> > > this
> > > > router:
> > > >
> > > >
> > > >
> > > > 1-  GRE Tunnels
> > > >
> > > > 2-  GRE Keepalive (OAM)
> > > >
> > > > 3-  802.1q over 802.1ad
> > > >
> > > > 4-  MPLS TE
> > > >
> > > > 5-  ATOM VLAN re-write
> > > >
> > > >
> > > >
> > > > We need to handle up to 80Gbps of traffic. Here is the setup:
> > > >
> > > > For Module setup we are going to use following FPC:
> > > >
> > > > -  T640-FPC3-ES
> > > >
> > > > For Physical connections we are going to use following PICs:
> > > >
> > > > 1-  PC-1XGE-TYPE3-XFP-IQ2
> > > >
> > > > 2-  PC-1XGE-XENPAK
> > > >
> > > > For GRE tunnels we are going to use following PICs:
> > > >
> > > > PC-Tunnel
> > > >
> > > > For Routing Engine following item is considered:
> > > >
> > > > -  RE- A-2000-4096-BB
> > > >
> > > > For SIB:
> > > >
> > > > -  SIB-I-T640-B
> > > >
> > > > For Control Board:
> > > >
> > > > -  CB-L-T
> > > >
> > > > And for Connector interface panel:
> > > >
> > > > -  CIP-L-T640-S
> > > >
> > > > Is there anybody here who can guide me is this setup good or not and
> > can
> > > I
> > > > have the mentioned feature with T640? Also is there any note about
> > > required
> > > > JunOS version of this setup?
> > > >
> > > >
> > > >
> > > > Thank you
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > juniper-nsp mailing list juniper-nsp@puck.nether.net  > > juniper-nsp@puck.nether.net>
> > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > > >
> > > > ___
> > > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > >
> > >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> 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] Best Place to Buy Used Juniper

[Graham Brown]

Thanks Damien ;),

Colton, I've never received pricing from them so don't know. I'm NZ based
and have always worked for a VAR so all my quotes are from Huniper direct
and have been brand new.

I suspect that they will be more expensive than EBay. But it's like buying
a used Audi from the main dealer, you get the piece of mind and warranty
that you won't from a private or third party sale. Worth every dollar if
you have a critical network.

Cheers,
Graham

On Tuesday, 29 March 2016, Damien DeVille <damien.devi...@gmail.com> wrote:

> I would suggest that this is different from other used gear options in
> that it is actually gear that is officially certified by Juniper and is not
> "grey market".  This means that you don't have to pay to get it inspected
> and reinstated per
> http://www.juniper.net/support/inspection_reinstatement.pdf.
>
> Juniper partnered with PureWRX to make this program work.
>
> Check out http://junipercpo.net/why-buy-jcpo/ and
> http://www.businesswire.com/news/home/20150810005317/en/PureWRX-Partners-Juniper-Networks-Offer-Certified-Pre-Owned
> for more information.
>
>
>
>
> - Damien
>
> On Mon, Mar 28, 2016 at 12:49 PM, Colton Conor <colton.co...@gmail.com
> <javascript:_e(%7B%7D,'cvml','colton.co...@gmail.com');>> wrote:
>
>> Graham,
>>
>> I have never seen this  http://junipercpo.net/ website until now. Are
>> they
>> really any different than the rest of the used Juniper guys? How does
>> their
>> pricing compare to what you see on eBay for example?
>>
>> On Sat, Mar 26, 2016 at 5:44 PM, Graham Brown <
>> juniper-...@grahambrown.info
>> <javascript:_e(%7B%7D,'cvml','juniper-...@grahambrown.info');>>
>> wrote:
>>
>> > Hi Colton,
>> >
>> > The official used, Juniper-certified gear is available here:
>> > http://junipercpo.net/
>> >
>> > HTH,
>> > Graham
>> >
>> > Graham Brown
>> > Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
>> > LinkedIn <http://www.linkedin.com/in/grahamcbrown>
>> >
>> > On 27 March 2016 at 06:10, Colton Conor <colton.co...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','colton.co...@gmail.com');>> wrote:
>> >
>> >> Where is the best place to buy used Juniper gear?
>> >> ___
>> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> <javascript:_e(%7B%7D,'cvml','juniper-nsp@puck.nether.net');>
>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>
>> >
>> >
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> <javascript:_e(%7B%7D,'cvml','juniper-nsp@puck.nether.net');>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>

-- 
-sent from my iPhone; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Best Place to Buy Used Juniper

[Graham Brown]

Hi Colton,

The official used, Juniper-certified gear is available here:
http://junipercpo.net/

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 27 March 2016 at 06:10, Colton Conor <colton.co...@gmail.com> wrote:

> Where is the best place to buy used Juniper gear?
> ___
> 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] purpose of "commit check"?

[Graham Brown]

I echo what Harald mentions, I also follow with 'commit check' after using
'commit confirmed <> comment <> | display detail | no-more'

The | display detail is very handy when dealing with SRX with huge
configurations or in clusters that can take a worrying amount of time to
complete (especially at 03:00).

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>

On 29 September 2015 at 10:37, Harald F. Karlsen <elf...@gmail.com> wrote:

>
>
> On 28.09.2015 23:24, Martin T wrote:
>
>> Hi,
>>
>> when I commit the candidate configuration in Junos, I tend to execute
>> "commit check" and if configuration check succeeds, then I execute
>> "commit comment ". However, when I think about it, "commit
>> (comment)" itself should perform those very same checks that "commit
>> check" does. If yes, then what is the point of "commit check"? Only
>> purpose I could see is to check the validity of the candidate
>> configuration in the middle of the configuration process, i.e. to
>> check if the changes made in candidate configuration so far are fine
>> but the candidate configuration is not ready to be committed.
>>
>>
> You can use "commit check" to confirm a "commit confirmed" action. That
> way you don't create a new configuration file in your rollback log every
> time you cancel a pending rollback.
>
> --
> Harald
>
> ___
> 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] Juniper Optics 10G SM XFP

[Graham Brown]

Hi David,

I have investigated this a little and can't find anything conclusive,
perhaps it's for 'channelised / concatenated'? I've checked on the most up
to date price list and only the 'XFP-10G-L-OC192-SR1' model is actually
available to order for the T,M,MX,PTX platforms.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 7 July 2015 at 11:17, David Miller dmil...@tiggee.com wrote:


 Can anyone tell me the differences between these two optics?

 XFP-10G-L-OC192-SR1  740-014279
 XFP-10G-L-OC192-SR1-C  740-031833

 -DMM


 ___
 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] /config/rescue.conf.gz

[Graham Brown]

Hello Victor,

You are quite correct that you normally can only save the current
configuration file; however I have just tested your assumption and this
does work.
The only snag was that I couldn't directly SCP the file onto the Juniper
back in the correct directory (I didn't try as root), I put the file in
/var/tmp then dropped into the shell and moved it over.

rollback rescue then loaded the file which I created.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 2 July 2015 at 20:44, Victor Sudakov v...@mpeks.tomsk.su wrote:

 Dear Colleagues,

 If I want my rescue configuration to be totally different from the
 current config, how do I edit/upload it? Because the request system
 configuration rescue save saves the current config as rescue.

 I just want a DHCP client on the management interface and some
 local login/password authentication for a possible emergency. Anything
 more than that is redundant.

 If I prepare a custom config offline and upload it as
 /config/rescue.conf.gz, will this work?

 --
 Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
 sip:suda...@sibptus.tomsk.ru
 ___
 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] JTAC Recommended Junos Software Versions Old?

[Graham Brown]

Hi Adam,

Apologies for the delay, I have just run your search and have the below:

Narrow Search By
[image: Down Arrow]
Resolved In
Fixed in 12.3R8(86)
Fixed in between(285)
Fixed in 13.3R6(128)
Fixed later (382)
Unresolved(122)
[image: Down Arrow]
Status
Closed(500+)
Open(293)
[image: Down Arrow]
Severity
Critical(59)
Major(500+)
Minor(218)

It must be an account level problem, I'd get in touch with your local SE,
or have a chat with David Bell as he'll have used that feature in the past.

Cheers,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 13 May 2015 at 21:59, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote:

  Graham Brown
  Sent: 13 May 2015 01:56
  Colton,
 
  Read the release notes for the version you are going to for any changes
  which may have been introduced.
  Further to that, you can use the PR search tool at
  https://prsearch.juniper.net/InfoCenter/index?page=prsearch and enter
  the
  current Junos version, platform currently being used and the version you
  intend to go to. This will display bugs resolved and outstanding.
 
  From the above, you can make an informed decision on whether there are
  any
  showstoppers, you can also run a POC internally to test critical
 features.
 
  HTH,
  Graham
 

 Hi Graham,

 For me if I click on the search button nothing happens.
 Was trying to search for MX 12.3R8 to 13.3R6
 Is it something with my account?

 adam


 --
 This email has been scanned for email related threats and delivered safely
 by Mimecast.
 For more information please visit http://www.mimecast.com
 --

___
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?

[Graham Brown]

Colton,

Read the release notes for the version you are going to for any changes
which may have been introduced.
Further to that, you can use the PR search tool at
https://prsearch.juniper.net/InfoCenter/index?page=prsearch and enter the
current Junos version, platform currently being used and the version you
intend to go to. This will display bugs resolved and outstanding.

From the above, you can make an informed decision on whether there are any
showstoppers, you can also run a POC internally to test critical features.

HTH,
Graham



Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 13 May 2015 at 04:29, Colton Conor colton.co...@gmail.com wrote:

 Ah! You are right looks like Juniper recently did update the document now
 recommending Junos 13.3R6! Glad they made the jump now time to upgrade!
 There should be no issues from going from 12.3R8.7 to Junos 13.3R6 right?

 On Tue, May 12, 2015 at 3:38 AM, Euan Galloway 
 euang+juniper-...@lists.eusahues.co.uk wrote:

  On Tue, May 12, 2015 at 12:49:42AM +, Raphael, Tim wrote:
   MX80s are still showing 12.3R8.7 as the recommended.
 
  On http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476 or
  elsewhere?
 
  (I'm liking that that KB says MX recommended version was changed 2
  days before this thread started?)
 
  --
  Euan Galloway
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX5 10G Ports

[Graham Brown]

Hi Colton,

This is now strictly enforced as of 12.2
http://kb.juniper.net/InfoCenter/index?page=contentid=KB23535smlogin=true
(login required). The interfaces will appear and be configurable but a
licence timer will countdown to zero, at which point the interfaces are
deactivated and will go dark. A licence will then need to be applied in
order to reactivate the interfaces.

show system license usage
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
scale-subscriber 0 1000 0 permanent
scale-l2tp 0 1000 0 permanent
scale-mobile-ip 0 1000 0 permanent
mx5-to-mx10-upgrade 1 0 1 29 days
mx10-to-mx40-upgrade 1 0 1 29 days
mx40-to-mx80-upgrade 1 0 1 29 days

show system alarms
3 alarms currently active
Alarm time Class Description
2011-09-08 11:55:08 PDT Minor License grace period for feature
mx40-to-mx80-upgrade(104) is about to expire
2011-09-08 11:55:08 PDT Minor License grace period for feature
mx10-to-mx40-upgrade(103) is about to expire
2011-09-08 11:55:08 PDT Minor License grace period for feature
mx5-to-mx10-upgrade(102) is about to expire

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 1 May 2015 at 08:43, Colton Conor colton.co...@gmail.com wrote:

 I know legally you are not supposed to use the four 10G built in ports on a
 Juniper MX5 unless you buy an upgrade license to a MX40 or MX80 level. I
 would like to know if technically will these ports work, or has Juniper
 software locked them down?

 Some old posts said that they have not locked them down.Others say you can
 use it for 30 days, but then they don't mention what happens after 30 days?
 Some say you can use it, but then the box constantly throws errors.

 I see from the feature explorer, version Junos OS 13.2R1 has a  Enforcing
 license-based restrictions while upgrading Junos OS feature.This feature
 is provided along with support for an upgrade license key for license-based
 features. When upgrading a Junos OS installation, a license for a feature
 is considered valid if the release version in the license key is greater
 than or equal to the release version of the software upgrade. Valid license
 keys are displayed in the output of the show system license command.


 http://www.juniper.net/techpubs/en_US/junos14.2/topics/concept/junos-license-key-components.html

 In this guide it says: Restricting port capacity is achieved by making a
 set of MIC slots and ports licensable. MICs without a license are locked,
 and are unlocked or made usable by installing appropriate upgrade
 licenses. The
 base capacity of a router is identified by the Ideeprom assembly ID (I2C
 ID), which defines the board type. However, the Junos OS licensing
 infrastructure allows the use of restricted ports without a license for a
 grace period of 30 days. After the grace period expires, the router reverts
 back to the base capacity if no upgrade license is purchased and installed
 for the locked ports.
 Does anyone have real world experience with using the 10G ports on a MX5?
 ___
 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] MX80 Sampling - High CPU

[Graham Brown]

12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think
there are many people waiting for these two releases...

Cheers,

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On 24 September 2014 03:18, Justin M. Streiner strei...@cluebyfour.org
wrote:

 Sounds like you are running into bugs PR963060 or PR671136.

 This is supposed to be fixed in 12.3R8 which is supposed to be released
 very soon.

 We ran into this behavior on a pair of MX480s and had to disable sampling
 for the time being.

 jms


 On Tue, 23 Sep 2014, Ritz Rojas wrote:

  We have a few MX80s (MX80-48T) that we're looking to deploy in certain
 applications where they'll be taking full Internet tables (v4 and v6).  We
 also have a need to gather flow data on our routers, and have noticed an
 interesting trend in the lab.

 We are not using an MS-MIC currently.

 This test box is running 12.3R7.7 at the moment, but we've seen this same
 thing in 11.4 too.

 When set up with full Internet routes and sampling is enabled, each time a
 commit is made for any change at all, RPD and sampled take turns grinding
 the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
 changes to BGP policy sometimes stall and take a decent amount of time (on
 the order of several minutes or more) to actually take effect.

 First RPD will climb up to almost 100% CPU utilization, chew it for a few
 minutes, then it'll go down and sampled will climb up to almost 100% for
 it's couple minutes turn and chew a bit.  Then sampled goes back down and
 RPD takes back over to 100% for a few more minutes.  Eventually it all
 finally calms back down and normalizes back to expected levels.

 Turn off sampling, and any CPU spikes post-commit are only on the order of
 seconds, not minutes, and any policy changes take effect pretty much
 immediately.

 We've seen this regardless of how flow is configured; we've configured
 flow
 with a simple config, as well as inline jflow, pretty much with the same
 results.  We're curious if anyone's had any of these same problems with
 jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
 weak sisters), and if there's any fix beyond the usual Doctor, it hurts
 when I do this, what should I do?.  Don't do that!.

 It's a nice feature, shame that using it seems to come with this heavy a
 price.

 As an aside, we also see a bit of a slowdown in the RIB/FIB
 learning/purging on BGP session turnup/reset, which we're well aware is a
 known issue with sampling enabled, so I won't be shocked if this is just
 how it is.  I'd love to be wrong.

 Here's our sampling config, quick and dirty, regular and inline jflow, in
 case we're missing something.

 Normal Sampling:

 router show configuration forwarding-options
 sampling {
input {
rate 8192;
run-length 0;
max-packets-per-second 2;
}
family inet {
output {
flow-server x.x.x.x {
port x;
version 5;
}
}
}
 }

 router show configuration interfaces xe-0/0/0
 unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
 }


 Inline Jflow Sampling:

 router show configuration forwarding-options
 sampling {
instance {
BLAH-INSTANCE {
input {
rate 5000;
}
family inet {
output {
flow-server x.x.x.x {
port ;
autonomous-system-type origin;
no-local-dump;
version-ipfix {
template {
BLAH-TEMPLATE;
}
}
}
inline-jflow {
source-address x.x.x.x;
}
}
}
}
}
 }

 router show configuration chassis
 tfeb {
slot 0 {
sampling-instance BLAH-INSTANCE;
}
 }


 router show configuration services
 flow-monitoring {
version-ipfix {
template BLAH-TEMPLATE {
flow-active-timeout 10;
flow-inactive-timeout 10;
template-refresh-rate {
packets 1;
seconds 10;
}
option-refresh-rate {
packets 1;
seconds 10;
}
ipv4-template;
}
}
 }


 router show configuration interfaces xe-0/0/0
 unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
 }
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

  ___
 juniper-nsp mailing

Re: [j-nsp] Inline jflow - No hash table changes

[Graham Brown]

Hi Scott,

Without taking a look at the implementation guides I can't answer this with
100% certainty, however look for PRs before deploying inline-jflow as it's
bitten a fair few people.

We're currently waiting for the next release of Junos to resolve a jflow
issue / issues.

Cheers,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On 12 September 2014 08:42, Scott Harvanek scott.harva...@login.com wrote:

 Hey guys,

 Quick question, if we setup inline jflow on a MX480 and do not adjust the
 hash table sizes, will the FPC still restart?*

 Specifically the config change would look like this ( MX480 VC, member 1,
 FPC 0(VC FPC 12) would be put into this but not member 0 ):


 [edit chassis]
 +   member 1 {
 +   fpc 0 {
 +   sampling-instance 480flows;
 +   }
 +   }
 [edit]
 +  services {
 +  flow-monitoring {
 +  version-ipfix {
 +  template ipv4 {
 +  flow-active-timeout 60;
 +  flow-inactive-timeout 60;
 +  template-refresh-rate {
 +  packets 1000;
 +  seconds 10;
 +  }
 +  option-refresh-rate {
 +  packets 1000;
 +  seconds 10;
 +  }
 +  ipv4-template;
 +  }
 +  }
 +  }
 +  }
 [edit interfaces xe-12/1/0 unit 716 family inet]
 +   sampling {
 +   input;
 +   }
 [edit]
 +  forwarding-options {
 +  sampling {
 +  instance {
 +  480flows {
 +  input {
 +  rate 1;
 +  }
 +  family inet {
 +  output {
 +  flow-server x.x.x.x {
 +  port 2055;
 +  version-ipfix {
 +  template {
 +  ipv4;
 +  }
 +  }
 +  }
 +  inline-jflow {
 +  source-address x.x.x.x;
 +  }
 +  }
 +  }
 +  }
 +  }
 +  }
 +  }


 * I find it pretty annoying the FPC will restart on the hash updates if
 you want to adjust the defaults...
 ___
 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] 12.1X for SRX

[Graham Brown]

Hi Quoc,

Just to add what Tyler has already provided. I have been running SRX,
mainly branch on 12.1R6.5 since release without a single bug. 12.1X44D30
since release without issue and I'm now evaluating 12.1X46D20 - no bugs
found yet.

Were talking about hundreds of SRX, not just a few. Granted, not all
features are used but I've certainly found the code to be rock solid.

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On 23 August 2014 11:05, Tyler Christiansen ty...@adap.tv wrote:

 Have used 12.1X on branch (550) and HE (1400) for over a year without any
 (known) bugs.  Ran into one issue on one of the 1400s in which IPSec phase
 1  2 would establish (and re-establish after being cleared) but would not
 forward IPSec traffic for route-based or policy-based tunnels.  Traffic
 forwarding for everything except IPSec was fine (otherwise phrase 1/2
 wouldn't come up).  No root cause or bug ID on that one because JTAC was
 taking too long to diagnose, so I'm not sure if it's a 12.1X bug or just a
 random freak accident.

 --tc


 On Fri, Aug 22, 2014 at 3:44 PM, Quoc Hoang via juniper-nsp 
 juniper-nsp@puck.nether.net wrote:

  Hi,
JTAC recently updated their recommendation for SRX to 12.1X which
  specifically supports the security platform.
  We are currently on the 11.4  train (for both branch and HE) but
  evaluating the latest 12.1X as a possible next rev.  Any stability
 concerns
  or major bugs that we should be aware? Would be interested in hearing
  everyone's experiences.
 
  Thanks,
  Quoc
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-ns
  https://puck.nether.net/mailman/listinfo/juniper-nsp
  ​​
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] what is different between virtual router and logical-system

[Graham Brown]

A good overview for logical systems is available at the below link:
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/logical-systems-overview-solutions.html

There is a good discussion from the Juniper Forum too:
http://forums.juniper.net/t5/Routing/Difference-between-logical-router-and-virtual-router/td-p/18694

HTH,
Graham

Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On 24 June 2014 17:16, bruno bruno.juni...@gmail.com wrote:

 Hi guys,


 i have use juniper for long time. but today my colleague ask me what is
 big different bwtween virtual router and logical-system?  from my point of
 view, the big different is interface configuration . with virtual router ,
 interface configuration under global config,while logical -system
 ,configure their interface under logical-system.   anything else ?  pls
 comment .thx.
 --
 Best Regards,
 Bruno
 ___
 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] proposed changes to clear bgp neighbor

[Graham Brown]

Another vote for the 'all' function for all 'clear' commands. BGP, IS-IS etc


On 27 February 2014 04:36, Phil Shafer p...@juniper.net wrote:

 Juniper users,

 We've been asked to make a change the clear bgp neighbor command
 to make the neighbor or all argument mandatory.  The root cause
 is the severe impact of clear bgp neighbor and the increasing
 accidental use of this command without a specific neighbor.

 In general, we avoid changing commands to add mandatory arguments,
 but my feeling is that the impact and severity of this specific
 command makes this an acceptable occasion for such a change.

 I'm looking for feedback about this change.  My working assumption
 is that clear bgp neighbor is a sufficiently rare command and
 would not be used in automation/scripts, so the impact of making
 the neighbor/all argument mandatory would be minimal.  Is this
 assumption accurate?

 Thanks,
  Phil

 [I've set reply-to to myself to avoid impacting the list]

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] fxp0.0 interface match in firewall filter doesn't work in JUNOS 12.3R5.7

[Graham Brown]

HI Tore,

Thanks for the heads up - I had earmarked this version for a project so
I'll test around this first.

Cheers,
Graham


On 21 January 2014 14:35, Tore Anderson t...@fud.no wrote:

 This is a heads-up to anyone planning to upgrade to 12.3R5.7, especially
 if you don't have easy access to the serial console, but only a firewall
 term such as:

 term allow-oob-management {
 from {
 interface fxp0.0;
 }
 then accept;
 }

 ...in your lo0.0 input filter (which presumably then goes on to drop all
 unmatched traffic): It simply doesn't work.

 I've confirmed on both MX80 and MX240, several times. After a reboot,
 the term just gets skipped, it seems. Deactivating the term, committing,
 and then reactivating it fixes the problem but that might of course be
 easier said than done if locked out of the box.

 Terms doing source-address matches seems to work fine.

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Difference between an MX80 and MX80-5G-AC-ADV

[Graham Brown]

HI Skeeve,

Two sites for you to save are:

https://chassisanalyzer.juniper.net/ca/
Paste in the output from 'show chassis hardware' and you'll get a full
breakdown of all supported FRUs, which you can paste into the second link
below:

http://tools.juniper.net/SerialNumberEntitlementSearch/ - this shows you
whether you have support and if so what contract and terms, or whether you
are within the warranty period etc.

As for your particular chassis, I'd have to use Google Fu and the beach is
calling...

HTH,
Graham


On 31 December 2013 11:16, Skeeve Stevens 
skeeve+juniper...@eintellegonetworks.com wrote:

 Hey all,

 How do I tell if an MX80 is a full MX80 or a MX80-5G-AC-ADV which was for
 partners a few years ago.

 Is there anything on the hardware which makes it difference, or any way to
 be able to tell.

 Is there any serial number check with Juniper that will be able to say what
 it should be and what the J-Care if purchased will be?

 ...Skeeve

 *Skeeve Stevens - *eintellego Networks Pty Ltd
 ske...@eintellegonetworks.com ; www.eintellegonetworks.com

 Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

 facebook.com/eintellegonetworks ;  http://twitter.com/networkceoau
 linkedin.com/in/skeeve

 twitter.com/theispguy ; blog: www.theispguy.com


 The Experts Who The Experts Call
 Juniper - Cisco - Cloud - Consulting
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 100% CPU HIT on EX4200

[Graham Brown]

Hi Sam,

'show chassis routing-engine' and 'show system processes extensive' are two
commands to start with, when investigating this issue.

The second command will show you what process is consuming resources etc.

HTH,
Graham


On 8 November 2013 13:51, Samol molas...@gmail.com wrote:

 Hi All,

 CPU on EX4200 run up to 100% for a period of time and I have not yet found
 what caused this. Based on your experiences, what are the things that can
 cause this and what are the commands to check this ?

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JNCIS SP

[Graham Brown]

In addition to the great resources available within the Fast Track section,
I can recommend the MX Series O'Reilly book written by Doug Hanks and Harry
Reynolds - http://www.juniper.net/us/en/training/jnbooks/mx-series.html

I used this, along with the Fast Track material to pass my JNCIS-SP.

Good luck with the studying!

Graham Brown
Network Engineer
Snap Internet
Christchurch, New Zealand
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn
http://www.linkedin.com/in/grahamcbrown



On 1 November 2013 04:18, Per Westerlund p...@westerlund.se wrote:

 Once logged in to https://learningportal.juniper.net/, you can navigate to

 Learning Portal Home  Fast Track  JNCIS-SP eLearning  JNCIS-SP Study
 Resources

 There are 3 PDF files available there, study guides for switching, routing
 and MPLS/VPN.

 /Per


 31 okt 2013 kl. 15:55 skrev Mohammad Khalil eng.m...@gmail.com:

  Hi all
  Where can i find the study guide for the JNCIS SP?
 
  Thanks
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp


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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP/LAG

[Graham Brown]

LACP is great until you hit a box that is busy and doesn't offload this to
the line card - for busy switches and firewalls, use periodic-slow instead
of fast - I've had instances of EX and SRX that can't keep up with
periodic-fast and the LAG ends up being torn down during commits.

Bear in mind that this is only on busy boxes and we deploy LACP wherever
possible...

Just my $0.02


On 18 October 2013 10:34, Chris Kawchuk juniperd...@gmail.com wrote:

 I sometimes use LACP as well as a poor man's BFD; in the case of the
 lights are on, but nobody's home syndrome.

 aka a situation where the physical link(s) may be up, but the control
 plane functions are dead at the far end. Without LACP control packets, you
 may inadvertently start trying to send traffic down a link where the other
 end isn't actually functional yet. That's a definite case, albeit for a
 single-link LACP.

 If you can turn it on, and both sides support it, then I suggest using it;
 I haven't seen any harm IMHO.

 - CK.


 On 18/10/2013, at 8:00 AM, Keith kwo...@citywest.ca wrote:

  Both sides came up on the MX and it looks ok. Am I going to get bitten
 in the ass
  at some point for not running LACP?


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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VC question

[Graham Brown]

My $0.02 is that I have worked with the EX4200 VCs since they were first
released and they have proved to work very well indeed. This includes first
hand installation / management and also from a service support aspect.

I have also worked with mixed VCs and these have worked extremely well too.
I'm currently looking at the EX4300 option for a campus re-design and this
looks like a nice upgrade from the EX4200 - CAM wise as well as backplane
throughput.

I've never used another vendors equipment deployed in a similar manner so
can't really compare them, but I'd certainly recommend the Juniper solution.

HTH,
Graham


On 10 October 2013 05:25, Bill Blackford bblackf...@gmail.com wrote:

 Capacity: Looking at the published numbers, a 4200 VC shows 128Gbps. 4300
 shows 320Gbps (this may be the same with the latest Cisco 3800 series).

 Functionality: I've had really good success with my GRES testing on a
 Juniper VC. The Master and Backup nodes are handled as FPC's in the same
 manner that Master and Backup RE's are handled with chassis routers. The
 route process appears to be running on both. Forcing a route engine switch
 dropped no packets (that I was able to notice). I have not done these tests
 with Cisco, especially the latest 3700, 3800's. They may behave in a
 similar manner, nor have I done extensive testing and comparison with
 either vendor's implementation.

 For me, just having both nodes of a two-switch VC act in a familiar manner
 with that of chassis routers, makes managing them much more comforting.




 On Wed, Oct 9, 2013 at 5:09 AM, Phil Bedard phil...@gmail.com wrote:

  The 4500 has a newer module with 64Gbps bi-directional links.  The 4550
  you can use two of the modules to get the 256 number.
 
  Phil
 
   On Oct 9, 2013, at 3:29 AM, Georgios Vlachos 
 g.vlac...@kestrel-is.gr
  wrote:
  
  
   Juniper VC is 32 Gbps per link (2), hence 64 Gbps full duplex actually.
  
  
   -Original Message-
   From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
  Behalf Of
   Maarten van der Hoek
   Sent: Wednesday, October 09, 2013 9:41 AM
   To: 'Phil Fagan'; 'R S'
   Cc: 'juniper-nsp'
   Subject: Re: [j-nsp] VC question
  
   The Junos is of course a big plus...
  
   However next to this the Thoughput should be higher with the Junipers!
  
   As far as my info goes (not much Cisco equipment over here / sorry)
 they
  go
   up to 64 Gps where Juniper can go up to 128 Gbps (EX4200) and EX4550 up
  even
   to 256 Gbps.
  
   Would of course be interesting to hear if somebody has prove for these
   figures?... :-)
  
   Brgds,
  
   Maarten
  
   -Oorspronkelijk bericht-
   Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens
  Phil
   Fagan
   Verzonden: woensdag 9 oktober 2013 4:37
   Aan: R S
   CC: juniper-nsp
   Onderwerp: Re: [j-nsp] VC question
  
   Pro=junos
   Con=nonjunos
  
   :-)
   On Oct 8, 2013 10:05 AM, R S dim0...@hotmail.com wrote:
  
  
  
   Is anybody
   able to tell me which are the very technical pro and cons between
   Juniper VC solution (vccp) against Cisco stack (Stackwise?) and Huwaei
   stack
   (iStack?) solutions ?
  
  
  
  
   Tks
  
  
   ___
   juniper-nsp mailing list juniper-nsp@puck.nether.net
   https://puck.nether.net/mailman/listinfo/juniper-nsp
   ___
   juniper-nsp mailing list juniper-nsp@puck.nether.net
   https://puck.nether.net/mailman/listinfo/juniper-nsp
  
   ___
   juniper-nsp mailing list juniper-nsp@puck.nether.net
   https://puck.nether.net/mailman/listinfo/juniper-nsp
   ___
   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
 



 --
 Bill Blackford

 Logged into reality and abusing my sudo privileges.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos BNG PPPoE inside a VPLS

[Graham Brown]

I've run into a very strange bug on the MX where PPP through a VPLS results
in the packets being mangled - affected circuits have been migrated to
L2VPNs. Although a fix is provided in 12.3R4 which we are currently testing
- I'll dig out the PR when I get into the office.

Graham Brown
Network Engineer
Snap Internet
Christchurch, New Zealand
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On 24 September 2013 21:46, Mark Tinka mark.ti...@seacom.mu wrote:

 On Tuesday, September 17, 2013 04:05:50 PM Adrien Desportes
 wrote:

  Hello William,
 
  Before 13.2 you would have to use an external loop to
  terminate the vpls on one side and the ppp on the other
  side (as lt- interface does not support the proper
  encapsulation for ppp).
 
  Starting 13.2 (that was just released), if you use L2VPN
  rather than VPLS to backhaul your DSLAM VLAN, the below
  feature might do the job w/o consuming ports for the
  external hairpin:
 
  http://www.juniper.net/techpubs/en_US/junos13.2/topics/co
  ncept/pseudowire-subscriber-interfaces-overview.html

 Now I really don't have to have VPLS at all.

 Happy days :-).

 Mark.

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 Install Validation Checklist

[Graham Brown]

Nice list Dave, thanks for the share.

Graham

Graham Brown
Network Engineer
Snap Internet
Christchurch, New Zealand
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On 5 September 2013 08:21, david@orange.com wrote:

 Hi

 Our default check list but that's for post upgrade not really for MX
 install !

 show version invoke-on all-routing-engines
 show system snapshot (on both RE)
 show chassis alarms
 show chassis routing-engine
 show chassis fpc
 show chassis hardware
 show chassis environment
 show chassis power
 show chassis fan
 show chassis fabric summary
 show chassis fabric summary
 show chassis fabric plane
 show chassis fabric fpcs
 show system storage
 show krt state
 show task memory
 show task memory history
 show task jobs
 show system processes summary
 show route summary
 show isis adjacency
 show ldp neighbor
 show ldp session
 show pim neighbor
 show bgp summary
 show vrrp brief
 show interfaces queue | match Physical|drop
 show interfaces statistics detail | match Physical interface|drops|errors
 show pfe stat error
 show system boot-messages
 show log messages | last 500
 show log chassisd  | last 100

 David

 David Roy
 IP/MPLS NOC engineer - Orange France
 Ph. : +33 2 99 87 64 72
 Mob. : +33 6 85 52 22 13
 SkypeID : davidroy.35
 david@orange.com

 //
 JNCIE-SP #703
 JNCIE-ENT #305
 JNCIP-SEC

 -Message d'origine-
 De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part
 de Mark Tinka
 Envoyé : mercredi 4 septembre 2013 17:46
 À : juniper-nsp@puck.nether.net
 Objet : Re: [j-nsp] MX960 Install Validation Checklist

 On Wednesday, September 04, 2013 05:32:34 PM Christopher Costa wrote:

  Curious if there's a  document (or feedback from personal
  experiences) on best-practice steps/commands to validate an MX960
  installation.  For example:
  - power supplies functional
  - fta's functional
  - routing-engines up
  - file system
  - modular cards (SCBs/MPC's, etc)
  - pluggable optics recognized
  - etc

 (run) show chassis hardware detail

 Cheers,

 Mark.


 _

 Ce message et ses pieces jointes peuvent contenir des informations
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
 recu ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and
 delete this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been
 modified, changed or falsified.
 Thank you.


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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX110H2-VA temperature sitting at 67c

[Graham Brown]

Hi Gavin,

I have a box sat on my desk and it's running a similar temperature:
admin@GB-DESK-TEST-UNIT show chassis routing-engine
Routing Engine status:
Temperature 65 degrees C / 149 degrees F

This is running 12.1X44-D20.3.

HTH,
Graham



On 24 August 2013 09:46, Gavin Henry ghe...@suretec.co.uk wrote:

 Hi all,

 Just got one of these in for OoB management and noted it's sitting at
 around 67 Celsius on a lab test bench with lots of space around it in a not
 really hot room.

 On latest 12.1X too. Others seeing this? When it goes to the DC I'm sure it
 will be cooler due to Airton,  but all its doing is ADSL and a few ipsec
 inbound tunnels.

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VC-port over Ethernet

[Graham Brown]

Nick,

Let us know the results of your testing.

However you can disable the default by issuing the below two commands:
request virtual-chassis vc-port delete pic-slot 1 port 2
request virtual-chassis vc-port delete pic-slot 1 port 3

HTH,
Graham


On 15 April 2013 23:54, Nick Kritsky nick.krit...@gmail.com wrote:

 Klaus,

 No, I don't want to form VC between 3300 and 4500.

 nick


 On Mon, Apr 15, 2013 at 2:16 PM, Klaus Groeger kla...@gmail.com wrote:

  Just one word, to double check if i understand you. You would like to
 form
  a VC between 3300 and 4500?
 
  That won't work. You can only form VC between 3300 or between 45xxx and
  4200.
  Klaus
  —
  Sent from Mailbox https://bit.ly/SZvoJe for iPhone
 
 
  On Mon, Apr 15, 2013 at 9:41 AM, Nick Kritsky nick.krit...@gmail.com
 wrote:
 
  Thanks. Just to clarify - I am actually trying to prevent this from
  happening.
  EX-3300 have ports xe-0/1/2 and xe-0/1/3 put in VC-port mode by default.
  So I wonder if two fresh, brand new EX-3300 can form VC when they are
  plugged into upstream 4550 using vc-ports.
  This can explain some strange behavior i was observing recently, but I
  was too busy fixing it, so I didn't run much tests.
  I plan to setup small lab for that. I will let you know of the outcome.
 
  nick
 
 
  On Sun, Apr 14, 2013 at 4:33 PM, Klaus Groeger kla...@gmail.com
 wrote:
 
  Hi
 
  I would recommend Q-in-Q on the intermediate switch. I have seen 4550
 VC
  spanning over metro erhernet, so this should work for 3300 also.
 
  Regards
 
  Klauzi
  —
  Sent from Mailbox https://bit.ly/SZvoJe for iPhone
 
 
  On Sat, Apr 13, 2013 at 9:21 PM, Nick Kritsky nick.krit...@gmail.com
 wrote:
 
  Dear J-NSP,
 
  Can anyone confirm/deny if two EX3300 can form virtual-chassis when
  their
  vc-ports are connected via third switch?
 
  thanks
  nick
  ___
  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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] equivalent of show dsl interface

[Graham Brown]

Hi Ali,

You should be able to use the 'show interfaces interface-name extensive
command. Full DSL statistics are included in this output.

http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-interfaces/jd0e20123.html

HTH,
Graham

On Wednesday, February 27, 2013, Ali Sumsam wrote:

 Hi,
 Does anyone know the equivalent of Cisco commands show dsl interface in
 Junos.
 I want to see the speed of DSL.

 Regards,
 *Ali Sumsam CCIE*
 *Network Engineer - Level 3*
 eintellego Pty Ltd
 a...@eintellego.net javascript:; ; www.eintellego.net

 Phone: 1300 753 383 ; Fax: (+612) 8572 9954

 Cell +61 (0)410 603 531

 facebook.com/eintellego
 PO Box 7726, Baulkham Hills, NSW 1755 Australia

 The Experts Who The Experts Call
 Juniper - Cisco – Brocade - IBM
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VSTP

[Graham Brown]

Hi Mohammed,

From the command you ran you should see the bridge ID for the switch you
are connected to and that of the root bridge. Don't forget that this may be
the same switch. If it is not, look at the root port and work your way
through the switched network. If nothing else you will also know what your
topology really looks like and also work out which switch will become root
if you lose the current root bridge, along with how this would change the
topology.

HTH,
Graham

On Tuesday, December 4, 2012, Mohammad Khalil wrote:

 Hi all
 I have a bridge domain working on several vlans
 The election of the bridge switch is based on the bridge-ID which consists
 of the system MAC address and the priority which is by default 32768
 I am trying to figure out who is the root bridge of my domain but could not
 find it
 I issued the command run show spanning bridge and got the mac address of
 the root bridge , but when searching for it among the other devices could
 not find a match , i used the command show chassis mac
 Any ideas?

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



-- 
-sent from my iPad; please excuse spelling, grammar and brevity-
___
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

[Graham Brown]

Hi Nick,

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.

HTH,
Graham


On 14 November 2012 10:26, Nick Kritsky nick.krit...@gmail.com wrote:

 Hello,

 There is something I don't understand.
 There is a SRX650 running BFD for OSPF sessions. BFD is working, however I
 wanted to make sure that it is processed in PFE.
 All counters of show pfe statistics traffic protocol bfd are zero, but
 BFD-related counters of show pfe statistics traffic are on-zero and
 increasing. What might be the reason of such difference?

 thanks
 Nick

 OS: 10.4R4.5
 BFD is running on ge-0/0/1

 Here is the output of show pfe statistics traffic protocol bfd:
 BFD protocol statistics:
 Packets with invalid interface : 0
 Packets with invalid address family: 0
 Packets with bad IP checksum   : 0
 Packets with bad IP options: 0
 Packets with bad IP length : 0
 Packets with bad udp checksum  : 0
 Packets with bad udp length: 0
 Packets with bad udp ports : 0
 Packets with no logical interface  : 0
 Packets with prefix length mismatch: 0
 Packets received   : 0
 Packets absorbed   : 0
 Packets failed to transmit : 0
 Packets receive failures   : 0
 Packets allocation failures: 0

 And here is the output of show pfe statistics traffic:
 Packet Forwarding Engine traffic statistics:
 Input  packets:  53237611735 5350 pps
 Output packets:  80428514254 7630 pps
 Packet Forwarding Engine local traffic statistics:
 Local packets input : 38162325
 Local packets output: 37968315
 Software input control plane drops  :0
 Software input high drops   :0
 Software input medium drops : 1088
 Software input low drops:0
 Software output drops   :0
 Hardware input drops:0
 Packet Forwarding Engine local protocol statistics:
 HDLC keepalives:0
 ATM OAM:0
 Frame Relay LMI:0
 PPP LCP/NCP:0
 OSPF hello :  1434683
 OSPF3 hello:0
 RSVP hello :0
 LDP hello  :0
 BFD: 26625331
 IS-IS IIH  :0
 LACP   :0
 ARP:  7093341
 ETHER OAM  :0
 Unknown:0
 Packet Forwarding Engine hardware discard statistics:
 Timeout:0
 Truncated key  :0
 Bits to test   :0
 Data error :0
 Stack underflow:0
 Stack overflow :0
 Normal discard : 20239282
 Extended discard   :0
 Invalid interface  :0
 Info cell drops:0
 Fabric drops   :0
 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU
 Error statistics:
 Input Checksum :0
 Output MTU :0
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] juniper MX as BRAS

[Graham Brown]

Hi Shadi,

Juniper published a nice 'Day One' booklet on using the MX as a BRAS.
You'll find a lot of info there as a starting point:
http://www.juniper.net/us/en/community/junos/training-certification/day-one/networking-technologies-series/dynamic-subscriber-management/
Rick Mur also wrote a great blog article on this, when the functionality
was first announced / released:
http://rickmur.wordpress.com/2012/04/13/bras-on-juniper-mx/

HTH,
Graham


On 13 November 2012 12:26, shadi zein shadi.zein...@gmail.com wrote:

 Dear Expertise,

 In my ISP we are investigating to use juniper MX as BRAS, i any one
 can provide me with technical document that cover this point .

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] STP Between Cisco and Juniper

[Graham Brown]

Saba,

I have not tried this myself but after being bitten by Foundry vs Juniper
spanning tree issues; I would highly recommend testing this in a
lab environment before deploying it. I also agree with Jonathan that rstp
would be the logical approach if you do not have to deploy MST.

HTH,
Graham


On 10 November 2012 05:57, Saba Sumsam saba+j...@eintellego.net wrote:

 Hi,
 I have a Layer 2 network consisting of a Cisco 2970G, SRX210 and SRX100.
 Following are the STP modes supported on each:

 Cisco 2970G: mst, pvst, rapid-pvst
 Juniper SRX100: STP, RSTP. MSTP
 Juniper SRX210: STP, RSTP

 My question is: Is Cisco mst interoperable with Juniper RSTP. What mode
 should I be using on each device in this case?

 Suggestions highly appreciated.

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J6350 Router recommended version

[Graham Brown]

Hi Rachid,

Whilst I do not use the J6350 I can tell you that the recommended release
from JTAC is JUNOS 10.4R11.4 (assuming that you have 1GB RAM  1GB Flash)
and JUNOS 10.2R4.8 if not.

I've had a look through the release notes and the J6350 is supported for
the 11.X and 12.1 versions with the same caveat as 10.4R11.4 for memory.

HTH,
Graham

On Wed, Oct 17, 2012 at 10:13 AM, Rachid DHOU rachid.d...@gmail.com wrote:

 Hi experts,

 Does someone use J6350 Router ?
 Is this router can support JUNOS 11 or 12 ?
 What is the recommended version ?

 What is the requirement on DRAM and compact flash, if we go to 12 ?



 Kind regards,
 Rachid DHOU
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Dynamic Profiles Question

[Graham Brown]

Hi Caillin,

I've not played with the MX for subscriber management specifically; however
Juniper released a PSN on Thursday detailing a special version of
code targeted specifically for these services.

PSN-2012-10-730 - 11.4X27 Release for MX Subscriber Management

All of the release notes and supporting information (scaling limitations
etc) are found from within the PSN.

HTH,
Graham

On Fri, Oct 5, 2012 at 4:26 PM, Caillin Bathern caill...@commtelns.comwrote:

 Hi Everyone,



 I am playing around with subscriber management on 12.2R1.3 MX series in
 the lab at the moment and I have a question about the RI variable.



 https://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/config
 uration-statement/routing-instances-edit-dynamic-profiles.html

 This link says that I can configure a static routing instance name
 rather than using the $junos-routing-instance variable yet I am finding
 I cannot configure this.  Does anyone know how this can be done?



 I also cannot find a way to set a default for the junos-routing-instance
 variable which would be an alternative.  Does anyone know how this can
 be done?



 [edit]

 admin@MX5T# set dynamic-profiles test routing-instances ?

 Possible completions:

   $junos-routing-instance  Dynamic profile routing instance name

 + apply-groups Groups from which to inherit configuration data

 + apply-groups-except  Don't inherit configuration data from these
 groups

 [edit]

 admin@MX5T# set dynamic-profiles test routing-instances internet


 ^

 syntax error.

 admin@MX5T# set dynamic-profiles test routing-instances internet



 I am also seeing some odd behaviour with vlan rewrite/push/pop/bridging
 when using dynamic profiles and vlan auto-configuration.  Has anyone
 else had issues here or have any recommendations?



 Regards,

 Caillin

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] inline-jflow

[Graham Brown]

Hi Moki,

No worries; this is the exact challenge that faced my customer. Their
server was on the management subnet which was only connected to the routers
via the management interfaces. I'm not sure what they did to resolve it; I
would presume that they moved the server.

Sorry that I don't have a better solution for you.
Graham

On Friday, September 7, 2012, moki wrote:

 Thank you Graham,
 I suspected that this is the case ...
 Is there another way to overcome this problem ?
 Because our netflow server connected to OOB management network which is
 routed only via Fxp interface ...

 On Thu, Sep 6, 2012 at 6:55 PM, Graham Brown 
 juniper-...@grahambrown.infojavascript:_e({}, 'cvml', 
 'juniper-...@grahambrown.info');
  wrote:

 Hi Moki,

 The export of flow data is not supported via an fxp interface. The fxp0
 interface does not have the hardware capabilities to handle this kind of
 operation.

 I had a similar customer query a while back; they could configure the
 export of flows via the fxp interface, however it never worked.

 I hope that this is of help,
 Graham
 --
 Graham Brown
 Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
 LinkedIn http://www.linkedin.com/in/grahamcbrown

 On Thu, Sep 6, 2012 at 1:05 PM, moki vom...@gmail.comjavascript:_e({}, 
 'cvml', 'vom...@gmail.com');
  wrote:

 Hello
 Does anyone know if inline-jflow support to send traffic via fxp
 interface.
 I tried to configure inline-jflow with the configuration bellow when the
 route to the destination is the fxp interface:
 family inet {
 output {
 flow-server 88.88.88.1 {-- routed via fxp
 port 2055;
 autonomous-system-type origin;
 version-ipfix {
 template {
 default-temp;
 }
 }
 }
 inline-jflow {
 source-address 88.88.88.2;
 }
 }

 Is it possible ?
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:_e({},
 'cvml', 'juniper-nsp@puck.nether.net');
 https://puck.nether.net/mailman/listinfo/juniper-nsp





-- 
-sent from my iPad; please excuse spelling, grammar and brevity-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] inline-jflow

[Graham Brown]

Hi Moki,

The export of flow data is not supported via an fxp interface. The fxp0
interface does not have the hardware capabilities to handle this kind of
operation.

I had a similar customer query a while back; they could configure the
export of flows via the fxp interface, however it never worked.

I hope that this is of help,
Graham
-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On Thu, Sep 6, 2012 at 1:05 PM, moki vom...@gmail.com wrote:

 Hello
 Does anyone know if inline-jflow support to send traffic via fxp interface.
 I tried to configure inline-jflow with the configuration bellow when the
 route to the destination is the fxp interface:
 family inet {
 output {
 flow-server 88.88.88.1 {-- routed via fxp
 port 2055;
 autonomous-system-type origin;
 version-ipfix {
 template {
 default-temp;
 }
 }
 }
 inline-jflow {
 source-address 88.88.88.2;
 }
 }

 Is it possible ?
 ___
 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] JNCIA

[Graham Brown]

Hi Mohammad,

Further to what Skeeve has already said, I would recommend having a read of
the Junos for Dummies book. This is a great overview of many topics and how
to perform them on the Junos platform; whilst this is not specific to any
certification in particular, it will certainly help you to use Junos
devices in the future. I'm not sure of your past experience with other
vendors but the majority of people new to Juniper have history with Cisco -
I wrote a blog on going from a CCNA to JNCIA, you can find this
herehttp://forums.juniper.net/t5/My-Certification-Journey/Transitioning-from-CCNA-to-JNCIA/ba-p/112472
.

Good luck with your studies.

On Sun, Jul 29, 2012 at 12:42 AM, Mohammad Khalil eng.m...@gmail.comwrote:

 Hi , I am new to Juniper and I want to go through the certificates
 Any guidelines will be appreciated

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




-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Graham Brown]

Skeeve,

This document shows when features became available in a version of Junos.
The EX2500 does not run Junos; hence it's omission from the document. If
you need a 10Gb switch, look at the EX4500 (or the SFX3500 if you need a
1RU footprint).

HTH
-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On Fri, May 4, 2012 at 5:18 AM, Skeeve Stevens 
skeeve+juniper...@eintellego.net wrote:

 Hey,

 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.

 *Skeeve Stevens, CEO*
 eintellego Pty Ltd
 ske...@eintellego.net ; www.eintellego.net http://www.eintellego.net.au

 Phone: 1300 753 383 ; Fax: (+612) 8572 9954

 Cell +61 (0)414 753 383 ; skype://skeeve

 facebook.com/eintellego

 twitter.com/networkceoau ; www.linkedin.com/in/skeeve

 PO Box 7726, Baulkham Hills, NSW 1755 Australia

 The Experts Who The Experts Call
 Juniper - Cisco – IBM
 ___
 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] Document Update - EX Features

[Graham Brown]

Apologies, I meant the QFX3500.

Graham

On Fri, May 4, 2012 at 9:34 AM, Graham Brown
juniper-...@grahambrown.infowrote:

 Skeeve,

 This document shows when features became available in a version of Junos.
 The EX2500 does not run Junos; hence it's omission from the document. If
 you need a 10Gb switch, look at the EX4500 (or the SFX3500 if you need a
 1RU footprint).

 HTH
 --
 Graham Brown
 Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
 LinkedIn http://www.linkedin.com/in/grahamcbrown

 On Fri, May 4, 2012 at 5:18 AM, Skeeve Stevens 
 skeeve+juniper...@eintellego.net wrote:

 Hey,

 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.

 *Skeeve Stevens, CEO*
 eintellego Pty Ltd
 ske...@eintellego.net ; www.eintellego.net http://www.eintellego.net.au

 Phone: 1300 753 383 ; Fax: (+612) 8572 9954

 Cell +61 (0)414 753 383 ; skype://skeeve

 facebook.com/eintellego

 twitter.com/networkceoau ; www.linkedin.com/in/skeeve

 PO Box 7726, Baulkham Hills, NSW 1755 Australia

 The Experts Who The Experts Call
 Juniper - Cisco – IBM
 ___
 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] dynamic flow control process (High Memory)

[Graham Brown]

Hi Mohammad,

I agree that an upgrade is your best bet. There is a matching PR:
https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR562242

DFCD memory slowly increasing if running dfcd without any trigger, or
without dynamic-flow-capture configuration
Resolved In 10.2R4 10.3R2 10.3R3 10.4R1 11.1R1

HTH
-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown


On Thu, Apr 26, 2012 at 11:22 AM, Ala' Amira aam...@bluezonejordan.comwrote:

 Dear Salbeeso,

 Just try to upgrade the software .

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Salbad
 Sent: Sunday, April 22, 2012 2:01 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] dynamic flow control process (High Memory)

 Hi All



 We have an M10i router running 10.2R3.10 (512M RAM)  ((uptime two years))
 with high memory utilization as follow:

 show chassis routing-engine à Memory utilization  95 percent

 show system processes extensive à 1317 root1  960   372M   363M
 select  39:09  0.00% dfcd



 it has been noted that the dynamic flow control process (dfcd) is taking
 372M of the memory.

 Another thing we've checked another router which was rebooted recently and
 it was OK,,, memory utilization 45% and dfcd allocation is only 30M



 Any ideas 



 Thank you in advance

 M. Salbad



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


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

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

Re: [j-nsp] JNCIP-SP latest dumps

[Graham Brown]

Xu,

Just re-read the JNCIP|E Sybex books, if you use dumps to pass an exam it
is cheating, devalues the certification and posting this sort of request on
a public forum that the Juniper certification team subscribe to is risking
having your certifications revoked.

It means so much more when you actually study hard and pass based on your
own knowledge / merit.
-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On Fri, Mar 30, 2012 at 9:08 AM, Xu Hu jstuxuhu0...@gmail.com wrote:

 Hi Team,
 Just want to check, if there any one have the latest JNCIP-SP dumps?
 Because next week i need to attend the exam.

 Thanks and Regards,
 ___
 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] Logical tunnel encapsulation

[Graham Brown]

Rafael, your memory is spot on. See an earlier post for verification:
https://puck.nether.net/pipermail/juniper-nsp/2011-June/020382.html

-- 
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown

On Fri, Dec 23, 2011 at 9:37 PM, Rafael Rodriguez packetjoc...@gmail.comwrote:

 If my memory is correct, 11.x supports IPv6 with lt.

 Sent from my iPhone

 On Dec 23, 2011, at 8:14, Eric Van Tol e...@atlantech.net wrote:

  Hi all,
  Is frame-relay encapsulation not supported on the MX80 logical tunnel
 interfaces?  I'm on 10.4R8.5 and need to configure IPv6 on an lt- interface:
 
  Interface on the default instance:
 
  # show interfaces lt-0/0/10
  unit 1 {
 encapsulation frame-relay;
 dlci 128;
 peer-unit 1;
 family inet {
 address 192.168.209.201/30;
 }
 family inet6 {
 address 2001:db8::d1c9/64;
 }
  }
  Interface on my logical-system:
 
  # show interfaces lt-0/0/10
  unit 1 {
 encapsulation frame-relay;
 dlci 128;
 peer-unit 0;
 family inet {
 address 192.168.209.202/30;
 }
 family inet6 {
 address 2001:db8::d1ca/64;
 }
  }
 
  Interface shows 'up' and no flags are set to indicate a problem.
  However, pinging doesn't work and this shows up in my logs:
 
  Dec 23 07:57:12  r1 tfeb0 HALP-trinity_nh_ucast_installnh(690)
 encaps-install failed: unsupported option
  Dec 23 07:57:12  r1 tfeb0 Failed to create platform state, unsupported
 option
  Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed,
 err 1 (Unknown) peer_class 0, peer_index 0 peer_type 17
  Dec 23 07:57:12  r1 /kernel: RT_PFE: NH details: idx 690 type 2 ifl 80
  Dec 23 07:57:12  r1 tfeb0 Failed to install in platform, unsupported
 option
  Dec 23 07:57:12  r1 tfeb0 Type specific Add failed unsupported option
 nh-id:690
  Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 2 (CHANGE NEXTHOP)
 failed, err 1 (Unknown) peer_class 0, peer_index 0 peer_type 17
  Dec 23 07:57:12  r1 l2cp[1186]: Read acess profile () config
  Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed,
 err 1 (Unknown) peer_class 0, peer_index 0 peer_type 17
  Dec 23 07:57:12  r1 /kernel: RT_PFE: NH details: idx 692 type 2 ifl 81
  Dec 23 07:57:13  r1 tfeb0 HALP-trinity_nh_ucast_installnh(690)
 encaps-install failed: unsupported option
  Dec 23 07:57:13  r1 tfeb0 Failed to create platform state, unsupported
 option
  Dec 23 07:57:13  r1 tfeb0 Failed to install in platform, unsupported
 option
  Dec 23 07:57:13  r1 tfeb0 Type specific Add failed unsupported option
 nh-id:690
  Dec 23 07:57:13  r1 tfeb0 Failed to instantiate new copy for NH(690)
  Dec 23 07:57:13  r1 tfeb0 Failed to change state
  Dec 23 07:57:13  r1 tfeb0 HALP-trinity_nh_ucast_installnh(692)
 encaps-install failed: unsupported option
  Dec 23 07:57:14  r1 tfeb0 Failed to create platform state, unsupported
 option
  Dec 23 07:57:14  r1 tfeb0 Failed to install in platform, unsupported
 option
  Dec 23 07:57:14  r1 tfeb0 Type specific Add failed unsupported option
 nh-id:692
 
  Also, this all works if I remove 'family inet6' and change encapsulation
 to 'ethernet'.
 
  If frame-relay encapsulation isn't supported, how does one use IPv6 on
 the lt- interfaces?
 
  Thanks in advance,
  evt
 
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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

Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)

[Graham Brown]

Thanks for the update Tima, I'll distribute this internally - thank you.

On Thu, Oct 13, 2011 at 10:17 AM, Tima Maryin timamar...@mail.ru wrote:

 On 10.10.2011 17:17, Graham Brown wrote:

 Hello Tima,

 Thank you for making me aware of this and raising this with JTAC, I am
 sure that this would be deemed as critical and an easy fix. If you get
 allocated a PR, could you please share this with the group so we can
 monitor the progress and get a heads up on what releases contain the
 fix. I am sure that this will get flagged as a fix rather than a feature
 request, which would generally follow a longer path for implementation.




 The PR is 698121 (not public available yet).

 I've been told that they will include fix for it into all active main and
 service releases including 9.3.

 It will include 191.255.0.0/16 and 223.255.255.0/24 also.


 And expect bulletin about it soon.

 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] JUNOS and 128.0.0.0 martian (JFYI)

[Graham Brown]

Hello Tima,

Thank you for making me aware of this and raising this with JTAC, I am sure
that this would be deemed as critical and an easy fix. If you get allocated
a PR, could you please share this with the group so we can monitor the
progress and get a heads up on what releases contain the fix. I am sure that
this will get flagged as a fix rather than a feature request, which would
generally follow a longer path for implementation.

Thank you,
Graham

On Mon, Oct 10, 2011 at 1:39 PM, Tima Maryin timamar...@mail.ru wrote:

 Hello!


 Recently RIPE NCC started to allocate addresses from 128/8 to end users,
 example:

 https://apps.db.ripe.net/**whois/lookup/ripe/inetnum/128.**
 0.0.0-128.0.7.255.htmlhttps://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html


 Junos software (upto and including 11.1) blocks those address by default:

  show route martians

 inet.0:
 0.0.0.0/0 exact -- allowed
 0.0.0.0/8 orlonger -- disallowed
 127.0.0.0/8 orlonger -- disallowed
 128.0.0.0/16 orlonger -- disallowed


 In fact there will be no connectivity for new addresses and Juniper routers
 all around the world unless people change de.fault behavior or juniper
 change default settings for martians

 I think it's time to do, I've just open JTAC case about it.



 p.s. set routing-options martians 128.0.0.0/16 orlonger allow
 fixes it.
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Fan Tray Failure in JM20

[Graham Brown]

Hi Jon,

Is there anything else in the chassisd logs, prior to these failure
messages? Have you tried re-seating these or had a visual inspection to
determine that they have actually failed and this is not being reported
incorrectly?

Have any core dumps been created?

Cheers,
Graham

On Fri, Oct 7, 2011 at 11:49 PM, Jon Helman j...@ic2net.net wrote:

 Is there any info on why all 4 fan trays would fail in a JM20?



 Oct  7 12:53:43  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Middle Fan,
 jnxOpera   tingState/Temp 6)

 Oct  7 12:57:14  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 1, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Upper Fan,
 jnxOperat   ingState/Temp 6)

 Oct  7 13:05:45  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 3, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Bottom Fan,
 jnxOpera   tingState/Temp 6)

 Oct  7 13:22:08  LA-JM20 xntpd[27290]: offset 0.00 sec freq 75.450 ppm
 error0.00 poll 4

 Oct  7 13:34:17  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 4, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Rear Fan,
 jnxOperatingStat   e/Temp 6)

 Oct  7 13:53:48  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Middle Fan,
 jnxOpera   tingState/Temp 6)

 Oct  7 13:57:18  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 1, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Upper Fan,
 jnxOperat   ingState/Temp 6)

 Oct  7 14:05:49  LA-JM20 chassisd[2627]: CHASSISD_SNMP_TRAP6: SNMP trap
 generate   d: Fan/Blower Failed
 (jnxContentsContainerIndex 4, jnxContentsL1Index 3, jnxCont
 entsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr Front Bottom Fan,
 jnxOpera   tingState/Temp 6)





 show chassis environment

 Class Item   Status Measurement

 Power Power Supply A OK

  Power Supply B OK

 Temp  FPC 0  OK 30 degrees C / 86 degrees F

  FPC 1  OK 31 degrees C / 87 degrees F

  FPC 2  OK 28 degrees C / 82 degrees F

  FPC 3  OK 30 degrees C / 86 degrees F

  Power Supply A OK 24 degrees C / 75 degrees F

  Power Supply B OK 23 degrees C / 73 degrees F

  SSB 0  OK 30 degrees C / 86 degrees F

  Backplane  OK 24 degrees C / 75 degrees F

  Routing Engine 0   OK 25 degrees C / 77 degrees F

  Routing Engine 1   OK 25 degrees C / 77 degrees F

 Fans  Rear Fan   Failed

  Front Upper FanFailed

  Front Middle Fan   Failed

  Front Bottom Fan   Failed

 Misc  Craft InterfaceOK



 {master}

 ic2-jm105011@LA-JM20





 ___
 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] Interesting EX4200 gotcha and resolution

[Graham Brown]

Excellent post Jeff, thanks for sharing.

On Sun, Sep 25, 2011 at 8:36 PM, Jeff Wheeler j...@inconcepts.biz wrote:

 A colleague pointed out recently that some of the gotchas and fixes we
 run into are interesting to others, so in that spirit, I have another
 one to share with you today.

 In this case, a malfunctioning EX4200 (10.4R4.5) appears to have valid
 ARP entries for a few boxes, but when you try to ping them, etc. the
 boxes do not get any traffic.  In fact, they receive nothing from the
 switch except ARP who-has.  They respond, and upon clearing the ARP
 entries from the EX4200, that process repeats.

 Upon investigating the PFE data, I found that the halp-nh arp-table
 was missing these ARP entries, even though they were present in the
 Junos CLI and indeed the correct MAC address is referenced in the PFE
 route table.  See below:

 PFEM0(vty)# show route ip prefix 192.0.2.39 detail

 IPv4 Route Table 0, default.0, 0x0:
 Destination   NH IP Addr  Type NH ID Interface
   ---  - -
 192.0.2.39   192.0.2.39  Unicast  2933 RT-ifl
 197 vlan.1122 ifl 197

  RT flags: 0x, Ignore: 0x, COS index: 0
  DCU id: 0, SCU id: 0,  RPF ifl list id: 0



 PFEM0(vty)# show nh id 2933 detail
   ID  Type  InterfaceNext Hop AddrProtocol
 Encap MTU   Flags  PFE internal Flags
 -    -  ---  --
     --  
  2933   Unicast  vlan.1122  192.0.2.39IPv4
 Ethernet 0  0x 0x

   Flags: 2   nh_idx:  3
   CMD:   Route   Arp Idx:  1341
   MTU Idx:   2   Num Tags:0
   Upd Cnt:   1   Tun Strt:False
   Chain_nh   3484:
   Hw install:1
   Mac: 00 0e 0c a2 2d dc



 PFEM0(vty)# show halp-nh arp-table
 Device: 0
 ...hundreds and hundreds of lines...
  ArpEntry Idx 1340 : 00:15:17:6b:a9:7c
  ArpEntry Idx 1342 : 00:25:90:2c:41:e5
 ...hundreds more, but where is Idx 1341?!


 Our fix is to remove 192.0.2.1/27 from the vlan.1122 configuration,
 commit, and then rollback.  This is obviously not good.  I would like
 to have tried installing a different ARP entry (by configuring this IP
 address on another machine) but I have not had an opportunity to test
 this yet.

 The reason this is happening is the ASIC vendor format ARP table in
 the PFE memory is abstracted from the Juniper ARP table, as I
 understand.  It appears that simply refreshing the Juniper ARP table
 with an identical entry does not cause a missing entry to be put into
 the forwarding table.

 I would love to be able to reproduce this, but with hundreds to a few
 thousand machines each on many EX4200 stacks, it happens very rarely.
 I only mention it because clear arp from the CLI does not work, so
 this problem gets escalated until it reaches someone brave enough to
 temporarily break some unaffected boxes to fix a broken one.  It would
 be nice, though, if clear arp actually worked right.

 If you encounter this problem and do something different, I would be
 very interested to hear from you!
 --
 Jeff S Wheeler j...@inconcepts.biz
 Sr Network Operator  /  Innovative Network Concepts

 ___
 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] Traffic Manager Appliance to limit or block P2P

[Graham Brown]

Hi Juan,

If you are considering the Juniper security products, bear in mind that
Juniper are moving towards the SRX as being their primary security platform.
Obviously they are not quite there with feature parity against the
Netscreens, but they are getting closer and the SRX platform will be around
a lot longer that the Netscreens. Also the SRX runs JUNOS, so the learning
curve will be less steep if your engineers already run Juniper routers /
switches.

Have a look at the comparisons and obviously test both to see which suits
your requirements best.

HTH,
Graham

On Thu, Sep 22, 2011 at 10:01 PM, Juan C. Crespo R. jcre...@ifxnw.com.vewrote:

 Guys

 We are looking to limit the P2P(kazaa, winMX, Ares)  traffic in ours POP
 could any one of you give us some advices? we're considering netscreen
 solution

 Thanks
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp

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