Re: [j-nsp] Krt queue issues

2012-10-02 Thread Saku Ytti
On (2012-10-02 15:20 -0400), Clarke Morledge wrote:

> routing table feed you can have before you start to hit this issue
> on the MX80?  Are there other load factors involved?

Yes there are other factors than just the number of BGP peers, I cannot
reliably identify them.

> I assuming that the RE-1300 on the MX chassis units do not suffer
> from this, correct?

It's inherent to JunOS, but it's lot harder to trigger it on faster
control-planes. MX80 and EX are more likely to see it.

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


[j-nsp] GRES on EX-Virtual chassis

2012-10-02 Thread Muruganandham M
Hello,

   I am referring the following link.

http://www.juniper.net/techpubs/en_US/junos10.3/topics/task/configuration/virtual-chassis-gres-cli.html

Is it mandatory to configure the mastership-priority to 255 to enable GRES
on the VC ?

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


Re: [j-nsp] Krt queue issues

2012-10-02 Thread Clarke Morledge

A very interesting thread.

Does anyone have a good feel for how many BGP neighbors with a full 
routing table feed you can have before you start to hit this issue on the 
MX80?  Are there other load factors involved?


I assuming that the RE-1300 on the MX chassis units do not suffer from 
this, correct?


As a workaround, could you have a script that brings up BGP neighbors in 
an orderly sequence after a reboot?


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187


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


Re: [j-nsp] Krt queue issues

2012-10-02 Thread Jared Mauch

On Oct 2, 2012, at 10:49 AM, Benny Amorsen wrote:

> "Darren O'Connor"  writes:
> 
>> Indeed, this is the worst thing this router can do. I have redundant
>> routers sitting there doing absolutely nothing as this router's
>> control-plane says everything is fine.
> 
> I'm looking at using MX80 as an Internet transit router too...
> 
> Do you know if it is possible to prioritize which routes get installed
> first into the FIB? In that case, a default route could be used to catch
> the wrongly-blackholed traffic. It is not particularly elegant or in
> keeping with being otherwise default-free, of course.

so, I've observed a lot of other interesting bugs as it relates to JunOS when 
running on a lower processor system.  These are the types of bugs they didn't 
see in the lab until they installed the same "slower" RE that we were using.  
Just some odd timing regression.

I have reason to believe some of this will get better in the long-term, but 
until then you will need to spend some time convincing JTAC and the developers 
to look into the suboptimal performance of the system under load.  (We spent a 
long time doing this in the past and they eventually found some code that had a 
poorly constructed set of arguments to an if statement.  This resulted in it 
always being true (or was it false?).

As far as the fallback 'default' route, if you are purchasing transit from 
someone, you could consider a last-resort default pointed at them.  You can 
exclude routes like 10/8 etc by routing these to discard + install on your 
devices.

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


Re: [j-nsp] Krt queue issues

2012-10-02 Thread Benny Amorsen
"Darren O'Connor"  writes:

> Indeed, this is the worst thing this router can do. I have redundant
> routers sitting there doing absolutely nothing as this router's
> control-plane says everything is fine.

I'm looking at using MX80 as an Internet transit router too...

Do you know if it is possible to prioritize which routes get installed
first into the FIB? In that case, a default route could be used to catch
the wrongly-blackholed traffic. It is not particularly elegant or in
keeping with being otherwise default-free, of course.


/Benny

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


Re: [j-nsp] Trigger Trap when interface is overloaded

2012-10-02 Thread david.roy
Thanks 

Yes I saw that but I'm not sure that this config is scalable and sometimes 
ifindex are not persistant after reboot. 

Best regards
David



 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : Per Granath [mailto:per.gran...@gcc.com.cy] 
Envoyé : mardi 2 octobre 2012 16:30
À : ROY David DTF/DERX; juniper-nsp@puck.nether.net
Objet : RE: Trigger Trap when interface is overloaded

Have a look at RMON.


> Is-there an easy way (without accounting-profile / event-script) to 
> generate a trap or a syslog when interface reach 95% of load (for 
> example) ? Platform MX / release 11.4


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.


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


Re: [j-nsp] Trigger Trap when interface is overloaded

2012-10-02 Thread Per Granath
Have a look at RMON.


> Is-there an easy way (without accounting-profile / event-script) to generate
> a trap or a syslog when interface reach 95% of load (for example) ? Platform
> MX / release 11.4


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


[j-nsp] Trigger Trap when interface is overloaded

2012-10-02 Thread david.roy
Hi all,

Is-there an easy way (without accounting-profile / event-script) to generate a 
trap or a syslog when interface reach 95% of load (for example) ? Platform MX / 
release 11.4

Many thanks
Best regards
David





David Roy
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.

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


Re: [j-nsp] Creating VC using Uplink ports (VCE) on ex-4200

2012-10-02 Thread Rehan Rafi
Hello Abdullah,

We configured them in one of project and VC works pretty fine using
uplinks. You are right, you will need the fiber module either 2x XFP or 4x
SFP depending upon requirement.


On Sun, Sep 30, 2012 at 12:09 PM, Abdullah Baheer
wrote:

> Hi Experts,
> We have two ex-4200 switches placed in two buildings, 400 to 500 meters
> apart.The switches are connected through a Trunk interface (through a fiber
> link and media-converters on both sides)
> We are thinking of running VC between these switches.As per my
> understanding I will need two uplink modules (2x XFP, or 4x SFP), and XFPs
> or SFPs, I guess I need at least two links for redundancy.
> Has anyone experienced running VC using uplink ports, using 1G ports or
> 10G ports, is there anything I need to watch for, is it a reliable/workable
> solution?
> Appreciate your inputs.
> ThanksAbdullah Baheer (JNCIE-M # 1402)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 

Regards,

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


Re: [j-nsp] MX80 port-mirror on MPLS interface

2012-10-02 Thread Leigh Porter
> > Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify
> family in any filter of forwarding-options for port-mirroring there is
> no family mpls available.
> 
> I think we need ERSPAN IETF draft, so you can export the original l2,
> regardless what headers you have afterwards.
> Why you cannot do this today, is because GRE wants ethertype, and there
> isn't ethertype for 'the original L2 frame'. Cisco has reserved 0x88be
> and 0x22eb for this. This is just too useful feature to be proprietary.
> There probably should be two version of this standard, one with shim
> header (like ERSPAN) and one without shim header (if that will allow it
> to be implemented by more currently shipping hardware)

It would be lovely if I could just do a simple Layer 2 port mirror to another 
port..

Oh well! I'll have to switch it through another box I suppose.

--
Leigh



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

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


Re: [j-nsp] MX80 port-mirror on MPLS interface

2012-10-02 Thread Daniel Hilj
Hi,

To my knowledge you will need a MS-DPC to do that and that is not available on 
MX80.

//Daniel


2 okt 2012 kl. 13:14 skrev "Leigh Porter" :

> Hey All,
> 
> Does anybody know if the MX80 supports mirroring of MPLS family traffic?
> 
> Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify family in 
> any filter of forwarding-options for port-mirroring there is no family mpls 
> available.
> 
> None of the documents seem to talk about mirroring MPLS traffic either..
> 
> Is this just not the done thing?
> 
> Thanks!
> 
> --
> Leigh Porter
> 
> 
> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> -- This e-mail has been checked for virus by IPnett's Security solution --
> 
-- This e-mail has been checked for virus by IPnett's Security solution --


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


Re: [j-nsp] MX80 port-mirror on MPLS interface

2012-10-02 Thread Saku Ytti
On (2012-10-02 11:13 +), Leigh Porter wrote:

Hi,

> Does anybody know if the MX80 supports mirroring of MPLS family traffic?

I don't, let me know if you manage to do it. You might be able to export IP
inside MPLS by circulating via LT, but I don't think you'll be able to
export MPLS frames as-is.

> Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify family in 
> any filter of forwarding-options for port-mirroring there is no family mpls 
> available.

I think we need ERSPAN IETF draft, so you can export the original l2,
regardless what headers you have afterwards.
Why you cannot do this today, is because GRE wants ethertype, and there
isn't ethertype for 'the original L2 frame'. Cisco has reserved 0x88be and
0x22eb for this. This is just too useful feature to be proprietary.
There probably should be two version of this standard, one with shim header
(like ERSPAN) and one without shim header (if that will allow it to be
implemented by more currently shipping hardware)

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


[j-nsp] MX80 port-mirror on MPLS interface

2012-10-02 Thread Leigh Porter
Hey All,

Does anybody know if the MX80 supports mirroring of MPLS family traffic?

Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify family in 
any filter of forwarding-options for port-mirroring there is no family mpls 
available.

None of the documents seem to talk about mirroring MPLS traffic either..

Is this just not the done thing?

Thanks!

--
Leigh Porter




__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

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