Re: [j-nsp] 6pe between Cisco and Juniper

Maybe you could try to configure next-hop-self on the Cisco's side, on all AFI? Le 4 sept. 2012 à 13:12, Mihai Gabriel a écrit : > You are partially right. The bgp session is established without > inet6-unicast capability advertised by Juniper, but as soon as Juniper > receives an ipv6 prefix wit

Re: [j-nsp] 6pe between Cisco and Juniper

of an IPv4+label NH, could be the source of your problem ? In those conditions, maybe a generalized next-hop-self in your whole iBGP could be fine? Just thinking aloud, but it could make sense. > and move all the traffic through RR? :) > > On Tue, Sep 4, 2012 at 4:47 PM, Olivier Beng

Re: [j-nsp] MX80 no more hash-key option in 12.2?

Hi Paul, I had previously (like you) the hash-key stuff configured on some MX80 gear, and removed it after reading David Roy's answer. I can confirm that the removal of this stuff left the tfeb in a strange state (running 11.4R5), with some funny logs at the commit (tfeb0 jnh_loadbalance_hashk

Re: [j-nsp] auto-negotiation on 1000BASE-X ports

1000Base-X can negotiate flow control. But, an interesting part of autoneg is Remote Fault Notification: one of the fibers in your 2 fibers link breaks, and the link becomes unidirectional; the side that sees its receiving fiber down sends a frame to notify the other side (which didn't see anyt

Re: [j-nsp] auto-negotiation on 1000BASE-X ports

Hi Martin, > by flow control you mean the 'regular' Ethernet flow control using the > PAUSE frame mechanism? Yes: the peers can negotiate its use, and in what direction. In that case, such explicit flow control replaces the old school "Back pressure" mechanism (a switch can send a fake ethernet

Re: [j-nsp] auto-negotiation on 1000BASE-X ports

> Either it's not working or I am doing it wrong.. Or maybe it has nothing to do with the name of the command? It's just clear to me that the behavior can not be deducted from the documentation (that doesn't say anything useful about this), so I'm afraid it would be necessary to ask to a presal

Re: [j-nsp] Internet access from VRF issue

Hi Alexey, I understand that you receive an iBGP route, place it in another VRF via rib-group, and expect it to be sent to another iBGP peer. Well, basically you expect a received iBGP route to be reflected to another iBGP peer ? regards, Olivier Benghozi Le 4 juin 2013 à 18:12, Alexey a

Re: [j-nsp] ISIS authentication issue

course ? -- regards, Olivier Benghozi Le 12 juin 2013 à 17:08, John Neiberger a écrit : > We've got an MX960 connected to a Cisco CRS, both of which are configured > for ISIS authentication. However, the CRS is currently configured for only > hello authentication. It appears that

Re: [j-nsp] Correct config for SRX port channel -> Cisco

Hi Phil, what is the Cisco model & IOS? Did you create the vlan in the vlan database in your Cisco switch? :) Maybe try switchport nonegotiate... Le 24 juil. 2013 à 17:39, Phil Mayers a écrit : > On 24/07/13 16:07, Phil Mayers wrote: >> On 24/07/13 15:48, Stacy W. Smith wrote: >>> In general

Re: [j-nsp] NTP Reflection

But due to another ridiculous way of implementing that, the Juniper KB article suggests to also allow: ; and not only your favorite ntp servers... Because if you don't do it, you'll obtain some nice "Server Timeout" if you want to issue a "show ntp status" or "show ntp associations". So: - Junos

Re: [j-nsp] move routes from VRF to inet.0

Hi Mike, also what we do here. However, that was not that easy, we observed that a discard route imported to another vrf via auto-export on the same box was imported with its next-hop, that is... discard, instead of triggering an additional lookup in the internet table (what we use on some Eri

Re: [j-nsp] OSPF external routes

You're redistributing eBGP to OSPF. Received OSPF routes from the other ASBR will be inserted in the RIB with preference 150. Received eBGP routes will be inserted in the RIB with preference 170. So OSPF will always be preferred over BGP routes unless you change the preference via an import pol

Re: [j-nsp] OSPF external routes

You can match them in an import policy from ebgp to the rib with a lower pref to prefer them by example. A better option would be to have a clean ibgp between your routers (mounted on loopbacks), to avoid redistributing ebgp to ospf, to keep only intercos & loopbacks in ospf, and to deal only w

Re: [j-nsp] filter-based forwarding... struggling

You have to add: set firewall filter FLEET-NAT term else-nat then accept By the way in 12.2R2 and later you can as well drop all this rib-group+forwarding instance stuff, and just replace "then routing-instance nat-vrf" by "then next-ip 10.1.0.51" in your firewall filter, as in a PBR Cisco lik

Re: [j-nsp] filter-based forwarding... struggling

it doesn't appear that next-ip is available on the EX platform; i'm running > 12.3R3.4 and that doesn't show up. > > also, setting "term else-nat then accept" ends up removing "term else-nat > then routing-instance nat-vrf". i don't believe you

Re: [j-nsp] Verifying Juniper ECMP

Hi John, as usual with Juniper it's ridiculously overcomplicated, David Roy wrote a fine article about that, at least for MX with DPC: http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html Olivier Le 15 avr. 2014 à 04:01, John Neiberger a écrit : > ​I kn

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

Hi Clarke, Are you using some MX80 routers ? :) regards, Olivier Benghozi Wifirst > In testing the design, my advertisements going out get updated almost > immediately with my upstream provider, per looking at their looking glass > during a "fiber cut." But on my end, eve

Re: [j-nsp] 12.1X47 only supports 2GB ram devices

Hi Michael, yes, we also have some SRX240H, and according to http://www.juniper.net/support/eol/srxseries_hw.html & http://www.juniper.net/support/eol/junos.html#3 , it's clear that for such models (and the other ones no longer sold), the release train 12.1X46 will be the last one (and support

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

Maybe you should wait. In 12.3R6 and before you can hit PR593444. But in 12.3R7 you will hit PR671136. Maybe in 12.3R8 it will "just" be slow, who knows... Olivier Le 22 août 2014 à 15:26, Justin M. Streiner a écrit : > Convergence with multiple full feeds (IPv4 and IPv6) is good if I disabl

Re: [j-nsp] SRX240 Multicast

quick and dirty test, I guess you might use the IP from the layer 3 interface vlan.100, without loopback, and it might do the trick. You didn't precise this but I also assume that the receiver is sending IGMP Joins :) regards, Olivier Benghozi Wifirst Le 28 août 2014 à 02:07, Keith a écri

Re: [j-nsp] Cosmetic bug? - mx80 12.2r7.7

Hi Darren, do you have inline sampling/Jflow/IPFIX configured ? If so, you may hit PR671136. Olivier Le 4 sept. 2014 à 14:02, Darren O'Connor a écrit : > Yes my bad. 12.3R7.7 > > Still shows the same. No issues forwarding traffic: > > root@mx80> show chassis tfeb > TFEB status: > Slot 0 info

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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] MPC3E oversubscribe rate with two 10x10GE MICs

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 capacity. > > But the devil was in how that capcity is shared bet

Re: [j-nsp] Export Inactive BGP routes with the best route is a BGP Route.

Hi, Can you describe what you would do on IOS ? It will be clearer I guess. regards, Olivier > 15 déc. 2014 at 23:22, Gustavo Santos wrote : > > Hi, > > I have a customer that needs to receive all routes from one of our transit > suppliers. The problem is after some research the Junos don´t

Re: [j-nsp] Question about 100 Gbps MPC4E

Hi all, But if you read the documentation again, you see that vlan-steering and sa-multicast are only workarounds to balance traffic going through old 100-Gigabit Ethernet type 4 PIC model number PD-1CE-CFP-FPC4 (T-series interface), which was designed with two 50Gb/s PFE, unlike more modern PI

Re: [j-nsp] IS-IS not installing route into RIB

Hi, Distance & path vector protocols (RIP, BGP) directly use RIB in JunOS as storage for the routes (unlike Cisco, where there's a BGP table before the RIB by example). In link-state protocols there's nothing such as a "route", only link-state information stored in a separate database, whose in

Re: [j-nsp] IS-IS not installing route into RIB

stalling > route in inet.0 table presents a problem as BGP route is preferred. > > Regards > > > On Fri, Feb 6, 2015 at 12:21 PM, Olivier Benghozi > mailto:olivier.bengh...@wifirst.fr>> wrote: > Hi, > > Distance & path vector protocols (RIP, BGP) directl

Re: [j-nsp] IS-IS not installing route into RIB

Damn, if no one has a clue I guess we're condemned to wait for your JTAC results... > Le 6 févr. 2015 à 14:08, Dragan Jovicic a écrit : > > Hi, > > Yes, exactly like that, with route-filter specifying a prefix. > > Regards > > On Fri, Feb 6, 2

Re: [j-nsp] Helo Juniper, your docs need work..

By the way in current JunOS 12.3 it looks there's at least one fix; in: http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html they w

Re: [j-nsp] Helo Juniper, your docs need work..

Well, they write in http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/firewall-filter-ex-series-match-conditions-support.html#jd0e2022

Re: [j-nsp] Problem with ether-type changing on QFX3500 VC

Hi Andrew, according to http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/getting-started-els.html you have to use some ether-options ethernet-switch-profile tag-protocol-

Re: [j-nsp] solution to a firewall question

Replace accept with next term in f1 ? next term works across filter list from what I see and according to the documentation ( http://www.juniper.net/documentation/en_US/junos13.3/topics/concept/firewall-filter-option-multiple-listed-overview.html

Re: [j-nsp] solution to a firewall question

this and come back. Thanks for solution. > > -Thanks, > VIjesh > > > From: Damien DeVille > Sent: Thursday, April 23, 2015 5:54 PM > To: Vijesh Chandran > Cc: Olivier Benghozi; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] solution to a firewall question >

Re: [j-nsp] JTAC Recommended Junos Software Versions Old?

MX104 is not supported in 12.3, it's that simple (13.2 minimum). And about features, MX104 is on par with other MX only in 13.3 anyway. Not very different on newer PTX chassis. > Le 30 avr. 2015 à 08:18, Mark Tinka a écrit : > > On 29/Apr/15 18:58, Colton Conor wrote: >> >> I notice that the

Re: [j-nsp] JTAC Recommended Junos Software Versions Old?

About memory leak on PFE with inline jflow, this is PR1071289, affected releases 13.3R5, 14.1R4, 14.2R1. > 1 mai 2015 at 20:44, Mark Tinka wrote : > > We are running 14.2R1 on MX80 and MX480. > > I see alot of people complaining about Netflow, but we haven't had any > issues on either platform

Re: [j-nsp] MX80 upgrade caveats

Anyway, why would anyone use 14.1 on MX80? I guess the choice would be between either 13.3R6 or 14.2R3 (once released); but 14.1 ? > Le 8 mai 2015 à 07:44, Per Granath a écrit : > > http://www.juniper.net/techpubs/en_US/junos14.1/information-products/topic-collections/release-notes/14.1/index.h

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

In 15 for Intel based RE, but for MX80 PowerPC, not sure if the second core will ever be supported... > Le 8 mai 2015 à 16:17, Arie Vayner a écrit : > > It's coming in 15 > On May 8, 2015 7:13 AM, "Colton Conor" wrote: > >> Has juniper implemented the use of multicore processors in their soft

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

http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html "Statement introduced in Junos OS Re

Re: [j-nsp] disable “soft-reconf-inbound”

set keep none > Le 17 juin 2015 à 12:56, Adam Vitkovsky a écrit : > > Hi folks, > > Is it possible to disable the default “soft-reconf-inbound” kind of thing in > Junos please? > Or is the RT based ORF between PEs and RRs the only option if one does not > want to keep the unmodified copy of A

Re: [j-nsp] disable “soft-reconf-inbound”

http://www.juniper.net/techpubs/en_US/junos13.3/information-products/topic-collections/release-notes/13.3/index.html?topic-76113.html "Starting in Junos OS Rele

Re: [j-nsp] MX104 Limitations

You meant: In MX80/104, where fabric should sit, you have 4 integrated 10GE ports. > 25 june 2015 @ 13:10, Saku Ytti wrote : > > Only difference is, that MPC 'wastes' 50% of capacity for fabric, and > MX104/MX80 spend this capacity for additional ports. (In MX80 where fabric > should sit, you h

Re: [j-nsp] MX104 Limitations

ti wrote : > > On (2015-06-25 13:14 +0200), Olivier Benghozi wrote: > > Hey Olivier, > >> You meant: In MX80/104, where fabric should sit, you have 4 integrated 10GE >> ports. > > This is common misconception. People think the chassis ports are magical, > bec

[j-nsp] L2VPN between Juniper MX and SmartEdge

Hi guys, any clue about interoperability issue between Juniper (some MX in JunOS 13.3R5, MPC cards) and Redback (SE600, SEOS 12.1.1.9, PPA3 20x1GE card) about L2VPN pseudowire, Martini style (using LDP signaling and LDP LSP) ? I'm trying to use such feature to forward a vlan between some equipm

Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

/MPLS NOC engineer - Orange France > Ph. : +33 2 99 28 57 66 > Mob. : +33 6 85 52 22 13 > SkypeID : davidroy.35 > david@orange.com > > JNCIE x3 (SP #703 ; ENT #305 ; SEC #144) > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck

Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

28 57 66 > Mob. : +33 6 85 52 22 13 > SkypeID : davidroy.35 > david@orange.com > > JNCIE x3 (SP #703 ; ENT #305 ; SEC #144) > > > -Original Message- > From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr] > Sent: jeudi 9 juillet 2015 23:26 > To: RO

Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

help, though :) > Le 10 juil. 2015 à 15:26, Olivier Benghozi a > écrit : > > Thanks David; > > how was configured the port or lag itself on the SE side? Between encap rw, > transport, or whatever, I don't have much success. > > thank, > Olivier &g

Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

; > On Thu, Jul 16, 2015 at 9:44 AM, Olivier Benghozi > wrote: >> OK, found the problem in my config that prevented the stuff to just work. >> >> One does not simply walk into new JunOS fancy features. >> Conclusion is that the only piece of code behin

Re: [j-nsp] JCare Differences

Right, but you have a one year warranty on MX stuff (return to factory). However depending of your needs you may want to have a nextday delivery or buy some spare... > Le 16 sept. 2015 à 14:33, Josh Baird a écrit : > > Hi, > > Mostly new to the Juniper world, and I'm a bit confused about JCa

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

Not hit by PR1101080 (When polling SNMP OID isisPacketCounterTable 1.3.6.1.2.1.138.1.5.3, the rpd process might crash) ? > Le 24 sept. 2015 à 15:42, Mark Tinka a écrit : > > > > On 24/Sep/15 15:36, Adam Vitkovsky wrote: > >> I suspect you are using the new MPCs right? > > Yes, we're on the

  1   2   >