>
> # show
> term term1-match {
> from {
> destination-address {
> 131.0.245.143/32;
> }
> packet-length 32-63;
> protocol 6;
> source-port 443;
> tcp-flags "syn & ack & !fin & !rst & !psh";
> }
> then {
> co
I don't see this behavior in 20.X trains, so possibly something introduced
in 21.
That being said, I think that concerns about SSD's dying because of write
volume is pretty over dramatic. The volume of logs written for everything
else is certainly much higher than this.
Worth opening a case on fo
>
> If you have Cisco HTTS or Juniper ACP or the like, where you get named
> engineers, then you can develop a mutual trust and give those
> engineers access to your network.
>
To each their own, but I'm with Jared on this. No way would a vendor have
any direct access. The most permissive I'd acce
>
> I also find that BFD can cause more problems than it fixes if you go too
> aggressive with it !
>
Concur here. BFD has its uses in specific circumstances, but it's almost
always much better to rely on interface state change and hold-time up FOO.
On Sat, Apr 27, 2024 at 6:34 AM Sean Clarke vi
>
> but a BGP-LU solution exists even for this problem.
>
My first thought was also to use BGP-LU.
On Wed, Apr 3, 2024 at 2:58 AM Saku Ytti via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> On Wed, 3 Apr 2024 at 09:45, Saku Ytti wrote:
>
> > Actually I think I'm confused. I think it will
I've read this a couple times. Also confused, but I think this is what you
are saying :
- You have a /19 aggregate that is announced via BGP to upstreams.
- You use an upstream RTBH service that will sink a particular destination
via a BGP announcement to a particular peer.
- When you add a /32 di
hough I haven't had reason or cycles to really ride it hard and see
where I can break it yet. :) )
On Fri, Feb 9, 2024 at 3:51 AM Saku Ytti wrote:
> On Thu, 8 Feb 2024 at 17:11, Tom Beecher via juniper-nsp
> wrote:
>
> > For any use cases that you want protocol interacti
will catch you on Juniper's metal ,
or your own metal for vMX, or cRPD ( assuming said bug is not hardware
dependent/related ).
On Thu, Feb 8, 2024 at 10:21 AM Mark Tinka wrote:
>
>
> On 2/8/24 17:10, Tom Beecher wrote:
>
> >
> > For any use cases that you want protocol
>
> I wouldn't consider cRPD for production. vRR (or vMX, if it's still a
> thing) seems to make more sense.
>
For any use cases that you want protocol interaction, but not substantive
traffic forwarding capabilities , cRPD is by far the better option.
It can handle around 1M total RIB/FIB using
>
> I am aware of a few major orders of the ACX7024 that Juniper are working
> on. Of course, none of it will become materially evidential until the
> end of 2024. That said, I think HP will give the box a chance, as there
> is a market for it. They might just put a time line on it.
>
I doubt this
>
> HPE will turn Juniper just like they turn 3com.
>
3Com's death started almost a decade before HP acquired them. They were
pretty much dead by the time that happened,
On Wed, Jan 10, 2024 at 2:38 PM Alexandre Figueira Guimaraes via
juniper-nsp wrote:
> HPE will turn Juniper just like they
>
> In our hubris to "decouple the control plane from the data plane (tm)",
> we, instead, decoupled the software/hardware integration from a single
> vendor.
>
I wouldn't necessarily agree that was the wrong *technical* decision.
Unfortunately, it was a perfect scenario to be exploited for the
MB
>
> Is there a difference between "MX204" and "MX204-HW-BASE"?
>
Strictly speaking they are just different SKUs, not different models.
MX204 : Chassis + Fan trays + PEMs
MX204-HW-BASE : Base MX204 chassis PLUS perpetual Junos software license
AFAIK , code that has enforcement is limited to speci
This is correct, they exist for the bypass LSPs.
I wouldn't characterize it as a dirty hack though. RFC4090 fast reroute
requires the backup pathways to be pre-computed for a sub-10ms switchover.
You put an export policy in place to make sure all labels (including
bypass) are in the FIB already. O
>
> Did I mention Arista is not spending valuable engineer time on all this
> license shit, but on actually making great products?
>
Oh they aren't?
https://www.arista.com/en/support/product-documentation/eos-feature-licensing
Arista will almost certainly move towards a licensing model similar t
MX304's.
>
> -Aaron
>
> On 10/24/2023 4:18 AM, Karl Gerhard via juniper-nsp wrote:
> > On 18/10/2023 18:55, Tom Beecher via juniper-nsp wrote:
> >> Juniper licensing is honor based. Won't impact functionality, will
> >> just grump at you on commits.
>
&g
Juniper licensing is honor based. Won't impact functionality, will
just grump at you on commits.
On Wed, Oct 18, 2023 at 10:32 AM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
>
> On 10/18/23 15:47, Aaron1 via juniper-nsp wrote:
>
> > Also, I get a license warning when commit
>
> Which in theory opens a new attack vector for the future.
>
What is the attack vector you foresee for a route sitting as hidden with
the potentially offending attributes stripped off?
On Thu, Aug 31, 2023 at 4:27 AM Tobias Heister via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi,
>
This PR may be worth asking about.
https://prsearch.juniper.net/problemreport/PR1693424
On Sat, Sep 2, 2023 at 7:08 PM Gonzalo Caceres via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi everyone,
>
> I have multicast traffic through a P2MP LSP and when this traffic goes
> through an EX
easonable to set the timeout to say 300 seconds
so there was less down time if it went wrong.
Thanks,
--
Tom
:: www.portfast.co.uk / @portfast
:: hosted services, domains, virtual machines, consultancy
___
juniper-nsp mailing list juniper-nsp@puck
We have A+B power delivered 3 phase to the racks, broken out on PDUs, but I
think I must have been thinking about another platform in regards to not
splitting PSUs across phases.
Thanks!
On Thu, 23 Mar 2023, 09:15 Mark Tinka via juniper-nsp, <
juniper-nsp@puck.nether.net> wrote:
>
>
> On 3/23/23
Hi all.
I had this idea in my head that MX960 power supplies should not be split
across phases, but I cant find anything in any documentation that says that.
Can anyone comment on whether multiple phases per PEM are supported, or
whether its even a reasonable idea to put into practice?
My though
What this is saying:
If you have a GROUP level policy, and make any MODIFICATIONS to INDIVIDUAL
neighbor policies, that individual neighbor will reset.
This means adding OR removing the peer level policy will trigger the reset.
As I recall, it is because there is normally a single BGP Update IO
Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.
On Wed, Aug 19, 2020 at 10:47 AM Co
This is the most recent Juniper document I had bookmarked for the QFX.
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protocols-edit-ddos-qfx-series.html
I agree with Saku that the ddos-policer is a good tool to use, but as he
said it requires turning f
Likely, but if you only need like 4 :)
On Wed, Mar 4, 2020 at 10:01 AM Mark Tinka wrote:
>
> On 4/Mar/20 16:53, Giuliano C. Medalha wrote:
>
> With the new MPC10 you can get 10 x 100G or 15 x 100G per slot in mx240 ,
> mx480 or mx960
>
> But you will need premium 3 chassis with scbe3 boards
You can still get 100G ports on the 960 chassis with MPC5E/6/7s , depending
on what kind of density you require.
On Wed, Mar 4, 2020 at 9:42 AM Mark Tinka wrote:
>
>
> On 4/Mar/20 16:36, Tom Beecher wrote:
> > It really depends on what you're going to be doing,but I still ha
It really depends on what you're going to be doing,but I still have quite a
few MX960s out there running pretty significant workloads without issues.
I would suspect you hit the limits of the MS-MPCs way before the limits of
the chassis.
On Wed, Mar 4, 2020 at 6:56 AM Ibariouen Khalid wrote:
>
I'm trying to set up a config very similar to the one described here:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB28198
which is basically: route-based VPN between SRX and ASA with multiple subnets
behind SRX and single subnet behind ASA.
Difference in my situation is I need to se
>> And regarding PRs delta between your present release and 17.4R2-S2 release
>> , JTAC is not authorised to provide that info. I suggest you to reach out
>> to juniper accounts team who can help you on this
>
> Why? I have no idea, maybe this engineer was just lazy but I’ve had the same
> fr
This was, and still is, the most accurate answer in the thread. To expand
on it further
Cisco IOS images are standalone binary images. Each time the device is
powered on, it loads the image it is configured too, and executes it. The
entire operating system is encapsulated in this image file, a
n Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
> >> These don't work on the 204?
> >>
> >> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> >> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
> >
> > They don'
These don't work on the 204?
Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
On Thu, Feb 28, 2019 at 2:51 PM Tarko Tikan wrote:
> hey,
>
> > i just found out that it seems not to be possible to poll Yellow/Red
> Alarm (Count or
So I missed your specific comment about being concerned about the bypass
LSPs.
I think (although I haven't tested this in forever) if you enable
no-node-protection under RSVP , that will prevent those interfaces from
being available for any node or link bypass LSP to use.
On Fri, Jan 25, 2019 at
Best option would be the coloring scheme along with explicit excludes in
the config for the LSPs you dont want to go through said device.
On Thu, Jan 24, 2019 at 3:25 PM Luis Balbinot wrote:
> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll giv
I feel like I hit this once and had to use a rib-group.
But it would probably be helpful to see the relevant configs in full.
On Wed, Dec 19, 2018 at 10:52 PM Anderson, Charles R wrote:
> On Wed, Dec 19, 2018 at 03:41:40PM -0800, Chris Cappuccio wrote:
> > Nathan Ward [nw...@daork.net] wrote:
>
tructing an argument about why we need to remember one
esoteric bit of knowledge about the config on that platform we haven't had
in use since the early Obama administration.
On Wed, Dec 19, 2018 at 6:11 PM Niall Donaghy
wrote:
> @Tom: Oh sure, hardlinks are rife and a HTTP 301 might be a
Lots of people (for better or for worse) may have hard linked / referenced
KB15585 in their documentation, so IMO it's a good idea to leave it up with
a bolded note of depreciation, which is what they did.
Expecting a bit of RTFM on the end user isn't that much, IMO.
On Wed, Dec 19, 2018 at 12:37
ct 12, 2018, at 9:07 AM, Niall Donaghy
> wrote:
> >
> > Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
> > traffic and found, 1) they don't count, and 2) IPv6 is unsupported for
> dsc.
>
> That's what I needed to know! Back to standa
I’m pretty sure we drilled Juniper about the IPv6 discard interface thing a
few months ago and got a feature request in for that. One of our guys
wasted about 2 weeks on that.
On Fri, Oct 12, 2018 at 09:07 Niall Donaghy wrote:
> Hi Jason,
>
> Yes we (large ISP) tried using dsc interfaces (MX ser
Related, my company open sourced a tool we've been working on for network
telemetry at NANOG in Vancouver. I'm 95% sure that a JTI receiver is
functional on our internal builds, but they're still working on a few
things with streaming receivers generally, so it's not yet in the public
repo. May be
You have switches with completely different buffer depths than you used to.
You prob want to look into that.
On Tue, Oct 2, 2018 at 9:39 AM james list wrote:
> Dear experts
>
> I’ve a strange issue.
>
> Our customer replaced two L2/3 switches (C6500) where a pure L2 and L3
> (hsrp) environment w
There's no one magic knob that fixes CPU spikes in an MPLS environment.
They're all different. What I change to optimize mine might knock your
network over in 5 minutes. You need to determine what is triggering the
churn before you can reasonable optimize it. Take a look at logs and see
what is cau
Hi Balasankar,
I dont have the same issue when I configure in the foreground.
I am running software version 15.1X49-D120.3 if that helps.
Ive been informed that we have support on this gear, so I will raise a case
via JTAC too.
Thanks!
Tom
On Mon, 27 Aug 2018 at 08:28, Balasankar Rajaguru
Hi everyone. I am trying to build some configuration groups with the
intention of keeping related configuration for some IPSEC VPNs etc nicely
contained in one spot - define all relevant configuration in a group and
apply it in one go, and also remove it *all* when you delete and remove the
configu
In my view, the benefits of keeping them separate far outweigh the
additional effort of creating and managing the additional groups.
On Fri, Jun 29, 2018 at 11:01 AM, Rob Foehl wrote:
> Wondering aloud a bit... I've seen plenty of cases where wedging parallel
> v4/v6 sessions into the same BGP
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
Thinking out loud.
Wouldnt that assume that you always access your REs inband, therefore
only ever connecting to the master? What if you access them out of
band via their ethernet ports. Each RE then needs its own unique key?
I mean, in theory they probably dont (is there anything to stop
multipl
On 13 January 2016 at 22:32, Mark Tinka wrote:
> A more current RE means you can run more recent Junos releases. I
> haven't run the RE-S-2000 in a while, so not sure how well it's
> supported by current Junos releases (someone else who has the older RE's
> might want to chime in).
Guess it depen
Ive been through this myself. The short of it is that you will need a
VPLS instance for each VLAN you wish to carry on SRX.
I dont remember the exact details, but the MX do some "magic" to
automatically carry multiple VLANs through a single VPLS instance,
whereas the SRX do not.
Try as you might,
According to libslax documentation, which is also the base of Junipers
implementation, the version statement indicates the minimum SLAX
language version required to run your script.
You can find libslax documentation here:
http://www.libslax.org/the-slax-language
On 22 December 2015 at 20:50, Mar
But would that be +14 assuming no VLAN headers, +18 assuming 1 VLAN
header, +22 assuming q-in-q ?
Was always my understanding that JunOS MTU figures were on-the-wire
frame sizes, whereas Cisco was always payload sizes, with requisite
headers accounted for automagically.
On 19 December 2015 at 16:
Use DHCP helper to point to an existing DHCP server where you can
serve leases from would be my thinking.
On 10 November 2015 at 01:15, Sebastian Bermeo
wrote:
> If this device not support this service, what kind of configuration may I
> use to run this function? I need a example, I'm learning o
On 29 September 2015 at 15:39, Phil Shafer wrote:
> "show | compare"
o/t but is there any difference between "show | compare" and "show | diff" ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-n
try doesn't work:
root@bki1-r140734-re1> request system reboot other-routing-engine
error: communication error while exchanging credentials with re0
error: Couldn't connect to re re0
So any chanced to fix this remotely without sending someone to
press the reset button?
Normal shutdown.
This is the reason recorded at the end of the shutdown process. Any action
that causes the re to reboot at this stage is equal.
On 14 Aug 2015 7:37 am, "james list" wrote:
> Hi
> In the second case if instead of hitting enter after the normal shutdown
> you power off and then po
I wonder if some double sided tape would suffice to hold it in place
until it needed to be replaced?
On 25 July 2015 at 00:13, Markus wrote:
> Am 23.07.2015 um 15:26 schrieb Colin Baker:
>>
>> Recently had a hard drive fail on one of our RE-850 in an M7i. Does
>> anyone have a known working (pre
Fixed.
Maybe the battery is dieing on the RE and some settings reset, but it
seems the boot list in the BIOS was set to LAN only.
Set it back to PMC,CF,HD,LAN and its back up and running.
Thanks for listening!
Tom
On 17 June 2015 at 16:25, Tom Storey wrote:
> Hi everyone. I powered off
replacing the RE?
I had a similar issue with it once before, but at that stage it
actually booted to a version-ish of JunOS where I was able to
re-configure the bootlist to include the HDD and CF, this time its not
even getting that far. :-(
Cheers
Tom
-1
!
Pastebin version (friendlier formatting etc): http://pastebin.com/nPXTcdvj
On 13 March 2015 at 19:08, Nick Cutting wrote:
> Very nice, your EMM is much better than mine !
>
> -Original Message-
> From: Tom Storey [mailto:t...@snnap.net]
> Sent: 13 March 2015 18:09
>
ou want it to
run more frequently than 60 seconds.
The odd thing is that I have a Cisco behind NAT firing up an IPSec
tunnel to a Juniper, and that works just fine. Strange that it wouldnt
work the other way around...
On 13 March 2015 at 17:06, Tom Storey wrote:
> Hi Nick,
>
> Yeah, I dont
m: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick
> Cutting
> Sent: 13 March 2015 16:25
> To: Tom Storey; cisco-nsp; juniper-nsp@puck.nether.net
> Subject: Re: [c-nsp] Help with an IPSec scenario
>
> I tried to get this to work for weeks, in the end, I u
Hi everyone,
Trying to establish an IPSec tunnel (route based) between a Juniper
SRX and a Cisco IOS router.
The topology is two routers with DSL services, the SRX is on a dynamic
IP, the Cisco on a static. No NAT is involved in the path between the
two routers.
Heres the configs Im working on:
Interesting, Ive got a couple of MX960's with high line AC PEMs in front of
me, and if I only turn one of them on, I only get half a router powered up.
As far as I know, there is still zoning with high line AC PEMs.
PEM0 and PEM2 supply one half of the router (slots 0-5 and RE0 and one fan
tray),
the right knob to push from RR to PE
simply the origin next-hop as sent from the CE,
but I didn't find it - any clues?
Thanks,
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
idea howto leak
routes received via inet-vpn to inet.0...
Thanks,
Tom
PS:
No, rib-groups between bgp.l3vpn.0 and inet.0 doesn't work, tried that
already.
Am 14/01/15 um 17:15 schrieb Chuck Anderson:
I just found this excellent post that describes how rib-groups and
auto-export work
Hi Dave & j-nsp,
I tried your example,
but it does not work - and I am a little bit helpless:
http://0bin.net/paste/lpH6zV8Pk2EXnI9L#F5xzmKZTpl9hA5QjZipHfz83-xdG6qexK4MGyM6SSCU
I also tried having an "accept all" import policy, but that doesn't
changed anything.
Thanks
but all of that also did not work :(
Any hint or idea?
Thanks,
Tom
PS: For the other way round, getting the default route to the VRF, I
simply use a next-table inet.0 route in the vrf.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
0, Olivier Benghozi
wrote:
> If you use one 10x10GE MIC and one 20x1GE, on the paper 120 Gb/s would
> mean no oversubscribing, but how the capacity will be really divided?
>
> > Tom Storey wrote :
> >
> > As was explained to me a while back, the MPC3E has ~120gbit of c
As was explained to me a while back, the MPC3E has ~120gbit of capacity.
But the devil was in how that capcity is shared between the two MIC slots.
When you have two active MICs that capacity is divided equally between the
two MICs: 50/50% or ~60/60gbps. It is NOT a case of operate one card at
fu
If you can handle burning 2 more ports on your SRX you could also do the
following:
The existing interface which the VLANs come in on is "interface A".
Take two more interfaces, B and C and hook them up back to back and
configure interfaces A and B as switched trunk interfaces.
On interface C yo
all
> set security zones security-zone INSIDE interfaces ge-0/0/0.0
> set security zones security-zone INSIDE interfaces lo0.0
> set security zones security-zone INSIDE interfaces st0.0
> set security zones security-zone INSIDE interfaces gr-0/0/0.0
>
>
>
> -
>
&
w my current configs?
Thanks in advance.
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Found an ebay listing with some pictures of a T1600 power supply
(T640/T1600/T4000, its all the same chassis so the pinout should be
the same) that also includes a description of each pin on the power
supply...
http://www.potomacescrap.com/ebay/images/STORE-5409-0005.JPG
http://www.potomacescrap.c
- the rib group magic was always voodoo for me...
Any idea or "best practices" to solve with another way?
Thanks,
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Cost, essentially.
I have recommended the MX5-MX80 series instead, being a proper routing
platform, but was asked to find other options too.
On 16 Apr 2014 20:07, "Chris Jones" wrote:
> Why not an MX instead?
>
>
> On Wed, Apr 16, 2014 at 11:41 AM, Tom Storey w
Hi everyone.
The SRX240 works pretty well as an MPLS/VPLS platform when stuck in packet mode.
I am wondering if the SRX550 operates in a similar way?
Has anyone out there used an SRX550 as a slightly more high powered
xPLS platform? Of particular interest it has 10GE modules available
that the S
et] On Behalf Of
> Mircho Mirchev
> Sent: Saturday, March 29, 2014 11:32 PM
> To: Tom Storey
> Cc: Juniper Maillist
> Subject: Re: [j-nsp] J2300/J4300 FPCs cannot go online
>
> Hi,
> Same here
> Seems there are more expired certificates.
> We'll have to try
Ive just tried this on my J2300 running 9.3r4.4.
The certificate now appears, unlike before when nothing appeared:
root> show system certificate
Certificate identifier: FeatureLicense-v4
However my FPC is still seemingly refusing to come online:
root> show chassis fpc detail
Slot 0 information:
show int diag optic
Some interfaces don't support it as mentioned, e.g. the fixed optic
STM-64/OC-192 PICs in my experience. Otherwise I haven't come across a PIC
that takes pluggable optics that this didn't work on, as long as the optic
supports DOM I guess.
On Friday, 21 March 2014, Keegan Hol
For everyones reference, this is the config I have been using, and
seems to work as you'd expect on a Cisco. Using this config I have run
Junipers against the same TACACS server used by Cisco devices without
any issues.
system {
authentication-order [ tacplus password ];
root-authenticatio
M/MX series. Am I trying to do something that
the SRX series simply cant do?
Im trying my hardest to work this out on my own, but I would again be
greatly appreciative if anyone has any tips or pointers. I think Ive
been through just about every forum post, blog, and random note I can
find on
on on this matter?
Most important: May I mix M2 and M2A in a nsrp cluster?
Thanks,
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Thanks for the responses so far, heres a few more details about what
Im experiencing at the moment.
So I start with something like this:
# show interfaces ge-0/0/12
description "VPLS test interface";
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
And I want to pop the VLAN header on ou
Hi everyone.
Im playing around with VPLS between 3x SRX240's and looking for a little info.
Ive got an interface configured as such:
ge-0/0/12 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-vpls;
vlan-id 123;
}
}
And betwe
Ok, so then you could in theory just leave the site-range command out
of a VPLS config in order to go by default values, unless you needed
to enforce a maximum site count?
On 8 January 2014 11:56, Saku Ytti wrote:
> On (2014-01-08 00:21 +), Tom Storey wrote:
>
> Hi Tom,
>
>>
Hi all,
Could someone validate my understanding (or lack of) about the purpose
of the "site-range" command...
>From the reading around I have done, the site-range basically
indicates how many sites maximum can/should exist for a given VPLS.
This tells the routers how many labels should be reserve
Yeah I did see this, but Im looking to avoid flow mode on the whole.
On Thursday, December 19, 2013, 雨飞 叶 wrote:
> You can also use selective packet mode: To get best of both worlds, see
>
> http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf
>
> On Thu Dec 19 2013 at
>
>
> Original message
> From: Phil Mayers 'p.may...@imperial.ac.uk');>>
> Date: 19/12/2013 6:09 PM (GMT+03:00)
> To: Tom Storey 't...@snnap.net');>>
> Cc: juniper-nsp@puck.nether.net 'juniper-nsp@puck.nether.net');
Excellent. Seems the prospects are good then. :-)
No new purchases.
On 19 December 2013 14:25, Tom Storey wrote:
> Hi everyone.
>
> Whats the general consensus about using a J series entirely in packet mode?
>
> Are there any gotchyas to be wary of, like missing features,
> p
On 19 December 2013 14:39, Phil Mayers wrote:
>> performance hit? It looks like you can configure 3 address families
>> for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
>> reading, enabling MPLS packet mode forces the whole box in to packet
>> mode, including inet4.
>
>
> Yes.
Hi everyone.
Whats the general consensus about using a J series entirely in packet mode?
Are there any gotchyas to be wary of, like missing features,
performance hit? It looks like you can configure 3 address families
for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
reading, en
Interesting. Has anyone tried this with protocols like IS-IS and with IPv6?
I'd love to add an EX3200 to my lab, but shelling out for a license would
make it a bit too expensive.
On 27 Nov 2013 00:25, "Paul S." wrote:
> From what I've seen, the license is mainly a 'nag license,' at least for
> BG
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.
On 8 November 2013 16:46, Paul Nazario wrote:
> That is what we've heard and they have
Isnt that the whole point of the OSI model? To separate different layers
and make them independent of each other so that one layer doesnt need to
care about ones above or below it as such?
With that in mind, different optics shouldnt have any kind of bearing on
LACP, which should only need a bunch
ut like to hear your opinion before...
(And no, I can't simply put output sampling on the other interfaces,
since there is MPLS forwarding on them active...)
Thanks,
Tom
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.
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.
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, nor
Just a thought, but have you tried doing a "chmod 664 /var/log/messages"?
That should make it world readable, so should not matter what your user
level/permissions are.
I would also compare the user/group ownership against a working box to make
sure its all the same.
On 13 June 2013 16:06, Vinc
being.
On 7 June 2013 11:43, Phil Mayers wrote:
> On 07/06/13 09:54, Tom Storey wrote:
>
> But without being able to redefine a variable, and with variables defined
>> inside an IF block not being accessible outside of that IF block, I will
>> need to reproduce my
if ($ifdescrdb/logical-interface[**name ==
> $if]/description) {
>
>
> The above means that only IFLs whose XML tag matches a string
> stored in variable $if will be processed.
> HTH
> Thanks
> Alex
>
> - Original Message - From: "Tom Storey"
>
1 - 100 of 162 matches
Mail list logo
