Re: [j-nsp] juniper router reccomendations

[james jones]

+1 MX104

On Thu, Jul 28, 2016 at 5:21 PM, Adam Vitkovsky 
wrote:

> > Mike [mailto:mike+j...@willitsonline.com]
> > Sent: Thursday, July 28, 2016 5:09 PM
> > To: Adam Vitkovsky; juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] juniper router reccomendations
> >
> > On 07/28/2016 12:50 AM, Adam Vitkovsky wrote:
> > >
> > > And on how effective is the NPU's lookup process, that is how
> > > effective is the actual lookup algorithm with CPU cycles and memory
> > > accesses, some NPUs can even offload complex lookup tasks to a
> > > specialized chip.
> > >
> >
> > I appreciate your presence on other forums, but I'm pretty sure nobody
> here
> > needs a basic explanation of how modern router platforms work. If you
> > missed it, the question was specifically about juniper and bang for the
> buck
> > and routing bgp on 10g and filtering.
> >
> > Some folks helpfully suggested using strategies to to decrease the
> required
> > size of the FIB, potentially meaning a lower box could do that job. That
> has
> > some merit, as the OP was right in that for this job I don't really care
> about
> > timbuktu more as whats 'close' to my two ip transit providers. I know
> nothing
> > of juniper and I'm just wondering if
> > MX80 is enough box for this or if I need to go higher up in the food
> chain. The
> > one iptransit provider at my 'A' location appears to originate about 20
> > networks from various netblocks and this would be easy to statically
> enter
> > into config while accepting defaults from both, achieving the same net
> result.
> >
> Ok let me dial back a notch then.
> You mentioned you need DoS filtering.
> Good DoS filters can get really complex and long (hence IDS/IPS systems
> exist).
> Complex filters cripple router's performance.
> Bottom line, depending on the complexity of DoS filters and pps rate,
> going with the cheapest box might not cut it.
> Hope you got my drift this time around.
>
> But to answer your question filtering 10G in and routing 1G out, there's a
> pretty good chance you'll be fine on MX80/MX104.
> Though as others have pointed out, how swift or scalable is the
> control-plane is another thing to consider.
>
> PS:
> Just out of interest, would you folks know if MX80 and MX104 have a Gen2
> Trio? (80Gbps per single PFE seems like Gen2, unless they are doing
> something "smart" with multiple LUs on one XM).
>
>
> adam
>
>
>
>
>
>
>
>
> Adam Vitkovsky
> IP Engineer
>
> T:  0333 006 5936
> E:  adam.vitkov...@gamma.co.uk
> W:  www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmas...@gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
> ---
>  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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX Command

[james jones]

+1


On Fri, Oct 25, 2013 at 3:29 PM, OBrien, Will obri...@missouri.edu wrote:

 show chassis fpc is a start.

 you can run various diags on the fpc pics themselves as well.

 On Oct 25, 2013, at 2:25 PM, Keith wrote:

  Is there a command on JunOS similar to the cisco command:
 
  show controller utilization
 
  Thanks,
  Keith
  ___
  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

[j-nsp] out of the box

[james jones]

Is there a away to get a Juniper device to pull its configuration from a
another location when it boots?

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

[j-nsp] RPM on SRX220

[james jones]

does the srx220 support RPM? if not is there a similar function that give
this functionality?


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

Re: [j-nsp] JunOS version for MX40?

[james jones]

if you can, I would go with at least the latest 12.1R. lots of bug fixes.

On Thu, Feb 7, 2013 at 3:45 PM, Gabriel Blanchard g...@teksavvy.ca wrote:

 If it's for a lab...why not run greatest and latest? if not, run the
 recommended.

 On 13-02-07 03:08 PM, Steve Feldman wrote:
  I have a couple of shiny new MX40s in my lab, and need to do some
 testing before we deploy them.
 
  They will be doing fairly vanilla BGP (~2 full feeds), IS-IS and/or
 OSPF, and some interface filtering.  No MPLS for now, but possibly in the
 future to support L2VPN/L3VPN services.
 
  What is your favorite version of JunOS for the MX5/10/40?  Juniper is
 recommending 11.2R5.5 this week.
 
 
  Thanks,
  Steve
  ___
  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] Redundancy with MX

[james jones]

Are you looking to do active-standby or active-active mc-lag?

On Mon, Jan 21, 2013 at 3:48 PM, Andre Christian 
andre.christ...@o3bnetworks.com wrote:

 Marcus - I am building about 10 PoPs and opted for the dual mx-80 design.
 Also looked at making the PoPs all layer 2 with a pair of exs.

 Plan to use MC-LAG where applicable.

 On Jan 21, 2013, at 3:43 PM, Markus H hauschild.mar...@gmail.com
 wrote:

  Hi,
 
  I wonder what kind of redundancy the community would prefer for
  small-medium sized PoPs.
  This is what I have come up with so far:
 
  a) 2xMX80
  Pro: Two seperate devices so less prone to config errors and chassis
 failure
  Con: Using redundant uplinks is more complicated (LB would need to be
  done via routing protocol)
 
  b) 1xMX240/480 with redundant SCB and RE
  Pro: Easier to use redundant uplinks (LACP)
  Con: Config error as well as chassis failure brings the whole PoP down
 
  Any further arguments? Best practices? What did you deploy?
 
 
  Best regards,
  Markus
  ___
  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] LAG on Ex4200 fiber + copper

[james jones]

In theory it should be possible. The best thing todo is configure it and do
a commit check and see what happens.



On Thu, Nov 29, 2012 at 3:07 AM, Riccardo S dim0...@hotmail.com wrote:


 Mates
 any other experience in regards on the initial question ?

 Tks

 Date: Wed, 28 Nov 2012 11:00:59 +0100
 Subject: Re: [j-nsp] LAG on Ex4200 fiber + copper
 From: dariu...@gmail.com
 To: dim0...@hotmail.com
 CC: juniper-nsp@puck.nether.net

 As far as I know and according to all Juniper docs you can only use
 optical pic ports and of course the dedicated vc port for this
 eg.

 https://www.juniper.net/techpubs//en_US/junos/topics/example/virtual-chassis-ex4200-link-aggregation-over-extended-vcps.html

 Regards,Darius

 On Wed, Nov 28, 2012 at 10:28 AM, Riccardo S dim0...@hotmail.com wrote:







 On ex-4200-24T

 is it possible to create a LAG using a 1 Gb up-link fiber port + a 1 Gb
 copper

 port ?





 Any juniper.net

 reference about that ?





 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

Re: [j-nsp] console switch to access juniper devices

[james jones]

Digi work pretty well. No need for the dongle.

On Fri, Mar 30, 2012 at 7:38 PM, Alexander Frolkin a...@eldamar.org.ukwrote:

  We went with OpenGear, it is inexpensive and has all the features we
 need.

 We also went with OpenGear.  Another advantage is that the company is
 very responsive to queries and feature requests.  They implemented
 several features for us (in a matter of weeks --- with any other company
 this would probably have taken years) and they're now in the production
 release.

 As far as I understand, they also allow you to put custom firmware on
 their boxes without voiding the warranty (although we were pretty happy
 with the OpenGear firmware).


 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] EX4200 missing ARP entry work-around

[James Jones]

Have you contacted JTAC about this issue?



On Wed, Jan 11, 2012 at 2:14 PM, Jeff Wheeler j...@inconcepts.biz wrote:

 We have decided on a better work-around for our missing ARP entry
 problems on the EX4200 and friends.

 As you may recall, the EX4200 will sometimes have an ARP entry in the
 control-plane, but it will not be present in the data-plane.  You can
 investigate by checking your destination IP address with the command
 `show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32`
 which will produce output like this:

 PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2
 prefix-length 32

  RouteType Paths RtIdx Rpf SipSa Row:Col:Row:Col
    - - --- - ---
  192.0.2.2  ECMP 0 2037  No  No439:0:0:0

  Dev0 (RtIdx:2037)
  -
  Command   : Route  CpuCode: 3
  AppSpCpuCodeEn: 0  UcSipFiltEna   : 0
  TtlDecEna : 1  TtlOptChkBypass: 0
  IngressMirror : 0  QoSProfileEn   : 0
  QoSProfileIndex   : 0  QoSPrecedence  : 1
  ModifyUp  : 2  ModifyDscp : 0
  CounterSet: 2  ArpBc2Cpu  : 0
  SipAccessLevel: 0  DipAccessLevel : 0
  IcmpRedirExpnMirr : 0  MtuProfileIdx  : 2
  Ipv6ScopeCheckEn  : 0  Ipv6DstSiteId  : 0
  NhTnnl: 0  NhTnnlIdx  : 0
  NhVlan: 6  NhIf   : VIDX4095
  NhArpIdx  : 138
 Device: 0
  ArpEntry Idx 138  : 00:2b:f0:19:87:01
  Hit/Miss  : N

 Notice above a reference to NhArpIdx 138.  In order for forwarding to
 work correctly, there must be an entry # 138 in the `halp-nh
 arp-table.`  Since there isn't one, the NhIf shown is VIDX4095, not a
 port.  However, if you want to verify that there is no NhArpIdx 138 in
 the hardware, you can examine the table with `show halp-nh arp-table`
 and scroll down to where # 138 should be.  You won't find it!

 PFEM0(vty)# show halp-nh arp-table
 Device: 0
 ... lots of scrolling ...
  ArpEntry Idx 136  : 00:18:8b:f8:b6:6e
  ArpEntry Idx 137  : 00:0e:b6:2d:01:a0
  ArpEntry Idx 139  : 00:19:b9:f9:24:2a
  ArpEntry Idx 140  : 78:2b:cb:3c:91:60

 How do you get the switch to populate that entry?  Well, since `clear
 arp` on the EX4200 doesn't actually do what it is supposed to do, what
 we have been doing in the past is deleting whole subnets, impacting
 potentially many machines, and then re-adding them.  This is not good
 but it does work.

 Our new solution is much better.  We just add a bogus static arp entry
 for 192.0.2.2, pointing to some made-up MAC address, and then we
 commit, roll back, and commit again.  Like magic, the ARP entry will
 re-populate correctly.  Almost as if you really did have a `clear arp`
 command on the EX4200, one that worked right!

 After adding and then deleting the bogus static ARP for 192.0.2.2 you
 can re-examine the PFE and see the results.  Also, your customer's
 Internets will begin working correctly again.

 I hope this helps.
 --
 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] QFX3500 as ToR switch?

[James Jones]

On Tue, Nov 8, 2011 at 5:29 PM, Wojciech Owczarek
wojci...@owczarek.co.ukwrote:

 Hi guys,

 My two pence here - I think they are two totally different devices...

 EX4500: 2U tall, will fit a shallow rack but still 2U, reversible air flow,
 PSUs with fat 16A C19/C20 plugs, 40 x 10GE (max. 48), no 40GE, much higher
 latency (store and forward only switch, 2 PFEs - around 4 x QFX3500
 latency, if you care).
 BUT supports VC and can also be stacked together in a mixed manner with
 EX4200s which is quite interesting if you want to build a mixed media
 stack.

 QFX3500:  1U, but damn long (70cm rack depth is the *minimum*, two mounting
 points - front and back - are a must). Server type construction. This
 device is designed to sit more in the middle of a rack than in the top.
 Non-reversible air flow: front to back cooling only, but switch ports are
 at the back, where server ports are and you can't change that. Console,
 power and management are on the other side so you have power cables
 sticking out the front of your rack, not good for server cabinets where
 server fronts are very close to the door. Requires some physical planning
 for deployment and for some people will not be an easy drop-in replacement
 for their previous TORs.Much lower latency (single PFE, cut-through but
 defaults to store  forward, I think it still qualifies as Ultra Low
 Latency these days). Supports 40GE and will serve as a QFabric node. High
 port density - 48 x 10GE out of the box, up to 64 x 10GE when using QSFP to
 SFP+ break-out cables, turning each of the 4 40GE into 4 x 10GE ports.

 Depends on what you want to do really, but the QFX3500 is more of a typical
 ToR, and definitely more future proof.

 Regards
 Wojciech

 On 8 November 2011 21:31, Jim Glen jim.g...@codonis.com wrote:

  Hi,
  I've deployed them and have been very pleased with their performance.
 
  The rational over choosing the QFX over the EX4500 is I intend to deploy
  these devices at some point soon into my consolidated Q-Fabric platform
  which the QFX is designed for the EX4500 does not have the same
 capability
  to participate.
 
  JimG
 
  On Nov 4, 201145308, at 9:56 AM, Sargun Dhillon wrote:
 
   I was wondering if anyone here has implemented the QFX3500 as a ToR
  switch. How have your experiences been, and how has it been as compared
 to
  other Juniper products? Additionally, I'm curious as to what made you
  choose it over the EX4500?
  
   --
  
   Sargun Dhillon
   VoIP (US): +1-925-235-1105
   ___
   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
 



 --
 -

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

+1 on Wojciech's thoughts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] M10i JUNOS Upgrade

[James Jones]

Just a tip I have found it always easier to backup everything and use the
jinstall file.





On Wed, Sep 28, 2011 at 3:06 PM, Jeff Wheeler j...@inconcepts.biz wrote:

 On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake 2012j...@gmail.com wrote:
  I am looking at upgrading the JUNOS on our M10i router. Current JUNOS
  platform is 6.3R1.3 . The router has redundant routing Engine  RE-5.0
 with
  512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can
 any
  one suggest on if I can upgrade the router to 11.1R5.4 with the current
  hardware specification .  Please advise on if a direct upgrade can be
 done
  as well from 6.3 to 11.1.

 If you have DFZ routes you should upgrade the RAM to 768MB, or
 alternatively, replace the router or buy more modern routing engines.
 There is a big jump in memory usage in 8.x and if you have only 512MB
 and are carrying Internet BGP routes, you will be using the swap and
 the RE will perform badly.

 No, you cannot do a direct upgrade from 6.3 to 11.1.  You'll be going
 through quite a few intermediate software versions to do that.  It
 will be easier to simply reinstall Junos from an 11.1 install-media
 disk and then load your configuration.

  Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing
 the
  combination of RAM used ..i.e 256+256MB or a single 512MB RAM.

 I don't think the RE-5.0 will recognize more than 256MB per slot.

 --
 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] MLAG on EX4500

[James Jones]

Are talking about multi-chassis lag?

Sent from my iPhone

On May 15, 2011, at 12:59 PM, Matt Hite li...@beatmixed.com wrote:

 Hello,
 
 Anyone have battle time using the virtual-chassis MLAG functionality
 on the EX4500 series? Has it given you any headache? Any potential
 pitfalls/bugs/versions I should look out for?
 
 We are exploring a high-availability LAG connection from hosts to
 pairs of redundant EX4500 joined into a virtual chassis. I would love
 to know if I am in for a world of hurt or not.
 
 Thanks,
 
 -M
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] LSA memory usage

[James Jones]

Can anyone tell me the average memory usage for Type 1 and Type 5 LSA's?

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