Re: [j-nsp] MX480 filter options?

[Eric Van Tol]

I unicasted Matt, but for anyone else looking for the same:


https://store.filtrationgroup.com/UAF/electronics-cooling-air-filters-by-manufacturer-juniper

  -evt 

On 10/27/20, 9:00 AM, "juniper-nsp on behalf of Matthew Crocker" 
 
wrote:


I’d like to do some PM on my MX480s and replace the filter,   
FLTR-KIT-MX480-S is $1,000 for a piece of foam and some stamped sheet metal.   
Does anyone have any alternatives?

-Matt

___
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] MX480 filter options?

[Doug McIntyre]

On Tue, Oct 27, 2020 at 12:58:07PM +, Matthew Crocker wrote:
> I’d like to do some PM on my MX480s and replace the filter,   
> FLTR-KIT-MX480-S is $1,000 for a piece of foam and some stamped sheet metal.  
>  Does anyone have any alternatives?


We thought that was absurd as well with Cisco...  Our solution was
just to get a roll of the same kind of filter material from Grainger
for like $40-$50, and we are set for life on filter replacements.
I suppose now-a-days you can find plenty on Amazon, but we could just
compare at Grainger with sample in hand to find the same. 

Its not like they innovated with special materials to filter out the
datacenter dust :-)

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

[j-nsp] MX480 filter options?

[Matthew Crocker]

I’d like to do some PM on my MX480s and replace the filter,   FLTR-KIT-MX480-S 
is $1,000 for a piece of foam and some stamped sheet metal.   Does anyone have 
any alternatives?

-Matt

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

Re: [j-nsp] MX480 / RE-S-2000-4096

[Saku Ytti]

The main problem you might run into, is the fact that DPCE has backup
only fabric connection, MPC not. So whole DPCE 40G is sending to
single egress Trio, in MX960 istead of getting 40Gbps, you'll get
26Gbps, unless you turn on redundancy mode, forcing MPC to make one
plane cold backup.

Complex setups require complex understanding and high OPEX.

On Thu, 7 Nov 2019 at 13:46, Mark Tinka  wrote:
>
>
>
> On 6/Nov/19 19:05, Misak Khachatryan wrote:
> > Hi,
> >
> > We do that with RE-S-1300 and DPCE 4x 10GE R sort of cards. No problems for 
> > a 4 or more years. And IPv6 full tables too.
>
> That's easy.
>
> Ask it to do QoS bits, policing bits, firewall bits, SCU/DCU bits, and
> it'll show you its true colors :-).
>
> Mark.
> ___
> 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] MX480 / RE-S-2000-4096

[Mark Tinka]

On 6/Nov/19 19:05, Misak Khachatryan wrote:
> Hi,
>
> We do that with RE-S-1300 and DPCE 4x 10GE R sort of cards. No problems for a 
> 4 or more years. And IPv6 full tables too.

That's easy.

Ask it to do QoS bits, policing bits, firewall bits, SCU/DCU bits, and
it'll show you its true colors :-).

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

Re: [j-nsp] MX480 / RE-S-2000-4096

[Misak Khachatryan]

Hi,

We do that with RE-S-1300 and DPCE 4x 10GE R sort of cards. No problems for a 4 
or more years. And IPv6 full tables too.


Best regards,
Misak Khachatryan,
Network Administration and
Monitoring Department Manager,

GNC- ALFA CJSC
1 Khaghaghutyan str., Abovyan, 2201 Armenia
Tel: +374 60 46 99 70 (9670),
Mob.: +374 55 19 98 40
URL:www.rtarmenia.am


On Fri, Nov 1, 2019 at 8:50 PM Dario Amaya 
mailto:darioamay...@gmail.com>> wrote:
Hello

We have the following hardware and we are looking to use this chassis
as an edge router, terminating 2x full table IP transit and some IXP
peering.

MX480
2x RE-S-2000-4096-S
2x SCB-MX960-S
1x MPC-3D-16XGE-SFPP
1x DPCE-R-20GE-2XGE

Is anybody here running these routing-engines in a similar role? How
is the CPU on them / convergence times? Hopefully not as bad as an
MX80...

Also - I know the RE's are EOL, but does anybody know if they will run
JUNOS later than 16.2?

Kind regards
___
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] MX480 / RE-S-2000-4096

[Theo Voss]

Hi Dario,

furthermore, 4 GB RAM is not much nowadays. I’d recommend looking for some 
1800x4’s or -X6’s.

Best regards,
Theo Voss

Von: juniper-nsp  im Auftrag von Mark 
Tinka 
Datum: Freitag, 1. November 2019 um 20:06
An: "juniper-nsp@puck.nether.net" 
Betreff: Re: [j-nsp] MX480 / RE-S-2000-4096



On 1/Nov/19 18:49, Dario Amaya wrote:


Also - I know the RE's are EOL, but does anybody know if they will run
JUNOS later than 16.2?

You're probably more likely to run into a whole host of issues with he
DPC's.

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

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

Re: [j-nsp] MX480 / RE-S-2000-4096

[Mark Tinka]

On 1/Nov/19 18:49, Dario Amaya wrote:

>
> Also - I know the RE's are EOL, but does anybody know if they will run
> JUNOS later than 16.2?

You're probably more likely to run into a whole host of issues with he
DPC's.

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

[j-nsp] MX480 / RE-S-2000-4096

[Dario Amaya]

Hello

We have the following hardware and we are looking to use this chassis
as an edge router, terminating 2x full table IP transit and some IXP
peering.

MX480
2x RE-S-2000-4096-S
2x SCB-MX960-S
1x MPC-3D-16XGE-SFPP
1x DPCE-R-20GE-2XGE

Is anybody here running these routing-engines in a similar role? How
is the CPU on them / convergence times? Hopefully not as bad as an
MX80...

Also - I know the RE's are EOL, but does anybody know if they will run
JUNOS later than 16.2?

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

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

[Scott Harvanek]

show ipsec security-associations
Security association: tusldc2-distribution
    Direction SPI AUX-SPI Mode   Type Protocol
    inbound   256 0   transport  manual AH
    outbound  256 0   transport  manual   AH

Junos: 16.1R4-S2.2

Scott H.
Login, LLC

On 6/16/19 11:20 AM, Scott Harvanek wrote:

I’ll get those outputs when at a terminal but the configuration did not change 
and this was working pre reboot :/

The only other change was a failed MPC that was replaced.

Downstream devices are sending HELLOs but this 480 is not indicating it’s 
receiving them via ospf3 stats output which is weird but connectivity is good.

-Scott H


On Jun 16, 2019, at 2:08 AM, Anderson, Charles R  wrote:

Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
and "security ipsec security-association FOO..."?

What does "show ipsec security-associations" show?

What Junos version?  There was a memory leak or file descriptor leak
in older Junos that killed the ipsec daemon after a long uptime, but I
don't recall anything that would cause it to fail right after reboot.
But you can try "restart ipsec-key-management" anyway.


On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
Hey guys,

Getting something interesting after a reboot;

Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't
dereference the sa name = XX

When trying to bring up the IPSec tunnel for ospf3 peering ( which never
establishes ), any ideas what this means? Do I need to restart the ipsec
key daemon?

___
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] MX480 ospf3 ipsec jammed?

[Scott Harvanek]

I’ll get those outputs when at a terminal but the configuration did not change 
and this was working pre reboot :/

The only other change was a failed MPC that was replaced.

Downstream devices are sending HELLOs but this 480 is not indicating it’s 
receiving them via ospf3 stats output which is weird but connectivity is good.

-Scott H

> On Jun 16, 2019, at 2:08 AM, Anderson, Charles R  wrote:
> 
> Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
> and "security ipsec security-association FOO..."?
> 
> What does "show ipsec security-associations" show?
> 
> What Junos version?  There was a memory leak or file descriptor leak
> in older Junos that killed the ipsec daemon after a long uptime, but I
> don't recall anything that would cause it to fail right after reboot.
> But you can try "restart ipsec-key-management" anyway.
> 
>> On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
>> Hey guys,
>> 
>> Getting something interesting after a reboot;
>> 
>> Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't 
>> dereference the sa name = XX
>> 
>> When trying to bring up the IPSec tunnel for ospf3 peering ( which never 
>> establishes ), any ideas what this means? Do I need to restart the ipsec 
>> key daemon?

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

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

[Anderson, Charles R]

Silly question, does the sa name match between "ospf3...ipsec-sa FOO"
and "security ipsec security-association FOO..."?

What does "show ipsec security-associations" show?

What Junos version?  There was a memory leak or file descriptor leak
in older Junos that killed the ipsec daemon after a long uptime, but I
don't recall anything that would cause it to fail right after reboot.
But you can try "restart ipsec-key-management" anyway.

On Sat, Jun 15, 2019 at 09:02:30PM -0500, Scott Harvanek wrote:
> Hey guys,
> 
> Getting something interesting after a reboot;
> 
> Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't 
> dereference the sa name = XX
> 
> When trying to bring up the IPSec tunnel for ospf3 peering ( which never 
> establishes ), any ideas what this means? Do I need to restart the ipsec 
> key daemon?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX480 ospf3 ipsec jammed?

[Scott Harvanek]

Hey guys,

Getting something interesting after a reboot;

Jun 16 01:58:45  MX480.1 kernel: ipsec_find_sa_in_so_gen(1999): Couldn't 
dereference the sa name = XX


When trying to bring up the IPSec tunnel for ospf3 peering ( which never 
establishes ), any ideas what this means? Do I need to restart the ipsec 
key daemon?


--
Scott H.

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

Re: [j-nsp] MX480 AC Power Supply fan replacement problem?

[Jonas Frey]

Chris,

the -F00 have a tachometer signal, so the device using it can read the
RPM easily.
The -R00 utilize a locking signal which only tells the device if the
rotor does spin freely or is locked (in which case the device can shut
down power to the fan to prevent any issues).

As you would imagine these are not interchangable as the device
configured to use them would not know about the different signal.

-JonasAm Freitag, den 14.12.2018, 15:34 -0800 schrieb Chris Cappuccio:
> Kevin Wormington [kw...@missouri-telecom.com] wrote:
> > 
> > Are the replacement fans the -R00 model of FFB0412SHN?
> > 
> > I recently replaced the fans in two MX480 supplies and they worked
> > fine and the alarms cleared.
> > 
> Oh crap. I have the -F00 versions. I'm having a hard time finding the
> difference 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] MX480 AC Power Supply fan replacement problem?

[Chris Cappuccio]

Kevin Wormington [kw...@missouri-telecom.com] wrote:
> Are the replacement fans the -R00 model of FFB0412SHN?
> 
> I recently replaced the fans in two MX480 supplies and they worked fine and 
> the alarms cleared.
> 

Oh crap. I have the -F00 versions. I'm having a hard time finding the 
difference between them.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX480 AC Power Supply fan replacement problem?

[Chris Cappuccio]

So, I had four MX 480 AC power supplies, across two totally different and
unrelated routers, all four of them have fan failures reported by JunOS.
These fans failed within a span of 6 months.

The old fans are definitely bad. On any given power supply, one of the
two fans are seized. Maybe both. So, the diagnosis given by JunOS appears
to be correct. I ordered Delta Electronics FFB0412SHN, the exact fan that
failed. I guess.

The new fan wires are neatly soldered in place. The connections are tight.
When the power supplies are re-installed, the new fans spin continuously. So,
you would think, we are ok? But, JunOS still detects fan failure, and the
alarm light on the front of the router goes on. 

Is there something that can be reset in the power supply? Or perhaps the
sensor wire is sending a different signal? Any ideas?

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

Re: [j-nsp] MX480

[Saku Ytti]

On Tue, 19 Jun 2018 at 18:03, Saku Ytti  wrote:

>from {
> source-prefix-list {
> rsvp_neighbors;
> }
> protocol udp;
> destination-port 8503;
> }
>

Oh, I need to add one important thing. RFC mandates that SPORT is
ephemeral, but JNPR uses 8503 (against RFC). If you're like me, you
build strict lo0 filters as strict as RFC allows, and in this case it
would not work, as 'source-port ' would not match the
incoming packet.

I think JNPR implementation is better than RFC, and I'd like errata
happen on the RFC. 8503<->8503 is more desirable than
ephemeral<->8503. But you should be defensive and accept at least
ephemeral + 8503 as source port, so that it doesn't break if JNPR
implementation starts to follow RFC. Usually there are no security
implications omitting source-port match (but never omit
destination-port match, even source is strictly known).

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

Re: [j-nsp] MX480

[Saku Ytti]

Hey Andrew,

We largely do not use any in-device tooling for configuration generation,
as that creates vendor dependencies we try to add sparingly. All data is
formal data in SQL and we turn this formal data into informal router
configuration via templates.
We consider router configurations immutable, we never change
configurations, we only reassign it. Not unlike in purely functional
programming.


On Wed, 20 Jun 2018 at 06:44, Andrew Thrift 
wrote:

> Hi Saku,
>
> I was just wondering how you are populating:
>
> source-prefix-list {
> rsvp_neighbors;
> }
>
> Manually, or via an apply-path ?
>
>
> Regards,
>
>
>
>
> Andrew
>
> On Wed, Jun 20, 2018 at 1:03 AM, Saku Ytti  wrote:
>
>> Hey Rei,
>>
>> Great catch.
>>
>> We have this:
>> term rsvp:self_ping {
>> from {
>> source-prefix-list {
>> rsvp_neighbors;
>> }
>> protocol udp;
>> destination-port 8503;
>> }
>> then {
>> count rsvp:self_ping;
>> accept;
>> }
>> }
>>
>>
>> This is really great feature, because previously make-before-break was
>> based on timer, with no idea if actually new LSP has been established or
>> if
>> old LSP is no longer used. So it could very easily lead to situation where
>> you push traffic to new LSP which isn't working or remove old LSP still
>> being used.
>>
>> self_ping removes the problem of pushing traffic to LSP which is not up
>> yet
>> and 'optimize-adaptive-teardown' removed problem of removing LSP still
>> being used. Making both sides triggered instead of arbitrary timer.
>>
>>
>>
>>
>> On Tue, 19 Jun 2018 at 17:56, Rei Alexandra Aoyama <
>> rei.a.aoy...@gmail.com>
>> wrote:
>>
>> > Hi Ian,
>> >
>> > 16.1R7 or 17.3R3 should be good. If you use MPLS RSVP, make sure you
>> look
>> > up MPLS self-ping which is a new feature in 16.1 - especially if you
>> have
>> > lo0 firewall. Otherwise you will have issue with LSP switchover. I think
>> > there is a PSN on that. I will look it up.
>> >
>> > ReiA
>> >
>> > On Sat, Jun 16, 2018 at 4:34 AM Ian Goodall  wrote:
>> >
>> > > Hi All
>> > >
>> > > Were looking to upgrade JUNOS on some of our older PE MX480/960
>> running
>> > pre
>> > > 15 code. We've had success on the 17.x train in P roles.
>> > >
>> > > 15.1 is recommended by JTAC but it's EOL in under 12 months.
>> > >
>> > > Historically picking a recent version with a high R release was
>> always a
>> > > good starting point. The release strategy has changed somewhat and
>> most
>> > > versions now don't go beyond R2.
>> > >
>> > > What's everyone deploying currently?
>> > >
>> > > Thanks
>> > >
>> > > IG
>> > > ___
>> > > 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
>>
>
>

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

Re: [j-nsp] MX480

[Andrew Thrift]

Hi Saku,

I was just wondering how you are populating:

source-prefix-list {
rsvp_neighbors;
}

Manually, or via an apply-path ?


Regards,




Andrew

On Wed, Jun 20, 2018 at 1:03 AM, Saku Ytti  wrote:

> Hey Rei,
>
> Great catch.
>
> We have this:
> term rsvp:self_ping {
> from {
> source-prefix-list {
> rsvp_neighbors;
> }
> protocol udp;
> destination-port 8503;
> }
> then {
> count rsvp:self_ping;
> accept;
> }
> }
>
>
> This is really great feature, because previously make-before-break was
> based on timer, with no idea if actually new LSP has been established or if
> old LSP is no longer used. So it could very easily lead to situation where
> you push traffic to new LSP which isn't working or remove old LSP still
> being used.
>
> self_ping removes the problem of pushing traffic to LSP which is not up yet
> and 'optimize-adaptive-teardown' removed problem of removing LSP still
> being used. Making both sides triggered instead of arbitrary timer.
>
>
>
>
> On Tue, 19 Jun 2018 at 17:56, Rei Alexandra Aoyama  >
> wrote:
>
> > Hi Ian,
> >
> > 16.1R7 or 17.3R3 should be good. If you use MPLS RSVP, make sure you look
> > up MPLS self-ping which is a new feature in 16.1 - especially if you have
> > lo0 firewall. Otherwise you will have issue with LSP switchover. I think
> > there is a PSN on that. I will look it up.
> >
> > ReiA
> >
> > On Sat, Jun 16, 2018 at 4:34 AM Ian Goodall  wrote:
> >
> > > Hi All
> > >
> > > Were looking to upgrade JUNOS on some of our older PE MX480/960 running
> > pre
> > > 15 code. We've had success on the 17.x train in P roles.
> > >
> > > 15.1 is recommended by JTAC but it's EOL in under 12 months.
> > >
> > > Historically picking a recent version with a high R release was always
> a
> > > good starting point. The release strategy has changed somewhat and most
> > > versions now don't go beyond R2.
> > >
> > > What's everyone deploying currently?
> > >
> > > Thanks
> > >
> > > IG
> > > ___
> > > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[Aaron Gould]

I'm running 17.4R1-S2.2 on MX960's with dual MPC7E-MRATE's in slot 0 and
11... and in some 960's, also MS-MPC-128G

-Aaron


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

Re: [j-nsp] MX480

[craig washington]

Yea I am able to download it now but don't see any release notes yet..



From: juniper-nsp  on behalf of Sebastian 
Wiesinger 
Sent: Monday, June 18, 2018 2:33 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX480

* Vincent Bernat  [2018-06-17 12:17]:
>  ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :
>
> > 16.1R7 is a golden release.
>
> Is it already released? Not listed here:
>  https://www.juniper.net/support/downloads/?p=mx480#sw
Download Software - Support - Juniper 
Networks<https://www.juniper.net/support/downloads/?p=mx480#sw>
www.juniper.net
Juniper Software Downloads. It is important to keep your products registered 
and your install base updated.



It's released now, backdated to the 15th, probably the build date.

Regards

Sebastian

--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
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] MX480

[Saku Ytti]

Hey Rei,

Great catch.

We have this:
term rsvp:self_ping {
from {
source-prefix-list {
rsvp_neighbors;
}
protocol udp;
destination-port 8503;
}
then {
count rsvp:self_ping;
accept;
}
}


This is really great feature, because previously make-before-break was
based on timer, with no idea if actually new LSP has been established or if
old LSP is no longer used. So it could very easily lead to situation where
you push traffic to new LSP which isn't working or remove old LSP still
being used.

self_ping removes the problem of pushing traffic to LSP which is not up yet
and 'optimize-adaptive-teardown' removed problem of removing LSP still
being used. Making both sides triggered instead of arbitrary timer.




On Tue, 19 Jun 2018 at 17:56, Rei Alexandra Aoyama 
wrote:

> Hi Ian,
>
> 16.1R7 or 17.3R3 should be good. If you use MPLS RSVP, make sure you look
> up MPLS self-ping which is a new feature in 16.1 - especially if you have
> lo0 firewall. Otherwise you will have issue with LSP switchover. I think
> there is a PSN on that. I will look it up.
>
> ReiA
>
> On Sat, Jun 16, 2018 at 4:34 AM Ian Goodall  wrote:
>
> > Hi All
> >
> > Were looking to upgrade JUNOS on some of our older PE MX480/960 running
> pre
> > 15 code. We've had success on the 17.x train in P roles.
> >
> > 15.1 is recommended by JTAC but it's EOL in under 12 months.
> >
> > Historically picking a recent version with a high R release was always a
> > good starting point. The release strategy has changed somewhat and most
> > versions now don't go beyond R2.
> >
> > What's everyone deploying currently?
> >
> > Thanks
> >
> > IG
> > ___
> > 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] MX480

[Rei Alexandra Aoyama]

Hi Ian,

16.1R7 or 17.3R3 should be good. If you use MPLS RSVP, make sure you look
up MPLS self-ping which is a new feature in 16.1 - especially if you have
lo0 firewall. Otherwise you will have issue with LSP switchover. I think
there is a PSN on that. I will look it up.

ReiA

On Sat, Jun 16, 2018 at 4:34 AM Ian Goodall  wrote:

> Hi All
>
> Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre
> 15 code. We've had success on the 17.x train in P roles.
>
> 15.1 is recommended by JTAC but it's EOL in under 12 months.
>
> Historically picking a recent version with a high R release was always a
> good starting point. The release strategy has changed somewhat and most
> versions now don't go beyond R2.
>
> What's everyone deploying currently?
>
> Thanks
>
> IG
> ___
> 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] MX480

[Sebastian Becker]

Right, got the message just some minutes ago:

JUNOS 16.1R7.7 has deployed

https://www.juniper.net/techpubs/en_US/junos16.1/information-products/topic-collections/release-notes/16.1/index.html

— 
Sebastian Becker


> Am 18.06.2018 um 16:33 schrieb Sebastian Wiesinger :
> 
> * Vincent Bernat  [2018-06-17 12:17]:
>> ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :
>> 
>>> 16.1R7 is a golden release.
>> 
>> Is it already released? Not listed here:
>> https://www.juniper.net/support/downloads/?p=mx480#sw
> 
> It's released now, backdated to the 15th, probably the build date.
> 
> Regards
> 
> Sebastian
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
>-- Terry Pratchett, The Fifth Elephant
> ___
> 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] MX480

[Sebastian Wiesinger]

* Vincent Bernat  [2018-06-17 12:17]:
>  ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :
> 
> > 16.1R7 is a golden release.
> 
> Is it already released? Not listed here:
>  https://www.juniper.net/support/downloads/?p=mx480#sw

It's released now, backdated to the 15th, probably the build date.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[Nitzan Tzelniker]

AFAIK from few JTAC cases both 16.1R7 and 17.3R3 should be out in the end
of this month or sometime next month
but as always it could be changed

Nitzan

On Mon, Jun 18, 2018 at 9:36 AM Sebastian Becker  wrote:

> The ETA for GA was 31-MAY-2018. So hopefully only a matter of days.
>
> —
> Sebastian Becker
>
> > Am 17.06.2018 um 23:11 schrieb craig washington <
> craigwashingto...@hotmail.com>:
> >
> > It's not released yet as far as I know.
> > I  know it was supposed to be at least per our SE at Juniper.
> > Hopefully will have some sort of update this week unless anyone else
> knows something.
> >
> >
> > From: juniper-nsp  juniper-nsp-boun...@puck.nether.net>> on behalf of Vincent Bernat <
> ber...@luffy.cx <mailto:ber...@luffy.cx>>
> > Sent: Sunday, June 17, 2018 10:17 AM
> > To: Sebastian Becker
> > Cc: juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>
> > Subject: Re: [j-nsp] MX480
> >
> > ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  s...@lab.dtag.de>> :
> >
> > > 16.1R7 is a golden release.
> >
> > Is it already released? Not listed here:
> >  https://www.juniper.net/support/downloads/?p=mx480#sw <
> https://www.juniper.net/support/downloads/?p=mx480#sw>
> > Download Software - Support - Juniper Networks <
> https://www.juniper.net/support/downloads/?p=mx480#sw>
> > www.juniper.net <http://www.juniper.net/>
> > Juniper Software Downloads. It is important to keep your products
> registered and your install base updated.
> >
> >
> > Is 16.1R6-S4 considered almost equivalent?
> > --
> > The fashion wears out more apparel than the man.
> > -- William Shakespeare, "Much Ado About Nothing"
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/juniper-nsp <
> 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] MX480

[Sebastian Becker]

The ETA for GA was 31-MAY-2018. So hopefully only a matter of days.

— 
Sebastian Becker

> Am 17.06.2018 um 23:11 schrieb craig washington 
> :
> 
> It's not released yet as far as I know.
> I  know it was supposed to be at least per our SE at Juniper.
> Hopefully will have some sort of update this week unless anyone else knows 
> something.
> 
> 
> From: juniper-nsp  <mailto:juniper-nsp-boun...@puck.nether.net>> on behalf of Vincent Bernat 
> mailto:ber...@luffy.cx>>
> Sent: Sunday, June 17, 2018 10:17 AM
> To: Sebastian Becker
> Cc: juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] MX480
>  
> ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  <mailto:s...@lab.dtag.de>> :
> 
> > 16.1R7 is a golden release.
> 
> Is it already released? Not listed here:
>  https://www.juniper.net/support/downloads/?p=mx480#sw 
> <https://www.juniper.net/support/downloads/?p=mx480#sw>
> Download Software - Support - Juniper Networks 
> <https://www.juniper.net/support/downloads/?p=mx480#sw>
> www.juniper.net <http://www.juniper.net/>
> Juniper Software Downloads. It is important to keep your products registered 
> and your install base updated.
> 
> 
> Is 16.1R6-S4 considered almost equivalent?
> -- 
> The fashion wears out more apparel than the man.
> -- William Shakespeare, "Much Ado About Nothing"
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> <mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp 
> <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] MX480

[craig washington]

It's not released yet as far as I know.

I  know it was supposed to be at least per our SE at Juniper.

Hopefully will have some sort of update this week unless anyone else knows 
something.



From: juniper-nsp  on behalf of Vincent 
Bernat 
Sent: Sunday, June 17, 2018 10:17 AM
To: Sebastian Becker
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX480

❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :

> 16.1R7 is a golden release.

Is it already released? Not listed here:
 https://www.juniper.net/support/downloads/?p=mx480#sw
Download Software - Support - Juniper 
Networks<https://www.juniper.net/support/downloads/?p=mx480#sw>
www.juniper.net
Juniper Software Downloads. It is important to keep your products registered 
and your install base updated.



Is 16.1R6-S4 considered almost equivalent?
--
The fashion wears out more apparel than the man.
-- William Shakespeare, "Much Ado About Nothing"
___
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] MX480

[Vincent Bernat]

 ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :

> 16.1R7 is a golden release.

Is it already released? Not listed here:
 https://www.juniper.net/support/downloads/?p=mx480#sw

Is 16.1R6-S4 considered almost equivalent?
-- 
The fashion wears out more apparel than the man.
-- William Shakespeare, "Much Ado About Nothing"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[Sebastian Becker]

16.1R7 is a golden release.

— 
Sebastian Becker

> Am 16.06.2018 um 19:49 schrieb Chris Hale :
> 
>  Wait for a golden release, ask JTAC about the next golden release coming 
> out.  Maybe 17.3R2 or R3.  They will be highly tested and classified as very 
> safe for production use immediately.
> 
> On Sat, Jun 16, 2018 at 12:32 PM Sebastian Becker  > wrote:
> 16.1R4 is deployed in the moment. 16.1R7 is a recommendation from Juniper to 
> us.
> 
> — 
> Sebastian Becker
> s...@lab.dtag.de 
> 
> > Am 16.06.2018 um 13:33 schrieb Ian Goodall  > >:
> > 
> > 
> > Hi All
> > 
> > Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre
> > 15 code. We've had success on the 17.x train in P roles.
> > 
> > 15.1 is recommended by JTAC but it's EOL in under 12 months.
> > 
> > Historically picking a recent version with a high R release was always a
> > good starting point. The release strategy has changed somewhat and most
> > versions now don't go beyond R2.
> > 
> > What's everyone deploying currently?
> > 
> > Thanks
> > 
> > IG
> > ___
> > 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 
> 
> 
> 
> -- 
> --
> Chris Hale
> chal...@gmail.com 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[craig washington]

Same here with the juniper recommendation, they have recommend the Golden 
release 16.1R7 for us also

Sent from my iPhone

> On Jun 16, 2018, at 2:59 PM, Saku Ytti  wrote:
> 
> Hey,
> 
>> Wait for a golden release, ask JTAC about the next golden release coming
>> out.  Maybe 17.3R2 or R3.  They will be highly tested and classified as
>> very safe for production use immediately.
> 
> I usually mature my images on SCSI spindles on VAX machines for at
> least two year to really bring out the stableness.
> 
> Real talk, Juniper has done significant work on rebasing the JunOS on
> single branch with compelling testing story, I believe their story, I
> believe newer JunOS are better. And generally stability is very
> situational, release having 1 bug affecting you greatly is far worse
> image to you, than image having 1M bugs not affecting you.
> I exercise similar methodology for all vendors
> 
> a) start with latest long term supported image
> b) test to see it's not obviously broken, if it is obviously broken,
> contact vendor for assistance
> c) if not obviously broken, deploy
> d) when you need new features, restart the process, when you need bug
> fixes install rebuild
> 
> Long term:
> 
> a) ask vendor to report you quarterly in which phase of development
> they found bugs and how much
> b) use that information to choose vendors who are getting better
> according the metrics, i.e. finding issues earlier in the process
> 
> We need to make good testing story economic necessity. I know some
> vendor testing initiatives have been shot down, when there has not
> been any external pressure to invest on the work. So we can achieve
> lot of good, if we are asking vendors to report the right things to
> us.
> I think in last two years all vendors are getting lot better in this.
> If I had to guess, I don't think it's the networking folk we get to
> thank here, I think it's the software focused shops who are asking for
> the right data from vendors. We should join them.
> 
> -- 
>  ++ytti
> ___
> 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] MX480

[Saku Ytti]

Hey,

>  Wait for a golden release, ask JTAC about the next golden release coming
> out.  Maybe 17.3R2 or R3.  They will be highly tested and classified as
> very safe for production use immediately.

I usually mature my images on SCSI spindles on VAX machines for at
least two year to really bring out the stableness.

Real talk, Juniper has done significant work on rebasing the JunOS on
single branch with compelling testing story, I believe their story, I
believe newer JunOS are better. And generally stability is very
situational, release having 1 bug affecting you greatly is far worse
image to you, than image having 1M bugs not affecting you.
I exercise similar methodology for all vendors

a) start with latest long term supported image
b) test to see it's not obviously broken, if it is obviously broken,
contact vendor for assistance
c) if not obviously broken, deploy
d) when you need new features, restart the process, when you need bug
fixes install rebuild

Long term:

a) ask vendor to report you quarterly in which phase of development
they found bugs and how much
b) use that information to choose vendors who are getting better
according the metrics, i.e. finding issues earlier in the process

We need to make good testing story economic necessity. I know some
vendor testing initiatives have been shot down, when there has not
been any external pressure to invest on the work. So we can achieve
lot of good, if we are asking vendors to report the right things to
us.
I think in last two years all vendors are getting lot better in this.
If I had to guess, I don't think it's the networking folk we get to
thank here, I think it's the software focused shops who are asking for
the right data from vendors. We should join them.

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

Re: [j-nsp] MX480

[Chris Hale]

 Wait for a golden release, ask JTAC about the next golden release coming
out.  Maybe 17.3R2 or R3.  They will be highly tested and classified as
very safe for production use immediately.

On Sat, Jun 16, 2018 at 12:32 PM Sebastian Becker  wrote:

> 16.1R4 is deployed in the moment. 16.1R7 is a recommendation from Juniper
> to us.
>
> —
> Sebastian Becker
> s...@lab.dtag.de
>
> > Am 16.06.2018 um 13:33 schrieb Ian Goodall :
> >
> >
> > Hi All
> >
> > Were looking to upgrade JUNOS on some of our older PE MX480/960 running
> pre
> > 15 code. We've had success on the 17.x train in P roles.
> >
> > 15.1 is recommended by JTAC but it's EOL in under 12 months.
> >
> > Historically picking a recent version with a high R release was always a
> > good starting point. The release strategy has changed somewhat and most
> > versions now don't go beyond R2.
> >
> > What's everyone deploying currently?
> >
> > Thanks
> >
> > IG
> > ___
> > 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
>


-- 
--
Chris Hale
chal...@gmail.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[Sebastian Becker]

16.1R4 is deployed in the moment. 16.1R7 is a recommendation from Juniper to us.

— 
Sebastian Becker
s...@lab.dtag.de

> Am 16.06.2018 um 13:33 schrieb Ian Goodall :
> 
> 
> Hi All
> 
> Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre
> 15 code. We've had success on the 17.x train in P roles.
> 
> 15.1 is recommended by JTAC but it's EOL in under 12 months.
> 
> Historically picking a recent version with a high R release was always a
> good starting point. The release strategy has changed somewhat and most
> versions now don't go beyond R2.
> 
> What's everyone deploying currently?
> 
> Thanks
> 
> IG
> ___
> 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] MX480

[Ian Goodall]

Hi All

Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre
15 code. We've had success on the 17.x train in P roles.

15.1 is recommended by JTAC but it's EOL in under 12 months.

Historically picking a recent version with a high R release was always a
good starting point. The release strategy has changed somewhat and most
versions now don't go beyond R2.

What's everyone deploying currently?

Thanks

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

Re: [j-nsp] MX480 Show Chassis Hardware irregularities

[Cassell, Brandon]

Output of a 'show chassis hardware extensive' also displays incorrect (old) 
serial. 
I'm looking into the 'restart chassis-control' as well, the chassis has 
redundant PEM's in it, but I'll have to wait until we have someone onsite who 
can pull that for us. 

Thanks,
Brandon 

 
On 6/8/18, 10:36 AM, "Niall Donaghy"  wrote:

Hi Brandon,

I've never seen this.

Musings:

- Does 'show chassis hardware extensive' also mis-report?
- Have you tried (perhaps not until JTAC have a look at current state 
of the device) 'restart chassis-control soft' and/or 'gracefully'?
- I don't know for sure, but I will take an educated guess that 
i) this process includes the I2C functions, and that ii) the PEM reports its 
serial number via I2C?
- Alternatively you might reseat the PEM, if the chassis configuration 
supports this as non-service-affecting?

Hopefully JTAC will bear fruit, or someone else who has actually 
experienced this can advise.

Br,
Niall

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Cassell, Brandon
    Sent: 07 June 2018 18:35
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX480 Show Chassis Hardware irregularities

Hi All,
After replacing a PEM in an MX480 running 14.2R7.5, we noticed that the 
serial number for the replaced PEM still shows the old serial when issuing a 
‘show chassis hardware’ and doesn’t reflect the correct serial for the new PEM. 
I’ve not gotten anything back from JTAC yet on this, and so far going through 
other MX480 and MX960 chassis on different versions of code don’t appear to 
have this issue.
Anyone seen this behavior before?

Thanks,
Brandon


___
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] MX480 Show Chassis Hardware irregularities

[Niall Donaghy]

Hi Brandon,

I've never seen this.

Musings:

- Does 'show chassis hardware extensive' also mis-report?
- Have you tried (perhaps not until JTAC have a look at current state 
of the device) 'restart chassis-control soft' and/or 'gracefully'?
- I don't know for sure, but I will take an educated guess that 
i) this process includes the I2C functions, and that ii) the PEM reports its 
serial number via I2C?
- Alternatively you might reseat the PEM, if the chassis configuration 
supports this as non-service-affecting?

Hopefully JTAC will bear fruit, or someone else who has actually experienced 
this can advise.

Br,
Niall

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Cassell, Brandon
Sent: 07 June 2018 18:35
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX480 Show Chassis Hardware irregularities

Hi All,
After replacing a PEM in an MX480 running 14.2R7.5, we noticed that the serial 
number for the replaced PEM still shows the old serial when issuing a ‘show 
chassis hardware’ and doesn’t reflect the correct serial for the new PEM. I’ve 
not gotten anything back from JTAC yet on this, and so far going through other 
MX480 and MX960 chassis on different versions of code don’t appear to have this 
issue.
Anyone seen this behavior before?

Thanks,
Brandon


___
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] MX480 Show Chassis Hardware irregularities

[Cassell, Brandon]

Hi All,
After replacing a PEM in an MX480 running 14.2R7.5, we noticed that the serial 
number for the replaced PEM still shows the old serial when issuing a ‘show 
chassis hardware’ and doesn’t reflect the correct serial for the new PEM. I’ve 
not gotten anything back from JTAC yet on this, and so far going through other 
MX480 and MX960 chassis on different versions of code don’t appear to have this 
issue.
Anyone seen this behavior before?

Thanks,
Brandon


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

Re: [j-nsp] MX480 Filter based forwarding performance

[Johannes Resch]

Hi,

short answer: it depends :-)

It is done in hardware, and for "sane" filters will work at line rate (e.g.
I have built a setup where few hundred GBit/s are forwarded using FBF on
MX960 with multiple MPC7E). However, if you use lots of exotic match
conditions and/or excessively long filter terms, you could end up with less
than line rate throughput - just as it is the case with general Trio
firewall filter term processing.

Best regards,
Johannes


On 17 May 2018 at 22:49, harbor235  wrote:

> I am hoping someone can provide a good  link to FBF performance, is it
> handled by the PFE in hardware or is it handled in software, limitations if
> any?
>
> I have a design that is using FBF extensively, currently we are not routing
> much traffic but that could change soon.
>
> thanks in advance,
>
> Mike
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX480 Filter based forwarding performance

[harbor235]

I am hoping someone can provide a good  link to FBF performance, is it
handled by the PFE in hardware or is it handled in software, limitations if
any?

I have a design that is using FBF extensively, currently we are not routing
much traffic but that could change soon.

thanks in advance,

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

Re: [j-nsp] mx480, netflow/version9 ipv6 help

[Justin M. Streiner]

On Wed, 23 Aug 2017, John Brown wrote:


yes, sorry I forgot to include that
fpc 1 {
   sampling-instance 1to1;


Be very careful with 1:1 sampling if that's what you are in fact doing. 
In most of the cases that come to mind, 1:1 sampling isn't necessary to 
get the data you need for things like traffic visualization/capacity 
planning.  Beyond perhaps very small traffic levels, it might not be 
supported at all.


jms


   inline-services {

   flow-table-size {

   ipv4-flow-table-size 5;

   ipv6-flow-table-size 5;

   }

   }

}

fpc 2 {

   sampling-instance 1to1;

   inline-services {

   flow-table-size {

   ipv4-flow-table-size 5;

   ipv6-flow-table-size 5;

   }

   }

}


On Wed, Aug 23, 2017 at 9:46 AM, Alvaro Pereira  wrote:

Hi John,

Do you have the following configured on the fpc you have installed?
ATTENTION! THIS WILL AUTOMATICALLY REBOOT THE FPC !!!

https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/ipv6-flow-table-size.html

Note: Any change in the configured size of the flow hash table sizes
initiates an automatic reboot of the FPC.

set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 12
set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 3

You might want to play with the numbers depending on your use case.

Alvaro

On Wed, Aug 23, 2017 at 7:17 AM, John Brown  wrote:


Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
error from Junos.
Any help is much appreciated.  THANK YOU

Junos: 14.2R1.9

Error from commit check

 sampling inline configuration error
Can't configure inline output with V5, V8 and V9 collector
configured for family inet6

Config snip

family inet {
output {
flow-server 192.168.1.2 {
port 2055;
version9 {
template {
ipv4;
}
}
}
inline-jflow {
source-address 10.0.0.1;
}
}
}
family inet6 {
output {
flow-server 192.168.1.2 {
port 2055;
version9 {
template {
ipv6;
}
}
}
inline-jflow {
source-address 10.0.0.1;
}
}
}

flow-monitoring {
version9 {
template ipv4 {
ipv4-template;
}
template ipv6 {
ipv6-template;
}
}
___
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] mx480, netflow/version9 ipv6 help

[John Brown]

Not sure my flow collector (a ELK based config) will properly handle IP-FIX

On Wed, Aug 23, 2017 at 9:48 AM,   wrote:
>> Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
>> error from Junos.
>> Any help is much appreciated.  THANK YOU
>
> We are exporting IPv6 netflow info using IPfix - haven't tried v9.
> Seems to work for us. In your config, try replacing all "version9"
> occurrences with "version-ipfix".
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx480, netflow/version9 ipv6 help

[John Brown]

yes, sorry I forgot to include that

fpc 1 {

sampling-instance 1to1;

inline-services {

flow-table-size {

ipv4-flow-table-size 5;

ipv6-flow-table-size 5;

}

}

}

fpc 2 {

sampling-instance 1to1;

inline-services {

flow-table-size {

ipv4-flow-table-size 5;

ipv6-flow-table-size 5;

}

}

}


On Wed, Aug 23, 2017 at 9:46 AM, Alvaro Pereira  wrote:
> Hi John,
>
> Do you have the following configured on the fpc you have installed?
> ATTENTION! THIS WILL AUTOMATICALLY REBOOT THE FPC !!!
>
> https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/ipv6-flow-table-size.html
>
> Note: Any change in the configured size of the flow hash table sizes
> initiates an automatic reboot of the FPC.
>
> set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 12
> set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 3
>
> You might want to play with the numbers depending on your use case.
>
> Alvaro
>
> On Wed, Aug 23, 2017 at 7:17 AM, John Brown  wrote:
>>
>> Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
>> error from Junos.
>> Any help is much appreciated.  THANK YOU
>>
>> Junos: 14.2R1.9
>>
>> Error from commit check
>>
>>  sampling inline configuration error
>> Can't configure inline output with V5, V8 and V9 collector
>> configured for family inet6
>>
>> Config snip
>>
>> family inet {
>> output {
>> flow-server 192.168.1.2 {
>> port 2055;
>> version9 {
>> template {
>> ipv4;
>> }
>> }
>> }
>> inline-jflow {
>> source-address 10.0.0.1;
>> }
>> }
>> }
>> family inet6 {
>> output {
>> flow-server 192.168.1.2 {
>> port 2055;
>> version9 {
>> template {
>> ipv6;
>> }
>> }
>> }
>> inline-jflow {
>> source-address 10.0.0.1;
>> }
>> }
>> }
>>
>> flow-monitoring {
>> version9 {
>> template ipv4 {
>> ipv4-template;
>> }
>> template ipv6 {
>> ipv6-template;
>> }
>> }
>> ___
>> 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] mx480, netflow/version9 ipv6 help

[sthaug]

> Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
> error from Junos.
> Any help is much appreciated.  THANK YOU

We are exporting IPv6 netflow info using IPfix - haven't tried v9.
Seems to work for us. In your config, try replacing all "version9"
occurrences with "version-ipfix".

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx480, netflow/version9 ipv6 help

[Alvaro Pereira]

Hi John,

Do you have the following configured on the fpc you have installed? *ATTENTION!
THIS WILL AUTOMATICALLY REBOOT THE FPC !!!*

https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/ipv6-flow-table-size.html

*Note: *Any change in the configured size of the flow hash table sizes
initiates an automatic reboot of the FPC.

set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 12
set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 3

You might want to play with the numbers depending on your use case.

Alvaro

On Wed, Aug 23, 2017 at 7:17 AM, John Brown  wrote:

> Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
> error from Junos.
> Any help is much appreciated.  THANK YOU
>
> Junos: 14.2R1.9
>
> Error from commit check
>
>  sampling inline configuration error
> Can't configure inline output with V5, V8 and V9 collector
> configured for family inet6
>
> Config snip
>
> family inet {
> output {
> flow-server 192.168.1.2 {
> port 2055;
> version9 {
> template {
> ipv4;
> }
> }
> }
> inline-jflow {
> source-address 10.0.0.1;
> }
> }
> }
> family inet6 {
> output {
> flow-server 192.168.1.2 {
> port 2055;
> version9 {
> template {
> ipv6;
> }
> }
> }
> inline-jflow {
> source-address 10.0.0.1;
> }
> }
> }
>
> flow-monitoring {
> version9 {
> template ipv4 {
> ipv4-template;
> }
> template ipv6 {
> ipv6-template;
> }
> }
> ___
> 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] mx480, netflow/version9 ipv6 help

[John Brown]

Hi,  I'm trying to add IPv6 to my flow picture and I'm getting an
error from Junos.
Any help is much appreciated.  THANK YOU

Junos: 14.2R1.9

Error from commit check

 sampling inline configuration error
Can't configure inline output with V5, V8 and V9 collector
configured for family inet6

Config snip

family inet {
output {
flow-server 192.168.1.2 {
port 2055;
version9 {
template {
ipv4;
}
}
}
inline-jflow {
source-address 10.0.0.1;
}
}
}
family inet6 {
output {
flow-server 192.168.1.2 {
port 2055;
version9 {
template {
ipv6;
}
}
}
inline-jflow {
source-address 10.0.0.1;
}
}
}

flow-monitoring {
version9 {
template ipv4 {
ipv4-template;
}
template ipv6 {
ipv6-template;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 MS-MPC-128G CHASSISD_SNMP_TRAP10 jnxFruOfflineReason 8 but no button press

[Sebastian Becker]

Hi Dave,

We had such an issue with the PTX and it turned out they had some bad quality 
of the buttons so that the normal shaking from the fan trays can lead to a 
button press. You need to go to the JTAC for further investigation.

-- 
Sebastian Becker
s...@lab.dtag.de

> Am 08.02.2017 um 22:31 schrieb Michael Gehrmann :
> 
> 
> Hi David,
> 
> Might be worth checking for core dumps. I'd also do a PR search for and
> check on release notes for later releases. I have previously found on rare
> occasion MS cards can get into weird corner cases which normally involve
> JTAC to resolve.
> 
> Regards
> Mike
> 
> On 9 February 2017 at 14:14, David B Funk  >
> wrote:
> 
>> We have a MX480 with a pair of MS-MPC-128G service boards that are tied
>> together as a 'ams' (mams-2 & mams-3 ) service aggregation for reliability.
>> 
>> Occasionally one of them, for no apparent reason, will go offline and then
>> back online while logging in 'chassid' log:
>> 
>> CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power on
>> (jnxFruContentsIndex 8, jnxFruL1Index 4, jnxFruL2Index 1, jnxFruL3Index 0,
>> jnxFruName PIC: MS-MPC-PIC @ 3/0/*, jnxFruType 11, jnxFruSlot 3,
>> jnxFruOfflineReason 2, jnxFruLastPowerOff 1052212977, jnxFruLastPowerOn
>> 1052213068)
>> (as well as a bunch of other stuff).
>> 
>> According to Junos docs, "jnxFruOfflineReason 8" -> "buttonPress(8), --
>> offlined by button press"
>> But I know that nobody was in the room at the time of those incidents, so
>> the button couldn't have been pressed.
>> 
>> I hadn't paid too much attention to this as it was only happening
>> occasionally and was either one board or the other. But today there was a
>> whole spate of such incidents (20 in less than 45 minutes) and at one point
>> it took both MPCs off line at the same time (thus noticable
>> service-interruptus ).
>> 
>> In the 'messages' log there are lines that correspond:
>> 
>>  /kernel: peer_input_pending_internal:[4506] VKS0 for peer type 22 indx
>> 12 reported a sb_state 32 = SBS_CANTRCVMORE
>>  /kernel: peer_inputs:4766 VKS0 closing connection peer type 22 indx 12
>> err 5
>>  /kernel: pfe_listener_disconnect: conn dropped: listener idx=7,
>> tnpaddr=0x13010080, reason: generic peer error
>>  datapath-traced[3960]: datapath_traced_connection_event_handler:
>> Disconnected from MSPMAND
>>  mspd[3958]: Removed PIC connection state for fpc=3 pic=0
>> session=0x827a180
>>  (FPC Slot 3, PIC Slot 0)  ms30 kernel: svcs_ms2_app_sigcore_exit:
>> sending UKERN_ST_DOWN (pid=190, td=0xc291f960, sig=6)
>>  (FPC Slot 3, PIC Slot 0)  ms30 mspsmd[178]: mspsmd_connection_shutdown:
>> Unexpected shutdown of connection, try reconnecting.
>>  /kernel: if_pfe_services_health_status: Generating Health status (down)
>> msg for ifd : ms-3/0/0
>>  /kernel: if_pfe_services_health_status: Generating health status (down)
>> for AMS member mams-3/0/0
>>  /kernel: if_pfe_ams_process_single_event: ifd:mams-3/0/0, ev =
>> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: ACTIVE,
>> member_present_count = 2
>>  /kernel: if_pfe_ams_process_member_down_event:Starting Discard Timer
>>  /kernel: aggr_link_op: link mams-3/0/0.1 (lidx=1) detached from bundle
>> ams0.1
>>  /kernel: if_pfe_ams_process_single_event:Done:mams-3/0/0, ev =
>> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: DISCARD,
>> member_present_count = 2
>>  /kernel: if_pfe_services_send_lb_options: PEER_BUILD_IPC_SLOT return
>> NULL
>>  last message repeated 4 times
>>  mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 641, ifAdminStatus up(1),
>> ifOperStatus down(2), ifName ms-3/0/0.0
>>  mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 734, ifAdminStatus up(1),
>> ifOperStatus down(2), ifName mams-3/0/0.1
>>  (FPC Slot 3, PIC Slot 0)  ms30 kernel: msgring_drain_process: bind
>> thread to hwtid (5) cpuid(5)
>>  (FPC Slot 3, PIC Slot 0)  ms30 kernel: Kmernel thread "msgdrainthr5"
>> (pid 21832) exited prematurely.
>> 
>> Usually it runs for days at a time with out a single one of these
>> incidents.
>> So I cannot tell if I've got a hardware flakey or a software bug that is
>> being triggered by some external events.
>> 
>> Any suggestions? (other than opening a jtac case).
>> 
>> --
>> Dave Funk  University of Iowa
>> College of Engineering
>> 319/335-5751   FAX: 319/384-0549   1256 Seamans Center
>> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
>> #include 
>> Better is not better, 'standard' is better. B{
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.ne 
>> 
>> ther.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=wBUwXtM9s
>> Khff6UeHOQgvw&r=iCARHrCSMVMu5fNENyuQGdvoQJpwI5WIbiqe9jFEMFg&
>> m=XA7G1eLizI_SB_PtEfaugLI3dfFDoy-OpLfVObS3k2s&s=8_SDm_
>> ZHLrndQoPMH2Xuvf0V2n-l-UiOloc3VthxWHY&

Re: [j-nsp] MX480 MS-MPC-128G CHASSISD_SNMP_TRAP10 jnxFruOfflineReason 8 but no button press

[Michael Gehrmann]

Hi David,

Might be worth checking for core dumps. I'd also do a PR search for and
check on release notes for later releases. I have previously found on rare
occasion MS cards can get into weird corner cases which normally involve
JTAC to resolve.

Regards
Mike

On 9 February 2017 at 14:14, David B Funk 
wrote:

> We have a MX480 with a pair of MS-MPC-128G service boards that are tied
> together as a 'ams' (mams-2 & mams-3 ) service aggregation for reliability.
>
> Occasionally one of them, for no apparent reason, will go offline and then
> back online while logging in 'chassid' log:
>
> CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power on
> (jnxFruContentsIndex 8, jnxFruL1Index 4, jnxFruL2Index 1, jnxFruL3Index 0,
> jnxFruName PIC: MS-MPC-PIC @ 3/0/*, jnxFruType 11, jnxFruSlot 3,
> jnxFruOfflineReason 2, jnxFruLastPowerOff 1052212977, jnxFruLastPowerOn
> 1052213068)
> (as well as a bunch of other stuff).
>
> According to Junos docs, "jnxFruOfflineReason 8" -> "buttonPress(8), --
> offlined by button press"
> But I know that nobody was in the room at the time of those incidents, so
> the button couldn't have been pressed.
>
> I hadn't paid too much attention to this as it was only happening
> occasionally and was either one board or the other. But today there was a
> whole spate of such incidents (20 in less than 45 minutes) and at one point
> it took both MPCs off line at the same time (thus noticable
> service-interruptus ).
>
> In the 'messages' log there are lines that correspond:
>
>   /kernel: peer_input_pending_internal:[4506] VKS0 for peer type 22 indx
> 12 reported a sb_state 32 = SBS_CANTRCVMORE
>   /kernel: peer_inputs:4766 VKS0 closing connection peer type 22 indx 12
> err 5
>   /kernel: pfe_listener_disconnect: conn dropped: listener idx=7,
> tnpaddr=0x13010080, reason: generic peer error
>   datapath-traced[3960]: datapath_traced_connection_event_handler:
> Disconnected from MSPMAND
>   mspd[3958]: Removed PIC connection state for fpc=3 pic=0
> session=0x827a180
>   (FPC Slot 3, PIC Slot 0)  ms30 kernel: svcs_ms2_app_sigcore_exit:
> sending UKERN_ST_DOWN (pid=190, td=0xc291f960, sig=6)
>   (FPC Slot 3, PIC Slot 0)  ms30 mspsmd[178]: mspsmd_connection_shutdown:
> Unexpected shutdown of connection, try reconnecting.
>   /kernel: if_pfe_services_health_status: Generating Health status (down)
> msg for ifd : ms-3/0/0
>   /kernel: if_pfe_services_health_status: Generating health status (down)
> for AMS member mams-3/0/0
>   /kernel: if_pfe_ams_process_single_event: ifd:mams-3/0/0, ev =
> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: ACTIVE,
> member_present_count = 2
>   /kernel: if_pfe_ams_process_member_down_event:Starting Discard Timer
>   /kernel: aggr_link_op: link mams-3/0/0.1 (lidx=1) detached from bundle
> ams0.1
>   /kernel: if_pfe_ams_process_single_event:Done:mams-3/0/0, ev =
> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: DISCARD,
> member_present_count = 2
>   /kernel: if_pfe_services_send_lb_options: PEER_BUILD_IPC_SLOT return
> NULL
>   last message repeated 4 times
>   mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 641, ifAdminStatus up(1),
> ifOperStatus down(2), ifName ms-3/0/0.0
>   mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 734, ifAdminStatus up(1),
> ifOperStatus down(2), ifName mams-3/0/0.1
>   (FPC Slot 3, PIC Slot 0)  ms30 kernel: msgring_drain_process: bind
> thread to hwtid (5) cpuid(5)
>   (FPC Slot 3, PIC Slot 0)  ms30 kernel: Kmernel thread "msgdrainthr5"
> (pid 21832) exited prematurely.
>
> Usually it runs for days at a time with out a single one of these
> incidents.
> So I cannot tell if I've got a hardware flakey or a software bug that is
> being triggered by some external events.
>
> Any suggestions? (other than opening a jtac case).
>
> --
> Dave Funk  University of Iowa
> College of Engineering
> 319/335-5751   FAX: 319/384-0549   1256 Seamans Center
> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
> #include 
> Better is not better, 'standard' is better. B{
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.ne
> ther.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=wBUwXtM9s
> Khff6UeHOQgvw&r=iCARHrCSMVMu5fNENyuQGdvoQJpwI5WIbiqe9jFEMFg&
> m=XA7G1eLizI_SB_PtEfaugLI3dfFDoy-OpLfVObS3k2s&s=8_SDm_
> ZHLrndQoPMH2Xuvf0V2n-l-UiOloc3VthxWHY&e=




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

[j-nsp] MX480 MS-MPC-128G CHASSISD_SNMP_TRAP10 jnxFruOfflineReason 8 but no button press

[David B Funk]

We have a MX480 with a pair of MS-MPC-128G service boards that are tied together 
as a 'ams' (mams-2 & mams-3 ) service aggregation for reliability.


Occasionally one of them, for no apparent reason, will go offline and then back 
online while logging in 'chassid' log:


CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power on (jnxFruContentsIndex 8, 
jnxFruL1Index 4, jnxFruL2Index 1, jnxFruL3Index 0, jnxFruName PIC: MS-MPC-PIC @ 
3/0/*, jnxFruType 11, jnxFruSlot 3, jnxFruOfflineReason 2, jnxFruLastPowerOff 
1052212977, jnxFruLastPowerOn 1052213068)
(as well as a bunch of other stuff).

According to Junos docs, "jnxFruOfflineReason 8" -> "buttonPress(8), -- offlined by 
button press"
But I know that nobody was in the room at the time of those incidents, so the 
button couldn't have been pressed.


I hadn't paid too much attention to this as it was only happening occasionally 
and was either one board or the other. But today there was a whole spate of such 
incidents (20 in less than 45 minutes) and at one point it took both MPCs off 
line at the same time (thus noticable service-interruptus ).


In the 'messages' log there are lines that correspond:

  /kernel: peer_input_pending_internal:[4506] VKS0 for peer type 22 indx 12 
reported a sb_state 32 = SBS_CANTRCVMORE
  /kernel: peer_inputs:4766 VKS0 closing connection peer type 22 indx 12 err 5
  /kernel: pfe_listener_disconnect: conn dropped: listener idx=7, 
tnpaddr=0x13010080, reason: generic peer error
  datapath-traced[3960]: datapath_traced_connection_event_handler: Disconnected 
from MSPMAND
  mspd[3958]: Removed PIC connection state for fpc=3 pic=0 session=0x827a180
  (FPC Slot 3, PIC Slot 0)  ms30 kernel: svcs_ms2_app_sigcore_exit: sending 
UKERN_ST_DOWN (pid=190, td=0xc291f960, sig=6)
  (FPC Slot 3, PIC Slot 0)  ms30 mspsmd[178]: mspsmd_connection_shutdown: 
Unexpected shutdown of connection, try reconnecting.
  /kernel: if_pfe_services_health_status: Generating Health status (down) msg 
for ifd : ms-3/0/0
  /kernel: if_pfe_services_health_status: Generating health status (down) for 
AMS member mams-3/0/0
  /kernel: if_pfe_ams_process_single_event: ifd:mams-3/0/0, ev = 
AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: ACTIVE, 
member_present_count = 2
  /kernel: if_pfe_ams_process_member_down_event:Starting Discard Timer
  /kernel: aggr_link_op: link mams-3/0/0.1 (lidx=1) detached from bundle ams0.1
  /kernel: if_pfe_ams_process_single_event:Done:mams-3/0/0, ev = 
AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: DISCARD, 
member_present_count = 2
  /kernel: if_pfe_services_send_lb_options: PEER_BUILD_IPC_SLOT return NULL
  last message repeated 4 times
  mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 641, ifAdminStatus up(1), 
ifOperStatus down(2), ifName ms-3/0/0.0
  mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 734, ifAdminStatus up(1), 
ifOperStatus down(2), ifName mams-3/0/0.1
  (FPC Slot 3, PIC Slot 0)  ms30 kernel: msgring_drain_process: bind thread to 
hwtid (5) cpuid(5)
  (FPC Slot 3, PIC Slot 0)  ms30 kernel: Kmernel thread "msgdrainthr5" (pid 
21832) exited prematurely.

Usually it runs for days at a time with out a single one of these incidents.
So I cannot tell if I've got a hardware flakey or a software bug that is being triggered 
by some external events.


Any suggestions? (other than opening a jtac case).

--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX480 with new RE's -- Memory mismatch alarms

[William McLendon]

hey all,

curious if anyone has seen this and knows why it happens or if its anything to 
be concerned about.  we received new MX480s with the new 64G Routing Engines 
where Junos is in a VM, and on both MX480s we have seen messages like the 
following:

MX480-2-re0> show system alarms 
2 alarms currently active
Alarm time   Class  Description
2016-11-28 21:25:07 UTC  Minor  RE 1 Mismatch in total memory detected
2016-11-28 21:25:02 UTC  Minor  RE 0 Mismatch in total memory detected

with syslog messages like this:

Nov 28 19:10:20.919 2016  MX480-2-re0 craftd[4836]: Minor alarm cleared, RE 0 
Mismatch in total memory detected
Nov 28 19:10:20.919 2016  MX480-2-re0 craftd[4836]: Minor alarm cleared, RE 1 
Mismatch in total memory detected
Nov 28 21:23:26.518 2016  MX480-2-re0 kernel: real memory  = 51539607552 (49152 
MB)
Nov 28 21:23:26.518 2016  MX480-2-re0 kernel: avail memory = 50002657280 (47686 
MB)
Nov 28 21:23:40.941 2016  MX480-2-re0 chassisd[4833]: 
re_rainier_perform_misc_checks:RE memory size mismatch expected 65536 M , 
actual 0 M
Nov 28 21:25:02.051 2016  MX480-2-re0 alarmd[5155]: Alarm set: RE color=YELLOW, 
class=CHASSIS, reason=RE 0 Mismatch in total memory detected
Nov 28 21:25:02.090 2016  MX480-2-re0 craftd[4836]:  Minor alarm set, RE 0 
Mismatch in total memory detected
Nov 28 21:25:07.372 2016  MX480-2-re0 alarmd[5155]: Alarm set: RE color=YELLOW, 
class=CHASSIS, reason=RE 1 Mismatch in total memory detected
Nov 28 21:25:07.372 2016  MX480-2-re0 craftd[4836]:  Minor alarm set, RE 1 
Mismatch in total memory detected


going to open a TAC ticket, but was curious if anyone else had seen this and 
had any insight.

Thanks,

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

Re: [j-nsp] MX480 + RE-S-1300 with more than 1024 VRRP instances possible?

[Nitzan Tzelniker]

Did you try vrrp-inherit-from

https://www.juniper.net/documentation/en_US/junos12.1/topics/task/configuration/vrrp-inheritance-for-a-group-configuring.html

Nitzan

On Thu, Nov 26, 2015 at 7:25 PM, "Rolf Hanßen"  wrote:

> Hi,
>
> just ran into that issue after creating a customer vlan on a MX480 with
> RE-S-1300-2048:
> "Too many VRRP instances on ae0.  Maximum allowed is 1024."
>
> According to what I can find this looks to me like a global limit and not
> an ae-specific or RE-specific value:
> "Note: A maximum of 1024 VRRP instances are supported per chassis."
>
>
> http://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/ccpe-vrrp-multiple-groups-subnets-summary.html
>
> Does anybody know a workaround or a possibility to increase the value?
>
> kind regards
> Rolf
>
>
> ___
> 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] MX480 + RE-S-1300 with more than 1024 VRRP instances possible?

[Rolf Hanßen]

Hi,

just ran into that issue after creating a customer vlan on a MX480 with
RE-S-1300-2048:
"Too many VRRP instances on ae0.  Maximum allowed is 1024."

According to what I can find this looks to me like a global limit and not
an ae-specific or RE-specific value:
"Note: A maximum of 1024 VRRP instances are supported per chassis."

http://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/ccpe-vrrp-multiple-groups-subnets-summary.html

Does anybody know a workaround or a possibility to increase the value?

kind regards
Rolf


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

Re: [j-nsp] MX480 Build

[Mark Tinka]

On 25/Jul/15 16:54, Colton Conor wrote:
> So how redundant an reliable would a MX480 be with two RE-2000's, 2
> SCB's, and 4 AC power supplies?

Extremely.

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

Re: [j-nsp] MX480 Build

[Raphael Mazelier]

Le 25/07/15 16:54, Colton Conor a écrit :

So how redundant an reliable would a MX480 be with two RE-2000's, 2 SCB's,
and 4 AC power supplies? I know in the ideal world there would be two of
these, but due to budget that is not an option. What have you seen fail on
MX480's?



I think this is good and stable router. In my opinion it would be 
preferable to have two mx480 (with one RE, one SBC each). In your 
scenario you'll have a very strong router, but it would not prevent for 
human error (or software).


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

Re: [j-nsp] MX480 Build

[Justin M. Streiner]

On Sat, 25 Jul 2015, Colton Conor wrote:


So how redundant an reliable would a MX480 be with two RE-2000's, 2 SCB's,
and 4 AC power supplies? I know in the ideal world there would be two of
these, but due to budget that is not an option. What have you seen fail on
MX480's?


At $dayjob, we replaced our old border routers with a pair of MX480s about 
a year ago.  Aside from one linecard that arrived DOA (replaced quickly
and hassle-free by Juniper), and a BGP-related code bug in the version we 
initially deployed, the boxes have been completely solid.


Two MX480s, each with a pair of SCB-Es, RE-S-1800s, two MPC3Ds with 4x10G 
MICs, and 4 power supplies.  One also has a 2x100G/8x10G MPC4E blade. 
These boxes handle multiple full IPv4 and IPv6 BGP feeds in two separate 
routing instances with a relatively complex routing policy with no major 
issues.


We're currently running Junos 12.3R8.7, which has been stable in our 
environment.


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

Re: [j-nsp] MX480 Build

[Colton Conor]

So how redundant an reliable would a MX480 be with two RE-2000's, 2 SCB's,
and 4 AC power supplies? I know in the ideal world there would be two of
these, but due to budget that is not an option. What have you seen fail on
MX480's?

On Wed, Jul 22, 2015 at 10:09 AM, Mark Tinka  wrote:

>
>
> On 22/Jul/15 17:01, Bill Blackford wrote:
> > I'm referencing my experience from a few years back. Thank you for the
> clarification.
>
> Nonetheless, I'd suggest looking into possible software limitations in
> current code in mixed environments. The last thing you need is a feature
> not working or downgrading to some "compatible" mode because of the
> presence of a DPC and MPC in the same chassis.
>
> Many of these things are documented in release notes (if you bother to
> read them), but some may be so quirky and you only learn them on the
> back of a 15-month old JTAC case.
>
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 Build

[Mark Tinka]

On 22/Jul/15 17:01, Bill Blackford wrote:
> I'm referencing my experience from a few years back. Thank you for the 
> clarification. 

Nonetheless, I'd suggest looking into possible software limitations in
current code in mixed environments. The last thing you need is a feature
not working or downgrading to some "compatible" mode because of the
presence of a DPC and MPC in the same chassis.

Many of these things are documented in release notes (if you bother to
read them), but some may be so quirky and you only learn them on the
back of a 15-month old JTAC case.

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

Re: [j-nsp] MX480 Build

[Bill Blackford]

I'm referencing my experience from a few years back. Thank you for the 
clarification. 

Sent from my iPhone

> On Jul 22, 2015, at 07:51, Damien DeVille  wrote:
> 
> You absolutely can mix MPCs and DPCs in the same chassis.  When the MPCs 
> first came out there were compatibility issues, but with modern Junos 
> versions (11.4 and on) those are history.
> 
> 
> - Damien
> 
>> On Wed, Jul 22, 2015 at 10:32 AM, Bill Blackford  
>> wrote:
>> I agree that this is a good build for what you've stated. I would definitely 
>> recommend an MS-DPC for off-loading any sampling or crypto.
>> 
>> You mention higher density with the use of MICs in the future. This would 
>> require taking the plunge to MPC and a replacement of your DPCs (you cannot 
>> mix DPC and MPC on the same chassis) and depending on the MPC choices, 
>> possibly the fans, SBCs and REs as well. Just something to keep in mind.
>> 
>> Sent from my iPhone
>> 
>> > On Jul 22, 2015, at 06:24, Colton Conor  wrote:
>> >
>> > I am considering buying a used MX480. It will have the following:
>> >
>> >
>> >
>> > 1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
>> > power
>> >
>> >
>> > 2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
>> > separately
>> >
>> >
>> >
>> > 1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
>> > Release 9.3 and later
>> >
>> >
>> >
>> >
>> >
>> > Assuming we have the latest software version from Juniper to install on
>> > this used box, is there anything we should know about this potential setup?
>> > I believe this DPC cards are EOL, but I think many people are still using
>> > them. I know there are more dense MIC cards out there, but that is not
>> > needed at this time.
>> >
>> >
>> >
>> > I think everything about this system is redundant besides the MS-DPC, but I
>> > could get another one of those too.
>> >
>> >
>> >
>> > Are there any licensing restrictions or upgrade restrictions I should be
>> > aware of? Does Juniper have any locks or software limitations on these
>> > larger routers like they do on the MX-5 through MX-80 and MX 104?
>> >
>> >
>> >
>> > Besides the chassis size and power consumption anything we should know or
>> > consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
>> > too small for our needs, so its really the MX480 vs MX960.
>> >
>> >
>> > I would be upgrading from a MX80, so this is quite a jump.
>> > ___
>> > 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] MX480 Build

[Colton Conor]

Are you sure you can not mix and match DPC with MPC?  I know it was not
recommended back in the day, but from what I have read its fine now. But I
have not seen either of these stated in an official Juniper document. Can
you mix and match or not?

On Wed, Jul 22, 2015 at 9:32 AM, Bill Blackford 
wrote:

> I agree that this is a good build for what you've stated. I would
> definitely recommend an MS-DPC for off-loading any sampling or crypto.
>
> You mention higher density with the use of MICs in the future. This would
> require taking the plunge to MPC and a replacement of your DPCs (you cannot
> mix DPC and MPC on the same chassis) and depending on the MPC choices,
> possibly the fans, SBCs and REs as well. Just something to keep in mind.
>
> Sent from my iPhone
>
> > On Jul 22, 2015, at 06:24, Colton Conor  wrote:
> >
> > I am considering buying a used MX480. It will have the following:
> >
> >
> >
> > 1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and
> AC
> > power
> >
> >
> > 2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
> > separately
> >
> >
> >
> > 1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos
> OS
> > Release 9.3 and later
> >
> >
> >
> >
> >
> > Assuming we have the latest software version from Juniper to install on
> > this used box, is there anything we should know about this potential
> setup?
> > I believe this DPC cards are EOL, but I think many people are still using
> > them. I know there are more dense MIC cards out there, but that is not
> > needed at this time.
> >
> >
> >
> > I think everything about this system is redundant besides the MS-DPC,
> but I
> > could get another one of those too.
> >
> >
> >
> > Are there any licensing restrictions or upgrade restrictions I should be
> > aware of? Does Juniper have any locks or software limitations on these
> > larger routers like they do on the MX-5 through MX-80 and MX 104?
> >
> >
> >
> > Besides the chassis size and power consumption anything we should know or
> > consider deciding between a MX 240, MX480, and MX960? It seems the MX240
> is
> > too small for our needs, so its really the MX480 vs MX960.
> >
> >
> > I would be upgrading from a MX80, so this is quite a jump.
> > ___
> > 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] MX480 Build

[Damien DeVille]

You absolutely can mix MPCs and DPCs in the same chassis.  When the MPCs
first came out there were compatibility issues, but with modern Junos
versions (11.4 and on) those are history.


- Damien

On Wed, Jul 22, 2015 at 10:32 AM, Bill Blackford 
wrote:

> I agree that this is a good build for what you've stated. I would
> definitely recommend an MS-DPC for off-loading any sampling or crypto.
>
> You mention higher density with the use of MICs in the future. This would
> require taking the plunge to MPC and a replacement of your DPCs (you cannot
> mix DPC and MPC on the same chassis) and depending on the MPC choices,
> possibly the fans, SBCs and REs as well. Just something to keep in mind.
>
> Sent from my iPhone
>
> > On Jul 22, 2015, at 06:24, Colton Conor  wrote:
> >
> > I am considering buying a used MX480. It will have the following:
> >
> >
> >
> > 1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and
> AC
> > power
> >
> >
> > 2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
> > separately
> >
> >
> >
> > 1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos
> OS
> > Release 9.3 and later
> >
> >
> >
> >
> >
> > Assuming we have the latest software version from Juniper to install on
> > this used box, is there anything we should know about this potential
> setup?
> > I believe this DPC cards are EOL, but I think many people are still using
> > them. I know there are more dense MIC cards out there, but that is not
> > needed at this time.
> >
> >
> >
> > I think everything about this system is redundant besides the MS-DPC,
> but I
> > could get another one of those too.
> >
> >
> >
> > Are there any licensing restrictions or upgrade restrictions I should be
> > aware of? Does Juniper have any locks or software limitations on these
> > larger routers like they do on the MX-5 through MX-80 and MX 104?
> >
> >
> >
> > Besides the chassis size and power consumption anything we should know or
> > consider deciding between a MX 240, MX480, and MX960? It seems the MX240
> is
> > too small for our needs, so its really the MX480 vs MX960.
> >
> >
> > I would be upgrading from a MX80, so this is quite a jump.
> > ___
> > 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] MX480 Build

[Bill Blackford]

I agree that this is a good build for what you've stated. I would definitely 
recommend an MS-DPC for off-loading any sampling or crypto. 

You mention higher density with the use of MICs in the future. This would 
require taking the plunge to MPC and a replacement of your DPCs (you cannot mix 
DPC and MPC on the same chassis) and depending on the MPC choices, possibly the 
fans, SBCs and REs as well. Just something to keep in mind.

Sent from my iPhone

> On Jul 22, 2015, at 06:24, Colton Conor  wrote:
> 
> I am considering buying a used MX480. It will have the following:
> 
> 
> 
> 1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
> power
> 
> 
> 2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
> separately
> 
> 
> 
> 1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
> Release 9.3 and later
> 
> 
> 
> 
> 
> Assuming we have the latest software version from Juniper to install on
> this used box, is there anything we should know about this potential setup?
> I believe this DPC cards are EOL, but I think many people are still using
> them. I know there are more dense MIC cards out there, but that is not
> needed at this time.
> 
> 
> 
> I think everything about this system is redundant besides the MS-DPC, but I
> could get another one of those too.
> 
> 
> 
> Are there any licensing restrictions or upgrade restrictions I should be
> aware of? Does Juniper have any locks or software limitations on these
> larger routers like they do on the MX-5 through MX-80 and MX 104?
> 
> 
> 
> Besides the chassis size and power consumption anything we should know or
> consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
> too small for our needs, so its really the MX480 vs MX960.
> 
> 
> I would be upgrading from a MX80, so this is quite a jump.
> ___
> 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] MX480 Build

[Mark Tinka]

On 22/Jul/15 16:04, Jerry Jones wrote:
> MPX support inline flow on Trio. Not as flexible but possible.

You mean MPC?

But the OP is getting DPC's, so he is either relegated to RE-based NDE,
or offload that to the MS-DPC.

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

Re: [j-nsp] MX480 Build

[Jerry Jones]

MPX support inline flow on Trio. Not as flexible but possible.

On Jul 22, 2015, at 8:51 AM, Colton Conor  wrote:

We would be getting redundant (2) RE-2000's with redundant (2) standard
SCB's.

The configuration would be full BGP tables with 4 providers on 10G ports.

The MS-DCP is a requirement for JFLOW on these older cards right? We would
also use the MS-DCP for IPSec tunnels to Cisco ASAs. Any issues with
Juniper MS-DPC talking to Cisco ASA? Might also do some NATting with the
MS-DCP.



On Wed, Jul 22, 2015 at 8:39 AM, Will O'Brien - NOAA Affiliate <
will.obr...@noaa.gov> wrote:

> You didn't specify which REs you'd get with it. Make sure you are getting
> a pair. (Even though the 960 uses three SCBs, you can only use two REs in
> that chassis as well.)
> The R blades are pretty solid, but you didn't specify any sort of config
> requirements.
> What will you be using the MSDPC for? (Last I checked redundancy config
> for those was disappointing, but I haven't used one in about a year and a
> half now.
> In the past, mixed mode wasn't recommended, but it doesn't seem to be a
> big deal now. (If you are considering buying MPCs at some point to use with
> the R blades.)
> 
> Will
> 
> On Wed, Jul 22, 2015 at 7:33 AM, Mark Tinka  wrote:
> 
>> 
>> 
>> On 22/Jul/15 15:24, Colton Conor wrote:
>>> 
>>> 
>>> 
>>> Besides the chassis size and power consumption anything we should know
>> or
>>> consider deciding between a MX 240, MX480, and MX960? It seems the
>> MX240 is
>>> too small for our needs, so its really the MX480 vs MX960.
>> 
>> You take a bigger hit on the MX960 with a fabric failure if all slots
>> are full.
>> 
>> Because the MX240 and MX480 have fewer slots, your exposure is more
>> limited in this regard.
>> 
>> But I think with the new SCB-E's, this may no longer be an issue for the
>> MX960. Been a while since I checked as we are exclusively MX480 for the
>> time being.
>> 
>> 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

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

Re: [j-nsp] MX480 Build

[Jerry Jones]

correct.
On Jul 22, 2015, at 8:53 AM, Colton Conor  wrote:

Eventhough the RE-2000 is going into EOL status, it is still faster and has 
more memory than the RE's in the MX80 or MX104 right? 

On Wed, Jul 22, 2015 at 8:38 AM, Jerry Jones  wrote:
The RE-2000 and SCB have been announced EOL for next year.

On Jul 22, 2015, at 8:24 AM, Colton Conor  wrote:

I am considering buying a used MX480. It will have the following:



1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
power


2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
separately



1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
Release 9.3 and later





Assuming we have the latest software version from Juniper to install on
this used box, is there anything we should know about this potential setup?
I believe this DPC cards are EOL, but I think many people are still using
them. I know there are more dense MIC cards out there, but that is not
needed at this time.



I think everything about this system is redundant besides the MS-DPC, but I
could get another one of those too.



Are there any licensing restrictions or upgrade restrictions I should be
aware of? Does Juniper have any locks or software limitations on these
larger routers like they do on the MX-5 through MX-80 and MX 104?



Besides the chassis size and power consumption anything we should know or
consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
too small for our needs, so its really the MX480 vs MX960.


I would be upgrading from a MX80, so this is quite a jump.
___
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] MX480 Build

[Raphael Mazelier]

Le 22/07/15 15:51, Colton Conor a écrit :

We would be getting redundant (2) RE-2000's with redundant (2) standard
SCB's.

The configuration would be full BGP tables with 4 providers on 10G ports.

The MS-DCP is a requirement for JFLOW on these older cards right? We would
also use the MS-DCP for IPSec tunnels to Cisco ASAs. Any issues with
Juniper MS-DPC talking to Cisco ASA? Might also do some NATting with the
MS-DCP.




I think your setup will be perfectly fine. regarding the flow, you have 
two options, inline jflow (with the help of ms-dpc) or software flow 
(this is what I am doing for now with no issues).
I had not played with ms-dpc so I don't know if they are good at making 
ipsec (but as ipsec is a common standard and asas the most common device 
to make ipsec tunnel, I think this is safe ?). Don't know for the nat.


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

Re: [j-nsp] MX480 Build

[Colton Conor]

Eventhough the RE-2000 is going into EOL status, it is still faster and has
more memory than the RE's in the MX80 or MX104 right?

On Wed, Jul 22, 2015 at 8:38 AM, Jerry Jones  wrote:

> The RE-2000 and SCB have been announced EOL for next year.
>
> On Jul 22, 2015, at 8:24 AM, Colton Conor  wrote:
>
> I am considering buying a used MX480. It will have the following:
>
>
>
> 1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
> power
>
>
> 2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
> separately
>
>
>
> 1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
> Release 9.3 and later
>
>
>
>
>
> Assuming we have the latest software version from Juniper to install on
> this used box, is there anything we should know about this potential setup?
> I believe this DPC cards are EOL, but I think many people are still using
> them. I know there are more dense MIC cards out there, but that is not
> needed at this time.
>
>
>
> I think everything about this system is redundant besides the MS-DPC, but I
> could get another one of those too.
>
>
>
> Are there any licensing restrictions or upgrade restrictions I should be
> aware of? Does Juniper have any locks or software limitations on these
> larger routers like they do on the MX-5 through MX-80 and MX 104?
>
>
>
> Besides the chassis size and power consumption anything we should know or
> consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
> too small for our needs, so its really the MX480 vs MX960.
>
>
> I would be upgrading from a MX80, so this is quite a jump.
> ___
> 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] MX480 Build

[Colton Conor]

We would be getting redundant (2) RE-2000's with redundant (2) standard
SCB's.

The configuration would be full BGP tables with 4 providers on 10G ports.

The MS-DCP is a requirement for JFLOW on these older cards right? We would
also use the MS-DCP for IPSec tunnels to Cisco ASAs. Any issues with
Juniper MS-DPC talking to Cisco ASA? Might also do some NATting with the
MS-DCP.



On Wed, Jul 22, 2015 at 8:39 AM, Will O'Brien - NOAA Affiliate <
will.obr...@noaa.gov> wrote:

> You didn't specify which REs you'd get with it. Make sure you are getting
> a pair. (Even though the 960 uses three SCBs, you can only use two REs in
> that chassis as well.)
> The R blades are pretty solid, but you didn't specify any sort of config
> requirements.
> What will you be using the MSDPC for? (Last I checked redundancy config
> for those was disappointing, but I haven't used one in about a year and a
> half now.
> In the past, mixed mode wasn't recommended, but it doesn't seem to be a
> big deal now. (If you are considering buying MPCs at some point to use with
> the R blades.)
>
> Will
>
> On Wed, Jul 22, 2015 at 7:33 AM, Mark Tinka  wrote:
>
>>
>>
>> On 22/Jul/15 15:24, Colton Conor wrote:
>> >
>> >
>> >
>> > Besides the chassis size and power consumption anything we should know
>> or
>> > consider deciding between a MX 240, MX480, and MX960? It seems the
>> MX240 is
>> > too small for our needs, so its really the MX480 vs MX960.
>>
>> You take a bigger hit on the MX960 with a fabric failure if all slots
>> are full.
>>
>> Because the MX240 and MX480 have fewer slots, your exposure is more
>> limited in this regard.
>>
>> But I think with the new SCB-E's, this may no longer be an issue for the
>> MX960. Been a while since I checked as we are exclusively MX480 for the
>> time being.
>>
>> 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] MX480 Build

[Litterick, Jeff (BIT)]

Sent from my Windows Phone

From: Jerry Jones<mailto:jjo...@danrj.com>
Sent: ‎7/‎22/‎2015 8:38 AM
To: Colton Conor<mailto:colton.co...@gmail.com>
Cc: Juniper List<mailto:juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] MX480 Build

The RE-2000 and SCB have been announced EOL for next year.

On Jul 22, 2015, at 8:24 AM, Colton Conor  wrote:

I am considering buying a used MX480. It will have the following:



1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
power


2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
separately



1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
Release 9.3 and later





Assuming we have the latest software version from Juniper to install on
this used box, is there anything we should know about this potential setup?
I believe this DPC cards are EOL, but I think many people are still using
them. I know there are more dense MIC cards out there, but that is not
needed at this time.



I think everything about this system is redundant besides the MS-DPC, but I
could get another one of those too.



Are there any licensing restrictions or upgrade restrictions I should be
aware of? Does Juniper have any locks or software limitations on these
larger routers like they do on the MX-5 through MX-80 and MX 104?



Besides the chassis size and power consumption anything we should know or
consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
too small for our needs, so its really the MX480 vs MX960.


I would be upgrading from a MX80, so this is quite a jump.
___
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] MX480 Build

[Will O'Brien - NOAA Affiliate]

You didn't specify which REs you'd get with it. Make sure you are getting a
pair. (Even though the 960 uses three SCBs, you can only use two REs in
that chassis as well.)
The R blades are pretty solid, but you didn't specify any sort of config
requirements.
What will you be using the MSDPC for? (Last I checked redundancy config for
those was disappointing, but I haven't used one in about a year and a half
now.
In the past, mixed mode wasn't recommended, but it doesn't seem to be a big
deal now. (If you are considering buying MPCs at some point to use with the
R blades.)

Will

On Wed, Jul 22, 2015 at 7:33 AM, Mark Tinka  wrote:

>
>
> On 22/Jul/15 15:24, Colton Conor wrote:
> >
> >
> >
> > Besides the chassis size and power consumption anything we should know or
> > consider deciding between a MX 240, MX480, and MX960? It seems the MX240
> is
> > too small for our needs, so its really the MX480 vs MX960.
>
> You take a bigger hit on the MX960 with a fabric failure if all slots
> are full.
>
> Because the MX240 and MX480 have fewer slots, your exposure is more
> limited in this regard.
>
> But I think with the new SCB-E's, this may no longer be an issue for the
> MX960. Been a while since I checked as we are exclusively MX480 for the
> time being.
>
> 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] MX480 Build

[Jerry Jones]

The RE-2000 and SCB have been announced EOL for next year.

On Jul 22, 2015, at 8:24 AM, Colton Conor  wrote:

I am considering buying a used MX480. It will have the following:



1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
power


2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
separately



1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
Release 9.3 and later





Assuming we have the latest software version from Juniper to install on
this used box, is there anything we should know about this potential setup?
I believe this DPC cards are EOL, but I think many people are still using
them. I know there are more dense MIC cards out there, but that is not
needed at this time.



I think everything about this system is redundant besides the MS-DPC, but I
could get another one of those too.



Are there any licensing restrictions or upgrade restrictions I should be
aware of? Does Juniper have any locks or software limitations on these
larger routers like they do on the MX-5 through MX-80 and MX 104?



Besides the chassis size and power consumption anything we should know or
consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
too small for our needs, so its really the MX480 vs MX960.


I would be upgrading from a MX80, so this is quite a jump.
___
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] MX480 Build

[Mark Tinka]

On 22/Jul/15 15:24, Colton Conor wrote:
>
>
>
> Besides the chassis size and power consumption anything we should know or
> consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
> too small for our needs, so its really the MX480 vs MX960.

You take a bigger hit on the MX960 with a fabric failure if all slots
are full.

Because the MX240 and MX480 have fewer slots, your exposure is more
limited in this regard.

But I think with the new SCB-E's, this may no longer be an issue for the
MX960. Been a while since I checked as we are exclusively MX480 for the
time being.

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

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

Re: [j-nsp] MX480 Build

[Mark Tinka]

On 22/Jul/15 15:24, Colton Conor wrote:
>
>
>
> Besides the chassis size and power consumption anything we should know or
> consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
> too small for our needs, so its really the MX480 vs MX960.

You take a bigger on the MX960 with a fabric failure if all slots are full.

Because the MX240 and MX480 have fewer slots, your exposure is more
limited in this regard.

But I think with the new SCB-E's, this may no longer be an issue for the
MX960. Been a while since I checked as we are exclusively MX480 for the
time being.

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

[j-nsp] MX480 Build

[Colton Conor]

I am considering buying a used MX480. It will have the following:



1x MX480-PREMIUM-AC - MX480 Base system with redundant RE-2000, SCB, and AC
power


2x DPCE-R-4XGE-XFP - 4x10GE Enhanced DPC for MX, requires optics sold
separately



1 x Juniper MS-DPC - IP services line card for MX Series Requires Junos OS
Release 9.3 and later





Assuming we have the latest software version from Juniper to install on
this used box, is there anything we should know about this potential setup?
I believe this DPC cards are EOL, but I think many people are still using
them. I know there are more dense MIC cards out there, but that is not
needed at this time.



I think everything about this system is redundant besides the MS-DPC, but I
could get another one of those too.



Are there any licensing restrictions or upgrade restrictions I should be
aware of? Does Juniper have any locks or software limitations on these
larger routers like they do on the MX-5 through MX-80 and MX 104?



Besides the chassis size and power consumption anything we should know or
consider deciding between a MX 240, MX480, and MX960? It seems the MX240 is
too small for our needs, so its really the MX480 vs MX960.


I would be upgrading from a MX80, so this is quite a jump.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 SCB firmware issue

[Masood Ahmad Shah]

It could also be a hardware issue in either the referenced scb0 or back
connector. Have you tried the following:

Re-seat the scb in its slot, and then check for bent pins at this time (you
can use a flashlight)
Swap the scb0 with a spare (Or borrow one from another slot 1, 2)

Cheers,
Masood

On Tue, Dec 30, 2014 at 5:29 AM, Dave Peters - Terabit Systems <
d...@terabitsystems.com> wrote:

> Thanks a lot for the information.
>
> It's definitely an SCBE (not a 2), but I tried upgrading to a 13 version
> just in case. Same FPGA revision error, and same firmware dead end.
>
> I appreciate the help. If anyone else has any pointers, let me know.
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Tobias Heister
> Sent: Tuesday, December 23, 2014 2:54 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX480 SCB firmware issue
>
> Hi,
>
> Am 23.12.2014 um 23:23 schrieb Dave Peters - Terabit Systems:
> > 1 alarm currently active
> > Alarm time   Class  Description
> > 2014-12-23 21:50:13 UTC  Major  CB 0 FPGA Revision unsupported
> >
> > In looking over the Juniper documentation, there's a "request system
> firmware" command to update the SCB, but unfortunately, I'm not seeing that
> option (meaning "request system ?" doesn't reveal firmware as a
> possibility). I'm also not seeing any specific BIOS/firmware files in the
> download section of the Juniper MX Series portion of the Juniper website.
>
> It is a hidden command, so you have to manually complete it. After the
> firmware it starts to auto complete:
>
> > request system firmware ?
> > Possible completions:
> >   downgrade
> >   upgrade
>
> > request system firmware upgrade ?
> > Possible completions:
> >   fpc  Upgrade FPC ROM monitor
> >   pic  Upgrade PIC firmware
> >   vcpu Upgrade VCPU ROM monitor
>
> The output above is from an MX240 with SCB.
>
> I have never seen that error showing up but from what i have seen on
> similar situations the firmware should be embedded in junos and the
> firmware upgrade should just work without additional files. But SCB seems
> not to be a valid upgrade target on MX:
>
> > request system firmware upgrade scb
> > error: command is not valid on the mx480
>
> tested on MX480 with SCBE
>
> Would you by any chance have bought SCBE2 (they would probably not been
> available in used condition) instead of SCB. Just asking because SCBE2 is
> supported starting from 13.something and does not work in 12.3
>
> --
> Kind Regards
> Tobias Heister
> ___
> 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] MX480 SCB firmware issue

[Dave Peters - Terabit Systems]

Thanks a lot for the information.

It's definitely an SCBE (not a 2), but I tried upgrading to a 13 version just 
in case. Same FPGA revision error, and same firmware dead end. 

I appreciate the help. If anyone else has any pointers, let me know.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Tobias Heister
Sent: Tuesday, December 23, 2014 2:54 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX480 SCB firmware issue

Hi,

Am 23.12.2014 um 23:23 schrieb Dave Peters - Terabit Systems:
> 1 alarm currently active
> Alarm time   Class  Description
> 2014-12-23 21:50:13 UTC  Major  CB 0 FPGA Revision unsupported
>
> In looking over the Juniper documentation, there's a "request system 
> firmware" command to update the SCB, but unfortunately, I'm not seeing that 
> option (meaning "request system ?" doesn't reveal firmware as a possibility). 
> I'm also not seeing any specific BIOS/firmware files in the download section 
> of the Juniper MX Series portion of the Juniper website.

It is a hidden command, so you have to manually complete it. After the firmware 
it starts to auto complete:

> request system firmware ?
> Possible completions:
>   downgrade
>   upgrade

> request system firmware upgrade ?
> Possible completions:
>   fpc  Upgrade FPC ROM monitor
>   pic  Upgrade PIC firmware
>   vcpu Upgrade VCPU ROM monitor

The output above is from an MX240 with SCB.

I have never seen that error showing up but from what i have seen on similar 
situations the firmware should be embedded in junos and the firmware upgrade 
should just work without additional files. But SCB seems not to be a valid 
upgrade target on MX:

> request system firmware upgrade scb
> error: command is not valid on the mx480

tested on MX480 with SCBE

Would you by any chance have bought SCBE2 (they would probably not been 
available in used condition) instead of SCB. Just asking because SCBE2 is 
supported starting from 13.something and does not work in 12.3

--
Kind Regards
Tobias Heister
___
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] MX480 SCB firmware issue

[Tobias Heister]

Hi,

Am 23.12.2014 um 23:23 schrieb Dave Peters - Terabit Systems:

1 alarm currently active
Alarm time   Class  Description
2014-12-23 21:50:13 UTC  Major  CB 0 FPGA Revision unsupported

In looking over the Juniper documentation, there's a "request system firmware" command to 
update the SCB, but unfortunately, I'm not seeing that option (meaning "request system ?" 
doesn't reveal firmware as a possibility). I'm also not seeing any specific BIOS/firmware files in 
the download section of the Juniper MX Series portion of the Juniper website.


It is a hidden command, so you have to manually complete it. After the firmware 
it starts to auto complete:


request system firmware ?
Possible completions:
  downgrade
  upgrade



request system firmware upgrade ?
Possible completions:
  fpc  Upgrade FPC ROM monitor
  pic  Upgrade PIC firmware
  vcpu Upgrade VCPU ROM monitor


The output above is from an MX240 with SCB.

I have never seen that error showing up but from what i have seen on similar 
situations the firmware should be embedded in junos and the firmware upgrade 
should just work without additional files. But SCB seems not to be a valid 
upgrade target on MX:


request system firmware upgrade scb
error: command is not valid on the mx480


tested on MX480 with SCBE

Would you by any chance have bought SCBE2 (they would probably not been 
available in used condition) instead of SCB. Just asking because SCBE2 is 
supported starting from 13.something and does not work in 12.3

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

[j-nsp] MX480 SCB firmware issue

[Dave Peters - Terabit Systems]

Hi all--

Pardon my stupidity, but I'm getting the following error on a new (purchased 
used) SCB for an MX480 running the recommended software release (12.3R6.6):

1 alarm currently active
Alarm time   Class  Description
2014-12-23 21:50:13 UTC  Major  CB 0 FPGA Revision unsupported

In looking over the Juniper documentation, there's a "request system firmware" 
command to update the SCB, but unfortunately, I'm not seeing that option 
(meaning "request system ?" doesn't reveal firmware as a possibility). I'm also 
not seeing any specific BIOS/firmware files in the download section of the 
Juniper MX Series portion of the Juniper website.

Can anyone take pity on me and give me some pointers on how to update the 
firmware and clear that error?

As always, much appreciated.

--Dave Peters


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

Re: [j-nsp] MX480 BNG

[Nitzan Tzelniker]

Where is your PPPoE configuration (access dynamic-profiles ...  ) ?
May be you can start with this document
http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/subscriber-access/mpls/subscriber-management-mpls.pdf

Nitzan


On Mon, Jun 2, 2014 at 5:45 PM, Brijesh Patel  wrote:

> Hello Folks,
>
>
>
> I created multiple L2circuit over interface xe-0/0/0 MX480 and Alcatel SR
> 7750 . Status of l2circuts is UP. Attached configuration FYI pls.
>
>
>
> Now I am  trying to emulate PPoE connection over new circuit(VCID 1
> which is up) with using of N2X tester but session is not established.
>
>
>
> Any idea or How do I troubleshoot PPOE connection ?
>
>
>
> Many Thanks,
>
>
>
> Brijesh Patel
>
> ___
> 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] MX480 BNG

[Brijesh Patel]

Hello Folks,



I created multiple L2circuit over interface xe-0/0/0 MX480 and Alcatel SR
7750 . Status of l2circuts is UP. Attached configuration FYI pls.



Now I am  trying to emulate PPoE connection over new circuit(VCID 1
which is up) with using of N2X tester but session is not established.



Any idea or How do I troubleshoot PPOE connection ?



Many Thanks,



Brijesh Patel
y135912@Nevri-BNG-J480-01> show configuration interfaces xe-0/0/0.300
encapsulation vlan-ccc;
vlan-id 300;
input-vlan-map pop;
output-vlan-map push;
family ccc {
filter {
input ccc-filter;
}
}

{master}
y135912@Nevri-BNG-J480-01> show configuration protocols l2circuit neighbor 
172.130.124.11 interface xe-0/0/0.300
virtual-circuit-id 1;

{master}
y135912@Nevri-BNG-J480-01> show l2circuit connections interface xe-0/0/0.300
Layer-2 Circuit Connections:

Legend for connection status (St)
EI -- encapsulation invalid  NP -- interface h/w not present
MM -- mtu mismatch   Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch  Up -- operational
VM -- vlan id mismatch   CF -- Call admission control failure
OL -- no outgoing label  IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCCTM -- TDM misconfiguration
BK -- Backup Connection  ST -- Standby Connection
CB -- rcvd cell-bundle size bad  SP -- Static Pseudowire
LD -- local site signaled down   RS -- remote site standby
RD -- remote site signaled down  XX -- unknown

Legend for interface status
Up -- operational
Dn -- down
Neighbor: 172.130.124.11
Interface Type  St Time last up  # Up trans
xe-0/0/0.300(vc 1)rmt   Up Jun  2 11:50:22 2014   1
  Remote PE: 172.130.124.11, Negotiated control-word: No
  Incoming label: 304848, Outgoing label: 130781
  Negotiated PW status TLV: No
  Local interface: xe-0/0/0.300, Status: Up, Encapsulation: ETHERNET

{master}
y135912@Nevri-BNG-J480-01>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Per Westerlund]

The logic for what filters get applied is like this (stolen from Juniper 
documentation):

• If you configure Filter A on the default loopback interface (lo0.0) and 
Filter B on the VRF loopback interface (lo0.x), the VRF routing instance uses 
Filter B.
• If you configure Filter A on the default loopback interface but do not 
configure a filter on the VRF loopback interface, the VRF routing instance does 
not use a filter.
• If you configure Filter A on the default loopback interface but do not even 
configure a VRF loopback interface, the VRF routing instance uses Filter A.

/Per

1 feb 2014 kl. 08:16 skrev Misak Khachatryan :

> Does anybody know how lo0.0 filter affects to other loopbacks and routing 
> instances. To be more clear, i have lo0.0 as loopback for MPLS and internal 
> MBGP, and routing instance with lo0.1 where internet lives. Also i have lo0.2 
> for NGN BGP MVPN for PIM.
> 
> Should I write filters specific for each lo and routing instance unit or 
> lo0.0 is catch all for everything?

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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Mark Tinka]

On Saturday, February 01, 2014 10:24:30 AM Saku Ytti wrote:
> On (2014-02-01 11:16 +0400), Misak Khachatryan wrote:
> > Should I write filters specific for each lo and routing
> > instance unit or lo0.0 is catch all for everything?
> 
> I recommend applying same filter in each loopback.
> Security posture of VPN is mostly same as INET, except
> source address is not to be trusted (there may be INET
> behind customer VPN and you may not know how it's
> managed) Critically make sure you verify destination
> address in firewall filter especially for non-customer
> protocols like ssh, http, snmp, ntp, igp etc.

For my NG-MVPN setup, I had a group that covers filtering to 
lo0 and all units under it:

protect-re-group {
interfaces {
lo0 {
unit <*> {
family inet {
filter {
input protect-re;
}
}
family inet6 {
filter {
input protect-re6;
}
}
}
}
}

I then had a lo0.1 service instantiation unit which was 
applied to my NG-MVPN VRF. It was important to have 
appropriate filtering against this because for the NG-MVPN 
deployment, things like PIM, IGMP and DHCP are all part of 
the VRF, and those hit the router control plane, and as 
such, need adequate protection.

If you're also doing BGP in the VRF to handle the RPF route 
to the Multicast source, you need to have the appropriate 
filter enabled.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Saku Ytti]

On (2014-02-01 11:16 +0400), Misak Khachatryan wrote:

> Should I write filters specific for each lo and routing instance
> unit or lo0.0 is catch all for everything?

I recommend applying same filter in each loopback. Security posture of VPN is
mostly same as INET, except source address is not to be trusted (there may be
INET behind customer VPN and you may not know how it's managed)
Critically make sure you verify destination address in firewall filter
especially for non-customer protocols like ssh, http, snmp, ntp, igp etc.

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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Misak Khachatryan]

Does anybody know how lo0.0 filter affects to other loopbacks and 
routing instances. To be more clear, i have lo0.0 as loopback for MPLS 
and internal MBGP, and routing instance with lo0.1 where internet lives. 
Also i have lo0.2 for NGN BGP MVPN for PIM.


Should I write filters specific for each lo and routing instance unit or 
lo0.0 is catch all for everything?


joel jaeggli wrote:

On 1/30/14, 6:46 AM, Saku Ytti wrote:

On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:


Thanks Abhi, i saw this document, but i need real life experience
about hardening thresholds or implementing additional
filter/policers.


In my experience there is some build-in unconfigurable policer to limit how
many packets can hit control-plane.
Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
with control-plane CPU load in MX960 just few percentage, it should be dying,
the global policer is just making attackers job easier by essentially
downgrading CPU performance.

So it probably goes something like this

traffic => if-filter => lo-filter => ddos-policer =>
global-unconfigurable-policer

Stock limitation to most DDoS policers are 20kpps, which is more than enough
to bring MX960 to its knees

If your DDoS policer can see good and bad traffic, low limit will just make
attacking easier. It's mostly useful to catch things lo0 cannot reasonably
protect like HTTP rate (you'd need <=4Mbps policer to have accceptable pps),
BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
accidental errors causing flood of 'trusted/good' packets.
But in this case, you'd rather keep IGP and BGP rocking than multicast, so I'd
police all non-critical to under 4kpps in DoS policer. For for critical I'd
try to guarantee only good traffic passes lo0.


A good solid control-plane protection acl with sensible rate limits is a
good place to start.


Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
unique policer, making sure that one session attacking does not stop
non-attacking sessions from working.
Shorter term JunOS should add PPS policers in FW filters for proper lo0
filtering and configurable global policer (I'd just remove it personally).


iirc from arp-storm-land I set per interface policers at limits lower
than those for the global policers (which are poorly or undocumented
(and vary by release/platform)) but can of course be emperically
determined. the upshot of that was the interface melting before the
whole box did.









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



--
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Saku Ytti]

On (2014-01-31 17:51 +0200), Mark Tinka wrote:

> > traceroute.
> 
> I open up and limit Traceroute to udp/33434-33523. Haven't 
> had any issues thus far.

33434-33534 here, also no complains from customers.

And I fully agree BCP is to allow what you must, drop rest.

Things which you can police safely to <4Mbps use lo0+policer, things which you
cannot police safely use ddos-protectoin.
Configure ddos-protection with very small values.

Majority of my ddos are 100pps, with few stuff at 4kpps. Keep in mind that
good and bad share same ddos policer so don't make the cure worse than the
poison, flow-based ddos policers will likely be cure, but I've not tested them
yet.
Your ddos config will be very long, as you at least need to configure all non
IP policers (IP you can cover in lo0) and there is no way to say 'default 0pps
or 100pps' and only specifically configure those you want to allow for more.
'apply-flags omit' is your friend for standard configuration.

It's shame FW filters in Trio are still restricted to specific domain, there
is no HW reason why Lo0 filter couldn't protect you from non-IP attacks, using
L2 etype, dmac, smac as keys.

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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Mark Tinka]

On Friday, January 31, 2014 05:22:39 PM joel jaeggli wrote:

> traceroute.

I open up and limit Traceroute to udp/33434-33523. Haven't 
had any issues thus far.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

On 1/31/14, 7:08 AM, Chuck Anderson wrote:
> On Thu, Jan 30, 2014 at 10:58:05PM -0800, joel jaeggli wrote:
>> http://tools.ietf.org/search/rfc6192
>>
>> has an excellent example recipie for juniper and cisco control-plane
>> protection.
>>
>> it's a good starting off point and it covers the rational behind the
>> various elements in detail.
> 
>   "o  Permit all other IPv4 and IPv6 traffic that was not explicitly
>   matched in a class above, rate-limited to 500 kbps, and drop above
>   that rate for each category"
> 
> Why would one want a default-allow policy, even rate-limited, for the
> control-plane?

traceroute.

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




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Chuck Anderson]

On Thu, Jan 30, 2014 at 10:58:05PM -0800, joel jaeggli wrote:
> http://tools.ietf.org/search/rfc6192
> 
> has an excellent example recipie for juniper and cisco control-plane
> protection.
> 
> it's a good starting off point and it covers the rational behind the
> various elements in detail.

  "o  Permit all other IPv4 and IPv6 traffic that was not explicitly
  matched in a class above, rate-limited to 500 kbps, and drop above
  that rate for each category"

Why would one want a default-allow policy, even rate-limited, for the
control-plane?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Misak Khachatryan]

Thank You very much,

I've also googled these, look very useful:

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/

http://cyruslab.net/2012/12/16/juniper-networks-default-configuration-hardening/

http://forums.juniper.net/t5/Management/Juniper-Device-Hardening-amp-Best-Practices/td-p/125185


joel jaeggli wrote:

http://tools.ietf.org/search/rfc6192

has an excellent example recipie for juniper and cisco control-plane
protection.

it's a good starting off point and it covers the rational behind the
various elements in detail.

some things like my l2 policer were meant to solve invidualized needs
there are probably examples in the wild albiet I can probably also dig
one up.

On 1/30/14, 10:03 PM, Misak Khachatryan wrote:

Thanks Saku and Joel for detailed explanations,

Do You know any good resource to start with lo filters? Recommendations
about how much police several types of packets and so on. I don't want
to do much experiments on production network.

joel jaeggli wrote:

On 1/30/14, 6:46 AM, Saku Ytti wrote:

On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:


Thanks Abhi, i saw this document, but i need real life experience
about hardening thresholds or implementing additional
filter/policers.


In my experience there is some build-in unconfigurable policer to
limit how
many packets can hit control-plane.
Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy
camper,
with control-plane CPU load in MX960 just few percentage, it should
be dying,
the global policer is just making attackers job easier by essentially
downgrading CPU performance.

So it probably goes something like this

traffic => if-filter => lo-filter => ddos-policer =>
global-unconfigurable-policer

Stock limitation to most DDoS policers are 20kpps, which is more than
enough
to bring MX960 to its knees

If your DDoS policer can see good and bad traffic, low limit will
just make
attacking easier. It's mostly useful to catch things lo0 cannot
reasonably
protect like HTTP rate (you'd need <=4Mbps policer to have
accceptable pps),
BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
accidental errors causing flood of 'trusted/good' packets.
But in this case, you'd rather keep IGP and BGP rocking than
multicast, so I'd
police all non-critical to under 4kpps in DoS policer. For for
critical I'd
try to guarantee only good traffic passes lo0.


A good solid control-plane protection acl with sensible rate limits is a
good place to start.


Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
unique policer, making sure that one session attacking does not stop
non-attacking sessions from working.
Shorter term JunOS should add PPS policers in FW filters for proper lo0
filtering and configurable global policer (I'd just remove it
personally).


iirc from arp-storm-land I set per interface policers at limits lower
than those for the global policers (which are poorly or undocumented
(and vary by release/platform)) but can of course be emperically
determined. the upshot of that was the interface melting before the
whole box did.









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








--
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

http://tools.ietf.org/search/rfc6192

has an excellent example recipie for juniper and cisco control-plane
protection.

it's a good starting off point and it covers the rational behind the
various elements in detail.

some things like my l2 policer were meant to solve invidualized needs
there are probably examples in the wild albiet I can probably also dig
one up.

On 1/30/14, 10:03 PM, Misak Khachatryan wrote:
> Thanks Saku and Joel for detailed explanations,
> 
> Do You know any good resource to start with lo filters? Recommendations
> about how much police several types of packets and so on. I don't want
> to do much experiments on production network.
> 
> joel jaeggli wrote:
>> On 1/30/14, 6:46 AM, Saku Ytti wrote:
>>> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:
>>>
 Thanks Abhi, i saw this document, but i need real life experience
 about hardening thresholds or implementing additional
 filter/policers.
>>>
>>> In my experience there is some build-in unconfigurable policer to
>>> limit how
>>> many packets can hit control-plane.
>>> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy
>>> camper,
>>> with control-plane CPU load in MX960 just few percentage, it should
>>> be dying,
>>> the global policer is just making attackers job easier by essentially
>>> downgrading CPU performance.
>>>
>>> So it probably goes something like this
>>>
>>> traffic => if-filter => lo-filter => ddos-policer =>
>>> global-unconfigurable-policer
>>>
>>> Stock limitation to most DDoS policers are 20kpps, which is more than
>>> enough
>>> to bring MX960 to its knees
>>>
>>> If your DDoS policer can see good and bad traffic, low limit will
>>> just make
>>> attacking easier. It's mostly useful to catch things lo0 cannot
>>> reasonably
>>> protect like HTTP rate (you'd need <=4Mbps policer to have
>>> accceptable pps),
>>> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
>>> accidental errors causing flood of 'trusted/good' packets.
>>> But in this case, you'd rather keep IGP and BGP rocking than
>>> multicast, so I'd
>>> police all non-critical to under 4kpps in DoS policer. For for
>>> critical I'd
>>> try to guarantee only good traffic passes lo0.
>>
>> A good solid control-plane protection acl with sensible rate limits is a
>> good place to start.
>>
>>> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
>>> unique policer, making sure that one session attacking does not stop
>>> non-attacking sessions from working.
>>> Shorter term JunOS should add PPS policers in FW filters for proper lo0
>>> filtering and configurable global policer (I'd just remove it
>>> personally).
>>
>> iirc from arp-storm-land I set per interface policers at limits lower
>> than those for the global policers (which are poorly or undocumented
>> (and vary by release/platform)) but can of course be emperically
>> determined. the upshot of that was the interface melting before the
>> whole box did.
>>
>>>
>>>
>>
>>
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Misak Khachatryan]

Thanks Saku and Joel for detailed explanations,

Do You know any good resource to start with lo filters? Recommendations 
about how much police several types of packets and so on. I don't want 
to do much experiments on production network.


joel jaeggli wrote:

On 1/30/14, 6:46 AM, Saku Ytti wrote:

On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:


Thanks Abhi, i saw this document, but i need real life experience
about hardening thresholds or implementing additional
filter/policers.


In my experience there is some build-in unconfigurable policer to limit how
many packets can hit control-plane.
Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
with control-plane CPU load in MX960 just few percentage, it should be dying,
the global policer is just making attackers job easier by essentially
downgrading CPU performance.

So it probably goes something like this

traffic => if-filter => lo-filter => ddos-policer =>
global-unconfigurable-policer

Stock limitation to most DDoS policers are 20kpps, which is more than enough
to bring MX960 to its knees

If your DDoS policer can see good and bad traffic, low limit will just make
attacking easier. It's mostly useful to catch things lo0 cannot reasonably
protect like HTTP rate (you'd need <=4Mbps policer to have accceptable pps),
BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
accidental errors causing flood of 'trusted/good' packets.
But in this case, you'd rather keep IGP and BGP rocking than multicast, so I'd
police all non-critical to under 4kpps in DoS policer. For for critical I'd
try to guarantee only good traffic passes lo0.


A good solid control-plane protection acl with sensible rate limits is a
good place to start.


Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
unique policer, making sure that one session attacking does not stop
non-attacking sessions from working.
Shorter term JunOS should add PPS policers in FW filters for proper lo0
filtering and configurable global policer (I'd just remove it personally).


iirc from arp-storm-land I set per interface policers at limits lower
than those for the global policers (which are poorly or undocumented
(and vary by release/platform)) but can of course be emperically
determined. the upshot of that was the interface melting before the
whole box did.









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



--
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Saku Ytti]

On (2014-01-30 09:18 -0800), joel jaeggli wrote:

> A good solid control-plane protection acl with sensible rate limits is a
> good place to start.

Absolutely. But FW policers are only bps not pps (trio hw is fully pps capable
and microcode etc, just lacks CLI).
You want to give scp, http, bgp more bps than the platform can handle with
small packets. scp and http could be solved with FW policer supporting pps,
but bgp can't really be solved without per-flow logic.

> iirc from arp-storm-land I set per interface policers at limits lower
> than those for the global policers (which are poorly or undocumented
> (and vary by release/platform)) but can of course be emperically
> determined. the upshot of that was the interface melting before the
> whole box did.

In distributed boxes it's dimensioned so that RE can take what every LC CPU
could try to punt it at the same time, so it can never ever be oversubscribed,
but often the limits are for RE many generations back and thus way too
restrictive.
I guess it's good the limits are there, for boxes which won't be configured by
operator, only one FPC will fail at a time, but it also feels they unfairly
punish those operators who actually configure the boxes and then end up having
downtime in situation which RE could have handled given the chance.
In centralized boxes like MX80 and MX104 the limiting makes no sense in any
case. MX80 is dead on 4Mbps (Mbps, not MBps) attack, with RE CPU sitting <10%.

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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Saku Ytti]

On (2014-01-30 16:29 +), santiago martinez wrote:

> Hi Saku, agree with you, LPTS is doing a better job right now...
> If I'm not wrong or miss interpreting Juniper documentation, Junos ddos
> aready support per flow ddos (12.3 and later)

I haven't had chance to try out, as we've been on 11.4 until very recently.
It's definitely looking like good progress, particularly for BGP it's likely
only practical solution.

I'll try to find time to try it out soon, thanks.

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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

On 1/30/14, 6:46 AM, Saku Ytti wrote:
> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:
> 
>> Thanks Abhi, i saw this document, but i need real life experience
>> about hardening thresholds or implementing additional
>> filter/policers.
> 
> In my experience there is some build-in unconfigurable policer to limit how
> many packets can hit control-plane.
> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
> with control-plane CPU load in MX960 just few percentage, it should be dying,
> the global policer is just making attackers job easier by essentially
> downgrading CPU performance.
> 
> So it probably goes something like this
> 
> traffic => if-filter => lo-filter => ddos-policer =>
> global-unconfigurable-policer
> 
> Stock limitation to most DDoS policers are 20kpps, which is more than enough
> to bring MX960 to its knees
> 
> If your DDoS policer can see good and bad traffic, low limit will just make
> attacking easier. It's mostly useful to catch things lo0 cannot reasonably
> protect like HTTP rate (you'd need <=4Mbps policer to have accceptable pps),
> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
> accidental errors causing flood of 'trusted/good' packets.
> But in this case, you'd rather keep IGP and BGP rocking than multicast, so I'd
> police all non-critical to under 4kpps in DoS policer. For for critical I'd
> try to guarantee only good traffic passes lo0.

A good solid control-plane protection acl with sensible rate limits is a
good place to start.

> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
> unique policer, making sure that one session attacking does not stop
> non-attacking sessions from working.
> Shorter term JunOS should add PPS policers in FW filters for proper lo0
> filtering and configurable global policer (I'd just remove it personally).

iirc from arp-storm-land I set per interface policers at limits lower
than those for the global policers (which are poorly or undocumented
(and vary by release/platform)) but can of course be emperically
determined. the upshot of that was the interface melting before the
whole box did.

> 
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[santiago martinez]

Hi Saku, agree with you, LPTS is doing a better job right now...
If I'm not wrong or miss interpreting Juniper documentation, Junos ddos
aready support per flow ddos (12.3 and later)
Best regards
Santiago

url:
http://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/scfd-enable-globally.html

[edit system ddos-protection
global
]user@host# *set flow-detection
*


On Thu, Jan 30, 2014 at 2:46 PM, Saku Ytti  wrote:

> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:
>
> > Thanks Abhi, i saw this document, but i need real life experience
> > about hardening thresholds or implementing additional
> > filter/policers.
>
> In my experience there is some build-in unconfigurable policer to limit how
> many packets can hit control-plane.
> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
> with control-plane CPU load in MX960 just few percentage, it should be
> dying,
> the global policer is just making attackers job easier by essentially
> downgrading CPU performance.
>
> So it probably goes something like this
>
> traffic => if-filter => lo-filter => ddos-policer =>
> global-unconfigurable-policer
>
> Stock limitation to most DDoS policers are 20kpps, which is more than
> enough
> to bring MX960 to its knees
>
> If your DDoS policer can see good and bad traffic, low limit will just make
> attacking easier. It's mostly useful to catch things lo0 cannot reasonably
> protect like HTTP rate (you'd need <=4Mbps policer to have accceptable
> pps),
> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
> accidental errors causing flood of 'trusted/good' packets.
> But in this case, you'd rather keep IGP and BGP rocking than multicast, so
> I'd
> police all non-critical to under 4kpps in DoS policer. For for critical I'd
> try to guarantee only good traffic passes lo0.
>
> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
> unique policer, making sure that one session attacking does not stop
> non-attacking sessions from working.
> Shorter term JunOS should add PPS policers in FW filters for proper lo0
> filtering and configurable global policer (I'd just remove it personally).
>
>
>
> --
>   ++ytti
> ___
> 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] MX480 RE-S-2000 IGMP flood

[Saku Ytti]

On (2014-01-30 14:35 +0400), Misak Khachatryan wrote:

> Thanks Abhi, i saw this document, but i need real life experience
> about hardening thresholds or implementing additional
> filter/policers.

In my experience there is some build-in unconfigurable policer to limit how
many packets can hit control-plane.
Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy camper,
with control-plane CPU load in MX960 just few percentage, it should be dying,
the global policer is just making attackers job easier by essentially
downgrading CPU performance.

So it probably goes something like this

traffic => if-filter => lo-filter => ddos-policer =>
global-unconfigurable-policer

Stock limitation to most DDoS policers are 20kpps, which is more than enough
to bring MX960 to its knees

If your DDoS policer can see good and bad traffic, low limit will just make
attacking easier. It's mostly useful to catch things lo0 cannot reasonably
protect like HTTP rate (you'd need <=4Mbps policer to have accceptable pps),
BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix
accidental errors causing flood of 'trusted/good' packets.
But in this case, you'd rather keep IGP and BGP rocking than multicast, so I'd
police all non-critical to under 4kpps in DoS policer. For for critical I'd
try to guarantee only good traffic passes lo0.

Longer term, JunOS should adapt LPTS from IOS-XR, where each session has
unique policer, making sure that one session attacking does not stop
non-attacking sessions from working.
Shorter term JunOS should add PPS policers in FW filters for proper lo0
filtering and configurable global policer (I'd just remove it personally).



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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Misak Khachatryan]

Thanks Abhi, i saw this document, but i need real life experience about 
hardening thresholds or implementing additional filter/policers.


Abhi wrote:

can u check the link below

http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/subscriber-management-ddos-packet.html


regards
abhijeet.c


On Thursday, January 30, 2014 2:57 PM, Misak Khachatryan
 wrote:

Hello,

I met very ugly problem yesterday. Consider following scheme:


    Cisco ASR 1006
   |
Customer | Juniper EX4200 |
   |
    Juniper MX480

Customer connected by one VLAN to both routers and established BGP
session with both.

Suddenly his router starts to send around 1 packets per second.
Most
of them are exactly this:

"1","0.00","0.0.0.0","224.0.0.1","IGMPv3","60","Membership Query,
general"

MX480 is just dying from this flood of packets, where ASR is fine.

I know that several DDoS policies are preconfigured to protect RE from
these situations but tresholds didn't trigger, so RE should handle them:

show ddos-protection protocols igmp
Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 0
Currently tracked flows: 0, Total detected flows: 0
* = User configured value

Protocol Group: IGMP

   Packet type: aggregate (Aggregate for all igmp traffic)
 Aggregate policer configuration:
   Bandwidth:2 pps
   Burst:2 packets
   Recover time:300 seconds
   Enabled:  Yes
 Flow detection configuration:
   Detection mode: Automatic  Detect time:  3 seconds
   Log flows:  YesRecover time: 60 seconds
   Timeout flows:  NoTimeout time: 300 seconds
   Flow aggregation level configuration:
 Aggregation level  Detection mode  Control mode  Flow rate
 Subscriber  Automatic  Drop  10 pps
 Logical interface  Automatic  Drop  10 pps
 Physical interface  Automatic  Drop  2 pps
 System-wide information:
   Aggregate bandwidth is never violated
   Received:  7268549Arrival rate:0 pps
   Dropped:  0   Max arrival rate: 17204 pps
 Routing Engine information:
   Bandwidth: 2 pps, Burst: 2 packets, enabled
   Aggregate policer is never violated
   Received:  4270279Arrival rate:0 pps
   Dropped:  0  Max arrival rate: 9979 pps
 Dropped by individual policers: 0
 FPC slot 1 information:
   Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
   Aggregate policer is never violated
   Received:  1658Arrival rate:0 pps
   Dropped:  0 Max arrival rate: 2 pps
 Dropped by individual policers: 0
 Dropped by flow suppression:0
 FPC slot 2 information:
   Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
   Aggregate policer is never violated
   Received:  7266879Arrival rate:0 pps
   Dropped:  0  Max arrival rate: 17204 pps
 Dropped by individual policers: 0
 Dropped by flow suppression:0
 FPC slot 3 information:
   Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
   Aggregate policer is never violated
   Received:  12  Arrival rate:0 pps
   Dropped:  0  Max arrival rate: 0 pps
 Dropped by individual policers: 0
 Dropped by flow suppression:0

Anybody have experience with configuration of additional mechanisms?
Anybody nave recommendations for threshold tuning?

I'm gonna to open ticket in JTAC of course, but here i can get faster
answers. Thank You in advance.

--
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp




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

Re: [j-nsp] MX480 RE-S-2000 IGMP flood

[Abhi]

can u check the link below

http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/subscriber-management-ddos-packet.html

 

regards
abhijeet.c




On Thursday, January 30, 2014 2:57 PM, Misak Khachatryan  
wrote:
 
Hello,
>
>I met very ugly problem yesterday. Consider following scheme:
>
>
>                       Cisco ASR 1006
>                      |
>Customer | Juniper EX4200 |
>                      |
>                       Juniper MX480
>
>Customer connected by one VLAN to both routers and established BGP 
>session with both.
>
>Suddenly his router starts to send around 1 packets per second. Most 
>of them are exactly this:
>
>"1","0.00","0.0.0.0","224.0.0.1","IGMPv3","60","Membership Query, 
>general"
>
>MX480 is just dying from this flood of packets, where ASR is fine.
>
>I know that several DDoS policies are preconfigured to protect RE from 
>these situations but tresholds didn't trigger, so RE should handle them:
>
>show ddos-protection protocols igmp
>Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 0
>Currently tracked flows: 0, Total detected flows: 0
>* = User configured value
>
>Protocol Group: IGMP
>
>   Packet type: aggregate (Aggregate for all igmp traffic)
>     Aggregate policer configuration:
>       Bandwidth:        2 pps
>       Burst:            2 packets
>       Recover time:     300 seconds
>       Enabled:          Yes
>     Flow detection configuration:
>       Detection mode: Automatic  Detect time:  3 seconds
>       Log flows:      Yes        Recover time: 60 seconds
>       Timeout flows:  No         Timeout time: 300 seconds
>       Flow aggregation level configuration:
>         Aggregation level   Detection mode  Control mode  Flow rate
>         Subscriber          Automatic       Drop          10 pps
>         Logical interface   Automatic       Drop          10 pps
>         Physical interface  Automatic       Drop          2 pps
>     System-wide information:
>       Aggregate bandwidth is never violated
>       Received:  7268549             Arrival rate:     0 pps
>       Dropped:   0                   Max arrival rate: 17204 pps
>     Routing Engine information:
>       Bandwidth: 2 pps, Burst: 2 packets, enabled
>       Aggregate policer is never violated
>       Received:  4270279             Arrival rate:     0 pps
>       Dropped:   0                   Max arrival rate: 9979 pps
>         Dropped by individual policers: 0
>     FPC slot 1 information:
>       Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
>       Aggregate policer is never violated
>       Received:  1658                Arrival rate:     0 pps
>       Dropped:   0                   Max arrival rate: 2 pps
>         Dropped by individual policers: 0
>         Dropped by flow suppression:    0
>     FPC slot 2 information:
>       Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
>       Aggregate policer is never violated
>       Received:  7266879             Arrival rate:     0 pps
>       Dropped:   0                   Max arrival rate: 17204 pps
>         Dropped by individual policers: 0
>         Dropped by flow suppression:    0
>     FPC slot 3 information:
>       Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
>       Aggregate policer is never violated
>       Received:  12                  Arrival rate:     0 pps
>       Dropped:   0                   Max arrival rate: 0 pps
>         Dropped by individual policers: 0
>         Dropped by flow suppression:    0
>
>Anybody have experience with configuration of additional mechanisms? 
>Anybody nave recommendations for threshold tuning?
>
>I'm gonna to open ticket in JTAC of course, but here i can get faster 
>answers. Thank You in advance.
>
>-- 
>Best regards,
>Misak Khachatryan,
>Head of Network Administration
>and Monitoring Department,
>GNC-Alfa CJSC.
>___
>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] MX480 RE-S-2000 IGMP flood

[Misak Khachatryan]

Hello,

I met very ugly problem yesterday. Consider following scheme:


  Cisco ASR 1006
 |
Customer | Juniper EX4200 |
 |
  Juniper MX480

Customer connected by one VLAN to both routers and established BGP 
session with both.


Suddenly his router starts to send around 1 packets per second. Most 
of them are exactly this:


"1","0.00","0.0.0.0","224.0.0.1","IGMPv3","60","Membership Query, 
general"


MX480 is just dying from this flood of packets, where ASR is fine.

I know that several DDoS policies are preconfigured to protect RE from 
these situations but tresholds didn't trigger, so RE should handle them:


show ddos-protection protocols igmp
Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 0
Currently tracked flows: 0, Total detected flows: 0
* = User configured value

Protocol Group: IGMP

  Packet type: aggregate (Aggregate for all igmp traffic)
Aggregate policer configuration:
  Bandwidth:2 pps
  Burst:2 packets
  Recover time: 300 seconds
  Enabled:  Yes
Flow detection configuration:
  Detection mode: Automatic  Detect time:  3 seconds
  Log flows:  YesRecover time: 60 seconds
  Timeout flows:  No Timeout time: 300 seconds
  Flow aggregation level configuration:
Aggregation level   Detection mode  Control mode  Flow rate
Subscriber  Automatic   Drop  10 pps
Logical interface   Automatic   Drop  10 pps
Physical interface  Automatic   Drop  2 pps
System-wide information:
  Aggregate bandwidth is never violated
  Received:  7268549 Arrival rate: 0 pps
  Dropped:   0   Max arrival rate: 17204 pps
Routing Engine information:
  Bandwidth: 2 pps, Burst: 2 packets, enabled
  Aggregate policer is never violated
  Received:  4270279 Arrival rate: 0 pps
  Dropped:   0   Max arrival rate: 9979 pps
Dropped by individual policers: 0
FPC slot 1 information:
  Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
  Aggregate policer is never violated
  Received:  1658Arrival rate: 0 pps
  Dropped:   0   Max arrival rate: 2 pps
Dropped by individual policers: 0
Dropped by flow suppression:0
FPC slot 2 information:
  Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
  Aggregate policer is never violated
  Received:  7266879 Arrival rate: 0 pps
  Dropped:   0   Max arrival rate: 17204 pps
Dropped by individual policers: 0
Dropped by flow suppression:0
FPC slot 3 information:
  Bandwidth: 100% (2 pps), Burst: 100% (2 packets), enabled
  Aggregate policer is never violated
  Received:  12  Arrival rate: 0 pps
  Dropped:   0   Max arrival rate: 0 pps
Dropped by individual policers: 0
Dropped by flow suppression:0

Anybody have experience with configuration of additional mechanisms? 
Anybody nave recommendations for threshold tuning?


I'm gonna to open ticket in JTAC of course, but here i can get faster 
answers. Thank You in advance.


--
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480 - 10.4R4.5 BGP

[David Miller]

On 1/16/2013 10:11 PM, Brandon Ross wrote:
> On Wed, 16 Jan 2013, Keith wrote:
> 
>> Peer #1 - all 4 networks are prepended with our AS 5 times:
> 
> Okay so far...
> 
>> This way I have two networks coming in on one gig link and the other two
>> networks are coming in over the other gig link.
> 
> No, you don't.  You have all 4 networks coming in on all 4 links.
> 
>> There should be no traffic incoming in on Peer #1 from the internet.
>> But there is.
> 
> Not quite.  You have advertised a route to another AS.  Each AS will use
> it's own criteria to decide how to route traffic.  For example, most
> service providers will prefer to send traffic to their customers' direct
> connections instead of sending that traffic to an intermediate AS.  That
> preference is usually implemented using localpref which is a decision
> made by routers before AS path length, just like you are doing to choose
> how to send traffic out of your network.
> 
> The only way to ensure that NO traffic comes in on that link is to
> advertise NO routes at all.
> 
> You can, however, influence traffic in a stronger way by advertising
> more specific routes (since more specific routes are always preferred)
> on links that you want to carry traffic.

You may also be able to set BGP communities on your announcements to
Peer1 to control their handling of your prefixes.

http://bgp.he.net/AS13768#_irr

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

Re: [j-nsp] MX480 - 10.4R4.5 BGP

[Brandon Ross]

On Wed, 16 Jan 2013, Keith wrote:


Peer #1 - all 4 networks are prepended with our AS 5 times:


Okay so far...


This way I have two networks coming in on one gig link and the other two
networks are coming in over the other gig link.


No, you don't.  You have all 4 networks coming in on all 4 links.

There should be no traffic incoming in on Peer #1 from the internet. But 
there is.


Not quite.  You have advertised a route to another AS.  Each AS will use 
it's own criteria to decide how to route traffic.  For example, most 
service providers will prefer to send traffic to their customers' direct 
connections instead of sending that traffic to an intermediate AS.  That 
preference is usually implemented using localpref which is a decision made 
by routers before AS path length, just like you are doing to choose how to 
send traffic out of your network.


The only way to ensure that NO traffic comes in on that link is to 
advertise NO routes at all.


You can, however, influence traffic in a stronger way by advertising more 
specific routes (since more specific routes are always preferred) on links 
that you want to carry traffic.


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp