[j-nsp] Junos MPLS/LDP L2circuit label issue

Hello folks, I'm trying to setup a l2circuit between a M20 box running Junos 8.5 and a cisco 1841 over two bonded T1s, the relevant configuration bits follow: show configuration interfaces lsq-3/0/0 per-unit-scheduler; unit 3 { encapsulation multilink-ppp; family inet {

Re: [j-nsp] MX960 AC power strip

You can easily get 30A PDUs with L6-20Rs which is what Juniper recommends for the MX960... e.g. http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=AP7893 Geist, ServerTech, etc. all also make many many options. -Scott H. -Login Inc. On 08/23/2012 07:59 AM, JA wrote:

Re: [j-nsp] FIB Capacity on older platform

We have a few older M20s in service still, with the RE-3.0 we have 2.4MM routes and 241k+ active, RE @ 60% memory usage, SSB @ 52% memory usage. Not bad for such an old box. -SH On 12/15/2012 10:34 AM, Michael Loftis wrote: FIB capacity is determined solely by the FEB/CFEB on those platforms.

[j-nsp] EX-2500 Rebooting at will

We have two 2500s that both seem to reboot at their own will and indicate power cycle as the reason for the last reload but both have dual power and neither has had a power interruption to either power supply and they are on different power sources it seems it may be related to the

[j-nsp] MX80 / 3D MIC buffers/queues

Does anyone know if there is there a way to see how much buffer space/queue space is being used for shaping policies on the MX80 / MIC-3D-20SFP? I can see queue status but I'm more interested in how much memory is being consumed for shaping. We apply some shaping policies per unit on

Re: [j-nsp] MX80 / 3D MIC buffers/queues

87% 65% GOT:293% 83% GOT:3100% 89% LOCAL: End of file 2013/11/7 Scott Harvanek scott.harva...@login.com mailto:scott.harva...@login.com Does anyone know if there is there a way to see how much

[j-nsp] M-series IPSEC / SP interface and VRF

Is there a way to build a IPSec tunnel / service interface where the local gateway is NOT in the same routing-instance as the service interface? Here's what I'm trying to do; [ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ] [ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]

Re: [j-nsp] M-series IPSEC / SP interface and VRF

Anyone with any ideas on this? Scott H. On 11/9/13, 12:58 PM, Scott Harvanek wrote: Is there a way to build a IPSec tunnel / service interface where the local gateway is NOT in the same routing-instance as the service interface? Here's what I'm trying to do; [ router A (SRX) ] == Switch

Re: [j-nsp] M-series IPSEC / SP interface and VRF

!!! aarseniev@m120 show version Hostname: m120 Model: m120 JUNOS Base OS boot [10.4S7.1] HTH Thanks Alex On 12/11/2013 16:05, Scott Harvanek wrote: Anyone with any ideas on this? Scott H. On 11/9/13, 12:58 PM, Scott Harvanek wrote: Is there a way to build a IPSec tunnel / service interface where

Re: [j-nsp] M-series IPSEC / SP interface and VRF

the to-be-ecrypted packets should arrive, from inet.0 or VRF? If the answer is correct/inet.0/VRF/VRF then migrate to next-hop-style IPSec and place inside sp-* unit into the VRF leaving outside sp-* unit in inet.0. HTH Thanks Alex On 12/11/2013 16:35, Scott Harvanek wrote: Alex, Yea, tried

[j-nsp] per-unit-scheduling, vlan shaping, MX480

Hey guys, What's the correct MIC/MPC combination to support per-vlan shaping? ( the mpc/mic supported feature docs are a bit confusing on this ) We're having success with a MX80 sporting a MIC-3D-20GE-SFP but looking to add a MX480 to replace some aging hardware and would like that same

Re: [j-nsp] M-series IPSEC / SP interface and VRF

or does it just not work on next-hop-style? Thanks, -SH On 11/12/13, 1:34 PM, Scott Harvanek wrote: Yep excellent, I'll give it a whirl, thanks! Scott H. On 11/12/13, 1:24 PM, Alex Arseniev wrote: So, if I understand Your requirement, You want sp-0/0/0.unit in VRF, correct? And outgoing GE

Re: [j-nsp] M-series IPSEC / SP interface and VRF

the tunnel, or 2/ You have to have a BGP import policy to change the nexthop to tunnel's remote address. If this is eBGP, then also add accept-remote-nexthop knob. HTH Thanks Alex On 17/12/2013 16:08, Scott Harvanek wrote: So this works to establish the tunnels, the problem is, BGP received routes

Re: [j-nsp] M-series IPSEC / SP interface and VRF

-instance VRFname dst.ip source whatever This src.ip must be known by/reachable from far end. HTH Thanks Alex On 17/12/2013 20:40, Scott Harvanek wrote: BGP is running in the tunnel and the next hop is the far side of the tunnel, everything looks correct. All the routes show the far end

[j-nsp] MX VC ISSU

Does anyone know if ISSU will ever be supported on a MX virtual-chassis? Kind of a show stopper to have to reboot the whole VC for a upgrade. -- Scott H. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net

Re: [j-nsp] MX VC ISSU

, assuming ISSU works as expected (I've heard a lot of horror stories). Thanks, Morgan On Wed, Apr 23, 2014 at 2:48 PM, Scott Harvanek scott.harva...@login.com mailto:scott.harva...@login.com wrote: Okay so then here's the million dollar question. Has anyone attempted a ISSU on a MX

Re: [j-nsp] MX VC ISSU

customers to MX VC over the next couple weeks. Thanks, Morgan On Thu, Apr 24, 2014 at 1:12 PM, Scott Harvanek scott.harva...@login.com mailto:scott.harva...@login.com wrote: Morgan, Yea, we've successfully done this in the lab with the MXs and breaking the VC. I guess it's better

[j-nsp] EX2500 communication failure outside subnet

DIsclaimer: I know the EX2500 is just a rebranded BLADE/IBM switch. Randomly the switch has refused to speak outside of its own subnet EXCEPT for traceroute/telnet/www. Fails: Ping, SNMP Works: Traceroute, Telnet, WWW E.g.: I can only ping within the subnet, nothing more and SNMP is

[j-nsp] ipv4/ipv6-flow-table-size

I'm wondering if anyone can clarify something for me from docs: * Any change in the configured size of flow hash table sizes initiates an automatic reboot of the FPC. * The total number of units used for both IPv4 and IPv6 cannot exceed 15. - Does the initial config entry of

Re: [j-nsp] ipv4/ipv6-flow-table-size

size is a combined value of v4 and v6 so 15 total a subset of which is IPV4 and the remainder is IPV6. Thanks Scott On Aug 25, 2014, at 3:02 PM, Scott Harvanek scott.harva...@login.com wrote: I'm wondering if anyone can clarify something for me from docs: * Any change in the configured

Re: [j-nsp] ipv4/ipv6-flow-table-size

, at 3:56 PM, Scott Harvanek scott.harva...@login.com wrote: Scott, Thanks, my next question then with that is - how/why is the default of ipv4 15 and ipv6 1? That would break that constraint of 15 total? Scott H. Login Inc. On 8/25/14, 3:53 PM, Scott Granados wrote: When ever you set the flow

[j-nsp] BGP Peer formatting

This is a silly/OCD question; I've faced this before and I can't recall how it was prettied up... If I recall there is a way to pretty up the formatting of show bgp summary; Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

Re: [j-nsp] BGP Peer formatting

Awesome, thank you very much :-) Both work great! Scott H. On 9/9/14, 9:32 PM, Ben Dale wrote: On 10 Sep 2014, at 7:54 am, Scott Harvanek scott.harva...@login.com wrote: This is a silly/OCD question; I've faced this before and I can't recall how it was prettied up... If I recall

[j-nsp] Inline jflow - No hash table changes

Hey guys, Quick question, if we setup inline jflow on a MX480 and do not adjust the hash table sizes, will the FPC still restart?* Specifically the config change would look like this ( MX480 VC, member 1, FPC 0(VC FPC 12) would be put into this but not member 0 ): [edit chassis] +

Re: [j-nsp] Inline jflow - No hash table changes

we're running dual-RE MX480 on a single chassis, not VC. We did take a hit on an MX-5, but I believe that was due to touching defaults, as you mentioned. So, I can offer you an anecdote but I don't have an official word on it. On Thu 2014-Sep-11 16:42:34 -0400, Scott Harvanek scott.harva

Re: [j-nsp] Inline jflow - No hash table changes

relevant to you at all. On Thu 2014-Sep-11 18:49:27 -0400, Scott Harvanek scott.harva...@login.com wrote: Thanks for all the input guys, we're going to give this a go early tomorrow morning. We're running 14.1, I'll report back my findings for reference. Scott H. On 9/11/14, 5:59 PM

[j-nsp] Virtual Chassis RPD/BGP Rsync high CPU

Has anyone had a issue with MX units in a VC where BGP rsync was consuming a boatload of CPU? Master chassis shows: Task StartedUser Time System Time Longest Run BGP rsync 9650 10. 0.8 0.0 ( BGP rsync is the only task with any

Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU

[48424]: Received 1 malformed attribute AGGREGATOR4(18) Mind you, the primary session with the peer stays up, this only kills the replication process... Scott H. On 9/18/14, 11:38 AM, Scott Harvanek wrote: Has anyone had a issue with MX units in a VC where BGP rsync was consuming

Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU

://kb.juniper.net/InfoCenter/index?page=contentid=JSA10491 ? You can drop any attribute, not only 128 as in the KB. Thanks Alex On 24/09/2014 18:38, Scott Harvanek wrote: Okay so we traced this down to BGP Replication for NSR. Looks like a bad attribute kills the replication process. Other than blocking

Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU

Disregard, 18 is correct, looks like IETF/RFC4893 has this as AS4_AGGREGATOR not AGGREGATOR4. Scott H. Login Inc. On 9/24/14, 5:11 PM, Scott Harvanek wrote: Well shoot, that's a great idea, looks like this command is hidden so I didn't even see it. I assume AGGREGATOR4 is type code 18? I

Re: [j-nsp] Dear Juniper...

I agree with this more than the former. I haven't had any issues finding specs etc. but it's certainly fatty block buzzword design. Scott H. On 9/25/14, 3:44 PM, Daniel Rohan wrote: I have to agree, but from a different angle. The How Do We section made me laugh out loud, so filled with

Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface

I think the question is, why not carry the customer traffic on a VLAN back to the MX80? Scott H. Login Inc. On 11/10/14 12:55 PM, Raphael Mazelier wrote: Le 10/11/14 18:40, Hugo Slabbert a écrit : What's the connection between the EX and the MX? Could you not just switch the customers

[j-nsp] L2Circuit with BGP/LDP

Hey all- I've got a question about a L2Circuit, normally we use LDP/OSPF, the loopback of the neighbor is reachable as the OSPF route for that /32 is available in the internal LDP route table. BGP routes are not imported into this table, my question is, is there a way to have a /32 received

Re: [j-nsp] L2Circuit with BGP/LDP

Thanks for the suggestions all, 3107 looks like it would do what I want, I'll give that a try. Scott H. On 2/19/15 9:46 AM, Adam Vitkovsky wrote: That's what I understood the PW Labels generated by BGP. Hmmm though now that I read Scott's post again he actually wanted to avoid using routing

[j-nsp] SRX / Flow + Session Data

Is there any way to get session data + flow data for clients off of a SRX box, basically we have a need to track URLs client machines may access, there's too much data to do a port mirror without losing historical data and flows don't contain the session data of course. Anyone had to run into

Re: [j-nsp] VCCP

We’ve been running VC on the MX platform for years without issue. Scott H Login, LLC > On Nov 16, 2017, at 8:51 AM, Chuck Anderson wrote: > > Virtual Chassis shares the management, control, and data planes across the > two routers. I don't like that from a high-availability

Re: [j-nsp] MPC5EQ Feedback?

Adam, I thought that the MPC3E and MPC5E had the same generation Trio w/ XL and XQ chips? Just the MPC5E has two XM chips. Scott H > On Nov 1, 2017, at 10:28 AM, <adamv0...@netconsultings.com> > <adamv0...@netconsultings.com> wrote: > >> Scott Harvanek >>

Re: [j-nsp] MPC5EQ Feedback?

single core 400G chip (also present in the recently > announced MX204 and MX10003). > > This said, I find MPC4 quite not bad in most scenarios. Never had any issues, > specific to its architecture. > > P. S. Finally this choice is all about money/performance. >

Re: [j-nsp] MPC5EQ Feedback?

David, Thanks for pointing that out, I did read that and understand the available options/limitations between the 10G/40G interfaces. :) Scott H > On Nov 1, 2017, at 11:34 AM, Hunter, David B. wrote: > > Scott, > > Just FYI, you may already be aware of this, but there was

[j-nsp] MPC5EQ Feedback?

Hey folks, We have some MX480s we need to add queuing capable 10G/40G ports to and it looks like MPC5EQ-40G10G is going to be our most cost effective solution. Has anyone run into any limitations with these MPCs that aren’t clearly documented? We intend to use them for L3/VLAN traffic w/

[j-nsp] QFX5110 / VXLAN

Is anyone on here running 5110s for VXLAN/VTEP/EVPN and run into any issues? I’ve gone over the caveats list Juniper has for these in regards to what they won’t do in regards to VXLAN and it seems like they meet our needs… just curious if anyone has run into any lesser documented issues with

Re: [j-nsp] L2ALD_MAC_MOVE_NOTIFICATION

https://puck.nether.net/pipermail/juniper-nsp/2014-November/029561.html > On Feb 22, 2018, at 10:37 PM, Nikolas Geyer wrote: > > You’ve probably got a layer 2 loop in your topology somewhere. OSPF probably > went down due to the RE CPU utilization going through the roof. > >

Re: [j-nsp] L2ALD_MAC_MOVE_NOTIFICATION

gt; mention in that blog. > > So lost > > > Thanks > > Brijesh > On Friday, February 23, 2018, Scott Harvanek <scott.harva...@login.com > <mailto:scott.harva...@login.com>> wrote: > https://puck.nether.net/pipermail/juniper-nsp/2014-November/029561.html >

Re: [j-nsp] QFX5110 / VXLAN

L2 GW. L3 GW and Route Type 5 support is quite recent. >> >> Beefier alternatives are QFX10002, or MX204 if you want to go MX route with >> fewer ports. Both have custom ASICs with higher scale, and higher chance to >> overcome caveats/limitations especially tied to chipset li

Re: [j-nsp] MX480 ospf3 ipsec jammed?

sec-key-management" anyway. > >> On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote: >> Hey guys, >> >> Getting something interesting after a reboot; >> >> Jun 16 01:58:45 MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't >>

Re: [j-nsp] MX480 ospf3 ipsec jammed?

. Login, LLC On 6/16/19 11:20 AM, Scott Harvanek wrote: I’ll get those outputs when at a terminal but the configuration did not change and this was working pre reboot :/ The only other change was a failed MPC that was replaced. Downstream devices are sending HELLOs but this 480 is not indicating it’s

[j-nsp] MX480 ospf3 ipsec jammed?

Hey guys, Getting something interesting after a reboot; Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't dereference the sa name = XX When trying to bring up the IPSec tunnel for ospf3 peering ( which never establishes ), any ideas what this means? Do I need