Re: [j-nsp] Juniper publishes Release notes as pdf

ile. > > Regular release notes are still available via web as previously. > > > > I’ll gladly pass along the feedback as well that SR notes need improvement. > > > > Joe > > > > Juniper Business Use Only > > *From: *juniper-nsp on behalf of > Olivie

Re: [j-nsp] Juniper publishes Release notes as pdf

That's right, it's ridiculous: the person in charge actually just clicks on «print as PDF» from its Juniper_internal_only_web_access, and uses the Portrait format instead of Landscape: therefore some part of the text is frequently eaten on the right of the document. No proofreading, no check, no no

Re: [j-nsp] QSA adapters and MTU

Actually 1G ports are «10G ports operating at 1G speed». So, configured as 10G ports on chassis side, giga-ether speed 1G on interface side. Le ven. 3 nov. 2023 à 16:53, Chris Wopat via juniper-nsp < juniper-nsp@puck.nether.net> a écrit : > I can test this on our lab box, but cant get 'supported

Re: [j-nsp] GRE tunnels on a QFX10002-60C

I guess that the right thing to do would be to provide a licence based model for MX304 with an entry level capacity licence priced as the MX204 currently is... > Le 27 juin 2022 à 18:15, Giuliano C. Medalha via juniper-nsp > a écrit : > > MX204 was announced at EoS > > We have used MX204 fo

Re: [j-nsp] upgrading an antique 240

Just in case, did you try a request system storage cleanup, before trying the recovery snapshot ? I suppose you had a look at https://kb.juniper.net/InfoCenter/index?page=content&id=KB33892 but it doesn't seem to match your problem, actually. What about a show chassis hardware detail | match " M

Re: [j-nsp] fpc1 user.notice logrotate: ALERT exited abnormally with [1]

Hi, this has nothing to do with the RE actually (and nothing to do with the router configuration). These messages come from the embedded Linux inside the MPC in slot 1 («fpc1»), when its logrotates is executed. This kind of infra inside the MPCs (a Linux running a Juniblob) exists since MPC7 I

Re: [j-nsp] SRX300 stuck in loader

Right, there are no USB images for SXR300. What is proabably needed is another SRX300 for creating an USB bootable snapshot (to boot the unbootable SRX300), then a snapshot from the USB to the flash (on the unbootable SRX300, once booted). Or someone with an SRX300 might create and make available

Re: [j-nsp] MX204 Maximum Packet Rates

By the way this one is public (not sure if relevant or not though): https://kb.juniper.net/InfoCenter/index?page=content&id=KB33477 > Le 20 mai 2021 à 14:00, Tobias Heister a écrit : > > Hi, > > MX204 has some limitations in terms of pps rates for smaller packet sizes if > inline-flow is conf

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

Hi, actually Juniper published PR1568533 about this (as it should have worked like KB35261 says but it was not) – the PR says it's fixed in 19.4R3-S3 too, by the way. Olivier > Le 19 mai 2021 à 13:26, Antti Ristimäki a écrit : > > Hi list, > > Just as a follow-up and for possible future ref

Re: [j-nsp] TCP-MSS adjust does not work on MPC10E

; {master}[edit] > > user-lo...@mx960.ol.lax.rnbn.net.RE0# run show forwarding-options hyper-mode > Current mode: normal mode > Configured mode: normal mode > {master}[edit] > user-lo...@mx960.ol.lax.rnbn.net.RE0# > > > > >> On Apr 17, 2021, at 12:52 A

Re: [j-nsp] TCP-MSS adjust does not work on MPC10E

MPC10. SCBE3? SCBE3 => hyper-mode by default. As there's no hypermode firmware in MPC-16x10, only the MPC10 would really be in hyper mode, and therefore the firmware loaded in the MPC10 would be the faster hypermode one, while the firmware in the 16x10 will still be the standard one with all the

Re: [j-nsp] qfx5100 help with Q in Q

Hi, I posted some working config last week in this ML (working for EX4600 and therefore QFX5100 – but on 18.4R3). > Le 19 août 2020 à 14:40, John Brown a écrit : > > Switch A is running 18.1R3.3 > Switch B is running 18.3R2.7 > Both are qfx5100-48s-6q. > > [...] > > I am trying to QinQ traffi

Re: [j-nsp] Juniper EX/QFX vlan-id-list limitation

0/1] > 'unit 3107' >duplicate VLAN-ID on interface > error: configuration check-out failed > > Cheers, > Rob > > > > > > -Original Message- > From: juniper-nsp On Behalf Of Olivier > Benghozi > Sent: 12 August 2020 19:12 >

Re: [j-nsp] Juniper EX/QFX vlan-id-list limitation

Hi, We miraculously found this doc before implementing such QinQ conf on EX4600 (that are low end QFX5100). So we didn't try to test the switch with this case, and we directly used such config: instead of vlan-id-list [some ids], we (nearly) always use the same one everywhere: vlan-id-list 2-40

Re: [j-nsp] track-igp-metric in LDP

That's right: if you want your LDP labeled traffic to follow your IGP costs instead of using unexpected paths (and you probably want it in fact, as if you want to do something else you usually use RSVP/MPLS-TE or Segment Routing), you just need track-igp-metric (and therefore it's always useful/

Re: [j-nsp] How to shut down laser on any optics

This would prove once again that vendor_endorsed_and_overcharged optics are just a useless scam. This being said, we didn't experience this neither with Skylane nor Cubeoptics transceivers (currently on MPC7-MRATE / 18.4R[2-3]-[S*]). It «just works» as we expect (laser is switched off when the

Re: [j-nsp] Subscriber DHCPv6 lease time for IA_NA from Radius Server

Maybe liveness-detection method layer2-liveness-detection and/or overrides client-negotiation-match incoming-interface so the binding just disappears quicker on the MX side? > Le 11 mars 2020 à 11:29, Sebastian Wiesinger a écrit : > > I'm currently testing IPv6 subscriber termination (PPP/L2TP)

Re: [j-nsp] Next-table, route leaking, etc.

I realise I wrote by mistake «next-hop» instead of «next-table» about everywhere :) > Le 10 févr. 2020 à 05:51, Olivier Benghozi a > écrit : > > To deal with this on MX stuff a way that looked like we did previously on > Redback gears (old beast but at least on them this «j

Re: [j-nsp] Next-table, route leaking, etc.

To deal with this on MX stuff a way that looked like we did previously on Redback gears (old beast but at least on them this «just works» with double lookup), we use a «third part« VRF. This is a dedicated empty VRF on each router with only a bunch of static next-table routes. It is a no-vrf-adv

Re: [j-nsp] SRX3xx VPN Client - NCP alternatives?

We were on 3.2 until last week, then updated to 4.0 this week. > Le 8 nov. 2019 à 02:26, Nathan Ward a écrit : > >> On 8/11/2019, at 2:13 PM, Olivier Benghozi >> wrote: >> >> Using split tunneling (and split DNS) with this here, on several macs (and >>

Re: [j-nsp] SRX3xx VPN Client - NCP alternatives?

Using split tunneling (and split DNS) with this here, on several macs (and good^H^Hold SRX2xx). It usually works properly (the routes to VPNize are configured statically within the profile config). Never seen such /1 routes. I know that «here it works» isn't that helpful, but at least this is how

Re: [j-nsp] QFX10008 and sFlow

Hi, you probably don't really want to configure the older sFlow monitoring those days (with its various limitations), what you probably really need is to configure inline IPFIX flow monitoring, as it is supported by QFX10k devices. > Le 14 oct. 2019 à 19:49, Tim Vollebregt a écrit : > > I’m to

Re: [j-nsp] QFX5100 and BGP graceful-shutdown in 19.1

The most amazing is that in 19.1 they support another «new» «on the edge» feature at last: bgp session shutdown (not just deactivate), 21 years later :) > Le 20 août 2019 à 10:39, Sebastian Wiesinger a écrit : > > JunOS 19.1 brings support for the BGP graceful shutdown mechanism > (RFC8326): >

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

Looks like the PR about this is now available: PR1443811 «RSVP refresh-timer interoperability between 15.1 and 16.1+». «Path message with long refresh interval (equal to or more than 20 minutes) from a node that does not support Refresh-interval Independent RSVP (RI-RSVP) is dropped by the rece

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

native-vlan isn't a problem here. > Le 23 juil. 2019 à 07:57, Mark Tinka a écrit : > > On 23/Jul/19 01:45, Olivier Benghozi wrote: > >> So if I understand well, they suddenly chose compatibility with Cisco & MX >> instead of compat with old EX (whereas an opt

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

4 months old thread, but (since I'm starting to test some QinQ stuff just now), I found both this thread and its «solution»: PR1413700 «Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms» «On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged traffic o

Re: [j-nsp] 802.3ad LAG between ASR 1002-X and Juniper MX204

We usually prefer LAGs here (with microBFD on backbone links) ; but, any horror stories to share? > Le 20 juil. 2019 à 12:06, Mark Tinka a écrit : > > We now restrict LAG's to router-switch 802.1Q trunks. > On backbone links, we've found regular IP ECMP to be more reliable than > LAG's. _

Re: [j-nsp] 802.3ad LAG between ASR 1002-X and Juniper MX204

Yes, you'd better drop all the hash+loadbalance+linkindex conf (by the way, on MX the "hash-key" knob is only for DPC cards, 10+ years old). However about the LAG itself, if you want something reliable you really should use LACP instead of static LAG. Static LAGs, a good way to get your traffic

Re: [j-nsp] PE-CE BGP announcements

Really sure of your export policy when removed from the neighbour (that is, any policy under the protocol or the group) ? show bgp neighbor exact-instance foo 10.108.35.254 | match export Any NO-EXPORT community attached on the route? > Le 7 mars 2019 à 20:04, Jason Lixfeld a écrit : > > My

Re: [j-nsp] Hyper Mode on MX

By the way HyperMode is only useful if you expect some very high throughput with very small packets (none of the MPCs are linerate using very small packets, but HyperMode brings it closer). Your Junirepresentative may show you a linerate performance/packet size graph with/without HyperMode to he

Re: [j-nsp] BGP Extended Community sub-type as zero not valid

Technically, AS0 is invalid (RFC 7607, but it was stated before that more or less clearly). However on JunOS you may fill the first field of an rt with 0 by using the IPv4:value format for rt (type 1): target:0.0.0.0:1 ..but you will be limited to 16 bits for the other field (so up to 65535).

Re: [j-nsp] Finding drops

Interesting to see that Hyper-mode is useless on MX204, by the way (it's expected to do something on MPC7). > Le 31 janv. 2019 à 16:46, adamv0...@netconsultings.com a écrit : > > Hmm interesting, so it's capped at the WA block then not on the ASIC, good to > know. > On MPC7s we did not run into

Re: [j-nsp] DNS Flag Day

It would mean that they run something older than 10.2 JunOS, that is a prehistoric release, which would be criminal in term of security. Anyway, putting stateful firewalls in front of DNS servers is a nonsense from the beginning. > Le 25 janv. 2019 à 13:06, Christian Scholz a écrit : > > What

Re: [j-nsp] Ex2300 for branch office

A few elements: EX2300: Broadcom instead of Marvel, CPU and memory are now decent (no more slow commits). Fans seem to be just a little more noisy than the 2200. - Worse (compared to EX2200): no VRF ; Virtual-Chassis now needs a licence (honour based) ; less space for ACL/firewall-filters (Broa

Re: [j-nsp] Finding drops

My 2 cents: it could be interesting to check if running the system in hyper-mode makes a difference (that should normally be expected). > Le 22 janv. 2019 à 20:42, adamv0...@netconsultings.com a écrit : > > That sort of indicates that for the 64B stream the packets are dropped by the > platform

Re: [j-nsp] Running MX480 without craft interface

It is. https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/mx480-fru-overview.html https://www.juniper.net/documentation/en_US/release-independent/juno

Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

PR1270686 restart statistics-service > Le 21 déc. 2018 à 01:23, Jeff Meyers a écrit : > > Dec 21 01:20:40 fra4-cr2 mib2d[67435]: SNMP_EVLIB_FAILURE: PFED ran out of > transfer credits with PFE.Failed to get stats. ifl index: 373 > > I already did a snmp process restart without any success. G

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

Works as expected here (16.1R7)... > Le 27 sept. 2018 à 13:43, Drew Weaver a écrit : > > I added 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org to > system ntp on an MX80 running JunOS 15. > > [edit system ntp] > drew@charlie# show > server 216.230.228.242; > server 45.79.109.1

Re: [j-nsp] ether-options vs gigether-options in MX series

> From: juniper-nsp On Behalf Of Olivier > Benghozi > Sent: Tuesday, September 18, 2018 11:57 AM > To: Juniper List > Subject: Re: [j-nsp] ether-options vs gigether-options in MX series > > ether-options -> gigether-options > >> Le 18 sept. 2018 à 17:47, Dre

Re: [j-nsp] ether-options vs gigether-options in MX series

ether-options -> gigether-options > Le 18 sept. 2018 à 17:47, Drew Weaver a écrit : > > Greetings, > > I am attempting to create a link aggregation on an MX80. > > Reading the documentation it indicates: > > ether-options { >802.3ad ae0; >} > > To an interface will add that physi

Re: [j-nsp] flow sampling aggregated interfaces

Flow sampling works on the address-family of layer3 subinterface, so it's under the "unit x family y", whether the unit is on an ae or a physical layer1/2 interface (since you want to sample all the traffic): set interfaces ae4 unit 0 family inet sampling input set interfaces ae5 unit 0 family i

Re: [j-nsp] LSP's with IPV6 on Juniper

For 6PE you have to: - delete the iBGP ipv6 groups - add family ipv6 labeled-unicast explicit-null to the IPv4 iBGP groups - add ipv6-tunneling to protocol mpls. - make sure your IGP is not advertising IPv6 addresses This is the way it's configured, with either RSVP-TE or LDP. > Le 29 août 2018 à

Re: [j-nsp] LSP's with IPV6 on Juniper

In global we have 6PE. In VRF we have 6VPE. Just works so far. An yes, the MPLS control-plane uses only IPv4: (the intercos between routers are in IPv4, LDP uses IPv4, IGP uses IPv4, and IPv6 is really announced over specific AFI/SAFI (labeled unicast IPv6 for 6PE, VPNv6 for 6VPE) in IPv4 MP-iB

Re: [j-nsp] Carrier interfaces and hold timers

That's not the point here ; the point here is: «to deal with their link constantly flapping». A constantly flapping link must be either fixed or cancelled. > On 16 aug 2018 at 03:23, Luis Balbinot wrote : > > Sometimes carriers protect optical circuits using inexpensive optical > switches that

Re: [j-nsp] Carrier interfaces and hold timers

In some cases, we have used holdtimers to wait before setting up the interface, but never before setting down it (if it's down, it's down, there are technologies to fast reroute). But a link is not expected to flap in normal case. If it flaps, it's broken (and we all know it happens). This bein

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

p, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-f...@uiowa.edu, phone: 319-335- > > On Wed, 11 Jul 2018, Olivier Benghozi wrote: >> One thing to think about, in IPv6: >> On MX, one can use "match protocol" (with Trio / M

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

One thing to think about, in IPv6: On MX, one can use "match protocol" (with Trio / MPC cards). But it's not supported on lo0 filters, where you were / probably still are restricted to "match next-header", in order to have a filter working as expected. > Le 11 juil. 2018 à 20:17, Drew Weaver a

Re: [j-nsp] inline jflow/srrd memory use/size

SRRD mem size should be related to the route table size, from what I understood... On an MX480 in 16.1R with DFZ in VRF: > show system processes extensive | match srrd 5174 root 1 200 1220M 509M select 3 30:36 0.00% srrd Not sure an MX104 is the best gear to run DFZ + inl

Re: [j-nsp] advertise-from-main-vpn-tables and Hub&Spoke VRFs (was: KB20870 workaround creates problems with Hub and Spoke) downstream hubs?

I guess you have an explicit match for those routes in your VRF export policy for the downstream VRF instance ? > On 29 may 2018 at 11:15, Sebastian Wiesinger wrote : > b) with advertise-from-main-vpn-tables > > [Hub instance] -> [Downstream hub instance] --> [bgp.l3vpn.0] -> MP-BGP > neig

Re: [j-nsp] MX204

And additionally, 24x10g is the default when you unpack and plug the box. > Le 16 mai 2018 à 18:28, Olivier Benghozi a > écrit : > > That port config tool sux ; but you can have 24x10g if you turn on the « per > PIC» small selector. > >> Le 16 mai 2018 à 18:15,

Re: [j-nsp] MX204

That port config tool sux ; but you can have 24x10g if you turn on the « per PIC» small selector. > Le 16 mai 2018 à 18:15, Bill Blackford a écrit : > > So that port config tool. It looks like I can't do 24 10g. However, I can do > 20 10g and a single 100g which makes no sense to me, but then

Re: [j-nsp] MX204

Looks like it will work, in « PIC Level » configuration (both PICs configured as « 10GE » – and it seems to be the default). The doc is crappy and the port checker tool is a nice piece of junk, however. > On 15 may 2018 at 00:15, Bill Blackford wrote : > > I'm looking at cost effective replacem

Re: [j-nsp] Difference between MPC4E-3D-32XGE-RB and MPC4E-3D-32XGE-SFPP ?

https://www.juniper.net/documentation/en_US/junos/topics/concept/chassis-license-mode-overview.html but not very clear... > Le 1 mai 2018 à 12:32, Nikolas Geyer a écrit : > > Can’t remember th

Re: [j-nsp] MX104 and NetFlow - Any horror story to share?

Hi Alain, While you seem to already be kind of suicidal (5 full tables peers on an MX104), on an MX you must not use netflow v9 (CPU based) but use inline IPFIX (Trio / PFE based). I suppose that Netflow-v9 on an MX104 could be quickly an interesting horror story with real traffic due to its ri

Re: [j-nsp] Going Juniper

Hi, While PPC is clearly slower than x86 stuff, the problem is that JunOS should have never been compiled for this architecture. I suppose/hope that the product manager who took such decision is now in a madhouse. As Saku Ytti wrote in NANOG ML in 2014 (when comparing Cisco 6500/7600 and MX80/

Re: [j-nsp] mx960 junos upgrade fail

Not sure you really can ISSU update between such versions... About the OS file, you want vmhost 64bits. The Net version is to freshinstall using PXE Netboot. And the "64 Bit-MX High-End Series" is the one you would use with a RE-1800 (directly running JunOS over FreeBSD over its hardware), while

Re: [j-nsp] mx960 junos upgrade fail

https://www.juniper.net/documentation/en_US/junos/topics/concept/installation_upgrade.html « Host upgrade—Use the junos-vmhost-install-x.tgz image upgrade. When you upgrade the host OS, you must specify

Re: [j-nsp] Juniper UDP Amplification Attack - UDP port 111 ?

So it most probably comes with "upgraded Junos with FreeBSD 10", that is 15.1+ on MX with intel CPUs. There's something fun described on PR1167786 about similar behaviour: "Due to Junos Release 15.1 enabling process rpcbind in FreeBSD by default, port 646 might be grabbed by rpcbind on startup,

Re: [j-nsp] LCP keeps renegotiating on L2TP tunnel

You need to trace the L2TP packets on both sides. "AVP" deals here with AVPs within L2TP control packets, not in radius. It's about the AsyncMap missing in L2TP SIL packets (made to exchange Asyncmaps), in Asyncmode PPP/L2TP. > On 22 feb 2018 at 07:23, Drikus Brits wrote : > > Heya Experts, >

Re: [j-nsp] EX4550 15.1 VLAN Translation

Hi Jed, the EX4550 doesn't use the "Enhanced Layer 2 Software / ELS" (basically, for Broadcom based EXs) ; that is, it uses the "legacy/former" EX config style (for Marvell based EXs), so this doc is not the right one. You may have a look at this "legacy EX" KB article about VLAN translation: h

Re: [j-nsp] KB20870 workaround creates problems with Hub and Spoke downstream hubs?

Note that our observations (and found workaround) were when using sub-policies applied within export-policies. > On 15 feb 2018 at 10:33, Olivier Benghozi wrote > : > > Now, if you see some VPN routes no longer advertised toward other PEs, it > probably means that your VRF

Re: [j-nsp] KB20870 workaround creates problems with Hub and Spoke downstream hubs?

Hi Sebastian, This is an old workaround by the way. Simpler workaround: use advertise-from-main-vpn-tables knob available since 12.3 (required if you have NSR anyway): https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/advertise-from-main-vpn-table-edit-pr

Re: [j-nsp] Single RE-S-X6-64G with "error: Unrecognized command (chassis-control)"

Since you create an Olive from an M/MX/T release, you know that Junos declares itself an "Olive" if it doesn't recognise a Juniper hardware it knows (well, except for vMX/vSRX/vRR/vWhatever, even if there was a bug in older releases where it nevertheless showed Olive). Additionally, RE-S-X6-64G

Re: [j-nsp] Transit composite next hops

ssis like the MX80 come with CNHs > configured as the default, but that's only true for ingress EVPN. And in fact it's for all MXs. Crappy doc. > I'm still confused :-) It's confusing. > On Sun, 11 Feb 2018 at 19:56 Olivier Benghozi <mailto:olivier.bengh...@wif

Re: [j-nsp] Single RE-S-X6-64G with "error: Unrecognized command (chassis-control)"

Hi Dave, > On 12 feb 2018 at 23:41, Dave Peters - Terabit Systems > wrote : > Forgive my ignorance, but I've got an RE-S-X6-64G running in an MX480 (BP3) > with an SCBE2, version 15.1R6.7, and it has a chassis-control problem: As this RE is not supported in 15.1R this seems legit, so I suppose

Re: [j-nsp] Transit composite next hops

Hi Luis, I already wondered the same thing, and asked to our Juniper representative ; the answer was that each family supports (and only supports) its specific CCNH flavour: CCNH for ingress: MX CCNH for transit: PTX (I didn't asked for QFX10k). Olivier > On 10 feb. 2018 at 19:17, Luis Balbinot

Re: [j-nsp] Prefix independent convergence and FIB backup path

Hi Mark, Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn AFI) we can see that, when possible: active eBGP path is backuped via iBGP path active iBGP path is backuped via another iBGP path We don't see: active iBGP backuped via inactive eBGP active eBGP backuped via a

Re: [j-nsp] Multicast through a switch

This is a bug, not a feature :P > On 9 janv. 2018 at 11:00, Gert Doering wrote : > > Well. Sort of. EX3300 manages to apply IGMP-snooping logic to 224.0.0.x > multicast, which by definition is link-local and is not(!) IGMP-queried > for - thus breaking EIGRP routing, for example. And annoying

Re: [j-nsp] Understanding limitations of various MX104 bundles

MX204 is probably not that expensive compared to a fully licensed MX104, I guess. And while MX204 doesn't have RE redundancy, it supports NSR so I understand it runs two JunOS VMs in a Windriver Linux as hypervisor, I guess. > On 5 janv. 2018 à 15:54, Edward Dore > wrote : > > The MX204 seems

Re: [j-nsp] Poll Question (VRF scale on MX)

The use of NH DMEM might also slightly vary with various features (LFA/PIC/multipath), I guess. > On 21 dec. 2017 at 12:19, adamv0...@netconsultings.com wrote : > > Junos code version: > Number of VRFs: > Number of destinations (total or average per VRF): > Output from: request pfe execute targe

Re: [j-nsp] Experience with Junos 15.1 on MX960?

Cosmetic bugs seen here: PR1254675, PR1289974, PR1293543, PR1261423 (all fixed in 16.1R6, can be seen in release notes). > On 13 dec. 2017 at 16:29, Michael Hare wrote : > > We are looking at moving to 16.1R6 within the new few weeks on an MX2010 from > 14.1. Several folks have mentioned cosm

Re: [j-nsp] Experience with Junos 15.1 on MX960?

We've been running 16.1R4-S3 or S4 for 4/5 months (we had to choose between 15.1F and 16.1R for our MPC7s), without MC-LAG. We've been hit by about 8 PR, including 4 non-cosmetic ones (with 3 also present in 15.1F anyway). Most of them are allegedly fixed in 16.1R6. 17 might be the next step in 6

Re: [j-nsp] Enhanced MX480 Midplane?

While I don't care about SONET/SDH in 2017 (sorry...), the enhanced midplane (in the MX240/480/960 MX generation) also (mainly?) allows more bandwidth per slot with the future SCBE3. You may find a fugitive Juniper 2016 PDF on your preferred search engine ("SCBE3" "premium3" "mx"). > On 14 nov.

Re: [j-nsp] Sporadic LUCHIP IDMEM read errors

Maybe http://news.nationalgeographic.com/2017/09/sun-solar-flare-strongest-auroras-space-science/ ? > On 26 sept. 2017 at 09:14, Sebastian Wiesinger wrote : > > Hello, > > we're seeing sporadic LUC

Re: [j-nsp] Moving onto EX2300

New additional licence needed to stack (VirtualChassis), VRF not supported. > On 20 sept. 2017 at 17:16, William wrote : > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > share their experience with this model? Anything to watch out for? ___

Re: [j-nsp] Junos 15 on EX2200's

There were some various memory leaks in 15.1R6 on EX, fixed in 15.1R6-S2 (TSB17127), and this probably didn't help :-P Last available is 15.1R6-S3. > On 31 aug 2017 at 21:11, Charles van Niman wrote : > > Just one datapoint, but I loaded 15.1R6 on my EX2200-C and saw mgd and > all ssh/snmp

Re: [j-nsp] Why JUNOS need re-establish neighbour relationship when configuring advertise-inactive

Here we directly set protocols bgp advertise-inactive (and in routing-instances too with an apply-group adding various stuff, like always-compare-med, router-id, and so on). Never seen any good reason to stay with the junos default about this point... > On 15 jul. 2017 at 14:32, Roger Wiklund wr

Re: [j-nsp] MPLS L3VPNs, Route-Reflection, and SPRING with IS-IS on QFX5100

By default JunOS will create a label for the primary loopback address (as told in "MPLS in the SDN Era", page 172). So, here, by default, the first one. If you wan a label for the "242" IP only: invert both loopback IPs in the conf, or declare the second one as primary. But if you need a label f

Re: [j-nsp] can i get junos file from device

It validates the checksums then stores an installer locally (with the content of the tgz) that will be started at next boot, which will install the OS and stores the stuff (mainly to /packages/). On some platforms the new OS is installed to the alternate boot partition (on EX platforms by examp

Re: [j-nsp] bgp peer flapping

But what about route-target filtering using BGP route-target family ? Seems close enough, works without any sessions reset, and "Statement introduced before Junos OS Release 7.4"... > On 27 apr. 2017 at 18:15, adamv0...@netconsultings.com wrote : > Hmm, good point, > ORR would be impossible with

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

Hi, > On 22 apr. 2017 at 22:47, Dragan Jovicic wrote : > > From documentation: >> On platforms containing only MPCs chained composite next hops are enabled by >> default. With Junos OS Release 13.3, the support for chained composite next >> hops is enhanced to automatically identify the underl

Re: [j-nsp] IPv6 flow routes

As read on https://www.juniper.net/techpubs/en_US/junos/topics/example/example-configuring-bgp-to-carry-ipv6-flow-routes.html : set routing-options rib inet6.0 flow route route-

Re: [j-nsp] Match multiple bgp communities in a policy with AND condition

We use some same kinds of things here, that is subpolicies expressions (or subpolicies chains at other places): policy-statement Blah { term MyTerm { from { policy ( ! (( ! A ) && B && ( C || D ))); } then next policy; } policy-statement A { term

Re: [j-nsp] problem with advertise ipv6 default route

Default BGP policy doesn't imply that static routes are spontaneously allowed anyway, so removing it is useless. Your bgp export policy is probably fucked up but unfortunately you didn't show it. > On 25 march 2017 at 16:23, Pedro wrote : > > On MX router i'm tring advertise ::/0 to v6 peers.

Re: [j-nsp] routing instances on EX2300

thfinder.juniper.net/feature-explorer/select-platform.html > > > -----Messaggio originale- > Da: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Per conto di > Olivier Benghozi > Inviato: giovedì 23 marzo 2017 11:23 > A: juniper-nsp@puck.nether.net > Oggetto: Re: [j

Re: [j-nsp] routing instances on EX2300

According to the Feature Explorer, VRF Lite are supported on EX2200, but not on EX2300. Reducing the feature set of new products is just ridiculous... > Le 23 mars 2017 à 08:55, Valentini, Lucio a écrit : > > I was trying to configure routing instances on the EX2300, like I did on the > EX4300

Re: [j-nsp] MX104 limitation

What about bypass-queuing-chip on MIC interfaces ? Would it work on MX80/104 ? > On 20 march 2017 at 01:32, Saku Ytti wrote : > > Ok that's only 31Gbps total, without having any actual data, my best > guess is that you're running through QX. Only quick reason I can come > up for HW to limit on s

Re: [j-nsp] Advertise inactive route EBGP session

It's expected to work according to https://www.juniper.net/documentation/en_US/junos/topics/example/bgp-advertise-inactive.html So, aren't you trying to advertise an AS200 route to an AS200 router ? In

Re: [j-nsp] Netflow/Jflow

t the FPC > > Nitzan > > On Fri, Nov 4, 2016 at 5:47 AM, Scott Granados <mailto:sc...@granados-llc.net>> wrote: > +1, this is how I have set things up as well and yes, changing the table > sizes will cause an FPC reboot. > > > On Nov 3, 2016, at 9:04 PM,

Re: [j-nsp] Netflow/Jflow

Hi Keith, Adjusting the size of the flow hash table will reboot the FPC. In 14.2 and previous, you have everything (15) for IPv4 and only a few entries for IPv6 and VPLS (0). Each unit is 256K flows (except for 0). Starting from 15.1R, all flow tables have a default size of "0" (that is, a mini-

Re: [j-nsp] Netflow/Jflow

Basically, you must use the latest incarnation of inline-jflow (starting from 14.2), with most of PR fixed (that is : 14.2R7, 15.1R4, 15.1F6) and it should be fine. > Le 2 nov. 2016 à 23:53, Scott Granados a écrit : > > Hi, it’s been a while so if I’m wrong I’m happy to be corrected but in you

Re: [j-nsp] MX 14.2R7 / PR1177571

arm disappeared after the 2nd RE was detected with the same > software or after a complete reboot? > > Best regards, > Theo > > Von: santiago martinez > Datum: Mittwoch, 26. Oktober 2016 um 15:15 > An: Theo Voss > Cc: "juniper-nsp@puck.nether.net" , O

Re: [j-nsp] MX 14.2R7 / PR1177571

Yes but with 14.2R6 on re0 and 15.1R4 on re1 (so, during the update). Did you check that /var was properly mounted on re1? :) > Le 26 oct. 2016 à 10:53, Theo Voss a écrit : > > we've upgraded two of our MXs (MX960, 1800x4-32) to 14.2R7 and ran into > PR1177571 which should already be fixed in

Re: [j-nsp] Suggestion for Junos Version MX104

About SRRD: - CPU usage: beware of PR1170656. Told to be fixed in 14.2R7 15.1R4 15.1F6. - Mem usage: beware of PR1187721. Told to be fixed only in future or service releases (14.2R8 15.1R5 15.1F6-S2 16.1R3). > On 25 oct. 2016 at 14:23, Mark Tinka wrote : > On 25/Oct/16 14:16, sth...@nethelp.no w

Re: [j-nsp] Best way to do QOS bleach

In 14.2R3 and later, and in 15.1F and 16.1R (but not in 15.1R). > On 17 oct. 2016 at 18:11, Dragan Jovicic wrote : > > And if you require more granular ingress remark, as Mark suggested after > 14.2R3.8 you can use policy-maps. ___ juniper-nsp mailing

Re: [j-nsp] Limit content of bgp.l3vpn.0

It just does. > On 28 sept. 2016 at 18:49, Johan Borch wrote : > > I don't have a route-reflector, this is a full iBGP mesh, will family > route-target still work? > > On Wed, Sep 28, 2016 at 4:27 PM, Dragan Jovicic wrote: > >> By default route-reflector will reflect/refresh all vpn routes to

Re: [j-nsp] MX upgrade to 15.1R4.6: loopback filters drop all traffic

Updated from 14.2 to 15.1R here (on several MX, same RE hardware). Didn't see this issue. Any particular stuff in your filters ? > Le 18 sept. 2016 à 09:18, Chuck Anderson a écrit : > > Has anyone upgraded from 14.2 to 15.1 and seen this issue? Right > after the upgrade, all loopback filters st

Re: [j-nsp] What version of Junos is best for bgp.

Well, technically 15.1R uses all 4 cores :) > Le 16 sept. 2016 à 20:48, Saku Ytti a écrit : > > Newer is always newer, new features and maybe new bugs. I will put on > my marketing hat and tell you must go with 16.1R1, because you're only > using single core in your fancy 4 core system! With 16.

Re: [j-nsp] IPV6 over MPLS

If you have only RSVP-TE, you may have a look at this (inet6 shortcuts) which might be an alternative to 6PE for you: https://forums.juniper.net/t5/TheRoutingChurn/Traffic-engineering-inet6-shortcuts-to-connect-IPv6-islands-Part/ba-p/192763

Re: [j-nsp] IPV6 over MPLS

Hi raf, When using the new LDP native IPv6 support, as explained in https://www.juniper.net/techpubs/en_US/junos16.1/topics/task/configuration/configuring-ldp-native-ipv6-support.html

  1   2   >