Hi Ben,
Thanx!
We'll play with it :)
Maarten
-Oorspronkelijk bericht-
Van: Ben Dale [mailto:bd...@comlinx.com.au]
Verzonden: dinsdag 24 september 2013 9:16
Aan: Maarten van der Hoek
CC: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] SRX Command
Just blew the dust off it and it stil
On (2013-09-25 08:29 +1000), Luca Salvatore wrote:
> This concerns me a little. I'M about to take a full table on a MX5.
> Is it only an issue when the adjacencyis lost and we need to receive the
> table again or will performance of the entire box be affected?
For what it's worth we're running
Please do share...
We are looking at launching an MX480 with RE1800's for BNG functions
(PPPOE). I'd really like to haul L2VPN's directly to the box and this
feature in 13.2 mentioned may be the solution...;)
Paul
On 2013-09-24 6:27 PM, "Graham Brown" wrote:
>I've run into a very strange bug
Harri,
As per the link below - add "then count" to all your policies (using the
following apply-group will do this quickly for you):
set groups COUNT-ALL security policies from-zone <*> to-zone <*> policy <*>
then count
set apply-groups COUNT-ALL
If you install the op-script provided and run i
I've run into a very strange bug on the MX where PPP through a VPLS results
in the packets being mangled - affected circuits have been migrated to
L2VPNs. Although a fix is provided in 12.3R4 which we are currently testing
- I'll dig out the PR when I get into the office.
Graham Brown
Network Engi
This concerns me a little. I'M about to take a full table on a MX5.
Is it only an issue when the adjacencyis lost and we need to receive the
table again or will performance of the entire box be affected?
--
Luca
On 25/09/13 12:18 AM, "Nitzan Tzelniker"
wrote:
>Hi,
>
>The problem with the
On Tuesday, September 24, 2013 04:50:41 PM Paul Stewart
wrote:
> Not to hi-jack this thread but does anyone know
> *real-world* numbers yet on the MX104 RE? I know it has
> more memory and is supposed to be "faster" but have no
> idea yet how much faster it really is?
>
> We don't have any in o
To add on Nitzan's comment(we work together):
When everything is stable all is good.
But bounce a full table BGP session, and than bounce an IGP adjacency and you
are in a lot of trouble.
This seems to be a combination of the (in)famous Junos software issue described
extensively by RAS and a proc
Hi
I s there a
way with Junos to manipolate OSPF metric to mark as unreachable a network
received
through a particular path ?
I was told
that with Screenos was possible, but I’m wondering if it is true or not ?
Any
experience ? feedback ?
Regards
Not to hi-jack this thread but does anyone know *real-world* numbers yet
on the MX104 RE? I know it has more memory and is supposed to be "faster"
but have no idea yet how much faster it really is?
We don't have any in our network yet but anxious to deploy one end of
year...
Thanks for any input
We are aware ppc on mx80 is slower than intel REs... but the original
question was for scalability not for performance/convergence.
Take a look at newer MX104 for more RE performance.
Krasi
On 24 September 2013 17:18, Nitzan Tzelniker wrote:
> Hi,
>
> The problem with the MX80 is not the FIB si
Hi,
The problem with the MX80 is not the FIB size but the slow RE
The time it take to receive full routing table is long and to put it into
the FIB is even worst
Nitzan
On Tue, Sep 24, 2013 at 10:21 AM, Krasimir Avramski wrote:
> Agree.. other elements like counters, filters, descriptors etc .
Thanks for lookup
We have JUNOS Software Release [10.4R5.5] and it doesn`t look like that we have
the option indictaed in last mail
admin@SRX-3600-P> show security policies ?
Possible completions:
<[Enter]> Execute this command
detail Show the detailed information
On Wednesday, September 18, 2013 06:13:06 PM rkramer wrote:
> I currently use MX240's throughout my routing environment
> today, and I'm looking to upgrade my existing NAT boxes,
> which are Cisco ASR's. They are running out of
> horsepower, and from what I'm seeing, MS-DPC's on MX's
> provide mo
On Tuesday, September 17, 2013 04:05:50 PM Adrien Desportes
wrote:
> Hello William,
>
> Before 13.2 you would have to use an external loop to
> terminate the vpls on one side and the ppp on the other
> side (as lt- interface does not support the proper
> encapsulation for ppp).
>
> Starting 13.
Hi Ben,
Did you succeed in building that script ?
(e.g. do you have it somewhere ? ;-) )
We've been playing with exports and then import in Excel...but still not
very nice..
A better solution would be nice.
(we can't you Junos-Space / or so because most deployments are in separate
Small / Branch
Agree.. other elements like counters, filters, descriptors etc .. but it is
dynamic allocation which isn't the case with ichip - 16M bank for
firewalls , 16M for jtree with fixed regions. Although there is a
workaround(
http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/jun
Hi,
Keep in mind that SRX and MX/MPC use different command hierarchy for the load
balancing hash config, which means your lab will not be useful.
SRX (and MX/DPC) use "hash-key"
MX/MPC use "enhanced-hash-key"
The hash is used on the ingress card of the MX (which might not be the card
connected
Just blew the dust off it and it still works ; )
http://pastebin.com/xiszACPf
If you're applying this to a chassis cluster, you may need to replace the line:
for-each ($policies-list/security-context/policies) {
with
for-each ($policies-list/multi-routing-engine-item/security-context/policies
19 matches
Mail list logo
