Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204

[Paul Stewart]

Wow that does suck … have used those alarm OID’s for a very long time with 
Juniper boxes …. 

> On Feb 28, 2019, at 3:27 PM, Simon Lockhart  wrote:
> 
> On Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
>> These don't work on the 204?
>> 
>> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
>> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
> 
> They don't seem to exist on either MX10003 or MX204...
> 
> $ snmpwalk -v 2c -c xxx mx10003 .1.3.6.1.4.1.2636.3.4
> iso.3.6.1.4.1.2636.3.4 = No Such Object available on this agent at this OID
> 
> $ snmpwalk -v 2c -c xxx mx204 .1.3.6.1.4.1.2636.3.4
> iso.3.6.1.4.1.2636.3.4 = No Such Object available on this agent at this OID
> 
> Simon
> ___
> 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] JNCIE-SP question

[Paul Stewart]

I think it varies with your job experience … if you are already working on 
complex MPLS networks for example then that’s a lot different from only having 
labs and less actual experience.

I spent a week preparing for JNCIA-JUNOS as already, at that time had some 
experience.  For JNCIS-SP I took some classroom courses and at the end of all 
them I wrote on the Friday afternoon (each evening of the course I studied 3-4 
hours however). JNCIP-SP etc… 

I’m not remotely suggesting that writing these exams is easy .. simply put, 
they are not.  In my situation I was very fortunate to have a lot of hands on 
experience combined with classroom training that in my opinion was well done.

Just my two cents worth …. 

Paul


On 2017-12-11, 11:06 AM, "juniper-nsp on behalf of Shamen Snyder" 
 
wrote:

I spent 2 hours a day reading and 8 hours of lab (sometimes more) on
weekends for about a year and a half. All that time I put into it paid off
as I passed on my first attempt. With that being said I paid out of pocket
for everything and really didn't want to waste the money on a failed
attempt.





On Mon, Dec 11, 2017 at 10:39 AM, Aaron Gould  wrote:

> I accomplished JNCIP-SP last week, and have a question for the JNCIE-SP
> folks out there.  To those of you who have done the SP track, how much
> time/effort do you recommend needs to go into preparing for JNCIE-SP ?
>
>
>
> My progression has been.
>
>
>
> ~3 months of study/prep - JNCIA-JUNOS
>
> ~6 months of study/prep - JNCIS-SP
>
> ~9 months of study/prep - JNCIP-SP
>
>
>
> .so how much more time/preparation will go into my preparing for a
> legitimate attempt at the JNCIE-SP lab ?
>
>
>
> -Aaron
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



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

Re: [j-nsp] Zabbix

[Paul Stewart]

How do you like Zabbix and what else do you monitor with it?  We are in midst 
of considering it (along with others) to replace Solarwinds….

Thanks,
Paul

> On Aug 18, 2017, at 2:04 AM, Matthew Taylor  wrote:
> 
> Hi,
> 
> Heavily use Zabbix with Juniper EX/MX and SRX devices.
> 
> Most of our templates are customised, although you can find a lot from Zabbix 
> Share.
> 
> https://share.zabbix.com/search?searchword=Juniper&search_cat=1
> 
> Cheers,
> Matt.
> 
> On 18/8/17 15:25, jayshankar nair via juniper-nsp wrote:
>> Hi,I am currently using zabbix(www.zabbix.com) for monitoring of routers. 
>> Has anybody on this forum use zabbix. In zabbix there is a concept called 
>> template for integration of mibs.
>> Please advise.
>> 
>> Thanks,Jayshankar
>> ___
>> 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] exam fees

[Paul Stewart]

Did know they had gone up .. but one thing that might help is with your next 
Juniper purchase, ask if they can provide you some JTC’s (which can be used for 
vouchers).  This depends on your relationship with Juniper and volume of orders 
of course :)


> On Jan 12, 2017, at 11:16 AM, Valentini, Lucio  
> wrote:
> 
> Hi there,
> 
> Has anyone noticed how much more an exam costs in comparison to last year? 
> 300 US$ is really a lot for an exam, what do you think ?
> 
> Is there a way to get a sponsor?
> 
> Thanks 
> 
> Cheers
> 
> Lucio
> ___
> 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] EX2200C-12-2G refusing to power up

[Paul Stewart]

Only ever seen one of them fail ever… typically quite dependable - the one that 
I had fail was a flash issue so it would power up and then crap out

This sounds like a power supply issue or something along those lines especially 
if you’re getting no lights or anything - suggest contacting Juniper to see if 
they can RMA it for you

Thanks,
Paul


> On Oct 3, 2016, at 10:26 AM, Valentini, Lucio  wrote:
> 
> Hi all,
> 
> today I tried to power up an EX2200C on my desk, after I had switched it off  
> through the CLI last week.
> But it wouldn´t power up. None of the LEDs lit up. I changed the cables and 
> the power slot, but the result is the same. What can have been to cause ? an 
> ESD? But how? I´m sure it never feel on the ground. It has been on my desktop 
> PC for a couple of months and it always worked fine until today.
> Any ideas?
> 
> Thanks
> 
> Lucio
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC

[Paul Stewart]

It’s a default setting … has to be in the configuration but suggest setting it 
to the appropriate option … in my case it’s typically enhanced-ip but that 
varies depending on your needs

http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/network-services-mode-overview.html
 


Please note that changing this requires a reboot in most situations

Paul


> On Jul 13, 2016, at 2:58 PM, Aaron  wrote:
> 
> My MX104's for my CGNat project just arrived and we've staged them in the
> network. I was turning them up and am seeing a certain command that I don't
> recall typing.. What is this for, and why do I need it ?
> 
> 
> 
> agould@blcn-h-104> show configuration | display set | grep "chassis net"
> 
> set chassis network-services all-ethernet
> 
> agould@blcn-h-104# set chassis network-services ?
> Possible completions:
>  enhanced-ethernetEnhanced ethernet network services
>  enhanced-ip  Enhanced IP network services
>  ethernet Ethernet network services
>  ip   IP network services
> [edit]
> agould@blcn-h-104# exit
> 
> 
> 
> - Aaron
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Juniper hardware purchasing and delivery time

[Paul Stewart]

It can depend on a few factors and what the partner's arrangement is with 
Juniper.

Depending on the partner's arrangement also determines where they have to 
acquire the equipment from (ie. Distribution or from Juniper directly).

The timeline you mention isn't entirely out of line.  Sometimes the delays are 
also with the reseller themselves and internal processes.

My experience has been typically a month for Juniper MX but for SRX/QFX stuff 
it's usually a week.   This is assuming that certain warehouses involved has 
stock - if not then SRX/QFX can take several weeks.  That was when I worked for 
a partner.

Now I'm on the other side of the table and the current partner we buy from 
takes a month just to process the paperwork internally ... very painful ... 

Paul


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
james list
Sent: Friday, June 26, 2015 3:00 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper hardware purchasing and delivery time

I did an agreement with a Juniper partner to buy some hardware (MX, SRX and
QFX) and it tooks 45 solar days to deliver the production boxes and 4 months 
for the spare (for maintenance) boxes (the spares remain in the partner 
warehouse…).


I’m wondering if on the Juniper partner side there are two different ways to 
order the devices with different SLA on the delivery time on Juniper side.


Any partner could switch on the light ?


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

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

Re: [j-nsp] MX80 upgrade caveats

[Paul Stewart]

Officially I think the answer is never upgrade more than three releases at
once .. I've cheated it and got away with it - also got burnt

So, 11.4 to 12.1 to 12.2 to 12.3 etc.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
thiyagarajan b
Sent: Thursday, May 7, 2015 1:49 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX80 upgrade caveats

Hi,  Any constraints for upgrading jmx80 from 11.4 to 14.1 directly?

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

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

Re: [j-nsp] Buying a used Juniper

[Paul Stewart]

What I've seen with this is that you pay for one year of "core support" and
then also take out "next day support" (or whatever level you wish) going
forward.  The one year of core support is basically to "certify" the
equipment and be able to get support in future.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Aaron Dewell
Sent: Tuesday, May 5, 2015 1:04 PM
To: Raphael Mazelier
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Buying a used Juniper


I looked into this once.  Support involves a one-time purchase of a
contract, back-dated to when it was last under contract.  Depending on how
long ago that was, it may be prohibitive as well.

On May 5, 2015, at 11:00 AM, Raphael Mazelier  wrote:
> 
> Le 05/05/15 18:47, Colton Conor a écrit :
>> What are the limitations of buying a used Juniper MX router? I assume 
>> there will be no JTAC support, but what would it take to licenses a 
>> used router to get JTAC support?
> 
> I don't know if juniper allow this, but if yes I think the price will 
> be prohibitive :)
> 
>> Does JTAC offer a one time support call fee for unlicensed routers?
>> 
> 
> I don't think so. And why Juniper will make this ? Juniper (as well as
other network vendor) don't like grey market.
> 
>> 
>> The router in question would be a MX480. Used, we can get them for under
>> 20K with redundant everything and 4 10G ports. New from Juniper I don't
>> even want to know what these would cost.
> 
> Lets try it. Juniper can make aggressive price :)
> 
> 
> -- 
> Raphael Mazelier
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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

[j-nsp] BGP Multipath Limits

[Paul Stewart]

According to
http://www.juniper.net/documentation/en_US/junos14.1/topics/topic-map/bgp-mu
ltipath.html

 

ECMP can be upgraded to 64 paths.  I'm looking to run BGP multipath across
up to 64 links for a production project on MX480's.

 

Anyone actually done this many paths in real world?  This is eBGP neighbor
relationship with equal costs on all paths.

 

Thanks,

Paul

 

 

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

Re: [j-nsp] Question about 100 Gbps MPC4E

[Paul Stewart]

Thanks – I’m really not sure to be honest … just seen some weird bugs with LAG 
over the years and thought it might be worthwhile to eliminate for testing 
purposes.  This way you at least have one less thing to consider as the source 
of the issue.

 

I haven’t seen anything like this in 13.3R2 but just getting involved with my 
first MPC4E 100G port deployments this week so was kind of curious….

 

Cheers,

Paul

 

 

From: Giuliano Medalha [mailto:giuli...@wztech.com.br] 
Sent: Friday, February 6, 2015 12:19 PM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Question about 100 Gbps MPC4E

 

Paul, we didnt do this test.

We can do it ... 

But we will need to run in ae5, because the traffic is very high today 90 Gbps 
and will rise a lot for the next few months.

The junos version is 13.3R2.

Do you think that ae5 configuration is not helping ?

We did the same test, on the same box, with 12 x 10G SFPP (MPC4E) and it works 
fine.

Thanks a lot,

Giuliano




Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811

+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br <mailto:giuli...@wztech.com.br> 
http://www.wztech.com.br/





​

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2014 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor  desta 
 mensagem  não  for o seu destinatário, 
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob 
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos 
documentos anexos. Neste caso, favor comunicar imediatamente 
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida 
apague-o. 

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission,  
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.

 

On Fri, Feb 6, 2015 at 3:01 PM, Paul Stewart mailto:p...@paulstewart.org> > wrote:

If you take the 100G port out of LAG does it have any impact on the issue you 
are seeing?  Can you share software version you are running?

Thanks,
Paul


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net 
<mailto:juniper-nsp-boun...@puck.nether.net> ] On Behalf Of Giuliano Medalha
Sent: Friday, February 6, 2015 4:35 AM
To: Adam Vitkovsky
Cc: juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> 
Subject: Re: [j-nsp] Question about 100 Gbps MPC4E

Adam,

Sorry about delay to answer this post.

We are trying to connect our JUNIPER MX960 router to a IX (Internet Exchange 
Point).

Once you are connected for the first time, the guys from the IX did a simple 
test (linux script) .. similar to an limited ARP Spoofing on every single 
physical port to evaluate the number of MAC answers supported for the router 
(minimum accepted is 1200). They will connect you to L2 main matrix.

We have another board on this router ... same MPC4E with 32 x 10G SFPP 
interfaces.  When we did the same ARP Spoofing test using a LAG with 8 x 10G 
interfaces ... it works fine.

With the new MPC4E board (2 x 100G + 8 x 10G SFPP) the test is not working.
The 100G (et-x/x/x) interface configured inside an AEx logical interface does 
not answer more than 80 MACs ...

We did every single configuration possible on this board ... but nothing is 
working.

The router learns the 1200 MACs ... but the answer does not return to the pc 
machine tester.

I was thinking about some special configuration for this board to do it to 
work. JUNIPER said that there is not any special configuration needed.

Today we will do a simple test using ettercap and a switch with 10G connections 
directly to the new board to see if we got something different.

Thanks a lot,

Giuliano

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br <mailto:giuli...@wztech.com.br> 
http://www.wztech.com.br/





WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2014 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor  desta 
 mensagem  não  for o seu destinatário, fica desde já notificado de que não 
poderá  divulgar,  distribuir ou, sob qualquer forma, dar conhecimento a 
terceiros das informações e do conteúdo dos documentos anexos. Neste caso, 
favor comunicar imediatamente o remetente, respondendo este e-mail ou 
tele

Re: [j-nsp] NAT on SRX with routed IP range

[Paul Stewart]

That's been my experience  proxy arp only on the external.

Paul


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Jonathan Call
Sent: Friday, February 6, 2015 3:00 PM
To: Tyler Christiansen
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] NAT on SRX with routed IP range

I've been reading the Juniper documentation and confirmed that the proxy-arp
statement is only needed when the  NAT IP falls within the subnet range of
the external IP address of the egress interface. It will automatically
proxy-arp for all else. It also doesn't matter if it is a source, a
destination or a static NAT.
In my case, the problem turned out to be a missing route on a third party
device preventing the traffic from even reaching the SRX.
Thanks!Date: Wed, 4 Feb 2015 14:16:02 -0800
Subject: Re: [j-nsp] NAT on SRX with routed IP range
From: ty...@adap.tv
To: lordsit...@hotmail.com
CC: juniper-nsp@puck.nether.net

Nope.  It's been a while, but I just reviewed our configuration, we removed
proxy-arp at some point.  Suppose it turns out proxy-arp wasn't needed.
We also have security policy configuration like this:
> show configuration security policies from-zone untrust to-zone trust 
> policy  {
match {source-address ;
destination-address ;application [  ];}then {permit;}}
If you want to make the NAT work for any outside source, you could just set
source-address to any.


On Wed, Feb 4, 2015 at 2:00 PM, Jonathan Call 
wrote:
I'm in the process of rewriting it all as a static NAT right now.

Are you applying any IP from routed block to your external interface?
Reading the rules of proxy-arp suggests that IP range needs to reside on the
external interface.

Thanks,

JonathanDate: Wed, 4 Feb 2015 13:52:00 -0800

Subject: Re: [j-nsp] NAT on SRX with routed IP range

From: ty...@adap.tv

To: lordsit...@hotmail.com

CC: juniper-nsp@puck.nether.net



Ah, sorry, I misunderstood.  We're using static NAT.  Here's a short
example.

> show configuration security nat static rule-set static-NATsfrom zone
untrust;rule  {match {destination-address ;destination-port ;}then {
static-nat {prefix {;
mapped-port ;}}}}







On Wed, Feb 4, 2015 at 1:08 PM, Jonathan Call 
wrote:







I added a proxy-arp enty:

source {rule-set my-lab-internal {from zone lab-internal;to zone
untrust;rule my-lab-inet {match {source-address192.168.2.0/26;}then
{source-nat {interface;}destination {pool lab-plasma {address
192.168.2.2/32 port 8080;}rule-set lab-nats {from zone untrust;rule
lab-plasma-1 {match {destination-address 4.5.32.16/32;destination-port
8080;} then {destination-nat pool lab-plasma;proxy-arp {interface
reth0.0 {address {4.5.32.16/32;}}}

The translation hit counter from 'show security nat destination rule all'
does not increment so I'm still not hitting the NAT rule. I have the
appropriate security policy rules between the untrust and lab-internal zones
to allow 8080 inbound and anything outbound.

Jonathan



Date: Wed, 4 Feb 2015 11:45:26 -0800

Subject: Re: [j-nsp] NAT on SRX with routed IP range

From: ty...@adap.tv

To: lordsit...@hotmail.com

CC: juniper-nsp@puck.nether.net



We use routed ranges to NAT a few hosts.  The key for us was configuring
proxy-arp on the untrust interface for the IPs.

On Wed, Feb 4, 2015 at 11:24 AM, Jonathan Call 
wrote:

I've seen plenty of examples of a static NAT where the SRX has a public IP
range on the untrusted interface. I have not found a good one for when the
SRX has an IP range routed to it.



SRX Public IP: 4.5.6.60/30Routed IP range (via the public interface)
4.5.32.16/28Trusted zone: 192.168.2.1/26



show configuration security nat (hopefully this will display properly)



source {rule-set my-lab-internal {from zone lab-internal;
to zone untrust;rule my-lab-inet {match {
source-address 192.168.2.0/26;}then {
source-nat {interface;}}
}}}destination {pool lab-plasma {address 192.168.2.2/32 port
8080;}rule-set lab-nats {from zone untrust;rule
lab-plasma-1 {match {destination-address
4.5.32.16/32;destination-port 8080;}
then {destination-nat pool lab-plasma;}}
}}



The result of this configuration is that no NAT occurs. But if I change the
destination-address to the SRX's external IP (4.5.6.60) it works just fine.



Jonathan



___



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] Question about 100 Gbps MPC4E

[Paul Stewart]

If you take the 100G port out of LAG does it have any impact on the issue you 
are seeing?  Can you share software version you are running?

Thanks,
Paul


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Giuliano Medalha
Sent: Friday, February 6, 2015 4:35 AM
To: Adam Vitkovsky
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Question about 100 Gbps MPC4E

Adam,

Sorry about delay to answer this post.

We are trying to connect our JUNIPER MX960 router to a IX (Internet Exchange 
Point).

Once you are connected for the first time, the guys from the IX did a simple 
test (linux script) .. similar to an limited ARP Spoofing on every single 
physical port to evaluate the number of MAC answers supported for the router 
(minimum accepted is 1200). They will connect you to L2 main matrix.

We have another board on this router ... same MPC4E with 32 x 10G SFPP 
interfaces.  When we did the same ARP Spoofing test using a LAG with 8 x 10G 
interfaces ... it works fine.

With the new MPC4E board (2 x 100G + 8 x 10G SFPP) the test is not working.
The 100G (et-x/x/x) interface configured inside an AEx logical interface does 
not answer more than 80 MACs ...

We did every single configuration possible on this board ... but nothing is 
working.

The router learns the 1200 MACs ... but the answer does not return to the pc 
machine tester.

I was thinking about some special configuration for this board to do it to 
work. JUNIPER said that there is not any special configuration needed.

Today we will do a simple test using ettercap and a switch with 10G connections 
directly to the new board to see if we got something different.

Thanks a lot,

Giuliano

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/





WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2014 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor  desta 
 mensagem  não  for o seu destinatário, fica desde já notificado de que não 
poderá  divulgar,  distribuir ou, sob qualquer forma, dar conhecimento a 
terceiros das informações e do conteúdo dos documentos anexos. Neste caso, 
favor comunicar imediatamente o remetente, respondendo este e-mail ou 
telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission,  
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.

On Fri, Jan 30, 2015 at 6:53 AM, Adam Vitkovsky  wrote:

> Hello Giuliano,
>
> I somehow did not get what is not working exactly?
> Are the ports not coming up? Is the LACP not coming up? Or you can't 
> pass frames between the VLANs?
>
> adam
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
> > Behalf Of Giuliano Medalha
> > Sent: 30 January 2015 01:13
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Question about 100 Gbps MPC4E
> >
> > ​People,
> >
> > We have a router (MX960) with the following MPC4E board (with SCBE2):
> >
> > http://www.juniper.net/documentation/en_US/release-
> > independent/junos/topics/reference/general/mpc4e-2x100ge-8x10ge.html
> >
> >
> > We are using it configured as aggregated ethernet AE3 (with LACP) 
> > connecting to a CISCO ASR9000 router (minimum-links 1 and link-speed 
> > 100g with MTU 9192) using flexible-vlan-tagging and 2 vlans (unit 
> > 100 and unit 200).
> >
> > I have found some specific documents about running this board on a
> special
> > way called SA-MULTICAST.
> >
> > http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configur
> > ati on/interfaces-mpc4e-100-ge-interop-sa-multicast.html
> >
> > My question is ... there is some special way to configure this board 
> > to talk with CISCO ASR9000 board ? Does cisco needs this king of 
> > configuration on juniper to work ?
> >
> > Something like 2 aggregated of 50 Gbps interfaces ? et-4/0/1:0
> > et-4/0/1:1
> >
> > Do you have something similar in your backbones ? Its necessary to 
> > do some special config or adjustment ?
> >
> > There is some MAC-LEARNING limit configured by default on this board ?
> >
> > Could you please help me how to find the correct way to put it to work ?
> >
> > Thanks a lot,
> >
> > Giuliano
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> --

Re: [j-nsp] SRX1xx Temperature Thresholds

[Paul Stewart]

We had an SRX 100 or 110 like that at one point... it kept going into alarm
state.  Ended up RMA'ing it back and getting a replacement after messing
around with it for too long.  

Paul


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Skeeve Stevens
Sent: Monday, January 19, 2015 8:18 AM
To: Alexandre Guimaraes
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX1xx Temperature Thresholds

Done it... not working.  Dropped the temp in a test environment by 6c...
but at 37c outside, its exceeding the threshold.



...Skeeve

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

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

Facebook: eintellegonetworks  ;
Twitter: eintellego 

LinkedIn: /in/skeeve  ; Expert360: Profile



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

On Mon, Jan 19, 2015 at 11:45 PM, Alexandre Guimaraes <
alexandre.guimar...@ascenty.com> wrote:

> Skeeve,
> Indeed. Try to put an outside fan, forcing an air flow.
>
>
>  Mensagem original-
> De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome 
> de Michael Dale Enviada em: domingo, 18 de janeiro de 2015 23:15
> Para: Skeeve Stevens; juniper-nsp@puck.nether.net
> Assunto: Re: [j-nsp] SRX1xx Temperature Thresholds
>
> They must be getting super hot!
>
>
> I have one in a place with no air flow and never had an issue with it.
>
>
> I would drill some holes in the top of the case :)
>
>
> Ours with no air flow (SRX110):
>
>
>
> Class Item   Status Measurement Temp  Routing
> Engine OK 78 degrees C / 172 degrees F
>   Routing Engine CPU Absent Power Power Supply 0
>   OK
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Has anyone else tried this?

[Paul Stewart]

I always liked this one:

JUNOS Routing Software Suite [12.3R6.6]


Juniper babies
The next generation starts
Gotta get more sleep



Paul

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Phil Shafer
Sent: Tuesday, October 07, 2014 8:13 AM
To: Paul Goyette
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Has anyone else tried this?

Or with the number of recruiters ;^)

Ob.Haiku:

Haikus are magic
Springing from your CLI
Wasting half your day


Paul Goyette writes:
>Yeah, but it didn't scale with our number of employees!
>
>
>
>-Original Message-
>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
>Behalf Of Chris Adams
>Sent: Monday, October 06, 2014 08:23 PM
>To: juniper-nsp@puck.nether.net
>Subject: Re: [j-nsp] Has anyone else tried this?
>
>Once upon a time, Dovid B  said:
>> root@gw3.nj1> show version and haiku
>> Hostname: gw3.nj1
>> Model: srx240h2
>> JUNOS Software Release [12.1X44-D30]
>> 
>> 
>> My session is dead:
>> Forgot to commit confirm.
>> Where are my car keys?
>
>That one is good, but "show version and blame" was better. :)
>--
>Chris Adams 
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net 
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net 
>https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

[j-nsp] AppTrack logs

[Paul Stewart]

Hi there…

Does anyone know of any open source applications that will analyze and
report on AppTrack logs from Juniper SRX?  I am not a fan of STRM and
looking for options…

Thanks,

Paul




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

Re: [j-nsp] OSPF question

[Paul Stewart]

Maybe turn on trace options and see that those updates are?  This will
tell you what the updates are and potentially the trigger for the updates.

Paul


On 2014-06-04, 12:35 PM, "R S"  wrote:

>Which can be the reason why among two MX (using irb) running OSPF there
>are around 100-150 OSPF Link State Update Packet retransmission per day ?
>No link is interrupted, no link is fauly/CRC...
>
>My customer is receiving traps on its monitoring systems and I've no
>clear clue about the reason...
>Any reccomendation/experience ?
>
>Thank you
> 
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>


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

Re: [j-nsp] ACX Series Technical Information

[Paul Stewart]

We tested and deployed them.  Our primary interest in them was to pickup
physical T1’s and transport them to another location for handoff.  The
first units were deployed about a year ago and have had zero issues.

Paul


On 2014-05-13, 11:45 PM, "Tim Jackson"  wrote:

>ACX is Broadcom Enduro inside. Basically a Cisco ASR901 (or Ciena 39xx).
>
>Route scaling for all ACX is somewhere around 12k routes (give or take,
>its
>11p on Bourbon Street)..
>
>Licensing is only for ptp as far as I know. I had talks about reducing
>price on units and per-port licensing was talked abou.t but no general
>licensing is in place.
>
>Runs 12.3X code.. Limited DHCP, most shit works.. I've deployed many 10s
>of
>units so far as edge PEs with good success.
>On May 13, 2014 10:02 PM, "Skeeve Stevens" <
>skeeve+juniper...@eintellegonetworks.com> wrote:
>
>> Hi all,
>>
>> The Juniper website is very light on technical information and
>>capabilities
>> of the ACX platform.
>>
>> Things such as throughput comparisons between models, routing protocols,
>> number of routes per routing protocols supported, etc.
>>
>> There also is no mention of licensing on the base datasheet, so I am
>> assuming everything it mentions, it is licensed for.
>>
>> Does anyone know of more detailed information?
>>
>> ...Skeeve
>>
>> *Skeeve Stevens - *eintellego Networks Pty Ltd
>> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>>
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>
>> facebook.com/eintellegonetworks ;  
>> linkedin.com/in/skeeve
>>
>> twitter.com/theispguy ; blog: www.theispguy.com
>>
>>
>> The Experts Who The Experts Call
>> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp



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

[j-nsp] Weird FPC errors MX480

[Paul Stewart]

Hey there…



MX480 running 11.4R9.4 and I’m getting weird error logs from a MPC2-3D with
a pair of 4X10G MIC cards:



Mar 21 10:33:26  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322791,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4

Mar 21 10:33:28  core2.toronto1 fpc2 LUCHIP(1) PPE_3 Errors sync xtxn error

Mar 21 10:33:28  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322792,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4

Mar 21 10:33:33  core2.toronto1 fpc2 LUCHIP(1) PPE_15 Errors sync xtxn error

Mar 21 10:33:33  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322793,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4

Mar 21 10:33:42  core2.toronto1 fpc2 LUCHIP(1) PPE_2 Errors sync xtxn error

Mar 21 10:33:42  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322794,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4

Mar 21 10:33:43  core2.toronto1 fpc2 LUCHIP(1) PPE_6 Errors sync xtxn error

Mar 21 10:33:43  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322795,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4

Mar 21 10:33:48  core2.toronto1 fpc2 LUCHIP(1) PPE_11 Errors sync xtxn error

Mar 21 10:33:48  core2.toronto1 fpc2 PPE Sync XTXN Err Trap:  Count 3322796,
PC 617d, 0x617d:  flow_age_read_active_timestamp 0x617d:  flow_age_ipv4



JTAC told me this is cosmetic but I am not convinced.  Anyone run across
this before?  It has been ongoing for a while and did not create any service
impact however this morning we started dropping packets on at least one port
and have not ruled out the card as a potential issue.

Thanks,

Paul



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

[j-nsp] MX PPPOE w/l2tp (subscriber management)

[Paul Stewart]

Hey folks – finally getting around to a project that has been getting held
up.

We have an MX480 deployed currently that is handling PPPOE traffic.  The
interface (AE with 4X10G) configuration is pretty straight forward:

paul@# show interfaces ae3

description “";

vlan-tagging;

auto-configure {

vlan-ranges {

dynamic-profile pppoe {

accept pppoe;

ranges {

any;

}

}

}

remove-when-no-subscribers;

}

mtu 9192;

encapsulation flexible-ethernet-services;

aggregated-ether-options {

lacp {

passive;

periodic fast;

}

}


Obviously there is an access section and a dynamic-profile section to
support this configuration.  This works today and well.

Now, we want to bring another VLAN into the MX480 for additional PPPOE
subscribers – but the catch is that this is via a wholesale provider handing
off lt2p tunnels (Bell Canada wholesale).

Today, on our Cisco configuration we have:

vpdn-group AGAS-1005

! Default L2TP VPDN group

 accept-dialin

  protocol l2tp

  virtual-template 1

 local name nexicom-1

 lcp renegotiation always

 l2tp tunnel password 7 x



bba-group pppoe global

 virtual-template 1



interface GigabitEthernet0/3.901

 description Bell AGAS Service (xxx)

 encapsulation dot1Q 901

 ip address xx.xx.xxx.27 255.255.255.248 secondary

 ip address xx.xx.xxx.28 255.255.255.248 secondary

 ip address xx.xx.xxx.26 255.255.255.248


And then virtual template(s) and a few static routes to each the far end of
the l2tp tunnels.

Has anyone converted a configuration like the above Cisco configuration into
a Juniper MX style configuration?  I did some reading on l2tp for subscriber
management on JunOS and am confused as ever :)

Thanks,

Paul




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

[j-nsp] Loopback Filter - NTP Question

[Paul Stewart]

Hi there

We are still finding some JunOS devices vulnerable in our network to the NTP
issue.  For devices with an IP address on the loopback this has proven to be
just an update to existing firewall filters where we allow the remote NTP
servers we query from and include the loopback IP itself.

Most of the remaining devices do not have an IP address on the loopback
which has presented a new challenge we were not expecting.  If we apply an
updated loopback firewall filter and attempt to filter NTP only to specific
sources it will fail every time if there is no actual IP address on the
loopback.  

Juniper says we must put an IP address on the loopback to work around this
issue so I am wondering what other folks are doing in these specific
situations? 

There are several options which to me the best would be to have Juniper
actually fix this issue with a proper NTP implementation

Thanks for any input

Paul




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

Re: [j-nsp] Juniper MX104

[Paul Stewart]

Hi Saku… 

I hope it really is - but based on the 16k number on MX80 becoming 4k 
realistically and with only minimal code changes implemented on MX104 vs MX80 I 
am not optimistic at this point.  I really hope to be proven wrong though :)

Paul


On Nov 14, 2013, at 7:22 AM, Saku Ytti  wrote:

> On (2013-11-14 06:51 -0500), Paul Stewart wrote:
> 
>> The MX104 most likely won’t be able to handle any more subscribers than 4k 
>> neither - but have not seen any POC”s or deployments yet on that hardware.
> 
> I'm bit more optimistic, as it has double the DRAM and somewhat faster PPC
> CPU, scale should be somewhat better.
> 
> -- 
> ++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] Juniper MX104

[Paul Stewart]

We have pushed MX80 very hard with PPPOE and found the 4k number to be 
realistic.  Of course it depends on what other features you are turning on as 
well.

I worked with Juniper team to perform POC’s and load testing with “real life 
environments” and at the end of the testing (and based on what I see with 
several of them deployed at customers) the 4k number is “safe”.

The MX104 most likely won’t be able to handle any more subscribers than 4k 
neither - but have not seen any POC”s or deployments yet on that hardware.

Paul


On Nov 13, 2013, at 1:46 AM, Christopher E. Brown  
wrote:

> 
> Scaling on the MX80 is supposed to be 16,000 per chassis, 8,000 per MIC
> and 4,000 per PIC and a 8,000 limit on PPPoE sessions.
> 
> In order to max out you need 2 MICs loaded with at least 1 port per PIC
> active for subscriber term at up to 4k per.
> 
> 
> Also, vlan units and PPPoE units both count as a sub... So if doing uniq
> stacked tag combo per sub w/ PPPoE you are using a unit at both the vlan
> and pppoe level per sub and when you hit the 8k limit you are also out
> of interfaces.
> 
> I have not personally seen a MX80 with that many active subs yet, will
> have to see if things run out of juice before the hard limits are reached.
> 
> On 11/12/13 7:52 PM, Skeeve Stevens wrote:
>> Does anyone know how many users the MX104 will be able to handle though?
>> 
>> The 4000 user limit on the MX80 was quite low.
>> 
>> Does the MX104 have the services port on the back like the MX80?  I'm
>> waiting for the CGN Services card which was supposed to be released around
>> now.
>> 
>> 
>> ...Skeeve
>> 
>> *Skeeve Stevens - *eintellego Networks Pty Ltd
>> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>> 
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>> 
>> facebook.com/eintellegonetworks ;  
>> linkedin.com/in/skeeve
>> 
>> twitter.com/theispguy ; blog: www.theispguy.com
>> 
>> 
>> The Experts Who The Experts Call
>> Juniper - Cisco - Cloud
>> 
>> 
>> On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale  wrote:
>> 
>>> That and I think a lot of the BRAS "migration" functionality (LNS/LAC etc)
>>> was late to the party after being told it wasn't going to happen for
>>> anything lower than the 240.
>>> 
>>> On 13 Nov 2013, at 12:51 pm, Bill Blackford  wrote:
>>> 
 My personal feeling is the MX80 wasn't widely adopted as a lower density
 subscriber box given the lack of redundant REs. The MX104 may find it's
 niche as a BRAS.
 
 
 
 
 On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol 
>>> wrote:
 
> One thing to keep in mind about these boxes is that, like the
> MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS
>>> (per-unit
> scheduling).  I'm confused as to why this is, considering they are
> Trio-based routers, but I digress.  I personally don't think that the
> astronomical cost to enable the 10G ports on all the low-end MX routers
>>> is
> worth it, considering they can't even do per-unit scheduling.
> 
> -evt
> 
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf Of
>> joel jaeggli
>> Sent: Tuesday, November 12, 2013 4:00 PM
>> To: Saku Ytti
>> Cc: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] Juniper MX104
>> 
>> 
>> On Nov 12, 2013, at 12:46 PM, Saku Ytti  wrote:
>> 
>>> On (2013-11-12 20:14 +), Tom Storey wrote:
>>> 
 Why so much just to enable some ports? How do they come up with that
 kind of price? Pluck it out of thin air?
 
 The hardware has been paid for, and I know thats only list pricing,
 but it still seems ridiculous.
>>> 
>>> The question might have been rhetoric. But I'll bite.
>>> 
>>> The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But
> the
>>> volume you can sell them also is very very small, so the margins need
> to
>> be
>>> very high to be able to design and support them.
>>> Licensing allows you to sell to larger group of people, people who
>> normally
>>> would buy smaller/inferior box, now can afford it,  which in turn
> allows
>> you
>>> to reduce your margins, making you more competitive.
>>> 
>>> I actually like it. I wish vendors like Agilent/Ixia, Spirent would
> sell
>>> test-kit with some sort of 'per hours used' license. Lot of SPs have
> need
>> for
>>> proper testing kit, but only will need them very irregularly. And
> renting
>> is
>>> always such a chore. It's same thing there, BOM is nothing, but volume
> is
>> even
>>> lower, so prices are ridiculously high, consequently proper testing is
>> very
>>> rarely done by other than telco size SPs.
>> 
>> It's one of those things where you work with account team. if the
> commercial
>> terms d

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Paul Stewart]

Thanks for bringing that up Š. 16,000 IFL¹s and PPPOE uses two IFL¹s per
subscriber and the box doesn¹t handle more than 4,000 PPPOE customers very
well.  There has been some challenges with Juniper identifying how far the
box will really scale - we tell our customers to not go above 4,000 as a
³good rule of thumb² of course depending on what they are doing and how
they are using it etcŠ.

-p

On 10/24/2013, 10:05 AM, "Alex D."  wrote:

>Am 19.10.2013 21:44, schrieb Enoch Nyatoti:
>> Hello,
>>
>> I am new to Juniper hence my request. We would like to deploy BRAS  and
>>LAC functionality on MX80 routers to existing Cisco NAS and I was
>>wondering if you could give me a lead on
>> how to configure these features in Junos including the relevant PPPoE
>> interface configuration. The idea is to tunnel some sessions to an LNS
>>depending on
>> the domain name.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>Hi,
>
>how much users do you want to terminate on your MX80 ?
>Keep in mind, that there is a limit of 16.000 IFLs. When you plan to use
>hierarchical qos, better go to a bigger platform.
>
>Regards,
>Alex
>
>___
>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] MX-MPC2-3D layer 3 license required

[Paul Stewart]

Honor system at moment - just received some licenses and they were just
paper (no codes to enter)

Paul


On 10/23/2013, 9:27 PM, "John pp"  wrote:

>Is the layer 3 license required or is it an honour system?
>
>Thanks
>___
>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] MX-80 as a BRAS and as a LAC

[Paul Stewart]

Also make sure you talk to your Juniper SE and engage him in your plans -
make sure you understand which code releases you require for your
deployment.  The last I checked, LNS was not supported on MX80 but that
may have changed in recent 13.2 code.

Like everything there’s several ways to configure things - here’s a pretty
base configuration that will hopefully help point you in the right
direction… the local pool assignment isn’t need if your Radius is going to
hand out all dynamic addresses...

dynamic-profiles {
PPPOE {
predefined-variable-defaults {
input-filter PERMIT-ALL;
output-filter PERMIT-ALL;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$junos-input-filter";
output "$junos-output-filter";
}
unnumbered-address lo0.0;
}
}
}
}
}
}

interfaces {
ge-1/0/0 { 
description ge0-1-0.dis4.xx;
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 404 { 
description x;
vlan-id 404;
family pppoe {
duplicate-protection;
dynamic-profile PPPOE;
short-cycle-protection;
}  
}  
}  
}


access {
radius-server {
Xx.xxx.xx.xxx {
secret “xxx"; ## SECRET-DATA
source-address xx.xx.xxx.xx;
}
Xx.xxx.xxx.xx {
secret “xxx"; ## SECRET-DATA
source-address xx.xxx.xx.xx;
}
}
group-profile DNS {
ppp {
primary-dns xxx.xxx.xx.xxx;
secondary-dns xx.xx.x.xxx;
}
}
profile RADIUS {
accounting-order radius;
authentication-order radius;
radius {
authentication-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
accounting-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
options {
revert-interval 0;
client-authentication-algorithm round-robin;
client-accounting-algorithm round-robin;
}
}
accounting {
order radius;
accounting-stop-on-failure;
accounting-stop-on-access-deny;
immediate-update;
update-interval 10;
statistics volume-time;
}
}
address-assignment {
pool PPPOE-1 {
link PPPOE-2;
family inet {
network 10.0.0.0/24;
range 1 {
low 10.0.0.1;
high 10.0.0.254;
}
}
}
   }
}
}
access-profile RADIUS;



Also note that this example doesn’t include anything for your routing.  So
everything in JunOS is “access-internal” and you need to redistribute them
into OSPF (or whatever IGP you are running).  When you redistribute them,
each route shows up separately for each subscriber - a large amount of /32
routes if you are not careful which can cause “bad things to happen(™)”.
What I did to work around this was to summarize the routes but in doing so
I had to ensure that static IP assignments would still function:

routing-options {
static {
route 10.0.0.0/24 discard;
}
}

policy-options {
term access-internal-1 {
from {
protocol access-internal;
route-filter 10.0.0.0/24 longer;
then reject;
}
term access-internal-2 {
from protocol access-internal;
then accept;
}
term implicit-deny {
then reject;
}
}
}


Hope that helps...

Paul



On 10/24/2013, 3:12 AM, "Terebizh, Evgeny"  wrote:

>Hi,
>Check out the feature map below:
>https://www.juniper.net/techpubs/en_US/junos12.3/information-products/path
>w
>ay-pages/subscriber-access/technology-overview-graphic.html
>
>Here¹s the relevant L2TP section:
>https://www.juniper.net/techpubs/en_US/junos13.2/information-products/path
>w
>ay-pages/subscriber-access/l2tp/subscriber-management-l2tp.html
>
>Bear in mind that you might need a juniper.net account to access these
>links. 
>
>
>/Evgeny
>
>
>
>
>On 19/10/13 23:44, "Enoch Nyatoti"  wrote:
>
>>Hello,
>>
>>I am new to Juniper hence my request. We would like to deploy BRAS  and
>>LAC functionality on MX80 routers to existing Cisco NAS and I was
>>wondering if you could give me a lead on
>>how to configure the

Re: [j-nsp] Junos BNG PPPoE inside a VPLS

[Paul Stewart]

Has anyone configured this up?  I'm looking to implement it (testing at
this point) but confused...:)

It looks like you still need to utilize an LT interface to identify which
PFE is going to do the heavy lifting?  Believe it or not, I've never
actually configured an LT interface before so this is perhaps a silly
question but which interface would I want for this purpose and how much
traffic could it handle?

Hardware inventory:
Item Version  Part number  Serial number Description
Chassis  MX480
Midplane REV 05   710-017414     MX480 Midplane
FPM BoardREV 02   710-017254     Front Panel
Display
PEM 0Rev 05   740-027736   xxx   DC 2.4kW Power
Entry Module
PEM 1Rev 05   740-027736   xxx   DC 2.4kW Power
Entry Module
PEM 2Rev 05   740-027736   xxx   DC 2.4kW Power
Entry Module
PEM 3Rev 05   740-027736   xxx   DC 2.4kW Power
Entry Module
Routing Engine 0 REV 08   740-031116   xxRE-S-1800x4
Routing Engine 1 REV 08   740-031116   xxRE-S-1800x4
CB 0 REV 15   710-021523     MX SCB
CB 1 REV 15   710-021523     MX SCB
FPC 0REV 05   750-04     MPCE Type 2 3D P
  CPUREV 04   711-038484     MPCE PMB 2G
  MIC 0  REV 29   750-028387     3D 4x 10GE  XFP
PIC 0 BUILTIN    2x 10GE  XFP
  Xcvr 0 REV 01   740-014289     XFP-10G-SR
  Xcvr 1 REV 01   740-014289     XFP-10G-SR
PIC 1 BUILTIN    2x 10GE  XFP
  QXM 0  REV 06   711-028408     MPC QXM
  QXM 1  REV 06   711-028408     MPC QXM
FPC 1REV 05   750-04     MPCE Type 2 3D P
  CPUREV 04   711-038484     MPCE PMB 2G
  MIC 1  REV 29   750-028387     3D 4x 10GE  XFP
PIC 2 BUILTIN    2x 10GE  XFP
  Xcvr 0 REV 01   740-014289     XFP-10G-SR
  Xcvr 1 REV 01   740-014289     XFP-10G-SR
PIC 3 BUILTIN    2x 10GE  XFP
  QXM 0  REV 06   711-028408     MPC QXM
  QXM 1  REV 06   711-028408     MPC QXM
Fan Tray Enhanced Left Fan
Tray

Any feedback appreciated...

Paul




On 2013-09-24 5:46 AM, "Mark Tinka"  wrote:

>On Tuesday, September 17, 2013 04:05:50 PM Adrien Desportes
>wrote:
>
>> Hello William,
>> 
>> Before 13.2 you would have to use an external loop to
>> terminate the vpls on one side and the ppp on the other
>> side (as lt- interface does not support the proper
>> encapsulation for ppp).
>> 
>> Starting 13.2 (that was just released), if you use L2VPN
>> rather than VPLS to backhaul your DSLAM VLAN, the below
>> feature might do the job w/o consuming ports for the
>> external hairpin:
>> 
>> http://www.juniper.net/techpubs/en_US/junos13.2/topics/co
>> ncept/pseudowire-subscriber-interfaces-overview.html
>
>Now I really don't have to have VPLS at all.
>
>Happy days :-).
>
>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] SSD disks high failure ratio ?

[Paul Stewart]

Our unit that is "effected" I already upgraded software on and didn't have a
problem - thankfully it looks like we got off lucky...:)

From:  Pierre-Yves Maunier 
Date:  Tuesday, 8 October, 2013 10:50 AM
To:  Paul Stewart 
Cc:  Phil Mayers , Saku Ytti ,
Juniper-Nsp List 
Subject:  Re: [j-nsp] SSD disks high failure ratio ?

> I confirmed just by serial number and also by the fact that during the reboot
> after a software upgrade my filesystem died on the /var partition.
> 
> I'm still waiting a confirmation from the TAC.
> 
> 
> On Tuesday, October 8, 2013, Paul Stewart  wrote:
>> Did you confirm by serial number that you were effected?  The reason I ask
>> is we had a pair of RE1800's that matched on part number but after JTAC
>> ran the serial numbers they re-assured us that we were not actually
>> effected (which is kind of scary in itself).
>> 
>> Paul
>> 
>> 
>> On 2013-10-07 7:58 PM, "Pierre-Yves Maunier" >  > wrote:
>> 
>>> >Hello,
>>> >
>>> >I have affected REs, and before I had the knowledge of the KB, I found a
>>> >workaround to repair the filesystem because the TAC was unable to tell me
>>> >anything about this KB.
>>> >
>>> >After an upgrade from 12.2R1.8 to 12.3R4.6 I got this :
>>> >
>>> >=== Bootstrap installer starting ===
>>> >Initialized the environment
>>> >Routing engine model is RE-S-1800x4
>>> >HW model is Intel(R) Xeon(R) CPU   C5518  @ 1.73GHz
>>> >[: kontron: unexpected operator
>>> >Discovered that flash disk = ad0 , hard disk = ad1
>>> >mount: /dev/ad1s1f : Invalid argument
>>> >ERROR: mount_partition: Mount /dev/ad1s1f /mnt failed
>>> >You are now in a debugging subshell (you may not see a prompt)Š
>>> >#
>>> >
>>> >And after a reboot I got this :
>>> >
>>> >Automatic reboot in progress...
>>> >** /dev/ad1s1a
>>> >FILE SYSTEM CLEAN; SKIPPING CHECKS
>>> >clean, 1673532 free (124 frags, 209176 blocks, 0.0% fragmentation)
>>> >** /dev/ad1s1e
>>> >FILE SYSTEM CLEAN; SKIPPING CHECKS
>>> >clean, 201639 free (31 frags, 25201 blocks, 0.0% fragmentation)
>>> >Cannot find file system superblock
>>> >32 is not a file system superblock
>>> >28740192 is not a file system superblock
>>> >** /dev/ad1s1f
>>> >
>>> >
>>> >LOOK FOR ALTERNATE SUPERBLOCKS? yes
>>> >
>>> >
>>> >SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
>>> >-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
>>> >SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).
>>> >tunefs: /var: could not read superblock to fill out disk
>>> >mount: /dev/ad1s1f : Invalid argument
>>> >WARNING:
>>> >WARNING: /var mount failed, building emergency /var
>>> >WARNING:
>>> >Creating initial configuration...mgd: commit complete
>>> >Setting initial options:  debugger_on_panic=NO debugger_on_break=NO.
>>> >Starting optional daemons:  usbd.
>>> >Doing initial network setup:
>>> >.
>>> >Initial interface configuration:
>>> >
>>> >
>>> >So the /var partition on /dev/ad1s1f (SSD) needed a fsck but it failed
>>> >because of a 'bad superblock'
>>> >
>>> >Going in the shell as root, I issued the following command to get a lisk
>>> >of
>>> >'backup' super-blocks :
>>> >
>>> >root@CORE-01% newfs -N /dev/ad1s1f
>>> >/dev/ad1s1f: 18342.8MB (37566076 sectors) block size 16384, fragment size
>>> >2048
>>> > using 100 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
>>> >super-block backups (for fsck -b #) at:
>>> > 32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568,
>>> > 3385760, 3761952, 4138144, 4514336, 4890528, 5266720, 5642912, 6019104,
>>> > 6395296, 6771488, 7147680, 7523872, 7900064, 8276256, 8652448, 9028640,
>>> > 9404832, 9781024, 10157216, 10533408, 10909600, 11285792, 11661984,
>>> >12038176,
>>> > 12414368, 12790560, 13166752, 13542944, 13919136, 14295328, 14671520,
>>> > 15047712, 15423904, 15800096, 16176288, 16552480, 16928672, 17304864,
>>> > 17681056, 18057248, 18433440, 18809632, 19185824, 19562016, 19938208,
>>> > 20314400, 20690592, 21

Re: [j-nsp] SSD disks high failure ratio ?

[Paul Stewart]

Yeah that's what I was wondering too ... We had the exact revisions and
models but then were told not to worry  Hmmm..  I'm still worrying ;)

On 2013-10-08 9:09 AM, "Phil Mayers"  wrote:

>On 08/10/13 13:57, Paul Stewart wrote:
>> Did you confirm by serial number that you were effected?  The reason I
>>ask
>> is we had a pair of RE1800's that matched on part number but after JTAC
>> ran the serial numbers they re-assured us that we were not actually
>> effected (which is kind of scary in itself).
>
>They told me something contradictory; I was assured I was OK because
>they were bought after "date X" but I pointed out the HW rev was 04 and
>the KB said <=05 was affected, at which point they decided I *was*
>affected.
>
>Seems they're a bit confused...


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

Re: [j-nsp] SSD disks high failure ratio ?

[Paul Stewart]

Did you confirm by serial number that you were effected?  The reason I ask
is we had a pair of RE1800's that matched on part number but after JTAC
ran the serial numbers they re-assured us that we were not actually
effected (which is kind of scary in itself).

Paul


On 2013-10-07 7:58 PM, "Pierre-Yves Maunier"  wrote:

>Hello,
>
>I have affected REs, and before I had the knowledge of the KB, I found a
>workaround to repair the filesystem because the TAC was unable to tell me
>anything about this KB.
>
>After an upgrade from 12.2R1.8 to 12.3R4.6 I got this :
>
>=== Bootstrap installer starting ===
>Initialized the environment
>Routing engine model is RE-S-1800x4
>HW model is Intel(R) Xeon(R) CPU   C5518  @ 1.73GHz
>[: kontron: unexpected operator
>Discovered that flash disk = ad0 , hard disk = ad1
>mount: /dev/ad1s1f : Invalid argument
>ERROR: mount_partition: Mount /dev/ad1s1f /mnt failed
>You are now in a debugging subshell (you may not see a prompt)Š
>#
>
>And after a reboot I got this :
>
>Automatic reboot in progress...
>** /dev/ad1s1a
>FILE SYSTEM CLEAN; SKIPPING CHECKS
>clean, 1673532 free (124 frags, 209176 blocks, 0.0% fragmentation)
>** /dev/ad1s1e
>FILE SYSTEM CLEAN; SKIPPING CHECKS
>clean, 201639 free (31 frags, 25201 blocks, 0.0% fragmentation)
>Cannot find file system superblock
>32 is not a file system superblock
>28740192 is not a file system superblock
>** /dev/ad1s1f
>
>
>LOOK FOR ALTERNATE SUPERBLOCKS? yes
>
>
>SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
>-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
>SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).
>tunefs: /var: could not read superblock to fill out disk
>mount: /dev/ad1s1f : Invalid argument
>WARNING:
>WARNING: /var mount failed, building emergency /var
>WARNING:
>Creating initial configuration...mgd: commit complete
>Setting initial options:  debugger_on_panic=NO debugger_on_break=NO.
>Starting optional daemons:  usbd.
>Doing initial network setup:
>.
>Initial interface configuration:
>
>
>So the /var partition on /dev/ad1s1f (SSD) needed a fsck but it failed
>because of a 'bad superblock'
>
>Going in the shell as root, I issued the following command to get a lisk
>of
>'backup' super-blocks :
>
>root@CORE-01% newfs -N /dev/ad1s1f
>/dev/ad1s1f: 18342.8MB (37566076 sectors) block size 16384, fragment size
>2048
> using 100 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
>super-block backups (for fsck -b #) at:
> 32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568,
> 3385760, 3761952, 4138144, 4514336, 4890528, 5266720, 5642912, 6019104,
> 6395296, 6771488, 7147680, 7523872, 7900064, 8276256, 8652448, 9028640,
> 9404832, 9781024, 10157216, 10533408, 10909600, 11285792, 11661984,
>12038176,
> 12414368, 12790560, 13166752, 13542944, 13919136, 14295328, 14671520,
> 15047712, 15423904, 15800096, 16176288, 16552480, 16928672, 17304864,
> 17681056, 18057248, 18433440, 18809632, 19185824, 19562016, 19938208,
> 20314400, 20690592, 21066784, 21442976, 21819168, 22195360, 22571552,
> 22947744, 23323936, 23700128, 24076320, 24452512, 24828704, 25204896,
> 25581088, 25957280, 26333472, 26709664, 27085856, 27462048, 27838240,
> 28214432, 28590624, 28966816, 29343008, 29719200, 30095392, 30471584,
> 30847776, 31223968, 31600160, 31976352, 32352544, 32728736, 33104928,
> 33481120, 33857312, 34233504, 34609696, 34985888, 35362080, 35738272,
> 36114464, 36490656, 36866848, 37243040
>
>Then this command fixed the problem (376224 is the first super-block after
>'32' which seem to have an issue) :
>
>root@CORE-01% fsck_ufs -y -b 376224 /dev/ad1s1f
>
>Does anyone knows what is the 'software solution' that 'has also been
>developed to correct the affected REs in the field' as said in the KB ?
>
>Pierre-Yves
>
>
>
>2013/10/4 Phil Mayers 
>
>> Saku Ytti  wrote:
>> >On (2013-10-03 18:08 -0400), Paul Stewart wrote:
>> >
>> >> "Article is in review and not yet ready for viewing"
>> >
>> >http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16210
>> >
>> >>
>> >>
>> 
>>http://kb.juniper.net/InfoCenter/index?page=content&id=S:TSB16164&smlogin
>>=
>> >
>> >--
>> >  ++ytti
>> >___
>> >juniper-nsp mailing list juniper-nsp@puck.nether.net
>> >https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> Thanks, this is very useful - does look like our new REs are affected
>>:o(
>

Re: [j-nsp] SSD disks high failure ratio ?

[Paul Stewart]

"Article is in review and not yet ready for viewing"

Paul


On 2013-10-03 5:42 PM, "Michael Smith"  wrote:

>
>On Sep 18, 2013, at 8:36 AM, Phil Mayers  wrote:
>
>> On 18/09/13 16:26, Anhost wrote:
>>> Known issue easily fixed on some shipped in last quarter. Check with
>>>your Juniper rep and they can ID. Not a hardware issue.
>> 
>> Is there a PR or similar?
>
>http://kb.juniper.net/InfoCenter/index?page=content&id=S:TSB16164&smlogin=
>true
>
>Login required.
>
>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

Re: [j-nsp] Junos BNG PPPoE inside a VPLS

[Paul Stewart]

I'm curious on the load sharing you mentioned here...

So you have a VPLS path from DSLAM going to two different BNG nodes at the
same time?  How does the PPPOE session setup work - first one to answer?
(presuming you are referring to PPPOE)

Love to hear more about this as we have talked about scenarios like I
believe you are referring to...

Thanks,

Paul



On 2013-09-26 5:39 PM, "William Jackson" 
wrote:

>The reason for the VPLS use is that we have multiple BNG nodes that load
>share the PPPoE sessions. And to mitigate single points of failure.
>
>I believe Juniper might just be looking into this scenario as well.
>
>
>___
>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 BNG PPPoE inside a VPLS

[Paul Stewart]

Please do share...

We are looking at launching an MX480 with RE1800's for BNG functions
(PPPOE).  I'd really like to haul L2VPN's directly to the box and this
feature in 13.2 mentioned may be the solution...;)

Paul


On 2013-09-24 6:27 PM, "Graham Brown"  wrote:

>I've run into a very strange bug on the MX where PPP through a VPLS
>results
>in the packets being mangled - affected circuits have been migrated to
>L2VPNs. Although a fix is provided in 12.3R4 which we are currently
>testing
>- I'll dig out the PR when I get into the office.
>
>Graham Brown
>Network Engineer
>Snap Internet
>Christchurch, New Zealand
>Twitter - @mountainrescuer 
>LinkedIn 
>
>
>On 24 September 2013 21:46, Mark Tinka  wrote:
>
>> On Tuesday, September 17, 2013 04:05:50 PM Adrien Desportes
>> wrote:
>>
>> > Hello William,
>> >
>> > Before 13.2 you would have to use an external loop to
>> > terminate the vpls on one side and the ppp on the other
>> > side (as lt- interface does not support the proper
>> > encapsulation for ppp).
>> >
>> > Starting 13.2 (that was just released), if you use L2VPN
>> > rather than VPLS to backhaul your DSLAM VLAN, the below
>> > feature might do the job w/o consuming ports for the
>> > external hairpin:
>> >
>> > http://www.juniper.net/techpubs/en_US/junos13.2/topics/co
>> > ncept/pseudowire-subscriber-interfaces-overview.html
>>
>> Now I really don't have to have VPLS at all.
>>
>> Happy days :-).
>>
>> Mark.
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
>-- 
>Graham Brown
>Twitter - @mountainrescuer 
>LinkedIn 
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 Route table Size

[Paul Stewart]

Not to hi-jack this thread but does anyone know *real-world* numbers yet
on the MX104 RE?  I know it has more memory and is supposed to be "faster"
but have no idea yet how much faster it really is?

We don't have any in our network yet but anxious to deploy one end of
year...

Thanks for any input...

Paul



On 2013-09-24 10:40 AM, "Krasimir Avramski"  wrote:

>We are aware ppc on mx80 is slower than intel REs... but the original
>question was for scalability not for performance/convergence.
>Take a look at newer MX104 for more RE performance.
>
>Krasi
>
>
>On 24 September 2013 17:18, Nitzan Tzelniker
>wrote:
>
>> Hi,
>>
>> The problem with the MX80 is not the FIB size but the slow RE
>> The time it take to receive full routing table is long and to put it
>>into
>> the FIB is even worst
>>
>> Nitzan
>>
>>
>> On Tue, Sep 24, 2013 at 10:21 AM, Krasimir Avramski
>>wrote:
>>
>>> Agree.. other elements like counters, filters, descriptors etc .. but
>>>it
>>> is
>>> dynamic allocation which isn't  the case with ichip - 16M bank for
>>> firewalls , 16M for jtree with fixed regions. Although  there is a
>>> workaround(
>>>
>>> 
>>>http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuratio
>>>n/junos-software-jtree-memory-repartitioning.html
>>> )
>>> for
>>> ichip I am calculating the worst case scenario with unique inner vpn
>>>label
>>> usage with composite nexthops.
>>>
>>>
>>> Best Regards,
>>> Krasi
>>>
>>>
>>> On 24 September 2013 09:40, Saku Ytti  wrote:
>>>
>>> > On (2013-09-24 08:49 +0300), Krasimir Avramski wrote:
>>> >
>>> > > Ichip(DPC) has 16-32M RLDRAM and holds 1M routes in FIB, so 256M on
>>> trio
>>> > is
>>> > > huge increment - it is in realm of ~5M routes(since they use
>>>dynamic
>>> > memory
>>> > > allocation to fill up with routes only) and more than 1M labeled
>>> prefix
>>> >
>>> > I don't think this is apples to apples. The 16MB RLDRAM is just for
>>> jtree,
>>> > while 256MB in trio has lot more than just ktree, and some elements
>>>are
>>> > sprayed across the 4*64MB devices which make up the 256MB RDLRAM.
>>> >
>>> > I'd be quite comfortable with 2M FIB throughout the lifecycle of
>>>current
>>> > generation, but I've never heard JNPR quote anything near this for
>>>trio
>>> > scale.
>>> >
>>> > I'm not sure I either understand why it matters if route is labeled
>>>or
>>> > not, if
>>> > each route has unique label, then it means you're wasting NH space,
>>>but
>>> if
>>> > you
>>> > are doing next-hop-self and advertising only loopback labels, then I
>>> don't
>>> > think labeled route should be more expensive.
>>> > (NH lives in RLDRAM in Trio as well, and I believe it specifically is
>>> > sprayed
>>> > across all four RLDRAM devices).
>>> >
>>> > --
>>> >   ++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
>>>
>>
>>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 Route table Size

[Paul Stewart]

This is the busiest MX80 we have in production - RE shows 61% memory used,
box handles this quite well and no concerns currently... Traffic wise,
it's doing about 3Gb/s in it's role

Paul


inet.0: 466698 destinations, 645933 routes (466680 active, 16 holddown, 12
hidden)
  Direct: 22 routes, 22 active
   Local: 21 routes, 21 active
OSPF:   2490 routes,   2489 active
 BGP: 643365 routes, 464138 active
  Static:  4 routes,  4 active
IGMP:  1 routes,  1 active
   Aggregate: 11 routes,  5 active
RSVP: 19 routes,  0 active

inet.3: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
RSVP: 19 routes, 19 active

mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
MPLS:  3 routes,  3 active
RSVP:  6 routes,  6 active
   L2VPN:  4 routes,  4 active
VPLS:  4 routes,  4 active
   
inet6.0: 14397 destinations, 19148 routes (14397 active, 0 holddown, 10
hidden)
  Direct: 18 routes, 11 active
   Local: 16 routes, 16 active
   OSPF3: 79 routes, 79 active
 BGP:  19035 routes,  14291 active

bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
 BGP:  4 routes,  4 active




On 2013-09-23 4:51 AM, "Saku Ytti"  wrote:

>On (2013-09-23 11:24 +1000), Luca Salvatore wrote:
>
>Hi Luca,
>
>> I can't seem to find how many IPv4/IPv6 routes the MX80 range can
>>support.  I know it can do the full BGP table but the info does not seem
>>to be anywhere on juniper.net.
>> I'm sure it used to beŠ. Perhaps I'm blind.  I can find it for EX
>>switches but not MX gear.
>
>The HW has exactly same 256MB RLDRAM as rest of Juniper high-end gear,
>including T4k. I.e. FIB is identical in all MX and new trio generation T
>gear.
>
>You can see how that memory is spread and populated via 'start shell pfe
>network tfeb0' and 'show jnh 0 pool ...'
>
>> Does anyone have a like to official juniper doco that states the max
>>route table for MX80?
>
>Any number would be only indicative/marketing. Much as same as if you'd
>ask
>how many routes can your laptop handle, it would depend what else will be
>using the memory.
>I'd say 1M is reasonable figure, maybe in some environments you could push
>it to 1.5M but you'll certainly not going to see 2M.
>
>I worry about this bit, as I already have boxes with >800k IPv4 prefixes.
>
>-- 
>  ++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] Jloader Update for EX4200

[Paul Stewart]

Haha... Yeah but do you know of anything that works properly? ;)

On 2013-09-20 6:06 AM, "Terje Krogdahl"  wrote:

>On Wed, Sep 18, 2013 at 02:03:48PM -0400, Chuck Anderson wrote:
>> Where do you get the "latest jloader"?  It isn't published in the same
>> place the regular JUNOS images are.  You have to happen to see the
>> TSB/KB article.  I hadn't known about any new one since the original
>> TSB (11.3I20110326_0802_hmerge) until I saw this email.
>
>You can subscribe to tech bulletins here:
>
>http://kb.juniper.net/InfoCenter/index?cmid=no&page=subscriptions
>
>-- 
>Terje Krogdahl
>
>  All roads lead to Rome
> - A clearly confused router (R. Perlman)
>___
>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] MX104 Power Draw (AC)

[Paul Stewart]

Does anyone have an MX104 deployed with dual AC power supplies and using the
4X10G built-in that could give me an idea of how much amperage (AC 110v) it
draws?

I can pull up the specs on it but looking for a reasonable estimate on
amperage draw, hopefully based on real world.

Many thanks,

Paul




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

Re: [j-nsp] Jloader Update for EX4200

[Paul Stewart]

Thank you ­ yes, I'm adding that into our processes here as well to try and
be "safe" about future upgrades.

Cheers,

Paul


From:  Chris Jones 
Date:  Wednesday, 18 September, 2013 12:18 PM
To:  Paul Stewart 
Cc:  "juniper-nsp@puck.nether.net" 
Subject:  Re: [j-nsp] Jloader Update for EX4200

> I'm at a point now where any time I upgrade an EX, I install the latest
> jloader too. It takes an extra 30 seconds and doesn't hurt anything if the
> switch already had that version running.
> 
> 
> On Wed, Sep 18, 2013 at 4:53 AM, Paul Stewart  wrote:
>> Hi there...
>> 
>> I was looking around for something this morning on EX4200 and stumbled
>> across a Jloader update.  Initially I presumed it was the original Jloader
>> update but then realized that it's another update that without applying
>> could have some pretty serious surprises in store...
>> 
>> My blog has a brief on it and link to the Juniper bulletin:
>> http://paulstewart.org/2013/09/18/jloader-release-for-the-ex4200-platform-on
>> ly/ 
>> <http://paulstewart.org/2013/09/18/jloader-release-for-the-ex4200-platform-on
>> ly/> 
>> 
>> Has anyone else come across this or been "bitten" by this yet?
>> 
>> Thanks,
>> 
>> Paul
>> 
>> 
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> -- 
> Chris Jones
> JNCIE-ENT #272
> CCIE# 25655 (R&S)


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

Re: [j-nsp] SSD disks high failure ratio ?

[Paul Stewart]

Only a limited number of them deployed so far but no failures *yet*

Paul



On 2013-09-18 9:43 AM, "Alexandre Snarskii"  wrote:

>
>Hi!
>
>Anyone else experienced high failure ratio with SSD disks installed on
>RE-S-1800x4 or it's just we are that "lucky" to have two disks failed
>within one week ? :(
>
>PS: and, just to fill the gap in the documentation: these disks are not
>the usual 2.5" notebook-like, they are 1.8" mSATA, not yet widely used
>form-factor, so you can't just get replacement from the nearest PC shop.
>Discovering this after ~400km drive adds more fun :)
>
>-- 
>In theory, there is no difference between theory and practice.
>But, in practice, there is.
>
>___
>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] Jloader Update for EX4200

[Paul Stewart]

Hi there...

I was looking around for something this morning on EX4200 and stumbled
across a Jloader update.  Initially I presumed it was the original Jloader
update but then realized that it's another update that without applying
could have some pretty serious surprises in store...

My blog has a brief on it and link to the Juniper bulletin:
http://paulstewart.org/2013/09/18/jloader-release-for-the-ex4200-platform-on
ly/

Has anyone else come across this or been "bitten" by this yet?

Thanks,

Paul



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

Re: [j-nsp] Junos BNG PPPoE inside a VPLS

[Paul Stewart]

I don't think that William will require that feature though as he's
handing off the traffic just as a VLAN to the BNG (vs having the BNG
become a PE router) ?  I understood the question to be whether or not
there's any issues "transporting" PPPOE traffic via an L2VPN or VPLS
instance .. Maybe I misunderstood

Paul


On 2013-09-17 10:05 AM, "Adrien Desportes" 
wrote:

>Hello William,
>
>Before 13.2 you would have to use an external loop to terminate the vpls
>on one side and the ppp on the other side (as lt- interface does not
>support the proper encapsulation for ppp).
>
>Starting 13.2 (that was just released), if you use L2VPN rather than VPLS
>to backhaul your DSLAM VLAN, the below feature might do the job w/o
>consuming ports for the external hairpin:
>
>http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/pseudowire-
>subscriber-interfaces-overview.html
>
>
>Adrien
>
>Le 17 sept. 2013 à 05:39, William Jackson  a
>écrit :
>
>> Gents
>> 
>> Theoretical question here:
>> 
>> I currently have a setup where I transport PPPoE frames between my xDSL
>>boxes and a centralised BNG.
>> I use one vlan tag per xDSL box aggregator box, so all the subs from a
>>specific box have the same vlan tag.
>> 
>> xDSL>(vlan tagged Eth)-->PE-->MPLS Network-->PE-->(vlan tagged
>>Eth)-->BNG(PPPoE) Termination.
>> 
>> This means that the mpls service I use to send my PPPoE traffic to my
>>centralised BNG ends on the BNGs upstream PE node, and I use a standard
>>vlan-tagging interface between BNG and PE.
>> I would like to extend the VPLS service to the BNG ( MX platform ), is
>>it possible to interwork the PPPoE termination into the VPLS service?
>> 
>> I cant seem to find anything about a type of setup like this?
>> 
>> Thank you
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp



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

Re: [j-nsp] L2VPN Termination

[Paul Stewart]

Hey Evgeny...

Yes, worked great.  The key was to include "connectivity-type irb" which
was missing originally...

paul@x> show configuration routing-instances xxx_IP_Transit
instance-type vpls;
vlan-id 100;
routing-interface irb.100;
route-distinguisher xx.xx.xxx:100;
vrf-target target:x:9100;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site Core {
site-identifier 2;
}
connectivity-type irb;
}
}

Traffic wise, this customer does up to 400Mb/s


No LT interfaces involved as end up doing it inside a VPLS instance via
IRB interface :)

Paul


On 2013-09-17 11:24 AM, "Terebizh, Evgeny"  wrote:

>Hi Paul, 
>Just curious. 
>Does it seem to work well?
>What is the maximum amount of traffic going through the lt interface?
>Aren't you facing any limits upon that?
>
>Thanks,   
>/Evgeny
>
>
>From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] on behalf of Paul
>Stewart [p...@paulstewart.org]
>Sent: Wednesday, July 31, 2013 3:05 AM
>To: Krasimir Avramski
>Cc: Juniper-Nsp
>Subject: Re: [j-nsp] L2VPN Termination
>
>Just wanted to say thanks - that worked great and it's now rolled into
>production with the customer....
>
>Paul
>
>
>From:  Krasimir Avramski 
>Date:  Tuesday, 30 July, 2013 2:08 AM
>To:  Paul Stewart 
>Cc:  Juniper-Nsp 
>Subject:  Re: [j-nsp] L2VPN Termination
>
>> Hi,
>>
>> On the core instance: set routing-instances xyz_IP_Transit protocols
>>vpls
>> connectivity-type irb
>>
>> Krasi
>>
>>
>> On Mon, Jul 29, 2013 at 11:35 PM, Paul Stewart 
>>wrote:
>>> Thanks folksŠ
>>>
>>> I have an issue with implementing this and was hoping for a "sanity
>>> check". ;)
>>>
>>> On the "core" side of this implementation I am not taking the VPLS
>>> instance to any form of a physical interface - I only have an IRB
>>> interface and the VPLS path will not come up.  I'm assuming the VPLS
>>>path
>>> won't establish because of lack of a physical interface or is it just
>>> something else that I've misconfigured?
>>>
>>> Core Router (MX480):
>>>
>>> paul@xxx> show configuration routing-instances
>>> xyz_IP_Transit {
>>> instance-type vpls;
>>> vlan-id 100;
>>> routing-interface irb.100;
>>> route-distinguisher xx.xx.xx.xx:100;
>>> vrf-target target:11666:9100;
>>> protocols {
>>> vpls {
>>> site-range 20;
>>> no-tunnel-services;
>>> site Core {
>>> site-identifier 2;
>>> }
>>> }
>>> }
>>> }
>>>
>>> CPE Facing Router (MX80):
>>>
>>>
>>> paul@dis1.peterborough4> show configuration routing-instances
>>> xyz_IP_Transit {
>>> instance-type vpls;
>>> vlan-id 100;
>>> interface ge-1/1/0.100;
>>> route-distinguisher xx.xx.xx.xx:100;
>>> vrf-target target:11666:9100;
>>> protocols {
>>> vpls {
>>> site-range 20;
>>> no-tunnel-services;
>>> site customer {
>>> site-identifier 1;
>>> }
>>> }
>>> }
>>> }
>>>
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>> On 2013-07-26 2:08 PM, "Tarko Tikan"  wrote:
>>>
>>>> >hey,
>>>> >
>>>>> >> Alternatively use routed VPLS on the core box if it is also an MX
>>>>>and a
>>>>> >> standard VPLS instance on the edge:
>>>>> >> 
>>>>>http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configurat
>>>>>io
>>>>> >> n/vpls-irb-solutions.html
>>>> >
>>>> >+1 for this. Not a hack, we have been using this for a while now and
>>>>got
>>>> >all major bugs fixed over time. In production for hundreds of
>>>>thousands
>>>> >of customers.
>>>> >
>>>> >Don't use lt- interfaces if you don't have to.
>>>> >
>>>>> >> Or if you are game then in the next release you should get "psX"
>>>>> >> interfaces on the MX for direct PWHT although it will still be
>>>>>bound to
>>>>> >> an lt- interface underneath.  Documentation already exists for
>>>>>this for
>>>>> >> 13.1.
>>>> >
>>>> >+1 for this as well. This will supposedly support all the features
>>>> >physical ports do so you can do HQoS etc.
>>>> >
>>>> >--
>>>> >tarko
>>>> >___
>>>> >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] Junos BNG PPPoE inside a VPLS

[Paul Stewart]

If I understand this correctly we are doing similar today...

Today, we have several POP's which have switches with VLAN trunks to
various equipment providing PPPOE (fixed wireless, xDSL etc).  At those
switches, we send a trunk up to an MX router.  Each of those VLAN's coming
into the MX is transported as either VPLS or L2VPN back to a centralized
BNG (MX as well).

xDSL--->VLAN Tags--->Switch--->VLAN Tags>MX>L2VPN>MPLS
Network>BNG(MX)

We treat the VLAN's just like any other L2VPN traffic...

Is this what you are thinking of doing?

Thanks,

Paul



On 2013-09-17 8:39 AM, "William Jackson" 
wrote:

>Gents
>
>Theoretical question here:
>
>I currently have a setup where I transport PPPoE frames between my xDSL
>boxes and a centralised BNG.
>I use one vlan tag per xDSL box aggregator box, so all the subs from a
>specific box have the same vlan tag.
>
>xDSL>(vlan tagged Eth)-->PE-->MPLS Network-->PE-->(vlan tagged
>Eth)-->BNG(PPPoE) Termination.
>
>This means that the mpls service I use to send my PPPoE traffic to my
>centralised BNG ends on the BNGs upstream PE node, and I use a standard
>vlan-tagging interface between BNG and PE.
>I would like to extend the VPLS service to the BNG ( MX platform ), is it
>possible to interwork the PPPoE termination into the VPLS service?
>
>I cant seem to find anything about a type of setup like this?
>
>Thank you
>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] L2VPN Termination

[Paul Stewart]

Just wanted to say thanks - that worked great and it's now rolled into
production with the customer

Paul


From:  Krasimir Avramski 
Date:  Tuesday, 30 July, 2013 2:08 AM
To:  Paul Stewart 
Cc:  Juniper-Nsp 
Subject:  Re: [j-nsp] L2VPN Termination

> Hi,
> 
> On the core instance: set routing-instances xyz_IP_Transit protocols vpls
> connectivity-type irb
> 
> Krasi
> 
> 
> On Mon, Jul 29, 2013 at 11:35 PM, Paul Stewart  wrote:
>> Thanks folksŠ
>> 
>> I have an issue with implementing this and was hoping for a "sanity
>> check". ;)
>> 
>> On the "core" side of this implementation I am not taking the VPLS
>> instance to any form of a physical interface - I only have an IRB
>> interface and the VPLS path will not come up.  I'm assuming the VPLS path
>> won't establish because of lack of a physical interface or is it just
>> something else that I've misconfigured?
>> 
>> Core Router (MX480):
>> 
>> paul@xxx> show configuration routing-instances
>> xyz_IP_Transit {
>> instance-type vpls;
>> vlan-id 100;
>> routing-interface irb.100;
>> route-distinguisher xx.xx.xx.xx:100;
>> vrf-target target:11666:9100;
>> protocols {
>> vpls {
>> site-range 20;
>> no-tunnel-services;
>> site Core {
>> site-identifier 2;
>> }
>> }
>> }
>> }
>> 
>> CPE Facing Router (MX80):
>> 
>> 
>> paul@dis1.peterborough4> show configuration routing-instances
>> xyz_IP_Transit {
>> instance-type vpls;
>> vlan-id 100;
>> interface ge-1/1/0.100;
>> route-distinguisher xx.xx.xx.xx:100;
>> vrf-target target:11666:9100;
>> protocols {
>> vpls {
>> site-range 20;
>> no-tunnel-services;
>> site customer {
>> site-identifier 1;
>> }
>> }
>> }
>> }
>> 
>> 
>> Thanks,
>> 
>> Paul
>> 
>> 
>> On 2013-07-26 2:08 PM, "Tarko Tikan"  wrote:
>> 
>>> >hey,
>>> >
>>>> >> Alternatively use routed VPLS on the core box if it is also an MX and a
>>>> >> standard VPLS instance on the edge:
>>>> >> http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio
>>>> >> n/vpls-irb-solutions.html
>>> >
>>> >+1 for this. Not a hack, we have been using this for a while now and got
>>> >all major bugs fixed over time. In production for hundreds of thousands
>>> >of customers.
>>> >
>>> >Don't use lt- interfaces if you don't have to.
>>> >
>>>> >> Or if you are game then in the next release you should get "psX"
>>>> >> interfaces on the MX for direct PWHT although it will still be bound to
>>>> >> an lt- interface underneath.  Documentation already exists for this for
>>>> >> 13.1.
>>> >
>>> >+1 for this as well. This will supposedly support all the features
>>> >physical ports do so you can do HQoS etc.
>>> >
>>> >--
>>> >tarko
>>> >___
>>> >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] vlan-tagging issue

[Paul Stewart]

Do you get a MAC address at all from the other box?

On 2013-07-29 6:17 PM, "Luca Salvatore"  wrote:

>I have an MX5 and SRX240 directly connected to each other.  I need to
>setup multuple VLANs between them.  My config looks like this:
>
>MX - Ge-1/0/2
>
>
>show configuration interfaces ge-1/0/2
>vlan-tagging;
>unit 10 {
>vlan-id 10;
>family inet {
>address 198.xxx.xxx.21/30;
>
>
>
>SRX - Ge-0/0/0
>run show configuration interfaces ge-0/0/0
>unit 0 {
>family ethernet-switching {
>  port-mode trunk;
>  vlan {
>members BGP-Routing-10;
>}
>
>
># run show configuration interfaces vlan unit 10
>family inet {
>   address 198.xxx.xxx.22/30;
>
>
># run show configuration vlans BGP-Routing-10
>vlan-id 10;
>  l3-interface vlan.10;
> I have the vlan.10 interface in the untrust zone with ping and BGP
>enabled:
># ...security zones security-zone untrust interfaces
>vlan.10 {
> host-inbound-traffic {
>system-services {
>  ping;
>  ssh;
>}
>protocols {
>   bgp;
>With this config I have no communication between the MX and SRX.  If I
>change them both to a normal 'family inet' config it works fine.
>Any idea what's going on here?  This should work, or am I missing
>something simple here
>
>___
>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] L2VPN Termination

[Paul Stewart]

Thanks folksŠ

I have an issue with implementing this and was hoping for a "sanity
check". ;)

On the "core" side of this implementation I am not taking the VPLS
instance to any form of a physical interface - I only have an IRB
interface and the VPLS path will not come up.  I'm assuming the VPLS path
won't establish because of lack of a physical interface or is it just
something else that I've misconfigured?

Core Router (MX480):

paul@xxx> show configuration routing-instances
xyz_IP_Transit {
instance-type vpls;
vlan-id 100;
routing-interface irb.100;
route-distinguisher xx.xx.xx.xx:100;
vrf-target target:11666:9100;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site Core {
site-identifier 2;
}
}
}
}

CPE Facing Router (MX80):


paul@dis1.peterborough4> show configuration routing-instances
xyz_IP_Transit {
instance-type vpls;
vlan-id 100;
interface ge-1/1/0.100;
route-distinguisher xx.xx.xx.xx:100;
vrf-target target:11666:9100;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site customer {
site-identifier 1;
}
}
}
}


Thanks,

Paul


On 2013-07-26 2:08 PM, "Tarko Tikan"  wrote:

>hey,
>
>> Alternatively use routed VPLS on the core box if it is also an MX and a
>> standard VPLS instance on the edge:
>> http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio
>> n/vpls-irb-solutions.html
>
>+1 for this. Not a hack, we have been using this for a while now and got
>all major bugs fixed over time. In production for hundreds of thousands
>of customers.
>
>Don't use lt- interfaces if you don't have to.
>
>> Or if you are game then in the next release you should get "psX"
>> interfaces on the MX for direct PWHT although it will still be bound to
>> an lt- interface underneath.  Documentation already exists for this for
>> 13.1.
>
>+1 for this as well. This will supposedly support all the features
>physical ports do so you can do HQoS etc.
>
>-- 
>tarko
>___
>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] L2VPN Termination

[Paul Stewart]

AhhŠ good thinking - we already do that today for some Metaswitch stuff Š
why didn't I think of that before? ;)

On 2013-07-25 7:50 PM, "Caillin Bathern"  wrote:

>Alternatively use routed VPLS on the core box if it is also an MX and a
>standard VPLS instance on the edge:
>http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio
>n/vpls-irb-solutions.html
>
>Or if you are game then in the next release you should get "psX"
>interfaces on the MX for direct PWHT although it will still be bound to
>an lt- interface underneath.  Documentation already exists for this for
>13.1.
>
>Caillin
>
>-Original Message-
>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>Of Paul Stewart
>Sent: Friday, 26 July 2013 8:11 AM
>To: m...@kenweb.org; juniper-nsp@puck.nether.net
>Subject: Re: [j-nsp] L2VPN Termination
>
>>
>>
>>
>>lt- interfaces are definitely a way to do it.  In my case I put an lt-
>>interface in a VPLS instance that was paired to another lt- with
>>"family inet .." in a virtual router instance.  I had a routed VPLS for
>
>>names sake.  In my situation though the lt- interface doesn't move much
>
>>traffic.  I'm unsure of what might happen if you tried to move real
>>traffic through it.
>
>I'll find out what 400 Mb/s or so of traffic looks like on Monday haha
>;)
>
>Paul
>
>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>--
>Message  protected by MailGuard: e-mail anti-virus, anti-spam and
>content filtering.http://www.mailguard.com.au/mg
>



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

Re: [j-nsp] L2VPN Termination

[Paul Stewart]

>
>
>
>lt- interfaces are definitely a way to do it.  In my case I put an lt-
>interface in a VPLS instance that was paired to another lt- with "family
>inet .." in a virtual router instance.  I had a routed VPLS for names
>sake.  In my situation though the lt- interface doesn't move much
>traffic.  I'm unsure of what might happen if you tried to move real
>traffic through it.

I'll find out what 400 Mb/s or so of traffic looks like on Monday haha ;)

Paul


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

Re: [j-nsp] L2VPN Termination

[Paul Stewart]

Thanks - another helpful person from the list sent me some config snippets
offline that should set me in the right direction (using LT interfaces)

Much appreciated,

Paul


On 2013-07-25 12:08 PM, "Mark Tinka"  wrote:

>On Thursday, July 25, 2013 06:54:57 PM Paul Stewart wrote:
>
>> Is there a way using an L2VPN to terminate the path on a
>> loopback or other virtual interface?  At the customer
>> premise, there is a physical port which could be one end
>> of the L2VPN but at a nearby core router I would like to
>> "virtually" terminate the other end therefore creating a
>> point to point /30 for BGP to speak over and provide a
>> full table?
>
>Cisco call this a Routed Pseudowire:
>
>http://www.cisco.com/en/US/docs/ios-
>xml/ios/mp_l2_vpns/configuration/xe-3s/mp-rt-pw-rt-vpls.html
>
>My memory fails me, but I recall someone mentioning
>something like this on this list in past, using lt-
>interfaces. Can't recall; any time I've wanted to do it,
>it's been on a Cisco.
>
>Maybe someone else can chime in.
>
>Mark.


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

[j-nsp] L2VPN Termination

[Paul Stewart]

Hey thereŠ

We have a new BGP customer coming onboard (they are pushing IP Transit from
us).  One of our local POP's is actually right on their campus so we will be
handing off the service directly from an MX port.

This MX is part of our LSP mesh but it does not have a full BGP Internet
table on it.  Several options exist (send full table down to this box, use
multi hop BGP etc) but one of them I'm curious to know if there's a way to
doŠ

Is there a way using an L2VPN to terminate the path on a loopback or other
virtual interface?  At the customer premise, there is a physical port which
could be one end of the L2VPN but at a nearby core router I would like to
"virtually" terminate the other end therefore creating a point to point /30
for BGP to speak over and provide a full table?

Thanks for any input ­ looking for something creative here ;)

Paul



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

Re: [j-nsp] SRX devices upgraded to 2GB ram

[Paul Stewart]

Thanks ­ we're a partner as well (in Canada) so reaching out to our SE
folksŠ.

Cheers,

Paul


From:  Gavin Henry 
Date:  Monday, 22 July, 2013 10:09 AM
To:  Paul Stewart 
Cc:  Skeeve Stevens ,
, Michael Dale 
Subject:  Re: [j-nsp] SRX devices upgraded to 2GB ram

> 
> This is the info we got from our supplier in UK who is a Juniper Elite
> partner:
> 
> " It's the same functionality and operation, just comes with 2G memory. It's
> part of a general refresh of the line that Juniper are doing just now to
> support future applications."
> 
> Not sure how close those applications are. Some more UTM apps?
> 
> Gavin. 


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

Re: [j-nsp] SRX devices upgraded to 2GB ram

[Paul Stewart]

This is definitely concerning as we have quite a number of SRX100/110
deployed (we use them for managed SOHO services).  I haven't seen any
discontinuation notice - anyone else?  I agree though that it's just a
matter of time thoughŠ..

Paul


On 2013-07-21 1:42 AM, "Skeeve Stevens"
 wrote:

>Yes,
>
>Looks like the SX100B and SRX100H have been discontinued and replaced with
>the SRX100H2.
>
>Also SRX110H-V{A,B} replaced with SRX110H2-V{A,B} models.
>
>I think the requirements for UTM and AppSecure needs more RAM.
>
>
>
>
>...Skeeve
>
>*Skeeve Stevens - *eintellego Networks Pty Ltd
>ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>
>Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
>facebook.com/eintellegonetworks ;  
>linkedin.com/in/skeeve
>
>twitter.com/networkceoau ; blog: www.network-ceo.net
>
>
>The Experts Who The Experts Call
>Juniper - Cisco - Cloud
>
>
>On Sun, Jul 21, 2013 at 11:14 AM, Michael Dale 
>wrote:
>
>> Hi All,
>>
>> Just wondering if anyone has noticed that it looks like the entire SRX
>> branch range has been upgraded to 2GB ram:
>> http://www.juniper.net/us/en/local/pdf/datasheets/1000281-en.pdf
>>
>> These models need at least JunOS 12.1X44-D15
>>
>> I just took delivery of a bunch of SRX110s and I suspect these are now
>>the
>> old models. Bit of a pain!
>>
>> Thanks,
>> Michael.
>>
>> ___
>> 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] Vlan question MX

[Paul Stewart]

We have seen it frequently - some carriers we've dealt with will only hand
off this way as it's their "templated method of delivery".  When we are
actually providing the service we ask the customer which they prefer (as
sometimes they want to stack other services onto the same physical
connection).

Paul


On 2013-07-08 6:00 PM, "Tom Storey"  wrote:

>The thing thats confusing me is, who on earth presents a service to a
>customer as a tagged service? Ive never come across such a thing.
>
>If you're plugged in to a router interface on the providers side, why is
>there a need to add VLAN tagging on top? Similarly, if you're plugged in
>to
>a switch, normally the switch port is just an access port, not a trunk.
>
>Someone help me out here... :-)


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

Re: [j-nsp] Vlan question MX

[Paul Stewart]

Hi KeithŠ

Assuming it's on two different interfaces on your side then it doesn't
matter (for layer3 interfaces).  On their side, it's best to ask them as
you want to ensure that the layer2 paths are kept separateŠ assuming they
are running this to two different routers (or even interfaces) then it
probably wouldn't cause issues.

Paul


On 2013-07-08 1:26 PM, "Keith"  wrote:

>Have this setup in the lab on some srx's but want to get some info
>on this.
>
>We have an upstream provider that we use a config:
>
>set interfaces ge-0/1/0 vlan-tagging
>set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
>set interfaces ge-0/1/0 unit 1500 vlan-id 1500
>set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30
>
>
>We are turning up a second connection to them that will be terminated on
>a 10G
>link and want us to use the same thing, vlan 1500, just a different IP
>address.
>
>Will this cause a problem by having the same vlan id on both links to the
>same provider? (I am guessing we are being terminated on different routers
>on their side).
>
>My lab router didn't complain so I'm guessing its probably ok.
>
>Thanks,
>Keith
>
>___
>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] 3rd optics on MX/EX/SRX

[Paul Stewart]

We've used "third party" optics with MX, M, EX, SRX, and J with no
issuesŠ. The closest issue I've come across was some 1000BaseT optics that
didn't fit properly (the optic was slightly narrower than the opening
leaving too much "wiggle room") but they will workedŠ

The optics we have been using are "Prolabs"

Cheers,

Paul


On 2013-06-26 1:25 PM, "Robert Hass"  wrote:

>Hi
>I have only experience with MX platfrom where I can use third party optics
>without any issues.
>
>We're going to buy also some SRX and EX gear. Are EX/SRX accept third
>party
>optics without any issues or we need any special coding ?
>
>Rob
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp



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

Re: [j-nsp] SRX Reliability

[Paul Stewart]

On 2013-06-12 1:18 PM, "Brent Jones"  wrote:

>On Wed, Jun 12, 2013 at 5:41 AM, Andrew Gabriel
>wrote:
>
>> On Wed, Jun 12, 2013 at 3:58 PM, Phil Mayers > >wrote:
>>
>> > We recently evaluated an SRX 3600, and modulo some minor cosmetic bugs
>> and
>> > one major one (PSN-2012-10-754, fixed in later software) they seemed
>> solid
>> > to me. We tested IPv4 & IPv6 layer4 firewalling, AppFW, dynamic
>>routing
>> > with BGP and multicast. It all seemed to work ok, and we have gone
>>ahead
>> > and purchased.
>> >
>> > It might help if you could specify what sort of things you want to do
>>on
>> > them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s can't
>>do)
>> > and so forth.
>> >
>>
>> Hi Phil,
>>
>> Thanks, we are mainly looking at basic FW, VPN, and routing capability,
>> which we need to be rock solid. We do not intend to use the IPS and UTM
>> type features at the moment.
>>
>> Thanks,
>> -Andrew.
>>
>>
>>
>>
>We have several sets of SRX1400s in chassis cluster, plus dozens of SRXs
>from SRX100's up to SRX240's throughout various offices.
>We've had minor bugs here and there, but they get resolved through code or
>workarounds, no more bugs than other vendors really.
>Early on, yes, pre-10, tons of bugs, but 10.4 and greater are solid.
>We do various NAT, FW, VPNs, routing instances, etc, no issues to report.

I'd echo Brent's comments above - we have just over 120 SRX's in
deployment currently and have very few issues.  Make sure you size them
appropriately to the task if using UTM.  Yes, as mentioned before 10.x
there was a lot of issues but we mainly deploy now at 11.4 and they are
solid.


Paul


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

[j-nsp] Tracking VRF Targets

[Paul Stewart]

Hey thereŠ.

Subject line might be a bit confusing but here goes:

In our Juniper network, we have a growing number of LSP's.  Primarily
these LSP's are used for l2vpn connections and some VPLS.
In our l2vpn configurations we assign VRF information which might look
like this:

vrf-target target:12345:2049

We are adopting target:our_asn:vlan_number as our standard way of "naming"
these targets.  Obviously we want to avoid duplications across the
network.  Our eBGP connections are all community driven as well and we
want to avoid assigning VRF-target that may conflict with them.

Is there any suggested "tracking" options that folks use to ensure network
wide unique VRF targets are being assigned?  We could use a spreadsheet
(yuck) or build a database for this ­ just looking for feedback on how
others tackle this today.


Any/all feedback much appreciatedŠ

Paul



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

Re: [j-nsp] Juniper MX480 BNG Feature ?

[Paul Stewart]

Hi Thong - I don't believe there is a way to do this in JunOS Š. Would
love to hear otherwise though.

Paul



On 2013-06-04 6:51 AM, "Thong Hawk Yen"  wrote:

>Hi J-NSP Members,
>
>We are using MX480 with Junos [11.4X27.44] as BRAS and with Juniper
>policy manager SRC with Software version SRC-PE Release 4.2 [V4.2.0.R-16]
>to provide Broadband services over PPPoE.
>The BRAS is the element  that is leasing out IP addresses to the
>subscribers on the ppo interfaces. We notice that there is a high
>percentage of users are actually idling, not sending/receiving any
>traffic but the sessions are taking up ip addresses.
>
>It is not very efficient to time-out their session because customer end
>routers will re-dial. Is there a way to leave the PPPoE session on while
>the BRAS relinquish idling sessions ip address and re-assign when the
>customer traffic is back ?
>
>Please advise. Any feedback from any deployment of other BRAS would be
>helpful. Thanks.
>
>Regards
>thong
>
>
>
>CONFIDENTIALITY
>-
>The contents of and any attachments to this email are private and
>confidential. If you are not the intended recipient or addressee
>indicated in this message, please notify the sender of the error and
>destroy the email and any attachments. Please do not reproduce the
>contents of the email or its attachments as such reproduction is a breach
>of confidentiality and for which legal action including injunctive relief
>may be sought against you. If it is your company policy that official
>communications are not by email, please advise immediately. Any opinions,
>conclusions and other information in this message that do not relate to
>the official business of TIME dotCom shall be understood as neither given
>nor endorsed by TIME dotCom, nor shall TIME dotCom shall be liable
>(directly or vicariously) for such opinions, statements or communications.
>___
>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] EX2200 OSPF question

[Paul Stewart]

Hey BrandonŠ.

We had one scenario that comes to mind where we pushed 600Mbps (layer3)
across an EX2200-C and it started dropping packets like crazy Š that was
on an "older" software image at the time which was prone to several other
problems so perhaps it was a software related issue.  We never went back
to that box for the routing requirements to verify so hopefully someone
else can chime in to share their experiences.  Typically we only use them
for layer2Š

Cheers,

Paul


On 2013-05-22 5:25 PM, "Brandon Ross"  wrote:

>On Wed, 22 May 2013, Paul Stewart wrote:
>
>> You have to buy the extended feature license on the EX2200 to run OSPF.
>> We have a bunch of EX2200-C deployed that have OSPF routes on them and
>> they work fine - to qualify that though, there is very little traffic
>> through them at layer3 - cant' see them handling much layer3 traffic.
>> That deployment is mainly layer2 oriented.
>
>Can you explain your concerns about layer 3 performance?  I was under the
>impression that the EX2200 was a hardware forwarding platform.  Am I
>incorrect?
>
>-- 
>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

Re: [j-nsp] EX2200 OSPF question

[Paul Stewart]

You have to buy the extended feature license on the EX2200 to run OSPF.
We have a bunch of EX2200-C deployed that have OSPF routes on them and
they work fine - to qualify that though, there is very little traffic
through them at layer3 - cant' see them handling much layer3 traffic.
That deployment is mainly layer2 oriented.

Also, on certain releases OSPFv3 would function and work fairly well only
to upgrade and then the feature stopped working. When I asked Juniper they
told me that OSPFv3 wasn't supported at all at which point I asked them
why we were able to run it for about a year on some older software
releases with no problems - answer I got was that the code was included by
mistake Š geeshŠ.

Paul


On 2013-05-22 5:10 PM, "joe mcguckin"  wrote:

>
>My understanding is that the EX2200 can run OSPF on 4 interfaces with the
>standard software license - right?
>
>How well does the OSPF work? Just from goofing around on the console, the
>response of the switch seems a little slow - like the cpu
>is a bit underpowered...
>
>Thanks,
>
>Joe
>
>Joe McGuckin
>ViaNet Communications
>
>j...@via.net
>650-207-0372 cell
>650-213-1302 office
>650-969-2124 fax
>
>
>
>
>___
>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] 1000BaseT SFP

[Paul Stewart]

We have some but as someone else pointed out, they are tri-rate we are
usingŠ.
Paul


On 2013-05-01 1:35 PM, "OBrien, Will"  wrote:

>I've yet to see any gig copper sfp talk at 100mb. Ever.
>
>Will O'Brien
>
>On May 1, 2013, at 12:32 PM, "Keith"  wrote:
>
>> Trying to connect GE copper SFP on MX to a 100meg port on a cisco
>>switch, 3560 actually.
>> 
>> ge-0/0/2 {
>> description "<< Test Link >>";
>> enable;
>> speed 100m;
>> link-mode full-duplex;
>> unit 0 {
>> family inet {
>> address 192.168.1.2/26;
>> 
>> show interface ge-0/0/2:
>> 
>> Physical interface: ge-0/0/2, Enabled, Physical link is Up
>>   Interface index: 136, SNMP ifIndex: 511
>>   Description: << Test Link >>
>>   Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, BPDU Error:
>>None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
>>Disabled, Flow control: Enabled,
>>   Auto-negotiation: Enabled, Remote fault: Online
>>   Device flags   : Present Running
>>   Interface flags: SNMP-Traps Internal: 0x4000
>>   Link flags : None
>>   CoS queues : 8 supported, 8 maximum usable queues
>>   Current address: 80:71:1f:91:10:02, Hardware address:
>>80:71:1f:91:10:02
>>   Last flapped   : 2011-04-28 13:44:09 PDT (1w5d 03:08 ago)
>>   Input rate : 0 bps (0 pps)
>>   Output rate: 0 bps (0 pps)
>>   Active alarms  : None
>>   Active defects : None
>> 
>>   Logical interface ge-0/0/2.0 (Index 74) (SNMP ifIndex 522)
>> Flags: SNMP-Traps 0x400 Encapsulation: ENET2
>> Input packets : 0
>> Output packets: 19
>> Protocol inet, MTU: 1500
>>   Flags: Sendbcast-pkt-to-re
>>   Addresses, Flags: Is-Preferred Is-Primary
>> Destination: 192.168.1.0/26, Local: 192.168.1.2, Broadcast:
>>192.168.1.63
>> Protocol multiservice, MTU: Unlimited
>> 
>> Swapped cables etc, my question is can these 1000BaseT SFP's work at
>>100M? I can configure them as such
>> but do they actually work at 100M?
>> 
>> Thanks,
>> Keith
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp



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

[j-nsp] PFE Drops

[Paul Stewart]

Can anyone point me to documentation on the specifics of the following
output?  I'm trying to understand specifically "Software input medium drops"
I believe at this pointŠ.

What's happening is the device becomes non-pingable (ICMP) for a few hours
about once a week and I'm trying to figure out why.  It only becomes
non-pingable from our monitoring system which as you can imagine is causing
us some grief ;)  The monitoring system relies on ping to test reachability.
It's important to note that during times that the device (EX or SRX
specifically) is not pingable, we can continue to collect SNMP data with no
issues.

Thanks,

Paul


Packet Forwarding Engine traffic statistics:

Input  packets: 41503426   35 pps

Output packets: 38415378   33 pps

Packet Forwarding Engine local traffic statistics:

Local packets input :  2039823

Local packets output:   230307

Software input control plane drops  :0

Software input high drops   :0

Software input medium drops :  843

Software input low drops:0

Software output drops   :0

Hardware input drops:0

Packet Forwarding Engine local protocol statistics:

HDLC keepalives:0

ATM OAM:0

Frame Relay LMI:0

PPP LCP/NCP:0

OSPF hello :0

OSPF3 hello:0

RSVP hello :0

LDP hello  :0

BFD:0

IS-IS IIH  :0

LACP   :0

ARP:  1922846

ETHER OAM  :0

Unknown:0

Packet Forwarding Engine hardware discard statistics:

Timeout:0

Truncated key  :0

Bits to test   :0

Data error :0

Stack underflow:0

Stack overflow :0

Normal discard :  1503184

Extended discard   :  204

Invalid interface  :0

Info cell drops:0

Fabric drops   :0

Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU
Error statistics:

Input Checksum :0

Output MTU :0




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

Re: [j-nsp] 1000BaseT SFP

[Paul Stewart]

We haven't had any issues using Prolabs 3rd party SFP's in MX platform
before at 100meg at least on DPCE cards - can't remember if we ever tried
with Juniper "authentic" before or notŠ  Also we have used them on MX80
platform (20x1 GE MIC card)

Paul


On 2013-05-01 2:20 PM, "Serge Vautour"  wrote:

>Very likely no. What's the SFP model number and the line card type you're
>using on the MX?
>
>Serge
>
>
>
>
> From: Keith 
>To: juniper-nsp@puck.nether.net
>Sent: Tuesday, May 10, 2011 8:59:06 PM
>Subject: [j-nsp] 1000BaseT SFP
> 
>
>
>Trying to connect GE copper SFP on MX to a 100meg port on a cisco switch,
>3560 actually.
>
>
>ge-0/0/2 { description "<< Test Link >>"; enable; speed 100m; link-mode
>full-duplex; unit 0 { family inet { address 192.168.1.2/26; show
>interface ge-0/0/2: Physical interface: ge-0/0/2, Enabled, Physical link
>is Up Interface index: 136, SNMP ifIndex: 511 Description: << Test Link
>>> Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, BPDU Error:
>>>None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
>>>Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote
>>>fault: Online Device flags   : Present Running Interface flags:
>>>SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8
>>>supported, 8 maximum usable queues Current address: 80:71:1f:91:10:02,
>>>Hardware address: 80:71:1f:91:10:02 Last flapped   : 2011-04-28
>>>13:44:09 PDT (1w5d 03:08 ago) Input rate : 0 bps (0 pps) Output
>>>rate: 0 bps (0 pps) Active alarms  : None Active defects : None
>>>Logical interface ge-0/0/2.0 (Index 74) (SNMP ifIndex 522) Flags:
>>>SNMP-Traps
> 0x400 Encapsulation: ENET2 Input packets : 0 Output packets: 19
>Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re Addresses, Flags:
>Is-Preferred Is-Primary Destination: 192.168.1.0/26, Local: 192.168.1.2,
>Broadcast: 192.168.1.63 Protocol multiservice, MTU: Unlimited Swapped
>cables etc, my question is can these 1000BaseT SFP's work at 100M? I can
>configure them as such
>but do they actually work at 100M? Thanks,
>Keith 
>
>
>
>___
>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] Price for MX5

[Paul Stewart]

You will get referred to a Juniper partner no matter which route you take -
Juniper doesn't sell direct (except to some very large accounts).

Where are you located geographically?

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Luan Nguyen
Sent: February-26-13 2:56 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Price for MX5

Hi folks,

If I need a quote for a couple of MX5, do I just call juniper sale up and
ask for a quote?
will it be cheaper to go through their resellers?

Thanks.

Regards,

-Luan
___
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] Framing Errors

[Paul Stewart]

Hi there.

 

I feel like I'm missing the obvious from shortage of sleep so hoping the
list can help me out ;)

 

We have a number of WAN connections that have wireless bridges in the middle
(Redline AN80 to be specific).  Each end of the wireless link has a  Juniper
EX2200 switch.  On the "uplink" interfaces we are seeing stats that look
like this:

 

paul@dis1.baseline1> show interfaces ge-0/0/0 extensive

 

  Traffic statistics:

   Input  bytes  :5167733467665  2825888 bps

   Output bytes  : 83528365  1871192 bps

   Input  packets:   4769429553  591 pps

   Output packets:   3316784471  541 pps

 

  Input errors:

Errors: 25696, Drops: 0, Framing errors: 25696, Runts: 0, Policed
discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts:
0, FIFO errors: 0, Resource errors: 0

 

  MAC statistics:  Receive Transmit

Total octets 5167733467665 83528365

Total packets   4769429553   3316784471

Unicast packets 4767231806   3312526230

Broadcast packets80016  1053853

Multicast packets  2117731  3204388

CRC/Align errors 256960

FIFO errors  00

MAC control frames   00

MAC pause frames 00

Oversized frames 0

Jabber frames2

Fragment frames149

Code violations  0

 

I've tried to abbreviate this output but my area of concern here is the
number of "errors" which seem to be specifically Framing Errors.

 

Ge-0/0/0 in this example is that same as all of the other sites we see the
issue - it's a trunked interface carrying either a few VLAN's upwards of in
some situations 20-25 VLAN's:

 

  Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
Disabled, Flow control: Enabled,

  Auto-negotiation: Enabled, Remote fault: Online

 

  Autonegotiation information:

Negotiation status: Complete

Link partner:

Link mode: Full-duplex, Flow control: None, Remote fault: OK, Link
partner Speed: 100 Mbps

Local resolution:

Flow control: Symmetric, Remote fault: Link OK

 

I guess I'm wondering why the MTU wouldn't be 1518 when trunked?  Should
there not be an additional 4 bytes for the VLAN headers?  My MTU magic is
failing me today..

 

Interface config looks like this:

 

paul@dis1.baseline1> show configuration interfaces ge-0/0/0

description ge1-1-0.dis1.cavan2;

unit 0 {

family ethernet-switching {

port-mode trunk;

vlan {

members [ OSPF_Cavan PPPOE_Baseline_24 PPPOE_Baseline_900
PPPOE_KawarthaTrails_24 PPPOE_KawarthaTrails_365 PPPOE_Baseline_365 ];

}

}

}

 

I've talked to Redline (the wireless bridge manufacturer) and they are
pointing the finger at cabling problems between their gear and the Juniper
switch - still a possibility but we've replaced everything already at a few
sites so I'm leaning towards a Redline issue itself, but wanted to rule out
something obvious in the Juniper side of things causing the Framing Errors.
We also have some sites where the number of "carrier transitions" are quite
high (again Redline radios in middle and EX2200 on each side).

 

Any insight/input much appreciated - would be really nice if someone on this
list has a similar setup and could share their experiences.

 

Thanks,

 

Paul

 

 

 

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

Re: [j-nsp] MX80 BGP performance after reboot

[Paul Stewart]

I was there for that lightning talk (and very recently seen that "feature"
actually happening) but what's getting described here by the OP doesn't seem
to be the same maybe I'm misunderstanding.

Paul

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler
Sent: February-11-13 6:59 PM
To: Juniper NSP
Subject: Re: [j-nsp] MX80 BGP performance after reboot

On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
 wrote:
> I noticed that a MX80 takes quite a long time after reboot to put all 
> routes into the KRT. Is that normal for that box? It takes around 10 
> minutes after BGP is established to get all the routes into the KRT

Yes, the routes taking a long time to install is "normal,"
unfortunately.  I feel like it has got worse since 10.4 but that might be my
imagination.

I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was
something like "if you want your routers to install routes, call Juniper and
reference PR# because they do not want to fix this bug."

I am hopeful that the move away from a single Junos release strategy to some
segregation among different products will allow Juniper to be more flexible
in how they allocate development resources to different platforms.

If I had to guess, I'd say the ddos-related log messages you are reading are
related to excessive need to generate ttl_exceeded packets because of
routing loops while BGP is announcing to neighboring routers but the routes
are not actually installed in the FIB yet.
Even if I am wrong about the specifics here, I am certain it is only a
symptom of the problem which is unrelated to the ddos-protection feature.

--
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX80 BGP performance after reboot

[Paul Stewart]

Interesting...

MX80 running 11.4R6.5 - takes about 5-7 minutes to come online, load BGP
tables and fully converge as a reference point:

inet.0: 446697 destinations, 609039 routes (446678 active, 13 holddown, 17
hidden)
  Direct: 21 routes, 21 active
   Local: 20 routes, 20 active
OSPF:   2324 routes,   2306 active
 BGP: 606641 routes, 444309 active
  Static:  3 routes,  3 active
IGMP:  1 routes,  1 active
   Aggregate: 10 routes,  4 active
RSVP: 19 routes, 14 active

inet.3: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
RSVP: 14 routes, 14 active

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
MPLS:  3 routes,  3 active
RSVP:  8 routes,  8 active
   L2VPN:  4 routes,  4 active
VPLS:  4 routes,  4 active

inet6.0: 79743 destinations, 83769 routes (79741 active, 1 holddown, 5
hidden)
  Direct: 18 routes, 11 active
   Local: 16 routes, 16 active
   OSPF3: 82 routes, 82 active
 BGP:  83653 routes,  79632 active

bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
 BGP:  4 routes,  4 active


I don't recall ever seeing any errors though as you describe... 

Paul



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian
Wiesinger
Sent: February-11-13 6:50 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 BGP performance after reboot

* Paul Stewart  [2013-02-12 00:36]:
> What version of JunOS?  Just one full table or many?

11.4R6-S1

Combined Full-Table from a few iBGP peers and around 70k routes from an IXP.
Approx. 700k Routes in RIB.

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] Are these temps high enough to cause any issues?

[Paul Stewart]

Hey there...

For reference, I logged into an MX80 that runs in a warm environment - we've
never lost any optics from this box:

Module temperature:  53 degrees C / 127 degrees
F
Module temperature:  62 degrees C / 143 degrees
F
Module temperature:  50 degrees C / 122 degrees
F
Module temperature:  54 degrees C / 129 degrees
F
Module temperature:  52 degrees C / 125 degrees
F
Module temperature:  52 degrees C / 126 degrees
F
Module temperature:  44 degrees C / 111 degrees
F
Module temperature:  45 degrees C / 114 degrees
F
Module temperature:  49 degrees C / 120 degrees
F
Module temperature:  44 degrees C / 110 degrees
F
Module temperature:  51 degrees C / 124 degrees
F
Module temperature:  49 degrees C / 121 degrees
F
Module temperature:  48 degrees C / 118 degrees
F

Class Item   Status Measurement
Temp  PEM 0  OK
  PEM 1  OK
  RE 0 IntakeOK 46 degrees C / 114 degrees F
  RE 0 Front Exhaust OK 49 degrees C / 120 degrees F
  RE 0 Rear Exhaust  OK 47 degrees C / 116 degrees F
  Routing Engine OK 54 degrees C / 129 degrees F
  Routing Engine CPU OK 66 degrees C / 150 degrees F
  TFEB 0 QX 0 TSen   OK 52 degrees C / 125 degrees F
  TFEB 0 QX 0 Chip   OK 60 degrees C / 140 degrees F
  TFEB 0 LU 0 TSen   OK 52 degrees C / 125 degrees F
  TFEB 0 LU 0 Chip   OK 67 degrees C / 152 degrees F
  TFEB 0 MQ 0 TSen   OK 52 degrees C / 125 degrees F
  TFEB 0 MQ 0 Chip   OK 61 degrees C / 141 degrees F
  TFEB 0 TBB PFE TSenOK 46 degrees C / 114 degrees F
  TFEB 0 TBB PFE ChipOK 56 degrees C / 132 degrees F
  TFEB 0 TFEB PCIE TSen  OK 53 degrees C / 127 degrees F
  TFEB 0 TFEB PCIE Chip  OK 68 degrees C / 154 degrees F
Fans  Fan 1  OK Spinning at high speed
  Fan 2  OK Spinning at high speed
  Fan 3  OK Spinning at high speed
  Fan 4  OK Spinning at high speed
  Fan 5  OK Spinning at high speed

For what it's worth...

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean
Sent: February-11-13 6:32 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Are these temps high enough to cause any issues?

Here is the output of a few commands (bolded).

In the past two weeks, one SFP from each of our border MX80's have failed.
They were juniper 1gig sx modules. I'm not sure if this is coincidence, or
if its heat related. According to the thresholds, things seem to be OK, but
I figured I should ask. For instance, the warn threshold for the modules are
like 180deg F, not sure what it is for the chassis or individual chips.
*
*
*someuser@somehost.somewhere>* *show interfaces diagnostics optics |match
temperature |except high|except low *
Module temperature:  50 degrees C / 122 degrees
F
Module temperature:  50 degrees C / 122 degrees
F
Module temperature:  48 degrees C / 119 degrees
F
Module temperature:  47 degrees C / 117 degrees
F
Module temperature:  49 degrees C / 120 degrees
F
Module temperature:  51 degrees C / 124 degrees
F

*someuser@somehost.somewhere> show chassis environment *
Class Item   Status Measurement
Temp  PEM 0  OK
  PEM 1  OK
  RE 0 IntakeOK 48 degrees C / 118 degrees F
  RE 0 Front Exhaust OK 51 degrees C / 123 degrees F
  RE 0 Rear Exhaust  OK 48 degrees C / 118 degrees F
  Routing Engine OK 55 degrees C / 131 degrees F
  Routing Engine CPU OK 66 degrees C / 150 degrees F
  TFEB 0 QX 0 TSen   OK 51 degrees C / 123 degrees F
  TFEB 0 QX 0 Chip   OK 61 degrees C / 141 degrees F
  TFEB 0 LU 0 TSen   OK 51 degrees C / 123 degrees F
  TFEB 0 LU 0 Chip   OK 66 degrees C / 150 degrees F
  

Re: [j-nsp] MX80 BGP performance after reboot

[Paul Stewart]

What version of JunOS?  Just one full table or many?

They are not the fastest boxes but we haven't seen these issues that I know
of .

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian
Wiesinger
Sent: February-11-13 6:16 PM
To: Juniper NSP
Subject: [j-nsp] MX80 BGP performance after reboot

Hi,

I noticed that a MX80 takes quite a long time after reboot to put all routes
into the KRT. Is that normal for that box? It takes around 10 minutes after
BGP is established to get all the routes into the KRT and in the meantime we
get messages like that every few seconds:

/kernel: rt_pfe_veto: Possible slowest client is sampled. States processed -
953500. States to be processed - 21526
rpd[1298]: RPD_KRT_Q_RETRIES: Route Update: No buffer space available
/kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2, rtsm_id
5, msg type 2
/kernel: rt_pfe_veto: Possible slowest client is sampled. States processed -
953500. States to be processed - 21545
rpd[1298]: RPD_KRT_Q_RETRIES: Route Update: No buffer space available
/kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2, rtsm_id
5, msg type 2
/kernel: rt_pfe_veto: Possible slowest client is sampled. States processed -
953500. States to be processed - 21558
/kernel: rt_pfe_veto: Possible second slowest client is xdpc0. States
processed - 1064571. States to be processed - 23

Oh and DDOS protection is also acting up:

jddosd[1323]: DDOS_PROTOCOL_VIOLATION_SET: Protocol TTL:aggregate is
violated at fpc 0 for 1 times, started at 2013-02-11 23:50:39 CET, last seen
at 2013-02-11 23:50:39 CET
jddosd[1323]: DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol TTL:aggregate has
returned to normal. Violated at fpc 0 for 1 times, from 2013-02-11 23:58:14
CET to 2013-02-11 23:58:14 CET

Any experiences from anyone else here?

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] Multicast Traffic over L2VPN

[Paul Stewart]

Can you explain this a bit more?   Sorry, this has me really curious and I
obviously need to get more up to speed on multicast because we are moving
towards IPTV shortly ;)

Here's the routing instance that is now working:

VLAN69-xxx-Headend {
instance-type vpls;
vlan-id 69;
interface ge-1/0/5.69;
route-distinguisher xx.xx.100.84:69;
vrf-target target::9069;
protocols {
vpls {
site-range 3;
no-tunnel-services;
site -DAC {
site-identifier 1;
}
}
}
}

We didn't configure anything specific to multicast.

Thanks,

Paul


-Original Message-
From: Tima Maryin [mailto:timamar...@mail.ru] 
Sent: January-29-13 2:54 PM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Multicast Traffic over L2VPN

On 29.01.2013 22:09, Paul Stewart wrote:
>
> We converted the path from a routing-instance type of L2VPN to that of 
> VPLS and now things are working fine.


Where you can also configure p2mp LSP for multicast traffic.

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

Re: [j-nsp] Multicast Traffic over L2VPN

[Paul Stewart]

Yeah - not much difference ... l2circuit using LDP sounds like it's worked
fine for years for you... we were trying l2vpn (MBGP/RSVP) but can't
understand why it would matter

We moved to VPLS and everything works - would love to know why we couldn't
pass traffic with l2vpn specifically  oh well I guess ;)

Thanks,

Paul


-Original Message-
From: sth...@nethelp.no [mailto:sth...@nethelp.no] 
Sent: January-29-13 2:29 PM
To: p...@paulstewart.org
Cc: ha...@juniper.net; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Multicast Traffic over L2VPN

> We converted the path from a routing-instance type of L2VPN to that of 
> VPLS and now things are working fine.  I read through some RFC docs 
> etc to try and better  understand why that made it work - came up with 
> some reading about VPLS multicast support that L2VPN didn't have and 
> then my head hurt trying to understand it LOL ;)

We have carried lots of multicast traffic on l2circuit (Martini type
point-to-point pseudowire) for years. Never had a problem.

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] Multicast Traffic over L2VPN

[Paul Stewart]

Hi Harry and thanks for the posting.

We converted the path from a routing-instance type of L2VPN to that of VPLS
and now things are working fine.  I read through some RFC docs etc to try
and better  understand why that made it work - came up with some reading
about VPLS multicast support that L2VPN didn't have and then my head hurt
trying to understand it LOL ;)

Thanks,

Paul


-Original Message-
From: Harry Reynolds [mailto:ha...@juniper.net] 
Sent: January-29-13 1:04 PM
To: Paul Stewart; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Multicast Traffic over L2VPN

Yes, I believe for L2 mcast should just work. This assumes the mcast is not
using some reserved MAC value such as that used by spanning tree, which if
not in a L2 port mode might be consumed locally, rather than transported to
the far end. 

Perhaps post your config (more than one type of l2 service, vpls vs. l2 ckt,
for example) and folks can comment.

HTHs


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Tuesday, January 29, 2013 5:15 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Multicast Traffic over L2VPN

Hi there..

 

I'm confused about something and wanted to ask the list for help..;)

 

Is there anything special required to carry multicast traffic across a L2VPN
path?  We have a situation where multicast isn't working properly and
there's a L2VPN path in the middle.  I have found lots of documentation on
layer 3 VPN's in Juniper and all the steps involved to bring that up . but
with a layer2 VPN does this not just pass through?

 

Sorry if this seems like a basic question - my love for multicast is pretty
limited.

 

Paul

 

 

 

___
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] Multicast Traffic over L2VPN

[Paul Stewart]

Hi there..

 

I'm confused about something and wanted to ask the list for help..;)

 

Is there anything special required to carry multicast traffic across a L2VPN
path?  We have a situation where multicast isn't working properly and
there's a L2VPN path in the middle.  I have found lots of documentation on
layer 3 VPN's in Juniper and all the steps involved to bring that up . but
with a layer2 VPN does this not just pass through?

 

Sorry if this seems like a basic question - my love for multicast is pretty
limited.

 

Paul

 

 

 

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

Re: [j-nsp] EX Switch Question

[Paul Stewart]

Thanks Pavel...

So is there anything reasonably priced in the Juniper lineup for this kind
of situation or do we look at Cisco/other?

Cheers,

Paul


-Original Message-
From: Pavel Lunin [mailto:plu...@senetsy.ru] 
Sent: January-10-13 11:32 AM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX Switch Question


Just don't go there. EX is in no way a metro SP switch.

Very common case, we've been discussing it with many customers, who
their-selves want a Juniper metro SP solution, maybe once a week since the
EX series was launched. After all that I am 100% sure this is not what EX is
all about.

10.01.2013 18:23, Paul Stewart wrote:
> Thanks but this is pure layer2 deployments (typically).  I should have 
> clarified that some of the VLAN's have IP but most are to link 
> buildings together within a metro etc
>
> Really, this is more of a metro ethernet type of environment.
>
> I'll read up again on this but I'm comparing this against a tried and 
> true Cisco solution we've used many times and it just worked (rather 
> simply too). with what I've seen/read so far on the Juniper front, 
> this is going to be a problem to implement - really hoping someone can 
> prove me wrong though ;)
>
> Paul
>
>


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

Re: [j-nsp] EX Switch Question

[Paul Stewart]

Thanks

We have a 6500 installation running hybrid IOS/CatOS and the CatOS component
does it quite well.  On another installation with MSFC2 supervisors and
native IOS we also have it working... both installations are very ancient
10+  years

:)

Paul


-Original Message-
From: Benny Amorsen [mailto:benny+use...@amorsen.dk] 
Sent: January-10-13 9:41 AM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX Switch Question

"Paul Stewart"  writes:

> Per VLAN ingress and egress bandwidth control (rate limiting on a per 
> VLAN basis with burst)

That sounds like hierarchial shaping. You need MX for that, and even then
you may meet challenges doing it on ingress.

I would have thought that the 6500 needed ES cards for that, but those have
only been available for about 5 years?


/Benny


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

Re: [j-nsp] EX Switch Question

[Paul Stewart]

Thank you - yes, both of those issues you highlighted have created problems
for us  especially lack of "tcp established"

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Emmanuel Halbwachs
Sent: January-10-13 9:59 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX Switch Question

Hello,

Tobias Heister (Thu 2013-01-10 14:31:40 +0100) :
> We have not yet found an EX platform (tried
> 2200/3200/4200/4500/8200) which supported policing on egress (using 
> Firewall filters and policing, never tried using QoS)

I don't know for the OP needs but for shure EX4200 does not have:

- syslog in firewall filters
- tcp flags (e. g. established) in firewall filters

in egress (physical or VLAN interface). 

Juniper confirmed that this is a hardware limitation. That was the reason we
went MX.

Cheers,

-- 
Emmanuel Halbwachs  Observatoire de Paris
Resp. Réseau/Sécurité   5 Place Jules Janssen
tel  : +33 1 45 07 75 54 F 92195 MEUDON CEDEX
   véhicules : 11 av. Marcellin Berthelot
___
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] EX Switch Question

[Paul Stewart]

Thanks - yup, we are just deploying some EX4500 at a customer site and ended
up keeping their EX4200's just for 100 meg ports ;(

-Original Message-
From: James S. Smith [mailto:jsm...@windmobile.ca] 
Sent: January-10-13 9:00 AM
To: 'li...@tobias-heister.de'; 'p...@paulstewart.org'
Cc: 'juniper-nsp@puck.nether.net'
Subject: Re: [j-nsp] EX Switch Question

Just avoid the 4500 if you need anything less than 1G copper.  The ports on
the 4500 won't negotiate to 10 or 100.  I was told by the sales engineer
that this switch is a "top of rack" switch so it doesn't support anything
less than 1G. 

I found that funny since I have a whole rack of Avaya gear that Avaya
insists must have the switch set to 100/Full.


- Original Message -
From: Tobias Heister [mailto:li...@tobias-heister.de]
Sent: Thursday, January 10, 2013 08:31 AM
To: Paul Stewart 
Cc: juniper-nsp@puck.nether.net 
Subject: Re: [j-nsp] EX Switch Question

Hi,

Am 10.01.2013 14:03, schrieb Paul Stewart:
> Per port ingress and egress bandwidth control (rate limiting with 
> burst)
> 
> Per VLAN ingress and egress bandwidth control (rate limiting on a per 
> VLAN basis with burst)

As you mentioned this could be the problem or showstopper.
We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which
supported policing on egress (using Firewall filters and policing, never
tried using QoS)

Just tested it on en EX8216 running 10.4R9 "Referenced filter 'test123' can
not be used as policer not supported on egress"

I do not know if this is a hardware or software problem and if it may be
solved in later releases (if software problem). The latest code we run is
11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of
remember it being a hardware problem but i am not sure.

We would have a couple use cases for this feature too so we would be
interested in any findings.

regards
Tobias


___
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] EX Switch Question

[Paul Stewart]

Thanks but this is pure layer2 deployments (typically).  I should have
clarified that some of the VLAN's have IP but most are to link buildings
together within a metro etc

Really, this is more of a metro ethernet type of environment.

I'll read up again on this but I'm comparing this against a tried and true
Cisco solution we've used many times and it just worked (rather simply
too). with what I've seen/read so far on the Juniper front, this is
going to be a problem to implement - really hoping someone can prove me
wrong though ;)

Paul


-Original Message-
From: Per Granath [mailto:per.gran...@gcc.com.cy] 
Sent: January-10-13 9:18 AM
To: Paul Stewart; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] EX Switch Question

The general idea is to do:

Policing (firewall filter) on ingress
Shaping (CoS) on egress

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010073-en.pdf

Shaping is typically per port, and I am not sure if you can do that per
VLAN.
But the feature guide say there is CoS support on RVIs...

https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/conc
ept/ex-series-software-features-overview.html#cos-features-by-platform-table

In that case, the EX4200 virtual chassis seems good.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Thursday, January 10, 2013 3:04 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX Switch Question


Per port ingress and egress bandwidth control (rate limiting with burst)

Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN
basis with burst)


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

[j-nsp] EX Switch Question

[Paul Stewart]

Hi folks..

 

We have a customer that has a Cisco 6500 - very old and they want to retire
it out of service (12+ years old).  The customer is a municipal fiber
provider and their main business is providing connectivity (vs providing
Internet).

 

They have approached us about a Juniper replacement and I've been thinking
about EX series but looking for some input please.

 

Their requirements are what would seem fairly basic:

 

40-50 switch ports supporting up to 1G (all copper today as they use media
converters and wish to continue using them)

Dot1q support on each port (yup, easy enough)

Per port ingress and egress bandwidth control (rate limiting with burst)

Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN
basis with burst)

 

When I have looked at the EX2200,3300,4200 series (which I'm reasonably
familiar with) I don't see a way to do this.  Our Juniper SE says the issue
is ingress bandwidth control and that the rest of the criteria is easily
met.

 

As they also would prefer and are also used to having a chassis level box
with power redundancy, switch processor redundancy etc then this has me
looking at EX6200/8200 series.  The EX6200 seems to be pretty much EX4200
"modules" so not sure if it solves my problem - thinking more towards EX8200
but not familiar enough to know if it will meet this criteria especially
ingress *and* egress per VLAN bandwidth controls.

 

Any thoughts are much appreciated ;)

 

Paul

 

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

Re: [j-nsp] Question about Routing Engine Redundancy on MX

[Paul Stewart]

Thanks RAS.. that's interesting as we've never actually tried that...

Have you tried this in a production environment or would you?  Do we have
any idea on whether or not JTAC would support this configuration officially?

I realize these are loaded questions - just really curious on this topic as
it opens up some "new possibilities" for us in some deployments...  Our SE
basically told us to "run" from this idea previously...

Cheers ;)

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: January-09-13 2:56 PM
To: Jose Sanchez
Cc: juniper-nsp
Subject: Re: [j-nsp] Question about Routing Engine Redundancy on MX

On Wed, Jan 09, 2013 at 12:39:05PM -0600, Jose Sanchez wrote:
> Hello,
> 
> Does anybody know if the RE Redundancy in Juniper MX Routers requires 
> that both RE are the same hardware or it is enough that the REs has 
> the same JUNOS Version?

As long as they're reasonably similar it should work fine. For MX that
pretty much means RE-2000 and RE-1300, you have no hope in hell of
mismatching the new ones (RE-1800x2/4, which require 64-bit JUNOS) with the
old ones. For some definition of work of course (for all of the active
redundancy), where in my experience the answer is "it doesn't". 
:)

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
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] Question about Routing Engine Redundancy on MX

[Paul Stewart]

Nothing that I have handy - sorry. we asked this question a few times to our
Juniper SE and were told that (so presumed it to be factual)

 

J

 

From: Jose Sanchez [mailto:jasjuni...@gmail.com] 
Sent: January-09-13 1:49 PM
To: Paul Stewart
Cc: juniper-nsp
Subject: Re: [j-nsp] Question about Routing Engine Redundancy on MX

 

Thank you,

 

Any link to the documentation that require this?

 

Thanks again

 

Jose

 

 

On Wed, Jan 9, 2013 at 12:43 PM, Paul Stewart  wrote:

Both same hardware


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jose Sanchez
Sent: January-09-13 1:39 PM
To: juniper-nsp
Subject: [j-nsp] Question about Routing Engine Redundancy on MX

Hello,

Does anybody know if the RE Redundancy in Juniper MX Routers requires that
both RE are the same hardware or it is enough that the REs has the same
JUNOS Version?

Thanks

Jose

___
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] Question about Routing Engine Redundancy on MX

[Paul Stewart]

Both same hardware

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jose Sanchez
Sent: January-09-13 1:39 PM
To: juniper-nsp
Subject: [j-nsp] Question about Routing Engine Redundancy on MX

Hello,

Does anybody know if the RE Redundancy in Juniper MX Routers requires that
both RE are the same hardware or it is enough that the REs has the same
JUNOS Version?

Thanks

Jose
___
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] MX5 with bras?

[Paul Stewart]

Thanks Skeeve.

 

We have had MX5/MX10/MX80 doing BRAS at customer deployments since around
March - the 11.2R5.4 release has a number of nasty bugs and wish they would
stop recommended it on their site. that was the second release in 11.2 we
had ran at the time.  Then we went into two different 11.4R code releases
and ran into some other issues and finally 11.4X27 came out and squashed
most of those bugs (but not nearly all of them unfortunately).  The
issues/bugs we ran into were mainly PPPOE related.

 

Also, we have seen a lot of similarity in the bugs on MX80 based hardware as
we have seen in MX480/960 BRAS boxes - some different, some the same to
date..

 

At the moment, we are faced with a few challenges on this platform .. one is
the load on the box with under 4k users (quite high at times) and a more
recent issue has re-surfaced involving PPPOE sessions not timing out
properly.

 

YMMV of course.

 

Paul

 

 

 

 

From: Skeeve Stevens [mailto:skeeve+juniper...@eintellego.net] 
Sent: Friday, December 07, 2012 8:50 PM
To: Paul Stewart
Cc: Gavin Henry; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX5 with bras?

 

Paul,

 

I understand that the 11.4X27 was required for the functionality for the MX
Midrange Family and that it is not in the mainline until later where it was
said that it will be merged in at 12.2R4 which has just been released (Nov
20).  I am not sure if all the functionality made it into this version or
not as I haven't looked/tested it.

 

Please also note that the JTAC recommended is still at 11.2R5.4 - but this
is due for an update soon I would think since the las update was 10 months
ago.

 

...Skeeve


 

Skeeve Stevens, CEO - eintellego Pty Ltd

ske...@eintellego.net ; www.eintellego.net <http://www.eintellego.net/> 

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

facebook.com/eintellego ; linkedin.com/in/skeeve 

twitter.com/networkceoau ; blog: www.network-ceo.net
<http://www.network-ceo.net/> 

  <http://eintellego.net/sig/logo.png> 

The Experts Who The Experts Call

Juniper - Cisco - IBM - Brocade - Cloud

-

Check out our Juniper promotion website for Oct/Nov!
<http://eintellego.mx/> eintellego.mx

Free Apple products during this promotion!!! 





On Sat, Dec 8, 2012 at 12:22 PM, Paul Stewart  wrote:

Just to clarify - latest X27 code is recommended for BRAS however you do not
require an X release for the functionality.

Paul

Sent from my iPhone

On 2012-12-07, at 6:32 PM, Skeeve Stevens mailto:skeeve%2bjuniper...@eintellego.net> > wrote:

> Yes it can.  But you need an X code of Junos to do it.
>
> You also need to buy the licenses for it as well.
>
> It supports up to 4000 users.
>
> Licenses needed:
>
> - LNS License
> - Subscriber Management Feature Pack
> - 4000 User License
> *
>
> *
> *Skeeve Stevens, CEO - *eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net
>
> Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellego ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/networkceoau ; blog: www.network-ceo.net
>
> The Experts Who The Experts Call
> Juniper - Cisco - IBM - Brocade - Cloud
> -
> Check out our Juniper promotion website for Oct/Nov!  eintellego.mx
> Free Apple products during this promotion!!!
>
>
>
> On Sat, Dec 8, 2012 at 10:19 AM, Gavin Henry  wrote:
>
>> Hi all,
>>
>> Can an MX5 do BRAS?
>>
>> Thanks.
>>
>> On 22 November 2012 20:50, Gavin Henry  wrote:
>>> Hi all,
>>>
>>> Is anyone running this or any MX series with wholesale ADSL services in
>> the UK?
>>>
>>> Any issues, gotchas or recommendations?
>>>
>>> This is for an entry level broadband sp focused on VoIP but to scale up.
>>>
>>> Thanks.
>>>
>>> --
>>> Kind Regards,
>>>
>>> Gavin Henry.
>>> Managing Director.
>>>
>>> T +44 (0) 1224 279484
>>> M +44 (0) 7930 323266
>>> F +44 (0) 1224 824887
>>> E ghe...@suretec.co.uk
>>>
>>> Open Source. Open Solutions(tm).
>>>
>>> http://www.suretecsystems.com/
>>>
>>> Suretec Systems is a limited company registered in Scotland. Registered
>>> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
>> Inverurie,
>>> Aberdeenshire, AB51 8GL.
>>>
>>> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>>>
>>> Do you know we have our own VoIP provider called SureVoIP? See
>>> http://www.surevoip.co.uk
>>
>>
>>
>> --
>> Kind Regards,
>>
>> Gavin Henry.
>> Managing Director.
>>
>&g

Re: [j-nsp] MX5 with bras?

[Paul Stewart]

Search for Juniper Technical Bulletin PSN-2012-10-730 . I don't believe it's
on the public download site however the bulletin will provide links to you..

 

Paul

 

 

From: Giuliano Medalha [mailto:giuli...@wztech.com.br] 
Sent: Friday, December 07, 2012 8:29 PM
To: Paul Stewart
Cc: Skeeve Stevens; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX5 with bras?

 

How can we get the X27 code ?  We need to ask to J-TAC ? 





WZTECH is registered trademark of WZTECH NETWORKS.
Copyright C 2012 WZTECH NETWORKS. All Rights Reserved.

The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or privileged
information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is prohibited.
If you have received this communication in error, please notify the sender
immediately and delete the material from any computer, including any copies.





On Fri, Dec 7, 2012 at 11:22 PM, Paul Stewart  wrote:

Just to clarify - latest X27 code is recommended for BRAS however you do not
require an X release for the functionality.

Paul

Sent from my iPhone

On 2012-12-07, at 6:32 PM, Skeeve Stevens mailto:skeeve%2bjuniper...@eintellego.net> > wrote:

> Yes it can.  But you need an X code of Junos to do it.
>
> You also need to buy the licenses for it as well.
>
> It supports up to 4000 users.
>
> Licenses needed:
>
> - LNS License
> - Subscriber Management Feature Pack
> - 4000 User License
> *
>
> *
> *Skeeve Stevens, CEO - *eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net
>
> Phone: 1300 753 383; Cell +61 (0)414 753 383
  ; skype://skeeve
>
> facebook.com/eintellego ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/networkceoau ; blog: www.network-ceo.net
>
> The Experts Who The Experts Call
> Juniper - Cisco - IBM - Brocade - Cloud
> -
> Check out our Juniper promotion website for Oct/Nov!  eintellego.mx
> Free Apple products during this promotion!!!
>
>
>
> On Sat, Dec 8, 2012 at 10:19 AM, Gavin Henry  wrote:
>
>> Hi all,
>>
>> Can an MX5 do BRAS?
>>
>> Thanks.
>>
>> On 22 November 2012 20:50, Gavin Henry  wrote:
>>> Hi all,
>>>
>>> Is anyone running this or any MX series with wholesale ADSL services in
>> the UK?
>>>
>>> Any issues, gotchas or recommendations?
>>>
>>> This is for an entry level broadband sp focused on VoIP but to scale up.
>>>
>>> Thanks.
>>>
>>> --
>>> Kind Regards,
>>>
>>> Gavin Henry.
>>> Managing Director.
>>>
>>> T +44 (0) 1224 279484  
>>> M +44 (0) 7930 323266  
>>> F +44 (0) 1224 824887  
>>> E ghe...@suretec.co.uk
>>>
>>> Open Source. Open Solutions(tm).
>>>
>>> http://www.suretecsystems.com/
>>>
>>> Suretec Systems is a limited company registered in Scotland. Registered
>>> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
>> Inverurie,
>>> Aberdeenshire, AB51 8GL.
>>>
>>> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>>>
>>> Do you know we have our own VoIP provider called SureVoIP? See
>>> http://www.surevoip.co.uk
>>
>>
>>
>> --
>> Kind Regards,
>>
>> Gavin Henry.
>> Managing Director.
>>
>> T +44 (0) 1224 279484  
>> M +44 (0) 7930 323266  
>> F +44 (0) 1224 824887  
>> E ghe...@suretec.co.uk
>>
>> Open Source. Open Solutions(tm).
>>
>> http://www.suretecsystems.com/
>>
>> Suretec Systems is a limited company registered in Scotland. Registered
>> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
>> Inverurie,
>> Aberdeenshire, AB51 8GL.
>>
>> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>>
>> Do you know we have our own VoIP provider called SureVoIP? See
>> http://www.surevoip.co.uk
>>
>> Did you see our API? http://www.surevoip.co.uk/api
>> ___
>> 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] MX5 with bras?

[Paul Stewart]

Just to clarify - latest X27 code is recommended for BRAS however you do not 
require an X release for the functionality.

Paul

Sent from my iPhone

On 2012-12-07, at 6:32 PM, Skeeve Stevens  
wrote:

> Yes it can.  But you need an X code of Junos to do it.
> 
> You also need to buy the licenses for it as well.
> 
> It supports up to 4000 users.
> 
> Licenses needed:
> 
> - LNS License
> - Subscriber Management Feature Pack
> - 4000 User License
> *
> 
> *
> *Skeeve Stevens, CEO - *eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net
> 
> Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellego ;  
> linkedin.com/in/skeeve
> 
> twitter.com/networkceoau ; blog: www.network-ceo.net
> 
> The Experts Who The Experts Call
> Juniper - Cisco – IBM - Brocade - Cloud
> -
> Check out our Juniper promotion website for Oct/Nov!  eintellego.mx
> Free Apple products during this promotion!!!
> 
> 
> 
> On Sat, Dec 8, 2012 at 10:19 AM, Gavin Henry  wrote:
> 
>> Hi all,
>> 
>> Can an MX5 do BRAS?
>> 
>> Thanks.
>> 
>> On 22 November 2012 20:50, Gavin Henry  wrote:
>>> Hi all,
>>> 
>>> Is anyone running this or any MX series with wholesale ADSL services in
>> the UK?
>>> 
>>> Any issues, gotchas or recommendations?
>>> 
>>> This is for an entry level broadband sp focused on VoIP but to scale up.
>>> 
>>> Thanks.
>>> 
>>> --
>>> Kind Regards,
>>> 
>>> Gavin Henry.
>>> Managing Director.
>>> 
>>> T +44 (0) 1224 279484
>>> M +44 (0) 7930 323266
>>> F +44 (0) 1224 824887
>>> E ghe...@suretec.co.uk
>>> 
>>> Open Source. Open Solutions(tm).
>>> 
>>> http://www.suretecsystems.com/
>>> 
>>> Suretec Systems is a limited company registered in Scotland. Registered
>>> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
>> Inverurie,
>>> Aberdeenshire, AB51 8GL.
>>> 
>>> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>>> 
>>> Do you know we have our own VoIP provider called SureVoIP? See
>>> http://www.surevoip.co.uk
>> 
>> 
>> 
>> --
>> Kind Regards,
>> 
>> Gavin Henry.
>> Managing Director.
>> 
>> T +44 (0) 1224 279484
>> M +44 (0) 7930 323266
>> F +44 (0) 1224 824887
>> E ghe...@suretec.co.uk
>> 
>> Open Source. Open Solutions(tm).
>> 
>> http://www.suretecsystems.com/
>> 
>> Suretec Systems is a limited company registered in Scotland. Registered
>> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
>> Inverurie,
>> Aberdeenshire, AB51 8GL.
>> 
>> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>> 
>> Do you know we have our own VoIP provider called SureVoIP? See
>> http://www.surevoip.co.uk
>> 
>> Did you see our API? http://www.surevoip.co.uk/api
>> ___
>> 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] cable modem/dsl/ftth bandwidth limiting

[Paul Stewart]

We are moving everything to "the edge".   I mean that the BRAS on DSL will
be doing it via profiles and on our CMTS systems it's already incorporated
into the cable mode profile.  We were previously doing a lot more of the
"rate limiting" in Radius profiles which were used by ERX (and Cisco 7200)
specific to PPPOE on DSL but found it easier and more consistent to do DSLAM
speed profiles... a lot less "moving parts" involved doing it this way - at
least in our environment.

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chris Evans
Sent: June-19-12 1:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] cable modem/dsl/ftth bandwidth limiting

Question for you service provider folks.  How do cable modems, dsl, ftth,
etc limit bandwidth? I believe that everything is limited at the customer
edge demarq device, performing bandwidth limits on a central network device
would be too costly to do.

Do the CE devices use a form of traffic shaping, policing or some other
algorithm?? I believe it's just traffic shaping as I've looked at packet
captures and never see too many retrans taking place.

Thanks for any info you can provide!
___
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 availability schedule

[Paul Stewart]

Usually the best way to find that info is via our Juniper SE if you have one
- they can contact the right folks internally to get that answered...

That's what works best for us anyways..

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
ramesh@wipro.com
Sent: Tuesday, May 22, 2012 2:31 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Junos availability schedule

Hi 

Is there any way to get the schedule of the Release Junos 12.2x where one of
the PR499536 is fixed. 
JTAC is unable to provide  a schedule. 

Regards 

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus transmitted
by this email. 

www.wipro.com

___
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] Solarwinds Montoring

[Paul Stewart]

Is there anyone on this list that is using Solarwinds for monitoring of
their Juniper equipment?  In this case, I'm specific to SRX branch series
and EX 2200/3200/4200 switches in particular.

 

We have a long term issue where Solarwinds beings reporting false outages on
this equipment - happens at least once a week and been going on too long.  I
would like to hear from anyone offline if they have seen issues similar.

 

Thanks,

Paul

 

 

 

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

Re: [j-nsp] About Juniper MX10 router performance

[Paul Stewart]

Sorry - I thought it was M10i you were talking about...

On the MX80 side this it the largest we have at the moment is around 650k
BGP routes.

Paul



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: April-23-12 6:03 AM
To: 'Md. Jahangir Hossain'; 'Jonathan Lassoff'
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] About Juniper MX10 router performance

The 1.6 million sounds around right but have nothing to confirm it.  The
largest table we have  running on an M10i looks like this:

Table  Tot Paths  Act Paths SuppressedHistory Damp State
Pending
inet.0549751 410074  0  0  0
0
bgp.l3vpn.00  0  0  0  0
0
bgp.l2vpn.00  0  0  0  0
0
inet6.065318  63375  0  0  0
0

Not sure if that helps or not - memory consumption sits around 50% 

That's from an M10i running RE850 cards...

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Md. Jahangir
Hossain
Sent: Monday, April 23, 2012 2:53 AM
To: Jonathan Lassoff
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] About Juniper MX10 router performance

Thanks  jonathan to reach you again.

Actually i need to confirmation how many  BGP routes this model can handle.

In some of forum i found 1.6million but in juniper site i can not found this
information.

So i am a little bit confused that way i  need to know the practical
information if  any one used this product related to this service.





thanks
jahangir








 From: Jonathan Lassoff 
To: Md. Jahangir Hossain 
Cc: "juniper-nsp@puck.nether.net" 
Sent: Monday, April 23, 2012 12:42 PM
Subject: Re: [j-nsp] About Juniper MX10 router performance
 
On Sun, Apr 22, 2012 at 10:24 PM, Md. Jahangir Hossain
 wrote:
> Dear valued member:
>
>
> Wishes all are fine.
>
>
> i need
> suggestion from you about Juniper MX10 router performance who already 
> implement this. i want to buy  this router for IP Transit provider 
> where i received  all global routes .
>
>
> it would be nice please put your valued suggestion about this issue .

Jahangir -- we spoke briefly about this on NANOG just now as well.

Do you have a specific question about the MX10? What is it that you're
trying to accomplish?

--j
___
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] About Juniper MX10 router performance

[Paul Stewart]

The 1.6 million sounds around right but have nothing to confirm it.  The
largest table we have  running on an M10i looks like this:

Table  Tot Paths  Act Paths SuppressedHistory Damp State
Pending
inet.0549751 410074  0  0  0
0
bgp.l3vpn.00  0  0  0  0
0
bgp.l2vpn.00  0  0  0  0
0
inet6.065318  63375  0  0  0
0

Not sure if that helps or not - memory consumption sits around 50% 

That's from an M10i running RE850 cards...

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Md. Jahangir
Hossain
Sent: Monday, April 23, 2012 2:53 AM
To: Jonathan Lassoff
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] About Juniper MX10 router performance

Thanks  jonathan to reach you again.

Actually i need to confirmation how many  BGP routes this model can handle.

In some of forum i found 1.6million but in juniper site i can not found this
information.

So i am a little bit confused that way i  need to know the practical
information if  any one used this product related to this service.





thanks
jahangir








 From: Jonathan Lassoff 
To: Md. Jahangir Hossain 
Cc: "juniper-nsp@puck.nether.net" 
Sent: Monday, April 23, 2012 12:42 PM
Subject: Re: [j-nsp] About Juniper MX10 router performance
 
On Sun, Apr 22, 2012 at 10:24 PM, Md. Jahangir Hossain
 wrote:
> Dear valued member:
>
>
> Wishes all are fine.
>
>
> i need
> suggestion from you about Juniper MX10 router performance who already 
> implement this. i want to buy  this router for IP Transit provider 
> where i received  all global routes .
>
>
> it would be nice please put your valued suggestion about this issue .

Jahangir -- we spoke briefly about this on NANOG just now as well.

Do you have a specific question about the MX10? What is it that you're
trying to accomplish?

--j
___
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] Layer2 Rate Limiting Bi-Directional

[Paul Stewart]

Hi folks.

 

Working with a customer that has an aging Cisco 6500 in place (hybrid
CatOS/IOS).  They are looking for a replacement and we have proposed Juniper
to them.

 

My question though is where to find support in the hardware platforms for
bi-directional per port *and* per VLAN rate limiting?

 

Basically, they are a municipal fiber provider so a majority of their
business is layer2 at varying Mb/s increments.  Because of their network
layout, they run into situations where a single fiber port may have multiple
customers on separate VLAN's.  We are looking for the ability on a single
port to limit the layer2 speeds inbound and outbound.  I don't' believe you
can do this in the EX series or am I mistaken?

 

On the layer3 side, they are primarily static routing with a small amount of
actual Internet traffic.

 

Thanks for your input,

 

Paul Stewart

 

 

 

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

Re: [j-nsp] EX4200 VC Pity Me

[Paul Stewart]

Change this so the "linecard" is a "backup RE" .. you have to run two
RE's...

Paul

virtual-chassis {
 preprovisioned;
 no-split-detection;
 member 1 {
 role line-card;
 serial-number FV0211137957;
 }
 member 0 {
 role routing-engine;
 serial-number BP0209472119;
 }
}

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dave Peters
Sent: Tuesday, April 03, 2012 7:46 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX4200 VC Pity Me

Hi all--

Trying to test a VC with two EX4200s running 10.4R9.2.  Very simple.  I just
can't get the backup (or line card) chassis to pass traffic.  
Pinging the gateway out of the routing engine or master works fine.  
Trying to ping through the backup/line card gives me nothing.  The VC is
recognized (per the below).  Something simple I'm doing wrong, I know.  
Here's some output (and thanks for any help you might provide):

root> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: a8ab.cf0b.66d6
   Mastership
Neighbor List
Member ID  Status   Serial NoModelpriorityRole  ID  
Interface
0 (FPC 0)  PrsntBP0209472119 ex4200-48t  129  Master*1  vcp-0
  1  vcp-1
1 (FPC 1)  PrsntFV0211137957 ex4200-48t0  Linecard   0  vcp-0
  0  vcp-1


root> show virtual-chassis vc-port member 0
fpc0:
--
Interface   Type  Trunk  Status   SpeedNeighbor
or ID (mbps)   ID  Interface
PIC / Port
vcp-0   Dedicated   1Up   320001   vcp-0
vcp-1   Dedicated   2Up   320001   vcp-1

{master:0}
root> show virtual-chassis vc-port member 1
fpc1:
--
Interface   Type  Trunk  Status   SpeedNeighbor
or ID (mbps)   ID  Interface
PIC / Port
vcp-0   Dedicated   1Up   320000   vcp-0
vcp-1   Dedicated   2Up   320000   vcp-1

{master:0}





root> show configuration
## Last commit: 2012-02-02 09:38:58 UTC by root version 10.4R9.2; system {
 root-authentication {
 encrypted-password bJ/GddyoJuiU2; ## SECRET-DATA
 }
 services {
 web-management {
 http;
 }
 }
 syslog {
 user * {
 any emergency;
 }
 file messages {
 any notice;
 authorization info;
 }
 file interactive-commands {
 interactive-commands any;
 }
 }
}
interfaces {
 ge-0/0/0 {
 unit 0 {
 family ethernet-switching;
 }
 }
 ge-0/0/1 {
 unit 0 {
 family ethernet-switching;
 }
 }
 ge-0/0/2 {
 unit 0 {
 family ethernet-switching;

*!truncated!*

 vlan {
 unit 0 {
 family inet {
 address 192.168.10.188/24;
 }
 }
 }
}
routing-options {
 static {
 route 0.0.0.0/0 next-hop 192.168.10.77;
 }
}
protocols {
 igmp-snooping {
 vlan all;
 }
 lldp {
 interface all;
 }
 lldp-med {
 interface all;
 }
}
ethernet-switching-options {
 storm-control {
 interface all;
 }
}
vlans {
 default {
 l3-interface vlan.0;
 }
}
poe {
 interface all;
}
virtual-chassis {
 preprovisioned;
 no-split-detection;
 member 1 {
 role line-card;
 serial-number FV0211137957;
 }
 member 0 {
 role routing-engine;
 serial-number BP0209472119;
 }
}

___
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] l2vpn tagged PE port to untagged PE port

[Paul Stewart]

Thanks David. I went back and checked. ummm. had the VLAN maps on the
opposite side (geesh!)

 

Appreciate the second set of eyes.. ;)

 

Paul

 

 

From: David Ball [mailto:davidtb...@gmail.com] 
Sent: April-03-12 10:45 AM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] l2vpn tagged PE port to untagged PE port

 

  Simply applying an 'input-vlan-map pop' and 'output-vlan-map push' on the
trunked port (ge-1/3/9) didn't do the job ?  I used to have to do that all
the time and don't recall encountering problems.  The routing-instance
encapsulation will need to be 'ethernet' on both sides once you do that.

 

David

 

On 3 April 2012 09:23, Paul Stewart  wrote:

Hi folks.



Have built an l2vpn session but ran into an issue.  One side of the session
is handed off on a trunked port:



[edit interfaces ge-1/3/9]

flexible-vlan-tagging;

speed 100m;

encapsulation flexible-ethernet-services;

}

unit 444 {

   description "OTA Testing";

   encapsulation vlan-ccc;

   vlan-id 444;

}



The routing instance looks like this:



[edit routing-instances OTA-Testing]

instance-type l2vpn;

interface ge-1/3/9.444;

route-distinguisher xx.xx.xxx.71:444;

vrf-target target:11666:9444;

protocols {

   l2vpn {

   encapsulation-type ethernet-vlan;

   interface ge-1/3/9.444;

   site dis1.millbrook1 {

   site-identifier 71;

   interface ge-1/3/9.444 {

   remote-site-id 59;

   }

   }

   }

}





The other end though has an untagged port (straight Ethernet).  I cannot
figure out how to hand this off and keep getting an encapsulation mismatch
on the l2vpn session?



{master}[edit interfaces ge-2/1/3]

speed 100m;

link-mode full-duplex;

encapsulation ethernet-ccc;

unit 0;



Routing instance:



{master}[edit routing-instances OTA_Testing]

instance-type l2vpn;

interface ge-2/1/3.0;

route-distinguisher xx.xx.xxx.xx:444;

vrf-target target:11666:9444;

protocols {

   l2vpn {

   encapsulation-type ethernet;

   interface ge-2/1/3.0;

   site core1.toronto1 {

   site-identifier 59;

   interface ge-2/1/3.0 {

   remote-site-id 71;

   }

   }

   }

}





I contacted JTAC and they suggested a VLAN map to pop and push. this didn't
work . I previously had this labbed up and can't find my notes ;)



Layer-2 VPN connections:



Instance: OTA_Testing

 Local site: core1.toronto1 (59)

   connection-site   Type  St Time last up  # Up trans

   71rmt   EM





Any thoughts on how I can fix this?



Appreciate it,

Paul



___
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] l2vpn tagged PE port to untagged PE port

[Paul Stewart]

Hi folks.

 

Have built an l2vpn session but ran into an issue.  One side of the session
is handed off on a trunked port:

 

[edit interfaces ge-1/3/9]

flexible-vlan-tagging;

speed 100m;

encapsulation flexible-ethernet-services;

}

unit 444 {

description "OTA Testing";

encapsulation vlan-ccc;

vlan-id 444;

}

 

The routing instance looks like this:

 

[edit routing-instances OTA-Testing]

instance-type l2vpn;

interface ge-1/3/9.444;

route-distinguisher xx.xx.xxx.71:444;

vrf-target target:11666:9444;

protocols {

l2vpn {

encapsulation-type ethernet-vlan;

interface ge-1/3/9.444;

site dis1.millbrook1 {

site-identifier 71;

interface ge-1/3/9.444 {

remote-site-id 59;

}

}

}

}

 

 

The other end though has an untagged port (straight Ethernet).  I cannot
figure out how to hand this off and keep getting an encapsulation mismatch
on the l2vpn session?

 

{master}[edit interfaces ge-2/1/3]

speed 100m;

link-mode full-duplex;

encapsulation ethernet-ccc;

unit 0;

 

Routing instance:

 

{master}[edit routing-instances OTA_Testing]

instance-type l2vpn;

interface ge-2/1/3.0;

route-distinguisher xx.xx.xxx.xx:444;

vrf-target target:11666:9444;

protocols {

l2vpn {

encapsulation-type ethernet;

interface ge-2/1/3.0;

site core1.toronto1 {

site-identifier 59;

interface ge-2/1/3.0 {

remote-site-id 71;

}

}

}

}

 

 

I contacted JTAC and they suggested a VLAN map to pop and push. this didn't
work . I previously had this labbed up and can't find my notes ;)

 

Layer-2 VPN connections:

 

Instance: OTA_Testing

  Local site: core1.toronto1 (59)

connection-site   Type  St Time last up  # Up trans

71rmt   EM

 

 

Any thoughts on how I can fix this?

 

Appreciate it,

Paul

 

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

Re: [j-nsp] SRX recommended software

[Paul Stewart]

We're pretty much on 10.4R8.5 back to 6.5 on most boxes.. no major issues.
I think we have a couple of boxes on 11.2 code due to features required that
weren't present in 10.4 tree.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Brent Jones
Sent: Monday, April 02, 2012 5:41 PM
To: Jeff Rooney
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX recommended software

On Mon, Apr 2, 2012 at 2:24 PM, Jeff Rooney  wrote:

> I have a few SRX650's that are running 10.4R9.2 per the Juniper 
> recommended release page
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476
> However,
> I just have a few more which came with 11.2R4.3 on them. Just curious 
> as to what everyone is running on these, should I downgrade the new 
> guys? or upgrade old?
>
> The workload on these boxes is nothing crazy, some IPSEC vpn, OSPF 
> with about 200 routes, firewalling, no cluster...etc.
>
> Thanks for any input.
>
> Jeff
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

I still run 11.1R3.5 on several sets of SRX1400s.
Then on branch units, I chose to stick with 10.4R6.5

I have to say, no major issues uncovered so far, same stuff as you, IPSec,
VPNs, OSPF...

--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Juniper BRAS

[Paul Stewart]

If your SE is not aware of the software issues etc - feel free to reach out
to me we've invested a lot of time recently dealing with MX subscriber
PPPOE issues and worked with Juniper a lot on this.

Paul


-Original Message-
From: m...@gw.ms [mailto:m...@gw.ms] On Behalf Of Matthias Brumm
Sent: March-27-12 11:45 AM
To: Paul Stewart
Cc: Liam Murphy; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Juniper BRAS

Hi!

I hope our SE will have the insight to provide us with such suggestions.

We will use some MX5 for core and border routers, but one will provide PPPoE
in some time. So it is not a must thing now, and perhaps some new software
releases will provide better service in this matter.

Matthias

Am 27. März 2012 17:40 schrieb Paul Stewart :
> That's correct - if you have direct connectivity to the DSLAM's 
> without the need to carry l2tp then you don't need the LNS functionality.
>
> If you wanted to "forward" that traffic to another provider (wholesale 
> it
> out) then you might require LNS as a function as well.
>
> It sounds like your usage is similar to our usage to date - we 
> own/operate our own DSLAM's therefore it's just "native PPPOE" for us.
>
> Be very careful on the software load you are running on the MX5 for 
> this purpose - I would highly suggest working with your SE to find a 
> stable and suitable software version.
>
> Paul
>
>
> -Original Message-
> From: m...@gw.ms [mailto:m...@gw.ms] On Behalf Of Matthias Brumm
> Sent: March-27-12 11:08 AM
> To: Paul Stewart
> Cc: Liam Murphy; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Juniper BRAS
>
> Hi!
>
> We have just ordered some MX5 to have the opportunity to provide PPPoE 
> for customers.
>
> What exactly is the meaning of lacking LNS support? If I understand 
> correctly LNS is the possibility to provide a tunnel endpoint for a 
> L2TP tunnel, sent from a provider, for example a DSL provider. The
> MX80(5) is capable of provide a PPPoE termination, if I have L2 access 
> to the DSLAMs or access switches?
>
> Regards,
>
> Matthias
>
> Am 26. März 2012 14:23 schrieb Paul Stewart :
>> I'm not up to speed on the MLPPP stuff but would look at
>> MX240/MX480/MX960 platform for sure.  The MX80 can only handle about 
>> 4k sessions and has no support for LNS yet I don't believe (coming 
>> though
> if I'm not mistaken).
>>
>> Paul
>>
>>
>> -Original Message-
>> From: Liam Murphy [mailto:liam.mur...@easynet.com]
>> Sent: March-26-12 6:30 AM
>> To: Paul Stewart; juniper-nsp@puck.nether.net
>> Subject: RE: [j-nsp] Juniper BRAS
>>
>> About 4000 sessions.
>> I am just not sure if I can have MLPPPoLT2P
>>
>> (i.e. up to 8 ppp sessions bundled inside a MLPPP session that 
>> terminates on a Juniper that is acting as an LNS, with subscriber QoS).
>>
>> Thanks!
>>
>>
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net
>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul 
>> Stewart
>> Sent: 23 March 2012 20:40
>> To: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] Juniper BRAS
>>
>> What kind of capacity?  M/MX is only option outside of E/ERX series...
>>
>>
>>
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net
>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Liam Murphy
>> Sent: March-23-12 1:22 PM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] Juniper BRAS
>>
>> Which Juniper router (not E-Series) is best suited for a BRAS.
>> (L2TP LNS with MLPPP)
>>
>> Regards
>>
>> Liam
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


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

Re: [j-nsp] Juniper BRAS

[Paul Stewart]

That's correct - if you have direct connectivity to the DSLAM's without the
need to carry l2tp then you don't need the LNS functionality.

If you wanted to "forward" that traffic to another provider (wholesale it
out) then you might require LNS as a function as well.

It sounds like your usage is similar to our usage to date - we own/operate
our own DSLAM's therefore it's just "native PPPOE" for us.

Be very careful on the software load you are running on the MX5 for this
purpose - I would highly suggest working with your SE to find a stable and
suitable software version.  

Paul


-Original Message-
From: m...@gw.ms [mailto:m...@gw.ms] On Behalf Of Matthias Brumm
Sent: March-27-12 11:08 AM
To: Paul Stewart
Cc: Liam Murphy; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Juniper BRAS

Hi!

We have just ordered some MX5 to have the opportunity to provide PPPoE for
customers.

What exactly is the meaning of lacking LNS support? If I understand
correctly LNS is the possibility to provide a tunnel endpoint for a L2TP
tunnel, sent from a provider, for example a DSL provider. The
MX80(5) is capable of provide a PPPoE termination, if I have L2 access to
the DSLAMs or access switches?

Regards,

Matthias

Am 26. März 2012 14:23 schrieb Paul Stewart :
> I'm not up to speed on the MLPPP stuff but would look at 
> MX240/MX480/MX960 platform for sure.  The MX80 can only handle about 
> 4k sessions and has no support for LNS yet I don't believe (coming though
if I'm not mistaken).
>
> Paul
>
>
> -Original Message-
> From: Liam Murphy [mailto:liam.mur...@easynet.com]
> Sent: March-26-12 6:30 AM
> To: Paul Stewart; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] Juniper BRAS
>
> About 4000 sessions.
> I am just not sure if I can have MLPPPoLT2P
>
> (i.e. up to 8 ppp sessions bundled inside a MLPPP session that 
> terminates on a Juniper that is acting as an LNS, with subscriber QoS).
>
> Thanks!
>
>
> -----Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
> Sent: 23 March 2012 20:40
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Juniper BRAS
>
> What kind of capacity?  M/MX is only option outside of E/ERX series...
>
>
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Liam Murphy
> Sent: March-23-12 1:22 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Juniper BRAS
>
> Which Juniper router (not E-Series) is best suited for a BRAS.
> (L2TP LNS with MLPPP)
>
> Regards
>
> Liam
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Juniper BRAS

[Paul Stewart]

I'm not up to speed on the MLPPP stuff but would look at MX240/MX480/MX960
platform for sure.  The MX80 can only handle about 4k sessions and has no
support for LNS yet I don't believe (coming though if I'm not mistaken).

Paul


-Original Message-
From: Liam Murphy [mailto:liam.mur...@easynet.com] 
Sent: March-26-12 6:30 AM
To: Paul Stewart; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Juniper BRAS

About 4000 sessions.
I am just not sure if I can have MLPPPoLT2P

(i.e. up to 8 ppp sessions bundled inside a MLPPP session that terminates on
a Juniper that is acting as an LNS, with subscriber QoS).

Thanks! 


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: 23 March 2012 20:40
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Juniper BRAS

What kind of capacity?  M/MX is only option outside of E/ERX series...



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Liam Murphy
Sent: March-23-12 1:22 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper BRAS

Which Juniper router (not E-Series) is best suited for a BRAS.
(L2TP LNS with MLPPP)

Regards

Liam 

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

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

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

Re: [j-nsp] Juniper BRAS

[Paul Stewart]

What kind of capacity?  M/MX is only option outside of E/ERX series...



-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Liam Murphy
Sent: March-23-12 1:22 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper BRAS

Which Juniper router (not E-Series) is best suited for a BRAS.
(L2TP LNS with MLPPP)

Regards

Liam 

___
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 10.4R8.5 on MX5? Am I forced to run 11.4+?

[Paul Stewart]

It will crash miserably. been there, done that ;)  I can't remember which 
release I was downgrading to and from... but I did try to downgrade an MX10 and 
got the "hardware not supported" error.  Went ahead anyways and poof!

Had to reinstall with USB ... thankfully it wasn't in production and I was 
onsite...

Paul


-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Timh Bergström
Sent: March-22-12 4:21 AM
To: Tima Maryin
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JunOS 10.4R8.5 on MX5? Am I forced to run 11.4+?

Hi,

Thanks for the information, it gives some answers. But what would actually 
happen if I try to install 10.4R8.5 with no-validate etc and "force" it to 
accept it, would it stop working or not, since it's the same hardware as the 
MX80 but with other "descriptions" it should work, but I'm unsure. Don't want 
to brick it. :-)

//T

On Thu, Mar 22, 2012 at 9:13 AM, Tima Maryin  wrote:
> Hi,
>
>
> Here:
> http://www.juniper.net/techpubs/en_US/junos11.2/information-products/t
> opic-collections/release-notes/11.2/topic-57399.html
>
>
> "New MX5, MX10, and MX40 3D Universal Edge Routers—Three new routers 
> based on the modular MX80 chassis are available in Junos OS Release 11.2R6."
>
>
> Though in 11.4 relnotes it's 11.2R3 :-/ So you probably should try 
> 11.2R6.
>
>
>
>
>
> On 22.03.2012 11:16, Timh Bergström wrote:
>>
>> Hi,
>>
>> I recently bought a MX5-T (Instead of the MX80-5G) and I'm running
>> 10.4R8.5 on my other MX80s and would naturally like to run the same 
>> codebase on all my MX-series hardware. However when I try to install 
>> the 10.4R8.5 release on the MX5-T it says that the platform is not 
>> supported, I thought the MX5/10/40 was the same hardware as the MX80 
>> (it surely looks the same, side-by-side)?
>>
>> Does anyone have any thoughts or information on this? It got 
>> delivered with 11.4R1.14 and I actually have no use of imix/etc 
>> whatever the new features is in the 11.X, I just want to run them as 
>> network edges with eBGP, iBGP and OSPF, no special stuff, and I'm 
>> happy with 10.4R8.5 so far.
>>
>> I also tried (for fun) to downgrade to 11.2R5.4 (which is the 
>> recommended release according to JTAC) but that didn't work either, 
>> the mgd process core-dumped and the validation failed, I did not run 
>> with "no-validate" (yet) for neither of the softwares.
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
Timh Bergström
Head of System Operations
Videoplaza/System Operations

timh.bergst...@videoplaza.com
+46 727 406 845
S:t Eriksgatan 46
Stockholm
www.videoplaza.com

skype: timh_bergstrom
gtalk: timh.bergst...@videoplaza.com
linkedin:

___
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