[j-nsp] juniper security advisories rss feeds broken this year?

[Joel Jaeggli via juniper-nsp]

About 3 months ago now I observed that the rss feeds associated with 
security advisories stopped updating.


this were urls like

https://kb.juniper.net/InfoCenter/index?page=rss&channel=SECURITY_ADVISORIES&cat=SRX_SERIES&detail=content

which now reforms into a link in the CMS like

https://supportportal.juniper.net/s/global-search/%40uri?language=en_US#t=All&sort=date%20descending

As far as I can tell that entry point is still reflected in current 
documentation


https://supportportal.juniper.net/s/article/How-can-I-get-an-RSS-feed-of-Knowledge-Base-Security-Advisory-and-Technical-Bulletin-articles

(updated 2021-10 so not that long ago)

However, since  some content manager change that occured on 1/13 is now 
completely broken.


this is the last article in my feed

https://supportportal.juniper.net/s/article/2022-01-Security-Bulletin-Junos-OS-and-Junos-OS-Evolved-After-receiving-a-specific-number-of-crafted-packets-snmpd-will-segmentation-fault-SIGSEGV-requiring-a-manual-restart-CVE-2022-22177?language=en_US

What are people doing at this point to subscribe to vendor specific 
juniper vulnerability publication.


Thanks

Joel

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

Re: [j-nsp] upgrading an antique 240

[Joel Jaeggli via juniper-nsp]

On 7/15/21 19:06, Randy Bush via juniper-nsp wrote:

Limited/Unlimited depends on your geographic region and if your
encryption access is limited.

ahhh; still that silliness.  it is in amerika.


As for 64/32 bit, check what it’s running now and go from there:

‘show version | match kernel’
https://kb.juniper.net/InfoCenter/index?page=content&id=KB25803

 r...@r1.dfw> show version | match kernel
 JUNOS Kernel Software Suite [14.2R7.5]

so i assume 32


yeah it's 32 bit

RE-S-2000-4096 is a 2ghz pentium m and afaik doesn't do 64bit.


randy

___
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] IPv6 hardening

[Joel Jaeggli]

On 12/30/19 06:19, harbor235 wrote:
> Does anyone have any updated router hardening guidelines, some of the sites
> I reference have not been updated for some time. e.g. www.team-cymru.org

Every time I build a new control-plane protection ACL at new company I
pretty much riff off what we did back in:

https://tools.ietf.org/html/rfc6192

some of the limits have changed and you need to salt to taste, but the
principles are largely still the same, and we have equivant
control-plane protection rulesets running on junipers / ciscos / aristas
and so on.

>
> thanks in advance,
>
>
> Mike
> ___
> 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] Segment Routing Real World Deployment (was: VPC mc-lag)

[joel jaeggli]

On 7/8/18 01:34, Mark Tinka wrote:
> 
> 
> On 7/Jul/18 23:54, Aaron Gould wrote:
> 
>> Thanks Mark, I haven't been aware of any buffer deficiency in my
>> 4550's.  If something adverse is occurring, I'm not aware.
> 
> The EX4550 has only 4MB of shared buffer memory. The EX4600 has only 12MB.
> 
> You need the "set class-of-service shared-buffer percent 100" command to
> ensure some ports don't get starved of buffer space (which will manifest
> as dropped frames, e.t.c.).
> 
> The Arista 7280R series switches have 4GB of buffer space on the
> low-end, all the way to 8GB, 12GB, 16GB, 24GB and 32GB as you scale up.

As they are a matrix of cell forwarders either attached to each other or
to a fabric it's probably more proper to think of that as 4GB of packet
buffer per asic. There is in fact a small amount onboard the asic and
then the large dollop of offboard gddr5.  while memory is still shared
among the locally attached ports it's unlikely that anything is going to
starve.

> 
>>
>> Thanks for the warning about large VC... I don't really intend on
>> going past the (2) stacked.  After we outgrow it, I'll move on.
> 
> We are dropping the VC idea going forward. Simpler to just have enough
> bandwidth between a switch and the router that you can predict.
> 
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Router for full routes

[joel jaeggli]

On 6/27/18 8:42 AM, Tom Beecher wrote:
> Can confirm convergence time on the MX80 with even a single full table
> session is extremely painful, and essentially not functional in a
> production environment.
>
>
> On Wed, Jun 27, 2018 at 7:10 AM, Dovid Bender  wrote:
>
>> Hi All,
>>
>> In my 9-5 I work for an ITSP where we have two MX5's with
>> - iBGP
>> - two up steams with two BGP sessions each (one per routes)
>> - one upstream with one bgp session
>> - one bgp session where we get minimal routes (maybe 15 total)
>>
>> I was told that convergence time on the MX5 would be horrible so we never
>> tried full routes. I am wondering what's the "lowest" model that can
>> support full routes without having an issue re-sorting the routes.
 the 32 bit freescale  control-plane cpu is bit under-powered.

virtual-mx / mx150  as software devices are more than capable of doing
it. So are devices like the mx204, MX REs newer than the RE-2000 (which
is a bit long in the tooth / more than 10 years old a this point) also 
mid-range and higher SRXes

>>
>> TIA.
>> ___
>> 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] Spine & leaf

[joel jaeggli]

On 6/22/18 11:44 PM, Mehul Gajjar wrote:
> Hello Juniper experts,
>
> I am new in Juniper.
>
> Can anyone help me the basic l2 spine & leaf configurations example. my
> concern is to high availability of server's connections.
High availability of a server's interface is typically achieved by
having more than one of them, on more than one switch.

There are  several ways to implement that, (MC-LAG, routing, etc) but in
fact  the topology of the network upstream of the switches service the
server is not necessarily the most important consideration.

if you have to actually scale an l2 network for edge servers I would
start by taking  look at multichassis lag approaches which are supported
on most junos platforms.

https://www.juniper.net/documentation/en_US/junos/topics/concept/mc-lag-feature-summary-best-practices.html

Personally I'm kind of done with large L2s so I would  probably just use
ebgp with a private asn per server and eschew all these l2 topologies.

joel
> Cheers !!!
> Mehul
> ___
> 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] More power questions

[joel jaeggli]

On 5/11/18 15:15, mike+j...@willitsonline.com wrote:
> Hi,
> 
> 
>     So I want to connect an MX240 and some other gear in a single
> cabinet at 208V. The group has convinced me this can work in general. I
> am now trying to find a rack mounted or Zero-U type metered 208V PDU but
> I am having a hell of a time finding one for this application. The power
> cords on the juniper are the 6-20 type (one ground, one horizontal
> blade, and one vertical blade), and I can't seem to find any PDU that
> have that as outlet styles. I do find some that have the 'C20' type,

You switch to a PDU  that is  a mix of c19 and c13.

for your c20 and c14 plugs

so for example

http://www.apc.com/shop/us/en/products/Rack-PDU-Basic-Zero-U-30A-200-208V-20-C13-4-C19/P-AP7541

and yeah you have new power cords.

> which is what the juniper has for an input at the power supply side of
> things. Im just trying to understand... is the deal that I now have to
> order different power cords and try to find some commonality between
> them all? My other gear is likely to be like ASR920 or somesuch and I
> am  totally confused how this could or should all be working. Someone
> out there can help me I hope..
> 
> Mike-
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[joel jaeggli]

On 12/16/16 1:24 PM, Jesper Skriver wrote:
> On Fri, Dec 16, 2016 at 02:45:14PM -0600, Aaron wrote:
>> Ah, thanks Jesper... you know how much those 7280's cost ? (just ballpark)

retail on 7280r-48C6 is 40k that's on the small end.

I'd find it rather hard to directly compare that the the scale/feature
matrix of a ptx1000 but if you're needs line up perhaps you can.
> No idea, sorry.
>
> /Jesper
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>




signature.asc
Description: OpenPGP digital signature
___
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

[joel jaeggli]

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
>




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 3rd party juniper compatible CFPs SR optics

[joel jaeggli]

On 9/27/16 8:12 AM, Adam Vitkovsky wrote:
>> Fredrik Korsbäck
>> Sent: Tuesday, September 27, 2016 3:58 PM
>>
>> On 27/09/16 16:47, Adam Vitkovsky wrote:
>>> Hi folks,
>>>
>>> What is the current stand in this matter?
>>> Are 3rd party juniper compatible CFPs a viable alternative?
>>> As it looks like no one is making CFP-SR10s, -are these dead/legacy?
>>> -cause it doesn’t seem to be such a problem to find 3rd party 100G QSFP-
>> SR4 –though not sure about the compatibility side of things.
>> Most of the things i tried works fine. Flex, Fiberstore. etc.
>>
>> SR10 is a quite horrible standard so that's why no-one is making them :) SR10
>> is only available in the bulky CFP-transciever since you need to fit a 
>> internal
>> gearbox to get 10 lanes out. If you can run with third-party why don't just 
>> do
>> LR4 directly? So you can be backwards and frontwards compatible with
>> whatever formfactor transciever you got on the other side. On 100G its only
>> LR4 that's available across the board of all devices.
>>
> That's actually a very good point regarding the future compatibility.
> I got scared by LR4 price tag around 10k as opposed to less than 1k for SR10.
> But I see now that Fiberstore has SR4 for around 1k -not sure where's the 
> catch though.
yeah, sr10 uses a 24 fiber mpo cable, it might have made sense inside a
rack at one time,but it's not even a great way to de-multiplex 10gig
ports respecting real-estate.
> Thanks a bunch
>
> 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
>




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Dealing with multihomed customer BGP primary/backup links

[joel jaeggli]

On 7/13/16 1:41 AM, Mark Tinka wrote:
> 
> 
> On 13/Jul/16 10:36, Cydon Satyr wrote:
> 
>> What would be the optimal way to deal with following scenario.
>>
>> The customer of ours has a primary bgp connection over primary link on one
>> router, and a backup bgp connection (up) on backup link on our other
>> router. The customer may or may not (usually not) terminate both
>> primary/backup links on the same router.
>>
>> We want to stop customer using backup link at all as long as the primary
>> link is up. Since we police both primary and backup link, customer can just
>> load balance and use both links.
>>
>> Without asking changes on his side (so something link MC-LAG won't fit
>> here, I guess?), what are way to deal with this.
>>
>> I can think of making a script which will not import their routes as links
>> a primary link route is in our table.
>>
>> The bgp conditional policy doesn't work for importing routes, only
>> exporting... so that won't work either.
>>
>> Any other suggestions maybe?
> 
> I know this may not answer your question, but this is why we don't sell
> active/backup services to customers.
> 
> We sell active/active, and it's the customer's responsibility to control
> which link has traffic. We solve the issue commercially, incentivizing
> the customer to self-control or pay up. Works well.
> 
> Active/backup scenarios work best if you can control the CPE, i.e., a
> managed service. Without that, best never to trust the customer to
> honour anything.

I suppose the question is when you have one circuit with a customer you
can police an interface to a certain rate. when you have two you have a
coordination problem. when you have 100 well you're probably just better
off billing on 95th (that's probably best anyway).

to marks point I'd be rather unhappy if I couldn't shift my traffic from
one circuit to another for example in a prelude to a maintenance, in a
make before break fashion.

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX104 capabilities question

[joel jaeggli]

On 6/21/16 7:12 PM, Josh Hoppes wrote:
> PAE can get the kernel to address more than 4GB of RAM, however a single
> process will still be limited.

this is straying off topic but.

yeah it doesn't use pae...

Arista kernels are 64 bit, user space is 32 bit derived from FC14.

Linux XX 3.4.43.Ar-3052562.4155M #1 SMP PREEMPT Sun Mar 20
19:36:57 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

all the control-plane cpus are 64 bit with the TORs having AMD apus. and
the beefier boxes having and intel xeon based RE.

big

processor   : 7
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Xeon(R) CPU  @ 2.60GHz
stepping: 7

little (this is a 7048t which is old)

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 6
model name  : AMD Turion(tm) II Neo N41H Dual-Core Processor
stepping: 3
microcode   : 0x1b6
cpu MHz : 1499.919

that said 4GB (which is typical for the single asic tors up until very
recently) is kinda tight, depending on how you use them so the older
boxes aren't going to last forever.


> On Tue, Jun 21, 2016 at 8:02 PM, Colton Conor 
> wrote:
> 
>> Saku,
>>
>> Can you expand on what you mean by the following quote: "I think they are
>> fundamentally able to produce less buggy code than
>> JNPR or CSCO.

yeah if there's any fundamental about it, it's that it carry less
legacy, is more general purpose, and has less hardware, wierd corner
cases and unreasonable customer demands to support. It has it share of
bugs, missing features and hardware specific limitations and quirks.

>> They are doing some of the classic mistakes, like
>> insisting market that they have single image like JNPR highlighted as
>> big competitive advantage over CSCO back in the day. But they'll need
>> to get rid of this message when moving to 64b or then they need to
>> screw people running older HW not capable for 32b."
>>
>> My understanding is right now they indeed do have a single downloadable
>> file no matter which arista switch model you have. Is that not the case?
>> Are you saying this file is 32 bit and not 64? That would suprise me since
>> I beleive most of their recent switches have more than 8GB of RAM in them.
>>
>> On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti  wrote:
>>
>>> On 9 June 2016 at 15:54, Mark Tinka  wrote:
>>>
 But is the IP and MPLS code mature enough for real-world use?
>>>
>>> It's getting there, customer by customer. It's not there for me. I
>>> expect Arista to be serious player in SP segment in a <2 years.
>>>
>>> As Arista is still controlled by owners who work there on daily basis,
>>> they can do things well, instead of seeking immediate gratification
>>> while adding technological debt. And none of them are in their first
>>> rodeo, are financially independent so I don't think they're interested
>>> in doing big exit, I think they're solely motivated in building great
>>> company and a great product. How long this issue will persist is
>>> anyone's guess.
>>>
>>> They do something quite different than JNPR or CSCO. I think
>>> programming language is important, and I think C is terrible language,
>>> because it's very hard to write quality code on.
>>> Arista isn't really using C, mostly C++ and good portion of that is
>>> machine generated from their own proprietary state description
>>> language. They also heavily unit test and automate black-box testing.
>>>
>>> I think they are fundamentally able to produce less buggy code than
>>> JNPR or CSCO. They are doing some of the classic mistakes, like
>>> insisting market that they have single image like JNPR highlighted as
>>> big competitive advantage over CSCO back in the day. But they'll need
>>> to get rid of this message when moving to 64b or then they need to
>>> screw people running older HW not capable for 32b.
>>>
>>> I wish someone would do something even more novel, like create full
>>> routing suite in Erlang. But from what we have now in the market, I
>>> think Arista is most innovative.
>>>
>>> --
>>>   ++ytti
>>>
>> ___
>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX10002 as P Router

[joel jaeggli]

On 4/16/16 9:40 AM, Mark Tinka wrote:
> 
> 
> On 16/Apr/16 17:58, Richard Hicks wrote:
> 
>> Thoughts on using the QFX10002 as a P only router?
>> WIll be our first big investment into Juniper hardware.
>>
>> All PE functionally will live elsewhere.  Mainly Cisco ASR9k and ASR1k for
>> now.
> 
> Multicast could be an issue, assuming this box is also running the
> Broadcom chipset (I'm not sure).

qfx1 is the juniper q5 npu, which is a bespoke cell based forwarder.

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] negative arp cache on JunOS?

[joel jaeggli]

On 3/31/16 3:49 PM, Jared Mauch wrote:
> For reasons that can’t be easily solved, we have a large subnet
> connected on a device that connects wireless and other devices.  I’m
> looking for a quick answer if someone has been able to configure
> negative arp caching on JunOS to prevent ARP floods or excessive ARPs
> for the same addresses.

while even a moderate sized ethernet switch fib could hold discard
entries for a /16 pretty easily any attempt to hold the non-attestations
for a v6 subnet is likely to end in tears I think.

> Anyone solved a similar problem?

arp sponging is a thing

https://ams-ix.net/technical/specifications-descriptions/controlling-arp-traffic-on-ams-ix-platform


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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Is there a noticeable performance difference between the RE-S-2000 and the RE-S-1800-X4 when rebuilding the FIB?

[joel jaeggli]

On 2/25/16 12:59 AM, v wrote:
> Hello,
> 
> let's assume a link goes down. The router (in our case a MX960) will
> have to rebuild the FIB in order to stop sending data to that
> interface.
> 
> Is there a performance difference in such a case between the
> RE-S-2000 and the RE-S-1800-X4? How long does that process take for
> you? I know that with the smaller REs it can take ages. :)

back with I had re2ks and the ability to test that sort of thing (2012)
they converged about 8k routes a second which resulted in the ingest of
a full table (in 2012) in under a minute.

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 with 3 RE's?

[joel jaeggli]

On 1/14/16 2:48 PM, Jeff wrote:
> Am 14.01.2016 um 23:19 schrieb Christopher E. Brown:
>>
>>
>> Agree, mixing DPC and MPC is a terrible idea.  Don't like DPC to begin
>> with, but nobody in their right mind mixes DPCs and MPCs.
>>
> 
> Why is that? The mentioned 16x 10G card actually sounds interesting but
> is still quite expensive compared to the older DPCEs with 4x 10GE so we
> had them in mind for our growth and are planning to use them together
> with the existing DPCEs. Why wouldn't you do it?

different asics, with varying amounts of memory, a long history of
stability problems running jointly that neither had seperately. lack of
feature parity (e.g. inline jflow).

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 with 3 RE's?

[joel jaeggli]

On 1/13/16 8:59 AM, Colton Conor wrote:
> Just to confirm though, its the extra RE that is different and not
> supported in this config right? The MX960 can use 3 SCB's at once, but only
> 2 REs? Or do I have the wrong too?

An mx960 has a full fabric with two SCBs. it is n+1 redundant with 3.
e.g. at that point you can swap one without cutting the fabric bandwidth
in half.

NSR/GRES uses two REs. a third RE in the chassis is cold and dead. iI's
probably an acceptable place to store a spare.

> 
> 
> 
> On Wed, Jan 13, 2016 at 8:16 AM, Mark Tinka  wrote:
> 
>>
>>
>> On 13/Jan/16 12:42, Jérôme Nicolle wrote:
>>
>>> Looks like the broker had a few spare SCB and REs and no functionnal
>>> chassis to slap them in, so he invented a bundle and didn't fully test
>> it.
>>
>> If the price is right, I'd take the extra RE and SCB as backup, in case
>> not including them does not yield any significant saving.
>>
>> Mark.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Limit on interfaces in bundle

[joel jaeggli]

On 10/29/15 5:57 AM, Edward Dore wrote:
> On 29 Oct 2015, at 12:49, Mark Tinka  wrote:
> 
>>
>>
>> On 29/Oct/15 14:22, Cydon Satyr wrote:
>>
>>> Oh wow.
>>>
>>> Any real drawbacks to running something like 32x10Gbps LAG link in core
>>> instead of higher bandwidth physical links? Just seems so unreal.
>>
>> Folk like AMS-IX have publicly acknowledged running 32x 10Gbps on their
>> exchange point (albeit, with Brocade) right before 100Gbps ports became
>> viable.
>>
>> I suppose the biggest issue will be how you hash equally across all of
>> the links, especially if much of the traffic being carried is inherently
>> Layer 2 (despite having a Layer 3 payload).
>>
>> Mark.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> I believe LINX were using 64x10G LAGs between the core nodes on the Juniper 
> LAN in London before the upgrade to use smaller 100G bundles.
> 
> I guess the biggest benefit of using 100G interfaces instead of 10x10G is 
> that you can support individual flows >10G.

a  reduction in fiber count or waves utilized is non-trivial given you
go from 20 fibers to 8 or 2.

> Edward Dore
> Freethought Internet
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP

[joel jaeggli]

On 10/14/15 2:54 PM, Michael Loftis wrote:
> You do not want to do LACP (or any ae)  over dissimilar links.  You
> will be on a trail of tears of poor performance and wonky behavior.
> LACP/ae is NOT designed for dissimilar links.

if they are nominally similar capacity l3 ecmp with and igp or bfd for
forwarding failure detection is just fine. if you're trying to build a
comon L2 you likely will be sad.

joel

> On Wed, 14, 2015 at 8:15 AM, David Samaniego  wrote:
>> Hi all. I need to create an LACP between two ex3300-24t. This can be
>> of the links transport provider allows me only 802.1Q and the other only
>> 802.1ad.
>> It might be possible to configure the LACP?
>>
>> I appreciate any insight that can be provided.
>>
>> Thank you,
>> David
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[joel jaeggli]

On 10/2/15 2:33 PM, Phil Rosenthal wrote:
>> On Oct 2, 2015, at 5:11 PM, Colton Conor  wrote:
>>
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?

afaik the re2000 was a single core pentium-m the re4x1800 is a bit more
robust.

> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>>
>>>
>>>
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html


 "Statement introduced in Junos OS Release 13.3 R4"
>>>
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>>
>>> Mark.
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

[joel jaeggli]

On 9/27/15 12:01 PM, Phil Bedard wrote:
> The 16x10G cards are not going to be full line rate at all packet
> sizes and depending on destinations can't push full line rate due to
> limitations to fabric BW on each PFE.

afaik the 16 x 10 fixed mpc was 1.2:1 oversubscribed.

> Phil
> 
> -Original Message- From: "Robert Hass"  
> Sent: ‎9/‎26/‎2015 8:42 AM To: "juniper-nsp@puck.nether.net"
>  Subject: [j-nsp] Cheaper way to have
> 2x100G and 16x10G wire-speed in MX480
> 
> Hi What is cheapest way to choose proper MPC/MICs to have 2x100G and
> 16x10G all wire-speed plus possibility to extend my configuration to
> total 32x10G and 4x100G ?
> 
> Is it possible to have 200Gbps (400G in both directions) per slot in
> cast of malfunction of one fabric card ?
> 
> What you can suggest ?
> 
> Rob ___ 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
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cooling Pads for Juniper SRX?

[joel jaeggli]

On 12/1/14 8:26 PM, Skeeve Stevens wrote:
> Hi all,
> 
> I have an issue with some Juniper SRX100's overheating.  I've seen them get
> hot before, especially placed on something similar (i.e. another SRX100)...
> and given warnings of overheating, but never shut down but this
> situation is different.
>
> These SRX100's are shutting down as they are reaching a core temperature of
> 70c as they are located in racks that are outside in the sun and on
> particularly hot days - around 32c-36c they overheat and turn themselves
> off.

It's a fanless enclosure, if it's in a pedestal or some kind on
enclosure, you could run it with the top off.

> Some might say this is understandable... and I sort of agree.  Although
> their operating system says they are good to 40c, that doesn't really seem
> to be the case.  The SRX110's are a little more tolerant given they are
> bigger units - but have the same operating environmentals (along with the
> EX2200-C).  But at the moment I have the SRX100's and would prefer not to
> swap them out as it will cost significantly.
> 
> Then one of my staff had (what I think) a good idea today... to use cooling
> pads... maybe like the ones you use for laptops or something.

there exist a variety of rack or panel mount fans...

http://www.rackmountmart.com/html/fS.htm

there was a while where I'd recycle the fan trays from total-control
chassis to exhaust air out the tops of cabinets. but that was 15 years ago.

> So I am wondering if anyone has been some solid - not $20 junk or such..
> but something that runs off mains, and works well 24x7x365 - maybe even
> something that only kicks in once a certain temperature has been reached.
> 
> I thought if anywhere, a couple of these mailing lists might have had some
> experience with these kinds of things - especially for those who have built
> regional pops and have had to cool some equipment.
> 
> Thanks all!
> 
> ...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 ;  
> linkedin.com/in/skeeve
> 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper T640 DC power cable lugs

[joel jaeggli]

it's .63 center to center...

the only part of the spec you care about is

Cable lug; dual hole, sized to fit 1/4-20 UNC terminal studs at 15.86-mm
(0.625-in.) center line.

https://www.anixter.com/en_au/product-set.Electrical%2BSupplies.Power%2BConnectors%2Band%2BLugs.html

this is probably a walkup item at your local graybar,

On 6/5/14, 5:33 PM, Scott wrote:
> Hi Guys,
> 
> I am hoping somebody here can point me in the right direction.
> 
> I have two T640's sitting around here at the office after it was
> decommissioned which I would like to start using in our lab for JUNOS
> testing purposes. Unfortunately while it was being decommissioned, the DC
> also removed cabling so we lost the original power cable lugs which came in
> the accessory box when it shipped.
> 
> The router is no longer under a support contract so I can't really ask JTAC
> for any guidance and our SE didn't know if they could be purchased
> separately. I have literally googled for hours but can't find anything that
> has the exact same dimensions and specs as listed on
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/dc-power-t640-cable-specifications.html
> .
> 
> Does anyone happen to know where I could purchase these specific cable lugs
> online?
> 
> Thanks!
> 
> Scott
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Trio Bandwidth

[joel jaeggli]

On 5/30/14, 10:32 AM, Eric Van Tol wrote:
> Hi all, I'm trying to clear something up that's been bothering me for
> some time and that is the MPC1/MPC2/MPC3E actual bandwidth specs.  I
> know from various sources that the MPC1 has a single Trio chipset,
> MPC2 has two Trio chipsets, and the MPC3E has a single enhanced Trio
> chipset.
> 
> The question I have is related to bandwidth.  The Juniper MX Series
> book says the MPC1 is 40Gb/s throughput, the MPC2 is 80Gb/s
> throughput, and the MPC3E is 130Gb/s throughput.  Are these numbers
> in "full duplex" rates, ie. the MPC2 can only handle 4x10G ports
> total before it is oversubscribed?  Or is the total throughput on
> each one really 80Gb/s, 160Gb/s, and 260Gb/s bi-directionally?

the bandwidth is symmetric... the forwarding lookup is only done on the
ingress linecard.

> Bonus question - what does the 'Enhanced' portion of the MPC1E/MPC2E
> provide over the original non-E versions?

larger microcode size

which impacts the availability of some relatively esoteric features...

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TACACS and Logical systems

[joel jaeggli]

On 3/20/14, 1:40 PM, Amos Rosenboim wrote:
> Hello Everybody,
> 
> One of our customers is going to implement logical systems in his network 
> (core and access on the same box, different logical systems).
> All user accounts are based on TACACS with AD integration.

this may be hearesy but the juniper's can be configured to authenticate
against the AD server directly via radius.

there are radius VSAs that can  be employed for various levels of access
control

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-system-basics/configuring-juniper-networks-vendor-specific-radius-attributes.html

http://dice.neko-san.net/2012/08/linking-junos-authentication-to-active-directory-using-radius/

> Our challenge is with the network operations folks, we would like to provide 
> them limited access to the core (base) and full access on the access router.
> So far the only option we could think of was to have different source IP when 
> accessing the core and access, and assign privileges in the TACACS based on 
> the combination of user and source IP.
> I'm wondering if anyone has deployed something more elegant from this ?
> 
> Regards
> 
> Amos
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Product against DDoS

[joel jaeggli]

On 2/18/14, 4:43 PM, Dobbins, Roland wrote:
> 
> On Feb 19, 2014, at 7:10 AM, Darius Jahandarie
>  wrote:
> 
>> It is worth pointing out that no transit providers actually accept
>> flowspec.
> 
> Some transit providers do in fact utilize flowspec, keeping in mind
> various implementation and performance issues.  I don't know of any
> who accept it from downstream customers, but that doesn't mean there
> aren't any, of course.

some experience with labbing it says you don't know which or when
flowsec route insertion is going to cause aberrant performance. In the
optimistic case that means at a minimum you want the operation of the
router and the flowspec to be coordinated because remediation may be
required.

> ---
>
> 
Roland Dobbins  // 
> 
> Luck is the residue of opportunity and design.
> 
> -- John Milton
> 
> 
> ___ juniper-nsp mailing
> list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

On 1/31/14, 7:08 AM, Chuck Anderson wrote:
> On Thu, Jan 30, 2014 at 10:58:05PM -0800, joel jaeggli wrote:
>> http://tools.ietf.org/search/rfc6192
>>
>> has an excellent example recipie for juniper and cisco control-plane
>> protection.
>>
>> it's a good starting off point and it covers the rational behind the
>> various elements in detail.
> 
>   "o  Permit all other IPv4 and IPv6 traffic that was not explicitly
>   matched in a class above, rate-limited to 500 kbps, and drop above
>   that rate for each category"
> 
> Why would one want a default-allow policy, even rate-limited, for the
> control-plane?

traceroute.

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

http://tools.ietf.org/search/rfc6192

has an excellent example recipie for juniper and cisco control-plane
protection.

it's a good starting off point and it covers the rational behind the
various elements in detail.

some things like my l2 policer were meant to solve invidualized needs
there are probably examples in the wild albiet I can probably also dig
one up.

On 1/30/14, 10:03 PM, Misak Khachatryan wrote:
> Thanks Saku and Joel for detailed explanations,
> 
> Do You know any good resource to start with lo filters? Recommendations
> about how much police several types of packets and so on. I don't want
> to do much experiments on production network.
> 
> joel jaeggli wrote:
>> On 1/30/14, 6:46 AM, Saku Ytti wrote:
>>> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:
>>>
>>>> Thanks Abhi, i saw this document, but i need real life experience
>>>> about hardening thresholds or implementing additional
>>>> filter/policers.
>>>
>>> In my experience there is some build-in unconfigurable policer to
>>> limit how
>>> many packets can hit control-plane.
>>> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy
>>> camper,
>>> with control-plane CPU load in MX960 just few percentage, it should
>>> be dying,
>>> the global policer is just making attackers job easier by essentially
>>> downgrading CPU performance.
>>>
>>> So it probably goes something like this
>>>
>>> traffic => if-filter => lo-filter => ddos-policer =>
>>> global-unconfigurable-policer
>>>
>>> Stock limitation to most DDoS policers are 20kpps, which is more than
>>> enough
>>> to bring MX960 to its knees
>>>
>>> If your DDoS policer can see good and bad traffic, low limit will
>>> just make
>>> attacking easier. It's mostly useful to catch things lo0 cannot
>>> reasonably
>>> protect like HTTP rate (you'd need <=4Mbps policer to have
>>> accceptable pps),
>>> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
>>> accidental errors causing flood of 'trusted/good' packets.
>>> But in this case, you'd rather keep IGP and BGP rocking than
>>> multicast, so I'd
>>> police all non-critical to under 4kpps in DoS policer. For for
>>> critical I'd
>>> try to guarantee only good traffic passes lo0.
>>
>> A good solid control-plane protection acl with sensible rate limits is a
>> good place to start.
>>
>>> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
>>> unique policer, making sure that one session attacking does not stop
>>> non-attacking sessions from working.
>>> Shorter term JunOS should add PPS policers in FW filters for proper lo0
>>> filtering and configurable global policer (I'd just remove it
>>> personally).
>>
>> iirc from arp-storm-land I set per interface policers at limits lower
>> than those for the global policers (which are poorly or undocumented
>> (and vary by release/platform)) but can of course be emperically
>> determined. the upshot of that was the interface melting before the
>> whole box did.
>>
>>>
>>>
>>
>>
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

On 1/30/14, 6:46 AM, Saku Ytti wrote:
> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:
> 
>> Thanks Abhi, i saw this document, but i need real life experience
>> about hardening thresholds or implementing additional
>> filter/policers.
> 
> In my experience there is some build-in unconfigurable policer to limit how
> many packets can hit control-plane.
> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
> with control-plane CPU load in MX960 just few percentage, it should be dying,
> the global policer is just making attackers job easier by essentially
> downgrading CPU performance.
> 
> So it probably goes something like this
> 
> traffic => if-filter => lo-filter => ddos-policer =>
> global-unconfigurable-policer
> 
> Stock limitation to most DDoS policers are 20kpps, which is more than enough
> to bring MX960 to its knees
> 
> If your DDoS policer can see good and bad traffic, low limit will just make
> attacking easier. It's mostly useful to catch things lo0 cannot reasonably
> protect like HTTP rate (you'd need <=4Mbps policer to have accceptable pps),
> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
> accidental errors causing flood of 'trusted/good' packets.
> But in this case, you'd rather keep IGP and BGP rocking than multicast, so I'd
> police all non-critical to under 4kpps in DoS policer. For for critical I'd
> try to guarantee only good traffic passes lo0.

A good solid control-plane protection acl with sensible rate limits is a
good place to start.

> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
> unique policer, making sure that one session attacking does not stop
> non-attacking sessions from working.
> Shorter term JunOS should add PPS policers in FW filters for proper lo0
> filtering and configurable global policer (I'd just remove it personally).

iirc from arp-storm-land I set per interface policers at limits lower
than those for the global policers (which are poorly or undocumented
(and vary by release/platform)) but can of course be emperically
determined. the upshot of that was the interface melting before the
whole box did.

> 
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 - Release 12.3R4

[joel jaeggli]

we have 12.3r4 on 960/480/240 all re2000 4GB 32 bit  all mpc/trio

we had some more than cosmetic issues with early 12.3 especially r1.7
this looks tollerable.

On 1/21/14, 7:00 PM, Giuliano Medalha wrote:
> ​People,
> 
> Does anyone used JUNOS 12.3R4 on MX960 gear ?
> 
> Is this a stable release ?
> 
> Could you please send some feedback about it ?
> 
> We have a recommendation of using it but we need to know if is stable or
> not in production environment ... considering BGP and MPLS.
> 
> Thanks a lot,
> 
> Giuliano
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[joel jaeggli]

On 1/13/14, 8:10 PM, Mark Tees wrote:
> Thanks Ben I will review those links.
> 
> I have the MX book and have read a decent portion of it. Thats what I was
> referring to. A quick glance shows some similar examples as to what was in
> the MX book. Same author so it makes sense.

RFC 6192

http://tools.ietf.org/search/rfc6192

Has good examples of juniper and cisco control-plane acls for ipv4 and ipv6.

Doug's book is as you noted also rather good.

IMHO this is basic belt and suspenders for router deployment and
everyone should do this.

> 
> On Tue, Jan 14, 2014 at 2:52 PM, Ben Dale  wrote:
> 
>>
>> On 14 Jan 2014, at 12:31 pm, Mark Tees  wrote:
>>
>>> What I was referring to was a detailed ACL/Filter for lo0 that only
>> allows
>>> traffic for enabled services on the routing engine.
>>>
>>> For example if Juniper posted a firewall filter template with all the
>>> possible services customers could then activate/deactivate what they need
>>> from the policy and log fails before discarding etc.
>>
>> What you think you're after is "show system connections" which is more or
>> less "netstat -an" and shows all ports that are listening on your RE - you
>> can now filter at will.
>>
>> Providing a list of every service for people to modify is not going to
>> solve these problems - "Oh hey, I'm using NTP, I'd better enable all those
>> rules"..
>>
>> What you actually want is an ACL with ONLY the services you've actually
>> configured and understand from the source/destinations you're using them
>> from and deny all else - then you *mostly* don't need to worry about this
>> sort of thing.
>>
>> If your employer is too tight to spring for the MX book (worth every cent
>> and then some), the following free Day One books will provide everything
>> you're after (sign up for a J-Net login if you don't already have one):
>>
>>
>> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/
>>
>> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/
>>
>> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/configuring-junos-policies/
>>
>> Ben
> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX and ipfix

[joel jaeggli]

On 1/7/14, 8:44 AM, OBrien, Will wrote:
> It looks like I need ipfix to get full flows from MPCs on the MX. From the 
> Juniper site, it seems that I need 12.x code. Is anyone happily running it? 
> I've got 12 on some small SRX, but have been very conservative on MX code 
> loads.

Been running 12.3 since middle of last year... more than cosmetic bugs,
it appears to have settled down (now running 4.6)

> I use bgp, ospf,  vrrp, mc-lag, and some routing instances.
> 
> 
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anybody use dual RE in srx3k? SCM only?

[joel jaeggli]

On 12/16/13, 1:07 PM, Morgan McLean wrote:
> Hi all,
> 
> Looking into installing the SCM module into a couple of SRX3600's I have in
> production. Notice the diagram from juniper says slot RE1 for SCM. Do they
> support running another RE? Just curious if anybody does this, if its worth
> it or if its even possible.
> 

typically if you have another RE it's sitting in another chassis as part
of the cluster. I don't think a 3600 can support a second RE in the
chassis in any kind of useful context.



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX104

[joel jaeggli]

On Nov 12, 2013, at 12:46 PM, Saku Ytti  wrote:

> On (2013-11-12 20:14 +), Tom Storey wrote:
> 
>> Why so much just to enable some ports? How do they come up with that
>> kind of price? Pluck it out of thin air?
>> 
>> The hardware has been paid for, and I know thats only list pricing,
>> but it still seems ridiculous.
> 
> The question might have been rhetoric. But I'll bite.
> 
> The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the
> volume you can sell them also is very very small, so the margins need to be
> very high to be able to design and support them.
> Licensing allows you to sell to larger group of people, people who normally
> would buy smaller/inferior box, now can afford it,  which in turn allows you
> to reduce your margins, making you more competitive.
> 
> I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell
> test-kit with some sort of 'per hours used' license. Lot of SPs have need for
> proper testing kit, but only will need them very irregularly. And renting is
> always such a chore. It's same thing there, BOM is nothing, but volume is even
> lower, so prices are ridiculously high, consequently proper testing is very
> rarely done by other than telco size SPs.

It’s one of those things where you work with account team. if the commercial 
terms don’t work out for most potential buyers, then the product won’t be 
successful and either things will change or they won’t. 

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] command monitor

[joel jaeggli]

routers don't track state of flows on ports… so typically the equivalent 
information is generated through packet sampling and then netflow export which 
is sent to a collector (nfsen for example) and then analyzed.

joel

On Oct 8, 2013, at 10:22 AM, Rodrigo Augusto  wrote:

> Hi folks!
> 
> Does anyone knows if junos have a command as equal linux iftop ?!
> Thanks!
> Rodrigo Augusto
> Gestor de T.I. Grupo Connectoway
> http://www.connectoway.com.br 
> http://www.1telecom.com.br 
> * rodr...@connectoway.com.br
> ( (81) 3366-7376
> ( (81) 8184-3646
> ( INOC-DBA 52965*100
> 
> 
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TCN guard on Juniper EX

[joel jaeggli]

segmenting the office from the DC by subnetting seems like a really easy
win.

On 9/11/13 4:45 AM, Ben Dale wrote:
> Hi Dennis,
> 
> The closest thing Junos has at the moment is root-guard, which would stop 
> your Netgears assuming root for the topology, but AFAIK TCNs would still be 
> accepted and acted upon.
> 
> Are your netgear boxes manageable?  You can't force ports into edge mode to 
> stop this?
> 
> On 11/09/2013, at 8:18 PM, Dennis Hagens  wrote:
> 
>> Hi All,
>>
>> Is there some way to filter out STP TCN BPDU's on a Juniper EX series switch?
>>
>> We have some old Netgears in our office environment (yes, I need to get rid 
>> of those) which send TCN's on edge port flaps.
>> This causes a lot of reconvergence / mac table flushes on our datacenter 
>> switches, which are connected via layer 2 with the office. We currently 
>> hooked up an HP switch with TCN  guard to mitigate this, but this introduces 
>> a SPOF.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Dennis Hagens
>> ___
>> 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 server recommendations

[joel jaeggli]

On 9/7/13 12:30 AM, Saku Ytti wrote:
> On (2013-09-07 04:23 +), Luechtefeld, Daniel G wrote:
> 
>> My QFabric will need at least 24 terminal server ports for all the console 
>> ports. I'd like one with options for an OOB POTS and/or cellular modem. What 
>> are your recommendations?
> 
> This is quite common question, but more rarely are people listing features
> they think are important in OOB. I'd love to hear that.

we use advocent 6048. imho they cost more than they should, but they do
the business.


> For me
> 
> a) persistently log what console ports output (good for post-mortem)
> 
> b) does not block connection to console, when one user connects (maybe NOC
> guy connected there, and went to lunch, very handy if device will upon
> connect offer a) share b) snoop c) disconnect existing user)
> 
> c) allows assigning IPv6 address to the console port and doing automatic
> ssh forward to it, so if 'ssh box' is dead, connecting to console is as
> easy as 'ssh box.oob', no need for training
> 
> d) allows easy way to send break, if JunOS is completely dead, you can get
> to debugger via break and powercycle box, without physical access. However,
> also it should guard from accidental breaks, maybe programmable
> key-sequence which causes break to be send, but nothing else (I use ^B^R^K
> in crisco)
> 
> e) way to monitor that when you'll need the OOB, it will actually work
> (this probably is very hard to guarantee by vendor, you'll probably need to
> just make script to periodically 'ssh box.oob, login, logout'. 
> 
> f) device itself supports tacacs and CLI dumping+storing of config, for
> easy replacement of defective unit
> 
> g) auto-sensing and/or software configurable pin-out
> 
> 
> 
> 
> And long term, please include in your RFQ scoring item for _proper_ OOB,
> separate OOB/MGMT CPU (like ilmi, cmp) not fate-sharing the control-plane.
> Which has ethernet port, sshd, dhcp-client. So you'll just ssh in, reset
> control-plane or for fresh box of factory, you ssh in, copy image and
> base-config.
> 

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

Re: [j-nsp] Connecting two spanning-tree domains

[joel jaeggli]

On 8/27/13 8:16 AM, Johan Borch wrote:
> This is basically two datacenters with a lot of devices on each side, and I
> need to exchange vlans in a redundant way. I need something solid so that
> one side can't interfere with the other side. Is there some way to add an
> extra L2 device between the networks to act as some kind of spanning tree
> "firewall" ;) talking MSTP and RSTP but not changing the root on either
> side?
>
You've arrived at a point where spanning tree may be running out of
steam, depending on your choice of platforms you should probably be
looking at trill/spb/L2vpn to glue these together. at some pooint you're
also going to want to use all your paths rather than blocking some of
them to build a loop-free topology.
> Regards
> Johan
>
>
> On Tue, Aug 27, 2013 at 4:20 PM, Marvin Bartchlett
> wrote:
>
>>  You will have to be very careful. If I’m not mistaken MST actually uses
>> CST to tie together the multiple spanning tree instances running in MST. If
>> you tie in a Cisco device running RSTP the Juniper and Cisco devices will
>> default to CST on those links since that’s the common ground (as Johan said
>> below).
>>
>> This will trigger a spanning-tree root election on your CST instance -
>> depending on how you have things configed you may endup with different
>> roots. This could effect the flow of your MST instances that rely on CST.
>>
>>  Best regards,
>> Marvin Bartchlett
>> Juniper Networks
>> Resident Engineer - City of Lakeland, FL
>> Mobile: +1-904-614-1712
>> Skype & Google+: mbartchlett
>>
>>  *From:* Ge Moua
>> *Sent:* Tuesday, August 27, 2013 9:35 AM
>> *To:* Johan Borch
>> *Cc:* juniper-nsp@puck.nether.net
>>
>> This is a juniper forum so I apologize ahead of time for the vendor-C
>> reference below (but standards-based L2 works mostly the same across all
>> vendor implementations):
>>
>> https://supportforums.cisco.com/thread/344842
>>
>> --
>> Regards,
>> Ge Moua
>> Univ of Minn Alumnus
>> --
>>
>> On 08/27/2013 08:16 AM, Johan Borch wrote:
>>> Will that mean that I still have two roots, one in each network and
>>> that they don't affect each other?
>>> Regards
>>> Johan
>>>
>>>
>>> On Tue, Aug 27, 2013 at 2:53 PM, Ge Moua >> > wrote:
>>>
>>> IIRC once joined, the MST and r-pvst L2 domains will speak CST (as
>>> a common denominator).   You may want to consider pruning vlans
>>> where only needed (esp if you have a high vlan count on either or).
>>>
>>> --
>>> Regards,
>>> Ge Moua
>>> Univ of Minn Alumnus
>>> --
>>>
>>>
>>> On 08/27/2013 03:56 AM, Johan Borch wrote:
>>>
>>> Hi!
>>>
>>> I need to connect two spanning-tree domains, one is running
>>> MSTP and one is
>>> running rapid-pvst. Is this doable? The two networks have
>>> different roots
>>> and it needs to stay like that but I still need redundant
>>> links between
>>> them. I need to transport VLANs from one network to the other
>>> and only one
>>> side support MPLS.
>>>
>>> Ideas? :)
>>>
>>> Regards
>>> Johan
>>> ___
>>> 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

Re: [j-nsp] Vlan question MX

[joel jaeggli]

On 7/8/13 3:00 PM, Tom Storey wrote:

The thing thats confusing me is, who on earth presents a service to a
customer as a tagged service? Ive never come across such a thing.
entirely appart from the case of metro-e/pbb/spb if you're doing L2 or 
L3 vpn, on the PE you can differentiate between tunnels/services 
provided to the customer by helpfully tagging them with a vlan-id.

If you're plugged in to a router interface on the providers side, why is
there a need to add VLAN tagging on top? Similarly, if you're plugged in to
a switch, normally the switch port is just an access port, not a trunk.

Someone help me out here... :-)


On 8 July 2013 22:47, Michael Loftis  wrote:


vlan-tagging tells JunOS to treat the interface as multiple separate
L3 interfaces, identified by VLAN ID.  Their end is almost certainly
similarly configured (maybe as a MPLS PE)

On Mon, Jul 8, 2013 at 10:26 AM, Keith  wrote:

Have this setup in the lab on some srx's but want to get some info
on this.

We have an upstream provider that we use a config:

set interfaces ge-0/1/0 vlan-tagging
set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
set interfaces ge-0/1/0 unit 1500 vlan-id 1500
set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30


We are turning up a second connection to them that will be terminated on

a

10G
link and want us to use the same thing, vlan 1500, just a different IP
address.

Will this cause a problem by having the same vlan id on both links to the
same provider? (I am guessing we are being terminated on different

routers

on their side).

My lab router didn't complain so I'm guessing its probably ok.

Thanks,
Keith

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



--

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
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] Vlan question MX

[joel jaeggli]

On 7/8/13 10:26 AM, Keith wrote:

Have this setup in the lab on some srx's but want to get some info
on this.

We have an upstream provider that we use a config:

set interfaces ge-0/1/0 vlan-tagging
set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
set interfaces ge-0/1/0 unit 1500 vlan-id 1500
set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30


We are turning up a second connection to them that will be terminated 
on a 10G
link and want us to use the same thing, vlan 1500, just a different IP 
address.


Will this cause a problem by having the same vlan id on both links to the
same provider? (I am guessing we are being terminated on different 
routers

on their side).


nope it's a layer-3 interface.

honey badger don't care.

My lab router didn't complain so I'm guessing its probably ok.

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

Re: [j-nsp] RIB and FIB - Memory for MX with LR

[joel jaeggli]

On 6/27/13 8:14 PM, Giuliano Medalha wrote:

People,

Thinking about configuring 2 Logical Systems in a MX480 box with RE1800X4,
how can we provide control for memory allocation ?

The box has the following configuration:

2 x RE1800X4-16GB
1 x MPC-3D-16XGE-SFPP-R-B
2 x SCBE-MX

Is it possible to control the RIB and the FIB size using JUNOS for each
Logical System ?

you can control was get's installed in the fib directly using policy...

my lab logical system route reflectors use something like this to limit 
what they install in the fib


routing-options {
...
forwarding-table {
export [ logical-system-fib-compress reject-all ];
}
}

policy-options {

policy-statement logical-system-fib-compress {
from protocol [ direct static isis ];
then accept;
}
policy-statement reject-all {
then reject;
}

}

which means the bgp rib can grow to fairly outlandish size and not crap 
up the fib associated with that logical system.


obviously you can be a little more fine grained.


Or is it automatic by the system ?

How much routes is possible in FIB for MX480 ?  2.5M ?  For this board when
create logical system it divide by two ?

Thanks a lot,

Giuliano
___
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] SRX550 Mode Packet Based for BGP Full Routing

[joel jaeggli]

On 6/21/13 6:55 AM, Pavel Lunin wrote:


 Given the exponential growth of the Internet BGP table, this is not 
going scale in the long term.

http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&range=--OR--&StartDate=+21-Jun-2003+1417+&EndDate=+21-Jun-2013+1321&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear

I'm going with linear...


___
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] PSU - MX480

[joel jaeggli]

Sorry, it works fine with two PSUs up was what I meant.

joel jaeggli  wrote:

>On 5/8/13 8:40 PM, John pp wrote:
>> Hey everyone,
>>
>> Few questions here that nobody seems to know!
>> the MX480 requires two PSU's to run
>> I purchased a MPC line card (16xge sfpp), so I need the high capacity fans
>> however how many *REGULAR *PSU's are needed for the high capacity fans..
>
>this chassis will run fine with psus up and 3 x 16 x 10 mpc linecard 
>I've never tried it with one.
>
>jjaeggli@XX# run show chassis hardware
>Hardware inventory:
>Item Version  Part number  Serial number Description
>Chassis MX480 Midplane
>Midplane REV 05   710-017414MX480 Midplane
>FPM BoardREV 02   710-017254   Front Panel Display
>PEM 0Rev 03   740-022697 PS 1.2-1.7kW; 100-240V AC in
>PEM 1Rev 03   740-022697PS 1.2-1.7kW; 100-240V AC in
>PEM 2Rev 03   740-022697  PS 1.2-1.7kW; 100-240V AC in
>PEM 3Rev 03   740-022697 PS 1.2-1.7kW; 100-240V AC in
>Routing Engine 0 REV 15   740-013063   RE-S-2000
>Routing Engine 1 REV 15   740-013063   RE-S-2000
>CB 0 REV 10   710-021523MX SCB
>CB 1 REV 10   710-021523   MX SCB
>...
>
>Fan Tray Enhanced Left Fan Tray
>> I'm finding these bigger 2520W PSU's, do I need these to run the high
>> capacity fans? Or will regular suffice? I want to have some fault
>> redundancy,
>>
>> i.e if the the regular can run it with 4 PSU then I'd go with the bigger
>> psu anyway as if one psu fails then we'll run into issues..
>>
>> hope someone can help me here
>>
>> 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
>

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

Re: [j-nsp] PSU - MX480

[joel jaeggli]

On 5/8/13 8:40 PM, John pp wrote:

Hey everyone,

Few questions here that nobody seems to know!
the MX480 requires two PSU's to run
I purchased a MPC line card (16xge sfpp), so I need the high capacity fans
however how many *REGULAR *PSU's are needed for the high capacity fans..


this chassis will run fine with psus up and 3 x 16 x 10 mpc linecard 
I've never tried it with one.


jjaeggli@XX# run show chassis hardware
Hardware inventory:
Item Version  Part number  Serial number Description
Chassis MX480 Midplane
Midplane REV 05   710-017414MX480 Midplane
FPM BoardREV 02   710-017254   Front Panel Display
PEM 0Rev 03   740-022697 PS 1.2-1.7kW; 100-240V AC in
PEM 1Rev 03   740-022697PS 1.2-1.7kW; 100-240V AC in
PEM 2Rev 03   740-022697  PS 1.2-1.7kW; 100-240V AC in
PEM 3Rev 03   740-022697 PS 1.2-1.7kW; 100-240V AC in
Routing Engine 0 REV 15   740-013063   RE-S-2000
Routing Engine 1 REV 15   740-013063   RE-S-2000
CB 0 REV 10   710-021523MX SCB
CB 1 REV 10   710-021523   MX SCB
...

Fan Tray Enhanced Left Fan Tray

I'm finding these bigger 2520W PSU's, do I need these to run the high
capacity fans? Or will regular suffice? I want to have some fault
redundancy,

i.e if the the regular can run it with 4 PSU then I'd go with the bigger
psu anyway as if one psu fails then we'll run into issues..

hope someone can help me here

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] vlans

[joel jaeggli]

On 5/3/13 3:26 PM, John pp wrote:

hey all,

what is the max amt of vlans on an mx480 (4k?)
some people have said 16k but i am unsure
some clarification would be great
it used to be 16k per PFE, I'm sure you could imagine some topologies 
where the router would be able to support a lot more than 16k vlans per 
chassis with that limitation.


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] ex4500 best-effort drops nowhere near congested

[joel jaeggli]

On 5/2/13 1:24 PM, Benny Amorsen wrote:

joel jaeggli  writes:


There's literally no options in between. so a 1/10Gb/s TOR like the
force10 s60 might have 2GB of shared packet buffer, while an like an
arista 7050s-64 would have 9MB for all the ports, assuming you run it
as all 10Gb/s rather than 100/1000/1/4 mixes of ports it can
cut-through-forward to every port which goes a long way toward
ameliorating your exposure to shallow buffers.

Why does cut-through help so much? In theory it should save precisely
one packets worth of memory, i.e. around 9kB per port. 500kB extra
buffer for the whole 50-port switch does not seem like a lot.


Until there's contention for the output side, you should only have one 
packet in the output queue at a time for each port on a cut through 
switch. which is like 96K of buffer for 1500 byte frames on a 64 port switch


Store and forward means you hold onto the packet a lot longer 
mechanically even if nominally you are able to forward at line rate so 
long as there's always a packet in the ouput queue to put on the wire. 
consider that the fastest cut-through 10Gb/s switches now are around 
.4usec and your 1500 byte packet takes ~1.2usec to arrive.


when adding rate conversion, consider that when having a flow come from 
a 10Gb/s to 1Gb/s port that another 1500byte packet can arrive every 
~1.2usec but you can only clock them back out every 12usec. jumbos just 
push the opportunities to queue for rate conversion out that much furthure




Lots of people say that cut-through helps prevents packet loss due to
lack of buffer, so something more complicated must be happening.


/Benny



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

Re: [j-nsp] ex4500 best-effort drops nowhere near congested

[joel jaeggli]

On 5/2/13 10:27 AM, Jeff Wheeler wrote:

On Wed, May 1, 2013 at 8:27 PM, ryanL  wrote:

i'm guessing this is a buffer thing, but i can't explain why it only
happens on my 1ge ports and not when i punt the traffic over an 10ge

Yes, it is a buffer thing.  A 10GE interface is basically never going
to not have time to transmit frames unless it is receiving from 10 or
more 1GE interfaces at the same instant, steadily, for long enough to
fill the buffer; or there is at least one 10GE interface also talking
to it.  On the other hand, two 1GE interfaces transmitting toward the
same out-going 1GE port can fill its buffer.

This is sometimes not obvious, because you look at the long-term
traffic and see a few hundred Mb/s, thinking, "why is there packet
loss?"  You must keep in mind that the available buffer on modern ToR
switches is often less than 1ms worth of traffic.
ex4500 has like 4MB of shared buffer per PFE which is not really enough 
to absorb a lot of microburst type activity.

The "buffer bloat" discussion of recent years has not done us any
favors.  Many customers now think that buffers have historically been
too big.  In fact, they were just often used incorrectly / configured
badly.  Now we are not evaluating purchases based on having sufficient
buffer, so vendors have spent years developing products that ... lack
sufficient buffer.
Well it's a bit different circumstances between tiny CPE routers sitting 
on dsl or cable  endpoint and and a 48port 10Gbe switch. design-wise a 
TOR has either whatever shared memory fits in the asic, or a large 
external buffer. There's literally no options in between. so a 1/10Gb/s 
TOR like the force10 s60 might have 2GB of shared packet buffer, while 
an like an arista 7050s-64 would have 9MB for all the ports, assuming 
you run it as  all 10Gb/s rather than 100/1000/1/4 mixes of 
ports it can cut-through-forward to every port which goes a long way 
toward ameliorating your exposure to shallow buffers.


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

Re: [j-nsp] Class E IP addresses

[joel jaeggli]

On 3/8/10 1:53 PM, keegan.hol...@sungard.com wrote:
As with most other "dirty" address ranges these will inevitably be 
used for something. It's just a fact of life as IPv4 space becomes 
more and more scarce. For example APNIC has begun assigning addresses 
in the previously reserved and often hijacked 1.0/8 range.
1/8 assignments were made 4 years ago (1/8 and 27/8 were assigned to 
apnic on jan 2010)


regarding 240/4 I'm pretty sure that's been a feature request for a 
while.I probably wouldn't put those on any interface facing hosts.



- wrote: -

To: juniper-nsp@puck.nether.net
From: Chuck Anderson 
Sent by: 
Date: 03/08/2010 04:08PM
Subject: [j-nsp] Class E IP addresses

From 9.6 release notes:

Class E addresses—The JUNOS Software now allows Class E addresses
to be
configured on interfaces. To allow Class E addresses to be
configured on
interfaces, remove the Class E prefix from the list of martian
addresses by
including the [edit routing-options martians 240/4 orlonger allow]
configuration
statement.

Whoa. What is the use of this? While it sounds like a neat idea to
reclaim Class E for actual use in this age of IPv4 depletion, the
idea
loses its appeal once you realize the huge numbers of legacy devices
that won't want to have anything to do with Class E.
___
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] SNMP on logical-system fxp0

[joel jaeggli]

On 4/25/13 8:47 AM, Saku Ytti wrote:

On (2013-04-25 08:29 -0700), joel jaeggli wrote:


It's not OOB, it's completely fate-sharing the freebsd/junos.

it's not part of the forwarding plane so it certainly is not
in-band, what you connect it to of course is your business. we
connect them to our oob network.

Yes it's not fate-sharing forwarding-plane, but it's fate-sharing the whole
control-plane.
You need ports, wiring to build fxp0 management network, which isn't even
redundant, single port down and it's not reachable.

Lot of cost+complexity for only benefit of being able to configure router
when forwarding is broken but router not.


power cycle the SCB that the alternate RE is in. but having serial
console on on ethernet for example would eliminate a terminal server
potentiallly and that needs to happen eventually imho.

Sadly Cisco did CMP, but removed in Nexus7k RP2, citing thermal/pincount
and lack of customer demand.
People aren't asking for proper solution to this problem in RFQs.


inline flow export is generated in linecard asics so it's not really
suitable for the oob port.

I think this is really my point, you need

* fxp0 for ssh, snmp
* inband for netflow, snmp (if HW)  (redundant)
* rs232 to attempt recovering box from control-plane software failure

Why build fxp0, if you need inband for something anyhow? It costs money,
adds complexity,
I doubt the impact on the BOM is signficant. the EM0/EM1 interfaces and 
the two ethernet switches embedded in the SCBs are a substantially more 
complex bit of RE supporting ethernet, then the third nic which is an 
intel 0x100f8086 sitting on one of the shared 32 pci busses and a port 
out the back. In the more embedded paltforms that's certainly just 
another ethernet embedded in the SOC.


pciconf -lv on your RE can point out just how simple an embedded pc 
you're actually dealing with, there's not a lot of magic there.


compared to what I'd rather have which would be a bmc or chassis 
management controller which actually probably is a significant 
integration issue particularly if you want access to both RE's and the 
SCBs and the linecards because that has to get physically connected via 
the midplane as the current REs are through the SCBs

  and delivers no value if RS232 is also implemented with
in-band.



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

Re: [j-nsp] SNMP on logical-system fxp0

[joel jaeggli]

On 4/25/13 7:55 AM, Brandon Ross wrote:

On Thu, 25 Apr 2013, Saku Ytti wrote:


On (2013-04-24 20:54 -0400), Jeff Wheeler wrote:


My view is that fxp0 is an out-of-band interface for manual
intervention; not one that I ever use for SNMP.
there are differing deployment models, our pop routers are polled by 
devices that are located on their oob network. they are also polled 
inband...


I know personally that it would be convenient to put the management 
interfaces in another routing instance and have snmp  work. the former 
works, the later doesn't. I belive that there have been feature requests 
about that for some time.


My view is that fxp0 is completely useless interface.

It's not OOB, it's completely fate-sharing the freebsd/junos.
it's not part of the forwarding plane so it certainly is not in-band, 
what you connect it to of course is your business. we connect them to 
our oob network.
OOB in this context refers to having a different path through the 
network than the path used for production IP traffic.  I see the value 
in having an Ethernet/IP interface that is not fate-sharing with the 
core OS as well, but that doesn't make fxp0 completely useless as 
previously stated.



In RS232 you can at least do 'panic-on-break', not having to rely
freebsd/junos to work to kick the box.
But RS232 sucks otherwise:


I'm not sure why we are suddenly debating the benefits and drawbacks 
of RS232.  The two interface types are there for very different reasons.



Of course correct solution would be, to connect fxp0 to separate HW,
running its own miniOS, from which you could copy imagees, reload RE 
etc.


That essentially what we are talking about.  Connect fxp0 to a 
SEPARATE switch that is used for only out of band traffic.  You then 
use this network to copy images, etc.  What am I missing here?



a basband management controller...

In DUAL RE deployments that's  somewhat less acute becasue you can power 
cycle the SCB that the alternate RE is in. but having serial console on 
on ethernet for example would eliminate a terminal server potentiallly 
and that needs to happen eventually imho.



And no, you would not use this FXP0 for SNMP or Netflow or whatnot.


Sure you can, I've done it, others here have said they've done it. 
Assuming the OOB network is well protected from outside traffic to 
avoid attacks and the like, why not?
inline flow export is generated in linecard asics so it's not really 
suitable for the oob port.


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

Re: [j-nsp] M10i

[joel jaeggli]

On 4/10/13 5:45 PM, Chris Adams wrote:

Once upon a time, Correa Adolfo  said:

I tought MX series were purely ethernet.

I think that was true initially, but (for example) there are MX5-80 MICs
to handle circuits from T1 up to OC192.


http://www.juniper.net/us/en/local/pdf/datasheets/1000378-en.pdf
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Max ARP entries on an MX240?

[joel jaeggli]

On 4/9/13 3:41 PM, Dave Peters - Terabit Systems wrote:

Can't seem to find a specific ceiling on this.  Anyone know the max ARP entries 
on an MX240?
There isn't one, it's going to depend on the amount of memory used for 
the rest of the fib. I imagine that with 2 million or  so l2 next hops 
the control plane would be rather busy.




Thanks in advance.

--Dave Peters

___
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] Stackable switches, looping stacking ports

[joel jaeggli]

On 4/9/13 11:15 AM, Tom Storey wrote:

Hey all.

A colleague of mine tells me that, if you have a single stackable switch
(not in a stack obviously) and do not loop the two stacking ports on the
back using the stacking cable that comes in the box, then you reduce the
effective throughput of the switch.
The ex4200's asic has a capacity of 136Gb/s from the front panel ports 
which is 100% of line rate across all ports. I don't imagine connecting 
the asic back to itself is that useful or usable topology.


Specifically I am talking about an EX4200.

To me this sounds a bit odd, and is not in line with my perhaps rudimentary
understanding of stackable switches, so hoping someone here can clarify
whether looping the stacking ports is good/bad/necessary/unnecessary?

Thanks.
Tom
___
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] Am I carrying this route or not ?

[joel jaeggli]

On 3/24/13 1:24 PM, Zehef Poto wrote:

Thank you Payam. I think I got what you mean.

In this particular case however, the X/22 route is not a customer or
anything. It is the IXP's peering LAN !

So... It means that the person requested all the IXP's members to
null-route the whole peering LAN ? How can you possibly ask for this ?

I peer with several members within this LAN. If I null-route the X/22 LAN,
we agree that my peering sessions will go down, right ?
What they're asking is for you to not carry the prefix in your 
network... The devices directly attached have that route at a lower 
admin distance (e.g. direct) your peering routers will therefore no have 
their sessions go down. However any bgp routes you learn over the 
peering fabric need to have a nexthop that is in your routing table, 
that could be the peering router (nexthop self)  a more specific route 
for the peer router or something else.



Thanks again,

2013/3/24 Payam Chychi 


  Carry a route is the same as accepting a route and having it become
active, allowing traffic to traverse your network to the destination. In
this case the user is asking you to drop the route (attack traffic) at your
edge if possible and not to carry it through your network and deliver it to
the end destination(his network) because its probably saturating or causing
him performance issues.

Normally networks well have a global community string that they can tag a
route with and it will send it to null0, dropping that traffic at the edge
v.s the user withdrawing its -/24 route from the advertise table. You can
also go on the peering router and set the next hop route for the attacked
destination ip to null0 (discard) and only traffic traversing that one
router well drop the traffic (global community well handle this if you
  have a multi homed network)

Local nullroute example:
"Set routing-options static route x.x.x.x/32 discard" ... Something like
this

All your doing is dropping traffic for x.x.x.x/x at your edge, most cases
its a /32 nullroute.

Google is your friend :)
Cheers,
--
Payam Chychi
Network Engineer / Security Specialist

On Sunday, 24 March, 2013 at 6:47 AM, Zehef Poto wrote:

Hey guys,

Thank you all for the very valuable input. Actually yes, Tobias is right,
I'm having this question because of the (quoted by Tobias) e-mail we got
yesterday across several IXPs.

I just don't understand what is to "carry a route in my backbone". Am I not
supposed to know all of (or most of) the Internet routes, since I work with
tier-1 upstream providers ? As a consequence, it means I'm carrying all
these routes right ?

A "show route X/22" tells that it was advertised by an eBGP peer on one of
my edge routers, and the three other ones learnt this same route via OSPF.

This is where I'm completely confused. What am I supposed to do to "carry"
a route or not ?

Thanks again,

2013/3/24 Tobias Heister 

Hi All,

Am 24.03.2013 00:26, schrieb Jeff Wheeler:

Whoever that person is that said something about "use next-hop-self"
in this context, either you misunderstood them, or you shouldn't
listen to them anymore. That has nothing to do with looking to see if
your router knows about a route.


This sounds like the OP wants to help the cloudfare guys who send the
following mail to DECIX/AMSIX (and probably other IX) yesterday.

We're currently seeing a very large attack directed to our IP on AMS-IX

(X).


We request that all peers:

1) Don't carry this route (X/22) in your backbone. (you can set

next-hop-self, etc). It'll save other security concerns and possible free
transit you're giving away to others.

2) Filter any traffic within to the AMS-IX exchange fabric (again,

X/22), except for your point to [multi]point BGP communications.

--
Kind Regards
Tobias Heister

___
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] ability to turn USB port on/off for MX routing engine?

[joel jaeggli]

You can turn off/on the alarm and warn circuits via the craft interface, 
which might do what you want, could use that to drive a relay.


joel

On 3/19/13 11:50 AM, Morgan McLean wrote:

I can see turning off USB from a security stand point, like disabling
console toobut then again in the event of needing to restore the device
that could be a big problem.

AND, if they have physical access, the war is already lost.

...Also, I don't think you should really be powering devices with your
routers? Just an opinion. Not exactly what its designed for.

Morgan


On Tue, Mar 19, 2013 at 11:28 AM, Clarke Morledge  wrote:


To answer my own question, I found out from JTAC that the ability to turn
off the power to the USB port on an MX routing engine is not possible
because it is "not supported".

I thought Junos was built on FreeBSD.   Aren't you supposed to be able to
do just about anything you want with FreeBSD?


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsp






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

Re: [j-nsp] Hashing on M10i LAG interfaces

[joel jaeggli]

On 3/14/13 1:33 PM, Chris Adams wrote:

I'm probably missing an obvious search term, but I didn't find this
myself, so asking...

How does an M10i hash packets to choose a link on a LAG interface?  Is
it configurable?  This is on a PE-4FE-TX if it matters.

http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/hash-key-edit-forwarding-options.html

that describes the hash key

modern mx uses enhanced key instead.

I found a document that says EX switches used a fixed (non-configurable)
hash method that includes source/dest MAC, IP, and (IIRC) port (I can't
find that page again now either; my Google-fu is slipping).



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

Re: [j-nsp] MX Series MIBS

[joel jaeggli]

On 3/4/13 8:15 AM, Josh Hoppes wrote:

A full set of MIBs are available here:
http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/juniper-specific-mibs-junos-nm.html

This MIB is is probably the one you want:
http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/mibs/mib-jnx-chassis.txt

They are versioned, I just linked to 11.4 as we are using that release
but I would make sure to use the one applicable for your deployment.
It's also worth noting that the m-series cacti templates do monitor the 
values you're looking for in the mx in general.

On Mon, Mar 4, 2013 at 9:09 AM, Brian Johnson  wrote:

I am having a difficult time determining what MIBs to monitor on my new Juniper 
MX routers. I come from a Cisco shop and know how to monitor CPU, memory and 
(of course) interface stats. I'm having no issues with monitoring interfaces, 
but cannot determine what MIBs to monitor for CPU and memory usage.

I am using Cacti and could not find a good template for MX routers out there. 
I'd be willing to build and share if anyone can tell me what important system 
mibs to graph and supply the mibs for the MX5 through MX80 units.

Thanks

- Brian



___
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] MX80 BGP performance after reboot

[joel jaeggli]

On 2/13/13 10:42 PM, Caillin Bathern wrote:

Couldn't RPD just reduce the TCP window size for BGP sessions to reduce
the rate at which it can receive routes from neighbouring routers?
This would mean that your FIB would always be synched to your RIB and
other routers would not blackhole by sending traffic to the router in
question (who's FIB is lagging behind its RIB), no?


as an aside,

When we're doing a maintence we generally let the router converge with 
our route-reflectors prior to bringing up the transit/peer neighbors. so 
that routes learned from the transits are replacing existing fib routes. 
that also has a salubrious interaction with our loose rpf check. 
spontaneous reboots aren't quite adjustable like that.


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Tuesday, 12 February 2013 12:43 PM
To: 'Juniper NSP'
Subject: Re: [j-nsp] MX80 BGP performance after reboot

I was there for that lightning talk (and very recently seen that
"feature"
actually happening) but what's getting described here by the OP doesn't
seem to be the same maybe I'm misunderstanding.

Paul

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler
Sent: February-11-13 6:59 PM
To: Juniper NSP
Subject: Re: [j-nsp] MX80 BGP performance after reboot

On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
 wrote:

I noticed that a MX80 takes quite a long time after reboot to put all
routes into the KRT. Is that normal for that box? It takes around 10
minutes after BGP is established to get all the routes into the KRT

Yes, the routes taking a long time to install is "normal,"
unfortunately.  I feel like it has got worse since 10.4 but that might
be my imagination.

I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which
was something like "if you want your routers to install routes, call
Juniper and reference PR# because they do not want to fix this
bug."

I am hopeful that the move away from a single Junos release strategy to
some segregation among different products will allow Juniper to be more
flexible in how they allocate development resources to different
platforms.

If I had to guess, I'd say the ddos-related log messages you are reading
are related to excessive need to generate ttl_exceeded packets because
of routing loops while BGP is announcing to neighboring routers but the
routes are not actually installed in the FIB yet.
Even if I am wrong about the specifics here, I am certain it is only a
symptom of the problem which is unrelated to the ddos-protection
feature.

--
Jeff S Wheeler 
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
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg


___
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

[joel jaeggli]

On 1/24/13 2:53 PM, Stephen Hon wrote:

Ouch… I picked a single MX480 chassis design over a dual MX80 because of
the unavailability of the MS-DPC card in the MX80.

yeah that's a consideration if you need an msdpc.

We're very new to Juniper here with close to no practical experience.
Nonetheless, we're migrating away from Brocade NetIron MLX to the MX and
we figured that dual RE and SCB would helpful relative to ISSU and NSR but
I guess the general consensus is that it's preferable to have separate
routers over redundant RE's.
dual RE and and NSR work and are useful... if you every have to replace 
a failing cb or RE and you do so without a hitch, you'll be pretty 
impressed. software upgrades even without ISSU are simpler and less 
impactful (and easier to recover from) than with only one RE
that said tradeoffs are tradeoffs and everyone has a slightly different 
point at which they compromise to meet their 
price/availability/functional needs.

I'm wondering though, would dividing some of the routing duties into
logical systems help to protect from a massive system-wide problem? From
what I understand the logical systems spin up their own set of processes
and have their own configuration so it would seem that there could be some
level of protection.
___
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] Splitting Dot1q VLAN across Logical Systems

[joel jaeggli]

On 1/24/13 3:24 AM, Skeeve Stevens wrote:

Hey all,

I want to build this scenario.

2 * MX80, with a trunk between then.

On the trunk (as an example) there would be two VLANs.

I would like to take VLAN 100 on Router-A Logical System A to Router-B
Logical System A, while at the same taking VLAN 200 on Router-A Logical
System B to Router-B Logical System B.

Does this make sense?

I'm hearing I have to allocate a whole physical interface to a Logical
System which means I can't use a VLAN from it for another Logical System.

Does this make sense with what I am looking to do?

you:

create  bridge group
put two vlans inside it
create an irb for each vlan
add each irb to a different logical system or routing instance

something like that.

Thanks ;-)
*

*
*Skeeve Stevens, CEO - *eintellego Pty Ltd
ske...@eintellego.net ; www.eintellego.net

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

facebook.com/eintellego ;  
linkedin.com/in/skeeve

twitter.com/networkceoau ; blog: www.network-ceo.net

The Experts Who The Experts Call
Juniper - Cisco – IBM - Brocade - Cloud
-
Check out our Juniper promotion website!  eintellego.mx
___
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

[joel jaeggli]

On 1/21/13 11:44 PM, Saku Ytti wrote:

On (2013-01-21 21:40 +0100), Markus H wrote:


I wonder what kind of redundancy the community would prefer for
small-medium sized PoPs.

a) 2xMX80
b) 1xMX240/480 with redundant SCB and RE

a) no question. As long as you can live with modest RE performance of MX80.
Routing separated two units always better than stateful single unit.

Frankly, I'm not sure if dual RE even delivers better MTBF, since it does
expose you to new issues, even outside HW failures. It probably does
deliver you better MTTR though.


I would always take two routers over one router with two RE's

I have Lost RE's or crashed them in ways that a second RE helped enough 
to consider them worthwhile, and  sometimes they make upgrading easier, 
but sometimes they make it harder, and it's pretty easy to justify 
trading lower cost and less complexity for modularity.


The original poster I think raised the issue of load balancing between 
upstream(s). realistically that isn't that hard if you're architecture 
is designed to account for it.


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

Re: [j-nsp] Smallest size IPv6 allocation typically advertised?

[Joel jaeggli]

On 1/22/13 17:19 , Morgan McLean wrote:
> Hi,
> 
> Just curious what the smallest v6 advertisement providers will accept is
> these days? I've seen no smaller than /48 mentioned on various boards, but
> I see arin will allocate all the way down to /32. 

A /32 is 16 bits shorter than a /48. and they'll do provider assignments
substantially shorter than /32 based on need.

While I occasionally see advertisements longer than a /48, my own
filters and those of many others seem to be on that basis.

> We currently have a /48,
> and I advertise the whole thing but I'm considering splitting it up among
> multiple sites.

if you are consider de-aggregating you should revise your request to
represent the number of sites that you have to refelect that. eg a /44
would be enough to support 16 sites support de-aggregation as necessary
and so forth.

> I haven't contacted my providers yet, I'm just curious.
> 

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

Re: [j-nsp] EX4200 VC PFE crashes

[joel jaeggli]

On 1/18/13 4:19 AM, Alexander Bochmann wrote:

Hi,

...on Mon, Jan 14, 2013 at 08:55:36PM +0100, Dennis Krul | Tilaa wrote:

  > So that means thousands of MAC, ARP and v6 neighbour entries in the PFE 
database (but nowhere near the supported limit of 16k entries).

16k doesn't seem realistic as soon as v6 is involved.

As far as I have heard, the EX4200 on the network for an event I recently
attended went down with slightly more than 1000 v6 ND entries... In the end
they had to move all L3 v6 stuff off those switches.
The chipset in the ex4200 is a little old-school now, the size of a 
subnet you can support is going to be smaller in v6 than v4, as L3 tors 
or aggregation  devices they're probably fine

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] SFP+ Cooper Option (not DAC)

[joel jaeggli]

On 1/17/13 8:14 AM, Giuliano Medalha wrote:

People,

Is there any option to use together with EX Series Switches with SFP+ using
cooper CAT6 cable ?

Or the only cooper option will be the DAC cable ?

Do you know any available option for SFP+ with RJ45 port for 10Gig ?
standalone 10Gbase-t phys currently exceed the power limitations for a 
sfp+ plus port so I imagine they haven't quite been reduced to that form 
factor yet.

Juniper accepts it ?  It works ?

Thanks a lot,

Giuliano
___
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] DDOS and MX-240's

[joel jaeggli]

On 1/6/13 10:51 PM, Bjørn Tore wrote:

Why would you accept any /32s in the first place?
From myself? I accept all sorts of prefix lengths internally that I 
would never accept from the internet.


I accept quite  a few pretty long prefixes from my arbor TMS for 
example, more in the context of RTBH e.g. RFC 5635 and so on.


Bjørn Tore @ mobil

Den 7. jan. 2013 kl. 06:22 skrev Joel jaeggli :


On 1/6/13 20:14 , Richard Gross wrote:

Dear List,

I am seeking advise.  If you wanted to block 800K /32's from your inbound
pipes, how would you do it?

Would you null route?   Put up multiple stanza firewall filters?   Which
way has the least amount of hit on router resources?

so I'd have a discard route, and I'd inject the prefixes from another
box probably quagga with a nexthop of the discard route. I'd expect an
re2000 to injest those routes in about 2 minutes

I probably wouldn't use flowspec for this at this point.


If you would prefer to reply off-list, that would be super.

richg
___
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] DDOS and MX-240's

[Joel jaeggli]

On 1/6/13 20:14 , Richard Gross wrote:
> Dear List,
> 
> I am seeking advise.  If you wanted to block 800K /32's from your inbound
> pipes, how would you do it?
> 
> Would you null route?   Put up multiple stanza firewall filters?   Which
> way has the least amount of hit on router resources?

so I'd have a discard route, and I'd inject the prefixes from another
box probably quagga with a nexthop of the discard route. I'd expect an
re2000 to injest those routes in about 2 minutes

I probably wouldn't use flowspec for this at this point.

> If you would prefer to reply off-list, that would be super.
> 
> richg
> ___
> 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] M120 : Arp broadcast messages causes irradic behaviour

[joel jaeggli]

On 11/28/12 10:56 PM, Sunil Mayenkar wrote:

Hello Gentlemen,

Problem faced: When a large broadcast generated by the downstream 
network(1,00,000Pkts per sec) hits the Juniper gigE interface it causes the 
node to behave erratically, not allowing remote login, LSPs flap, until the 
port is shut down.

I understand that a default arp policer is applied on the interface. What is 
the value of this policer? And whether its a good idea to modify this policer?
The  policer is global and iirc varies by platform and release, you can 
police arp storms to lower per interface limits than the global limits  
which does reduce the likelyhood of the box becoming unusable. I recall 
having to experiment in order to get it right.

Thanks in advance.
Sunil Mayenkar
___
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] How reliable is EX multichassis? 3300 and 8200 switches

[joel jaeggli]

On 10/30/12 5:49 PM, Pavel Lunin wrote:

"Richard A Steenbergen"  wrote:


IMHO multi-chassis boxes are for
people who can't figure out routing protocols

When it comes to ethernet switching, "routing protocols" means what? :)

spanning-tree/trill/l2vpn/NVO and so on.

And the same observation  applies,  stacked switches while popular might 
not be the best approach from an availability standpoint.

___
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] VRRP between mixed M7i and M10i

[Joel jaeggli]

On 9/3/12 06:48 , sth...@nethelp.no wrote:
 1) Did someone have a chance to configure a subnet with 4 Mixed routers M7i
 and M10i and VRRP enabled between all of them ?
>>>
>>> VRRP runs between *two* routers. Aside from that, no specific problems
>>> with M7i vs M10i (and why should there be? M7i and M10i are hardware
>>> and software wise very much alike).
>>
>> VRRP can run on more than two routers just fine.  All but one router
>> on any LAN will become a backup.
> 
> Thanks for the correction. A followup question: Under what circumstances
> would you want to configure VRRP on more than two routers on the same
> LAN segment? We've always used just two...

if you have 4 routers...

rtr0
vrrp-priority 101
rtr1
vrrp-priority 99
rtr2
vrrp-priority 97
rtr3
vrrp-priority 95

does exactly what you think it would.

In practice I've done this when shifting traffic beween two pairs (a new
and old pair) of routers.

> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] MX960 AC power strip

[joel jaeggli]

On 8/23/12 6:59 AM, JA wrote:

Hi

I need advice if someone is having an MX960 up on AC power.

Usually high capacity (32A) power bars (PDU) come with C13 or C19 outlets
while Juniper has no provision for such power cords.
we use c19-c20 cables. we have a standard supplier for those so I don't 
believe we're using a juniper p/n


the device (well the whole rack) is fed off two PDUs with a 30a 3 phase 
service for each

  If European power
cords are ordered with MX960, the CEE7/7 plug can be connected to Schuko
outlets. But there is no Schuko PDU that supports more than 16A. One can
easily exceed 16A if two power supplies are connected on same PDU.

Can anyone recommend some alternative or if anyone faced similar situation?
___
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] SRX as a server load balancer for service redundancy?

[joel jaeggli]

On 8/15/12 10:08 AM, Majdi S. Abbas wrote:

On Wed, Aug 15, 2012 at 09:53:07AM -0700, joel jaeggli wrote:

I'm generally down on the idea of putting a stateful firewall in
front of a service that accepts unsolicited incoming connections, it
will tend to be the least scalable item in the path.

That's okay, anyone that does this is quickly going to turn off
the involved ALG, as well as all the TCP state checks.  They may even
wind up in packet mode.
yeah agree, and it should do small packet up to a point, after which 
it's unsuitable, but until then.

Not that a 210 is super scalable to begin with... but now that
the J-series has effectively been turned into the SRX line I suspect
this is more common than we think.
  At least for Juniper's customers,
given the obvious gap in the product line.

--msa



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

Re: [j-nsp] SRX as a server load balancer for service redundancy?

[joel jaeggli]

On 8/15/12 9:34 AM, Scott T. Cameron wrote:

The SRX isn't a loadbalancer.

Use something sensible like haproxy, nginx, etc.
We do layer 3 ecmp in front of our load balancer tier and I imagine that 
would be fairly straight forward to implement with an srx. each 
destination to be load balanced to  is available via several nexthops, 
in this case the destinations are advertised using a ebgp session 
originating from a private ASN.


This approach doesn't deal with application health checks or asymmetric 
load balancing but you can take a destination out of the rotation by 
withdrawing the routes and if the bgp session drops that happens 
automatically. l3+l4 hash per flow load balancing is stateless but 
sticky. it can be implemented on more than one device.


I'm generally down on the idea of putting a stateful firewall in front 
of a service that accepts unsolicited incoming connections, it will tend 
to be the least scalable item in the path.




Scott

On Wed, Aug 15, 2012 at 12:07 PM, OBrien, Will  wrote:


I'm wondering if I can do a simple server load balancer using a SRX.

Example:
Server A offers up service on port .

Server B has the same service.

If Server A goes offline, send traffic over to server B.
Resume when Server A becomes available again.



One thought is to use something like track-ip to push a static nat mapping
around.
Ideally, I'd love to monitor the port.

Ideas or examples? This is really just for failover, rather than load
balancing.


I suppose I could monitor the service from a control machine and have a
script execute a configuration change if the service becomes unreachable.
I'd prefer it if the entire process were managed from the SRX.

(In this case it's a pair of clustered SRX 210s.)

Will
___
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] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP

[joel jaeggli]

On 6/24/12 11:11 AM, Sascha Luck wrote:

On Sun, Jun 24, 2012 at 10:37:22AM -0700, Joel jaeggli wrote:


extending the control-plane of an ethernet switch over tens of
kilometers is a imho a seriously bad idea.


Why, actually? Latency issues?
Latency is a consideration given your control-plane is not distributed. 
What happens when it gets partitioned is a bigger issue. That is a 
problem when they're all in the same  rack and there's a ring of 
stacking cables, it's a bigger problem at considerable remove. finally 
while your  mtbf is about the same for 8 seperate switches vs 8 in a 
stack the impact on overall availability due to stack failure is much 
greater.



rgds,
Sascha



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

Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP

[Joel jaeggli]

On 6/24/12 09:20 , Sascha Luck wrote:
> James,
> 
> On Sun, Jun 24, 2012 at 08:43:22PM +1000, James Jimenez wrote:
>> I am curious with a EX4200 as to the requirements of the uplink ports
>> when
>> attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP
>> module is unable to be used however I have been told that this does in
>> fact
>> work and the documentation may not have caught up yet?
> 
> the information I have is that the extended VC links must be optical. .
> 
>> I am also curious as to the requirements of the fibre uplink ports. If we
>> are purchasing carrier services does it have to be a dark fibre link
>> or are
>> we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We
>> are hoping to VCT a number of chassis over a 30km distance.

extending the control-plane of an ethernet switch over tens of
kilometers is a imho a seriously bad idea.

> AFAIK, VCCP uses non-standard Ethernet frames and there must not be any
> L2 (and up) devices in the VC link path as these devices would drop the
> VCCP frames.
> 
> rgds,
> Sascha Luck
> ___
> 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] Broadcast storm on M7i fxp0 kills the CFEB?

[joel jaeggli]

On 6/22/12 6:28 AM, Phil Mayers wrote:

On 22/06/12 13:29, Amos Rosenboim wrote:

Hello Phil,

I have seen this happen a few times and with different platforms.
A good way to avoid this is to configure policing on the OOB switches
ports facing the REs.


Unfortunately, our OOB network is constructed from older, repurposed 
equipment. I doubt we have the ability to do the required egress 
policing.


What kind of policing parameters have you successfully used?


The arp policer is the one that normally kicks in. there are golobal 
defaults which iirc vary by platform. the trick is to have per interface 
limits which are lower than the global limits so that the policer 
renders that interface unusable without rendering all arp learning on 
the box dead at once.

___
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] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

[joel jaeggli]

On 6/22/12 9:49 AM, Morgan Mclean wrote:

This is exactly what happened. The session table filled up. One of our security 
guys took down our edge 650 cluster from a single unix box out on the net.

This is what happens when you use a stateful box for an internet router.

a  router with a covering aggreate and some knowledge of the more 
specifc on the interior would inexpensively discard traffic bound for 
unreachable destinations.


Sent from my iPhone

On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron"  wrote:


On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean  wrote:


I have a /24 I want to announce, but I don't actually have it anywhere on
the network. I NAT some of its IP's on the SRX that has the BGP session
with our providers.

I've been using static routes with the discard flag, but I don't really
like the way the SRX handles traffic. It still creates sessions for traffic
destined to IP's not used anywhere (hitting the static route) and can be
easily dos'd because of this.

Is there a better way to just tell our providers hey, we have this range?



It sounds like you're using the SRX as an edge router with a BGP session
upstream?

I don't have this architecture here, but I had the same problem.  I had my
edge router announce the /24 to the BGP upstreams, and my SRX announce the
/24 via OSPF to the MX.

Unfortunately, one of my IPs was hammered, and filled up the session table
with invalid sessions.  That's the real issue, at least in my case, was
that even invalid sessions were taking a session, and prohibiting
legitimate traffic from flowing.

The solution was only to announce from SRX to MX (edge router) the /32s
that were actually in use.

I suppose that a firewall filter may help on your ingress ports to only
permit the traffic to the /32s that are actually in use, but I can't say
from experience if this will happen before a session is created, even in
invalid state.

Scott
___
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] More Multicast Routing Help needed please..

[Joel jaeggli]

On 6/22/12 07:37 , Spam wrote:
> Hello All, I've been trying to get multicast routing between 2 vlans on my 
> SRX240 working
> so the Apple Mac's on both vlans can see each other and use their respective 
> services.

bonjour is:

 224.0.0.251

by definition it's local to one subnet.

224.0.0.0   - 224.0.0.255 (224.0.0/24)  Local Network Control Block

http://tools.ietf.org/html/rfc3171

routers are not allowed to forward that (you don't want to forward ospf
LSAs (224.0.0.5) between subnets either).

> I have read many articles but still haven't gotten it to work. I'm sure I'm 
> just missing 1-2
> commands. I also do not want to do this via DNS tricks as that is a pain in 
> the ass to admin.

but scalable... wide area bonjour is  not trickery, it is however a
service for which dynamic dns updates are well suited.

> I'd like to set it up once in one location(device) and be done with it..

put the devices on the same subnet.

> Here are the configs for the various interfaces/parts of Multicast routing.
> Any idea how to get this working. I'm pulling whats left of my hair out here 
> :-)

your multicast config looks like it would work albiet you're using pim
DM which is designed to flood everything (your goal I know).

> Spammy
> 
> ==
> protocols {
> igmp {
> interface vlan.666 {
> version 3;
> }
> interface vlan.1002 {
> version 3;
> }
> interface fxp0.0 {
> disable;
> }
> }
> pim {
> rp {
> local {
> address 10.0.0.2;
> }
> }
> interface vlan.666 {
> mode dense;
> }
> interface vlan.1002 {
> mode dense;
> }
> }
> }
> =
> Outputs
> =
> show pim interfaces
> 
> Instance: PIM.master
> Name   Stat Mode   IP V State NbrCnt JoinCnt(sg) JoinCnt(*g) 
> DR address
> ppd0.32769 Up   Sparse  4 2 P2P0   0
> 0
> vlan.1002  Up   Dense   4 2 DR 0   1
> 0 172.26.102.1
> vlan.666   Up   Dense   4 2 DR 0   8
> 0 10.0.0.1
> .
> show igmp interface
> 
> Interface: vlan.666
> Querier: 10.0.0.1
> State: Up Timeout:None Version:  3 Groups: 12
> Immediate leave: Off
> Promiscuous mode: Off
> Passive: Off
> Interface: vlan.1002
> Querier: 172.26.102.1
> State: Up Timeout:None Version:  3 Groups:  4
> Immediate leave: Off
> Promiscuous mode: Off
> Passive: Off
> Configured Parameters:
> IGMP Query Interval: 125.0
> IGMP Query Response Interval: 10.0
> IGMP Last Member Query Interval: 1.0
> IGMP Robustness Count: 2
> Derived Parameters:
> IGMP Membership Timeout: 260.0
> IGMP Other Querier Present Timeout: 255.0
> 
> show configuration interfaces vlan.666
> description "Network: Old 10.x Network";
> family inet {
> address 10.0.0.1/22;
> 
> show configuration interfaces vlan.1002
> description "Network: WLAN";
> family inet {
> address 172.26.102.1/24;
> ___
> 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] CPU in Routing Engines - MX

[Joel jaeggli]

On 5/12/12 03:32 , jo...@bjorklund.cn wrote:
> Hello,
> 
> Whats kind of CPU do Juniper use in RE-S-2000-4096 and RE-S-1800x2-8G ?

re2000 is a single core pentium-m

1800x2 is a more modern dual-core cpu


> /Jonas
> ___
> 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] Help Needed for Bonjour Routing/OSX Clients

[Joel jaeggli]

On 5/10/12 16:21 , Phil Mayers wrote:
> On 10/05/12 17:12, Jonathan Lassoff wrote:
>> On Thu, May 10, 2012 at 2:54 AM, Phil Mayers > > wrote:
>>
>> On 09/05/12 22:55, Jonathan Lassoff wrote:
>>
>> I've gotten this to work in the past, but it ended up being a
>> LOT more work
>> than just using DNS names and routing (which I've subsequently
>> done each
>> time).
>>
>>
>> Out of curiosity, how did this work? Isn't most mDNS traffic TTL=1?
>>
>>
>> I don't know about all the various implementations out there (of if the
>> standard says anything), but my modern-ish OSX box does 255:
> 
> Ok. Though I note that they're both link-local multicast groups, so
> again I wonder how people did them cross-subnet.

wide area bonjour is done like this:

http://www.dns-sd.org/ServerSetup.html
 ___
> 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] WAN-PHY support for EX-series 10g interfaces

[Joel jaeggli]

On 2/20/12 21:28 , Mark Tinka wrote:
> On Wednesday, February 15, 2012 08:21:15 PM Tim Jackson 
> wrote:
> 
>> LAN-PHY only on EX4200/4500 as far as i know.
> 
> I haven't yet quite found low-end Ethernet switches that do 
> anything more than LAN-PHY; but it's been a while since I 
> last did that check anyway.

I would doubt very much if the marvell asic would include a sonnet framer.

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

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

Re: [j-nsp] MX960 Redundant RE problem

[Joel jaeggli]

On 2/15/12 10:56 , Daniel Roesen wrote:
> On Wed, Feb 15, 2012 at 12:24:50PM -0500, Stefan Fouant wrote:
>> The cool thing is the Backup RE is actually listening to all the
>> control plane messages coming on fxp1 destined for the Master RE
>> and formulating it's own decisions, running its own Dijkstra,
>> BGP Path Selection, etc. This is a preferred approach as opposed
>> to simply mirroring routing state from the Primary to the Backup
>> is because it eliminates fate sharing where there may be a bug
>> on the Primary RE, we don't want to create a carbon copy of that
>> on the Backup.
> 
> I don't really buy that argument. Running the same code with the same
> algorithm against the same data usually leads to the same results.
> You'll get full bug redundancy - I'd expect RE crashing simultaneously.
> Did NSR protect from any of the recent BGP bugs?
> 
> The advantage I see are less impacting failovers in case of a) hardware
> failures of active RE, or b) data structure corruption happening on both
> REs [same code => same bugs], but eventually leading to a crash of the
> active RE sooner than on the backup RE, or c) race conditions being
> triggered sufficiently differently timing-wise so only active RE
> crashes.

when ISSU actually works it's a godsend.

> Am I missing something?
> 
> Best regards,
> Daniel
> 

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

Re: [j-nsp] What is an acceptable amount of latency for traffic routed through an SRX cluster?

[Joel jaeggli]

On 1/9/12 16:28 , Morgan McLean wrote:
> Yes, we are using it for security purposes. Why would I spend so much money
> on a box that is so limited in throughput due to its various fw inspection
> overhead?
> 
> I am running two 3600's that connect via 10GE to a couple core 8208 EX
> switches, which then multihome down to top of rack switches. The 3600's are
> using a reth group to manage which 10ge connection has the gateway
> addresses.
> 
> The firewalls are barely loaded, under 6,000 sessions with a very slow ramp
> rate. Not a whole lot of policies, not a whole lot of address book entries
> (under 100?), running some OSPF with less than 130 routes. This also
> happens between two zones for example that are any any.
> 
> The interface peaks at around a gigabit a second at anywhere from 75k to
> 100k pps. This box is in no way loaded. Personally I think the caching
> issues my boss mentioned are related to something else, and I think .5ms
> isn't so unreasonable, but I'm being pressed as to why its so much
> higher. The application is a replicating cache system based around
> memcached.

given that I've seen memcache replication occur over signficantly longer
distances I'd pretty much not identify latency the first order culprit.
repcached is asyncronous and it tends to ramp quite quickly if you've
got a big membase replicating into an empty bucket.

> I don't think any ALG could possibly be applied to this, but I'll double
> check.
> 
> Thanks,
> Morgan
> 
> On Mon, Jan 9, 2012 at 3:48 PM, Phil Mayers  wrote:
> 
>> On 01/09/2012 11:23 PM, Morgan McLean wrote:
>>
>>> Its an SRX3600 cluster, with no traffic traversing the fabric connection,
>>> so its all being contained on one chassis. These are just standard ICMP
>>> packets between two linux hosts on different subnets.
>>>
>>
>> I assume you are using these as a firewall, not just as a "convenient"
>> JunOS router?
>>
>> What is the security topology? How many policies and of what type do you
>> have? What's the background load in terms of bits/sec, packets/sec, session
>> ramp rate, etc.? What are the interface speeds?
>>
>> This is a complex question to answer in general. To give some comparative
>> data, we have Netscreen 5400s with M2 10G cards, hundreds of policies, tens
>> of thousands of address book entries, full BGP routing with ~1000 routing
>> entries, and session counts of ~20k sessions, ramp rate ~15k/minute.
>>
>> Through these firewalls, we incur an extra ~200usec on a ping round trip
>> time.
>>
>> So yes, I would say that going from 0.1msec (100usec) to 0.5msec (500usec)
>> is about the right order for a fast gig/ten gig firewall with moderately
>> complex config and load. Obviously the SRX 3600 and NS 5400 are different
>> beasts.
>>
>> Frankly, if your demands are such that you can't tolerate 400usec of
>> incurred latency, you possibly shouldn't be running it though a security
>> device. What kind of "caching application" is this?
>>
>> Are you sure the latency you're measuring with a ping is the same latency
>> your application is incurring? Are you sure an ALG isn't activating for
>> your traffic - perhaps try creating a policy to match the traffic and
>> explicitly disable the "application" / ALG.
>>
>> Cheers,
>> Phil
>>
>> __**_
>> 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] What is an acceptable amount of latency for traffic routed through an SRX cluster?

[Joel jaeggli]

srx covers at least three different hardware architectures...

An srx 5800 in a publicly available testing can do sub 300usec
forwarding on small packet workloads.

what srx we're talking about would probably set the expectation a bit
better.

joel


On 1/9/12 14:40 , Morgan McLean wrote:
> In our switch domain we have typically .1 ms of latency, however for
> traffic being routed through a gateway on the SRX to another vlan, the
> latency jumps up to about .5 or .6ms. Is this normal? Is this high? My boss
> is putting pressure on me because he says this added latency is stressing
> some caching applications we have.
> 
> Thanks,
> Morgan
> ___
> 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] Whitebox 10Gb/s capture challenge

[Joel jaeggli]

On 1/9/12 08:05 , OBrien, Will wrote:
> I'm pondering the idea of trying to build a relatively inexpensive 10Gb 
> capture box.
> The simple solution is a dell R710 with 10Gb nics. I have some, they work, 
> but I'd have to spend $50k to get enough of them.
> 
> So, my challenge is keeping the price point is something around $1000-$1500 - 
> basically the 10Gb version of a 1u gigE capture system.

Intel Ethernet X520-SR2 Server Adapter is ~$950, that's your dual port
10Gbe nic with optics if you do single port it's ~$800.

> In general, I probably don't need to ever write 10Gb/s to disk, but it would 
> be nice load the dice for success.
> My thoughts are a reasonable performance motherboard with 10Gb PCIe nics or a 
> white box mobo with onboard SFP+ ports.
> 
> Anyone gone this route?
> 
> 
> Will O'Brien
> University of Missouri, DoIT DNPS
> Network Systems Analyst - Redacted
> 
> obri...@missouri.edu
> 
> 
> 
> 
> ___
> 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 11.2R4.3 on MX

[Joel jaeggli]

On 12/21/11 12:20 , Brendan Mannella wrote:
> Just wondering if anyone has been brave enough to run Junos 11.2R4.3 yet on
> a MX960? We are currently on the latest 10.4, but would really like to
> upgrade to get “trunk style” config on Trio line cards. I also noticed
> during a previous ISSU that the Trio based line cards aren’t compatible yet
> with ISSU and had to be rebooted during a software upgrade. This feature is
> also available in 11.2.

We had several fixes that were available there and after labbing
11.2R4.3 for about a week we put it in production and so far we've been
doing ok...

Also issu did work from 11.2.r3.3 to r4.3

> 
> Our configuration is pretty basic, Layer2, BGP, OSPF, nothing fancy.
> 
> 
> 
> Any info would be appreciated.
> 
> 
> 
> Thanks,
> 
> 
> 
> Brendan
> ___
> 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 BGP issues causing locallized Internet Problems, (Mon, Nov 7th)?

[Joel jaeggli]

On 11/7/11 17:58 , Jared Mauch wrote:
> Juniper doesn't believe security bugs should be public. You must be a
> customer with support to access their portal.
> 
> Cisco has a good policy. You can view any security bugs and get fixes
> regardless of your contract status.

In either case there are a rather complex set of dependencies and
caveats associated with available releases, and the risk and timing of
an upgrade has to be balanced against operational needs, customer
scedures, feature requests and platforms involved.

If we rolled a new release everytime juniper sent us a notification or
found a pr for a bug we tripped over we'd be rolling probably twice a
month which is probably not sustainable. same applies to other vendors
we have in the mix.

> Jared Mauch
> 
> On Nov 7, 2011, at 6:53 PM, Jack Bates  wrote:
> 
>> More importantly, if it was the issue dated in August, how in the
>> heck do I get on a list which tells me such a critical bug exists?
>> 
>> 
>> Jack
>> 
>> On 11/7/2011 2:03 PM, Krembs, Jesse wrote:
>>> Has anyone else seen this issue?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 'Juniper BGP issues causing locallized Internet Problems, (Mon,
>>> Nov 7th) 
>>> 
>>> 
>>> via SANS Internet Storm Center, InfoCON:
>>> green   on 11/7/11
>>> 
>>> 
>>> We're starting to get reports (thanks to both Branson and Darryl)
>>> that a Juniper OS bug with BGP, combined with some specific BGP
>>> updates today, are resulting in some key internet routers being
>>> DOS'd due to high CPU loads. We'll post more data as it comes
>>> in.
>>> 
>>> === Rob VandenBrink Metafore (c) SANS Internet Storm
>>> Center. http://isc.sans.edu    Creative
>>> Commons Attribution-Noncommercial 3.0 United States License.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Jesse Krembs - Data Network Architecture&  Planning
>>> 
>>> FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT
>>> 05403 | jkre...@fairpoint.com
>>> 
>>> www.FairPoint.com  | 802.951.1519
>>> office | 802.735.4886 cell
>>> 
>>> 
>>> 
>>> 
>>> ___
>>>
>>>
>>>
>>> 
This e-mail message and its attachments are for the sole use of the
intended recipients.  They may contain confidential information, legally
privileged information or other information subject to legal
restrictions.  If you are not the intended recipient of this message,
please do not read, copy, use or disclose this message or its
attachments, notify the sender by replying to this message and delete or
destroy all copies of this message and attachments in all media.
>>> ___ 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] out of band management - real OOB

[Joel jaeggli]

Sorry, this is late,  as far as this thread goes but I think I'd add one
more thing since I've got oob networks big enough to have to add l3
boundries in them...

juniper's not the only vendor with this issue by far...

On 9/19/11 13:59 , Jonathan Lassoff wrote:
> On Mon, Sep 19, 2011 at 1:42 PM, Pavel Lunin  wrote:
> 
>> 2011/9/17 Chris Evans 
>>
>>> Juniper devices have out of band ethernet ports, but have the HUGE HUGE
>>> downfall of being in the main routing table conflicting with every other
>>> route.
>>>
>>
>>
>> BTW, can anyone give a good real-world example of a _routed_ OOB management
>> network usage?
>>
>> As far as I understand the whole concept of OOB MGT IP interface was
>> invented to make the management network totally isolated from any transit
>> traffic. For security concerns, at the days when firewalls were not trusty
>> enough, when lack of Internet connection was not that big issue. If you
>> really need to implement this, you won't run into any routing conflict,
>> since it's a really separated network, will you?
>>
>> But. Nowadays not really many folks run separate PCs for OOB MGT totally
>> apart of their LAN, corporate environment, email, Internet, etc. Even
>> though
>> some conservators may still desire this sort of design, most NMS need an
>> Internet connection to update something. In this case — yes, you bump into
>> a
>> routing conflict using fxp0, but why to use fxp0 in such a scenario?

So, I have a routed oob, and proxy-arp is your friend. the netmask on
the management interface needs to be big enough to cover your whole oob
network... organizing your addresses space such that this is feasible is
left as an exercise for the reader.

>> An only exception I know of (looks like a real design flaw by Juniper) is
>> the SRX cluster case, where you MUST use fxp0 interfaces, if you want to
>> have access to particular members of a cluster. Otherwise you can only
>> access a virtual devise as a whole, with no clue which particular node you
>> connect to. Not so big problem in real world, to be honest, but if you are
>> required to connect it to, say, NSM, which goes to the Internet through
>> this
>> same SRX cluster, you got a real pain in the rear (workarounds exist, of
>> course).
>>
>> Sure, there are some good applications of fxp0 in field, but this does not
>> much relate to real routing issues.
>>
> 
> I see two ways one can go about this. Either programmatically tunnel into an
> OOB L2 segment via a "bastion" host in an on-demand fashion, or point some
> routes (dynamically, or otherwise) into your internal network for management
> use.
> 
> The risk of pointing routes into your internal network, IMO, is that
> very-specific ACLs for management access can begin to have a blurred
> distinction. RFC-1918 space can overlap, and public IPs within an internal
> network can sometimes overlap with an active transit path.
> 
> It's more work to script things to work nicely, but I believe the dynamic
> tunneling method is the safer thing to do.
> In the spirit of Junipers clean separation of the data and forwarding
> planes, it seems too bad that they end up using the kernel routing table to
> hold what goes in the forwarding hardware as well.
> 
> If you have the blessing of being able to have an all-J network, or one with
> devices that all support multiple routing tables and routing protocol
> separation (a la logical systems, or routing instance) -- setting up
> separate routing tables for management vs. traffic-carrying is probably a
> good thing.
> 
> --j
> 
>> ___
>> 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] Unfamiliar with Juniper M10 Config Files

[Joel jaeggli]

the show bgp neighbor (neighborip)

on the juniper will tell you how many it's sending. e.g. an example
session...

Active prefixes:  64903
Received prefixes:374540
Accepted prefixes:374538
Suppressed due to damping:0
Advertised prefixes:  3

On 10/21/11 09:15 , Loopback EZ wrote:
> I am replacing an old Cisco router with a Brocade MLX as IBGP peer to a
> Juniper M10.  I am only getting 250K routes and I have NO filtering
> enabled.  I know that the Juniper is receiving a full EBGP route table
> but is only passing 250K to any of its internal IBGP peers including the
> old Cisco.  Suspect that there is route summarization happening so it
> would not overrun an old Cisco SUP module.  Where should I look for
> summarization or any other possible cause in the Juniper config?
> 
> 
> ___
> 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] TCAM full on EX8200?

[Joel jaeggli]

On 10/14/11 03:08 , Phil Mayers wrote:
> On 13/10/11 20:21, Richard A Steenbergen wrote:
> 
>> EX8200 uses SRAM for forwarding lookups, and TCAM for firewall
>> filtering. SRAM is perfectly capable of doing lookups at these speeds,
>> and infact is a lot more flexible than TCAM, whereas TCAM is actually
>> much better suited for doing high speed packet filtering.
> 
> On that topic; I'm familiar with how TCAM can be used to accelerate
> routing lookups, but less so with SRAM. Is the SRAM used to implement a
> "simple" lookup table/tree, or does SRAM have some special properties
> that enable it to do fast routing lookups?

Tree based longest match...

one such discussion (by a vendor that uses tcam for the most part)

http://www.nanog.org/meetings/nanog39/presentations/fib-hankins.pdf

and it's not just sram of course RL-DRAM2 is also used (by for example
the MX)

> Just curious, if anyone has any pointers to how SRAM is actually used
> ___
> 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] TCAM full on EX8200?

[Joel jaeggli]

On 10/13/11 12:21 , Richard A Steenbergen wrote:
> On Thu, Oct 13, 2011 at 02:19:40PM +0200, Michele Bergonzoni wrote:
>> Il 13/10/2011 13.31, Chen Jiang ha scritto:
>>> AFAIK, The EX8200 use SRAM for FIB and TCAM for ACL, that's not like
>>> EX2200/3200/4200 that use TCAM for all FIB and ACL.
>>
>>> You could vty to line card and try this knob and see what happened:
>>> PFEM2(vty)# show shim route lpm-dmm-stats
>>
>> Not sure to understand how something can switch data at that speed using 
>> SRAM as a FIB, but it's consistent with my TCAM appearing almost empty.

sram or rl-dram works just fine as fib, and it has way lower power
requirements in general.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Pulse Client Mobile Devices with SRX ?

[Joel jaeggli]

On 9/27/11 18:58 , Jonathan Lassoff wrote:
> On Tue, Sep 27, 2011 at 6:20 AM, Chris Gapske  
> wrote:
>> Sorry Very new at this but I would like to ask for help on an issue.
>>
>> I am getting conflicting stories on the ability of the SRX.  TAC says they 
>> cannot get Mobile  Devices such as Android or Idevices to connect with the 
>> pulse client.
>> However I have heard reports of people getting there Android devices to work 
>> can anybody confirm this ?
>>
>> Thank you .. I am pretty new at the SRX thank you.
> 
> Apparently it is possible to do on some SRX platforms. I've only had
> success in terminating mobile clients against the "Secure Access"
> (SA-series) devices running IVE/SSL VPN software.
> 
> I found this KB article on doing it. It utilizes the "Dynamic VPN"
> feature. http://kb.juniper.net/InfoCenter/index?page=content&id=KB17641
> 
> Beware the Android client though -- as of several months ago, it only
> provided a wrapped web browser, rather than real IP tunneling. The iOS
> Pulse client does proper tunneling though.

2.1 which has been around for a while does support ip tunneling but only
on devices where the end user has root access, which either means you
have developer phones or they've been hacked.

> Good luck.
> 
> Cheers,
> jof
> 
> ___
> 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] full table?

[Joel jaeggli]

On 9/20/11 10:26 , Keegan Holley wrote:
> Is it always necessary to take in a full table?  Why or why not?  In light
> of the Saudi Telekom fiasco I'm curious what others thing.  This question is
> understandably subjective.  We have datacenters with no more than three
> upstreams.  We would obviously have to have a few copies of the table for
> customers that want to receive it from us, but I'm curious if it is still
> necessary to have a full table advertised from every peering.  Several ISP's
> will allow you to filter everything longer than say /20 and then receive a
> default.  Just curious what others think and if anyone is doing this.

given the large number of people who have a default as a backup (which
can be empirically measured) there are plenty of things you can do to
avoid taking a full table, with relatively minor impact.

> ___
> 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] out of band management - real OOB

[Joel jaeggli]

On 9/19/11 14:04 , Chris Morrow wrote:
> 
> 
> On 09/19/11 16:59, Jonathan Lassoff wrote:
>>>  BTW, can anyone give a good real-world example of a_routed_  OOB
>>> management
>>>  network usage?

yeah, I I find that oob networks larger than a /21 are sort of hard to
manage therefore we  split them up into l3 segments.

>>>  As far as I understand the whole concept of OOB MGT IP interface was
>>>  invented to make the management network totally isolated from any
>>> transit
>>>  traffic.

It is.

>>> For security concerns, at the days when firewalls were not
>>> trusty
>>>  enough, 

They still aren't.

when lack of Internet connection was not that big issue.

It isn't.

 If you
>>>  really need to implement this, you won't run into any routing conflict,
>>>  since it's a really separated network, will you?
>>>

Ships in the night may still pass in some cases.

> how about like management networks on ss7 deployments?
> 
> It's really not that hard to conceive of a 'management card' on a
> network device that can twiddle all of the network device's parts and
> maintains a separate routing world from the production side of the
> hardware.
> 
> Hell, you could even envision something like this in the world of
> servers: ilom (sun), drac (dell), hp-whatever-the-hell...
> 
> -chris
> 
> in 2011, we CAN have more than routing table on a single device, yes?
> ___
> 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] Using MX router with JunOS Script to DDos detection and Mitigation

[Joel jaeggli]

Managements of stats (and therefore event correlation) is generally some
not done on the router itself... So netflow gets exported someplace
else, e.g. to a machine running flowtools, nfsen, arbor peakflow etc,
the data is massaged into some meaningfull state and then decisions are
made as to what to do with that information. those decisions may
signaled back to the router using bgp or openflow.

joel

On 8/30/11 17:28 , Ernest Lau wrote:
> Hello,
> 
> Are there any JunOS scripts that can we can use with MX Router to detect
> DDos and then apply actions to those flows based on configuration?  We
> particularly interested in flows through the router and not flows to the RE
> itself.
> 
> Thanks,
> 
> Ernest
> ___
> 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] How can change the OSPF backbone area number other 0?

[Joel jaeggli]

On 9/12/11 01:19 , medrees wrote:
> Dear Experts
> 
>  
> 
>   I'm confusing why all vendors chooses OSPF backbone area to be
> area 0 

rfc 2328

  3.1.  The backbone of the Autonomous System

The OSPF backbone is the special OSPF Area 0 (often written as
Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP
addresses). The OSPF backbone always contains all area border
routers. The backbone is responsible for distributing routing
information between non-backbone areas. The backbone must be
contiguous. However, it need not be physically contiguous;
backbone connectivity can be established/maintained through the
configuration of virtual links.

Virtual links can be configured between any two backbone routers
that have an interface to a common non-backbone area.  Virtual
links belong to the backbone.  The protocol treats two routers
joined by a virtual link as if they were connected by an
unnumbered point-to-point backbone network.  On the graph of the
backbone, two such routers are joined by arcs whose costs are
the intra-area distances between the two routers.  The routing
protocol traffic that flows along the virtual link uses intra-
area routing only.

and I'm asking if there is method to change this number to any other
> to be configured in all routers within the network?

maybe I'm missing the question but not all routers in a network need to
be members of area 0.

if you're attempting to segment the backbone into smaller sections you
should probably consider is-is.

>  
> 
>  
> 
> Thanks,
> 
> Best Regards,
> 
> Mohamed Edrees
> 
> ___
> 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 RE how fast is slow

[Joel jaeggli]

userspace has to be recompiled for ppc.

freebsd ppc tree has parity with x86 more or less.  e.g. this is just
another processor architecture.

the relative performance of a freescale cpu vs say re-2000 is a
consideration, just like you'd expect re-4x1800 to be faster than re-2000

joel

On 9/8/11 10:52 , Abhi wrote:
> Hi saku 
> 
> Not to sure but I understand that ppc support would be part of free bsd 
> kernel so would that require change to the process running on the top of 
> them; if yes what kind of changes these would be?
> 
> 
> Sent from Yahoo! Mail on Android
> 
> ___
> 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 EX8208 - Redundant RE Option

[Joel jaeggli]

disclaimer, I'm on the buying end not the selling end.

there's one license per RE, so two.

recall that you're in HA mode (probably) so the features will be enabled
on both RE at the same. That said I don't recall it failing when
unlicensed (not that I recommend running that way) and your milage may vary.


On 8/29/11 19:45 , GIULIANO (WZTECH) wrote:
> People,
> 
> Does anyone knows about how much advances licenses are necessary for a
> EX8208 chassis
> configured with 2 Routing Engines ?
> 
> EX8208-AFL EX8208 Advanced Feature License
> 
> It will be necessary 1 or 2 licenses ?
> 
> Theses licenses are available for chassis or for RE ?
> 
> If we use OSPFv3 ... considering 1 single licenses ... if the main RE
> fails ... the backup RE will stop doing OSPFv3 because lack of license ?
> 
> Does anyone have experienced this before ?
> 
> Thanks a lot,
> 
> Giuliano
> ___
> 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 Questions

[Joel jaeggli]

On 8/27/11 05:48 , Julien Goodwin wrote:
> On 27/08/11 22:13, Saku Ytti wrote:
>> Hardwarewise scaling is same as any MPC in larger MX, but control-plane is 
>> lot
>> less beefy than big brothers. Not really sure why, it's not like intel CPU
>> would be significant BOM addition to MX80 compared to freescale.
>> downscaling trio would have been expensive, lot cheaper to reduce
>> the scale of the box is to fit it with poorer RE with less 
>> memory
> 
> OK that's not really fair. Even a trivial embedded Intel x86 (and most
> usably performing clones) are a *lot* more complex then PowerPC can be
> (which is still worse then the single-chip ARM systems now available).
> In dollar terms after everything's added in it should have worked though.

this is the lspci output from an arista ethernet switch, the
control-plane processor is basically an amd laptop sourced from
components on the imbedded roadmap. while not an apples to apples
comparision  device wise (trio is a lot more functional than the
broadcom) it's a passable example of embedded x86 control plane in a 1u
l3 ethernet switch.

[jjaeggli@a5-8a-z1 ~]$ lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
Alternate
00:01.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(int gfx)
00:04.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(PCIE port 0)
00:08.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(NB-SB link)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(PCIE port 4)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(PCIE port 5)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA
Controller [IDE mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 42)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
(rev 40)
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
00:14.6 Ethernet controller: Broadcom Corporation NetLink BCM5785
Gigabit Ethernet (rev 01)
00:16.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:16.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Link Control
01:05.0 VGA compatible controller: ATI Technologies Inc Device 9712
02:00.0 Ethernet controller: Broadcom Corporation Device b846 (rev 02)
04:00.0 System peripheral: Arastra Inc. Device 0001 (rev 0a)
[jjaeggli@a5-8a-z1 ~]$
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 42)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
(rev 40)
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
00:14.6 Ethernet controller: Broadcom Corporation NetLink BCM5785
Gigabit Ethernet (rev 01)
00:16.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:16.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron,
Athlon64, Sempron] Link Control
01:05.0 VGA compatible controller: ATI Technologies Inc Device 9712
02:00.0 Ethernet controller: Broadcom Corporation Device b846 (rev 02)
04:00.0 System peripheral: Arastra Inc. Device 0001 (rev 0a)
[jjaeggli@a5-8a-z1 ~]$
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(PCIE port 5)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA
Controller [IDE mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0
Controller
00:12.2 USB 

Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines

[Joel jaeggli]

On 8/25/11 17:56 , Jonas Frey (Probe Networks) wrote:
> Thats not completely accurate, for example the Intel Atom D525 does run
> 64bit code.

there are a number of atoms the support 64bit, I think that the
observation I was making was that there are atoms that don't support
PAE, by virtue of not supporting 4 or more GB of ram.

>
>> There are plenty of machines that do. virtually every intel system since
>> the pentium pro  (except the atom) has the hardware if not the bios
>> support for doing so, that's not germain to the question of whether it's
>> feasible/useful in an embedded system. In particular, in a system (like
>> for example a firewall) where kernel datastructures may represent the
>> overwhelming source of memory utilization, the  PAE performance hit may
>> trivially overwhelm the value of any memory that can otherwise be freed
>> up for userspace.
>>
>> 64bitness has been the prefered approach for intel based servers since
>> about 2003, but the embedded lifecycle runs on it's own timeline.

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

Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines

[Joel jaeggli]

On 8/24/11 06:25 , Keegan Holley wrote:
>
> Sent from my iPhone
>
> On Aug 24, 2011, at 9:13 AM, Chris Adams  wrote:
>
>> Once upon a time, Keegan Holley  said:
>>> Interestingly enough my SE told us this is possible at lease on our Mx480 
>>> and MX960 boxes. Our lab boxes are otherwise engaged at the moment so we 
>>> havent tested. One note regarding general computing though.  The processor 
>>> can only address 4G (3.8 or so actually) of ram with a 32 bit word size.  
>>> So even if you get the re's running the 32 bit code they will only register 
>>> 4G of the precious 16G.
>> Well, that isn't entirely true.  Intel added the Physical Address
>> Extension to the Pentium Pro many years ago (and virtually everything
>> claiming to be i686 compatible has PAE).  PAE allows the OS kernel to
>> address up to 36 bits of RAM (64G), just not all at once.
> I've never heard of this actually being used though.  Maybe I'm wrong though. 
>  Most people just modified their code to support 64 bit and stopped there. I 
> also haven't seen any boards RE's or regular Mobo's with 32 bit procs and 
> support for more that the 4G of RAM.

There are plenty of machines that do. virtually every intel system since
the pentium pro  (except the atom) has the hardware if not the bios
support for doing so, that's not germain to the question of whether it's
feasible/useful in an embedded system. In particular, in a system (like
for example a firewall) where kernel datastructures may represent the
overwhelming source of memory utilization, the  PAE performance hit may
trivially overwhelm the value of any memory that can otherwise be freed
up for userspace.

64bitness has been the prefered approach for intel based servers since
about 2003, but the embedded lifecycle runs on it's own timeline.
>>  In general, a
>> given program can still only see 32 bits, unless it does special bank
>> switching.
>>
>> I don't know about PAE support on FreeBSD or JUNOS, but it does exist in
>> all x86 Juniper hardware.
> Interesting.
>
>> -- 
>> Chris Adams 
>> Systems and Network Administrator - HiWAAY Internet Services
>> I don't speak for anybody but myself - that's enough trouble.
>> ___
>> 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