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 with

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 Benghozi olivier.bengh

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

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

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

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

Re: [j-nsp] ISIS authentication issue

, of course ? -- regards, Olivier Benghozi Le 12 juin 2013 à 17:08, John Neiberger jneiber...@gmail.com 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

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 p.may...@imperial.ac.uk a écrit : On 24/07/13 16:07, Phil Mayers wrote: On 24/07/13 15:48, Stacy W. Smith

Re: [j-nsp] NTP Reflection

But due to another ridiculous way of implementing that, the Juniper KB article suggests to also allow: router-loopback-address; 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

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

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

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 like

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

-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 can have both. thx ryan On Sat, Feb 15, 2014 at 6:30 PM, Olivier Benghozi

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

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, even though BGP starts

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 strei...@cluebyfour.org a écrit : Convergence with multiple full feeds (IPv4 and

Re: [j-nsp] SRX240 Multicast

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 kwo...@citywest.ca a écrit : Hi

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 darre...@outlook.com a écrit : Yes my bad. 12.3R7.7 Still shows the same. No issues forwarding traffic: root@mx80 show chassis tfeb TFEB status:

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 t...@snnap.net wrote : As was explained to me a while back, the MPC3E has ~120gbit of capacity. But the devil was in how that capcity is

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 gustkil...@gmail.com wrote : Hi, I have a customer that needs to receive all routes from one of our transit suppliers. The problem is after some research

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

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

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 dragan...@gmail.com a écrit : Hi, Yes, exactly like that, with route-filter specifying a prefix. Regards On Fri, Feb 6, 2015 at 1:55 PM, Olivier Benghozi

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

route is preferred. Regards On Fri, Feb 6, 2015 at 12:21 PM, Olivier Benghozi olivier.bengh...@wifirst.fr mailto:olivier.bengh...@wifirst.fr wrote: Hi, Distance path vector protocols (RIP, BGP) directly use RIB in JunOS as storage for the routes (unlike Cisco, where there's a BGP

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 http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html they

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 http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/firewall-filter-ex-series-match-conditions-support.html#jd0e2022

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

. -Thanks, VIjesh From: Damien DeVille damien.devi...@gmail.com 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 You are correct -- I misread the documentation. I think

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 mark.ti...@seacom.mu a écrit : On 29/Apr/15 18:58, Colton Conor wrote: I

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 mark.ti...@seacom.mu 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

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 per.gran...@gcc.com.cy a écrit :

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 ar...@vayner.net a écrit : It's coming in 15 On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote: Has juniper implemented the use of

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 http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html Statement introduced in Junos OS

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

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 s...@ytti.fi 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

Re: [j-nsp] MX104 Limitations

: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, because they don't support QX QoS. But the chassis ports are actually on the WAN

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

set keep none Le 17 juin 2015 à 12:56, Adam Vitkovsky adam.vitkov...@gamma.co.uk 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

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

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

help, though :) Le 10 juil. 2015 à 15:26, Olivier Benghozi olivier.bengh...@wifirst.fr 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 Le 10 juil. 2015 à 12:00

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

:44 AM, Olivier Benghozi olivier.bengh...@wifirst.fr 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 behind the chained composite next-hop ingress for l2ckt

Re: [j-nsp] Limit on interfaces in bundle

max 64 ports per LAG: http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/maximum-links-edit-chassis-.html There's also a

Re: [j-nsp] how to leak aggregate/generated routes while modifying next-hop

t.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 0.0.0.0/0 (1 entry, 1 announced) *Static Preference: 5 Next hop: Next table: internet.inet.0 Next-hop reference count: 8 State: Probably other methods may be simp

Re: [j-nsp] how to leak aggregate/generated routes while modifying next-hop

Hi Adam, > Le 17 nov. 2015 à 16:07, Adam Vitkovsky a écrit : > > Hi Oliver, > > I see, but if you manually created a static route with the correct next-table > in the special/dedicated "aggregate" VRF, wouldn’t it be then easier to just > manually create the

Re: [j-nsp] EX4550: LACP channels short lost after commit

ckets fast? > > - since slow means longer conversion times: will a link down event still wait > for the channel member to timeout or will this be handled as an instant > member failure? > > > Thanks! > > Jeff > > Am 30.10.2015 um 15:05 schrieb Olivier Benghozi: >&

Re: [j-nsp] EX4550: LACP channels short lost after commit

Infamous LAG LACP flap... I think there are several factors: crappy Junos code, LACP is CPU managed (at least on EX), so a pike in CPU (or a latency in the dedicated process) can break LAGs (make them flap in fact). I had some similar issues with SRX code. Go for slow LACP rate (30 seconds

Re: [j-nsp] understand "request system software rollback" in Junos

Maybe it can be used before reboot - during which the real install process takes place (but I guess that request delete jinstall does also that). What is clear is that the doc is crappy as usual. > Le 16 oct. 2015 à 13:53, Martin T a écrit : > > Markus, > > I have jbundle

Re: [j-nsp] MPC2E vs MPC2E NG

From what I know, "NG" only means "same features than before but with added memory for Flexible Queuing Option feature (with additional license)". This one: http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/flexible-queueing-mode-overview.html

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

#703 ; ENT #305 ; SEC #144) -Original Message- From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr] Sent: jeudi 9 juillet 2015 23:26 To: ROY David DTSI/DERS Cc: redback-...@puck.nether.net; juniper-nsp Subject: Re: [j-nsp] L2VPN between Juniper MX and SmartEdge Hi David

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

david@orange.com JNCIE x3 (SP #703 ; ENT #305 ; SEC #144) -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Olivier Benghozi Sent: jeudi 9 juillet 2015 22:07 To: redback-...@puck.nether.net; juniper-nsp Subject: [j-nsp] L2VPN

[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

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

Re: [j-nsp] understand "request system software rollback" in Junos

http://www.juniper.net/techpubs/en_US/junos13.3/information-products/topic-collections/release-notes/13.3/topic-83364.html#rn-downgrade "To downgrade from

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

to use multiple cores? Do you think the >> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the >> MX240/480 have one or 2 cores? >> > > I have heard that this is planned for Junos 15. > > -Phil >>> On Mon, May 11, 2015 at 7:04

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?

Re: [j-nsp] MTU on switch interfaces

That's correct, but normally the port default MTU is set automagically when you change the trunk/access mode. > Le 19 déc. 2015 à 09:21, Tom Storey a écrit : > > But would that be +14 assuming no VLAN headers, +18 assuming 1 VLAN > header, +22 assuming q-in-q ? > > Was always

Re: [j-nsp] Suggestions on management of dual-RE devices

Juniper document provides each RE with it's own MANAGEMENT address (on fxp port of each RE), not its own loopback. You configure a single loopback (interface lo0.0). Anyway, about your need, there is:

Re: [j-nsp] RR and VPN on PE L3VPN

Hi Tim, About sessions flaps: Yes, other i-MP-BGP will flap on PE1 once the group with cluster-id configured has a first established neighbor (and will also flap once the last established neighbor goes down in this group). The solution documented in the link you wrote works (a passive pseudo

Re: [j-nsp] force-64bit

This is not completely contradictory with the Juniper doc ; as usual with the Juniper doc written with feet, you have to read between the lines: -> Written in the doc: "Tip: You need not restart the routing protocol process (rpd) to use the 64-bit mode" -> To be understood: "Joke: You need not

Re: [j-nsp] syslog is flooded with curious messages (MX5 / 14.2R2.8)

14.2R5, had frequent /kernel: hw.chassis.startup_time update to 1449495334.808647 messages. I just did something like set sytem syslog file messages kernel warning to drop them... > Le 22 janv. 2016 à 12:12, Eduardo Schoedler a écrit : > > Same problem here... > > Jan 22

Re: [j-nsp] Enable EVPN on existing mpls l3vpn network

> 19 feb 2016 at 00:02, Chuck Anderson wrote : > >> recommended 13.3R8 code. I read NSR is not supported for EVPN. If i >> enable family evpn signalling will NSR be supported for existing l3vpn >> functionality? > > Yes. No. But there's a workaround: > Yes, the BGP session

Re: [j-nsp] Optimizing the FIB on MX

I think that this recommandation makes sense: I don't see any good reason to have, by default, eBGP routes with a better administrative distance ("preference", in Junos) than your IGP (OSPF or ISIS). This been said, in all BGP implementations, the BGP best path selection algo includes a

Re: [j-nsp] JUNOS precision-timers for BGP

This knob has been in all our confs for years (from 12.3 to 14.2). At least it doesn't seem to do anything bad. > Le 25 avr. 2016 à 17:16, Adam Chappell a écrit : > > Does anyone have positive or negative experience with this feature in 14.1 > please? > > Currently in

Re: [j-nsp] Full routes on MX5

And also [edit system commit delta-export], in 14.2 and later. > Le 26 avr. 2016 à 18:54, Daniel Verlouw a écrit : > > have you considered using the [system commit fast-synchronize] option? > Allows the config to commit simultaneously on both REs. > > Also [system commit

Re: [j-nsp] EX backup/primary partitions switched?

If you have activated (as everyone should probably do) "system auto-snapshot", and did a system snapshot after your last JunOS update, then there's nothing wrong, so there's nothing to correct. The switch will alternate between da0s1 and da0s2 at each JunOS update, and you don't mind. > Le 20

Re: [j-nsp] MX80 vs MX40

By the way, if you buy new routers, notice that End of Sale for MX5/10/40/80 is to be announced this year (not RoHS2 compliant). They are replaced by MX104 (coming in various license packages to replicate the licensing model of MX5/10/40). > Le 17 avr. 2016 à 01:46, Amarjeet Singh

Re: [j-nsp] New to Juniper: loopback interface address for the re0 configuration group?

lo0.0 interface is to be configured under "set interfaces lo0 blah". Because you really don't want a changing lo0 IP if there's a switchover. Usually in re0/1 groups for MX (or member0/1 for Virtual Chassis EX switches, or member0/1-re0/1 for Virtual Chassis MX) you define a hostname mentioning

Re: [j-nsp] JUNOS precision-timers for BGP

... Fine on SRX, MX, and older 12.3 on EX4200, at last. Just started an EX3300 in 12.3R12-S1 today with precision-timers configured: 0 (zero) keepalives were sent, session flapped every 90 seconds. What a good job and a fine quality check... > Le 25 avr. 2016 à 18:43, Olivier Bengh

Re: [j-nsp] Booting from tftpboot u-boot

What about https://www.proteus.net/community/blogs/recovering-u-boot-mode ? > Le 30 juil. 2016 à 17:20, Lukasz Martyniak a > écrit : > > > I already try this, but system goes to u-boot “=>” before it

Re: [j-nsp] juniper router reccomendations

Looks like "System performance enhancements for rpd, Packet Forwarding Engine, and kernel (MX Series)" in release notes: https://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1F6/topic-106259.html#jd0e1020

Re: [j-nsp] 15.1 on MX104

Hi Josh, There's no 15.1R6 yet, but 15.1R4 (or 15.1F6 for Features on steroids release train). There no new Freebsd on PPC platform (so no SMP, no new partitioning scheme and so on). Since 15.1 on PPC is not "Junos OS with upgraded FreeBSD", I suppose there's just no change about memory

Re: [j-nsp] SNMP access to default RI when lo0.0 is inside a VRF

Poll the router using "@yourcommunity" > Le 20 juil. 2016 à 18:22, Jason Lixfeld a écrit : > > I have an EX9204 running 14.2R4.9. I’m accessing the box in-band via lo0 > which is configured inside a management routing-instance (VRF). My SNMP > management station also

Re: [j-nsp] Rewriting customer DSCP with MPLS EXP

Not in 15.1R, but back in 15.1F. What a mess... > Le 8 août 2016 à 22:02, Olivier Benghozi <olivier.bengh...@wifirst.fr> a > écrit : > > Well it's in 14.2 and in 16.1, BUT not in 15.1. > To announce a new feature? Just remove an old one in the previous release, > and a

Re: [j-nsp] Rewriting customer DSCP with MPLS EXP

Well it's in 14.2 and in 16.1, BUT not in 15.1. To announce a new feature? Just remove an old one in the previous release, and add it back... > Le 2 juil. 2016 à 15:39, Mark Tinka a écrit : > >> Yes, I read your mails :) >> But I had the impression that it was advertised

Re: [j-nsp] Rewriting customer DSCP with MPLS EXP

Hi, I know this thread is more than one year old, but I had a not_that_far need (outbound packet 802.1p field rewrite based on DSCP, instead of internal CoS)... Well, I've just seen that the needed feature is only available in (freshly released) (completely radioactive) 16.1 release.

Re: [j-nsp] Rewriting customer DSCP with MPLS EXP

er than Juniper's old-style rewriting on egress. > > > On 1/Jul/16 18:02, Olivier Benghozi wrote: >> I know this thread is more than one year old, but I had a not_that_far need >> (outbound packet 802.1p field rewrite based on DSCP, instead of internal >> CoS)... >

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

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

Re: [j-nsp] RVSP signaled L3VPN and RRs

One must not use NHS for all routes on an RR, but only for external routes :) policy-statement next-hop-self { term iBGP { from { protocol bgp; route-type internal; } then next policy; } term default { then {

Re: [j-nsp] RVSP signaled L3VPN and RRs

Did you set protocols mpls traffic-engineering mpls-forwarding ? > Le 18 août 2016 à 17:13, raf a écrit : > > So there is a problem in resolving route of my L3vpn as there is no route in > inet.3 for my RRs. ___ juniper-nsp

Re: [j-nsp] Limit on the number of BGP communities a route can be tagged with?

And about a limitation to 10 communities: I've seen that on SEOS (Redback/Ericsson OS for SmartEdge routers) when using "set community" in a route-map. This is a ridiculous arbitrary limitation, of course. Hopefully the limitation was only in the CLI, not in the BGP code itself. So the

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

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

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

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

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

Re: [j-nsp] Netflow/Jflow

dose not > restart the FPC > > Nitzan > > On Fri, Nov 4, 2016 at 5:47 AM, Scott Granados <sc...@granados-llc.net > <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

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

n: Theo Voss <m...@theo-voss.de> > Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>, Olivier > Benghozi <olivier.bengh...@wifirst.fr> > Betreff: Re: [j-nsp] MX 14.2R7 / PR1177571 > > Hi there, yes we did hit the same PR. > > the alarm was rai

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.

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 ?

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,

Re: [j-nsp] routing instances on EX2300

: 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-nsp] routing instances on EX2300 > > According to the Feature Explorer, VRF Lite are supported on

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

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

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

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

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

  1   2   >