Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

[Tim Franklin via juniper-nsp]

On 16/07/2023 00:51, C K via juniper-nsp wrote:


Indeed. And as you’re alluding to and most probably already know this — yeah 
most of us end up settling on “some release train” for a while, after we spend 
3-4 months testing it thoroughly in the Lab... then spend 18 months getting 
everything in the network “up to that release”. With hundreds of beefy devices 
spread across the globe, and having to do customer notifications to each and 
every service, (and get them to also agree on the time that we’re doing it.. 
some of my customers have a LOT of weight, and can say ’no’), it does take 
quite a while to get through it all.

And yup - by that time, 2+ years has gone past, and it’s time to do it all over 
again. Lather, rinse, repeat. ;)


You missed the fun part where you have to explain *again* every few 
months to the CISO and their minions why you can't adhere to the 
written-by/for-Windows-admins "Patching Policy" that says everything in 
the company is upgraded to "the latest release" within 14 days, no 
software version is ever "more than three months old", and similar 
messages of joy ;)


Cheers,
Tim.


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

Re: [j-nsp] juniper.net down?

[Tim Harman via juniper-nsp]

On 19/10/2022 7:12 am, Aaron via juniper-nsp wrote:

juniper.net down?


Seems to be loading fine from New Zealand.

Even logging in with my account worked, something that seems rare these 
days!


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

Re: [j-nsp] AFEB vs TFEB

[Tim Jackson]

Isn't the T for Taz, the old MX80 code name?

On Thu, Nov 26, 2020, 11:18 AM Caio Fratelli  wrote:

> Greetings,
>
> Does anyone know why Juniper uses the name AFEB on MX104 referring to
> its Forward Engine Base instead of TFEB?
> I know that TFEB means Trio Forward Engine Base, so what's the meaning
> for the "A" on AFEB?
>
> Thank you.
> ___
> 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] Appending customer ASN to BGP

[Tim Jackson]

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/as-path-edit-routing-options.html

On Sun, Nov 8, 2020, 2:09 PM Dario Amaya  wrote:

> Hello,
>
> Our customer has own ASN from ARIN and want us to take care of all
> routing. We already originate the customer prefix from our ASN. What
> is easiest / recommended way to append customer's ASN to the prefixes
> to make it appear as though it's originated from their ASN without any
> routing equipment / BGP from them? This is on Juniper MX, is L3VPN the
> answer?
> ___
> 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] DHCP relay monitoring

[Tim Howe]

On Thu, 9 Jul 2020 13:48:16 +0200
Baldur Norddahl  wrote:

> [snip]
> 
> I can open a case with JTAC for the cause of the crash, but I am 
> thinking about how to monitor the relay.

In the past I have used traceoptions, which was helpful.

Under system, processes, dhcp-service, traceoptions I have done:
  file DHCP.log size 100m files 3;
  level all;  
  flag all;

You can then look at that file.  There will be a lot of info.

This works on my ACX5048.  I have not tried on an MX.

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

Re: [j-nsp] ACX5448 & ACX710

[Tim Durack]

We have a very small deployment of ASR920 running 16.12. Work well for us,
and we do some pretty kinky/exotic stuff: small scale BNG, Internet in VRF,
selective FIB, port-based DHCPv4/v6/PD, IP unnumbered, IPoDWDM...

If you can stomach the BU wars, UADP is a nice ASIC - I think the Cat9k has
legs, but the Enterprise BU is definitely in a parallel universe. I asked
about porting XR to run on UADP. That didn't really go over well.

I am wary of NCS due to the merchant silicon and general uncertainty - why
announce the Cisco 8000 with no family loyalty? Looks like a replacement to
me.

Tim:>

On Wed, Jan 22, 2020 at 1:18 PM Colton Conor  wrote:

> We too have the ACX5048 and QFX5100's, and have been unhappy with them
> both. They both have the same Trident II chip set, but run different code
> which is annoying to say the least.  Not to mention these aren't really
> built for Metro-E deployments. They are not hardened, so datacenter only.
> Plus, the don't support 23 inch racks nor 2 post racks. Makes them hard to
> put in a customers site.
>
> I looked at the ASR920 just now, it has too few 10G ports on it. The NCS
> 540 seems to be more ideal for our needs. Does the NCS 540 fit the bill?
>
> On Wed, Jan 22, 2020 at 10:05 AM Alexandre Guimaraes <
> alexandre.guimar...@ascenty.com> wrote:
>
> > 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" <
> > juniper-nsp-boun...@puck.nether.net em nome de mark.ti...@seacom.mu>
> > 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__puc

Re: [j-nsp] QFX10008 and sFlow

[Tim Jackson]

Iirc enabling it on 1 unit will actually turn it on on all units on sFlow.

Re: IPFIX, it's probably broken, too. At least on the fixed config boxes it
is:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1365864

On Mon, Oct 14, 2019, 5:18 PM Olivier Benghozi 
wrote:

> Hi,
> you probably don't really want to configure the older sFlow monitoring
> those days (with its various limitations), what you probably really need is
> to configure inline IPFIX flow monitoring, as it is supported by QFX10k
> devices.
>
> > Le 14 oct. 2019 à 19:49, Tim Vollebregt  a écrit :
> >
> > I’m toying around with some QFX10008’s in a customer PoC.
> > Having some issues with sFlow and can’t find proper documentation in
> regards to this.
>
> ___
> 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] QFX10008 and sFlow

[Tim Vollebregt]

Hi All,

I’m toying around with some QFX10008’s in a customer PoC.
Having some issues with sFlow and can’t find proper documentation in regards to 
this.

I’m trying to get sFlow samples from ae/LAG’s.

According to documentation:
• You cannot configure sFlow monitoring on a link aggregation group 
(LAG), but you can configure it individually on a LAG member interface.

ae22 is transporting some L3 subinterfaces with vlan tags
ae22 consists of:
et-0/0/1
et-1/0/3

In the ’set protocols sflow interfaces’ you have to put the logical (.0/.xxx) 
interface.

In the autocomplete of ’set protocols sflow interfaces’ I found out that the 
member interfaces of ae22 are listed together with the logical L3 subinterfaces.
For example:
et-0/0/1.511
et-0/0/1.513
et-0/0/1.514
and
et-1/0/3.511
et-1/0/3.513
et-1/0/3.514

I would assume I should just enable sflow for all these member subinterfaces.
This works fine with 1 L3 subinterfaces enabled, however when I want to add 
multiple I get the following error:

[edit protocols sflow]
  'interfaces et-0/0/1.511'
only one ifl is allowed
error: configuration check-out failed 

Is this a license limitation? Or am I doing something wrong? Would be a bit 
weird if an interface can only sample sFlow for a single L3 subinterface.

Thanks in advance,

Tim

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

Re: [j-nsp] 100G DAC issue between MX204 and QFX5110

[Tim Jackson]

Don't think it's just you. We've had tons of issues with QSFP28 optics
across all sorts of hardware.

--
Tim

On Thu, Jun 20, 2019 at 8:38 AM Saku Ytti  wrote:

> Is it just me or does 100GE have lot more interop issues than we had
> with 1GE and 10GE?
>
> Vendor rep explained it as MSA being too ambiguous so both can do
> everything right and still not interop, unsure if defensive or
> factual.
>
>
> On Thu, 20 Jun 2019 at 16:34, Tim Jackson  wrote:
> >
> > We've actually had the reverse issue where 17.4 is the only release that
> > some DACs will function. Any 18.x release seems to break them. These
> aren't
> > Juniper coded DACs, but just generic coded:
> >
> >
> https://paste.somuch.fail/?248d62d55916f17b#+flZp6LEb0ZY48AI/3rc4YidWw6LENIQTPxpc4O6j7g=
> >
> > --
> > Tim
> >
> > On Thu, Jun 20, 2019 at 8:24 AM Chris Wopat  wrote:
> >
> > > We have tested flexoptix 3rd party DAC between MX204 and
> QFX5120/QFX10002
> > > with mixed results. Per release notes/ HCL, DAC isn't supported on
> MX204
> > > until 18.2
> > >
> > > https://apps.juniper.net/hct/product/#prd=MX204
> > >
> > > We couldn't link anything with mx204 dac on anything below 18.2. There
> are
> > > also a few DAC related PRs in the 18.2r1 release notes.
> > >
> > >
> > >
> https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/18.2/junos-release-notes-18.2.pdf
> > > ___
> > > 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
>
>
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 100G DAC issue between MX204 and QFX5110

[Tim Jackson]

We've actually had the reverse issue where 17.4 is the only release that
some DACs will function. Any 18.x release seems to break them. These aren't
Juniper coded DACs, but just generic coded:

https://paste.somuch.fail/?248d62d55916f17b#+flZp6LEb0ZY48AI/3rc4YidWw6LENIQTPxpc4O6j7g=

--
Tim

On Thu, Jun 20, 2019 at 8:24 AM Chris Wopat  wrote:

> We have tested flexoptix 3rd party DAC between MX204 and QFX5120/QFX10002
> with mixed results. Per release notes/ HCL, DAC isn't supported on MX204
> until 18.2
>
> https://apps.juniper.net/hct/product/#prd=MX204
>
> We couldn't link anything with mx204 dac on anything below 18.2. There are
> also a few DAC related PRs in the 18.2r1 release notes.
>
>
> https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/18.2/junos-release-notes-18.2.pdf
> ___
> 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] Silly question for a Friday

[Tim Jackson]

Sorry, I'm thinking of ping/traceroutes..

On Fri, Jun 7, 2019, 4:49 PM Tim Jackson  wrote:

> show route family inet/inet6 
>
> On Fri, Jun 7, 2019, 4:43 PM Chris Adams  wrote:
>
>> I can "show route " and JUNOS will do a DNS lookup and show
>> the route for the resolved IP.  Is there any way to control that for
>> hosts with multiple IPs, especially IPv6?
>> --
>> Chris Adams 
>> ___
>> 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] Silly question for a Friday

[Tim Jackson]

show route family inet/inet6 

On Fri, Jun 7, 2019, 4:43 PM Chris Adams  wrote:

> I can "show route " and JUNOS will do a DNS lookup and show
> the route for the resolved IP.  Is there any way to control that for
> hosts with multiple IPs, especially IPv6?
> --
> Chris Adams 
> ___
> 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] EVPN/VXLAN over IPsec over Internet

[Tim Jackson]

I've done some hacks with an MX to do inline GRE frag+reassembly over the
internet with a looped macsec GigE port to get encrypted traffic with full
MTU. You could add VXLAN to that and get what you want kinda. MX GRE inline
frag/reassembly works well.



On Sat, Jun 1, 2019, 7:44 AM Chen Jiang  wrote:

> Hi! Experts
>
> Sorry for disturbing, we know that EVPN/VXLAN cannot fragment packets, but
> we want to use IPsec/Internet as backup EVPN/VXLAN path, is there any
> workaround to forwarding such packets in EVPN/VXLAN over IPsec over
> Internet?
>
> Thanks in advance.
>
> --
> BR!
>
>
>
>James Chen
> ___
> 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] QSFP28 oddities between Arista and QFX after upgrade

[Tim Jackson]

Check FEC settings. Try turning FEC on or off on both sides.

Arista: (config-if)#error-correction encoding reed-solomon

Juniper: set interfaces et-0/0/1 gigether-options fec fec91

On Sat, May 11, 2019, 6:32 AM Jason Lixfeld  wrote:

> I had no idea auto-negotiation was still a thing with 100G, but in any
> event, toggling auto negotiation didn’t work.
>
> > On May 11, 2019, at 2:21 AM, Eric Krichbaum  wrote:
> >
> > I had a similar issue with 18.x and MX204. Did you try turning off
> auto-negotiation?
> >
> > set interfaces et-4/0/52 ether-options no-auto-negotiation
> >
> > I had a similar issue with QFX5100/EX4300 and 40G and this fixed the
> issue oddly enough.
> >
> > Eric
> >
> > -Original Message-
> > From: juniper-nsp  On Behalf Of
> Jason Lixfeld
> > Sent: Friday, May 10, 2019 6:13 PM
> > To: juniper-nsp 
> > Subject: [j-nsp] QSFP28 oddities between Arista and QFX after upgrade
> >
> > Hey,
> >
> > I have a QFX5110 in the lab which I upgraded from 17.something to 18.4
> to resolve some ISIS weirdness.  ISIS weirdness resolved, but now the
> previously working link between this QFX and an Arista 7280SR no longer
> comes up, despite light levels on both sides being within norms.  I went
> from 18.4 to 19.1 just for the hell of it, and still no bueno.
> >
> > The QSFP28 in the QFX comes up if it’s looped to itself, as does the
> QSFP28 in the Arista.  The Arista QSFP28 links to another Arista, or an
> MX204.  The QFX QSFP28 links to the same MX204 as well (no other QSFP28
> gear to test with otherwise) so it seems to be a weird compatibility issue
> between the Arista and the QFX?
> >
> > Does this sort of thing smell familiar to anyone?  I’ve had pretty good
> luck with 100G compatibility in general so far, so I’m not overly familiar
> with any knobs to work around any compatibility issues that may creep up
> here or there, so happily accept some pointers if anyone has some clue.
> >
> > Thanks!
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
>
> ___
> 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] 400G is coming?

[Tim Rayner]

> It seems these are oversubscribed to the backplane.  8×100G + 2×400G
> is 1.6 Tbit/s, and 12×100G + 3×400G is 2.4 Tbit/s, but all three of
> MX240, MX480 and MX960 are listed as having 1.5 Tbit/s max per slot.
> (And is that 1.5 Tbit/s in *and* out, or is that just 750 Gbit/s per
> direction?)
As I understand it, when a 400G port is enabled, 3 of the 100G ports are made 
un-available (not sure whether there is an option for sub-rate on the 400G port 
keeping more of the 100G ports available), hence there will be a limit of 1.5 
Tbps per slot with no over-subscription.  It is actually a 15x100G card... each 
group of 5 ports can enable one of its ports as 400G, thereby disabling three 
of its other 100G ports... there is 500Gbps of capacity per port group = 
available as 5 x 100G, or 1 x 400G + 1 x 100G.

The card with less capacity (ie. 2 groups of 5 ports, rather than 3 groups of 5 
ports) just reduces the electronics and thereby the power consumption by 1/3.

I hope this helps

Tim.

Tim Rayner
Optical Engineer, AARNet Pty Ltd
street address: Building 9, Banks Street, YARRALUMLA  ACT  2600
postal address:  GPO Box 1559, CANBERRA   ACT   2601
t. +61 2 6222 3575 f. +61 2 6222 3535 e. tim.ray...@aarnet.edu.au
w. www.aarnet.edu.au
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 in 2-post rack?

[Tim Jackson]

You can probably use some 4-post conversion kits to mount it in 2-post..
The mounts/rails on the MX204 are very similar to the other 1RU QFX mounts.
Either flush or center-mount:

https://www.racksolutions.com/2-post-conversion-brackets.html
https://www.racksolutions.com/4u-flushmount-conversion-kit.html

On Fri, Mar 15, 2019 at 2:51 PM Richard Hicks 
wrote:

> Is anyone running the MX204 in a 2-post rack?
> How is it holding up?
>
> Spec sheet says it requires 4-post, which is a non-start in many of our
> locations.
>
> Thanks,
> Rick
> ___
> 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] MX960 power supply stopped during ISSU

[Tim Warnock]

Power supplies have firmware on them ;)

Regardless - I don't know much about the MX960 arch but do you have enough 
power supplies to maintain N+1  at full tilt?

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Aaron Gould
> Sent: Wednesday, 30 January 2019 5:12 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] MX960 power supply stopped during ISSU
> 
> Last night I had a successful ISSU upgrade. BUT. "show chassis alarm" showed
> me that PEM0 power supply had issues.  Searching logs didn't turn up any
> previous issues so I think that this happened during the ISSU process.
> Anyway ever seen something like that before?  I would've thought that a
> software upgrade wouldn't do much with power, but I'm wondering now.
> 
> 
> 
> 17.4R1-S2.2 - old
> 
> 17.4R2-S1.2 - new
> 
> 
> 
> agould@blvr-960> show chassis alarms
> 
> 3 alarms currently active
> 
> Alarm time   Class  Description
> 
> 2019-01-29 00:33:12 CST  Major  PEM 0 Input Failure
> 
> 2019-01-29 00:33:12 CST  Major  PEM 0 Not OK
> 
> 2019-01-29 00:32:27 CST  Minor  Backup RE Active
> 
> 
> 
> .this morning CO Tech went on site and said power feeds to PEM0 were fine,
> and no tripped fuzes or anything.  "show chassis power" showed 2 feeds
> expected and connected, and good power but not putting anything out.
> 
> He removed the bad PEM0 and put it into lab MX960, and it works!
> 
> 
> 
> Some messages seen were. I wonder what "bump volt" means ?  .wondering
> if
> that is an action to actually hit the voltage of each PEM, and if so, wonder
> if that would've tripped on offline.
> 
> 
> 
> Jan 29 00:32:20  hwdb: entry for cbd 2988 at slot 2 inserted
> 
> Jan 29 00:32:20  acb_add: CB 2, initializing SGLS SGLINk type 2 Local ACB
> type 4
> 
> Jan 29 00:32:20  acb_sglink_init: GE 8374 PHY PMC ctrl 2 : 0xa300 at slot 2
> 
> Jan 29 00:32:20  acb_sglink_init: GE 8374 PHY PMC ctrl 2: set TXCLK4 at slot
> 2
> 
> Jan 29 00:32:20  acb_sglink_init: GE 8354 PHY Auto Neg Status 2: 0x2a for
> slot 2
> 
> Jan 29 00:32:20  acb_sglink_init: GE 8354 PHY is byte aligned for slot 2
> 
> Jan 29 00:32:21  acb_sglink_init: GE 8374 PHY Auto Neg Status 2: 0xa0 at
> slot 2
> 
> Jan 29 00:32:21  acb_sglink_init: GE 8374 PHY is byte aligned at slot 2
> 
> Jan 29 00:32:21  acb_sglink_init: CB slot 2 SGLS version 0
> 
> Jan 29 00:32:21  acb_sglink_init: CB slot 2 SGLS type 2, acb type 4
> 
> Jan 29 00:32:21  acb_add: CB 2, initializing PCIe hub
> 
> Jan 29 00:32:21  acb_add: setting CB 2 cache type and i2c 0xbac
> 
> Jan 29 00:32:21  ch_probe_frus: Routing Engine 1 added
> 
> Jan 29 00:32:21  reading RE 1 initial state
> 
> Jan 29 00:32:21  reading host processor dimms
> 
> Jan 29 00:32:22  hwdb: entry for re 3087 at slot 1 inserted
> 
> Jan 29 00:32:22  ch_probe_frus: PEM 0 added
> 
> Jan 29 00:32:22  reading PEM 0 initial state
> 
> Jan 29 00:32:22  Bump volt: reset structure for pem 0 during add
> 
> Jan 29 00:32:22  ch_probe_frus: PEM 1 added
> 
> Jan 29 00:32:22  reading PEM 1 initial state
> 
> Jan 29 00:32:22  Bump volt: reset structure for pem 1 during add
> 
> Jan 29 00:32:22  ch_probe_frus: PEM 2 added
> 
> Jan 29 00:32:22  reading PEM 2 initial state
> 
> Jan 29 00:32:22  Bump volt: reset structure for pem 2 during add
> 
> Jan 29 00:32:22  ch_probe_frus: PEM 3 added
> 
> Jan 29 00:32:22  reading PEM 3 initial state
> 
> Jan 29 00:32:22  Bump volt: reset structure for pem 3 during add
> 
> Jan 29 00:32:22  ch_probe_frus: FPM 0 added
> 
> Jan 29 00:32:22  reading FPM 0 initial state
> 
> Jan 29 00:32:22  check_and_carp_on_i2cs_version I2CS version=0x29
> 
> 
> 
> Jan 29 00:33:12  blvr-960 alarmd[16028]: Alarm set: Pwr supply color=RED,
> class=CHASSIS, reason=PEM 0 Not OK
> 
> Jan 29 00:33:12  blvr-960 craftd[13352]:  Major alarm set, PEM 0 Not OK
> 
> Jan 29 00:33:12  blvr-960 chassisd[13337]: CHASSISD_PEM_INPUT_BAD:
> status
> failure for power supply 0 (status bits: 0x2); check circuit breaker
> 
> Jan 29 00:33:12  blvr-960 alarmd[16028]: Alarm set: Pwr supply color=RED,
> class=CHASSIS, reason=PEM 0 Input Failure
> 
> Jan 29 00:33:12  blvr-960 craftd[13352]:  Major alarm set, PEM 0 Input
> Failure
> 
> Jan 29 00:33:12  blvr-960 chassisd[13337]: CHASSISD_PEM_INPUT_BAD: Input
> failure for power supply 0 (status bits: 0x2); check circuit breaker
> 
> Jan 29 00:33:17  blvr-960 chassisd[13337]: CHASSISD_PEM_INPUT_BAD:
> status
> failure for power supply 0 (status bits: 0x2); check circuit breaker
> 
> 
> 
> Jan 29 00:33:12  send: red alarm set, device PEM 0, reason PEM 0 Not OK
> 
> Jan 29 00:33:12 CHASSISD_PEM_INPUT_BAD: status failure for power supply
> 0
> (status bits: 0x2); check circuit breaker
> 
> Jan 29 00:33:12  send: red alarm set, device PEM 0, reason PEM 0 Input
> Failure
> 
> Jan 29 00:33:12 CHASSISD_PEM_INPUT_BAD: Input failure for power supply 0
> (status bits: 0x2); check circuit breaker
> 
> 
> 
> -Aaron
> 
> 
> 
> ___
> 

Re: [j-nsp] Finding drops

[Tim Warnock]

You're looking in the wrong place :)

You might better understand if you look here: 
https://en.wikipedia.org/wiki/Ethernet_frame

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Jason Lixfeld
> Sent: Tuesday, 22 January 2019 6:09 AM
> To: Juniper List 
> Subject: [j-nsp] Finding drops
> 
> Hi all,
> 
> I’m doing some RFC2544 tests through an MX204.  The tester is connected to
> et-0/0/2, and the test destination is somewhere out there via et-0/0/0.  64
> byte packets seem to be getting dropped, and I’m trying to find where on
> the box those drops are being recorded.
> 
> I’ve distilled the test down to generating 100 million 64 byte (UDP) packets 
> to
> the destination, but the counters on et-0/0/2 read as though they’ve only
> received about 76.6% of those packets.
> 
> If I change the test to send 100 million 100 byte packets, the counters on et-
> 0/0/2 account for all packets.
> 
> I’ve tried looking at various output to find a counter that registers the 
> missing
> packets, but I’m not having any luck.
> 
> Aside from 'show interface et-0/0/2 extensive’, I’ve looked here with no
> luck:
> 
> show interface queue et-0/0/2
> show pfe statistics traffic detail
> show pfe statistics exceptions
> show pfe statistics error
> 
> Somewhere else I should be looking?
> ___
> 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] MX204 Tunnel Services

[Tim Jackson]

I've done LT interfaces on MX204 with multiple LSYS' to build some lab
topologies without issue. This was back in beta and worked fine, haven't
run it on newer code, but I do run GRE tunnels in 18.1R3 without issue.

--
Tim



On Wed, Dec 26, 2018, 5:43 PM Fraser McGlinn  Hey Everyone,
>
> Yet another post re MX204 ;)
>
> Trying to get lt-x/x/x interfaces working on MX204 (18.3R1.9), thus far no
> luck. Interfaces are created and bandwidth set after enabling tunnel
> services on the PIC, however only output packets on the source interface
> increment. Input packets do not increment on the receiving unit, so seems
> to get lost in the nether.
>
> Has anyone got LT interfaces working on MX204 and an example config?
>
> Cheers,
> Fraser
> ___
> 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] MX80 Input Scheduling/Shaping

[Tim Jackson]

The QX/Dense Queuing Block exists for the MIC slots on the MX80.

Looks like you get 12 queues per MX80/104 for ingress shaping. Doesn't seem
to be tied to QX at all. Egress you get per unit on the MIC slots though.


https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/cos-configuring-ingress-hierarchical-cos-on-trio-mpc-mic.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-hierarchical-scheduling-understanding-fine-grained-queuing-for.html


On Fri, Oct 5, 2018, 8:45 PM Alexander Arseniev via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hello,
> Egress scheduling/shaping on MIC ports - correct, that's why I said
> "roughly" equal.
> Ingress scheduling/shaping  requires Q or EQ MPC which is not supported
> on MX80.
> Thanks
> Alex
>
> -- Original Message --
> From: sth...@nethelp.no
> To: arsen...@btinternet.com; juniper-nsp@puck.nether.net
> Sent: 05/10/2018 20:20:06
> Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping
>
> >>Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX
> >>series book, 2nd ed, page 598.
> >>
> >>MX80 COS capabilities are roughly equal to MPC1, without Q.
> >
> >Disagree. MX80 does per-VLAN queuing/scheduling/shaping just fine for
> >ports on MICs. *Not* for the builtin 10G ports.
> >
> >Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> ___
> 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] Use cases for IntServ in MPLS backbones

[Tim Cooper]

> On 2 Oct 2018, at 11:24, James Bensley  wrote:
> 
>> On Tue, 2 Oct 2018 at 10:57, Mark Tinka  wrote:
>> I've never quite understood it when customers ask for 8 or even 16 classes. 
>> When it comes down to it, I've not been able to distill the queues to more 
>> than 3. Simply put, High, Medium and Low. The 4th queue is for the network 
>> itself.
> 
> I'm not saying I agree with this 8 classes - just stating what it was
> :) I also agree that most people genuinely don't need more than 3-4.
> We often "helped" (nudged) customers to design their traffic into just
> a few classes.
> 
> Here in the land of Her Majesty and cups of tea, if you want to
> operate as part of the Public Services Network (a national effort to
> provide unified services to the public sector across multiple
> providers to stamp out any monopoly) you must comply with their 6
> class model [1]:
> https://www.gov.uk/government/publications/psn-quality-of-service-qos-specification/psn-quality-of-service-qos-specification
> 
> So this 6 classes, we split voice signalling and media into two, with
> the media being an LLQ, and had a separate class to guarantee traffic
> for control and MGMT plane traffic (e.g. we can still SSH to our
> routers with a customer DoS is filling the pipes) we ended up with 8.
> Yay :(
> 
> Cheers,
> James.
> 
> [1] As is customary with any tech savvy government, they've since
> sacked off various PSN standards without providing any replacement so
> everyone is just sticking to the same expired standards for now
> 
> __

The QoS obligations has been pretty much cut/paste from PSN into HSCN 
obligations, if you haven’t come across that yet. So look forward to that... ;)

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

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

[tim tiriche]

hello,

i have 5 PE routers running with full iBGP/RSVP-TE MPLS Mesh.

There is a CE connected to PE5 and PE4.

Based on BGP Path selection all of the PE {1,2,3,4} are preferring route to
PE5 due to BGP Path selection based on AS PATH tiebreaker.

However, i would like PE1 to prefer PE4 and the rest to PE5.  What is the
best way to go about doing this?

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

Re: [j-nsp] auto b/w mpls best practice -- cpu spikes

[tim tiriche]

.o issues with convergence or suboptimal paths.  The noc is constantly
seeing high cpu alerts and that was concerning.  Is this normal in other
networks?

Running 14.1R7.4 with mx480/240 mix.
I usually follow the code listed here:
https://kb.juniper.net/InfoCenter/index?page=content=KB21476

Which code version have these optimization happened in?


On Wed, Sep 12, 2018 at 2:11 AM Saku Ytti  wrote:

> Hey Tim,
>
> I'd optimise for customer experience, not CPU utilisation. Do you have
> issues with convergence time, suboptimal paths?
>
> Which JunOS you're running? There are quite good reasons to jump in
> recent JunOS for RSVP, as you can get RSVP its own core, and you can
> get make-before-break LSP reoptimisation, which actually works
> event-driven rather than timer based (like what you have, causing LSP
> blackholing if LSP convergence lasts longer than timers).
>
>
>
>
> On Wed, 12 Sep 2018 at 08:05, tim tiriche  wrote:
> >
> > Hi,
> >
> > Attached is my MPLS Auto B/w Configuration and i see frequent path
> changes
> > and cpu spikes.  I have a small network and wanted to know if there is
> any
> > optimization/best practices i could follow to reduce the churn.
> >
> > protocols {
> > mpls {
> > statistics {
> > file mpls.statistics size 1m files 10;
> > interval 300;
> > auto-bandwidth;
> > }
> > log-updown {
> > syslog;
> > trap;
> > trap-path-down;
> > trap-path-up;
> > }
> > traffic-engineering mpls-forwarding;
> >
> > rsvp-error-hold-time 25;
> > smart-optimize-timer 180;
> > ipv6-tunneling;
> > optimize-timer 3600;
> > label-switched-path <*> {
> > retry-timer 600;
> > random;
> > node-link-protection;
> > adaptive;
> > auto-bandwidth {
> > adjust-interval 7200;
> > adjust-threshold 20;
> > minimum-bandwidth 1m;
> > maximum-bandwidth 9g;
> > adjust-threshold-overflow-limit 2;
> > adjust-threshold-underflow-limit 4;
> > }
> > primary <*> {
> > priority 5 5;
> > }
> > }
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] auto b/w mpls best practice -- cpu spikes

[tim tiriche]

Hi,

Attached is my MPLS Auto B/w Configuration and i see frequent path changes
and cpu spikes.  I have a small network and wanted to know if there is any
optimization/best practices i could follow to reduce the churn.

protocols {
mpls {
statistics {
file mpls.statistics size 1m files 10;
interval 300;
auto-bandwidth;
}
log-updown {
syslog;
trap;
trap-path-down;
trap-path-up;
}
traffic-engineering mpls-forwarding;

rsvp-error-hold-time 25;
smart-optimize-timer 180;
ipv6-tunneling;
optimize-timer 3600;
label-switched-path <*> {
retry-timer 600;
random;
node-link-protection;
adaptive;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 20;
minimum-bandwidth 1m;
maximum-bandwidth 9g;
adjust-threshold-overflow-limit 2;
adjust-threshold-underflow-limit 4;
}
primary <*> {
priority 5 5;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] L3VPN/RR/PE on Same router

[tim tiriche]

Hello,

I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the
US.  The other routers in the US are not RR and regular iBGP.  This router
also acts as RR for Europe and takes in full BGP table.  Is there some
caveats to watch out for?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Tim Jackson]

https://www.racksolutions.com/2-post-rack-rails.html

--
Tim

On Wed, Aug 1, 2018 at 5:39 PM, Colton Conor  wrote:

> We are constantly having to mount these larger switches to two post racks.
> To my knowledge Juniper does not make 2 post mounting brackets for these
> switches. Does anyone have any recommendations on a shelf or something to
> hold these up? We are dealing with 19 and 23 inch racks.
> ___
> 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] Router for full routes

[Tim Jackson]

I think the PFE ukern runs as a process in the hypervisor that uses another
core and a few G of ram:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4479 root  20   0 16.7g  16g  26m S  500 53.0 114757:25 qemu-system-x86
21332 root  20   0 3008m 263m 215m R  135  0.8  30488:26 J-UKERN

--
Tim


On Wed, Jun 27, 2018 at 9:02 AM, Jason Lixfeld 
wrote:

> So the rest is for guest VMs then?
>
> > On Jun 27, 2018, at 9:57 AM, Tim Jackson  wrote:
> >
> > Yeah 16G for the RE + I think you actually get 5 cores in the Junos VM:
> >
> > % sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
> > hw.machine: amd64
> > hw.model: QEMU Virtual CPU version 1.7.2
> > hw.ncpu: 5
> > hw.machine_arch: amd64
> >
> > It's really fast though. Great little box so far.
> >
> > --
> > Tim
> >
> >
> > On Wed, Jun 27, 2018 at 8:51 AM, Chris Adams  wrote:
> >
> >> Once upon a time, Tim Jackson  said:
> >>> Yes. Calling it decent is an understatement. It's really quick. It's a
> >> Xeon
> >>> E5-2608Lv4.
> >>
> >> Yep.  The RE VM "only" gets half the resources (so 4 cores and 16G RAM),
> >> but that is plenty good!  It also has dual NVMe SSDs for storage.  When
> >> I upgraded JUNOS from 17.4 to 18.1, I think it only took about 3 minutes
> >> from "request system reboot" until I could SSH back in to the RE
> >> management ethernet.
> >>
> >> --
> >> Chris Adams 
> >> ___
> >> 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] Router for full routes

[Tim Jackson]

Yeah 16G for the RE + I think you actually get 5 cores in the Junos VM:

% sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: QEMU Virtual CPU version 1.7.2
hw.ncpu: 5
hw.machine_arch: amd64

It's really fast though. Great little box so far.

--
Tim


On Wed, Jun 27, 2018 at 8:51 AM, Chris Adams  wrote:

> Once upon a time, Tim Jackson  said:
> > Yes. Calling it decent is an understatement. It's really quick. It's a
> Xeon
> > E5-2608Lv4.
>
> Yep.  The RE VM "only" gets half the resources (so 4 cores and 16G RAM),
> but that is plenty good!  It also has dual NVMe SSDs for storage.  When
> I upgraded JUNOS from 17.4 to 18.1, I think it only took about 3 minutes
> from "request system reboot" until I could SSH back in to the RE
> management ethernet.
>
> --
> Chris Adams 
> ___
> 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] Router for full routes

[Tim Jackson]

Yes. Calling it decent is an understatement. It's really quick. It's a Xeon
E5-2608Lv4.


On Wed, Jun 27, 2018 at 8:31 AM, Jason Lixfeld 
wrote:

>
>
> > On Jun 27, 2018, at 9:18 AM, Mark Tinka  wrote:
> >
> > At this stage, I'd say the cheapest MX router you should go for that is
> > decent is the MX204.
>
> Isn’t the MX204 RE more than decent?  8 core 1.6Ghz, 32GB DDR4 RE sounds
> like decent is an understatement, no?
> ___
> 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] MX204

[Tim Jackson]

I think you're in the ~200gbps range for them if VXLAN is considered tunnel
services. If not it should be line rate.

ARP scale on 204 is rather large, even when terminating over a VTEP.

That's my exact use case for the MX 204 tbh.

On Tue, May 15, 2018, 11:49 AM Luca Salvatore via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> How is the MX204 for VXLAN routing (routing between VXLANs)
> Can i expect close to line rate performance for that?
> Curious how it would stack up against triednt2+ based switches fo VXLAN
> routing.
>
> On Mon, May 14, 2018 at 8:44 PM Mark Tinka  wrote:
>
> >
> >
> > On 15/May/18 02:24, Aaron Gould wrote:
> > > Does it have lots of MPLS service capability?
> >
> > It's the same Trio chip you find in modern MPC's. So I expect so.
> >
> > Testing some shortly.
> >
> > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204

[Tim Jackson]

It's a great box. Basically an MPC7e in 1RU with a fast intel-based RE
(Xeon E5-2608Lv4)

Only kinda weird drawback is you can't use all 4x100G and the 8xSFP+
onboard. (https://apps.juniper.net/home/port-checker/)

17.4R1+ only.

The routing-engine VM gets 16G of ram. 32G total in the box.

No MIC slots, so 0 services you can add to it (no MS-MIC, etc).. 8x SFP+,
4x QSFP-28..

What else do you wanna know?


On Mon, May 14, 2018 at 12:41 PM, Bill Blackford 
wrote:

> Anyone using MX204?
>
> Thoughts?
>
> Benefits / Drawbacks?
>
> Thank you in advance.
>
> B
>
> ___
> 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] What is your experience with the EX2200

[Tim St. Pierre]

I have a DC model that has well over 1000 days of uptime, not a single 
issue.


I do a lot of vLAN, some IGMP snooping, and use the SFP ports.  I 
haven't done any routing with it as of yet, but it's a great switch for 
simple needs.




On 2017-12-08 12:41 PM, Dan White wrote:

We're considering purchasing these switches for our branch offices. Our
needs include PoE, and basic routing functionality. What's been your
experience with these switches?



--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?

[Tim St. Pierre]

Well, that clears that up.

Seems odd they would choose the same form factor for incompatible 
designs, but that explains why the 2-port card is more expensive.


Thanks!


On 2017-12-03 05:27 PM, Saku Ytti wrote:

Hey Tim,

Simple answer, not possible, as you need PHY and 4x10GE does not have
one, while 2x10GE does have one.





Longer answer.

This is quite interesting question. I'll first explain why the answer
is decidedly 'not possible on MX80'. Trio MQ WAN side can operate as
SERDES or 4x10GE PHY. which can drive XFP ports directly. On MPC cards
and  MX80 the front-plate 4x10G use the PHYs on MQ. Rest of the ports
on MX80vsit on 'fabric' side, which can only run as SERDES. To attach
any more ports than 4x10GE on-boardvports to MX80, you need chip to
talk to the fabric side, which is SERDES only, you need some chip to
interface with SERDES and offer PHY (IX chip.

So 4x10GE MIC is simpler, stupider (And lower BOM) than 2x10GE MIC, as
it does not have IX chip at all, as PHY is driven by MQ. Where as
2x10GE MIC has IX chip and PHY. This allows us to put the 2x10GE
interfaces on the 'fabric' side of the MQ.

Now for reasons I don't fully understand MQ PHY actually cannot drive
SFP+, only XFP. So MX104 is using IX chip and external PHY to drive
the on-board SFP+. Technically it /could/ sit on 'fabric' side, and
you could wire the box so that on WAN side you can attach 4x10GE XFP
MIC. However I'm almost certain that the on-chassis SFP+ ports are
still connected on the WAN side, so reason why it wouldn't never work
on MX104 is same as MX80, no PHY on the 4x10GE XFP MIC.



On 24 November 2017 at 19:20, Tim St. Pierre <t...@communicatefreely.net> wrote:

Hello,

As anyone ever put a 4XGE MIC card in a MX104?  Only the 2XGE card is
supported obviously, but I'm curious to know what would happen if someone
did?  Is it just oversubscribed?  Would it not work at all?

-Tim

--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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






--
--
Tim St. Pierre
System Operator
Communicate Freely
289 225 1220 x5101
t...@communicatefreely.net
www.communicatefreely.net

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

[j-nsp] MIC-3D-4XGE-XFP in a MX104?

[Tim St. Pierre]

Hello,

As anyone ever put a 4XGE MIC card in a MX104?  Only the 2XGE card is 
supported obviously, but I'm curious to know what would happen if 
someone did?  Is it just oversubscribed?  Would it not work at all?


-Tim

--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

Re: [j-nsp] Simple v4 vs v6 traffic measurement

[Tim St. Pierre]

It won't work on the M10i, but when I get the MX104 turned up, I'm going 
to try this!


Just to follow up, I did manage to get Cacti graphing the firewall 
counters, so I now have nice graphs, and can see that we are about 25% 
IPv6 now.


Thanks everyone!



On 2017-10-31 05:21 PM, Daniel Verlouw wrote:

Tim,

On Tue, Oct 31, 2017 at 9:00 PM, Tim St. Pierre
<t...@communicatefreely.net> wrote:

Can anyone suggest a simple way to measure interface traffic by address
family?  Currently, I'm measuring interface traffic using SNMP queries and
just grabbing the in / out bit byte counters.

check out 
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/forwarding-class-accounting-edit-interfaces.html
(only on MX/MPC)
IIRC there's a separate MIB too.

   --Daniel.


--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

Re: [j-nsp] Simple v4 vs v6 traffic measurement

[Tim St. Pierre]

Cool.  I made up the filters and counters, and I can see them at show 
firewall counter customer-v4-down filter res-out-4 for example.


Now I just need to install the firewall MIB for Cacti.

Thanks!


On 2017-10-31 04:50 PM, Saku Ytti wrote:

Hey Tim,


Can anyone suggest a simple way to measure interface traffic by address
family?  Currently, I'm measuring interface traffic using SNMP queries and
just grabbing the in / out bit byte counters.

One way would be to create firewall filter with counter for both AFIs.
Filter counters are SNMP gettable.



--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

Re: [j-nsp] MACsec over a service provider

[Tim Jackson]

I've done 1g MACSEC over l2circuit or ccc just fine.. You can even do stuff
like get an MX104 with a 20G MIC that supports MACSEC, loop a 1g port back
into itself, carry that EoMPLS over a GRE tunnel w/ inline frag/re-assembly
and do "encrypted" VPN using a pair of MX104s..

--
Tim

On Tue, Oct 31, 2017 at 3:49 PM, Chuck Anderson <c...@wpi.edu> wrote:

> My testing has revealed that it works, as long as the service provider
> (MX) is doing something like e-line/l2circuit/CCC rather than bridging.  I
> even got it to work with ethernet-ccc on the MX port facing the EX4300 and
> vlan-ccc on the MX port facing the core/WAN.
>
> However I've now run into an issue where I can only get a single MACsec
> connection working on the EX4300's.  As soon as I add a 2nd one, it fails
> to come up.  If I then reboot, neither one comes up.  If I deactivate the
> 2nd one, the 1st one comes up.
>
> On Tue, Oct 31, 2017 at 07:30:35PM +, Nick Cutting wrote:
> > I am also interested in this - my carriers keep saying "try it"
> >
> > I have the config now - still have not tested - but I'm moving many of
> my customer P2P links (hosted by carriers) to nexus switches that don't
> support macsec.
> >
> > Is anyone in the enterprise doing this over e-line services?
> >
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf Of Chuck Anderson
> > Sent: Friday, October 27, 2017 9:39 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] MACsec over a service provider
> >
> > This Message originated outside your organization.
> >
> > Destination MAC 01:80:c2:00:00:03, EtherType 0x888e (ieee8021x) is eaten
> by the PE router (MX480).  I'm not sure about the ASR9k at the other end of
> the production scenario--it may have the same trouble.
> >
> > My lab is like this, with the EX2200 substituting for the ASR9k.  The
> idea is to have MACsec between the EX4300s, with the middle being
> transparent to it.
> >
> > I got this working:
> >
> > EX4300---EX2200---EX4300
> >
> > For the EX2200, I had to configure layer2-protocol-tunneling to allow
> the EAPOL 802.1x through:
> >
> > vlans {
> > MACSEC-TRANSPORT {
> > vlan-id 10;
> > ##
> > ## Warning: requires 'dot1q-tunneling' license
> > ##
> > dot1q-tunneling {
> > layer2-protocol-tunneling {
> > all;
> > }
> > }
> > }
> > }
> >
> > MACsec comes up fine on both EX4300s and I can ping between them.
> >
> >
> > But this fails:
> >
> > EX4300---EX2200---MX480---EX4300
> >
> > I'm doing simple bridging through the MX, but the MX doesn't support the
> mac-rewrite needed (ieee8021x).  Anyone have any clever ideas to work
> around that limitation?
> >
> > On Fri, Oct 27, 2017 at 05:40:57PM +0300, Elijah Zhuravlev wrote:
> > > Hello
> > >
> > > Ethertypes 0x888e and 0x88e5 should be supported by the switching hw,
> > > no any other special requirements.
> > > Btw keep in the mind macsec overhead, +32.
> > >
> > > regards, Eli
> > >
> > > On Fri, 27 Oct 2017 10:23:01 -0400
> > > Chuck Anderson <c...@wpi.edu> wrote:
> > >
> > > > Has anyone been able to run MACsec over a service provider's
> > > > Ethernet Private Line (or even just a 802.1q vlan)?  I'm looking at
> > > > using 10gig ports on the EX4300 or the EX4600/QFX5100-24Q with the
> > > > MACsec uplink module.
> ___
> 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] Simple v4 vs v6 traffic measurement

[Tim St. Pierre]

Hello,

Can anyone suggest a simple way to measure interface traffic by address 
family?  Currently, I'm measuring interface traffic using SNMP queries 
and just grabbing the in / out bit byte counters.


I would like to somehow measure the amount of IPv4 and IPv6 traffic 
separately, mostly to see how well our customer uptake is on the v6 side 
of things.  Without getting into traffic sampling (may try that another 
day), is there a simple way to set a counter by address family on an 
interface?


I'm mostly working with MX, but have one M10i in there too.

Thanks!

-Tim

--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

Re: [j-nsp] Using a QFX5100 without QFabric?

[Tim Jackson]

MPLS is now supported on IRB on QFX5100:

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html#jd0e57



On Fri, Oct 27, 2017 at 3:50 PM, Andrey Kostin  wrote:

> Chris Wopat писал 25.10.2017 13:00:
>
>> On 10/24/2017 05:30 PM, Vincent Bernat wrote:
>>
>>>   ❦ 24 octobre 2017 14:29 -0400, Andrey Kostin  :
>>>
>>>
> Straight up saying "don't put public IPs on them" doesn't seem like
>> the best advice to me. You can certainly do this, we do and it's fine.
>> When you craft your RE protection filter you just have to squeeze a
>> bit more space here or there compared to say, an MX filter. You should
>> have this enabled weather you're using public IPs or not.
>>
>> Regarding TCAM programming, it's loud and clear when this happens via
>> a console message and a sev0 syslog message.
>>
>
> Yes, that's true, and we spend a decent amount of time packing lo0 filters
> in a tiny TCAM after discovered that filter input-list silently allows
> everything except the first filter and doesn't generate any complaint.
> So, no objection for public IPs but only careful filter planning required.
>
> --
> Kind regards,
> Andrey
>
> ___
> 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] EX4550 (Un-)known unicast flooding at session start for up to 100ms

[Tim]

Hi Pavel,

not sure if it's related but is very interessting. I checked the mac
learning log on several 4550 and found the learn/delete indicator
minute by minute. I think we will increase the entry counts per index
an look if something getting better (or worse).

Regards,
Tim

2017-08-12 11:54 GMT+02:00 Pavel Lunin <plu...@gmail.com>:
>
>
> Not sure this is specifically related to the OP but there is a known
> hardware limitation/feature of some Broadcom chips used in many EX switches
> of the previous generations (including EX4500). They use a hash table to
> reduce MAC lookup length, which was too small in some older JUNOS versions,
> leading to hash-collisions and consequent mac learning failures in some
> scenarios.
>
> Links, worth to check:
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/mac-lookup-length-edit-ethernet-switching-options.html
> https://forums.juniper.net/t5/Ethernet-Switching/EX4500-show-ethernet-switching-hash-collisions/td-p/204849
> https://yingsnotebook.wordpress.com/2017/03/20/mac-address-learning-problem-in-juniper-ex-switch/
>
>
>
>
> 2017-08-12 2:14 GMT+02:00 Aaron Gould <aar...@gvtc.com>:
>>
>> Sorry to hear that.
>>
>> I may have mentioned previously to someone else on the list... my EX4550's
>> are rock solid... over 4 years uptime... I run our mirrored/redundant data
>> centers behind them (hp 3par, hypervisors, etc) and our internet cdn caches
>> behind them too...(Akamai, netflix, and that other one)
>>
>> A pair of 4550's in top of racks virtual chassis'ed together
>>
>> Here they are...
>>
>> root@sabn-dcvc-4550> show system uptime | grep "up|fpc"
>> fpc0:
>> 7:07PM  up 1516 days,  5:51, 0 users, load averages: 0.09, 0.11, 0.08
>> fpc1:
>> 7:07PM  up 1516 days,  5:51, 2 users, load averages: 0.22, 0.17, 0.16
>>
>>
>> root@stlr-dcvc-4550> show system uptime | grep "up|fpc"
>> fpc0:
>> 7:09PM  up 1520 days,  4:21, 0 users, load averages: 0.11, 0.15, 0.14
>> fpc1:
>> 7:09PM  up 1520 days,  4:42, 1 user, load averages: 0.25, 0.22, 0.18
>>
>>
>> root@stlr-dcvc-4550> show version | grep "fpc|model|boot"
>> fpc0:
>> --
>> Model: ex4550-32f
>> JUNOS Base OS boot [12.2R4.5]
>> fpc1:
>> --
>> Model: ex4550-32f
>> JUNOS Base OS boot [12.2R4.5]
>>
>> run a bunch of vlans/stp...
>>
>> {master:1}
>> root@stlr-dcvc-4550> show spanning-tree bridge brief | grep
>> "protocol|Vlan"
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 12
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 1000
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 10
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 11
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 210
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 204
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 202
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 201
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 14
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 13
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 1006
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 101
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 921
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 2
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 2202
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 3
>> Enabled protocol: RSTP
>>
>> STP bridge parameters for VLAN 4
>>
>>
>>
>> ___
>> 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] EX4550 (Un-)known unicast flooding at session start for up to 100ms

[Tim]

Hi Brian,

yes we're using MSTP. The bridge-priority of EX4550 and QFZ are all on
default (32k afaik), because the QFX is connected to a Cisco 6500,
which is the Core.

We're in the middle of a Cisco -> Juniper migration.

regards,
Tim


2017-08-11 16:55 GMT+02:00 Brian Nelson <brian.nel...@utdallas.edu>:
> Tim,
> Basic question: do you have spanning tree enabled and what is the
> bridge-priority of each boxen?
>
> Brian Nelson
>
>
> On 8/11/2017 5:00 AM, Tim wrote:
>
> Hi everybody,
>
> the last half year (since we extend some monitoring/logging things) we
> observe multiple times a day strom control triggering across the
> network. We could trace it back, that it happen on a regular basis if
> heavy stream are initiated (database copy jobs, vmotion stuff, etc.)
> it seems that the EX4550 Switches in the data path needs up to 100ms
> for mac learning unit he stops the (un-)known unicast flooding.
> Because of the heavy nature of the traffic streams we are talking
> about 7-8 MB flooded traffic during the 100ms.
>
> The topology is quite simple and straight.
>
> SRV1 - EX4550 - QFX5100 - EX4550 - SRV2
>
> With a sniffing server attached to a normal port on the EX4550 Switch
> near SRV1. Normal port means, that it is of course not a mirror port
> to only got the flooded stuff.
>
> We've open a case at our service partner, but recieved a at least
> disputable answer "Hey, works as designed. Normal behavior like Cisco,
> etc.)"
>
> In my personal 15 years experience with Cisco, Extreme/Enterasys
> Networks and Nortel Networks i've never see this magnitude of MAC
> learning latency / unicast flooding.
> If i imagine that this behavior is normal, it would mean that just a
> dozen concurrent heavy streams would fuck up all other ports and even
> a 40G uplink has no chances and gets heavily overloaded in this time
> frame.
>
> What brings me to my question. Does anyone here have any experience
> with "typical" MAC learning latencies or similar problems with Juniper
> / $vendor like this?
>
> Best regards,
> Tim
> ___
> 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] EX4550 (Un-)known unicast flooding at session start for up to 100ms

[Tim]

Hi everybody,

the last half year (since we extend some monitoring/logging things) we
observe multiple times a day strom control triggering across the
network. We could trace it back, that it happen on a regular basis if
heavy stream are initiated (database copy jobs, vmotion stuff, etc.)
it seems that the EX4550 Switches in the data path needs up to 100ms
for mac learning unit he stops the (un-)known unicast flooding.
Because of the heavy nature of the traffic streams we are talking
about 7-8 MB flooded traffic during the 100ms.

The topology is quite simple and straight.

SRV1 - EX4550 - QFX5100 - EX4550 - SRV2

With a sniffing server attached to a normal port on the EX4550 Switch
near SRV1. Normal port means, that it is of course not a mirror port
to only got the flooded stuff.

We've open a case at our service partner, but recieved a at least
disputable answer "Hey, works as designed. Normal behavior like Cisco,
etc.)"

In my personal 15 years experience with Cisco, Extreme/Enterasys
Networks and Nortel Networks i've never see this magnitude of MAC
learning latency / unicast flooding.
If i imagine that this behavior is normal, it would mean that just a
dozen concurrent heavy streams would fuck up all other ports and even
a 40G uplink has no chances and gets heavily overloaded in this time
frame.

What brings me to my question. Does anyone here have any experience
with "typical" MAC learning latencies or similar problems with Juniper
/ $vendor like this?

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

[j-nsp] QoS on subinterfaces clarification

[tim tiriche]

Hi,

If i have 1 physical interface of 10G and 2 sub interface.  How can i make
sure:

1 Interface = 4G
2 Interface = 6G

And then Queues on each interface.  Eg: EF = 10% of 4G on 1 Interface and
EF = 10% of 6G on 2 Interface?

Do the queues, get percentages based on the shaping value?

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

[j-nsp] qos output classifer and scheduler on same interface

[tim tiriche]

Hi,

I have an MPLS ckt of 10M to a provider that is congested on outbound and
would like to apply QoS profile on it.

Can i apply an output MF classifier to classify the traffic into the queue
and then apply the scheduler profiles?

Typically, classification is done on inbound but i have quite a few input
sources and would only like to apply it on this interface.  Has anyone done
this and would this work?


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

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

https://www.juniper.net/documentation/en_US/junos16.1/topics/concept/mpls-features-qfx-series-overview.html#mpls-features-by-release

On Fri, Dec 16, 2016 at 2:50 PM, Aaron <aar...@gvtc.com> wrote:

> Thanks Tim(s), I understand the QFX1 isn’t mpls capable.
>
>
>
> Also, I’m thinking the cisco ncs5501 might work for me at (6) 100’s.
> also, wow, ncs5502 has (48) 100 gig.
>
>
>
> -Aaron
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

Arista does not have RSVP-TE, nor fully featured BGP-LU..

FlexRoute for full fib usage seems a little like black magic & hand waving
though:
https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf


The other cheaper option to the PTX1000 is QFX1 when you don't need a
full FIB.

--
Tim



On Fri, Dec 16, 2016 at 2:30 PM, Jesper Skriver <jes...@skriver.dk> wrote:

> On Fri, Dec 16, 2016 at 02:21:22PM -0600, Aaron wrote:
> > I was thinking about the ptx1000 as a supercore fast mpls swapping
> p-box.  I understand it can have (24) 100 gig !
> >
> > I've seen the PTX1000 referred to as a supercore router , and I
> understand it has MPLS LSR functions (someone told me that it does not do
> mpls edge (pe) functions)
> >
> > ...i see/hear no mention of mpls for this 7280...
> > https://www.arista.com/en/products/7280r-series
> > http://www.gossamer-threads.com/lists/nanog/users/188708
>
> https://www.arista.com/en/support/product-documentation/supported-features
>
> click MPLS tab
>
> > ...i have heard of the NCS5500 but I think it only has (4) 100 gig and
> we are wanting 6 or more.  Does cisco have a small form factor mpls router
> with lots of 100 gig ?
> >
> > - Aaron
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Durack]

NCS-5501 non-SE version is 48x 10G + 6x 100G
NCS-5502 is 48x 100G


On Fri, Dec 16, 2016 at 3:21 PM Aaron <aar...@gvtc.com> wrote:

> I was thinking about the ptx1000 as a supercore fast mpls swapping p-box.
> I understand it can have (24) 100 gig !
>
> I've seen the PTX1000 referred to as a supercore router , and I understand
> it has MPLS LSR functions (someone told me that it does not do mpls edge
> (pe) functions)
>
> ...i see/hear no mention of mpls for this 7280...
> https://www.arista.com/en/products/7280r-series
> http://www.gossamer-threads.com/lists/nanog/users/188708
>
> ...i have heard of the NCS5500 but I think it only has (4) 100 gig and we
> are wanting 6 or more.  Does cisco have a small form factor mpls router
> with lots of 100 gig ?
>
> - Aaron
>
> -Original Message-
> From: Jared Mauch [mailto:ja...@puck.nether.net]
> Sent: Friday, December 16, 2016 1:12 PM
> To: Tim Jackson <jackson@gmail.com>
> Cc: Aaron <aar...@gvtc.com>; jnsp <juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] Juniper PTX1000
>
> There’s 3 main boxes in this space, the Cisco NCS550x, PTX1K and the
> Arista 7280 all with varying positives/negatives based on your use case.
>
> I’m not aware of many other full fib scale devices in this profile, if I’m
> missing some I’d like to know :-)
>
> - Jared
>
> > On Dec 16, 2016, at 2:08 PM, Tim Jackson <jackson@gmail.com> wrote:
> >
> > It costs wy too much is what I think about it..
> >
> > --
> > Tim
> >
> >
> >
> > On Fri, Dec 16, 2016 at 12:12 PM, Aaron <aar...@gvtc.com> wrote:
> >
> >> Anyone using the PTX1000 ?  If so, let me know what you think about it.
> >>
> >>
> >>
> >> - 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
>
>
> ___
> 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] Juniper PTX1000

[Tim Jackson]

It costs wy too much is what I think about it..

--
Tim



On Fri, Dec 16, 2016 at 12:12 PM, Aaron <aar...@gvtc.com> wrote:

> Anyone using the PTX1000 ?  If so, let me know what you think about it.
>
>
>
> - 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

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Tim Jackson]

monitor traffic interface ge-0/0/0 size  no-resolve layer2-headers
extensive

--
Tim

On Mon, Nov 28, 2016 at 12:43 PM, Alex K. <nsp.li...@gmail.com> wrote:

> Hello everyone,
>
> By any chance - is there an equivalent for Ciscos' "debug ip packet"
> command in Juniper?
>
> I'm fully aware that there is a complete distinction between forwarding
> layer and control layer, in those devices - But,  I'm taking specifically
> about traffic TARGETING the box itself.
>
> I'm troubleshooting a strange behavior by Juniper EX line. It's a compex
> topology but the issue is very simple: under certain circumstances, an EX
> stop responding even to pings to its own addresses, even from directly
> connected interfaces.
>
> I'm fully aware that I can mirror a port on those machines (and such), but
> mirroring alone, will not answer the million dollar question - why?
>
> Since there is no doubt that packets are reaching the box (packets don't
> leak from a directly connected cable, with PC on its other end) - I was
> hoping, Juniper might have provided us with a trace option, for following
> the packet inside the box?
>
> Anyone know such trace option?
>
>
> Any suggestions will be welcomed.
> ___
> 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] QoS when there is no congestion

[Tim St. Pierre]

If you have some lower bandwidth links, you may still see a latency 
improvement if you implement QoS.


The important thing here is in your output queues, as strict priority 
will see voice traffic serviced first.  Even if nothing is ever dropped, 
going out the queue first keeps latency low.


-Tim

On 2016-11-08 04:48 AM, tim tiriche wrote:

Hello,

Do we need QoS if there is no congestion in the network for Voice/Video
traffic?

Is there a case where Voice/Video traffic could experience any delay if
there were data packets to process before the voip traffic?

Would this be a concern on older hardware?

for example:

[voip][data][data][data][data] --> router

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


--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

[j-nsp] QoS when there is no congestion

[tim tiriche]

Hello,

Do we need QoS if there is no congestion in the network for Voice/Video
traffic?

Is there a case where Voice/Video traffic could experience any delay if
there were data packets to process before the voip traffic?

Would this be a concern on older hardware?

for example:

[voip][data][data][data][data] --> router

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

Re: [j-nsp] Infranet controller solution

[Tim Jackson]

The Pulse Secure you're talking about is the Dynamic VPN client, not as an
Infranet enforcer..

--
Tim

On Fri, Oct 28, 2016 at 11:45 AM, Bill Blackford <bblackf...@gmail.com>
wrote:

> I believe it's a licensing issue and I don't know the details of their
> agreement with Pulse Secure after they spun them off, so it may be all of
> the platforms. I ran into it with the branch models.
>
> On Fri, Oct 28, 2016 at 7:54 AM, james list <jameslis...@gmail.com> wrote:
>
> > Interesting, which models are you referring to ? Also high end (ie 5600
> or
> > 5800) ?
> >
> > Cheers
> >
> > 2016-10-28 16:49 GMT+02:00 Bill Blackford <bblackf...@gmail.com>:
> >
> >> I was told by our SE that the newer models of SRX will no longer support
> >> Pulse Secure. I've also had to downgrade code to get older models to
> >> support it as well.
> >>
> >> Sent from my iPhone
> >>
> >> > On Oct 28, 2016, at 00:59, Michael Gehrmann <mgehrm...@atlassian.com>
> >> wrote:
> >> >
> >> > Hi James,
> >> >
> >> > I'm only aware of Palo Alto and Juniper supporting this function. The
> >> next
> >> > generation SRX (300 and 1500) have some pretty good pricing from what
> I
> >> > have experienced.
> >> >
> >> > https://www.pulsesecure.net/download/document/988/PulseSecur
> >> e_Solution_Brief_PAN_PPS_d1v5.fin.pdf
> >> >
> >> > I have experienced the Juniper integration with NAC and it works very
> >> well.
> >> >
> >> > Cheers
> >> > Mike
> >> >
> >> >> On 28 October 2016 at 18:52, james list <jameslis...@gmail.com>
> wrote:
> >> >>
> >> >> Hi Mike
> >> >> here the functionality I'm looking for in the firewall device:
> >> >>
> >> >> - integration with MAG Pulse Secure
> >> >> - policy enforcement using at least destination ip address, port and
> >> >> protocol
> >> >> - policy enforcement with action at least like allow, deny, reject
> >> >> - policy enforcement based on user role
> >> >>
> >> >> Cheers
> >> >> James
> >> >>
> >> >>
> >> >> -
> >> >>
> >> >> 2016-10-28 7:21 GMT+02:00 Michael Gehrmann <mgehrm...@atlassian.com
> >:
> >> >>
> >> >>> Hi James,
> >> >>>
> >> >>> Might be useful if you describe what functionality you are trying to
> >> >>> achieve. i.e. SRX as an enforcer
> >> >>>
> >> >>> Also you may not find many 'cheaper' alternatives in the TNC space:
> >> >>> https://en.wikipedia.org/wiki/Trusted_Network_Connect
> >> >>>
> >> >>> Cheers
> >> >>> Mike
> >> >>>
> >> >>>> On 28 October 2016 at 01:36, james list <jameslis...@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>> Hi experts,
> >> >>>>
> >> >>>> has anybody ever configured an infranet controller solution using
> MAG
> >> >>>> (today Pulse Secure) other than using SRX firewall ?
> >> >>>>
> >> >>>>
> >> >>>> I looking to find an alternative solution to SRX and as far as I’ve
> >> >>>> searched till now, seems that only Palo Alto could do something.
> I’m
> >> >>>> wondering if there are (cheaper) alternative…
> >> >>>>
> >> >>>>
> >> >>>> Thanks in advance
> >> >>>>
> >> >>>>
> >> >>>> Cheers
> >> >>>>
> >> >>>> James
> >> >>>> ___
> >> >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Michael Gehrmann
> >> >>> Senior Network Engineer - Atlassian
> >> >>> m: +61 407 570 658
> >> >
> >> >
> >> > --
> >> > Michael Gehrmann
> >> > Senior Network Engineer - Atlassian
> >> > m: +61 407 570 658
> >> > ___
> >> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >
> >
>
>
> --
> Bill Blackford
>
> Logged into reality and abusing my sudo privileges.
> ___
> 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] EVPN/VXLAN on QFX5100

[Tim Jackson]

You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3
lookup for the remote VTEP goes across an LSP the VXLAN traffic will too..

But it's not l2ompls.. it's l2ovxlanoipompls.

--
Tim

On Aug 3, 2016 6:52 PM, "Chris Kawchuk" <juniperd...@gmail.com> wrote:

> You cannot use MPLS as the "underlay" Transport on QFX51xx. I tried the
> same -- you need to use VxLAN as the "transport LSP" so to speak. (Think of
> VXLAN remote VTEP IP address as being the outer label, and the VNI is the
> inner label.)
>
> There's a config guide floating around out there on the JNPR Website fort
> the QFX manual showing how to setup the VTEPs so that the switches setup an
> "inet.3" table between each other for remote-next-hop resolution (from
> iBGP/MP-BGP sessions), pointing to a remote VTEP IP.
>
> Good luck! Would be nice if they could do MPLS as the underlay, but
> <-insert Trident2+ Pipeline issues-> here.
>
> - CK.
>
>
> On 4 Aug 2016, at 7:19 am, Joe Freeman <j...@netbyjoe.com> wrote:
>
> > The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and
> > MP-IBGP.
> >
> > A show evpn instance extensive command shows that the two switches see
> each
> > other, but I am unable to learn mac addresses between them.
>
> ___
> 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] MX104 capabilities question

[Tim Jackson]

It can't hold a full table in it's FIB for sure, but in the RIB it's fine:

inet.0: 588286 destinations, 1091804 routes (588284 active, 0 holddown, 2
hidden)

--
Tim

On Thu, Jun 9, 2016 at 9:40 AM, Aaron <aar...@gvtc.com> wrote:

> Thanks, Let me test this claim that an acx5048 cannot hold a full bgp
> table…… anyone know a way to get a test bgp session for a full feed ?
>
>
>
> -Aaron
>
>
>
>
>
> “I think the big thing the ACX5048 is lacking is the ability to hold a
> full routing table compared to the MX104 and ASR9001. Remember the ACX5048
> has a Broadcom Trident II chipset.”
>
>
>
>
>
> ___
> 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] force-64bit

[Tim Hoffman via juniper-nsp]

On Wed, Jun 1, 2016 at 11:09 AM, Saku Ytti  wrote:

> On 1 June 2016 at 20:32, Phil Rosenthal  wrote:
> > I suspect that there is not that high of a risk of bugs due to this
> change, in all likelihood, the only changes required for this was a
> different compiler and perhaps the use of a few 64 bit instead of 32 bit
> variables — but even with a low risk of bugs, if there is no benefit, I’m
> not sure what the point of adding even a low risk of bugs.
>
> This is also not super new feature, it's been in shipping software for
> over two years.


So this means we're half way towards it being stable right
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Tim Hoffman via juniper-nsp]

64bit RPD is newer, and by nature will have more bugs - so don't run this
unless you need it. Check this with "show task memory" - this will show
what you have used of the RPD accessible memory. As Phil notes, you'd need
significant RIB scale (which does exist in larger networks) to require
this...

Enabling this will cause RPD to restart as you kill one process and start
another.

Tim

On Wed, Jun 1, 2016 at 9:22 AM, Phil Rosenthal <p...@isprime.com> wrote:

> I’ll ask the obvious question — do you actually have a ‘need’ for this?
>
> Even on systems with many peers, 5+ full tables, and a full IGP mesh, I
> haven’t seen rpd much over 1GB of ram in use.  64bit rpd would only be
> beneficial if you have a need for a rpd process using more than 4GB of ram.
>
> Is this a theoretical use case, or is there an actual need?
>
> Best Regards,
> -Phil Rosenthal
> > On Jun 1, 2016, at 3:58 AM, Theo Voss <m...@theo-voss.de> wrote:
> >
> > Hi,
> >
> > has anybody enabled „system processes force-64bit“ on 64bit Junos? Have
> you done this during daily ops or during a maintenance window? According to
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode:
> „You need not restart the routing protocol process (rpd) to use the 64-bit
> mode.“...
> >
> > Thanks in advance for your comments! ;-)
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > Cheers,
> > Theo Voss
> > ___
> > 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
>



-- 
Tim Hoffman | Twitter, Inc.
1355 Market St. | San Francisco, CA | 94103
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] srrd process

[Tim Jackson]

451m here on an MX104 running 14.2:

 2269 root 1  400   451M   445M select  36:07  0.00% srrd

Looks to be the sampling daemon:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1F5/topic-104232.html

With Junos OS Release 15.1F2 and later, when inline sampling is enabled on
MX Series-based FPC, the srrd (Sampling Route-Record Daemon) process would
be created to maintain, collect and export JFLOW records. On a regular time
intervals, the srrd scans through the sampling database for any
update/change in the record. In a scaled environment with more route churn,
for example 1.14M routes, the scan process might hog CPU for more than
2.5sec which leads to FPC crash. In some situations, the scan process can
run for longer time without causing FPC crash, but it can cause BFD
sessions to flap. PR1158154

--
Tim


On Thu, May 19, 2016 at 12:03 PM, Han Hwei Woo <h...@astutehosting.com>
wrote:

> We had an MX80 become unresponsive the other night while trying to turn
> down our peers at an exchange during a maintenance, which was due to
> running out of RAM and a bunch of processes swapping out. We had recently
> upgraded to 14.2R6.5, and have now noticed there is a new process that
> wasn't present in 12.3 and 13.3.
>
>   PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU
> COMMAND
>  1733 root 1   40   778M   705M kqread  43:13  0.73% rpd
>  1745 root 1  400   585M   578M select   0:20  0.00% srrd
>
> I can't seem to find anything about what srrd is. Anyone have any ideas,
> and what function it serves? Almost 600MB out of a total 2GB on an MX80 is
> quite a good portion.
>
> --
> Han Hwei Woo
> h...@astutehosting.com
>
> Astute Hosting Incorporated
> T: 1.888.685.1661 (604.637.7939)
> M: 604.417.2092
> F: 604.738.0518
> www.astutehosting.com
> 100% Uptime Dedicated Hosting in Vancouver, Seattle,
> Los Angeles, Toronto, New York, and Miami
>
> ___
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Tim Jackson]

I've never used their software in production, but I have been looking
at it for some 100G ToR switches.. The featureset is awesome, but I
can't really speak to how well the software works as I haven't
received any demo gear actually running it yet..

I will say that a 32x100G Tomahawk + their SW is less (by a little)
than I was paying for Trident II boxes (QFX5100/EX4600) from Juniper..
I don't know what ACX5k costs, though.

--
Tim

On Tue, May 10, 2016 at 12:16 PM, Colton Conor <colton.co...@gmail.com> wrote:
> Tim,
>
> Do you use IP Infusion software today? I have never heard of them, but I
> like the software feature set I see on their website with MPLS and MEF
> features. However, I doubt the white box plus their software will be any
> less than the Juniper solution, but I could be surprised.
>
> On Tue, May 10, 2016 at 8:46 AM, Tim Jackson <jackson@gmail.com> wrote:
>>
>> You might be able to buy some off the shelf (E.g. Acton or quanta etc)
>> white box Trident 2 box and look IP Infusion for an OS on it. It may be cost
>> competitive and have almost all of the features..
>>
>> On May 10, 2016 8:31 AM, "Colton Conor" <colton.co...@gmail.com> wrote:
>>>
>>> Aaron,
>>>
>>> Just wondering if you company compared any other products from other
>>> vendors against the ACX5048? Is there anything else on the market with
>>> this
>>> high of port count, for this low of a price, with this amount of
>>> features?
>>>
>>> On Mon, May 9, 2016 at 11:52 AM, Aaron <aar...@gvtc.com> wrote:
>>>
>>> > Thanks Raphael,
>>> >
>>> > My core links are untagged typically... in rare case I'll tag, and it
>>> > doesn't seem to be a problem, I haven't done that on acx5048 yet
>>> >
>>> > Ok I did MEF EPL (eline port based carrying any and all vlans, tagged
>>> > and
>>> > untagged...) works. I shut and deactivate core bgp for this test to
>>> > prove
>>> > that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
>>> > l2protocols seem to be fine ( I tested cdp and stp for CE to CE and
>>> > it's
>>> > fine )...of course the config's below are the MPLS PE's... the ce's I
>>> > mention are not shown anywhere here.
>>> >
>>> >
>>> > ---3600
>>> >
>>> > interface GigabitEthernet0/15
>>> >
>>> >  switchport trunk allowed vlan none
>>> >
>>> >  switchport mode trunk
>>> >
>>> >  load-interval 30
>>> >
>>> >  service instance 1 ethernet
>>> >
>>> >   encapsulation default
>>> >
>>> >   l2protocol forward
>>> >
>>> >   xconnect 10.101.12.245 999 encapsulation mpls
>>> >
>>> > --- ACX5048
>>> >
>>> > set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
>>> > virtual-circuit-id 999
>>> >
>>> > set interfaces ge-0/0/38 encapsulation ethernet-ccc
>>> >
>>> > set interfaces ge-0/0/38 unit 0 family ccc
>>> >
>>> > - 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
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Tim Jackson]

You might be able to buy some off the shelf (E.g. Acton or quanta etc)
white box Trident 2 box and look IP Infusion for an OS on it. It may be
cost competitive and have almost all of the features..
On May 10, 2016 8:31 AM, "Colton Conor"  wrote:

> Aaron,
>
> Just wondering if you company compared any other products from other
> vendors against the ACX5048? Is there anything else on the market with this
> high of port count, for this low of a price, with this amount of features?
>
> On Mon, May 9, 2016 at 11:52 AM, Aaron  wrote:
>
> > Thanks Raphael,
> >
> > My core links are untagged typically... in rare case I'll tag, and it
> > doesn't seem to be a problem, I haven't done that on acx5048 yet
> >
> > Ok I did MEF EPL (eline port based carrying any and all vlans, tagged and
> > untagged...) works. I shut and deactivate core bgp for this test to prove
> > that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
> > l2protocols seem to be fine ( I tested cdp and stp for CE to CE and it's
> > fine )...of course the config's below are the MPLS PE's... the ce's I
> > mention are not shown anywhere here.
> >
> >
> > ---3600
> >
> > interface GigabitEthernet0/15
> >
> >  switchport trunk allowed vlan none
> >
> >  switchport mode trunk
> >
> >  load-interval 30
> >
> >  service instance 1 ethernet
> >
> >   encapsulation default
> >
> >   l2protocol forward
> >
> >   xconnect 10.101.12.245 999 encapsulation mpls
> >
> > --- ACX5048
> >
> > set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
> > virtual-circuit-id 999
> >
> > set interfaces ge-0/0/38 encapsulation ethernet-ccc
> >
> > set interfaces ge-0/0/38 unit 0 family ccc
> >
> > - 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cgnat on service module - interesting bgp advertisements

[Tim Jackson]

Mind pasting your show route for those routes and your export policy?
On Apr 19, 2016 6:48 PM, "Aaron"  wrote:

> Very interesting. anyone know why this is happening ?  Is this documented ?
> I put a /25 as the public nat pool, but look what this mx104 is advertising
> via bgp.. It appears to chop up that /25 into a bunch of smaller subnets
> and
> advertise those out
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show configuration | grep 1.2.3. | display set
>
> set services nat pool nat1 address 1.2.3.128/25
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show route advertising-protocol bgp 10.101.0.2
> table one.inet.0
>
>
>
> one.inet.0: 782 destinations, 970 routes (782 active, 0 holddown, 0 hidden)
>
>   Prefix  Nexthop  MED LclprefAS path
>
> * 10.144.2.4/30   Self 100I
>
> * 1.2.3.129/32 Self 100I
>
> * 1.2.3.130/31 Self 100I
>
> * 1.2.3.132/30 Self 100I
>
> * 1.2.3.136/29 Self 100I
>
> * 1.2.3.144/28 Self 100I
>
> * 1.2.3.160/27 Self 100I
>
> * 1.2.3.192/27 Self 100I
>
> * 1.2.3.224/28 Self 100I
>
> * 1.2.3.240/29 Self 100I
>
> * 1.2.3.248/30 Self 100I
>
> * 1.2.3.252/31 Self 100I
>
> * 1.2.3.254/32 Self 100I
>
>
>
>
>
> 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

Re: [j-nsp] protect ssh and telnet

[Tim Jackson]

Sadly, you guys messed up ACX5k lo0 filtering.. Even though it's a
QFX5100/EX4600 inside..

--
Tim

On Mon, Apr 4, 2016 at 9:23 PM, Phil Shafer <p...@juniper.net> wrote:
> Aaron writes:
>>I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
>>on my juniper ACX5048's.
>
> First comment is: if you want security, don't allow telnet.
> Force the use of ssh.
>
> Me, I don't even like allowing passwords.  JUNOS now supports the
> "system services ssh no-passwords" knob to force the use of ssh
> keys over text passwords.  And your radius server will happily serve
> ssh keys.  Force the move away from passwords.
>
> The "lo0" filter covers traffic to the routing engine.  Any filter
> applied to lo0 will block/allow only that traffic.
>
> More generally, take a look at the "secure junos template" from
> Team Cymru:
>
> http://www.team-cymru.org/templates.html
>
> Thanks,
>  Phil
> ___
> 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 ecmp feature and usage

[Tim Jackson]

For L3 and L3VPN ECMP should work fine. For any L2oMPLS you're gonna be SOL.
On Mar 28, 2016 9:08 PM, "Alexandre Guimaraes" <
alexandre.guimar...@ascenty.com> wrote:

> 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Encrypted MPLS between MXes

[Tim Jackson]

That's good news to hear.. Today EX4600 was my solution, and it actually
works quite well.

On Sun, Mar 27, 2016, 1:27 PM Saku Ytti <s...@ytti.fi> wrote:

> On 27 March 2016 at 21:12, Tim Jackson <jackson@gmail.com> wrote:
> > Run EX4600s as your P routers, and encrypt w/ MACSec on them.
>
> IIRC next-gen Trio does MacSec, so all ports will support it.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Encrypted MPLS between MXes

[Tim Jackson]

Run EX4600s as your P routers, and encrypt w/ MACSec on them.
On Mar 27, 2016 1:11 PM, "Alex K."  wrote:

> Hello everyone,
>
> I was just wondering if there's a new way to encrypt MPLS traffic between
> MX boxes without the good old encrypted GRE?
>
> MPLS over encrypted MACSec links, encrypted internal tunnels between
> logical systems, everything goes. If that was your network, what's the
> craziest idea you'd go with?
>
> Is at 2016, we're still stuck with MPLS over GRE over IPSec, to encrypt
> MPLS traffic?
>
> Feel free to share your thoughts.
>
> Thank you.
> ___
> 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] leak routes between L3VPN VRF's

[tim tiriche]

Hello,

I am looking for a clean and simple way to leak routes between VRF's on the
same PE and across different PE?

For eg:  On PE1 and PE2, if i have 3 VRF's. (VRF1, VRF2, VRF3).  These are
mpls l3vpn vrf's.

How can i leak routes between VRF1 and VRF2 on the same PE and across PE

a) Can i do it only using RT (vrf-import)? or do i need to also implement
rib-groups?
b) can i do auto-export with policies on PE1 for exchanging routes only
between VRF1 and VRF2

I would like to avoid rib-groups if possible and looking for simplicity and
best practices around this.

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

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

[tim tiriche]

Hello,

I have an existing L3VPN network with NSR.

If i want to enable EVPN, is it just a matter of enabling family evpn
signalling on the bgp neighbors?

Will doing so, cause a session reset or affect existing production services
or something else i need to be aware of?  this will be on the junos
recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
enable family evpn signalling will NSR be supported for existing l3vpn
functionality?

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

[j-nsp] mpls auto bandwidth - minimum bw

[tim tiriche]

Hi,

In my network, i have mostly 10G links and i have mpls auto bw with min-bw
of 10m configured.
which means when i create an lsp, 10m is always reserved.

however, there are remote sites where i have 10m/100m and with 10m min-bw
reservation the lsp fails to come up.

how do folks address this?  is there any harm in keeping the min-bw 10bps
uniformly everywhere?  will that cause any side effect?


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

Re: [j-nsp] MX: mixin family bridge and family inet

[Tim St. Pierre]

I'm pretty sure you have to add the interfaces to the bridge domains:

vlan-200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.2;
++  interface xe-0/0/2.0;
 }

We use a similar setup on MX, and it works well.



On 2016-01-25 10:34 AM, Vincent Bernat wrote:

Hey!

Currently, I am using an IRB interface on a MX104:

For example, on xe-2/0/2, I have:

#v+
vlan-tagging;
unit 0 {
 family bridge {
 interface-mode trunk;
 vlan-id-list [ 200 300 ];
 }
}
#v-

I have this bridge domain:

#v+
vlan-200 {
 domain-type bridge;
 vlan-id 200;
 routing-interface irb.2;
}
#v-

And irb.2:

#v+
family inet {
 address 172.22.254.225/28;
}
#v-

Now, I would like to be able to also use L3 subinterfaces on
xe-2/0/2. So, I added "flexible-vlan-tagging" (but I think this is
useless) and "encapsulation flexible-ethernet-services"

#v+
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
 encapsulation vlan-bridge; /* Also tried without */
 family bridge {
 interface-mode trunk;
 vlan-id-list [ 200 300 ];
 }
}
unit 100 {
 vlan-id 100;
 family inet {
 unnumbered-address lo0.1;
 }
}
#v-

On xe-2/0/2.100, "monitor traffic interface xe-2/0/2.100" see no packets
(even while pinging) and the counters for this interface are staying to
0. I suppose everything is swallowed by the "family bridge". I can't use
an irb.X interface as it is not possible to use an unnumbered-address in
this case.

Googling a bit, I have been unable to see an example mixing a "family
bridge" with a subinterface. To my understanding,
"flexible-ethernet-services" should allow me to do that.

Any idea?

Thanks!


--
Tim St. Pierre
System Operator
Communicate Freely
www.communicatefreely.net
289-225-1220 x5101

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

[j-nsp] Bandwidth aware using BGP on ISP transit

[tim tiriche]

Hello,

How do big companies manage traffic on ISP links automatically.

For eg: I have 10 ISP/Transit links and all announcing the same prefixes.

During a DDOS attack, one of the ISP link got saturated.

I would like to be able to do something if bandwidth exceeds 50% use other
links.

In MPLS, we can leverage RSVP subscription.  Is there a way to automate
this for Transit peers?

In the past, i have used aspath for certain prefixes which is slow and does
not help for short lived DDOS attacks.

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

Re: [j-nsp] Gracefully delete MPLS RSVP LSP

[Tim Hoffman via juniper-nsp]

Increase the route preference on the LSP;
[edit protocols mpls label-switched-path R1-R2-a]
+preference 200;


On Wed, Dec 16, 2015 at 2:29 PM, Masood Ahmad Shah <masoodn...@gmail.com>
wrote:

> Raising LSP metric sounds good to me
>
> On Wed, Dec 16, 2015 at 10:00 PM, tim tiriche <tim.tiri...@gmail.com>
> wrote:
>
> > Hello,
> >
> > i have 2 LSP to the same destination.
> >
> > 1st LSP name = R1-R2-a
> > 2nd LSP name = R1-R2-b
> >
> > I have link protection enabled.
> >
> > i want to delete the 1st LSP and wanted to know what is a graceful way to
> > do this?
> >
> > Is there a way to shift traffic from 1st LSP to 2nd LSP?  I don't have
> LSP
> > metric and rely on IGP metrics.
> >
> > eg: changing priorities, or can i introduce LSP metrics temporarily to
> 65k?
> >
> > Sincerely,
> > --Tim
> > ___
> > 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] Gracefully delete MPLS RSVP LSP

[tim tiriche]

Hello,

i have 2 LSP to the same destination.

1st LSP name = R1-R2-a
2nd LSP name = R1-R2-b

I have link protection enabled.

i want to delete the 1st LSP and wanted to know what is a graceful way to
do this?

Is there a way to shift traffic from 1st LSP to 2nd LSP?  I don't have LSP
metric and rely on IGP metrics.

eg: changing priorities, or can i introduce LSP metrics temporarily to 65k?

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

Re: [j-nsp] MPLS admin groups implementation

[tim tiriche]

High metric on all inter-regions would be the ideal and simpler way.

I wasn't sure if i might be over looking or missing something.

Any real world experiences would be helpful.

-Tim

On Fri, Dec 11, 2015 at 2:26 AM, Adam Vitkovsky <adam.vitkov...@gamma.co.uk>
wrote:

> > tim tiriche
> > Sent: Friday, December 11, 2015 8:53 AM
> >
> > Hi,
> >
> > I have an existing MPLS network of 3 regions
> >
> > ASIA US and EUROPE
> >
> > I don't want LSP's within US to be established via ASIA or EUROPE and
> vice
> > versa.
> >
> > I want to create an admin group call it: GOLD and apply an exclude on
> all US
> > LSP's.
> >
> > the problem is this will cause LSP to bounce.  since i have my config in
> apply
> > groups this change will affect all lsp's.  i want to know is this
> traffic impacting if
> > i have link protection in place?
> >
> > is there a graceful way to do this?
> >
> Doing a lot of assumptions here but maybe setting high metric on all
> inter-region links?
>
> You can configure your LSPs with "adaptive" cmd -then make before break is
> enabled.
> But I'm not sure if configuring LSP with adaptive will bounce it, it
> shouldn't I think, (but you can try yourself with a dummy lsp).
>
> > second question, if i have a statement like this:
> >
> > lsp a-b
> > admin-group exclude [gold silver]
> >
> > does that mean, if an interface has either gold OR silver an LSP will not
> > choose the path or is it an AND?
> >
> The overall cli rule is if you specify multiple arguments of the same
> character it's OR and it's AND among arguments of different character.
> For example:
>
> admin-group {
> exclude [ group-name1 OR group-name2 ];
> AND
> include-all [ group-names ];
> AND
> include-any [ group-names ];
>
>
> adam
>
>
>
> Adam Vitkovsky
> IP Engineer
>
> T:  0333 006 5936
> E:  adam.vitkov...@gamma.co.uk
> W:  www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmas...@gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS admin groups implementation

[tim tiriche]

The concern is, i have 6 LSP to every router in US and i am not sure if
there is a possibility of any of the LSP's using the high metric inter
region link.


On Fri, Dec 11, 2015 at 2:42 AM, tim tiriche <tim.tiri...@gmail.com> wrote:

> High metric on all inter-regions would be the ideal and simpler way.
>
> I wasn't sure if i might be over looking or missing something.
>
> Any real world experiences would be helpful.
>
> -Tim
>
> On Fri, Dec 11, 2015 at 2:26 AM, Adam Vitkovsky <
> adam.vitkov...@gamma.co.uk> wrote:
>
>> > tim tiriche
>> > Sent: Friday, December 11, 2015 8:53 AM
>> >
>> > Hi,
>> >
>> > I have an existing MPLS network of 3 regions
>> >
>> > ASIA US and EUROPE
>> >
>> > I don't want LSP's within US to be established via ASIA or EUROPE and
>> vice
>> > versa.
>> >
>> > I want to create an admin group call it: GOLD and apply an exclude on
>> all US
>> > LSP's.
>> >
>> > the problem is this will cause LSP to bounce.  since i have my config
>> in apply
>> > groups this change will affect all lsp's.  i want to know is this
>> traffic impacting if
>> > i have link protection in place?
>> >
>> > is there a graceful way to do this?
>> >
>> Doing a lot of assumptions here but maybe setting high metric on all
>> inter-region links?
>>
>> You can configure your LSPs with "adaptive" cmd -then make before break
>> is enabled.
>> But I'm not sure if configuring LSP with adaptive will bounce it, it
>> shouldn't I think, (but you can try yourself with a dummy lsp).
>>
>> > second question, if i have a statement like this:
>> >
>> > lsp a-b
>> > admin-group exclude [gold silver]
>> >
>> > does that mean, if an interface has either gold OR silver an LSP will
>> not
>> > choose the path or is it an AND?
>> >
>> The overall cli rule is if you specify multiple arguments of the same
>> character it's OR and it's AND among arguments of different character.
>> For example:
>>
>> admin-group {
>> exclude [ group-name1 OR group-name2 ];
>> AND
>> include-all [ group-names ];
>> AND
>> include-any [ group-names ];
>>
>>
>> adam
>>
>>
>>
>> Adam Vitkovsky
>> IP Engineer
>>
>> T:  0333 006 5936
>> E:  adam.vitkov...@gamma.co.uk
>> W:  www.gamma.co.uk
>>
>> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
>> of this email are confidential to the ordinary user of the email address to
>> which it was addressed. This email is not intended to create any legal
>> relationship. No one else may place any reliance upon it, or copy or
>> forward all or any of it in any form (unless otherwise notified). If you
>> receive this email in error, please accept our apologies, we would be
>> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
>> email postmas...@gamma.co.uk
>>
>> Gamma Telecom Limited, a company incorporated in England and Wales, with
>> limited liability, with registered number 04340834, and whose registered
>> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
>> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>>
>>
>>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MPLS admin groups implementation

[tim tiriche]

Hi,

I have an existing MPLS network of 3 regions

ASIA US and EUROPE

I don't want LSP's within US to be established via ASIA or EUROPE and vice
versa.

I want to create an admin group call it: GOLD and apply an exclude on all
US LSP's.

the problem is this will cause LSP to bounce.  since i have my config in
apply groups this change will affect all lsp's.  i want to know is this
traffic impacting if i have link protection in place?

is there a graceful way to do this?

second question, if i have a statement like this:

lsp a-b
admin-group exclude [gold silver]

does that mean, if an interface has either gold OR silver an LSP will not
choose the path or is it an AND?

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

Re: [j-nsp] MAC filter on EX switches

[Tim St. Pierre]

Thanks for all the help everyone.  I didn't know firewall filters could 
apply to layer 2.


It actually doesn't matter if it ends up in the bridge table, as long as 
it doesn't go out the other side.  There is only one MAC address we want 
to pass.  The topology is MX5 -> Procera -> Exchange fabric.
We would put an EX between the Procera and the Exchange and only allow 
the MAC from the MX5 to pass.


I have an EX2200 that I may be able to test this on before we try it on 
the production network.


-Tim

On 2015-12-09 05:20 PM, Eduardo Schoedler wrote:

If you do "show arp no-resolve", does it shows the mac-address?

--
Eduardo

2015-12-09 18:03 GMT-02:00 Aaron <aar...@gvtc.com>:

I’m not sure what you mean Eduardo.



I just typed that mac address into the firewall filter as a test.  I did not
test this to see if it would really stop traffic.



Aaron



From: Eduardo Schoedler [mailto:lis...@esds.com.br]
Sent: Wednesday, December 09, 2015 1:47 PM
To: Aaron


Cc: Juniper List
Subject: Re: [j-nsp] MAC filter on EX switches



Aaron,



in this example, can you confirm if the mac-address is not learned by the
switch?



Thanks.


Em quarta-feira, 9 de dezembro de 2015, Aaron <aar...@gvtc.com> escreveu:


I was unable to find an example in that web page and others I just tried to
look for online ... an example that would deny only one mac and allow all
others... which I believe is what Tim was looking to accomplish.  I just dug
into my notes and tried this... seems to make sense to me, BUT USE WITH
CAUTION please Tim, et al, as I haven't tested it and don't know the full
effects of it yet... plus I'm fairly new to the Junos world...so...

someone more experienced than me please let us know if there is a better way
to accomplish such a scenario.


Set mode...

set firewall family ethernet-switching filter deny-a-mac term term1 from
source-mac-address aa:bb:cc:dd:ee:ff/48
set firewall family ethernet-switching filter deny-a-mac term term1 then
discard
set firewall family ethernet-switching filter deny-a-mac term term2 then
accept

set interfaces ge-0/0/11 unit 0 family ethernet-switching filter input
deny-a-mac

-
Stanza mode, or whatever it's called...

gvtc@eng-lab-ex4550-1# show | compare
[edit interfaces]
+   ge-0/0/11 {
+   unit 0 {
+   family ethernet-switching {
+   filter {
+   input deny-a-mac;
+   }
+   }
+   }
+   }
[edit]
+  firewall {
+  family ethernet-switching {
+  filter deny-a-mac {
+  term term1 {
+  from {
+  source-mac-address {
+  aa:bb:cc:dd:ee:ff/48;
+  }
+  }
+  then discard;
+  }
+  term term2 {
+  then accept;
+  }
+  }
+  }
+  }

{master:0}[edit]
gvtc@eng-lab-ex4550-1# commit
configuration check succeeds
commit complete

{master:0}[edit]



Aaron


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Muhammad Atif Jauhar
Sent: Wednesday, December 09, 2015 9:55 AM
To: Tim St. Pierre
Cc: Juniper List
Subject: Re: [j-nsp] MAC filter on EX switches

Hi Tim,
Check bellow link may it help you.

https://www.juniper.net/techpubs/en_US/junos12.3/topics/example/port-securit
y-protect-from-snooping-database-attack.html#/

Regards,
Atif.
On Dec 9, 2015 6:43 PM, "Tim St. Pierre" <t...@communicatefreely.net> wrote:


Hello list,

Does anyone know if it's possible to configure an EX switch, such as
an EX
2200 to filter ingress based on MAC address?

It's important that the switch just drop disallowed MAC addresses, but
not shut down the port.  We have a network device that is sporadically
using the wrong mac address as the source, and when it goes into a
Cisco switch at a peering exchange, they shutdown our port for half an
hour because of the cisco MAC security.

We would like to put an EX in there to filter it while we figure out
what's causing it.

Thanks!


--
Tim St. Pierre
System Operator
Communicate Freely
www.communicatefreely.net
289-225-1220 x5101

___
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



--

Eduardo Schoedler







--
Tim St. Pierre
System Operator
Communicate Freely
www.communicatefreely.net
289-225-1220 x5101

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

[j-nsp] RR and VPN on PE L3VPN

[tim tiriche]

Hi,

I have the following:

PE1 router (VRF A and VRF B) - USA
PE2 router (VRFA, VRFB, VRFC, VRFD) - USA
I currently have full mesh iBGP between PE1 and PE2.

I am adding a PE3 in EUROPE and would like to have PE1 act as an RR for PE3.
I will add full mesh MPLS LSP for all PE's.

How will PE3 get VRFC and VRFD, since PE1 currently does not have VRFC and
VRFD in its bgp.l3vpn.0 table?

Is it true, i will loose all my BGP sessions if configure cluster-id on PE1?

http://www.juniper.net/documentation/en_US/junos13.3/topics/topic-map/bgp-sessions.html

Any advice would be appreciated.

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

[j-nsp] dynamic prefix list based on as-path .. is it possible?

[tim tiriche]

Hello,

Goal: on transit provider link, allow ASN XYZ to reach port 80 and drop all
other destined to port 80?


I don't want to build a static filter as ASN XYZ could have additional
updates.
Not sure if flowspec can match on as-path?

Any pointers would be helpful.

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

Re: [j-nsp] Juniper 10G Switch Options

[Tim Jackson]

I'd recommend QFX5100 or EX4600. Same hardware inside for both.

Beware that there are a few issues with DHCP and DHCPv6 pass through on
them, but that seems to be resolved now.
On Jun 4, 2015 6:22 AM, Colton Conor colton.co...@gmail.com wrote:

 We need a Juniper switch with at least 24 built in SFP+ ports. Looks like
 Juniper has a ton of options including the EX4500, EX4550, EX4600, and the
 QFX line which I don't know much about. This switch will be for aggregation
 purposes for an access network that has GPON OLT's with 10G uplinks on
 them. What do you recommend? Which has the latest hardware? Which is the
 most cost effective? Any limitations to be aware of?
 ___
 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] Juniper 10G Switch Options

[Tim Jackson]

It should support EVPN shortly.

On Thu, Jun 4, 2015, 6:38 AM Joe Freeman j...@netbyjoe.com wrote:

 Keep in mind the QFX5100 doesn't support evpn or vpls. To do vpls right
 now, we're having to l2vpn back to an MX tunnel interface and stitch into a
 bridge domain. It's not pretty but so far it has worked. We've got our
 fingers crossed that evpn is coming soon.

 Also, the 5100's apparently aren't using ASICs, or at least aren't using
 an ASIC on the interfaces that will support flexible-ethernet-services.
 What this means is that I can't L2 switch a customer on the same QFX
 interface that I'm either A) Terminating another customer at L3 (l3 vpn for
 example), or B) Doing a vlan-ccc/l2circuit/l2vpn connection on. This means
 there are some use cases (p2p ethernet circuits between olt's in the same
 CO for instance) that may require more than 1 port between the QFX and the
 olt.

 Joe

 On Thu, Jun 4, 2015 at 8:26 AM, Tim Jackson jackson@gmail.com wrote:

 I'd recommend QFX5100 or EX4600. Same hardware inside for both.

 Beware that there are a few issues with DHCP and DHCPv6 pass through on
 them, but that seems to be resolved now.
 On Jun 4, 2015 6:22 AM, Colton Conor colton.co...@gmail.com wrote:

  We need a Juniper switch with at least 24 built in SFP+ ports. Looks
 like
  Juniper has a ton of options including the EX4500, EX4550, EX4600, and
 the
  QFX line which I don't know much about. This switch will be for
 aggregation
  purposes for an access network that has GPON OLT's with 10G uplinks on
  them. What do you recommend? Which has the latest hardware? Which is the
  most cost effective? Any limitations to be aware of?
  ___
  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] Quick way to Shift MPLS traffic away from an interface

[tim tiriche]

Hello,

What is the quick way to shift LSP traffic from an interface after
increasing the igp metric?

question:

- What command can I use to find all lsp traversing the iface and a good
way to clear them? I am assuming I would need to run clear mpls
optimize-aggressive on the lsp's on that particular router only? Is my
understanding correct?

- Is it a good idea to turn on optimize-aggressive?

Any best practices or pointers would be appreciated!

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

[j-nsp] Fwd: Quick way to Shift MPLS traffic away from an interface

[tim tiriche]

Hello,

What is the quick way to shift LSP traffic from an interface after
increasing the igp metric?

question:

- What command can I use to find all lsp traversing the iface and a good
way to clear them? I am assuming I would need to run clear mpls
optimize-aggressive on the lsp's on that particular router only? Is my
understanding correct?

- Is it a good idea to turn on optimize-aggressive?

Any best practices or pointers would be appreciated!

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

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

[Raphael, Tim]

The support/downloads page is yet to be updated - that’s what I was pointing 
out.
I’m reliably informed that this should change shortly.

Tim Raphael







On 12/05/2015 4:38 pm, Euan Galloway euang+juniper-...@lists.eusahues.co.uk 
wrote:

On Tue, May 12, 2015 at 12:49:42AM +, Raphael, Tim wrote:
 MX80s are still showing 12.3R8.7 as the recommended.

On http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476 or
elsewhere?

(I'm liking that that KB says MX recommended version was changed 2
days before this thread started?)

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



Zetta Disclaimer: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this email by mistake and delete this email from your system. 
Computer viruses can be transmitted via email. The recipient should check this 
email and any attachments for the presence of viruses. ZettaServe Pty Ltd 
accepts no liability for any damage caused by any virus transmitted by this 
email.

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

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

[Raphael, Tim]

MX80s are still showing 12.3R8.7 as the recommended.


Tim Raphael







On 12/05/2015 8:40 am, Dale Shaw dale.shaw+j-...@gmail.com wrote:

Hi Colton,


On Tue, May 12, 2015 at 10:35 AM, Colton Conor colton.co...@gmail.com
wrote:

 So what is going to be the next recommended JTAC version after 12.3R8.7?

The recommended release for most MX platforms changed the other day, to
13.3R6.

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



Zetta Disclaimer: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this email by mistake and delete this email from your system. 
Computer viruses can be transmitted via email. The recipient should check this 
email and any attachments for the presence of viruses. ZettaServe Pty Ltd 
accepts no liability for any damage caused by any virus transmitted by this 
email.

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

[j-nsp] OAM LFM configuration

[tim tiriche]

Hi,

I want to run OAM LFM on a OSPF/MPLS backbone (p2p links) running BFD.

primary purpose:

* detection at l2
* if there are errors, shut down the link.
* if there is udld, shut down the link.

If anyone doing something similar and can share the configuration, it would
be helpful.
I am not sure on best practices on the threshold for error rate.

Does it make sense to run all of the following or would Ethernet oam be
good enough?

bfd on rsvp lsp and ospf and eth oam.

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

Re: [j-nsp] Stable JunOS for MX80

[Raphael, Tim]

11.4R12.4 seems pretty stable can also go 12.3R8.7 as well.

Tim Raphael






On 16/04/2015 3:09 pm, thiyagarajan b bn.thiyagara...@gmail.com wrote:

Hi All,

Request to suggest stable JunOS for MX 80 with 2GB DRAM and Flash.

Running internet service and MPLS majorly.

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



Zetta Disclaimer: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this email by mistake and delete this email from your system. 
Computer viruses can be transmitted via email. The recipient should check this 
email and any attachments for the presence of viruses. ZettaServe Pty Ltd 
accepts no liability for any damage caused by any virus transmitted by this 
email.

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

Re: [j-nsp] Arguments for commit scripts

[Tim Jackson]

Use an apply-macro..

--
Tim

On Wed, Mar 18, 2015 at 3:27 PM, Ross Vandegrift r...@kallisti.us wrote:
 Hi all,

 Working on a commit script with a regex that might need occasional updates.
 Ideally, this could be stored in the config, and loaded at run-time.
 Possible?

 If not: any catches with abusing annotate to provide this?

 Thanks,
 Ross

 ___
 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] Request for help: Firewall config to match fragmented ipv6 packet

[Tim Jackson]

... V6 fragments don't exist.
On Mar 14, 2015 7:36 PM, Vijesh Chandran vij...@juniper.net wrote:

 Hello,
   Is it possible to match a fragmented ipv6 traffic using juniper fw term?
 Please help if someone knows this.


 -Thanks,
  Vijesh

 ___
 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] draft-ietf-mpls-ldp-ipv6-16

[Tim Durack]

On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti s...@ytti.fi wrote:

 On (2015-02-19 11:06 -0500), Tim Durack wrote:

  What is the chance of getting working code this decade? I would quite
 like
  to play with this new fangled IPv6 widget...
 
  (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last
  piece for me.)

 Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to
 accept
 IPv6 next-hop in BGP LU, but probably does not work out-of-the-box?
 Isn't Segment Routing implementation day1 IPV4+IPV6 in XR?

 --
   ++ytti


I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that is
not all that is needed.

I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working
over IPv6.

IPv6 control plane this decade may yet be optimistic.

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

Re: [j-nsp] draft-ietf-mpls-ldp-ipv6-16

[Tim Durack]

On Fri, Feb 20, 2015 at 11:33 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk
 wrote:

  Of Tim Durack
  Sent: 20 February 2015 14:00
  IPv6 control plane this decade may yet be optimistic.
 

 And most importantly it's not actually needed it's just a whim of network
 operators.

 adam


 --
 This email has been scanned for email related threats and delivered safely
 by Mimecast.
 For more information please visit http://www.mimecast.com
 --


I don't consider unique addressing of infrastructure a whim.

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

[j-nsp] draft-ietf-mpls-ldp-ipv6-16

[Tim Durack]

I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015.

What is the chance of getting working code this decade? I would quite like
to play with this new fangled IPv6 widget...

(Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last
piece for me.)

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

Re: [j-nsp] Experience with QFX5100 13.2 14.1

[Tim Jackson]

For DHCPv4 that was the case, but it still persisted after disabling
dhcp-relay. For DHCPv6, ipv6 isn't even configured on the box.

--
Tim


On Fri, Jan 16, 2015 at 11:15 AM, Michael Loftis mlof...@wgops.com wrote:

 On Thu, Jan 15, 2015 at 6:43 AM, Tim Jackson jackson@gmail.com
 wrote:
  L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any
  traffic that would have been sent an ICMP redirect (even with that turned
  off) will be duplicated.. One copy forwarded through the RE, one copy
  through T2 caused by PR1022354 (there are other scenarios that can cause
  this, too.. and this is still unfixed).. I think in 13.x there is an LDP
  bug (PR889585), but it's easy to work around.
 
  L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25
  in L2 will be silently discarded (punted to the RE as you can see this
  traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe
  13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR
 for
  that one yet.

 Do you have DHCPv4 enabled in any other way?   Ex dhcp-relay?  I ask,
 b/c, on an unrelated platform (nd entirely different JunOS
 versions- MX960s and EX9214s) we ran into - turning on dhcp-relay will
 cause them to punt all UDP port 67 traffic.  Even if it's on an
 interface that isn't mentioned in the config.  I haven't had a chance
 yet to see if that happens to all logical instances or just the LI
 that the dhcp-relay or dhcp features are enabled on.  Like I said,
 unrelated platform, but, effectively the same thing.

 
  I've also had several QFX5100-96S boxes reboot without reason (on
 software
  all the way up to 14.1X53-D10), 0 logs, like they were powered off..
 Still
  haven't found the root cause of this one yet, we're suspecting a bad
 batch
  of hardware possibly.
 
  I have several that are about to enter a mixed L2+L3/MPLS P/PE role
 soon..
  MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there
  haven't been any issues outside of the previously mentioned L2 gotchas.
 
 
  In general the experience has been pretty positive with them outside of a
  few L2 snafus.. I'm also not using the boxes in a traditional DC role,
  these are all SP roles..
 
 
  On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann 
  richih.mailingl...@gmail.com wrote:
 
  Dear all,
 
  I was wondering what experience, if any, you have had with QFX5100.
 
  Of special interest would be what JunOS version you are running, what
  features you have enabled, and if you consider them production-ready.
 
 
  This question is open-ended on purpose.
 
 
  Thanks,
  Richard
  ___
  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



 --

 Genius might be described as a supreme capacity for getting its possessors
 into trouble of all kinds.
 -- Samuel Butler

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

Re: [j-nsp] Experience with QFX5100 13.2 14.1

[Tim Jackson]

On Thu, Jan 15, 2015 at 6:55 AM, Chuck Anderson c...@wpi.edu wrote:


 We are using 48S in production with 13.2X51-D20  D26, standalone and
 VC (not VCF), L2 features only (MSTP, RSTP).  TISSU worked great up to
 D20 (completely hitless), but I was told I couldn't use it for getting
 to D26 (it would fail or cause issues), so I didn't try.


I forgot to mention that we tried TISSU a couple of times with no success..
Evidently it had to do with CoS configuration according to JTAC, but it
wasn't something I bothered spending much time on.

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

Re: [j-nsp] Experience with QFX5100 13.2 14.1

[Tim Jackson]

L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any
traffic that would have been sent an ICMP redirect (even with that turned
off) will be duplicated.. One copy forwarded through the RE, one copy
through T2 caused by PR1022354 (there are other scenarios that can cause
this, too.. and this is still unfixed).. I think in 13.x there is an LDP
bug (PR889585), but it's easy to work around.

L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25
in L2 will be silently discarded (punted to the RE as you can see this
traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe
13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR for
that one yet.

I've also had several QFX5100-96S boxes reboot without reason (on software
all the way up to 14.1X53-D10), 0 logs, like they were powered off.. Still
haven't found the root cause of this one yet, we're suspecting a bad batch
of hardware possibly.

I have several that are about to enter a mixed L2+L3/MPLS P/PE role soon..
MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there
haven't been any issues outside of the previously mentioned L2 gotchas.


In general the experience has been pretty positive with them outside of a
few L2 snafus.. I'm also not using the boxes in a traditional DC role,
these are all SP roles..


On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann 
richih.mailingl...@gmail.com wrote:

 Dear all,

 I was wondering what experience, if any, you have had with QFX5100.

 Of special interest would be what JunOS version you are running, what
 features you have enabled, and if you consider them production-ready.


 This question is open-ended on purpose.


 Thanks,
 Richard
 ___
 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] juniper qfx5100 vs ex9200

[Tim Jackson]

QFX5100 has L2VPN (LDP based) now, and will get EVPN support..
On Dec 24, 2014 7:07 AM, Chuck Anderson c...@wpi.edu wrote:

 EX9200 has more potential to support more MPLS features as a PE, like
 EVPN.  QFX5100 is a nice box, but won't do much MPLS (L3VPN, but no
 L2VPN, VPLS or EVPN).  See the Feature Explorer:

 http://pathfinder.juniper.net/feature-explorer/search-features.html

 Interestingly, EX9200 isn't shown as having L3VPN support.  You need
 to take the Feature Explorer with a grain of salt.  If you look up
 BGP for L2VPNs and L3VPNs for example, it only shows PTX support for
 that feature, but of course MX supports that too.

 On Wed, Dec 24, 2014 at 03:55:30AM +, Randy Manning wrote:
  People,
 
  Any advice on a distribution layer switch for campus networks?  juniper
  qfx5100 vs ex9200?  I am not sure what the requirements need to be a
  priority.  The core is MX 960 and currently routing.  I am thinking about
  campus distro¹s becoming PE with TE and allowing the core¹s to label
  switch only?  Given the current network and possible change, which
  platform is the best?  Qfx or ex?
 
  Data centers are working well with q-fabric, but I understand that has
  been abandoned by juniperŠ. Which is sadŠ I liked the eVPN BGP NLRI
 design.
 
 
  Thanks,
  -
  Randy
 ___
 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] QFX5100 question

[Tim Jackson]

To be honest, I'd run them as a P instead and use the MX as your PE.
For large L2 flows over MPLS there's no support or plans (or maybe
even the ability afaik) to support any sorts of FAT-PW or entropy
label for the box. As an LSR they work great.

There are some issues in the current 14.1 code with any traffic that
*might* get an ICMP redirect (even if no-redirects is turned on) that
causes some awesome behavior (such as duplicate packets where one gets
forwarded by the RE, and another by the BCM asic).. Outside of that
and a couple of other issues 14.x has been fine so far on it.

--
Tim

On Thu, Dec 18, 2014 at 4:07 PM, Joe Freeman j...@netbyjoe.com wrote:
 Before we go out and spend a large amount of money to replace some gear
 we're not happy with in our network, I thought I'd check to see what
 opinions I could get on the QFX5100.

 We are looking at using them in an MPLS PE role, with the new code release
 that has added support for L2VPN's (according to our SE). Each of these
 5100's would be connected to at least one MX router (preferably two for
 redundancy) via one or more 10Ge LAG groups. Our CO's are too far apart for
 40Gbe at the moment.

 Any thoughts or opinions would be helpful.

 Thanks-
 Joe
 ___
 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] Cooling Pads for Juniper SRX?

[Tim St. Pierre]

If you are running these outdoors in racks with solar gain and 36 degree
ambient, then you really need to look at cooling your racks properly.

These devices don't have the wide temperature range that something like
an ACX does, so you may want to look into some system for cooling the racks.

There are lots of good heat exchanger cooling systems for outdoor
cabinets.  You can also get some nice AC units that mount in the door. 
Dantherm makes a nice 48v air conditioner for small enclosures.

Failing that, the suggestion below to add some fans is probably the best
one.  That, and try to maintain some space between them.

On 14-12-02 12:21 AM, joel jaeggli wrote:
 On 12/1/14 8:26 PM, Skeeve Stevens wrote:
 Hi all,

 I have an issue with some Juniper SRX100's overheating.  I've seen them get
 hot before, especially placed on something similar (i.e. another SRX100)...
 and given warnings of overheating, but never shut down but this
 situation is different.

 These SRX100's are shutting down as they are reaching a core temperature of
 70c as they are located in racks that are outside in the sun and on
 particularly hot days - around 32c-36c they overheat and turn themselves
 off.
 It's a fanless enclosure, if it's in a pedestal or some kind on
 enclosure, you could run it with the top off.

 Some might say this is understandable... and I sort of agree.  Although
 their operating system says they are good to 40c, that doesn't really seem
 to be the case.  The SRX110's are a little more tolerant given they are
 bigger units - but have the same operating environmentals (along with the
 EX2200-C).  But at the moment I have the SRX100's and would prefer not to
 swap them out as it will cost significantly.

 Then one of my staff had (what I think) a good idea today... to use cooling
 pads... maybe like the ones you use for laptops or something.
 there exist a variety of rack or panel mount fans...

 http://www.rackmountmart.com/html/fS.htm

 there was a while where I'd recycle the fan trays from total-control
 chassis to exhaust air out the tops of cabinets. but that was 15 years ago.

 So I am wondering if anyone has been some solid - not $20 junk or such..
 but something that runs off mains, and works well 24x7x365 - maybe even
 something that only kicks in once a certain temperature has been reached.

 I thought if anywhere, a couple of these mailing lists might have had some
 experience with these kinds of things - especially for those who have built
 regional pops and have had to cool some equipment.

 Thanks all!

 ...Skeeve

 *Skeeve Stevens - *eintellego Networks Pty Ltd
 ske...@eintellegonetworks.com ; www.eintellegonetworks.com

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

 facebook.com/eintellegonetworks ;  http://twitter.com/networkceoau
 linkedin.com/in/skeeve

 twitter.com/theispguy ; blog: www.theispguy.com


 The Experts Who The Experts Call
 Juniper - Cisco - 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


-- 
--
Tim St. Pierre
System Operator
Communicate Freely
289 225 1220 x5101
t...@communicatefreely.net
www.communicatefreely.net

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

Re: [j-nsp] EX2200 rate limiting/shaping question

[Tim Jackson]

filter-specific means that if you apply multiple terms in the firewall
filter with an action of policer that it aggregates across all of
those in that filter.

term-specific means each term gets its own rate in that filter.

To do what you're after you just do a interface-specific firewall
filter which should cause it to use different counters/policers per
interface that it is applied to.

--
Tim



On Tue, Nov 25, 2014 at 11:10 AM, joe mcguckin j...@via.net wrote:
 Can someone explain the difference between filter-specific and term-specific? 
 I want to create a filter for rate limiting and apply it to multiple  
 physical ports and have each interface
 rate limited independently, not as an aggregate.

 Thanks,

 Joe



 ___
 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] DHCPv6 relay on an M10i

[Tim St. Pierre]

Does anyone have DHCPv6 relay working on an M10i?

I have a number of GPON customers attached to a ge interface via a layer
2 access network.  I want to be able to provide the customer routers
with an IP address, DNS servers, and a delegated prefix that will be
added to the route table as an access route.

V4 DHCP relay works just great, but I can't seem to get it to work with
v6 using more or less the same configuration.  Does anyone else have
this working?

Thanks!

-Tim

-- 
--
Tim St. Pierre
System Operator
Communicate Freely
289 225 1220 x5101
t...@communicatefreely.net
www.communicatefreely.net

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

Re: [j-nsp] ACX is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Tim Jackson]

Speaking of RRs, has anyone actually looked at:

http://www.metaswitch.com/products/networking/virtual-route-reflector

?


On Thu, Nov 13, 2014 at 10:02 AM, Daniel Verlouw dan...@shunoshu.net wrote:
 Hej Mark,

 On Thu, Nov 13, 2014 at 5:10 PM, Mark Tinka mark.ti...@seacom.mu wrote:
 I'd deploy vMX as a route reflector. I was actually
 evaluating vRR a few months ago, but it still had a long way
 to go, so went with Cisco's CSR1000v (which is, basically,
 IOS XE) instead.

 would you be able to elaborate on your experience with vRR ? We’re
 about to re-evaluate our RR deployment and going ‘virtual / PC-based’
 is certainly high on our list. Too bad there's hardly any info on vRR
 around, or I'm looking in the wrong place (which is not terribly hard
 after yet another poor redesign of jnpr.net)

 Other than being used as RR, I (so far) fail to see how vMX would be
 deployed in carrier networks such as ours. Virtualized DCs, yes,
 maybe, but that’s whole different ball game.

 BR, Daniel.

 ___
 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] EX3300/4300 Switch MPLS CCC Support

[Tim Jackson]

Licenses for stupid SW features are total BS, here's to hoping that Juniper
figures this out. Probably not though.

If I missed that, sorry..

From what I know, MPLS on new EX is unlikely to happen (even though I
really really really want it). ACX is where MPLS on Broadcom based products
is going to happen (outside of the generous MPLS featureset available on
QFX today).

--
Tim

On Fri, Nov 7, 2014 at 10:44 PM, Skeeve Stevens 
skeeve+juniper...@eintellegonetworks.com wrote:

 I was referring to OSPF, IPv6, etc.. basic features

 and the fact you need an EFL and AFL now is just rude.


 ...Skeeve

 *Skeeve Stevens - *eintellego Networks Pty Ltd
 ske...@eintellegonetworks.com ; www.eintellegonetworks.com

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

 facebook.com/eintellegonetworks ;  http://twitter.com/networkceoau
 linkedin.com/in/skeeve

 twitter.com/theispguy ; blog: www.theispguy.com


 The Experts Who The Experts Call
 Juniper - Cisco - Cloud - Consulting - IPv4 Brokering

 On 8 November 2014 15:35, Tim Jackson jackson@gmail.com wrote:

 Is MPLS CCC really a basic feature?

 What other enterprise switch can do L2 over MPLS?

 I'd imagine that EX4300 is capable of it (and more) that it can do it,
 but why waste the effort making l2circuit work on Broadcom DC/EX
 chips? It wasn't promised in the switches datasheets, was it?

 Push for cash?

 Basic features?

 You got shit for free now you expect it. I agree that shit should just
 appear from my vendors magically for free at prices cheaper than their
 competitors, but I also live in the real world where reality and my
 dreams aren't the same thing..

 Then again, I'm also just an angry man waiting on his plane in an
 airport...

 --
 Tim

 On Fri, Nov 7, 2014 at 10:22 PM, Skeeve Stevens
 skeeve+juniper...@eintellegonetworks.com wrote:
  I agree... it is quite rude and seems to be just a push for cash
  considering what basic features these are.
 
 
  ...Skeeve
 
  *Skeeve Stevens - *eintellego Networks Pty Ltd
  ske...@eintellegonetworks.com ; www.eintellegonetworks.com
 
  Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
 
  facebook.com/eintellegonetworks ;  http://twitter.com/networkceoau
  linkedin.com/in/skeeve
 
  twitter.com/theispguy ; blog: www.theispguy.com
 
 
  The Experts Who The Experts Call
  Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
 
  On 8 November 2014 12:26, Robin Williams robin.willi...@tnp.net.uk
 wrote:
 
  Hi all,
 
  We currently make some use of the MPLS CCC functionality of EX3200 and
  EX4200 switches with the AFL, but note that their replacements EX3300
 and
  EX4300 don't have any MPLS support.  Does anyone know if this is a
  temporary lack of support while the box is being developed further, or
 is
  there no plans no bring this support back in the new products?  I don't
  like the way the EX3300 is being touted as the replacement for the
 EX3200
  but the feature set has entirely changed.
 
  I also think it's a bit rich that you now need an EFL license for
 things
  like OSPF support, where you didn't previously, and for the AFL
 features
  such as BGP, you now need both an EFL *AND* and AFL where you
 previously
  only needed an AFL.
 
  Would be interested to hear other opinions on this, to me it all seems
  like a bit of a silly move on the part of Juniper and a gift to Cisco.
 
  Regards,
  Robin.
  ___
  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