[j-nsp] GRE Keepalive on M10/M20

[Alireza Soltanian]

Hi Everybody
We have several M10/M20 with PE-Tunnel pics. I wonder how can I enable GRE
keepalive for GRE tunnels?
We also have M320 with PC-Tunnel pics. GRE keepalive works fine with GRE
tunnels on this PIC of M320 but for M10/M20 the related command was not
shown. Anyway When I configure it the command is accepted but GRE Keepalive
functionality does not work and I have an error about LFI interface
I searched the Internet but could not find anything. I must mention We use
JunOS 9 to 11 on these M10/M20

Thank you for your help and support...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Where to find install media for EOL hardware platforms and Junos releases?

[Martin T]

I got the install-media-7.4R1.7-domestic installation image from a
user in this mailing list and then upgraded to Junos 8.5R4.3 with
jinstall-8.5R4.3-domestic-signed install package.


thanks,
Martin

On 9/23/15, Martin T  wrote:
> This did cross my mind, but those routers are in remote locations and
> this would require fairly long maintenance window. I hope that someone
> either has the install-media-8.5R4.3-domestic image or there is a way
> to build disk-image from jinstall-8.5R4.3-domestic-signed.tgz which I
> have. I guess an older install-image would work as well and then I
> could upgrade to 8.5R4.3 with jinstall-8.5R4.3-domestic-signed.tgz.
>
>
> Martin
>
> On 9/23/15, Dave Bell  wrote:
>> Not the best solution, but have you thought about taking your live
>> routers down for maintenance, and dd'ing the contents of the CF onto
>> another card?
>>
>> Regards,
>> Dave
>>
>> On 23 September 2015 at 13:10, Martin T  wrote:
>>> Or maybe someone has install-media-8.5R4.3-domestic image on some old
>>> tape-drive and is willing to share it? :)
>>>
>>>
>>> thanks,
>>> Martin
>>>
>>> On 9/21/15, Martin T  wrote:
 Hi,

 I have one RE-600-2048(256MB CF and 40GB HDD) and one RE-333-768(256MB
 CF and 40GB HDD) routing engine. Both are with blank CF and HDD. I
 would like to install Junos 8.5R4.3 on those routing engines and use
 those as spares for some old routers with the same routing-engines and
 software, but I cant find the install media for such legacy software
 release. Oldest one available from Juniper web site for M series seems
 to be 12.3R1.7(install-media-12.3R1.7-domestic), but I need
 install-media-8.5R4.3-domestic. Is there a way to download EOL Junos
 releases from Juniper web-site? Or is there a way to build
 install-image from jinstall
 tarball(jinstall-8.5R4.3-domestic-signed.tgz)?


 thanks,
 Martin

>>> ___
>>> 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] Junos load balancing question

[Adam Vitkovsky]

Hello Peter,

Interesting question,
You should be able to check yourself what the hashing looks like in HW.

Try: show forwarding-options enhanced-hash-key - works on EX/QFX
If the above cmd is not available then maybe: - works on MX
start shell pfe network fpc
show jnh lb

I think the RE traffic would be hashed based on its characteristics (e.g. each 
BGP session is basically a TCP flow) according to the loadbalancing settings on 
the box.
But now that I think about it, especially if the bundle spans across multiple 
Line Cards ,you'd have to start the shell on RE and check the LB settings there.
Hmm but the exception to this would be CP traffic that is offloaded to LCs, 
like BFD or VRRP for instance ,cause that type of traffic originates from a 
particular LC so the hashing between bundle members would be done on the egress 
LC I guess, if hashing would be in place at all in this case.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

Re: [j-nsp] upgrading a ex4550 VC to 15R1.8 using non-stop-upgrade

[Simone Spinelli]

Thank you Peter,

now it's clear: we shouldn't have done it ... :)
But we need that release to support some non-juniper optics.
As soon as we have new hardware we will test a step-by-step upgrade.

Best Regards
Simone

On Wed, Sep 23, 2015 at 11:11 PM, Peter Tavenier 
wrote:

> > On 23 Sep 2015, at 14:48, Simone Spinelli 
> wrote:
> >
> > Hi all,
> >
> > few days ago we upgraded a 6 members VC of ex4550 from 12.3R6 to 15R1.8.
> > using nssu precedure.
> > We have linjux boxes connected with LACP on different member.
> > We checked all the requirement listed on:
> >
> http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/installation/ex-series-software-upgrading-nssu-fixed-virtual-chassis-cli.html
> >
> > After we started the upgrade , all the LACP links  went down (one by one
> > depending on the upgraded member), even if linecards were up and running
> > and connected to the VC.
> > In the end, everything went back to normal when the master RE came up.
> > Actually a member was still stuck with all the LACP ports in "detached"
> > state: after a manual reboot, it went ok.
> >
> > Did anybody have a similar issue?
> > Any suggestion for investigation?
>
> Hi Simone,
>
> If you see
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/ex-series-nssu-support-tables.html#ex4200-4500-vc
> and then the PR1030508 you see there were some issue’s with this 12.3R6
> release, so not sure if you hit that.
>
> However even if you don’t use NSSU I think this upgrade path (did you
> upgrade directly to 15R1.8?) is not supported[1]
>
> "Support for upgrades and downgrades that span more than three Junos OS
> releases at a time is not provided, except for releases that are designated
> as Extended End-of-Life (EEOL) releases.”
> and
> "You can upgrade or downgrade to the EEOL release that occurs directly
> before or after the currently installed EEOL release, or to two EEOL
> releases earlier or later.”
>
> - JunOS 12.3 is an Extended End of Life (EEOL) Release[2]
> - JunOS 13.3 and 14.1 are also EEOL.
> So you could upgrade form 12.3 to 14.1 (I’m not sure if ISSU is supported
> in this path as well).
>
> [1]
> http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1/topic-83365.html#rn-junos-ex-migration-upgrade-downgrade
> [2] http://www.juniper.net/support/eol/junos.html
>
> --
> Peter
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

[Mark Tinka]

On 24/Sep/15 15:18, Adam Vitkovsky wrote:

> I’d like to ask what do you think about the new JTAC recommended release 
> 13.3R6 for MX960 please? Any hidden gotchas?

Never tried it. We're on 14.2 on our MX's.

No major drama.

>
> Do you folks rely on the JTAC recommendations or you just go with any code 
> that best suits your needs based on the inhouse testing please?

The latter.

>
> Also I'm wondering what does it mean out of support, since Juniper didn't 
> give any of us enough time to properly test and then upgrade all the devices 
> to a new code I'm just wondering if I get the "upgrade the code" every time I 
> log a JTAC next year?

It means Juniper could have found some catastrophic issue that has been
fixed in a new release, and would warn you against the previous one.

You likely won't be warned each time you open a case, though.

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

Re: [j-nsp] Policing On LAG's - Update!

[Mark Tinka]

Hi all.

So for the archives - this issue turned out to be a bug. Juniper have
filed it under:

PR1098486

"The "shared-bandwidth-policer" knob is used to enable
configuration of interface-specific policers applied on an
aggregated Ethernet bundle to match the effective bandwidth and
burst-size to user-configured values. But this feature is
broken from Junos release 14.1R1 when "enhanced-ip" is
configured on MX platform with pure trio-based line cards. The
bandwidth/burst-size of policers attached to Aggregated
Ethernet interfaces are not dynamically updated upon member
link adding or deletion."

The issue is resolved in Junos 14.2R4 and 15.1R2.

We have tested 14.2R4.9 and confirm that the issue is, indeed, resolved.

If you can't upgrade to from 14.1 through to anything pre-14.2R4, the
workaround is to delete, commit, re-apply and commit the srTCM firewall
policers.

In case you are using trTCM policers, I found that the above workaround
doesn't work - your only option is to delete the policer at the
interface level, commit, re-apply and commit again.

The problem with the workaround is that if one of your MPC's that has a
port in the LAG was to ever restart (for whatever reason), you could end
up seeing this issue again, and would need to re-apply the workarounds.

Hope this helps anyone else out there that could be facing this issue.

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

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

[Olivier Benghozi]

Not hit by PR1101080 (When polling SNMP OID isisPacketCounterTable 
1.3.6.1.2.1.138.1.5.3, the rpd process might crash) ?

> Le 24 sept. 2015 à 15:42, Mark Tinka  a écrit :
> 
> 
> 
> On 24/Sep/15 15:36, Adam Vitkovsky wrote:
> 
>> I suspect you are using the new MPCs right?
> 
> Yes, we're on the MPC's.
> 
>> May I ask why did you go for 14.2 rather than 14.1R4 then please? Was it 
>> bugs or features driven?
> 
> We started with 14.1 in June of last year.
> 
> I requested a feature from Juniper which shipped in 14.2.
> 
> Everything works; we haven't had any issues with any of the features we use.
> 
> Mark.

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

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

[Mark Tinka]

On 24/Sep/15 15:36, Adam Vitkovsky wrote:

> I suspect you are using the new MPCs right?

Yes, we're on the MPC's.

> May I ask why did you go for 14.2 rather than 14.1R4 then please? Was it bugs 
> or features driven?

We started with 14.1 in June of last year.

I requested a feature from Juniper which shipped in 14.2.

Everything works; we haven't had any issues with any of the features we use.

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

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

[Mark Tinka]

On 24/Sep/15 15:48, Olivier Benghozi wrote:

> Not hit by PR1101080 (When polling SNMP OID isisPacketCounterTable 
> 1.3.6.1.2.1.138.1.5.3, the rpd process might crash) ?

Admittedly, we aren't polling that OID.

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

[j-nsp] JTAC recommended release 13.3R6 for MX960

[Adam Vitkovsky]

Hi Folks,

I’d like to ask what do you think about the new JTAC recommended release 13.3R6 
for MX960 please? Any hidden gotchas?

Do you folks rely on the JTAC recommendations or you just go with any code that 
best suits your needs based on the inhouse testing please?

Also I'm wondering what does it mean out of support, since Juniper didn't give 
any of us enough time to properly test and then upgrade all the devices to a 
new code I'm just wondering if I get the "upgrade the code" every time I log a 
JTAC next year?

Thank you very much

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

Re: [j-nsp] JTAC recommended release 13.3R6 for MX960

[Adam Vitkovsky]

Hi Mark,
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Thursday, September 24, 2015 2:26 PM
>
> On 24/Sep/15 15:18, Adam Vitkovsky wrote:
>
> > I’d like to ask what do you think about the new JTAC recommended release
> 13.3R6 for MX960 please? Any hidden gotchas?
>
> Never tried it. We're on 14.2 on our MX's.
>
> No major drama.

I suspect you are using the new MPCs right?
May I ask why did you go for 14.2 rather than 14.1R4 then please? Was it bugs 
or features driven?

Thank you very much

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

[j-nsp] 14.2 trio flexible firewall matching?

[Michael Hare]

I'm wondering if anyone on list has tried this or gotten decent caveat 
information on this feature.  I intend to lab it but haven't gotten around to 
it yet.

http://www.juniper.net/documentation/en_US/junos14.2/topics/concept/firewall-filter-flexible-match-conditions-overview.html

Some things I wanted to explore;
* Matching ethernet dst addr bit 8 to count/police ethernet multicast
* Poor man's DNS reflection firewall (counting/policing DNS ANY attempts, aka 
fkfkfkfz.guru lookups) 

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

Re: [j-nsp] GRE Keepalive on M10/M20

[Alireza Soltanian]

Does Anybody have any suggestion?
On 24 Sep 2015 12:14, "Alireza Soltanian"  wrote:

> Hi Everybody
> We have several M10/M20 with PE-Tunnel pics. I wonder how can I enable GRE
> keepalive for GRE tunnels?
> We also have M320 with PC-Tunnel pics. GRE keepalive works fine with GRE
> tunnels on this PIC of M320 but for M10/M20 the related command was not
> shown. Anyway When I configure it the command is accepted but GRE Keepalive
> functionality does not work and I have an error about LFI interface
> I searched the Internet but could not find anything. I must mention We use
> JunOS 9 to 11 on these M10/M20
>
> Thank you for your help and support...
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] HDD requirements for RE-333 and RE-600

[Martin T]

Hi,

I have a RE-333 and RE-600 both with Fujitsu MHT2030AT HDDs. It is a
30GB, 4200rpm PATA HDD in slave mode:

root> show system boot-messages | match ad1
ad1: 28615MB  at ata0-slave UDMA33

root>

Now if I replace this HDD with Hitachi HTS541680J9AT00 80GB, 5400rpm
PATA HDD in slave mode, then both RE-333 and RE-600 even do not pass
the POST. RE does not seem to boot at all. According to specs, Hitachi
drive requires 5.0W at startup(maximum peak) while Fujitsu requires
4.5W at startup. Is it possible that RE is not able to provide more
than 4.5W(900mA at 5V) to HDD? Or does BIOS of RE-333 and RE-600
accept only certain HDD models?


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