Re: [j-nsp] gNMI on MX960

* Ebben Aries via juniper-nsp [2024-03-07 19:55]: > Am I to assume your JSON config is for the gnmi input plugin for > telegraf and is the complete config? I don't belive this plugin > supports the qos field either so can you share the precise version you > are testing with? > > How about

Re: [j-nsp] gNMI on MX960

* Jared Mauch via juniper-nsp [2024-03-07 16:51]: > > What do you mean by complete? > > > [edit services analytics] > jared@Router# set sensor asdf resource ? > Possible completions: > System resource identifier string > /junos/services/health-monitor/config/ Health monitoring

Re: [j-nsp] gNMI on MX960

Hi Jared, thanks for the answer. * Jared Mauch via juniper-nsp [2024-03-07 16:41]: > I’ve been spending some time on this as well, here’s the first thing I would > ask you: > > > If you do “show version | match tele” > > What do you see? I’ve had varying results based on the platform.

[j-nsp] gNMI on MX960

Hello everyone, I'm trying (and failing) to get gNMI running on an MX960. All I'm getting are weird errors. Has anyone successfully used gNMI subscriptions on an MX box for streaming telemetry? If so, which config did you use on the box and in the client? My config on the MX is this: set system

Re: [j-nsp] FEC on 25G-LR links between Juniper and Arista

* Sebastian Wiesinger via juniper-nsp [2023-12-06 12:55]: > Hi, > > we've run in some weird issue with 25G links and FEC between Juniper > QFX5120 and Arista. > > We have functioning links using 25G-SR optics and FEC108 > (Reed-Solomon) error correction. On Arista that

[j-nsp] FEC on 25G-LR links between Juniper and Arista

Hi, we've run in some weird issue with 25G links and FEC between Juniper QFX5120 and Arista. We have functioning links using 25G-SR optics and FEC108 (Reed-Solomon) error correction. On Arista thats default, on the QFX we use set interfaces et-0/0/46 gigether-options fec fec108 This works.

Re: [j-nsp] MX304 - Edge Router

* Karl Gerhard via juniper-nsp [2023-10-24 11:18]: > 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. > It depends. MACSEC on EX and QFX first had a license warning and a > permanent

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

* Wojciech Janiszewski [2020-03-11 11:43]: > Hi Sebastian, > > If I remember correctly, DHCP Lease Time can be adjusted by using Radius > Session-Timeout attribute. Hi Wojciech, I saw that parameter, but that would at the same time disconnect the PPP Session as a whole as I understand it. It

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

Hi, I'm currently testing IPv6 subscriber termination (PPP/L2TP) on an MX204 (18.4R2) and I have a bit of a problem with DHCPv6 IA_NA address allocation. By default the lease time for the address is one day (86400 seconds) when the address is received by Radius. The Cisco CPE configures this

Re: [j-nsp] Any red flags on this MX240 configuration...

* Alain Hebert [2020-02-26 14:47]: >     Beside the RE-S-2000-4096-S being EOL.  My experience with 16.2 was > pretty solid. > >     We're planning to have 3 Full Routes BGP and the MPLS alphabet soup, > yadi yada. > >     We don't want 2 RE since we'll use 2 MX240 and there is no point to go >

Re: [j-nsp] Juniper MX Physical Interface Damping

* Nathan Ward [2020-01-20 10:40]: > > > On 20/01/2020, at 10:33 PM, Sebastian Wiesinger > > wrote: > > > > Hello, > > > > I'm currently looking at physical interface damping on Juniper MX: > > > > https://www.juniper.net/documentation/en_US

[j-nsp] Juniper MX Physical Interface Damping

Hello, I'm currently looking at physical interface damping on Juniper MX: https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-damping-longer-physical-interface-transitions.html Fun Fact: Nowhere on this site is it mentioned that the penalty added per

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

Hi, JunOS 19.1 brings support for the BGP graceful shutdown mechanism (RFC8326): https://tools.ietf.org/html/rfc8326 https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/graceful-shutdown-edit-protocols-bgp.html While you could always do this by hand I was

Re: [j-nsp] prsearch missing in inaction

* Richard McGovern via juniper-nsp [2019-05-09 13:58]: > Tom, sorry but that is way far-fetched. Nathan, if TAC will not > provide you this info, then I am sure your local SE can assist. I > know I can/would for any of my accounts. I don't know, Juniper seems to go strange ways in terms of

Re: [j-nsp] EVPN/VXLAN experience

* Andrey Kostin [2019-03-28 15:24]: > Hi Sebastian, > > Could you please clarify a little bit, does this limit on bridge-domain > number apply when you have same 500 vlans on 30 aes or each ae has unique > 500 VNIs? Hi, it's the same 500 VLANs on all 30 AEs. > How is external connectivity

Re: [j-nsp] EVPN/VXLAN experience (was: EX4600 or QFX5110)

* Rob Foehl [2019-03-22 18:40]: > Huh, that's potentially bad... Can you elaborate on the config a bit more? > Are you hitting a limit around ~16k bridge domains total? Well we're just putting VLANs on LACP trunks like this: ae0 { mtu 9216; esi {

Re: [j-nsp] EVPN/VXLAN experience (was: EX4600 or QFX5110)

* Richard McGovern via juniper-nsp [2019-03-22 17:53]: > Sebastian, a couple of questions. > > 1. Your design is pure QFX5100 Leaf/Spine today? If yes, I assume > you maybe only have 1 flat VXLAN network, that is you have no L3 > VXLAN, yes? Exactly, the fabric is completely contained. >

Re: [j-nsp] EVPN/VXLAN experience

* Andrey Kostin [2019-03-22 16:16]: > One more question just came to mind: what routing protocol do you use for > underlay, eBGP/iBGP/IGP? Design guides show examples with eBGP but looks > like for deployment that's not very big ISIS could do everything needed. > What are pros and cons for BGP vs

[j-nsp] EVPN/VXLAN experience (was: EX4600 or QFX5110)

* Andrey Kostin [2019-03-15 20:50]: > I'm interested to hear about experience of running EVPN/VXLAN, particularly > with QFX10k as L3 gateway and QFX5k as spine/leaves. As per docs, it should > be immune to any single switch downtime, so might be a candidate to really > redundant design. All

Re: [j-nsp] MPC7E-MRATE - won't come online (enhanced-ip done)

* Aaron Gould [2018-12-18 16:16]: > Added a new MPC7E-MRATE to an MX960 today. it stays in "Present" mode under > "show chassis fpc" and will not come "Online". Any ideas ? Maybe a stupid question but did you turn it on? request chassis fpc slot x online Do you have enough power (high

Re: [j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

* Sebastian Wiesinger [2018-04-24 09:16]: > Hello, > > we've noticed problems with third party vendors QSFP 40G optics after > upgrading our JunOS on QFX5100. The problems manifest as a general > instablility on the QSFP links with symptoms like: So, we've got the information

Re: [j-nsp] Configuration database stuck with mgd crashing

* Phil Shafer [2018-09-01 20:28]: > "commit full" helps when daemons miss config changes (which they > shouldn't) or if you just want to say "because I said so", but it > needs a functioning database, provided by MGD. In this case, MGD > has corrupted the database (due to a software bug) and the

Re: [j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

* Jason Healy [2018-08-22 12:22]: > On Aug 22, 2018, at 4:52 AM, Sebastian Wiesinger > wrote: > > > > apparently there is now a PR for this: PR1309613 > > I realize you may not have the answers, but if you do... > > 1) Does this affect platforms other than th

Re: [j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

* Jared Mauch [2018-04-28 01:51]: > I’ve seen issues on QFX-5200 depending on the optics and cabling type. We’ve > had to set > FEC on the ports to none. This may also be a problem with the QSFP/QSFP+ > type optics. > The threshold was in going from 15.x -> 17.x, so it’s possible it showed up

Re: [j-nsp] L3VPN/RR/PE on Same router

* tim tiriche [2018-08-16 16:40]: > Hello, > > I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the > US. The other routers in the US are not RR and regular iBGP. This router > also acts as RR for Europe and takes in full BGP table. Is there some > caveats to watch out

Re: [j-nsp] Juniper vs Arista

* Saku Ytti [2018-08-14 10:31]: > On Tue, 14 Aug 2018 at 09:35, Mark Tinka wrote: > > > The Arista code is so Cisco-like, and in our use-case, has done > > everything as advertised in the manuals and in the "Arista Warrior" > > O'Reilly publication. So we haven't had to struggle... but then

Re: [j-nsp] Does QFX5100-24Q-2P support vxlan?

* Chen Jiang [2018-07-21 16:17]: > Hi! Experts > > Sorry for disturbing, I am building a EVPN/VXLAN test bed but found there > is no vxlan option under QFX5100-24Q-2P's vlans hierarchy: Can't speak for 17.2 but with 17.4 QFX5100-24Q have the vxlan option and it works just fine (with exception

Re: [j-nsp] MX480

* Vincent Bernat [2018-06-17 12:17]: > ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  : > > > 16.1R7 is a golden release. > > Is it already released? Not listed here: > https://www.juniper.net/support/downloads/?p=mx480#sw It's released now, backdated to the 15th, probably the build date.

Re: [j-nsp] Taking down VPLS unit with OAM CFM

* Pierre Emeriaud [2018-06-15 11:00]: > > is it possible to mark a VPLS site interface unit as down when OAM CFM > > signals a fault over that unit? > > It's possible. Try something like this: > > > root@lab-mx80-2# show protocols oam ethernet connectivity-fault-management > > action-profile

[j-nsp] Taking down VPLS unit with OAM CFM

Hi, is it possible to mark a VPLS site interface unit as down when OAM CFM signals a fault over that unit? Setup is like this: [MX][ae1.2000]---CPE---Switch >CFM MEP--> The CFM should take down ae1.2000 when the link between CPE and switch fails. Signaling works fine but the

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

* Olivier Benghozi [2018-05-29 18:38]: > I guess you have an explicit match for those routes in your VRF > export policy for the downstream VRF instance ? I don't know what you mean by "explicit match" exactly, but we have an vrf-export policy that matches these routes. Regards Sebastian --

Re: [j-nsp] MX104 updated x86 Route Engines

* Saku Ytti [2018-05-03 16:44]: > I still hope they'd make 1GE optimised platform. Like 2*QSFP28 + > 40*SFP+ then licensing for 1GE and sub use, and 10GE use, Yes please! But it seems higher speeds are more important right now... :( Regards Sebastian -- GPG Key: 0x93A0B9CE

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

* Brijesh Patel [2018-04-30 16:35]: > Hello Members, > > Any idea what is Difference between MPC4E-3D-32XGE-RB and > MPC4E-3D-32XGE-SFPP ? > > Juniper PDf says : > > MPC4E-3D-32XGE-SFPP 32x10GbE, full scale L2/L2.5 and *reduced scale L3 > features* > and >

Re: [j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

* Chris via juniper-nsp [2018-04-24 09:58]: > I can't keep switching firmware around to try and resolve this/isolate to a > specific revision, but it is interesting that you also note you have not > experienced any issues with 16.1, the same as us. If you get a proper

[j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

Hello, we've noticed problems with third party vendors QSFP 40G optics after upgrading our JunOS on QFX5100. The problems manifest as a general instablility on the QSFP links with symptoms like: * Links take minutes to come up * Links go down randomly * Links show CRC/Align errors and packets

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

* Vincent Bernat [2018-03-29 13:01]: > Here is the full output. There are two selected paths (and two > additional paths which are not used due to lower preference). > > vbe@net-connect001.gv2> show route 10.16.39.3 extensive > > inet.0: 236 destinations, 908 routes (236

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

* Vincent Bernat [2018-03-28 16:26]: > Hey! > > I am trying to setup a Juniper QFX5100 as a VTEP with a very classic > setup. Everything works as expected, but the setup is only using one > possible path from the underlay network. > > I have the route to the other VTEP like

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

Hi, we configured the workaround mentioned in KB20870 to prevent unwanted VPN BGP session flaps when configuring eBGP/route-reflector clients. A problem we noticed is that when using a Hub hub on the affected router and when a downstream hub is used as well, it seems that the downstream hub stops

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

* Olivier Benghozi [2017-09-26 12:42]: > Maybe > http://news.nationalgeographic.com/2017/09/sun-solar-flare-strongest-auroras-space-science/ > > > ? I was actually

[j-nsp] Sporadic LUCHIP IDMEM read errors

Hello, we're seeing sporadic LUCHIP IDMEM read errors like these (from two routers): fpc5 LUCHIP(0) IDMEM[112821] read error tfeb0 LUCHIP(0) IDMEM[303084] read error It is a single error and does not impact traffic in any measurable way for us. It appears to be random on different router

Re: [j-nsp] L2TP LNS on MX

* Nitzan Tzelniker [2017-09-15 15:18]: > You probably missing > S-MX80-SA-FP Which is funny because that's exactly what we requested for testing. Well then, seems Juniper gave us the wrong license for our tests. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3

[j-nsp] L2TP LNS on MX

Hello, I'm currently trying to set up a L2TP LNS on an MX80. I'm not getting very far and after debugging everything I'm suspecting a licensing issue. l2tp traceoptions says: Sep 15 14:20:51.268207 Process Request Sep 15 14:20:51.268246 SEQ RecvClientMsg:jl2tp-test-client session-id:5 Opcode:1,

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Dragan Jovicic [2017-05-04 14:30]: > To nitpick, policing is terminating (implicit accept for conforming > traffic), so you'd need "the next-term" to pass conforming traffic to next > term. Otherwise you'd pass 200m of ntp plus 1g of other traffic. > Cascaded policing: > >

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Dragan Jovicic [2017-05-04 14:30]: > To nitpick, policing is terminating (implicit accept for conforming > traffic), so you'd need "the next-term" to pass conforming traffic to next > term. Otherwise you'd pass 200m of ntp plus 1g of other traffic. > Cascaded policing: > >

Re: [j-nsp] reinject traffic from DDoS filtering device

* Alexander Dube [2017-05-04 11:55]: > Hello, > > i've a problem reinjecting filtered traffic from a anti ddos device > into our network. What we want to achive is, that traffic which > comes from our upstreams/peerings is redirected to a filtering > device. This is the

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Sebastian Wiesinger <sebast...@karotte.org> [2017-05-04 11:23]: > * "Rolf Hanßen" <n...@rhanssen.de> [2017-05-03 15:13]: > > But as long as the filter for family inet/inet6 is set, the logical > > interface filter is ignored for that family. > >

Re: [j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.

* Alain Hebert [2017-05-03 16:29]: > Hi, > > As for a bit before 14.1X53-D42.3 (sorry I do not have the exact > version) NSSU worked on the 6 members fab with 2 re, all QFX 5100. Okay, we have 15.1 at the moment. Do you not configure spanning-tree on your box or how

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* "Rolf Hanßen" [2017-05-03 15:13]: > But as long as the filter for family inet/inet6 is set, the logical > interface filter is ignored for that family. > If I remove the family filter, the logical interface filter is used. > > How do I combine that on a Juniper MX? You need

Re: [j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.

* Alain Hebert [2017-05-02 13:18]: > Hi, > > Beside Juniper, anyone have some successful experience to share about a > second source of QSFP+-40-LR4? > > All the optics tested from our usual rock solid providers ended up > flapping or spamming log message :( Hi,

Re: [j-nsp] bgp peer flapping

* adamv0...@netconsultings.com [2017-04-27 09:01]: > > Aaron Gould [mailto:aar...@gvtc.com] > > Wednesday, April 26, 2017 7:08 PM > > > > How often do we rename bgp group names ? I don't ever. Wondering if this > > is something that people do often. > > > Do you

Re: [j-nsp] bgp peer flapping

* james list [2017-04-26 17:55]: > Dear all > I’ve a question: is it correct from your point of view that if I change the > BGP group name on my MX the BGP peer inside the group goes to flap ? Yes that is "correct" for JunOS AFAIK. I think the reason was that the data

Re: [j-nsp] EX4550 - global or per-vlan mac table?

* Jeff [2016-08-22 10:45]: > Hello, > > does anyone know if the EX4550 has a real "per VLAN" mac table? I am asking > because we recently saw the router MAC changing from the switches uplink to > the customer's downlink in his vlan, most likely caused by a loop of some >

Re: [j-nsp] MX960 Power Options

* Chuck Anderson [2016-01-26 05:24]: > I recommend 4 x 208V. The MX960 uses "power zones" in a 2+2 > arrangement where half of the chassis is powered by 2 PEMs, and the > other half of the chassis is powered by the other 2 PEMs. Make sure > the 1st PEM for each zone is powered by

Re: [j-nsp] MX960 Power Options

* sth...@nethelp.no [2016-01-26 14:24]: > > > I recommend 4 x 208V. The MX960 uses "power zones" in a 2+2 > > > arrangement where half of the chassis is powered by 2 PEMs, and the > > > other half of the chassis is powered by the other 2 PEMs. Make sure > > > the 1st PEM for

[j-nsp] JNCIP-SP with JNCIE-SP Bootcamp preparation

Hello, I'm currently looking at the JNCIP-SP certification and after that eventually the JNCIE-SP exam. To prepare for JNCIP-SP I was told to just take the JNCIE-SP Bootcamp as this would prepare me for JNCIP-SP as well. On the other hand I heared from a few people that the bootcamp only

[j-nsp] MC-LAG Split-Brain detection

Hello, does anyone here know how *exactly* MC-LAG split-brain detection works in the event that one of the MC-LAG peers is down? For example when one of the MC-LAG peers does a software upgrade and is down the traffic is switched to the other peer. How does JunOS distinguish this from a

Re: [j-nsp] Adding IRB to VPLS

* Cydon Satyr cydonsa...@gmail.com [2015-06-12 15:03]: I am trying to configure what Cisco would call a routed pseudowire. I'm trying to do this by configuring bridge-domain with irb, and using that irb in VPLS instance (and vrf instance), like this: routing-instances { vpls-red { [..]

Re: [j-nsp] Adding IRB to VPLS

* Cydon Satyr cydonsa...@gmail.com [2015-06-12 15:33]: Also what's the point of connection-type irb then? It keeps the VPLS connection up even when all the physical interfaces are down so that your irb is still online. If you don't have this the IRB would go down as soon as all physical ports

Re: [j-nsp] Adding IRB to VPLS

* Cydon Satyr cydonsa...@gmail.com [2015-06-12 15:21]: That makes perfect sense... But why are there examples with only irb interfaces in vpls? If you have no physical ports than you can have only an IRB on the router. Also, your examples requires that IFL have vlan-vpls encap, whereas in my

Re: [j-nsp] EVPN

* Chuck Anderson c...@wpi.edu [2015-05-05 16:51]: On Fri, May 01, 2015 at 05:53:54PM -0400, Chuck Anderson wrote: Is anyone doing EVPN in production yet? I take it from the deafening silence that either no one is doing EVPN in production, or no one is willing to admit it. Is anyone

Re: [j-nsp] Thoughts on MX80 v MX104 RE performance

* Saku Ytti s...@ytti.fi [2015-04-22 17:03]: I think that we will see an Intel CPU based RE on MX104 in the future. It just doesn't make sense to have one PPC platform for which custom code must be written. The MX80 will probably go EOL in that case. Juniper has tons of non-intels, most

Re: [j-nsp] Thoughts on MX80 v MX104 RE performance

* Mike Williams mike.willi...@comodo.com [2015-04-20 16:42]: Hey all, There was a discussion May last year about the MX104 and BGP performance. With the take away being that the MX104 RE is still pretty weak, at least compared to the modern x86 REs fitted to some of the bigger models. The

Re: [j-nsp] About RD in vpls multi-homing environment.

* Pyxis LX pyxi...@gmail.com [2015-04-11 20:21]: And I found another configuration example on Juniper website: http://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/vpls-bgp-multihoming.html This example suggests that PE1 and PE2 should use different RDs. That link already

[j-nsp] What in deity's name does export-rib do and will I ever need it?

Hello, I'm just doing some lab experiments with rib-groups and importing BGP routes from inet.0 into VRFs. Ever so often export-rib shows up in discussions/documentation. I wanted to read about this elusive config option and now I'm about to throw the towel and just ignore it. I think I now read

Re: [j-nsp] DDOS_PROTOCOL_VIOLATION_SET: Protocol Reject:aggregate

* Brendan Mannella bmanne...@teraswitch.com [2014-12-10 23:18]: Just wondering if anyone has ever seen these DDOS messages before and what i should be looking at to resolve. Dec 10 11:10:24 re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned to

[j-nsp] Counters for Storm-Control on EX switches?

Hello, are there any counters showing how many packets are dropped by storm control on a Juniper EX? It doesn't show up in dropped packets, only produces a (not very informative) syslog message. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are

Re: [j-nsp] Juniper MX Upgrade / Configuration question

* Haynes, Matthew mhay...@lightower.com [2014-10-14 17:03]: Hi All, I was wondering if anyone knows where a MX router stores the boot configuration its going to use after you load a new version of code on the router. I have verified that its not using /config/juniper.conf.gz when its

Re: [j-nsp] MX80 Sampling - High CPU

* Graham Brown juniper-...@grahambrown.info [2014-09-23 22:33]: 12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think there are many people waiting for these two releases... So, 12.3R8 is out. Any practical experiences if inline jflow / sampling is faster now? Regards

Re: [j-nsp] MX80 Sampling - High CPU

* Brendan Mannella bmanne...@teraswitch.com [2014-10-01 13:12]: We have a mx240 with inline flow enable, we were getting frequent cpu spikes, we installed 12.3R8 yesterday and the spikes are resolved. Interesting, do you also monitor route propagation from RIB to FIB (via 'show krt state' or

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

* Olivier Benghozi olivier.bengh...@wifirst.fr [2014-08-23 20:09]: Maybe you should wait. In 12.3R6 and before you can hit PR593444. But in 12.3R7 you will hit PR671136. PR671136 is fixed in 12.3R7-S2 at least. Other than that I'm really waiting for 14.2 to see if they did manage to fix

[j-nsp] Drawbacks when using QFX5100 and EX4300 in mixed VCF mode

Hello, Juniper supports mixing QFX5100 and EX4300 in a Virtual Chassis Fabric mixed mode but they talk about some vague performance and/or impact when doing so: --- Hardware Requirements for a Virtual Chassis Fabric A VCF can

Re: [j-nsp] Drawbacks when using QFX5100 and EX4300 in mixed VCF mode

* Sebastian Wiesinger juniper-...@ml.karotte.org [2014-08-19 17:51]: Hello, Juniper supports mixing QFX5100 and EX4300 in a Virtual Chassis Fabric mixed mode but they talk about some vague performance and/or impact when doing so: Aaand after I sent this, I get the link to a page listing

Re: [j-nsp] MX80 stops forwarding after enabling inline flow sampling

* Scott Granados sc...@granados-llc.net [2014-07-15 16:36]: I found more to bring this thread home. The problem I had was covered in PR963060. We discovered this problem a long time ago and there are already 1-2 threads on this ML where this has happend. Took Juniper some time to even

Re: [j-nsp] Viability of EX4300 in a primarily l3 environment?

* Paul S. cont...@winterei.se [2014-08-02 05:18]: Hi folks, We're considering the EX4300 to run routing (l3) for a few hypervisors of ours that are connected via l2. Primarily interested due to the rather massive arp limit (64, 000) on the switch, but we've been told (and searched for

Re: [j-nsp] mx240 - chassisd process takes whole cpu

* Piotr piotr.1...@interia.pl [2014-06-20 00:36]: Hi, Since 13:50 i have very high cpu on routing engine, router doesn't answer for some snmp request (re cpu, interface counters are ok) but besides this, looks good - router pass traffic. It looks like problem with chassisd process ( nanslp

[j-nsp] Opportunistic ARP on Juniper MX?

Hello, does anyone know if Juniper MX does opportunistic ARP? Meaning, will it send out an ARP request by itself when an ARP entry expires (like Cisco does) or will it wait until it needs to resolve the ARP entry when a packet arrives? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B

Re: [j-nsp] Opportunistic ARP on Juniper MX?

* Mark Tinka mark.ti...@seacom.mu [2014-05-26 09:18]: On Monday, May 26, 2014 09:10:20 AM Sebastian Wiesinger wrote: does anyone know if Juniper MX does opportunistic ARP? Meaning, will it send out an ARP request by itself when an ARP entry expires (like Cisco does) or will it wait

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

* Phil Mayers p.may...@imperial.ac.uk [2014-03-05 19:12]: Chris, can you elaborate on why low TTL on multicast frames will cause high CPU? Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit the CPU, but so will a few other ranges that fall into the Link-Local There's no

Re: [j-nsp] router-jockeys and gui tools

* Phil Shafer p...@juniper.net [2014-03-05 19:36]: [hijacking part of a thread from Keegan] Keegan Holley writes: My gut says this is as much a product of Space being new as the general skeptcisim most router-jockeys have towards GUI/WebUI based management tools. As the on-box CLI

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

* Clarke Morledge chm...@wm.edu [2014-03-06 16:42]: Sebastian, No, you are not alone on this issue. For a little more context, I have seen the same type of behavior associated with Apple Bonjour traffic related to Multicast DNS reported on this thread in November, 2013:

Re: [j-nsp] proposed changes to clear bgp neighbor

* Phil Shafer p...@juniper.net [2014-02-26 16:42]: Juniper users, We've been asked to make a change the clear bgp neighbor command to make the neighbor or all argument mandatory. The root cause is the severe impact of clear bgp neighbor and the increasing accidental use of this command

[j-nsp] Multicast/Broadcast Packets going to EX CPU

Hello, I'm currently looking at an EX4500 setup that had a few problems related to multicast/broadcast packets going to the CPU (and sometimes preventing required packets like LACP reaching the CPU) of the switch. I assume this was because the queue between PFE and CPU was full (is there a way to

Re: [j-nsp] Enabling SSL support for JunosScript invocation

* Saku Ytti s...@ytti.fi [2013-12-02 15:54]: On (2013-12-02 09:17 -0500), Phil Shafer wrote: JUNOS uses the fetch app under the covers, which lacks HTTPS support. We're moving to curl, which does. I don't have an ETA on this support. I believe the problem is, domestic incorrectly

[j-nsp] MACsec on EX switches

Hello, has anyone here experience with MACsec on EX switches (4550/4200)? Especially performance, caveats, problems with the required JunOS software (JunOS Controlled)? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE

[j-nsp] PCI ERROR when inserting MX-MPC1E-3D in MX960

Hello, I tried to take a MX-MPC1E-3D FPC online in a MX960 chassis in the lab. This produced PCI errors like this: Oct 10 13:38:41 /kernel: pic_listener_connect: conn established: mgmt addr=0x1b80, Oct 10 13:38:42 fpc11 CLKSYNC: master RE connection made Oct 10 13:38:42 fpc11

[j-nsp] AE loadbalancing with Ethernet CCC over L2VPN

Hello, I have the following setup: [CE] == AE(2 links) == [MX80] --- L2VPN --- [MX80] == AE(2 links) == [CE] The problem is that the MX80s both only send outgoing traffic to the CE on one link of the AE bundle. There is no hash-key/enhanced-hash-key configured on the boxes. The configuration

[j-nsp] IPv6 VRRP packets dropped?

Hello, I have two MX routers with a VPLS instance. The instance has an irb interface on both routers with IPv6 VRRP configured on it. On the backup router I see the VRRP mastership flap every few seconds. When I look at VRRP statistics I see that it receives much less packets than the other

Re: [j-nsp] Config archive subtleties

* Ben Dale bd...@comlinx.com.au [2013-08-08 02:00]: I haven't use this in anger for a while, so apologies if some of this functionality is already available, but how about: - an option to disable compression of the config file - an option to specify the naming convention used - eg: always

[j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

So, it's friday and there is PSN-2013-08-987. Am I overlooking something or is that only a problem for people who speak OSPF with other parties (customers, strangers,...)? I don't see the big attack vector in comparison to speaking OSPF with others in the first place... Regards Sebastian --

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

* Cheikh-Moussa, Ahmad a...@axians.de [2013-08-02 11:03]: Hi Sebastian, it depends on the environment. On a PtP interface it is not an issue, on a broadcast network, it could be an issue. In general, it is always recommended to turn authentication ( md5) on and protect the RE with a lo0

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

* Chris Morrow morr...@ops-netman.net [2013-08-02 11:12]: On 08/02/2013 04:26 AM, Sebastian Wiesinger wrote: So, it's friday and there is PSN-2013-08-987. Am I overlooking something or is that only a problem for people who speak OSPF with other parties (customers, strangers,...)? I

Re: [j-nsp] flow sampling: what packets are chosen?

* sth...@nethelp.no sth...@nethelp.no [2013-07-25 01:21]: When using inline IPFIX the only valid rate is 1. The option run-length isn't configurable, because there's no need to sample data from the perspective of the microcode in the Trio Lookup Block. Every packet will be inspected and

Re: [j-nsp] Can I do dumb Q-in-Q switching on Juniper MX?

* Sebastian Wiesinger juniper-...@ml.karotte.org [2013-07-01 12:11]: Hello, I need to do a sort of dumb Q-in-Q on a MX box. What I want from the MX is: Hello, a follow up to my question. We decided to do MPLS CCC (as we have a MPLS enabled core). It works just fine with RSVP. I'll send

[j-nsp] Can I do dumb Q-in-Q switching on Juniper MX?

Hello, I need to do a sort of dumb Q-in-Q on a MX box. What I want from the MX is: Take alle VLAN tagged frames on an Port (CE-facing) and switch them to another interface (Core-Facing). On the core-facing interface push VLAN 42 on the frames (Q-in-Q). When frames arrive on the core-facing IF,

Re: [j-nsp] KRT queue stalls fixed in 11.4R8?

* Grzegorz Janoszka grzeg...@janoszka.pl [2013-06-24 21:57]: On 24-06-13 21:07, Rob Foehl wrote: According to the release notes for 11.4R8, the KRT queue stall issue (PR836197) has been marked as resolved. Has anyone had a chance to confirm this on a suitably session-heavy MX? You still

Re: [j-nsp] BOOTP helper on MX vrf

* Saku Ytti s...@ytti.fi [2013-06-14 09:51]: Another problem with DHCP-relay is that, AFAIK, it causes _all_ dhcp packets in every interface to be punted. So some transit DHCP packet jetting through your router in unrelated interface gets punted. I find this most unsatisfactory, but of course

[j-nsp] BOOTP helper on MX vrf

Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality).

Re: [j-nsp] BOOTP helper on MX vrf

* Mark Tinka mark.ti...@seacom.mu [2013-06-13 13:24]: On Thursday, June 13, 2013 01:03:04 PM Sebastian Wiesinger wrote: So any information regarding this is appreciated. This was my working configuration on an MX480 running Junos 10.4: routing-instances { SOME-VRF-NAME

[j-nsp] RPD queue stall, RIB/FIB programming time fixed in 11.4R8?

Hello, reading PR836197 and KB26792, it seems that the RPD queue starving/stalling was improved (even fixed?) in 11.4R8, 12.1X45-D10, 13.1R1 and 13.2R1. To quote from the KB: | Starving jobs are now added to a FIFO (first in-first out) queue. This | guarantees that a starving job is always

Re: [j-nsp] experience using 10G DAC (twinax) cables between EX and multi-vendor

* Andy Litzinger andy.litzin...@theplatform.com [2013-05-15 21:00]: Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor gear? Did you use Juniper DAC cables or the other vendor cables? In particular I'm planning on linking a Cisco UCS Fabric Interconnect and also an

  1   2   >