Re: [j-nsp] fpc1 user.notice logrotate: ALERT exited abnormally with [1]

[Alexandre Guimaraes]

Hello Thomas, 

Probably, there ir no space to allocate new files from logrotate service.
Remove all files >   request system storage cleanup

Check this configuration lines to keep log files under control:

> show configuration system syslog 
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
file LINKS-UP-DOWN {
daemon info;
match "(SNMP_TRAP|VCCPD_PROTOCOL)";
archive size 1m files 10;   
<===<
}
file LOGS-DE-CLI {
interactive-commands info;
match .*CMDLINE.*;
archive size 1m files 10; 
<===<
}

Att
Alexandre

Em 15/06/2021 10:07, "juniper-nsp em nome de Thomas Mann" 
 
escreveu:

Hi,

Today one of our fpcs started throwing every minute logrotate syslog alerts.
Did you faced something like this before ?

Jun 15 12:38:01 core1-re1 fpc1 user.notice logrotate: ALERT exited
abnormally with [1]
Jun 15 12:39:01 core1-re1 fpc1 user.notice logrotate: ALERT exited
abnormally with [1]
Jun 15 12:40:01 core1-re1 fpc1 user.notice logrotate: ALERT exited
abnormally with [1]
Jun 15 12:41:01 core1-re1 fpc1 user.notice logrotate: ALERT exited
abnormally with [1]

Thank you
Thomas
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=Oxvd2WuQK8ZBQ6JHgkFJJAmFKCM83zFFQMarz7LmYc4=JLlSfXMikzVxGECMhrIK_pYd67bPC9zog-poLSajALU=

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Alexandre Guimaraes]

The best answer ever!

Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
before get a code similar a release, follow Tom Beecher schemas.

IT'S A LOTTERY to pick a junos release. 

One of my case
I have deployed some QFX5120 32C and 48Y units a year ago, exactly Aug/2019, 
until today, those units are offline and waiting a code that’s fix 
RSVP/ISIS/MPLS signalization until there, wasted money, etc



Em 19/08/2020 13:32, "juniper-nsp em nome de Tom Beecher" 
 escreveu:

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 

wrote:

> How do you plan which JUNOS version to deploy on your network? Do you 
stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.juniper.net_InfoCenter_index-3Fpage-3Dcontent-26id-3DKB21476-26actp-3DMETADATA=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI=
>
> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times
> to keep track of all these issues, but I am unimpressed that there are 
this
> many bugs.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo=
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo=

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 vs MX10K

[Alexandre Guimaraes]

What model of MX10k?


Em 04/03/2020 08:56, "juniper-nsp em nome de Ibariouen Khalid" 
 escreveu:

dear Juniper community

is there any limitation of using MX960 as DC-GW compared to MX10K ?

juniper always recommends to use MX10K , but i my case i need MS-MPC which
is not supported on MX10K and i want to knwo if i will have some limitation
on MX960.

Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=fZPomAfgI6F_gCmglyCCQEd7ffiHarAb7El2RzioVt8=LfmhcIovDqSZJMirXRIbBV7E4uNs9PqHzR_R6ZnPMKw=


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] QFX5100 - l2ckt in ae subinterfaces not working - vlan-ccc

[Alexandre Guimaraes]

Gents, good day.

Since Juniper, with no respect, removed a feature from QFX5100 platform 
- l2circuits over  AE subinterfaces, version 14.1X53-D42.3 is the last one 
where the feature are enable and JTAC now, doesn’t provide support anymore, 
since is an old version.
I use on these boxes, Ethernet-CCC, Vlan-CCC in phy or AE ports. 
RSVP/ISIS/MPLS enabled. Now I stuck to move with theses QFX since new versions 
of software or hardware(5110 or 5120) doesn't have the feature. But I need to 
purchase lot of switches for new facilities and make some upgrades of capacity 
of the working facilities.

Did you guys knows switches 48ports 1/10Ge,  4 or 6ports 40/100Ge  able 
to do the same thing and Juniper compatible?


I am working almost one year with SE to try to solve this problem...

Below, part of configuration:


Model: qfx5100-48s-6q
Junos: 14.1X53-D42.3

ae1 {
description "CR-00280 - L3 - sw02-metro-osc ae0";
flexible-vlan-tagging;
mtu 8000;
encapsulation flexible-ethernet-services;
aggregated-ether-options {
lacp {
active;
}
}
unit 3 {
description "nononono";
encapsulation vlan-ccc;
vlan-id 3;
}
unit 552 {
description " nonononono";
vlan-id 552;
family inet {
address 10.7.16.85/30;
}
}
unit 1354 {
description "nononononono";
encapsulation vlan-ccc;
vlan-id 1354;
}
unit 2275 {
description "nonononononono";
encapsulation vlan-ccc;
vlan-id 2275;
}
suporte@sw03-mpls-osc# set interfaces ae15 encapsulation ?
Possible completions:
ethernet-bridge  Ethernet layer-2 bridging
extended-vlan-bridge  VLAN layer-2 bridging
flexible-ethernet-services  Allows per-unit Ethernet encapsulation configuration
 
 
error: invalid value: ae15
L2circuit over AE interface is not supported on QFX5k platforms.
suporte@sw03-mpls-osc# set protocols l2circuit neighbor 177.115.1.71 interface 
ae15.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5448 & ACX710

[Alexandre Guimaraes]

Mark and gents.

Juniper really doesn't care about Metro services, since ACX5048, "The 
Promissed" equipment that was ready to solve our problems regarding port 
density and functions, but... ACX5048 doesn't work as expected as Giuliano 
said(Giuliano is my SE), We brought some ACX5048... in less than a month of 
operation, we remove those box from network, they became a layer2 switch only. 
So Juniper release the new ACX, but the problems still the same.

From my perspective, they don't have time to develop a good software 
and they just release anything for us thinking that someday, they will correct 
the software of the new hardwar, and we will be happy, but they just forget 
that we provide services and we have SLA. I have my personal cents about this 
subject...

MX, maybe, is the most stable hardware/software that they had in this 
moment. But there is no good density of ports, or we had to choose what type of 
ports we had to work on with, I can't accept this, a MPC7E-MRATE working with 
only 4 100Gb ports... (aahhh this is because de backplane bla bla bla bla) 
hardware release with bad development to run against market... to not lose the 
market.

Other problem that I have here, is with QFX5100 platform, using a 
functionality(version 14.1X53-D35.3), that they remove at the newest release 
software, and, they(Juniper) don't had solution for that and, they really don't 
care 

Now I have a big problem in large scale, since I have hundreds of 
QFX5100, can't upgrade due that, and JTAC don't support that old release 
anymore. 

And, I don't want to talk about QFX5120 deception...


This is my cent, and my feelings about.


Att
Alexandre


Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" 
 escreveu:



On 22/Jan/20 17:17, Eric Van Tol wrote:

> 
> Which is something many of us smaller providers have been begging them 
for YEARS to make. Hopefully it doesn't have restrictions on port 
configurations like the MX204 or weird filtering limitations like the original 
ACX boxes. The ASR920 is popular for a reason - they are rock-solid, offered 
decent port configurations, sensible and reasonably priced licensing, small 
form-factor and features decent enough for an access MPLS device.

And, custom silicon that does, pretty much, what you're used to seeing
on IOS XE boxes.

Juniper, I've realized, are really not interested in the Metro-E space.
I know it's great to think merchant silicon is the answer to get into
that space, but it doesn't look to me like they will be bother the
ASR920 anytime soon.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5110 : Q-in-Q in VXLAN

[Alexandre Guimaraes]

Well...

From my experience with QFX5100, Q-inQ, does not work at all, only 
one(in one) vlan have the right to pass(VXLAN), L2TP Protocols don't have the 
rights to pass, funny thing

For years I discuss with local Juniper representative or Juniper team 
itself... but... no one cent about a solution once again, when I need a 
QinQ(full services), I use Cisco Catalysts

Don't expend time and energy trying to find a solution for this 
neglect

I heard the same thing about the version 18.x, but honestly... leave it 
there... I still prefer keep my environment work and running with 14.1X53 with 
Mpls stuffs and an EX facing the customer.   flow like water

 
Att.,
Alexandre Guimarães
+55.19. 3517-7724
+55.19. 99822.4866
 
alexandre.guimar...@ascenty.com
www.ascenty.com 
 
 

Em 11/09/2018 09:46, "juniper-nsp em nome de Alain Hebert" 
 escreveu:

 Hi,

 On QFX5100 the L2TP/Q-in-Q services has limitations.  I have to dig 
through my pile of tickets for details...  but I remember something 
about PVST+ packets not being forwarded at all.

 So we just switched everything to MPLS/l2circuits/VLAN CCC (for 
now) instead of battling with the QFX5100 platforms.  We'll deploy 
EVPN/VXLAN to our customers once we find a solution but we're not in a rush.

 PS: I heard a rumor that there is a fix in 18.x for the QFX5100...

 To note that the QFX5110 platform do not seem to be suffering from 
the same issues...  I suggest to get a demo to confirm the functionality.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 09/10/18 17:20, Pavel Lunin wrote:
> Hey,
>
> The Q-in-Q encapsulation comes from the EX2300 switches to the QFX 
switches
>> (the S-VLAN Q-in-Q tag is also 1001), but on the other end of the tunnel 
we
>> don't have the Q-in-Q frames coming.
>>
> I am curious if the packets don't leave the ingress VTEP at all or the
> tail-end VTEP can't treat them.
>
> "ping -f -s 1000" and "monitor interface traffic" can help to figure out
> where the packets are dropped. And if the VXLAN packets leave the
> core-facing interface of the ingress VTEP, I'd suggest to put a sniffer in
> the middle and take a look at the packets closely.
>
> Not that I am sure that it will work but... Juniper explicitly says that
> it's supported on all Trident2/2+/3-based switches in the very very fresh
> JUNOS (make sure that you don't miss this point).
>
> I suspect that it's not a honest Q-in-Q-in-VXLAN but some cheating, e. g.
> pop the VLAN tags and push them back on the other side, while VXLAN tunnel
> carries untagged / single-tagged frames. (Yes this requires per-vlan
> tunnels and might not work for your need).
>
> This is how VLAN-based Martini pseudowires work on those switches (even on
> EX4550, if memory serves). It's officially supported in 
EX-to-EX/QFX-to-QFX
> mode, where it works out-of-the-box, while in case where you have an
> MX-like router on the other end, you need to manually push/pop VLAN tags
> and disable control-word on the MX side (discussed many times in this 
list).
>
>
> --
> Pavel
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

Saku, just forgot

When we use l2circuits, you remove some layer of routing protocol 
troubleshooting. In just few command you know what’s going on.

In a flap, BGP session will be dropped after timers reached.

RSVP/ISIS/LDP will be affect immediately.  Also ISIS is the fundamental key of 
everything over here

With BGP, you have to check everything twice, including filters everywhere if 
someone change this or change that.



att
Alexandre

Em 7 de jul de 2018, à(s) 17:16, Mark Tinka  escreveu:

> 
> 
> On 7/Jul/18 18:03, Alexandre Guimaraes wrote:
> 
>> Yes! But... Ex4550 we have 32 ports 1/10Gb, using expansion slots, more 
>> 1/10Gb or 40Gb ports.  L2circuits, QinQ L2TP, vlan translation, rtg 
>> local-interface switching and so on...
>> 
>> We eat 1/10Gb ports, ASR920 didn’t help us with that.
> 
> Agreed - the ASR920 lacks port density. But, it does have the features, which 
> come at a decent price.
> 
> Depending on how things pan out with Broadcom in the few short years to come, 
> I think this will be a particularly good area for Arista to pick all their 
> competitors off, should they come right with their IP/MPLS software 
> implementations.
> 
> I feel the established/traditional equipment vendors are too busy producing 
> half-baked Broadcom-based solutions just to have a "cheap" option to deal 
> with customers considering Arista or white boxes; and focusing more on 
> pushing their heavily-bloated "data centre" switches at massive $$ premiums. 
> Slowly but surely, Arista (or anyone else copying their model) will rise to 
> fill the gap.
> 
> Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

Saku,

Indeed. iBGP will be redundant and resilient, yes... with a cost, 90 seconds 
(timers) of unavailability and more 1-3 minutes to get back online. I know, we 
can change timers, bfd and so on...  
 
I used that before... but

Not everyone have MX960, MX480 handling BGP in every part of the network, I 
don’t have...  I have QFX, hundreds of them. Now imagine in some MX, you have 
5/6 full routing table coming from upstream or peerings partners. Now 
experience a flap between two of those MX exchanging full routing table for a 
entire night
At some point, routing engines become angry and stop updating routes(normally, 
MX have a baaad routing update rate). Doomsday have arrived! 

Everyone gets crazy, angry customers blaming, services inside vpls, vpls 
getting loss bla bla bla

Degraded fibers keep flapping lights on/off less than 30/90 seconds, no iBGP 
alarms. No one knows what’s going on...

As I said: VPLS save me from the dark(another Operation History: Once Upon 
time: we used Portugal Telecom IP/MPLS solution), Now L2circuits now 
enlightened my days. I can sleep!

By the way, I still using VPLS/iBGP for point multipoint services.  

att
Alexandre

Em 7 de jul de 2018, à(s) 17:16, Mark Tinka  escreveu:

> 
> 
> On 7/Jul/18 18:03, Alexandre Guimaraes wrote:
> 
>> Yes! But... Ex4550 we have 32 ports 1/10Gb, using expansion slots, more 
>> 1/10Gb or 40Gb ports.  L2circuits, QinQ L2TP, vlan translation, rtg 
>> local-interface switching and so on...
>> 
>> We eat 1/10Gb ports, ASR920 didn’t help us with that.
> 
> Agreed - the ASR920 lacks port density. But, it does have the features, which 
> come at a decent price.
> 
> Depending on how things pan out with Broadcom in the few short years to come, 
> I think this will be a particularly good area for Arista to pick all their 
> competitors off, should they come right with their IP/MPLS software 
> implementations.
> 
> I feel the established/traditional equipment vendors are too busy producing 
> half-baked Broadcom-based solutions just to have a "cheap" option to deal 
> with customers considering Arista or white boxes; and focusing more on 
> pushing their heavily-bloated "data centre" switches at massive $$ premiums. 
> Slowly but surely, Arista (or anyone else copying their model) will rise to 
> fill the gap.
> 
> Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

> Have you considered the Cisco ASR920 if you are running MPLS pw's on your 
> EX4550's?


Yes! But... Ex4550 we have 32 ports 1/10Gb, using expansion slots, more 1/10Gb 
or 40Gb ports.  L2circuits, QinQ L2TP, vlan translation, rtg local-interface 
switching and so on...

We eat 1/10Gb ports, ASR920 didn’t help us with that.

I am waiting local Juniper team test the new ACX5448 with services that I run, 
to see what way I will follow,  I will keep everyone posted

Att
Alexandre
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

Saku,

Mark is correct, l2circuits are end-to-end services where uptime is based at 
the termination points,
Inside the backbone, every l2circuits works under LSP with FRR, so...  from on 
point to another, LSP can search the best route, put in place a second best 
route(standby), how many routes you want...

If we experience some degraded fiber/service, checking the LSP, we know where 
to look. And after disabling that segment of network, all problem solved.

Tshoot time decreased to few minutes only, and this makes everyone happy.

VPLS is very good when you use one port per customer, 1/10Gb, when you have to 
set trunk ports of 10Gb and put lots of vlan in a VC of 5to10 QFX switches,  
things gone wild...  one error, a l2 loop will shut every customer inside that 
distribution POD.

Think that layer2 still inside the vpls instance inside the MX routers and drop 
down to the VC. You can loop easily, yes, here, ops team did l2 loop two times 
in one year, dropping more than 500 customers. With a big impact after the 
second, the order was to move to
L2circuits, Mac learning and so one still resides at cpe equipment, and the 
core still clean.

I’m just sharing my operational experience and fears, quality of services 
offered... we provide last mile connect from carriers like Verizon, Orange, 
Algar, British Telecom and so on... so quality of service and availability is 
the rule of the business. Also we provide l2circuits of 10/40/100Gbps for ISP 
over here. So, quality and uptime is the focus.

ELS cli bring me some problem with QinQ L2TP services since it doesn’t works, 
also with the RTG, doesn’t work to, cause that I still using ex2200, ex3300.

About those Aristas, I don’t have notice if some one use them as a P router or 
if they have xconnect/l2circuits services, even local Arista dealer knows 
we have some Aristas working only with layer2/3 for colocation services inside 
our datacenters facilities.



att
Alexandre

Em 7 de jul de 2018, à(s) 09:38, Mark Tinka 
mailto:mark.ti...@seacom.mu>> escreveu:



On 7/Jul/18 14:16, Saku Ytti wrote:


I feel your frustration, but to me it feels like there is very little
sharable knowledge in your experience.

Hmmh, I thought there was a fair bit, explicit and inferred. I feel Alexandre 
could have gone on more than his TL;DR post allowed for :-).



 You seem to compare full-blown
VPLS, with virtual switch and MAC learning to single LDD martini. You
also seem to blame BGP pseudowires for BGP transport flapping, clearly
you'd have equally bad time if LDP transport flaps, but at least in
BGP's case you can have redundancy via multiple RR connections, with
LDP you're reliant on the single session.

Sounded like BGP flaps was one of several problems Alexandre described, 
including an unruly BGP routing table, et al.

Not sure how relevant RR redundancy is per your argument, as ultimately, a 
single customer needing an end-to-end pw is mostly relying on the uptime of the 
PE devices at each end of their circuit, and liveliness of the core. If those 
pw's are linked by an LDP thread, what would a 2nd LDP-based pw (if that were 
sensibly possible) bring to the table?  I'm not dissing BGP-based pw signaling 
in any way or form, but for that, you'd need "Router + IGP + BGP + RR + RR" to 
be fine. With LDP-based signaling for just this one customer, you only need 
"Router + IGP + LDP" to be fine.

Personally, I've never deployed VPLS, nor had the appetite for it. It just 
seemed like a handful on paper the moment it was first published, not to 
mention the war stories around it from the brave souls that deployed it when 
VPLS was the buzzword then that SDN is these days. It certainly made the case 
for EVPN, which I still steer clear from until I find a requirement that can't 
be solved any other way.

Again, no dis to anyone running VPLS; just much respect to you for all your 
nerve :-).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

My Usage Cent

My core Network, P and PE, are 100% Juniper

We start using VPLS, based in BGP sessions, at that time we was working at 
maximum of 2 or 3 new provisions per day.
We won a big project contract, we reach 90/100 per month.
VPLS become a issue in all fronts...

Planning/ low ports - price of 10G ports using MX and rack space usage

Provisioning... vlan remap, memory usage of the routers and 2000/2500 
circuits/customers per MX

Tshoot, a headache to find the signaling problem when, for example: fiber 
degraded, all BGP sessions start flapping and the things become crazy and the 
impact increase each minute.

Operating, vpls routing table become a pain is the ass when you use multipoint 
connections and with Lucifer reason, those multipoint become unreachable and 
the vpls table and all routing tables become ruge to analyze.

Regarding L2circuits using Ldp 

We migrate every vpls p2p to L2circuits, with that...

Very fast provisioning, 6 lines of configuration per box.

Fast tshoot, 
less MX, more QFX/EX4550/ACX2200

End to end circuits... ripping of all those routes from tables keeping tables 
clean as possible.

Today I can sleep a entire night, weeks and month with a problem of those MX 
dying due vpls memory usage, vlan misconfigured causing l2 looping.

My efforts today is working only with l2circuits... that’s the problem that I 
am facing now...

Ex4550 will be EOS soon... with no replacement of features...  maybe the 
ACX5448? Who knows

L2circuits is clean and fast... with no mistakes
I use, rsvp/mpls/isis/ldp routing services in every MX family, ex4550, qfx, 
acx2200 that I have, Everyone knows everyone, l2circuits reach everyone part 
and every city where we have our network.



att
Alexandre

Em 7 de jul de 2018, à(s) 08:16, Mark Tinka  escreveu:

> 
> 
>> On 7/Jul/18 13:03, James Bensley wrote:
>> 
>> Ah, I remember that thread. It became quite long and I was very busy
>> so I lost track of it. Just read through it. I also looked at LDPv6 a
>> while back and saw it was not well supported so passed. For us 6PE
>> (and eventually 6vPE as we move to Internet in a VRF) "just works".
>> IPv6 native in SR isn't actually enough of a reason for me to migrate
>> to it I don't think.
> 
> LDPv6 implementation in IOS XR was a bit spotty 2 years. After our next
> round of code upgrades later this year on Cisco and Juniper, I'll see
> where we are and target to get LDPv6 going before we close out 2018.
> 
> 
>> You mentioned in the NANOG thread that you wanted to remove BGP from
>> your core - are you using 6PE or BGP IPv6-LU on every hop in the path?
>> I know you are a happy user of BGP-SD so I guess it's Internet in the
>> GRT for you?
> 
> I removed BGPv4 from the core back in 2008 (previous job). So all IPv4
> traffic is forwarded inside MPLS, purely label-switched in the core.
> This is just simple LDP signaling + MPLS forwarding toward a BGP next-hop.
> 
> For IPv6, as LDPv6 is not yet fully deployed around the network, we are
> still carrying BGPv6 in the core. That is normal hop-by-hop IP
> forwarding. We don't like 6PE or anything like that because it still
> depends on IPv4; I'd much rather run both protocols ships-in-the-night.
> That way, if one of them were to break, chances are the other should
> still be good.
> 
> We don't do Internet in a VRF. Seems like too much headache, but that's
> just me, as I know it's a very popular architecture with many operators
> out there. We carry all routing in global, as you rightly point out,
> making heavy use of iBGP and communities to create excitement :-).
> 
> We love BGP-SD -- it means we can deliver the same types of services on
> all platforms in all sections of the network, be it in the data centre
> or Metro, or be it on a big chassis or a tiny 1U router, or be it in a
> large or small PoP.
> 
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: QFX5100 vs ACX5048

[Alexandre Guimaraes]

Aaron,
I am using 15.1X54-D51.7, I will try D61.6 version, Let´s see.

I moved out all Carriers NNI almost 2 years ago and never 
change anymore since that fatidic day, now the impact will affect only ethernet 
l2circuits.



--- JUNOS 15.1X54-D51.7 built 2016-08-22 17:14:59 UTC
{master:0}
> show system uptime
fpc0:
--
Current time: 2018-07-02 11:03:15 BRT
.
.
.
11:03AM  up 647 days,  8:57, 1 user, load averages: 0.13, 0.10, 0.08


Att
Alexandre

De: Aaron Gould 
Enviada em: segunda-feira, 2 de julho de 2018 10:17
Para: 'Giuliano C. Medalha' ; Alexandre Guimaraes 

Cc: 'Juniper List' 
Assunto: RE: [j-nsp] QFX5100 vs ACX5048

ACX5048

15.1X54-D61.6

- Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: QFX5100 vs ACX5048

[Alexandre Guimaraes]

Same over here  vlan leaking

De: Gustavo Santos 
Enviada em: segunda-feira, 2 de julho de 2018 10:11
Para: Alexandre Guimaraes 
Cc: Colton Conor ; juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] QFX5100 vs ACX5048

I had some issues with ACX5048 , the most noticable was arp packets from pure 
L2 vlans and VPLS punting to CPU and flooding the default arp policer police..
JTAC was able to reproduce the issue and gave us an option to disable default 
arp policer until they release a service release to fix this issue that was 
solved indeed.

Another problem was upgrading to the lastest Junos JTAC recommended that made 
the ACX5048 unusable... ( Junos was unable to find the physical ports..)  We 
had to downgrade to get it back working again..

On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes 
mailto:alexandre.guimar...@ascenty.com>> wrote:
Better in terms of concept. In term of usage, i still investing in qfx5100

Acx5058 Suppose to be a promise of a new future, unfortunately, with all 
problematic of the qfx5100 hardware, the acx5048 leak vlan till the last breath 
of cpu after that, all deamons and services going down up and down, up 
and down.

I never more brought one peace ACX5048 after jtac didnt responds why and 
solution for the leaking...( I have only two acx5048 and hundreds on QFX...).

The new promise is the new acx5448. No vlan leaking, a good load balance(ae) 
algorithm, full of this full of that a lot of promise.

Let’s see...

att
Alexandre

Em 1 de jul de 2018, à(s) 19:31, Colton Conor 
mailto:colton.co...@gmail.com>> escreveu:

> What is the main difference between these two boxes? Hardware wise they
> look identical. Is there anything on the hardware side that makes the
> ACX5048 better than a QFX5100, or is it only software related?
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 vs ACX5048

[Alexandre Guimaraes]

Better in terms of concept. In term of usage, i still investing in qfx5100

Acx5058 Suppose to be a promise of a new future, unfortunately, with all 
problematic of the qfx5100 hardware, the acx5048 leak vlan till the last breath 
of cpu after that, all deamons and services going down up and down, up 
and down.

I never more brought one peace ACX5048 after jtac didnt responds why and 
solution for the leaking...( I have only two acx5048 and hundreds on QFX...).

The new promise is the new acx5448. No vlan leaking, a good load balance(ae) 
algorithm, full of this full of that a lot of promise.

Let’s see...

att
Alexandre

Em 1 de jul de 2018, à(s) 19:31, Colton Conor  escreveu:

> What is the main difference between these two boxes? Hardware wise they
> look identical. Is there anything on the hardware side that makes the
> ACX5048 better than a QFX5100, or is it only software related?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ipsec tunnel flapping

[Alexandre Guimaraes]

Sameer


Reason: IPSec SA delete payload received from peer, corresponding IPSec SAs 
cleared

This is a phase 2 problem, maybe deadpeerdetection failure, VPN monitoring 
failure, a failure during rekey when old SA is deleted notification sent to 
delete old SA. Most of the cases.



att
Alexandre

Em 25 de jun de 2018, à(s) 03:42, sameer mughal 
mailto:pcs.same...@gmail.com>> escreveu:

both sites on srx.
following are the logs.

 show log junilog|match st0.15
Jun 25 01:47:51   rpd[1867]: EVENT  st0.15 index 86 
Jun 25 01:47:51   rpd[1867]: EVENT UpDown st0.15 index 86 
Jun 25 01:47:51   rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 -> 
10.115.10.2 
Jun 25 01:47:51   kmd[1902]: KMD_VPN_DOWN_ALARM_USER: VPN IPSEC-15-VPN from 
103.229.87.66 is down. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW, vpn 
name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote 
tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID: 
103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , 
Traffic-selector local ID: 
ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), Traffic-selector remote 
ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), SA Type: Static, 
Reason: IPSec SA delete payload received from peer, corresponding IPSec SAs 
cleared
Jun 25 01:47:51   mib2d[1865]: SNMP_TRAP_LINK_DOWN: ifIndex 588, ifAdminStatus 
up(1), ifOperStatus down(2), ifName st0.15
Jun 25 01:48:06   kmd[1902]: KMD_VPN_UP_ALARM_USER: VPN IPSEC-15-VPN from 
103.229.87.66 is up. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW, vpn 
name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote 
tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID: 
103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , 
Traffic-selector local ID: 
ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), Traffic-selector remote 
ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), SA Type: Static
Jun 25 01:48:06   rpd[1867]: EVENT  st0.15 index 86 
Jun 25 01:48:06   rpd[1867]: EVENT UpDown st0.15 index 86 
Jun 25 01:48:06   rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 -> 
10.115.10.2 
Jun 25 01:48:06   mib2d[1865]: SNMP_TRAP_LINK_UP: ifIndex 588, ifAdminStatus 
up(1), ifOperStatus up(1), ifName st0.15
Jun 25 01:51:52   kmd[1902]: KMD_VPN_DOWN_ALARM_USER: VPN IPSEC-15-VPN from 
103.229.87.66 is down. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW, vpn 
name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote 
tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID: 
103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , 
Traffic-selector local ID: 
ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), Traffic-selector remote 
ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), SA Type: Static, 
Reason: IPSec SA delete payload received from peer, corresponding IPSec SAs 
cleared
Jun 25 01:51:52   rpd[1867]: EVENT  st0.15 index 86 
Jun 25 01:51:52   rpd[1867]: EVENT UpDown st0.15 index 86 
Jun 25 01:51:52   rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 -> 
10.115.10.2 
Jun 25 01:51:52   mib2d[1865]: SNMP_TRAP_LINK_DOWN: ifIndex 588, ifAdminStatus 
up(1), ifOperStatus down(2), ifName st0.15
Jun 25 01:52:07   rpd[1867]: EVENT  st0.15 index 86 
Jun 25 01:52:07   rpd[1867]: EVENT UpDown st0.15 index 86 
Jun 25 01:52:07   kmd[1902]: KMD_VPN_UP_ALARM_USER: VPN IPSEC-15-VPN from 
103.229.87.66 is up. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW, vpn 
name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote 
tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID: 
103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , 
Traffic-selector local ID: 
ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), Traffic-selector remote 
ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0<http://0.0.0.0/0>), SA Type: Static
Jun 25 01:52:07   rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 -> 
10.115.10.2 
Jun 25 01:52:07   mib2d[1865]: SNMP_TRAP_LINK_UP: ifIndex 588, ifAdminStatus 
up(1), ifOperStatus up(1), ifName st0.15

{primary:node0}

On Mon, Jun 25, 2018 at 3:03 AM, Alexandre Guimaraes 
mailto:alexandre.guimar...@ascenty.com>> wrote:
Have you checked the errors? Do a deep Inspection and check the packets to see 
what’s the behavior that’s trigger the down state. Tcpdump Will give you hints.

Both sides uses SRX?

att
Alexandre

Em 24 de jun de 2018, à(s) 07:59, sameer mughal 
mailto:pcs.same...@gmail.com>> escreveu:

> Hi All,
> I am facing ipsec tunnel flapping issue on srx550. Both sides isp links are
> up and stable but still tunnel is flapping.
> Can anyone facing similar problem or any solution to fix this issue?
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.ne

Re: [j-nsp] Ipsec tunnel flapping

[Alexandre Guimaraes]

Have you checked the errors? Do a deep Inspection and check the packets to see 
what’s the behavior that’s trigger the down state. Tcpdump Will give you hints.

Both sides uses SRX?

att
Alexandre

Em 24 de jun de 2018, à(s) 07:59, sameer mughal  
escreveu:

> Hi All,
> I am facing ipsec tunnel flapping issue on srx550. Both sides isp links are
> up and stable but still tunnel is flapping.
> Can anyone facing similar problem or any solution to fix this issue?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] iSCSI on EX4550 switch port

[Alexandre Guimaraes]

Mark,

Ex4550 give me local interface l2circuits switching bypassing all traffic 
without change, I am looking for a switch that have the same feature with 
48ports 1/10Gb. And of course all other ex4550 features. QinQ with L2TP and so 
on...

If you know some brand and model, I will be glad to know.

att
Alexandre

Em 8 de jun de 2018, à(s) 07:52, Mark Tinka 
mailto:mark.ti...@seacom.mu>> escreveu:

We are going Arista.

For basic Layer 2 Ethernet switching, it's going to do the job, with Gigs of 
buffer memory.

The back-breaker for us was when Juniper decided to do silly things with the 
CLI in the EX4600 vs. what we'd been used to with the EX4550. Since it took 
them a year to tell me they'll make the EX4600 CLI as simple as the EX4550 one 
in 2019, I jumped ship. Fair point, the still-small buffers on the EX4600 
didn't help either...

Mark.

On 8/Jun/18 12:21, Alexandre Guimaraes wrote:

I agree with Mark.

Unfortunately, There is no other switch with the same features with more 
buffer. As far as I know.

att
Alexandre

Em 8 de jun de 2018, à(s) 07:05, Mark Tinka 
<mailto:mark.ti...@seacom.mu> escreveu:



The EX4550 has terribly small buffers (4MB if memory serves - pun intended).

Do you have this setup:

set class-of-service shared-buffer percent 100

It has helped us for a while, but it's time to kick this box out.

Mark.



On 8/Jun/18 07:55, Simone Spinelli wrote:
MTU?
Ethernet flow control?

My 2 cents.
Simone



On Fri, 8 Jun 2018 at 01:28, Jonathan Call 
<mailto:lordsit...@hotmail.com> wrote:

I have a NetApp using iSCSI sitting on an EX4550. The iSCSI port on the
EX4500 is dropping packets on a regular basis, but its queue length is
always zero:

 Queue counters:   Queued packets  Transmitted packets  Dropped
packets
   0 best-effort0   1518576563
1510331
   1 assured-forw   00
   0
   5 expedited-fo   00
   0
   7 network-cont   0   138429
   0

Before I start messing with queues/Class of Service setting I'm curious if
anyone has seen this before and might steer me in a good direction to find
out what is going on? (Other than getting rid of this old EX4550)

Jonathan

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
.



___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Going Juniper

[Alexandre Guimaraes]

Hello everyone!

Last notice that I have about Junos fusion, some features doesn’t work in to 
satellite ports, like ethernet ccc.

Did you guys that use, can confirm that, or all features are available?

att
Alexandre

Em 11 de abr de 2018, à(s) 08:11, Ola Thoresen  escreveu:

> On 11. april 2018 12:51, Saku Ytti wrote:
> 
>> On 11 April 2018 at 13:43, Ola Thoresen  wrote:
>> 
>> 
>>> We have recently started playing with MX204 and Junos Fusion, and that makes
>>> a really nice setup.
>>> With either EX4300 (for 1G) or QFX5100 (for 10G), you get a lot of ports and
>>> a great routing engine for a "decent" cost.
>> I have strong dislike to satellite solutions. I'd rather even run L2
>> backhaul than satellite. There tends to be all kind of catches and
>> esoteric differences between 'native' port and satellite port, and
>> those are not documented anywhere, probably not even known to vendor,
>> and you just stumble on them as you go. As well as you have to carry
>> the increased bug surface of the vendor's proprietary host<->satellite
>> code.
>> 
>> 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 have 
> more or less managed to do it right.  They use pretty standard protocols for 
> everything, it is just "packaged" so you don't need to think about it.
> 
> But as you say, you can easily use the exact same hardware in a regular L2 
> setup, the thing you gain from the satellite setup is central management of 
> only the routers, which can be a time and management saver.
> 
> /Ola (T)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexandre Guimaraes]

Behalf of the problems that you guys are facing...

I have another one with RSVP neighbor issue.

QFX5100 running   14.1X53-D46.7 and QF5110 running 17.4R1-S1.9 (and others SR 
version) doen´s work the RSVP protocol - neighbor don’t come up.

Juniper ATAC recognized the problem and they ask to me to upgrade all (more 
than 70 units in production) QFX5100 to save version/release.

They even know how to solve the problem...  

Alexandre

-Mensagem original-
De: juniper-nsp  Em nome de Nitzan 
Tzelniker
Enviada em: quarta-feira, 28 de março de 2018 16:44
Para: ber...@luffy.cx
Cc: juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] BGP EVPN, VXLAN and ECMP

Not sure I understand you but both can run 17.3R2 (just time of
installation )


On Wed, Mar 28, 2018 at 10:16 PM Vincent Bernat  wrote:

>  ❦ 28 mars 2018 19:06 GMT, Nitzan Tzelniker  :
>
> > The 5100 run 15.1X53-D63 and the 5110 17.3R2
>
> Do you mean the other way around? No 15.1X53 for the 5100.
> --
> Use statement labels that mean something.
> - The Elements of Programming Style (Kernighan & Plauger)
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with MX10003

[Alexandre Guimaraes]

Agreed with Mark.

I have the same discussion with Giuliano about that. 

Expensive line cards against 40/100 mx204 or MX10003.

We are using QFX5110 and QFX5100 at transport layer (P) where (up to)40km is 
the distance. Keeping MX960 and MX480 delivering services (PE).

The detail about those MXs, and why not put services on them is the 
reliability/redundancy, as a P only, if they crash, all services still running 
on PE equipments.

I think that’s the clue about Juniper’s investment and business way


My cents...

att
Alexandre

Em 26 de jan de 2018, à(s) 03:34, Mark Tinka  escreveu:

> 
> 
>> On 25/Jan/18 20:42, Giuliano C. Medalha wrote:
>> 
>> We are testing the MX10003 right now.
> 
> We're looking at the MX10003 to support customers in the edge who want
> to connect at 40Gbps or 100Gbps. Seems to make more sense to handle
> 1Gbps and 10Gbps links on our MX480, and do the 40Gbps and 100Gbps on
> the MX10003, and avoid having to put expensive MPC's into the MX480 rather.
> 
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] l2circuit down one side/up another

[Alexandre Guimaraes]

Caio,

Have you check something?

Are these extremes let the signaling pass thru?

att
Alexandre

Em 21 de out de 2017, à(s) 07:54, Rafael Ganascim 
> escreveu:

Just more checks:

How is the MPLS forwarding table for the negotiated Labels for loopback and
l2circuit?
Are you using label PHP? Can you switch It off?
Is the LDP adjacency up and exchanging labels?
Are the l2circuit neighbors configured between loopback interfaces?

Regards,




Em 20 de out de 2017 8:26 AM, "Caio" 
> escreveu:

Hello people,

There's a weird problem I would like to share with you.
I have the following scenario:

MX104 -> L2 SW (1) -> L2 SW (2) -> MX80

Both L2 SW are Extreme X460 and they're doing nothing except forwarding
frames at layer 2.

In order to simplify our topology, we have changed the MX104 uplink to L2
SW (2) so the topology went to MX104 -> L2 SW (2) -> MX80.

After that, the BGP sessions went up and all the traffic has returned as
expected, however I have three l2circuit connections (vlan-ccc mode) and
they went to "Down (OL)" status at one side and Up at another. In order to
reestablish them we had to do a rollback of the physical changes we did.

As it just don't make any sense to me, I summon you experts to help me with
that, so we can try to figure out what went wrong.

Additional details: I'm using LDP signaling at both sides. It' a point to
point L3 connection, so I have the loopback interfaces configured at both
sides and a /30 between them, also I have static routes to reach their
loopback interface's addresses.

Any help will be appreciated.

Cheers,
Caio
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] l2circuit down one side/up another

[Alexandre Guimaraes]

MTU?

RSVP ISIS/OSPF LDP neighborhood are ok?

Loopback filters?

att
Alexandre

Em 20 de out de 2017, à(s) 08:26, Caio 
> escreveu:

Hello people,

There's a weird problem I would like to share with you.
I have the following scenario:

MX104 -> L2 SW (1) -> L2 SW (2) -> MX80

Both L2 SW are Extreme X460 and they're doing nothing except forwarding
frames at layer 2.

In order to simplify our topology, we have changed the MX104 uplink to L2
SW (2) so the topology went to MX104 -> L2 SW (2) -> MX80.

After that, the BGP sessions went up and all the traffic has returned as
expected, however I have three l2circuit connections (vlan-ccc mode) and
they went to "Down (OL)" status at one side and Up at another. In order to
reestablish them we had to do a rollback of the physical changes we did.

As it just don't make any sense to me, I summon you experts to help me with
that, so we can try to figure out what went wrong.

Additional details: I'm using LDP signaling at both sides. It' a point to
point L3 connection, so I have the loopback interfaces configured at both
sides and a /30 between them, also I have static routes to reach their
loopback interface's addresses.

Any help will be appreciated.

Cheers,
Caio
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic

[Alexandre Guimaraes]

Aaron,

   I use them, yes, not in the lab, in the real world, the distance is 37km.

   40Km transceiver use high power, much more than 10km transceivers, you have 
to attenuate to decrease power and fit the threshold.
Use “show interface diagnostic optics et-0/0/x” to check the levels.

The acx or any other Juniper switch will disable the interface if the 
signal does not match the threshold.

att
Alexandre

Em 4 de out de 2017, à(s) 21:04, Aaron Gould 
> escreveu:

Well, when the transport eng I work with found out that I had these two 40km 
optics connected with a 3’ jumper he ran into the lab to disconnect it…. So 
that’s probably why you see no light right now…. Lemme get back into the office 
Monday and we will go from there… yeah, as I mentioned I’m working with my 
Juniper account SE on this, so he may update support matrix if he discovers 
they are good…. I dunno.



Thanks



-Aaron



___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: ACX5048 - 40 gbps ER 40 km optic

[Alexandre Guimaraes]

Aaron,

Sounds strange this behavior, since i have both ACX5048 and QFX5100 
work with them very well.

Now, try to attenuate the fibers between those  switches,  40Km works 
with high power in the TX for low distances. Inside the lab, the multimode QSFP 
is my recommendation.

Probably, the other end are receiving too much power.



   Laser output power high alarm threshold   
Laser output power low alarm threshold
Laser output power high warning threshold 
Laser output power low warning threshold  
Laser rx power high alarm threshold 
Laser rx power low alarm threshold
Laser rx power high warning threshold 
Laser rx power low warning threshold  



Alexandre

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Aaron 
Gould
Enviada em: quarta-feira, 4 de outubro de 2017 16:21
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] ACX5048 - 40 gbps ER 40 km optic

I put this into my ACX5048 in the lab today. actually 2 of them.
QSFP+-40G-ER4 (aka QSFPP-40GBASE-ER4) SMF 40 km 1310 nm optic

 

Optic is seen in cli, but I see no led's on chassis and when I plug them into 
each other, interfaces stay up/down.

 

Is there something I need to do to make this 40 gig optic work in the
ACX5048 (JUNOS 15.1X54-D61.6) ?

 

{master:0}
agould@eng-lab-5048-2> show interfaces terse | grep et-
et-0/0/48   updown
et-0/0/49   updown

{master:0}
agould@eng-lab-5048-2> show interfaces et-0/0/48 Physical interface: et-0/0/48, 
Enabled, Physical link is Down
  Interface index: 657, SNMP ifIndex: 582
  Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 40Gbps, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Disabled, Media type: Fiber
  Device flags   : Present Running Down
  Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Current address: 20:4e:71:45:d3:d3, Hardware address: 20:4e:71:45:d3:d3
  Last flapped   : 2017-10-04 10:26:33 CDT (00:09:14 ago)
  Input rate : 0 bps (0 pps)
  Output rate: 0 bps (0 pps)
  Active alarms  : LINK
  Active defects : LINK
  Interface transmit statistics: Disabled

{master:0}
agould@eng-lab-5048-2> show interfaces et-0/0/49 Physical interface: et-0/0/49, 
Enabled, Physical link is Down
  Interface index: 658, SNMP ifIndex: 583
  Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 40Gbps, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Disabled, Media type: Fiber
  Device flags   : Present Running Down
  Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Current address: 20:4e:71:45:d3:d7, Hardware address: 20:4e:71:45:d3:d7
  Last flapped   : 2017-10-04 10:27:53 CDT (00:07:56 ago)
  Input rate : 0 bps (0 pps)
  Output rate: 0 bps (0 pps)
  Active alarms  : LINK
  Active defects : LINK
  Interface transmit statistics: Disabled

{master:0}
agould@eng-lab-5048-2> show chassis hardware Hardware inventory:
Item Version  Part number  Serial number Description
Chassis(removed...)  ACX5048
Pseudo CB 0
Routing Engine 0  BUILTIN  BUILTIN   ACX5K Routing
Engine
FPC 0REV 07   650-060546   (removed...)  ACX5048
  CPU BUILTIN  BUILTIN   FPC CPU
  PIC 0   BUILTIN  BUILTIN   48x10G-6x40G

Xcvr 48  REV 01   740-059185   (removed...)  QSFP+-40G-ER4
Xcvr 49  REV 01   740-059185   (removed...)  QSFP+-40G-ER4
Power Supply 0   REV 04   740-043886   (removed...)  JPSU-650W-DC-AFO
Power Supply 1   REV 04   740-043886   (removed...)  JPSU-650W-DC-AFO
Fan Tray 0   ACX5K Fan Tray 0,
Front to Back Airflow - AFO
Fan Tray 1   ACX5K Fan Tray 1,
Front to Back Airflow - AFO
Fan Tray 2   ACX5K Fan Tray 2,
Front to Back Airflow - AFO
Fan Tray 3   ACX5K Fan Tray 3,
Front to Back Airflow - AFO
Fan Tray 4   ACX5K Fan Tray 4,
Front to Back Airflow - AFO




{master:0}
agould@eng-lab-5048-2> show chassis pic pic-slot 0 fpc-slot 0 FPC slot 0, PIC 
slot 0 information:
  Type 48x10G-6x40G
  StateOnline
  PIC version  2.7
  Uptime 99 days, 23 hours, 26 minutes, 3 seconds

PIC port information:
 FiberXcvr vendor   Wave-
Xcvr
  Port Cable typetype  Xcvr vendorpart number   length
Firmware
  48   40GBASE ER4 

Re: [j-nsp] A wierd problem with QinQ at QFX5100

[Alexandre Guimaraes]

That's my friend Giuliano My mentor!!

All information that he provides is 100% correct.

att
Alexandre

> Em 27 de mai de 2017, às 16:51, Giuliano C. Medalha <giuli...@wztech.com.br> 
> escreveu:
> 
> Andrew
> 
> Good afternoon.
> 
> Q-in-Q works fine here for us in our production networks and in our labs.
> 
> Do you need the a sample config ?
> 
> We need to umderstand the topology to help. You can contact us in private.  
> Can you share with us ?
> 
> The problem is not qinq itself ... the problem is the limited numbers of 
> protocols supported by L2PT in Junos ELS ( for qfx5100 )
> 
> My sugestion is to buy the EDGE license and use MPLS L2circuit to transport 
> protocols PDUs ... only if you need it.
> 
> But if you does not need the pdu transport and need point to multipoint 
> solutions ... another way is to use VXLAN / EVPN config.  Works fine for the 
> QFX family
> 
> We have this solutions implemented in some service providers and DC 
> environments ... and they use an access switch ( like ex2200 ) to encapsulate 
> pdu using qinq before the qfx5100. Works fine and we can automate it with a 
> tool that we developed ( in cloud ) to provision the vxlan tunnel on each 
> qfx5100 interface.
> 
> Hope this helps
> 
> Att,
> 
> Giuliano C. Medalha
> WZTECH NETWORKS
> +55 (17) 98112-5394
> giuli...@wztech.com.br<mailto:giuli...@wztech.com.br>
> 
> From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of Andrew 
> Osnach <and...@osnach.kiev.ua>
> Sent: Wednesday, May 24, 2017 11:33:20 AM
> To: Alexandre Guimaraes; Allan Eising
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] A wierd problem with QinQ at QFX5100
> 
> Hi guys,
> 
> Thank you for the answers. It's really sad to hear about it and there're
> two equally unsatisfactory solutions: vlan mapping or vlan ranges
> reservation..
> 
> Thanks again for the explanation!
> 
> 
>> On 23.05.17 14:52, Alexandre Guimaraes wrote:
>> Andrew
>> 
>> Unfortunately, Allan is correct... don't expect use QinQ in ELS system, will 
>> be very annoying trying to find a way the let the packets flow inside. And 
>> they don't flow gracefully
>> 
>> A friend told to me:  QFX are Ferraris I answer him: then Juniper, don't 
>> knows how to drive.
>>  :)
>> 
>> att
>> Alexandre
>> 
>>> Em 23 de mai de 2017, às 06:00, Allan Eising <eis...@nordu.net> escreveu:
>>> 
>>> Excerpts from Andrew Osnach's message of May 23, 2017 10:31 am:
>>>> Hello,
>>>> 
>>>> I have a mixed VC (QFX5100 and 3500, if it means) with 14.1X53-D40.8.
>>>> There's an interface that incapsulates C-VLANs into S-VLAN:
>>>> 
>>>> set interfaces ae31 flexible-vlan-tagging
>>>> set interfaces ae31 mtu 9216
>>>> set interfaces ae31 encapsulation extended-vlan-bridge
>>>> set interfaces ae31 unit 3174 vlan-id-list 21-22
>>>> set interfaces ae31 unit 3174 input-vlan-map push
>>>> set interfaces ae31 unit 3174 input-vlan-map vlan-id 3174
>>>> set interfaces ae31 unit 3174 output-vlan-map pop
>>>> 
>>>> The other side:
>>>> 
>>>> set interfaces ae0 flexible-vlan-tagging
>>>> set interfaces ae0 mtu 9216
>>>> set interfaces ae0 encapsulation extended-vlan-bridge
>>>> set interfaces ae0 unit 3174 vlan-id 3174
>>>> 
>>>> S-VLAN configured like this:
>>>> set vlans sv3174-qinq interface ae0.3174
>>>> set vlans sv3174-qinq interface ae31.3174
>>>> 
>>>> At this point everything works fine, but if I create a VLAN with the
>>>> same ID as a C-VLAN (21 or 22):
>>>> set vlans v21-user vlan-id 21
>>>> the traffic in the C-VLAN 21 stops.
>>>> When I delete v21-user the traffic in C-VLAN 21 restores.
>>>> 
>>>> What's wrong with it and how can I fix it?
>>>> 
>>> Hi,
>>> 
>>> QinQ on the QFX and all the other boxes running the ELS style is a bit
>>> of an abomination.
>>> 
>>> VLANs configured with extended-vlan-bridge interfaces are forwarded
>>> using a different daemon than VLANs forwarded using the
>>> classic ethernet-switching daemon.
>>> 
>>> It's quite likely that you cannot share VLAN IDs between the two methods of 
>>> forwarding.
>>> 
>>> I would bug Juniper about this, but I wouldn't expect them to be able to
>>> fix it.
>>> 
>>> Best regards,
>>> 
>>> Allan Eising
>>> 
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] A wierd problem with QinQ at QFX5100

[Alexandre Guimaraes]

Andrew

Unfortunately, Allan is correct... don't expect use QinQ in ELS system, will be 
very annoying trying to find a way the let the packets flow inside. And they 
don't flow gracefully

A friend told to me:  QFX are Ferraris I answer him: then Juniper, don't 
knows how to drive.
 :)

att
Alexandre

> Em 23 de mai de 2017, às 06:00, Allan Eising  escreveu:
> 
> Excerpts from Andrew Osnach's message of May 23, 2017 10:31 am:
>> Hello,
>> 
>> I have a mixed VC (QFX5100 and 3500, if it means) with 14.1X53-D40.8.
>> There's an interface that incapsulates C-VLANs into S-VLAN:
>> 
>> set interfaces ae31 flexible-vlan-tagging
>> set interfaces ae31 mtu 9216
>> set interfaces ae31 encapsulation extended-vlan-bridge
>> set interfaces ae31 unit 3174 vlan-id-list 21-22
>> set interfaces ae31 unit 3174 input-vlan-map push
>> set interfaces ae31 unit 3174 input-vlan-map vlan-id 3174
>> set interfaces ae31 unit 3174 output-vlan-map pop
>> 
>> The other side:
>> 
>> set interfaces ae0 flexible-vlan-tagging
>> set interfaces ae0 mtu 9216
>> set interfaces ae0 encapsulation extended-vlan-bridge
>> set interfaces ae0 unit 3174 vlan-id 3174
>> 
>> S-VLAN configured like this:
>> set vlans sv3174-qinq interface ae0.3174
>> set vlans sv3174-qinq interface ae31.3174
>> 
>> At this point everything works fine, but if I create a VLAN with the
>> same ID as a C-VLAN (21 or 22):
>> set vlans v21-user vlan-id 21
>> the traffic in the C-VLAN 21 stops.
>> When I delete v21-user the traffic in C-VLAN 21 restores.
>> 
>> What's wrong with it and how can I fix it?
>> 
> 
> Hi,
> 
> QinQ on the QFX and all the other boxes running the ELS style is a bit
> of an abomination.
> 
> VLANs configured with extended-vlan-bridge interfaces are forwarded
> using a different daemon than VLANs forwarded using the
> classic ethernet-switching daemon.
> 
> It's quite likely that you cannot share VLAN IDs between the two methods of 
> forwarding.
> 
> I would bug Juniper about this, but I wouldn't expect them to be able to
> fix it.
> 
> Best regards,
> 
> Allan Eising
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RES: RES: QFX 5100 and Q-in-Q

[Alexandre Guimaraes]

Chuck,

   The way that are you doing works well (I call it as dot1q tagging 
services), The way that I need to use, L2TP doesn't works. (QinQ services)

   Due the limited "QinQ", I need to keep CPE at customers to deal with 
QinQ/L2TP services.

Att.

AŁexandre


De: Chuck Anderson
Enviado: sábado, 25 de março 09:28
Assunto: Re: [j-nsp] RES:  RES:  QFX 5100 and Q-in-Q
Para: juniper-nsp@puck.nether.net

I'm using Q-in-Q as a tap aggregation function. Port mirrors and/or optical 
taps from other devices are connected to QFX5100 ports which encapsulate the 
foreign traffic with Q-in-Q, then flood the traffic to all ports in the same 
outer VLAN. Analyzers are connected to the output ports. It may be that L2 
protocols like PVST+ are not passing through, but that doesn't matter much for 
my use case: set interfaces xe-0/0/0 description "MIRROR1 INPUT from device 
foo" set interfaces xe-0/0/0 flexible-vlan-tagging set interfaces xe-0/0/0 
native-vlan-id 2 set interfaces xe-0/0/0 mtu 9216 set interfaces xe-0/0/0 
encapsulation extended-vlan-bridge set interfaces xe-0/0/0 unit 2 vlan-id-list 
1-4094 set interfaces xe-0/0/0 unit 2 input-vlan-map push set interfaces 
xe-0/0/0 unit 2 input-vlan-map vlan-id 2 set interfaces xe-0/0/0 unit 2 
output-vlan-map pop set interfaces xe-0/0/0 unit 2 family ethernet-switching 
filter output DISCARD set interfaces xe-0/0/24 description "MIRROR1 OUTPUT to 
analyzer bar" set interfaces xe-0/0/24 flexible-vlan-tagging set interfaces 
xe-0/0/24 mtu 9216 set interfaces xe-0/0/24 encapsulation extended-vlan-bridge 
set interfaces xe-0/0/24 unit 2 vlan-id-list 1-4094 set interfaces xe-0/0/24 
unit 2 input-vlan-map push set interfaces xe-0/0/24 unit 2 input-vlan-map 
vlan-id 2 set interfaces xe-0/0/24 unit 2 output-vlan-map pop set interfaces 
xe-0/0/24 unit 2 family ethernet-switching filter input DISCARD set vlans 
MIRROR1 interface xe-0/0/0.2 set vlans MIRROR1 interface xe-0/0/24.2 set vlans 
MIRROR1 switch-options no-mac-learning On Sat, Mar 25, 2017 at 12:22:40AM 
+, Alexandre Guimaraes wrote: > Chuck, > > > Could you please share portion 
of your QinQ configuration? In my tests, facing customer side, used: > > set 
vlans S-VLAN-200 vlan-id 200 > set vlans S-VLAN-200 interface ge-0/0/14.200 > > 
set interfaces ge-0/0/14 flexible-vlan-tagging > set interfaces ge-0/0/14 
native-vlan-id 200 > set interfaces ge-0/0/14 mtu 6000 > set interfaces 
ge-0/0/14 encapsulation extended-vlan-bridge > set interfaces ge-0/0/14 unit 
200 vlan-id-list 10-30 > set interfaces ge-0/0/14 unit 200 input-vlan-map push 
> set interfaces ge-0/0/14 unit 200 output-vlan-map pop > > > Even you can 
encapsulates customer vlan inside a service vlan, all layer 2 protocols will 
not pass. > > > >  > De: juniper-nsp 
[juniper-nsp-boun...@puck.nether.net] em nome de Chuck Anderson [c...@wpi.edu] 
> Enviado: sexta-feira, 24 de março de 2017 18:33 > Para: 
juniper-nsp@puck.nether.net > Assunto: Re: [j-nsp] RES: QFX 5100 and Q-in-Q > > 
I had to load 14.1X53-D40 to have a basic working Q-in-Q config. D35 > was 
broken in some fundamental way. > > On Fri, Mar 24, 2017 at 04:31:56PM +, 
Alexandre Guimaraes wrote: > > Alain, > > > > As far i know, QinQ - L2TP does 
not work at QFX5100. > > > > Att., > > Alexandre > > > > 
 > > De: juniper-nsp 
[juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert 
[aheb...@pubnix.net] > > Enviado: sexta-feira, 24 de março de 2017 13:07 > > 
Para: juniper-nsp@puck.nether.net > > Assunto: [j-nsp] QFX 5100 and Q-in-Q > > 
> > Well, > > > > We're having all sort of massive failure making Q-in-Q works 
in our > > QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 
17.x > > > > Such a simple thing should not take 1 week of back & forth with 
JTAC. > > > > Anyone have some experience to share on that subject? > > > > 
Thank. ___ juniper-nsp mailing list 
juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: RES: QFX 5100 and Q-in-Q

[Alexandre Guimaraes]

Chuck, 


   Could you please share portion of your QinQ configuration?  In my tests, 
facing customer side, used:

set vlans S-VLAN-200 vlan-id 200
set vlans S-VLAN-200 interface ge-0/0/14.200
 
set interfaces ge-0/0/14 flexible-vlan-tagging
set interfaces ge-0/0/14 native-vlan-id 200
set interfaces ge-0/0/14 mtu 6000
set interfaces ge-0/0/14 encapsulation extended-vlan-bridge
set interfaces ge-0/0/14 unit 200 vlan-id-list 10-30
set interfaces ge-0/0/14 unit 200 input-vlan-map push
set interfaces ge-0/0/14 unit 200 output-vlan-map pop


Even you can encapsulates customer vlan inside a service vlan, all layer 2 
protocols will not pass. 




De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Chuck Anderson 
[c...@wpi.edu]
Enviado: sexta-feira, 24 de março de 2017 18:33
Para: juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] RES:  QFX 5100 and Q-in-Q

I had to load 14.1X53-D40 to have a basic working Q-in-Q config.  D35
was broken in some fundamental way.

On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote:
> Alain,
>
>   As far i know, QinQ - L2TP does not work at QFX5100.
>
> Att.,
> Alexandre
>
> 
> De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert 
> [aheb...@pubnix.net]
> Enviado: sexta-feira, 24 de março de 2017 13:07
> Para: juniper-nsp@puck.nether.net
> Assunto: [j-nsp] QFX 5100 and Q-in-Q
>
>  Well,
>
>  We're having all sort of massive failure making Q-in-Q works in our
> QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x
>
>  Such a simple thing should not take 1 week of back & forth with JTAC.
>
>  Anyone have some experience to share on that subject?
>
>  Thank.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: QFX 5100 and Q-in-Q

[Alexandre Guimaraes]

Alain,

  As far i know, QinQ - L2TP does not work at QFX5100.

Att.,
Alexandre 


De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert 
[aheb...@pubnix.net]
Enviado: sexta-feira, 24 de março de 2017 13:07
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] QFX 5100 and Q-in-Q

 Well,

 We're having all sort of massive failure making Q-in-Q works in our
QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x

 Such a simple thing should not take 1 week of back & forth with JTAC.

 Anyone have some experience to share on that subject?

 Thank.

--
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: MX10 - BGP and LDP sessions flapping without a reason

[Alexandre Guimaraes]

Niall,
Thank you for your help, I will review carefully your consideration and 
apply them in a Maintenance Window, and keep looking...

But today, perhaps I find the problem, that is related to a large 
broadcast domain network of one customer. I saw some  tfeb information about a 
large udp/igmp flooding incoming in one interface, o saw it before, but don’t 
imagine that behavior was bad for the MX. Move the customer to a MX480, those 
flaps stops.

Again, thank you.


Alexandre

-Mensagem original-
De: Niall Donaghy [mailto:niall.dona...@geant.org] 
Enviada em: terça-feira, 8 de novembro de 2016 19:41
Para: Alexandre Guimaraes <alexandre.guimar...@ascenty.com>; 
juniper-nsp@puck.nether.net
Assunto: RE: MX10 - BGP and LDP sessions flapping without a reason

Have you ran 'show krt queue' and 'show krt state' during times of outage?

The control plane hardware on MX5 (or whatever you license it as) is puny - a 
Freescale e500v2 CPU @ 1.33GHz, 2.4DMIPS/MHz, therefore 
3192 DMIPS (single core).
We deployed a couple of MX80s in our network and had problems with route 
convergence, BGP stability, etc. in a full-mesh iBGP 
scenario.
As L3 devices we found them unusable. As L2 devices they were fine.
In particular, MX5/MX80 with MS-MIC is a bad combination - this would 
eventually peg the CPU and drop sessions, or crash the TFEB and 
core dump.

Other issues we encountered were a cosd memory leak that we never got to the 
bottom of.

Junos also runs some redundant processes by default which are not even 
applicable on MX5/80.
You can disable these and gain some extra RAM:

[edit system]
 +   processes {
 +   cfm disable;
 +   send disable;
 +   ethernet-connectivity-fault-management disable;
 +   ddos-protection disable;
 +   ppp disable;
 +   sonet-aps disable;
 +   link-management disable;
 +   iccp-service disable;
 +   }

See also 
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1099523 - 
rpd.record file size/rotation issue if Junos < 
14.1R6.

In our particular use case we removed the L3 terminations from the box and 
instead used l2circuits to haul them to nearby MX960 
routers which could handle the control plane load.
As L2 termination devices they were fine, but I would be very reluctant to 
touch MX5/80 if I could avoid it!

Kind regards,
Niall

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Alexandre Guimaraes
> Sent: 08 November 2016 13:32
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] MX10 - BGP and LDP sessions flapping without a reason
>
> Hi all,
>
>   Did anyone experiencing something like this on MX10 without an obvious
> reason- there has been no changes in network topology, all the interfaces are
> up, no configuration changes has been done. There isn't anything useful in the
> "show log messages" output. If I check the updates sent by BGP
> peers, there is not excessive flood by none of the peers, BGP sessions flaps
> randomly.
>
>   Anyone seen such behavior before where RPD has high CPU utilization 
> without a
> clear reason? Is it somehow possible to trace the updates going to RPD in
> order to understand better, what exactly RDP is doing at the time when the CPU
> utilization is high?
>
>   Jtac already working in on it to try to find the issue, but until now, I
> think that they had no clue of whats going on.
>
>
>
> Model: mx10-t
> Junos: 14.1R7.4
> Hardware inventory:
> Item Version  Part number  Serial number FRU model number
> Midplane REV 08   711-038213     CHAS-MX10-T-S
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX10 - BGP and LDP sessions flapping without a reason

[Alexandre Guimaraes]

Hi all,

Did anyone experiencing something like this on MX10 without an obvious 
reason- there has been no changes in network topology, all the interfaces are 
up, no configuration changes has been done. There isn't anything useful in the 
"show log messages" output. If I check the updates sent by BGP
peers, there is not excessive flood by none of the peers, BGP sessions flaps 
randomly.

Anyone seen such behavior before where RPD has high CPU utilization 
without a 
clear reason? Is it somehow possible to trace the updates going to RPD in 
order to understand better, what exactly RDP is doing at the time when the CPU 
utilization is high?

Jtac already working in on it to try to find the issue, but until now, 
I 
think that they had no clue of whats going on.



Model: mx10-t
Junos: 14.1R7.4
Hardware inventory:
Item Version  Part number  Serial number FRU model number
Midplane REV 08   711-038213     CHAS-MX10-T-S
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: ACX2200 - bandwidth control at subinterfaces

[Alexandre Guimaraes]

Chris,
I saw your email after this, don´t worry.

I understand the situation where a routing platform had to be used
(MX routers). But, according ACX description, "a capable ACX Series
Universal Access Routers for metro-ethernet services" and so on

Perhaps my understanding of telecommunication is worst than ever
where in a world, the bandwidth is growing and growing faster than ever and
ACX provide good bandwitdth for small sites with a small price(less power,
less space, less price than a MX5/10), but these small sites had 50/100
l2circuits for different customers. In a 1Gig port, I can allocate 10/50
circuits giving low cost per port. (Thinking that everyone, had to monetize
their operation for each byte passing through).

50 x 5mbps l2circuts cost less than 250Mbps peak, now imagine if 5
customers, with no bandwidth limits can do if  they reach 200Mbps each...
ACX is not for that? Only MX are? And those QFX? None of them had a minimal
bandwidth control or schedules or something that control the bandwidth.
Maybe I´m choose wrong my NNI equipment for small sites.

I don´t know... 

can someone help?




Alexandre

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de
Chris Kawchuk
Enviada em: quinta-feira, 25 de agosto de 2016 23:23
Para: juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] ACX2200 - bandwidth control at subinterfaces

You mean scheduler maps/shaping on a subinterface?

Correct.

EX doesn't do per-unit schedulers. If they did, nobody would buy an MX for
HQoS. ;)

You can do hard policers though... which is nasty.

I think you can still shape per-queue (i.e. [edit class-of-service
schedulers] best-effort shaping-rate XX;); so, using some output firewall
filters, you can put different VLANs into different queues, and shape each
queue. 

However you give up some of the QoS functionality (only 8 HQ queues to play
with...)


___

sample config I hacked together in 5 minutes on an ex2200c - passes commit.


ge-0/0/0 {
vlan-tagging;
unit 1 {
description "Some cusotmer - use best-effort HW queue - shape to
100m";
vlan-id 1;
family inet {
address 1.1.1.1/24;
}
}
unit 2 {
description "another cusotmer - use assured-forwarding HW queue -
shape to 100m";
vlan-id 2;
family inet {
address 2.2.2.1/24;
}
}
}


class-of-service {  
interfaces {
ge-0/0/0 {
scheduler-map my-wacky-per-queue-shaper;
}
}
scheduler-maps {
my-wacky-per-queue-shaper {
forwarding-class best-effort scheduler best-effort-scheduler;
forwarding-class assured-forwarding scheduler assured-scheduler;
}
}
schedulers {
best-effort-scheduler {
shaping-rate 100m;
buffer-size percent 50;
priority low;
}
assured-scheduler {
shaping-rate 100m;
buffer-size percent 50;
priority low;
}
}

___
   

You'll need to use an output firewall filter on unit 1 to shove all traffic
into BE, and on unit 2 to shove all traffic to AF. Remember only 8 HQ
queues; and you'll likely reserve Queue 7 for network-control anyways.. so 7
effective queues (0-6) to play with.

Secondly, the EX has SMALL HW buffers; especially if I start carving them up
as I did above -- beware.

- CK.



On 25 Aug 2016, at 5:52 am, Alexandre Guimaraes
<alexandre.guimar...@ascenty.com> wrote:

> Gents, afternoon,
> 
> 
>   After some research and a talk with my SE about how to control 
> bandwidth at subinterfaces using ACX2200 Access Routers. I´h reached a 
> point where we can´t control bandwidth using subinterfaces.
> 
>   Had someone of you guys, find a way to control that?
> 
>   Class-of-services only control the interface itself, not the 
> subinterface.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ACX2200 - bandwidth control at subinterfaces

[Alexandre Guimaraes]

Gents, afternoon,


After some research and a talk with my SE about how to control
bandwidth at subinterfaces using ACX2200 Access Routers. I´h reached a point
where we can´t control bandwidth using subinterfaces.

Had someone of you guys, find a way to control that?

Class-of-services only control the interface itself, not the
subinterface.




Alexandre
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Active/Active

[Alexandre Guimaraes]

Here, we had lot of SRX equipments working as firewall services, you can use as 
routing platform, if u need too.

We had started using A/A mode, but times of times we face a lot of problems 
when the packet arrives at fw01-wan passing through fw1-lan, and return using 
fw2-lan. The firewall drop those packets until the rebalance or switchover the 
cluster/reth

The firewall concept, if something enter at interface wan1, have to go out 
using wan1.

There is a reth, I know, but this occurs and JTAC did not explain why until 
today.

Other worst thing was when the packet enters at fw2-lan, cross the data/control 
plane cluster links and go out at fw1-wan.

If you had 10gb ports at wan and lan, but the data/control links are 1g you 
will be shaped at 1g.

Our traffic are more than 3GBps, and all these traffic has ripped of.

Working with A/P, we never more experienced that painful days, so the tshoots 
are very better this way.

Also, Juniper recommends A/P because of those problem that I'd mentioned. Ask 
to your Juniper representative. 

Sorry if mistyped something, typing using mobile.

Att.
AŁexandre

> Em 26 de jun de 2016, às 15:33, Brian Spade <bitkr...@gmail.com> escreveu:
> 
> Hi Alexandre,
> 
> On Sun, Jun 26, 2016 at 11:19 AM, Alexandre Guimaraes
> <alexandre.guimar...@ascenty.com> wrote:
>> Brian,
>> 
>> Sorry about my cent, do not use active/active scenario.
>> 
>> My recomendation is active/backup
>> 
>> Att.
>> AŁexandre
> 
> Ya, I'm thinking of going to A/P, but due to bandwidth requirements,
> we'd really like to use both ISP circuits at the same time.  I know we
> won't be able to achieve a perfect balance.  Are there particular
> reasons you recommend A/P over A/A?  I know some of the normal
> arguments, like it's harder to troubleshoot and perhaps harder on the
> firewalls.
> 
> Thanks.
> /bs
> 
>> 
>>> Em 26 de jun de 2016, às 15:16, Brian Spade <bitkr...@gmail.com> escreveu:
>>> 
>>> Hi,
>>> 
>>> I'm trying to figure out the best way to setup an SRX cluster as
>>> active/active.  I have attached a diagram of the topology, but it's a
>>> full mesh of links.  The ISP links are local interfaces and the
>>> southbound interfaces to the core routers are reth's.  Core1 is HSRP
>>> primary for all VLANs.  FW1 is primary for RG1 and FW2 is primary for
>>> RG2.  The IGP is OSPF but have many VRFs that are connected to the FW
>>> with transit VLANs to bind the sub-interface to virtual router & zone.
>>> 
>>> The issue I have is Core2 has no active OSPF neighbors in this setup.
>>> Therefore, if Core1 fails, there will be a control outage as Core2
>>> establishes OSPF adjacencies.
>>> 
>>> So I'm thinking it might be better to remove the reth's and use local
>>> interfaces on the FW/CORE links.  This way I can have a full mesh of
>>> OSPF adjacencies and no control plane loss when Core1 fails.
>>> 
>>> Does anyone have thoughts on this or recommend the best way to achieve
>>> this active/active full mesh setup?  If there's good reason to not use
>>> active/active, I'd welcome the feedback.
>>> 
>>> Thanks.
>>> /bs
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Active/Active

[Alexandre Guimaraes]

Brian,

Sorry about my cent, do not use active/active scenario.

My recomendation is active/backup

Att.
AŁexandre

> Em 26 de jun de 2016, às 15:16, Brian Spade  escreveu:
> 
> Hi,
> 
> I'm trying to figure out the best way to setup an SRX cluster as
> active/active.  I have attached a diagram of the topology, but it's a
> full mesh of links.  The ISP links are local interfaces and the
> southbound interfaces to the core routers are reth's.  Core1 is HSRP
> primary for all VLANs.  FW1 is primary for RG1 and FW2 is primary for
> RG2.  The IGP is OSPF but have many VRFs that are connected to the FW
> with transit VLANs to bind the sub-interface to virtual router & zone.
> 
> The issue I have is Core2 has no active OSPF neighbors in this setup.
> Therefore, if Core1 fails, there will be a control outage as Core2
> establishes OSPF adjacencies.
> 
> So I'm thinking it might be better to remove the reth's and use local
> interfaces on the FW/CORE links.  This way I can have a full mesh of
> OSPF adjacencies and no control plane loss when Core1 fails.
> 
> Does anyone have thoughts on this or recommend the best way to achieve
> this active/active full mesh setup?  If there's good reason to not use
> active/active, I'd welcome the feedback.
> 
> Thanks.
> /bs
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[Alexandre Guimaraes]

Had experienced the same thing.

After adding this to the loopback filter, the problem gone


set firewall family inet filter PROTECT-RE term aceita-ldp from protocol tcp
set firewall family inet filter PROTECT-RE term aceita-ldp from protocol udp
set firewall family inet filter PROTECT-RE term aceita-ldp from source-port 646
set firewall family inet filter PROTECT-RE term aceita-ldp from 
destination-port 646
set firewall family inet filter PROTECT-RE term aceita-ldp then accept

Alexandre

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de joel 
ahumuza
Enviada em: quinta-feira, 28 de abril de 2016 12:38
Para: juniper-nsp@puck.nether.net
Cc: t...@roketelkom.co.ug
Assunto: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 
and ACX1100)

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7 where 
the LDP sessions are continuously flapping, the logs indicate the following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x 
is down, reason: hold time expired Apr 21 03:36:34  hostname rpd[2299]: 
RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x 
is down, reason: all adjacencies down Apr 21 03:55:34  hostname rpd[2299]: 
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification 
from peer Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session 
x.x.x.x is down, reason: received notification from peer Apr 21 03:55:35  
hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: 
received notification from peer Apr 21 03:55:35  hostname rpd[2299]: 
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification 
from peer

The physical connections are okay, no flaps or errors on the p2p connections We 
are running ISIS as the IGP, whose adjacency is stable.

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback 
interface.

Unfortunately the actions did not yield much since the flaps have been ongoing.

Anyone have any Idea on what the problem / solution might be?

--
Blessings,

AJ.
SkypeID - jl.hmz
ahumuza-joel.blogspot.ug
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Acx5048 ecmp feature and usage

[Alexandre Guimaraes]

Gents,

I had a demand where the equipment that best fits is an ACX5048 for N  reasons

I use some vpls and l2circuits, but there is a feature that i need to use, ecmp.

Someone had knownledge about the ecmp feature using ACX5048?

Att.
AŁexandre

> Em 28 de mar de 2016, às 22:34, Mark Tees  escreveu:
> 
>> On 27 March 2016 at 22:02, Saku Ytti  wrote:
>> On 27 March 2016 at 13:37, Mark Tinka  wrote:
>> 
>> Hey,
>> 
>>> As costs and management got out of control, they run l3vpn's and
>>> Internet in the same chassis, but on different line cards.
>>> 
>>> Eventually, everything converged.
>> 
>> I tend to agree. If there is significant CAPEX delta buying L3 MPLS
>> VPN + HQoS capable boxes and Internet transit capable boxes, then it
>> might make sense to buy two networks, as likely L3 MPLS VPN traffic
>> rates are very minor but service requires much higher touch hardware.
>> But I don't suspect the delta is high these days and more importantly
>> I don't think the IP device CAPEX is very large part of TCO.
>> 
>> Another justification might be, if the software stack is very
>> different, but for L3 MPLS VPN will need all services IP Transit uses,
>> so having IP Transit on same devices does not require turning on
>> additional services, so it is not really creating additional risk on
>> the premium services.
>> If your bread and butter would be L2 VPN, then separating IP transit
>> on another edge device might be very prudent, as you could do away
>> with BGP and IP lookups completely on the edge.
>> 
>> I am fan of Internet-in-VRF, mainly because global-table is special
>> case and it's hard to import/export route between global and VRF, and
>> this complexity has forced me to do some really bad/ugly solutions,
>> which would have been clean and simple if Internet was in VRF. It does
>> not have to mean ugly traceroutes, you can configure device on TTL
>> exceeded to pop labels and do IP lookup in transit for returning TTL
>> exceeded messages. This does not even exclude BGP free core, as your
>> core can have static route pointing to anycast IGP loopback added to
>> all edge devices with full BGP, so TTL exceeded message goes to
>> closest edge device for lookup, probably creating less than
>> millisecond additional delay on traceroute.
> 
> Yes, ICMP tunnelling possibly seems to be what I need for that.
> 
>> 
>> OP states that mistakes in IGP do not affect each other, but mistakes
>> in the 'core' network IGP where the L2 circuits run, still break
>> everything.
> 
> True, there is shared risk here but not in all cases for us.
> 
>> 
>> I'd say you need solid arguments to separate  the networks, state
>> exact specific problems and how it solves them, default to converged
>> network in absence of such arguments. For background it might be
>> interesting to hear what problems you've had, what is prompting this
>> separate edge.
> 
> Agree. Rather than being paranoid about it I need a strict list.
> 
> 
>> 
>> 
>> --
>>  ++ytti
> 
> 
> 
> -- 
> Regards,
> 
> Mark L. Tees
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: Cisco ME3600 migration to something with more 10 gig ports

[Alexandre Guimaraes]

Taking a hide with Aaron,

Reading carefully this thread, looking at ACX5000 e QFX5100, I would 
like to 'hear' the QFX51000 considerations.

Today, use them at distribution layer, delivering more than 6 switches 
as a virtual chassis configuration, never had a big issue regarding the 
software or cpu/memory issues.

When version 14.1 was released, I just start to tests those QFX5100 due 
to 40Gb ports, for l2circuits/p2p circuits with all MPLS services, regarding 
some limitation(vpls), and never had major issues regarding the software issues 
and so on, even using ISSU for upgrade the QFX5100.

Richard mentioned a bad experience with QFX5100.

Richard,
Coud you please share what you had experienced?






Alexandre

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Aaron
Enviada em: segunda-feira, 26 de outubro de 2015 17:49
Para: 'Raphael Mazelier'; juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports

Thanks again for all your insights and feedback.  I've tried to bring your 
comments all together here below...

I'm revisiting this thread please since I am still looking to replace my Cisco 
Me3600's in my distribution layer of my network.  They only have (2)
10 gig ports and I need more 10 gig.  I want all mpls l2vpn/l3vpn capabilities 
that I at least have on my current ME3600's.

I would like to add that (6) ports 10 gig may not be enough for us to scale to 
the future.  We would like more than 6.  If I LAG (2) 10's to my OLT/FTTH 
Chassis and go east and west with 20 gig each direction, then I've used up all 
(6) 10 gig's.  I think this rules out the ASR920's.  

--
About the Juniper ACX5000...

Mark mentioned - "Juniper's ACX5000 units are multi-rate systems. Only problem 
is there are Broadcom chipsets in there. Okay for most applications, but you 
may hit fundamental issues that software can't rectify. That is why we dropped 
our consideration for them.".. " The ACX5000 was a reasonable attempt, but 
that Broadcom chipset is a liability. As always, Juniper continue to drop the 
ball on this"

James mentioned - " Yep, I mean it's a QFX 5100.  Cisco ASR 9xx are certainly 
more better suited IMO for edge applications."
--
About the Juniper EX4550...

Mark mentioned - " The EX4550 falls very short of that re: full IP/MPLS 
capabilities."
Raphael mentioned - "If l3vpn is your case you can consider ex4550 (with 
caution). I use them as PE with some kind of success. But... there is some 
limitations you should be aware of :  
- the cpu is slow, even the snmp process can kill the control plane if there is 
too much polling
- mpls : l2circuit is working, but not l2vpn, nor vpls. l3vpn is working but 
the number of routing instance is limited (around 40 if I remember correctly. 
And the big one : no local leaking between routing instance. Very annoying.
- snmp counter on sub interface (but there are workaround)
--
About the Juniper QFX5100...

Richard mentioned - " My experience with that platform and 14.1 has been very 
unpleasant.  13.2 does not support MPLS PE."
--
About the Cisco ASR903...

I'm interested in this.  What do y'all think about this?  It seems that this is 
a scalable box with its dual power, dual cpu, 6 slot with various Ethernet card 
options.  I wonder what a starter box would cost (chassis, one cpu, one power 
supply, one (8) port 10 gig module) ?



Any other comparable products out there y'all know of?

Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Raphael Mazelier
Sent: Tuesday, July 14, 2015 12:45 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports



Le 14/07/15 15:45, Phil Mayers a écrit :

>
> L3VPN was our use-case; it may or may not do L2VPN, we don't have much 
> use for it locally.
>

If l3vpn is your case you can consider ex4550 (with caution).
I use them as PE with some kind of succes. But.. there is some limitations you 
should be aware of :

- the cpu is slow, even the snmp process can kill the control plane if there is 
too much polling
- mpls : l2circuit is working, but not l2vpn, nor vpls. l3vpn is working but 
the number of routing instance is limited (arround 40 if I remember correctly. 
And the big one : no local leaking between routing instance. 
Very annoying.
- snmp counter on sub interface (but there are workarround)

Regards,

--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

___

[j-nsp] RES: VC on a QFX5100 won't go away

[Alexandre Guimaraes]

> show virtual-chassis 

Preprovisioned Virtual Chassis
Virtual Chassis ID: cf12.a99f.e63b
Virtual Chassis Mode: Enabled
Mstr   Mixed Route 
Neighbor List
Member ID  Status   Serial NoModel  prio  Role  Mode  Mode ID  
Interface
0 (FPC 0)  PrsntTA3714071234 qfx5100-48s-6q 129   Master*  N  VC   2  
vcp-255/0/50

 1  vcp-255/0/51
1 (FPC 1)  PrsntTA3714141234 qfx5100-48s-6q 129   Backup   N  VC   0  
vcp-255/0/50

 2  vcp-255/0/51
2 (FPC 2)  PrsntTA3714141234 qfx5100-48s-6q   0   Linecard N  VC   1  
vcp-255/0/50

0  vcp-255/0/51


See vcp-255/0/51 ports:

> show virtual-chassis vc-port 
fpc0:
--
Interface   Type  Trunk  Status   SpeedNeighbor
or ID (mbps)   ID  Interface
PIC / Port
0/50Configured -1Up   42   vcp-255/0/51
0/51Configured -1Up   41   vcp-255/0/50

fpc1:
--
Interface   Type  Trunk  Status   SpeedNeighbor
or ID (mbps)   ID  Interface
PIC / Port
0/50Configured -1Up   40   vcp-255/0/51
0/51Configured -1Up   42   vcp-255/0/50

fpc2:
--
Interface   Type  Trunk  Status   SpeedNeighbor
or ID (mbps)   ID  Interface
PIC / Port
0/50Configured -1Up   41   vcp-255/0/51
0/51Configured -1Up   40   vcp-255/0/50


So:

request virtual-chassis vc-port delete pic-slot X port Y member   Z







-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Dave 
Peters - Terabit Systems
Enviada em: quinta-feira, 12 de novembro de 2015 18:05
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] VC on a QFX5100 won't go away

Hi all--

I've been trying to remove the VC config from a QFX5100 running 13.2X51-D38, 
and I'm not having any luck. I've tried zeroizing and going into the shell to 
remove the files in the config/vchassis folder, but I'm having no luck.  
Looking at the config, I'm seeing:

root> show configuration


commit {
factory-settings {
reset-virtual-chassis-configuration;
reset-chassis-lcd-menu;


root>

Which isn't on a factory default system, but I can't seem to clear that portion 
of the configuration, and I when I delete the .conf files from the shell, the 
commit/factory-settings/reset-vc stuff pops up all over again.

This is probably a really simple thing, but I'm not getting it. Can anyone help?

Thanks much.

--Dave Peters
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: Juniper MX VPLS S-Tag pop/push with QoS

[Alexandre Guimaraes]

Marcin,
Could you please share some config? Ihad tried that with no results.

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Marcin 
Wojcik
Enviada em: quarta-feira, 11 de novembro de 2015 09:01
Para: Nealon, Mike
Cc: juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] Juniper MX VPLS S-Tag pop/push with QoS

Hi Mike,

I'd use 'learn-vlan-1p-priority X' in your filter in order to make sure the QoS 
classification is based on the S-tag.
'user-vlan-1p-priority X' is useful if you want to base the classification on 
the C-Tag.

Marcin.

On Fri, Nov 6, 2015 at 5:57 PM, Nealon, Mike  wrote:
> Hello, does anybody have knowledge of the order of operations relative to QoS 
> classification of a packet when using a pop/push mechanism in a VPLS 
> instance? I'm trying to make sure packets are classified based on the S-Tag 
> that I am "popping", but I fear the pop may happen before the classification. 
> I need the QoS/P-Bit information in the S-Tag to persist across the network. 
> So I guess the actual question is: How is QoS information persistence 
> achieved when you need to also provide VLAN ambiguity?
>
> Thanks all,
>
> -Mike
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: Junos load balancing

[Alexandre Guimaraes]

James

   I just had experinced the same thing btwn SRX3600 and Nexus7k


Alex


De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de james list 
[jameslis...@gmail.com]
Enviado: sexta-feira, 18 de setembro de 2015 10:38
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] Junos load balancing

Hi folks,
can anybody explain me how highend SRX load balancing is performed by
default on a reth interface ?

My SRX reth is connected to an MX80 LAG, and performes some OSPF adj on
different vlans on different routing-instances.

I see some problems sometimes when one of the two SFP of the SRX reth (the
one with the higher id) gets errors, I’m wondering to understand why some
OSPF neighbors remains up, some no, some services are ok (ie ping) some not
(ie telnet).

And also any url reference please.

Junos 12.1X44-D20.2

Greetings,
James
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RSVP signaled LSPs across LACP bundles

[Alexandre Guimaraes]

If not?

--A.  from X


 Harry Reynolds escreveu 

Yes, if you have a sufficient number of flows adaptive should help; seems like 
the perfect use case.

Regards





-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Daniel Rohan
Sent: Friday, July 17, 2015 3:49 PM
To: juniper-nsp
Subject: [j-nsp] RSVP signaled LSPs across LACP bundles

Hi all,

Quick question for those who might have run across this.

I have a 4x10Gb backbone based on Juniper MX routers. The 10Gb interfaces are 
LAG'd with LACP using the default layer4 hash. It works wonderfully under 
normal conditions.

I'm using RSVP to signal dedicated LSPs for a bunch of pseudowires/l2circuits 
across our network.  The bandwidth for a few of these pseudowires is as high as 
10Gbps.

When one of the 10Gb LSPs starts to get close to 9.4 or 9.5 Gbps of 
utilization, we start to see other customer traffic drop, RTT latency increase 
etc. The 10Gb flow starts to drop packets as well.

The cause appears to be obvious: the 10G flow is getting hashed onto one of my 
four links in the LACP bundle, and there it stays (it's a single TCP session). 
Any other customer traffic that is unlucky enough to be hashed onto that link 
contends with that mammoth flow and everyone loses.

I'm trying to find a way to work around this and looking for ideas.
Per-packet spray hashing is not an option. Would adaptive load balancing help? 
Something else? I'm trying to avoid the scenario where I have to dedicate 
specific 10Gb links just for these bursty psuedowires in order to protect other 
traffic. That seems regressive, although the remainder of this customer traffic 
*would* handily fit on a 30Gb LACP bundle.

-Dan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: SRX1xx Temperature Thresholds

[Alexandre Guimaraes]

Skeeve,
Indeed. Try to put an outside fan, forcing an air flow. 


 Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Michael 
Dale
Enviada em: domingo, 18 de janeiro de 2015 23:15
Para: Skeeve Stevens; juniper-nsp@puck.nether.net
Assunto: Re: [j-nsp] SRX1xx Temperature Thresholds

They must be getting super hot!


I have one in a place with no air flow and never had an issue with it.


I would drill some holes in the top of the case :)


Ours with no air flow (SRX110):



Class Item                           Status     Measurement Temp  Routing 
Engine                 OK         78 degrees C / 172 degrees F
      Routing Engine CPU             Absent Power Power Supply 0                
 OK         



___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RES: SRX1xx Temperature Thresholds

[Alexandre Guimaraes]

Skeeve,

Impossible to change fan configuration at SRX100 they don´t have fan.

And, do no change temp thresholds, even you do that, the firewall will 
burn and will stop working, those components inside didn´t handle very well 
with high temperature. Try to improve the air flow to keep your SRX100 Services 
Gateway working on a safe temp.

From Juniper Techpubs:  The SRX100 Services Gateway does not include a fan and 
does not generate any acoustic noise.


--Alexandre
-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Skeeve 
Stevens
Enviada em: domingo, 18 de janeiro de 2015 21:28
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] SRX1xx Temperature Thresholds

Hi guys,

I have two SRX 100 series (100 + 110) which both sit on or near the yellow 
alarm threshold at all times.  On a warm day they hit reach the Red alarm and 
shut down.

I would like to increase the threshold by a few degrees on both units.
Does anyone know how to do this?


==

admin@SS-*SRX100*-GW show chassis temperature-thresholds
   Fan speed  Yellow alarm  Red alarm
 Fire Shutdown
  (degrees C)  (degrees C) (degrees C)
 (degrees C)
Item Normal  High   Normal  Bad fan   Normal  Bad fan
  Normal
Chassis default N/A   N/A   63  N/A   72  N/A
90
Routing Engine  N/A   N/A   63  N/A   72  N/A
90

admin@SS-*SRX100*-GW show chassis environment
Class Item   Status Measurement
Temp  Routing Engine OK 63 degrees C / 145 degrees F

---

admin@SS-*SRX110*-GW show chassis temperature-thresholds
   Fan speed  Yellow alarm  Red alarm
 Fire Shutdown
  (degrees C)  (degrees C) (degrees C)
 (degrees C)
Item Normal  High   Normal  Bad fan   Normal  Bad fan
  Normal
Chassis default N/A   N/A   70  N/A   92  N/A
95
Routing Engine  N/A   N/A   70  N/A   92  N/A
95

admin@SS-*SRX110*-GW show chassis environment
Class Item   Status Measurement
Temp  Routing Engine OK 68 degrees C / 154 degrees F


...Skeeve

*Skeeve Stevens - Founder  Chief Network Architect* eintellego Networks Pty Ltd
Email: ske...@eintellegonetworks.com ; Web: eintellegonetworks.com

Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve

Facebook: eintellegonetworks http://facebook.com/eintellegonetworks ;
Twitter: eintellego https://twitter.com/eintellego

LinkedIn: /in/skeeve http://linkedin.com/in/skeeve ; Expert360: Profile 
https://expert360.com/profile/d54a9


The Experts Who The Experts Call
Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp