Re: [j-nsp] VMX integrated FPC

On Mon, 21 Dec 2020 at 09:56, Mark Tees wrote: > > Hello > > I remember when I originally got my mittens on VMX there was a boot > flag to tell it to use an integrated FPC or integrated RIOT without a > separate VM running forwarding. I can't find my notes on that. > > Does anyone know if that's

Re: [j-nsp] LAG/ECMP hash performance

On Wed, 28 Aug 2019 at 08:21, Saku Ytti wrote: > SRC: (single 100GE interface, single unit 0) > 23.A.B.20 .. 23.A.B.46 > TCP/80 > DST: (N*10GE LACP) > 157.C.D.20 .. 157.C.D.35 > TCP 2074..65470 (RANDOM, this alone, everything else static, should > have guaranteed fair balancing) > > I'm

Re: [j-nsp] LAG/ECMP hash performance

On Sat, 24 Aug 2019 at 10:06, Saku Ytti wrote: Hi Saku, > Has anyone ran into a set of flows where ostensibly you have enough > entropy to balance fairly, but you end up seeing significant imbalance > anyhow? Can you share the story? What platform? How did you > troubleshoot? How did you fix?

Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

On Thu, 25 Apr 2019 at 08:49, Tarko Tikan wrote: > > hey, > > > Please let me know if anything was unclear or if someone has other > > ideas or theories. > > Been following this thread and do not have anything to contribute at > this point but wanted to say I (and I hope many others) appreciate

Re: [j-nsp] OSPF reference-bandwidth 1T

TLDR; metrics aren't a purely design/academic decision, they are operational too. On Thu, 24 Jan 2019 at 09:27, Saku Ytti wrote: > I don't disagree, I just disagree that there are common case where > bandwidth is most indicative of good SPT. If by "good" you mean "shortest" (least number of

Re: [j-nsp] OSPF reference-bandwidth 1T

On Thu, 17 Jan 2019 at 18:09, Saku Ytti wrote: > It boggles my mind which network has _common case_ where > bandwidth is most indicative of best SPT. Hi Saku, I've worked on several small networks where you don't have equal bandwidth links in the network. I don't mean U/ECMP, I mean a ring

Re: [j-nsp] OSPF reference-bandwidth 1T

On Wed, 16 Jan 2019 at 15:06, Event Script wrote: > > In the process of adding 100G, LAGs with multiple 100G, and to be prepared > for 400G, looking for feedback on setting ospf reference-bandwidth to 1T. > > Please let me know if you have had any issues with this, or if it has been > a smooth

Re: [j-nsp] Finding drops

On Mon, 21 Jan 2019 at 20:09, Jason Lixfeld wrote: > > Hi all, > > I’m doing some RFC2544 tests through an MX204. The tester is connected to > et-0/0/2, and the test destination is somewhere out there via et-0/0/0. 64 > byte packets seem to be getting dropped, and I’m trying to find where on

Re: [j-nsp] vMX questions - vCPU math

On 30 December 2018 21:54:17 CET, Robert Hass wrote: ... >My confusion is related to HT setting, as you wrote to disable it. > >But vMX Getting Started Guide for KVM says: > >"CPU pinning with flow caching enabled (performance mode) is different >than >with flow >caching disabled (lite mode).

Re: [j-nsp] vMX questions - vCPU math

On 30 December 2018 18:40:50 CET, James Bensley wrote: > Text with lots of typos ^ Sorry about that, on a mobile. >I often make notes and never get around to publishing them online >anywhere. Nearly 2 Yeats ago (where did the time go?) I was testing >CRS1000v performance. Thi

Re: [j-nsp] vMX questions - vCPU math

On 30 December 2018 18:12:43 CET, Aaron1 wrote: >With vMX I understand that as more performance is needed, more vcpu, >network card(s) and memory are needed. As you scale up, a single vcpu >is still used for control plane, any additional vcpu‘s are used for >forwarding plane. The assignment

Re: [j-nsp] Opinions on fusion provider edge

On 8 November 2018 14:23:02 GMT, Tarko Tikan wrote: >hey, > >> There is >> nothing wrong with layer 2 aggregation switches in my opinion, the >> only technical advantage in my opinion to using SP Fusion for a layer >> 1 extension to a router compared to a layer 2 switch is that SP >Fusion >>

Re: [j-nsp] Opinions on fusion provider edge

On Wed, 7 Nov 2018 at 13:03, Antti Ristimäki wrote: > Wrt the original question about possible issues with Fusion, we have faced > quite a many. Currently one of the biggest pains is to get CoS configured > properly on Fusion ports. We have a case open, where any CoS scheduler change > stops

Re: [j-nsp] Juniper Buffer Bloat

On Thu, 18 Oct 2018 at 10:36, Benny Lyne Amorsen wrote: > > James Bensley writes: > > > If customers have WAN links that are slower than their LAN links - > > that is where fq-codel was designed to be implemented and that is why > > it should be implemented on the

Re: [j-nsp] Juniper Buffer Bloat

ce. Taking this full circle - fq-codel is aimed at addressing bufferbloat, not congested up-links on the devices in your network, please note that these are two seperate problems. A port/link/line card upgrade fixes the congested core/backhaul link problem. On Thu, 18 Oct 2018 at 06:59, Mark Tinka

Re: [j-nsp] Juniper Buffer Bloat

On 17 October 2018 20:53:44 CEST, Colton Conor wrote: >I was wondering if Juniper supports anything like fq-codel to prevent >buffer bloat? Specifically we would like to do rate shaping and >subscriber >management on core Juniper MX's. However, most network devices do >simple >buffers and

Re: [j-nsp] Traffic delayed

On 4 October 2018 19:34:01 BST, james list wrote: >Due to the fact that access switch are QFX5100 in virtual chassis, does >anybody know if IS-IS managing virtual- chassis has something happening >every 30 minutes which could cause delay? > >Cheers As per my previous message, you should see

Re: [j-nsp] BFD Distributed Mode for IPv6

On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote: > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > > If you'd have separate ISIS process for v6 would it be possible to spin up a > separate/dedicated BFD process for that ISIS? Unless I'm mistaken BFD isn't "multi-tenant", so only one set

Re: [j-nsp] Use cases for IntServ in MPLS backbones

On Tue, 2 Oct 2018 at 15:11, Mark Tinka wrote: > Of course, in the real world, > it was soon obvious that your Windows laptop or your iPhone XS sending > RSVP messages to the network will not scale well. A point I was trying to make way back in this thread, was that IntServ doesn't scale well

Re: [j-nsp] BFD Distributed Mode for IPv6

On Tue, 2 Oct 2018 at 21:46, Mark Tinka wrote: > On 2/Oct/18 21:13, James Bensley wrote: > > I presume that if one were to run MT-ISIS there would be no impact to IPv4? > > > We already run MT for IS-IS. I consider this as basic a requirement as "Wide > Metrics&q

Re: [j-nsp] Traffic delayed

On Tue, 2 Oct 2018 at 19:59, james list wrote: > > Can you elaborate? > Why just every 30 minutes the issue? Seeing as you have an all Juniper set up I don't think there is a need to cross-post to two lists simultaneously. If you feel there is a need, please post to the two lists separately as

Re: [j-nsp] BFD Distributed Mode for IPv6

On Tue, 2 Oct 2018 at 16:39, Mark Tinka wrote: > The real-world problem we are seeing is when, for whatever reason, the > RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well, > IS-IS integrates both IP protocols. I presume that if one were to run MT-ISIS there would be no

Re: [j-nsp] Use cases for IntServ in MPLS backbones

On Tue, 2 Oct 2018 at 14:03, Tim Cooper wrote: > The QoS obligations has been pretty much cut/paste from PSN into HSCN > obligations, if you haven’t come across that yet. So look forward to that... > ;) > > Tim C Unfortunately yes James. ___

Re: [j-nsp] Use cases for IntServ in MPLS backbones

On Tue, 2 Oct 2018 at 11:23, Mark Tinka wrote: > If you are a large network (such as yourselves, Saku) where it's very likely > that the majority your customers are talking to each other directly across > your backbone, then I could see the case. But when you have customers > transiting

Re: [j-nsp] Use cases for IntServ in MPLS backbones

On Tue, 2 Oct 2018 at 10:57, Mark Tinka wrote: > I've never quite understood it when customers ask for 8 or even 16 classes. > When it comes down to it, I've not been able to distill the queues to more > than 3. Simply put, High, Medium and Low. The 4th queue is for the network > itself. I'm

Re: [j-nsp] Use cases for IntServ in MPLS backbones

On Tue, 2 Oct 2018 at 10:10, Saku Ytti wrote: > > Hey James, Hi Saku > > Yeah so not already using RSVP means that we're not going to deploy it > > just to deploy an IntServ QoS model. We also use DSCP and scrub it off > > of dirty Internet packets. > > Have you considered full or short pipe?

Re: [j-nsp] Use cases for IntServ in MPLS backbones

> On 1/Oct/18 12:16, adamv0...@netconsultings.com wrote: > > > Hi folks, Hi Adam, On Mon, 1 Oct 2018 at 12:00, Mark Tinka wrote: > > So we don't do any label signaling via RSVP-TE at all. > > We use DSCP, but really only for on-net traffic. > > Off-net traffic (like the Internet) is really

Re: [j-nsp] help with routing bypassing bgp path selection

On Mon, 1 Oct 2018 at 06:49, tim tiriche wrote: > > hello, > > i have 5 PE routers running with full iBGP/RSVP-TE MPLS Mesh. > > There is a CE connected to PE5 and PE4. > > Based on BGP Path selection all of the PE {1,2,3,4} are preferring route to > PE5 due to BGP Path selection based on AS PATH

[j-nsp] IS-IS POI

Hi All, Have anyone used this feature, did it actually help you pin-point the source of an IGP issue? https://www.juniper.net/documentation/en_US/junos/topics/concept/isis-poi-tlv-overview.html

Re: [j-nsp] PyEZ - variable into rpc.get request

On Tue, 4 Sep 2018 at 01:33, Jason Taranto wrote: > > Hi All, > > After a while of my head colliding with the wall beside me, would anyone know > how to get a variable into an rpc command via pyez. > > My latest attempt is below. > > r2check = raw_input("Route to check e.g XXX.XXX.XXX.XXX : ")

Re: [j-nsp] spring/sr ospf - opaque lsa's

Hi Aaron, I'm not 100% what you're asking here. Opaque LSAs are used in SR to advertise the SID for a prefix/node/adj within the IGP: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-25 Cheers, James. ___ juniper-nsp mailing list

Re: [j-nsp] Longest Match for LDP (RFC5283)

On 31 July 2018 at 15:29, wrote: > One follow up question, > What about the case, where the minimum set of /32 loopback routes and > associated labels is simply beyond the capabilities of an access node. > Is there a possibility for such access node to rely on default route + label > -where

Re: [j-nsp] Longest Match for LDP (RFC5283)

actly my point: > On Mon, Jul 30, 2018, 11:15 James Bensley wrote: >> unless we create horrible per-LDP >> neighbour policies on the agg node that only allow the labels for the >> exact loopbacks that access node needs to reach. Cheers, James. _

Re: [j-nsp] Longest Match for LDP (RFC5283)

Hi Krasimir, Krzysztof, On 24 July 2018 at 17:25, Krasimir Avramski wrote: > It is used in Access Nodes(default route to AGN) with > LDP-DOD(Downstream-on-Demand) Seamless MPLS architectures - RFC7032 > A sample with LDP->BGP-LU redistribution on AGN is here. Thanks Krasimir. Sorry for the

Re: [j-nsp] Longest Match for LDP (RFC5283)

On 24 July 2018 at 14:35, wrote: > Hi James Hi Adam, > Suppose I have ABR advertising default-route + label down to a stub area, > And suppose PE-3 in this stub area wants to send packets to PE1 and PE2 in > area 0 or some other area. > Now I guess the whole purpose of "Longest Match for LDP"

[j-nsp] Longest Match for LDP (RFC5283)

Hi All, Like my other post about Egress Protection on Juniper, is anyone using what Juniper call "Longest Match for LDP" - their implementation of RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) ? The Juniper documentation is available here:

Re: [j-nsp] Egress Protection/Service Mirroring

On 15 July 2018 at 19:20, Krzysztof Szarkowicz wrote: ... >>> https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf >>> https://www.youtube.com/watch?v=MoZn4qq3FcU=69=0s=UUIvcN8QNgRGNW9osYLGsjQQ ... >> I was originally refering to >>

Re: [j-nsp] Egress Protection/Service Mirroring

On 15 July 2018 at 11:12, wrote: > @James is on my todo list so maybe we can exchange notes, (I plan on using > it in RSVP-TE environment so the added complexity will be only marginal). > Yes I've been waiting for this feature for quite some time in cisco (got > promises that maybe on SR) -maybe

Re: [j-nsp] Egress Protection/Service Mirroring

On 15 July 2018 at 12:47, Saku Ytti wrote: > On Sun, 15 Jul 2018 at 13:12, wrote: Hi Saku, Adam, >> > a) If P2->PE2 goes down, we have to wait for PE1 to experience it, after >> PE1 >> > experiences it, it can immediately redirect to PE3 >> > b) If PE2->CE2 goes down, PE2 should be able to

[j-nsp] Egress Protection/Service Mirroring

Hi All, Has anyone used Egress Protection/Service Mirroring, anyone got any stories they can share good or bad? To clarify, I'm talking about: https://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-03

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 8 July 2018 21:35:36 BST, adamv0...@netconsultings.com wrote: >Hold on gents, >You are still talking about multi-hop TCP sessions, right? Sessions >that >carry information that is ephemeral to the underlying transport network >-why >would you want those session ever go down as a result of

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 5 July 2018 at 09:40, Mark Tinka wrote: > > In our case, we have different boxes from Cisco, each with varying support > for SR. This makes things very tricky, and then we need to also throw in our > Juniper gear. For me, the potential pain isn't worth the hassle, as we are > not suffering in

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 5 July 2018 09:56:40 BST, adamv0...@netconsultings.com wrote: >> Of James Bensley >> Sent: Thursday, July 05, 2018 9:15 AM >> >> - 100% rFLA coverage: TI-LA covers the "black spots" we currently >have. >> >Yeah that's an interesting use

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 5 July 2018 14:08:02 BST, Aaron Gould wrote: >I really like the simplicity of my ldp-based l2vpn's... eline and elan > >You just made me realize how that would change if I turned off ldp. > >So, SR isn't able to signal those l2circuits, and manual vpls instances >? >... I would have to do

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 4 July 2018 at 18:13, Mark Tinka wrote: > > > On 4/Jul/18 18:28, James Bensley wrote: > > Also > > Clarence Filsfils from Cisco lists some of their customers who are > happy to be publicly named as running SR: > > https://www.youtube.com/watch?v=NJxtvNssgA8=yo

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 4 July 2018 at 17:09, James Bensley wrote: > On 4 July 2018 at 10:09, Mark Tinka wrote: >> >> >> On 4/Jul/18 10:58, Niall Donaghy wrote: >>> Hi Mark, >>> >>> As for segment routing, several of our NREN partners have SR up and running >&

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 4 July 2018 at 10:09, Mark Tinka wrote: > > > On 4/Jul/18 10:58, Niall Donaghy wrote: >> Hi Mark, >> >> As for segment routing, several of our NREN partners have SR up and running >> in their backbones. >> We in GÉANT (the backbone that connects these NRENs) are looking toward >> deploying

Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

On 29 June 2018 at 13:55, Gert Doering wrote: > Hi, > > On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote: >> Just wondering what's the latest on the GPU for packet forwarding front (or >> is that deemed legacy now)? > > Last I've heard is that pixel shaders do not map

Re: [j-nsp] How does internal communication between vMX virtual control plane and virtual forwarding plane work?

On 4 June 2018 at 13:46, Martin T wrote: > Hi! Hi! > When I deploy a vMX using orchestration scripts, then I end up with > following virtualized topology: > > https://i.imgur.com/bBTXGM0.png > > Now when I execute "file copy root@192.168.122.1:/tmp/1G_file > /dev/zero" in vMX, then I can see

Re: [j-nsp] Force a reboot from the serial console?

On 31 May 2018 at 18:04, Chris Adams wrote: > I had an MX80 crash (insert sad face here) - worse problem was that it > did a crash dump and then did NOT reboot. I have out-of-band serial > access to the console, so I could see that, after the dump completed, it > just printed: > > watchdog:

Re: [j-nsp] "show ip cef exact-route"

ted 4.2.3. and 4.3.2) As previously mentioned On 15 May 2018 at 09:47, James Bensley <jwbens...@gmail.com> wrote: > With regards to ECMP/LAG you need to run some extra commands that are > often platform specific. For ASR9K for example use the "bundle-hash" > command - I

Re: [j-nsp] "show ip cef exact-route"

On 15 May 2018 at 10:20, Zsolt Hegyi wrote: > In case you haven't read it yet, there is a free book called This Week: An > Expert Packet Walkthrough on the MX Series 3D by David Roy, it has a bunch > of examples on using jsim and other FPC/PFE commands, including what I

Re: [j-nsp] "show ip cef exact-route"

On 15 May 2018 at 02:51, Nikolas Geyer wrote: > Someone at Juniper has kindly reached out and advised that a similar command > was added in 17.1R1 for the MX; > >

[j-nsp] "show ip cef exact-route"

Hi All, Does anyone know of a command like the Cisco CEF "exact-route" command on Juniper? I've seen this older thread: https://lists.gt.net/nsp/juniper/50645 Which links to a post on using JSIM but for DPC cards, but I'm interested in MPC cards:

Re: [j-nsp] mpls.0 doesn't show LSI as the next hop

Hi Arie, On 1 May 2018 at 23:21, Arie Vayner wrote: > user@MX104> show route table mpls.0 > 16 *[VPN/0] 00:25:28 > to table vpn_public_vrf.inet.0, Pop > > > While if we do the same on our MX240 it looks like this: > 18

Re: [j-nsp] migration from cisco VRF+Vrrp to the juniper ACX

On 1 May 2018 at 17:07, A. Camci wrote: > does anyone have an idea why it does not work on Acx( vrf+ vrrp). > > Br ap How have you tried to debug this set up? >From your original em ail:"maybe vrf+vrrpdoesnt work on a ACX." - Have you confirmed this, are you trying

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

On 17 April 2018 at 11:57, Gert Doering <g...@greenie.muc.de> wrote: > Hi, > > On Tue, Apr 17, 2018 at 12:34:18PM +0300, Saku Ytti wrote: >> On 17 April 2018 at 11:25, James Bensley <jwbens...@gmail.com> wrote: >> >> > Also you say you have OS

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

On 16 April 2018 at 20:58, Aaron Gould wrote: > See juniper interface MTU is set to max 16000 bytes. but when I ping I can > only get 9584 bytes through to the other side of the link. This mx960 is > linked to another mx960, but Ciena 6500 dwdm is in between the mx960's. Hi

Re: [j-nsp] Going Juniper

>>> On 11 April 2018 at 13:43, Ola Thoresen wrote: >>> Granted at least JNPR offering allows you to run same device as pure >>> L2, with Cisco offering it is satellite-only box, cannot be used as >>> L2. >> >> I know what you mean, but I must say that this time it seems like they

Re: [j-nsp] Going Juniper

On 11 April 2018 at 10:31, Saku Ytti wrote: > New RE for MX104 was on the table early on in the MX104 history, but > then JNPR changed tracks, citing XEON not being thermally possible on > it. I had heard (more or less from the horses mouth) that the MX104's were initially

Re: [j-nsp] maximum-prefixes not enforced on option B gateways

On 28 March 2018 at 11:55, Pierre Emeriaud wrote: > Gents, > > I just noticed an issue on a couple of option B gateways in our > network. The max-prefix within routing-instances is not enforced. It's > although taken into account. > > This is on M120 running 12.3R6-S3 (yes I

Re: [j-nsp] Juniper EX4550 load balancing of MPLS over LAG

On 8 March 2018 at 21:45, Erdal Rasid wrote: > Now this works great in the majority scenarios, because hey let's be honest, > MAC addresses for the longest time started with 00-0.. > > This fools the system to believe that the inner packet is IP, while it is an >

Re: [j-nsp] DDoS to core interface - mitigation

On 8 March 2018 at 20:35, Saku Ytti wrote: > Hey Daniel, > > Apologies for not answering your question, but generally this is not a > problem, because: > > a) have edgeACL which polices ICMP and UDP high ports to your links > and drops rest > b) don't advertise your links in IGP or

Re: [j-nsp] Upgrading from RE-S-2000-4096-S/SCB-MX960-S to RE-S-1800X4-32G-S/SCBE2-MX-S

On 17 January 2018 at 09:32, Niall Donaghy wrote: > Hi Craig, > > Indeed Misak's recommendation is the one I would follow. > > We are in the process of upgrading SCBEs to SCBE2s and indeed you must power > off for this. > > As for the RE upgrades, JNPR states here >

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

On 4 January 2018 at 18:34, Josh Baird wrote: > Hi all, > > Given the MX104-MX5-AC bundle which comes with 1 20x 1GE MIC pre-installed > (and none of the onboard 10Gbps interfaces enabled), is this box actually > limited to 20Gbps overall throughput? > > Can I install another

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

Amazon recently announced bare metal instances which provide access to the CPU virtual instruction set such as Intel VT-x, so although I haven't had a chance to look into it much just yet, I'm hoping one can spin up vMX/ASR9Kv etc. using these instances in Amazon and just offload the scaling issue

Re: [j-nsp] [c-nsp] LACP between router VMs

On 8 November 2017 at 16:30, Jeff Meyers wrote: > Hi Adam, > > LACP packets (so called slow packets in the linux kernel) are never > forwarded by the bridging code. If it didn't change in the last ~2 years, > you will have to hack your kernel in order to let them pass. It's

Re: [j-nsp] LDP VPLS - Multi-homing

On 10 October 2017 at 01:45, Aaron Gould wrote: > Ah, I see what you are asking. I don't know, perhaps someone on list knows > the particulars. > > About the multiple active fwd'ing paths for mhome'd pe-ce... I think someone > told me that is a benefit that evpn brings to the

Re: [j-nsp] LDP VPLS - Multi-homing

On 9 Oct 2017 18:52, "Aaron Gould" wrote: Thanks James, What exactly are you trying to figure out ? you mentioned " I was trying to work out the mechanism for signalling the non-designated-forwarding PE-CE link to go operationally "down"... -Aaron I was wondering how it

Re: [j-nsp] LDP VPLS - Multi-homing

On 9 October 2017 at 12:49, Aaron Gould wrote: > Ah. I think I might be on to something. I see that when I do a BGP VPLS > (fec 128, rfc 4761) style config, then I do NOT see the pw's active between > the non-designated-forwarding multi-homed pe's... and, this seems to be >

Re: [j-nsp] MX Forwarding Scale/Monitoring

On 5 September 2017 at 17:29, Harry Reynolds wrote: > The memory is dynamic and can be allocated as needed. I think the key is that > NH is limited to a maximum of 11 double mega words. What matters is overall > utilization, and then how close NH is to having 11DMW, and if

[j-nsp] MX Forwarding Scale/Monitoring

Hi All, I’ve searched juniper.net and JTAC has also failed me, so I turn to j-nsp for help; $dayjob has some MX chassis which are running 13.something (basically pre 15.1 which is when “show system resource-monitor fpc” was added). We want to monitor FIB usage on our MX platforms. “show system

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

On 16 July 2017 at 12:23, Daniel Roesen wrote: > On Sat, Jul 15, 2017 at 12:33:16PM +0300, Saku Ytti wrote: >> Usually JunOS (like other platforms) resets session when you have to >> change update group. If you'd have multiple neighbours under TO-VRx >> sharing same export-policy

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

On 2 May 2017 at 11:30, <adamv0...@netconsultings.com> wrote: >> James Bensley >> Sent: Tuesday, May 02, 2017 9:28 AM >> >> Just to clarify, one doesn't need to enable indirect-next-hop because it > is >> enabled by default, but if it we

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

On 27 April 2017 at 14:41, <adamv0...@netconsultings.com> wrote: >> James Bensley >> Sent: Thursday, April 27, 2017 9:13 AM >> >> It might be worth pointing out that on Cisco you need to enable PIC Core for >> PIC Edge to work at its best. > So it's either

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

On 19 April 2017 at 17:20, Dragan Jovicic wrote: > What Cisco originally calls "PIC Core" is simply indirect-next-hop feature > on routers, same on Juniper. On "flat" architectures without indirect > next-hop, a failure of an uplink (a core link) on a PE router would require

Re: [j-nsp] VMX 17.1 experiencing high latency/packet loss with SRIOV

On 5 April 2017 at 15:38, wrote: > The NIC is an Intel XL710 running at 10Gbps. I don't know about vMX for Junos 17, is the i40evf driver supported (for X710 Intel NICs)? We are having a similar issue with Cisco's CSR1000v on CentOS with KVM and X710 NICs. The

Re: [j-nsp] vMX SR-IOV

It's not supported by the Intel drivers. Travelling, I'll try and find you a link tomorrow. Cheers, James. On 23 Mar 2017 21:18, "Stefan Stoyanov" wrote: > Hi everyone, > > Does anyone have an idea, why vMX SR-IOV vlan-tagging isn't working? > If I use "unit 0" without

Re: [j-nsp] l2circuit/xconnect between MX104 and a ME3600X

You need to share the configs I think you want much help with this. Also from the Cisco side can you give the full output from... show xconnect interface Gi0/1 detail show mpls l2transport vc 2 detail show mpls l2transport binding 2 show mpls forwarding-table labels 18 detail Cheers, James.

Re: [j-nsp] Service Activation Testing

> On 22/09/2016 14:41, Joe Freeman wrote: >> I've been asked to put together a solution that allows us to do SAT on >> every new turnup. These are all Ethernet services. >> >> I've been trying to figure out how to do it in the MX platform since that's >> what we predominately have in our CO's, but

Re: [j-nsp] Juniper vMX

> From: Josh Reynolds > Sent: Friday, September 9, 2016 7:41:13 PM > To: Alex Valo > Cc: Juniper List > Subject: Re: [j-nsp] Juniper vMX > > > Disclaimer: I have not used vMX. > > You might be better off going with something like VyOS/Vyatta. A quad core > high clock xeon

Re: [j-nsp] Inter-AS MPLS OptB Endianness Issue?

On 18 Jul 2016 11:58, "James Bensley" <jwbens...@gmail.com> wrote: > > I have had an off list resposne confirming that others have seen this > issue, so I'm not totally mad. > > Will speak to JTAC if I get the chance. > > Cheers

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

Thanks all :) Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

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

On 23 August 2016 at 13:40, Olivier Benghozi wrote: > 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.

Re: [j-nsp] Inter-AS MPLS OptB Endianness Issue?

I have had an off list resposne confirming that others have seen this issue, so I'm not totally mad. Will speak to JTAC if I get the chance. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net

[j-nsp] Inter-AS MPLS OptB Endianness Issue?

Hi all, Just noticed this the lab that between an ASR9K (5.3.3) and MX480 (13.3R8.7), nothing "major" as it work but just curious is anyone else has seen this (especially between two MXs), I haven't. On the MX the RD for the ABC VRF was set to "route-distinguisher 196744L:200;" and the RT is

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

On 19 May 2016 at 10:53, Mark Tinka <mark.ti...@seacom.mu> wrote: > > > On 19/May/16 11:49, James Bensley wrote: > >> In Cisco land we have the interface command "carrier-delay", for Junos >> (this scenario) can the OP not use some variant of "set inter

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

In Cisco land we have the interface command "carrier-delay", for Junos (this scenario) can the OP not use some variant of "set interfaces xe-0/0/1 hold-time up 5000" ? Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

On 28 April 2016 at 17:16, Hugo Slabbert wrote: > Use a community of simply "@SecretCommunity", *WITHOUT* the actual RI > specified. That will pull everything. It's a little weird, but it works. Yeah I had someone point that out to me offlist. I can confirm it's now working

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

On 28 April 2016 at 12:50, Dale Shaw wrote: > Hi James, > My memory's a bit hazy on this, but do you see everything you want to see if > you prefix the community string with a "@" in your cacti config? Hi Dale, As per my original email, I am prefixing the

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

On 27 April 2016 at 17:10, Phil Mayers wrote: > On 27/04/16 16:58, Per Westerlund wrote: >> >> That is default behavior, but you can access other RI's interfaces by >> explicitly using the RI name. No way to reach all IFs at once via a RI. > > > I'm a bit confused now. >

[j-nsp] SNMP walk on JunOS from inside a routing instance

Hi All, I am migrating from one Cacti box to another, the new one polls some MX boxes inside a routing instance but the old one polls in inet0 in no routing instance. When I snmpwalk the MX boxes from the new Cacti box I am only returned the interfaces which are inside that routing instance the

Re: [j-nsp] Redistribute Connected in Junos

On 17 November 2015 at 15:49, Dave Bell wrote: > Hi James, > > Your export policy isn't adding on your community. > > Try: > term 10 { > from { > protocol direct; > interface [ ge-0/1/0.89 fe-1/1/3.89 ]; > } > community add 0089_VRF; > then

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

On 1 December 2015 at 14:14, Mark Tinka wrote: > > > On 1/Dec/15 15:03, john doe wrote: > >> >> >> I think price wise MX is a better deal. ASR fully loaded with cards and >> licences for various services gets expensive fast. > > Depends what cards you are loading in there.

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

On 1 December 2015 at 17:29, Stepan Kucherenko wrote: > My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped > grouping BGP prefixes in one update if they have same attributes so it's one > prefix per update now (or sometimes two). > > Transit ISP we

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

On 2 December 2015 at 09:17, Mark Tinka wrote: > > > On 1/Dec/15 17:49, john doe wrote: > >> >> >> >> Yeah, I was just referring to cli experience. commits, rollback, hierarchy >> within. Prior XR IOS was wall of text, no? > > Still is, but you get used to working with what

[j-nsp] Redistribute Connected in Junos

to get some directly connected return routes back from PE2 via RR to PE1. Many thanks, James. bensley@RR1> show configuration protocols bgp group Core-MX480 type internal; local-address RR1.Lo0.IP.165; family inet { unicast; } family inet-vpn { unicast; } family inet6 { unicast;

Re: [j-nsp] l2circuit between ASR9k and MX80

On 31 July 2015 at 11:41, Marcin Kurek not...@marcinkurek.com wrote: Hello, I'm doing some interoperability tests between Cisco and Juniper routers and I wanted to ask about a particular piece of config. I would expect that it shouldn't work, but it works perfectly, so I'm a bit confused.

Re: [j-nsp] MPLS LDP router-id

Hi Mohammad, I think you are looking for the following commands on your Cisco device (if I have understood the problem correctly), IOS: interface x/y/z mpls ldp discovery transport-address interface IOS-XR: mpls ldp vrf ABC123 interface GigabitEthernet0/0/0/1 address-family ipv4

Re: [j-nsp] Cisco ME3600 migration to something with more 10 gigports

On 14 July 2015 at 16:13, Aaron aar...@gvtc.com wrote: Thanks everyone for your input. Does the mx80 support all the mpls L3vpn and L2vpn things I mentioned ? It does do all this: I'm needing more 10 gig ports in my CO's for purposes of upgrading my FTTH OLT shelves with 10 gig. I

  1   2   >