Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

[Phil Bedard]

This is from an industry perspective and not specific to Juniper.  BIER won't 
really  happen without hardware support which is coming but will not be 
compatible with a lot of already deployed hardware.  

There was some IETF work going on to figure out how to map multicast to SR-MPLS 
but it kind of died off last year.  

TreeSID is more of a Cisco solution, and relies on an external PCE to build the 
multicast tree at every branch point across an SR-enabled network.  

Near-term mLDP specifically for multicast, without unicast enabled, is a 
solution.  Ingress replication is becoming a bit more popular as multicast as 
an overall percentage of traffic has continued to drop.  

Phil 

On 7/12/18, 6:43 AM, "juniper-nsp on behalf of Jackson, William" 
 
wrote:

So just to throw a question out there:

When I last looked at SR this was a big empty hole when it came to 
multicast.
As we are possibly removing mLDP and RSVP from the network in favour of 
SR(-TE) what are people doing to fill this void.

There were some drafts being worked on last year and if I recall one that 
seemed more "developed" was "Bit Index Explicit Replication", but I haven't 
heard anything more about this topic and it hasn't been mentioned in the thread 
so far.

Any comments?

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] vRR experience

[Phil Bedard]

I’ve been using them with KVM for a long time now just acting as virtual test 
routers, and have tested the vRR functionality as well with several hundred 
simulated peers.   No real issues to report, some have been up for over a year 
now running 14.x code revisions.   I have not tested the ORR functionality yet 
but will be testing it in the near future.  

Phil 

-Original Message-
From: juniper-nsp  on behalf of John 
Luthcinson 
Date: Wednesday, July 27, 2016 at 03:32
To: 
Subject: [j-nsp] vRR experience

Hi list

Are you using Juniper's vRR (virtual route reflector) as route reflector in
production?
Or do you have any experience of testing it?

I'm thinking it as one of possible options. We don't have any experience of
it.

All comments are appreciated.
___
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] Segment Routing ( SPRING )

[Phil Bedard]

Also if folks are looking for an early intro into the config and operation 
within Junos there is a relatively new book “MPLS in the SDN Era” from Juniper 
and it has quite a bit on SPRING.  The other nice thing about the book is all 
the use cases are mixed-vendor including both Junos and IOS-XR configs.  

Phil 



-Original Message-
From: juniper-nsp  on behalf of Saku Ytti 

Date: Friday, January 15, 2016 at 09:02
To: "Jackson, William" 
Cc: "juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] Segment Routing ( SPRING )

>Hey William,
>
>
>RSN. 1st half of 2016. I'm sure you can get some image to play with if
>you contact your account team.
>
>On 15 January 2016 at 14:33, Jackson, William
> wrote:
>> Hi
>>
>>
>>
>> have been reading cisco documentation on this topic.
>>
>> I was wondering if anyone knew the JUNOS status for this was?
>>
>>
>>
>> Cant find much on the website etc etc.
>>
>>
>>
>> many thanks
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>-- 
>  ++ytti
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] vMX for ESXi

[Phil Bedard]

I misspoke, there is a higher performance version starting in 5.4.0 of XRv and 
6.0 as well.  These do use the DPDK.  

Phil 

From:  Phil B 
Date:  Friday, January 8, 2016 at 19:40
To:  Adam Vitkovsky , Robert Hass 
, Mark Tinka 
Cc:  "juniper-nsp@puck.nether.net" 
Subject:  RE: [j-nsp] vMX for ESXi

There isn't a performance optimized version of XRv, it's really only useful for 
low speed applications like the vRR bersion of Junos.  I do use them 
extensively for control plane testing and they work as vRRs.  

 

 Now 6.0 is starting to get there since it is Linux based instead of QNX, has 
CPU core affinities, etc.  Afaik still no support for Intel DPDK like vMX and 
the vSR from ALU.

 

Phil

 

 

 


From: Adam Vitkovsky
Sent: Wednesday, January 6, 2016 7:52 AM
To: Robert Hass; Mark Tinka
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vMX for ESXi

 

Hi,

 

> Robert Hass

> Sent: Wednesday, January 06, 2016 12:03 PM

> 

> But returning to vMX - we have a lot of use-cases for vMX, so Cisco products

> are not cure for us :) Still waiting for *WORKING* vMX do VMware.

> 

Got me wondering in what use cases vMX is better than XRv please?

 

adam

 

 

 

Adam Vitkovsky

IP Engineer

 

T:  0333 006 5936

E:  adam.vitkov...@gamma.co.uk

W:  www.gamma.co.uk

 

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

 

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

 

 

___

juniper-nsp mailing list juniper-nsp@puck.nether.net

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

 

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

Re: [j-nsp] vMX for ESXi

[Phil Bedard]

There isn't a performance optimized version of XRv, it's really only useful for 
low speed applications like the vRR bersion of Junos.  I do use them 
extensively for control plane testing and they work as vRRs.  

 Now 6.0 is starting to get there since it is Linux based instead of QNX, has 
CPU core affinities, etc.  Afaik still no support for Intel DPDK like vMX and 
the vSR from ALU.

Phil




From: Adam Vitkovsky
Sent: Wednesday, January 6, 2016 7:52 AM
To: Robert Hass; Mark Tinka
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vMX for ESXi

Hi,

> Robert Hass
> Sent: Wednesday, January 06, 2016 12:03 PM
>
> But returning to vMX - we have a lot of use-cases for vMX, so Cisco products
> are not cure for us :) Still waiting for *WORKING* vMX do VMware.
>
Got me wondering in what use cases vMX is better than XRv please?

adam



Adam Vitkovsky
IP Engineer

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

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

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


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

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

Re: [j-nsp] Multi Core on JUNOS?

[Phil Bedard]

Well you may see the ability to run the  Junos CP on more powerful external 
servers with virtualized hardware, I think a few vendors are working on those 
type of a solutions.  Juniper has done similar things in the past with 
multi-chassis.  

Phil

-Original Message-
From: "Adam Vitkovsky" 
Sent: ‎10/‎22/‎2015 7:31 AM
To: "Saku Ytti" 
Cc: "" 
Subject: Re: [j-nsp] Multi Core on JUNOS?

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 11:54 AM
> On 22 October 2015 at 10:38, Adam Vitkovsky
>  wrote:
>
> Hey,
>
> > I thought that's the plan to separate routing protocols to separate
> processes or is this concerning only BGP?
>
> Not processes, threads, due to IPC concerns.
>
Hey,

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)

adam



Adam Vitkovsky
IP Engineer

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

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

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


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

Re: [j-nsp] Multi Core on JUNOS?

[Phil Bedard]

Timos (now SROS) is all internal, no config knobs I am aware of,  but the whole 
system was built to be multithreaded from the beginning.  Their vRR 
implementation is very fast because it can distribute the neighbor sessions 
across multiple cores.  If you look at the vRR stuff they have put out there 
are some more details.  

Phil

-Original Message-
From: "Adam Vitkovsky" 
Sent: ‎10/‎8/‎2015 3:55 PM
To: "Saku Ytti" ; "Colton Conor" 
Cc: "juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] Multi Core on JUNOS?

Hi Saku,

> Of Saku Ytti
> Sent: Thursday, October 08, 2015 5:34 PM
> TimOS has been able to distribute work from BGP to many cores, as far as I
> know all other vendors will only ever use one core for BGP at given time.
>
Actually IOS XR "had" the capability to run BGP in a standalone or distributed 
mode on CRS (found a comment that on 4.2.0 the "bgp distributed speaker" config 
was removed).
-in distributed mode up to 15 BGP speaker process could be offloaded to DRPs 
-even in different nodes (multi-chassis) and you can assign peers to different 
speaker processes.
-but there are some drawbacks during best path selection algorithm because only 
the partial best paths for a local speaker process are stored into dRIB that is 
then shared via IPC between the different speaker processes.
-and also some restrictions on how AFs can be distributed across the speaker 
processes but it's worth nothing that in case of a failure of one process/AF 
the other AFs are intact.

The other "current" possibility on XR is to run Multi-Instance BGP.
In this mode each BGP instance (max 4) is a completely separate set of 
processes running on the same or different RP or DRP the processes don’t share 
any RIB so no need for distributed adj-rib-in.
If required each instance can have a different AS number.

I'm not familiar with TimOS (other than reviewing the config guide) so I'd be 
interested to see what options are there.


adam



Adam Vitkovsky
IP Engineer

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

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

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


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

Re: [j-nsp] Multi Core on JUNOS?

[Phil Bedard]

I thought I saw a roadmap blurb about multi-core RPD in 16.x.  I think its a 
considerable amount of work.  

Phil

-Original Message-
From: "Olivier Benghozi" 
Sent: ‎10/‎2/‎2015 8:41 PM
To: "juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] Multi Core on JUNOS?

I have heard that:
1) forget it about PowerPC CPUs (MX 80/104).
2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP 
activated; but I guess that as long as rpd won't be recoded accordingly, it 
won't be any faster.

> Le 2 oct. 2015 à 23:33, Phil Rosenthal  a écrit :
> 
>> On Oct 2, 2015, at 5:11 PM, Colton Conor > > wrote:
>> 
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?
>> 
> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>> 
>>> 
>>> 
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
 
 
 "Statement introduced in Junos OS Release 13.3 R4"
>>> 
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>> 
>>> 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] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

[Phil Bedard]

If you want full line rate to the fabric on all ports you can only use 12, but 
the oversubscription is small. The fabric BW is like 37G for the set of four 
ports.  If you are sending traffic between two ports on the same PFE it doesn't 
count and you can get line rate on all 16 ports if your traffic makeup fits and 
connections are in the right places.  

In the OP scenario I assume he is using the 10G for clients and 100G as uplinks 
so he would run into the limitation.  

This was on the 960 I am not sure if the 240 is any different.  

Phil

-Original Message-
From: "joel jaeggli" <joe...@bogus.com>
Sent: ‎9/‎27/‎2015 3:49 PM
To: "Phil Bedard" <phil...@gmail.com>; "Robert Hass" <robh...@gmail.com>; 
"juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

On 9/27/15 12:01 PM, Phil Bedard wrote:
> The 16x10G cards are not going to be full line rate at all packet
> sizes and depending on destinations can't push full line rate due to
> limitations to fabric BW on each PFE.

afaik the 16 x 10 fixed mpc was 1.2:1 oversubscribed.

> Phil
> 
> -Original Message- From: "Robert Hass" <robh...@gmail.com> 
> Sent: ‎9/‎26/‎2015 8:42 AM To: "juniper-nsp@puck.nether.net"
> <juniper-nsp@puck.nether.net> Subject: [j-nsp] Cheaper way to have
> 2x100G and 16x10G wire-speed in MX480
> 
> Hi What is cheapest way to choose proper MPC/MICs to have 2x100G and
> 16x10G all wire-speed plus possibility to extend my configuration to
> total 32x10G and 4x100G ?
> 
> Is it possible to have 200Gbps (400G in both directions) per slot in
> cast of malfunction of one fabric card ?
> 
> What you can suggest ?
> 
> 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
> 


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

Re: [j-nsp] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

[Phil Bedard]

The 16x10G cards are not going to be full line rate at all packet sizes and 
depending on destinations can't push full line rate due to limitations to 
fabric BW on each PFE. 

Phil

-Original Message-
From: "Robert Hass" 
Sent: ‎9/‎26/‎2015 8:42 AM
To: "juniper-nsp@puck.nether.net" 
Subject: [j-nsp] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

Hi
What is cheapest way to choose proper MPC/MICs to have 2x100G and 16x10G
all wire-speed plus possibility to extend my configuration to total 32x10G
and 4x100G ?

Is it possible to have 200Gbps (400G in both directions) per slot in cast
of malfunction of one fabric card ?

What you can suggest ?

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] Cisco ME3600 migration to something with more 10 gigports

[Phil Bedard]

Yeah the PTX1K is a 2.88 Tbps box with 28 100G ports, not exactly comparable to 
a ACX or ASR920 in ports or pricing.  :)  Cisco doesn't really have anything 
comparable to it at the moment. The ACX or MX80 is what Juniper has that 
competes with the ASR920.  

Phil

-Original Message-
From: Mark Tinka mark.ti...@seacom.mu
Sent: ‎7/‎14/‎2015 3:26 AM
To: Ivan Ivanov ivanov.i...@gmail.com; Aaron aar...@gvtc.com
Cc: Juniper List juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Cisco ME3600 migration to something with more 10 gigports



On 13/Jul/15 17:40, Ivan Ivanov wrote:


 PTX1000
 https://www.juniper.net/us/en/products-services/routing/ptx-series/ptx1000/

Looks good, but won't hit the ME3600X/ASR920 price-point.


 For cheaper option you can check ACX5000.

 ACX5000
 https://www.juniper.net/us/en/products-services/routing/acx-series/acx5000/

Broadcom chipset, as I mentioned to the OP on c-nsp. Limits your options.

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] SNMP OID for last signalled LSP bandwidth

[Phil Bedard]

It just returns the current RSVP-signaled bandwidth, whether it was 
auto-bandwidth setting the value or not. 

Phil 




-Original Message-
From: Vijesh Chandran
Date: Monday, March 16, 2015 at 15:29
To: Phil Bedard, juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SNMP OID for last signalled LSP bandwidth

Thanks Phil for reply.
Is this really returning auto bandwidth stuff? The last signaled one?

Regards,
Vijesh
Mob:669.777.8502




On 3/16/15, 10:35 AM, Phil Bedard phil...@gmail.com wrote:

Here is a snippet from an old script I had to get the snmp stats and
current RSVP reservation.

This first OID .1.3.6.1.4.1.2636.3.2.3.1.1 you walk and it returns the
names and dynamic OIDs of the ingress LSPs.  The $1 awk returns is the
specific OID associated with an LSP.

snmpbulkwalk -v2c -Oan -c $comm $router .1.3.6.1.4.1.2636.3.2.3.1.1 | awk
'{sub(/^.1.3.6.1.4.1.2636.3.2.3.1.1/, );print $1}'

my $lsp_bytes_oid = .1.3.6.1.4.1.2636.3.2.3.1.3;
my $lsp_bw_oid = 1.3.6.1.4.1.2636.3.2.3.1.21;

Those are the two OIDs where the second one is for the RSVP reservation.
In order to get the value you'll have to concatenate the OIDs from the
first one onto the second one.  As an example if I have an LSP from the
first one with a returned value of:

.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.66.80.82.74.48.49.45.49.45.6
6.69.0.0.0.0.0.0

You can get the current RSVP reservation with the full OID

1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.6
6.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0


snmpget -v2c -Oan -c mycommunity 10.4.6.26
.1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.
66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0
.1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.
66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0 = INTEGER: 1000


The value returned is in Kbps.


The first OID grabs the current byte stats from the LSP but it's not
reliable, there are points where the value will reset to 0 and you don't
really know when it's going to be.  Another way to get the data is via
Junosscript.  You can use this call:

$jnx-get_mpls_lsp_information(ingress = 1, detail = 1, statistics
= 1);   It will return all the information you need, you just have to
scrape the data from the returned output.


Phil 




-Original Message-
From: Vijesh Chandran
Date: Monday, March 16, 2015 at 00:19
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] SNMP OID for last signalled LSP bandwidth


Is my following assumptions correct?
Below red colored one is the last signaled/reserved bandwidth for a
given LSP (this one). What would be the SNMP OID to get this value if
yes.
LSP is configured as autobandwidth.


User@routershow mpls lsp name
FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-1 detail
Ingress LSP: 376 sessions

17.0.129.1
  From: 17.0.146.2, State: Up, ActiveRoute: 0, LSPname:
FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-1
  ActivePath: FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-10 (primary)
  Node/Link protection desired
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Least-fill
  Autobandwidth
  ^
  MaxBW: 20Gbps
  AdjustTimer: 43200 secs AdjustThreshold: 10%
  Max AvgBW util: 42.739Mbps, Bandwidth Adjustment in 4046 second(s).
  Overflow limit: 3, Overflow sample count: 0
  Underflow limit: 0, Underflow sample count: 130, Underflow Max AvgBW:
42.739Mbps
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary   FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-10 State: Up
Priorities: 7 7
Bandwidth: 47.5412Mbps# Presumably, this is the last
signaled/reserved bandwidth for this LSP correct?  If yes, what is the
SNMP OID for this? Is this mplsPathInfoBandwidth?
^^
OptimizeTimer: 1800
SmartOptimizeTimer: 180
  Include Any: AMR POP BB-JNPRExclude: DONOTINCLUDE
Reoptimization in 824 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 730)
17.0.148.80 S 17.0.148.75 S 17.0.136.103 S 17.0.156.81 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
10=SoftPreempt 20=Node-ID):
  17.0.148.2(flag=0x29) 17.0.148.80(flag=9 Label=646346)
17.0.136.2(flag=0x29 Label=16324) 17.0.148.75(flag=9 Label=16324)
17.0.156.1(flag=0x21 Label=22971) 17.0.136.103(flag=1 Label=22971)
17.0.129.1(flag=0x20 Label=3) 17.0.156.81(Label=3)
  Secondary FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-20 State: Dn
Priorities: 7 7
OptimizeTimer: 1800
SmartOptimizeTimer: 180
  Include Any: BB BB-JNPRExclude: DONOTINCLUDE
No computed ERO.
   1028 Feb  6 21:54:00.328 Clear Call
Total 1 displayed, Up 1, Down 0
---snip-


Regards,
Vijesh
Mob:669.777.8502
___
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

Re: [j-nsp] SNMP OID for last signalled LSP bandwidth

[Phil Bedard]

Here is a snippet from an old script I had to get the snmp stats and current 
RSVP reservation.  

This first OID .1.3.6.1.4.1.2636.3.2.3.1.1 you walk and it returns the names 
and dynamic OIDs of the ingress LSPs.  The $1 awk returns is the specific OID 
associated with an LSP.

snmpbulkwalk -v2c -Oan -c $comm $router .1.3.6.1.4.1.2636.3.2.3.1.1 | awk 
'{sub(/^.1.3.6.1.4.1.2636.3.2.3.1.1/, );print $1}'

my $lsp_bytes_oid = .1.3.6.1.4.1.2636.3.2.3.1.3;
my $lsp_bw_oid = 1.3.6.1.4.1.2636.3.2.3.1.21;

Those are the two OIDs where the second one is for the RSVP reservation.  In 
order to get the value you'll have to concatenate the OIDs from the first one 
onto the second one.  As an example if I have an LSP from the first one with a 
returned value of:  

.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0

You can get the current RSVP reservation with the full OID 

1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0


snmpget -v2c -Oan -c mycommunity 10.4.6.26 
.1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0
.1.3.6.1.4.1.2636.3.2.3.1.21.78.69.80.54.68.83.82.74.48.50.45.78.69.80.54.66.80.82.74.48.49.45.49.45.66.69.0.0.0.0.0.0
 = INTEGER: 1000


The value returned is in Kbps.  


The first OID grabs the current byte stats from the LSP but it's not reliable, 
there are points where the value will reset to 0 and you don't really know when 
it's going to be.  Another way to get the data is via Junosscript.  You can use 
this call:  

$jnx-get_mpls_lsp_information(ingress = 1, detail = 1, statistics = 
1);   It will return all the information you need, you just have to scrape 
the data from the returned output.  


Phil 




-Original Message-
From: Vijesh Chandran
Date: Monday, March 16, 2015 at 00:19
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] SNMP OID for last signalled LSP bandwidth


Is my following assumptions correct?
Below red colored one is the last signaled/reserved bandwidth for a given LSP 
(this one). What would be the SNMP OID to get this value if yes.
LSP is configured as autobandwidth.


User@routershow mpls lsp name FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-1 
detail
Ingress LSP: 376 sessions

17.0.129.1
  From: 17.0.146.2, State: Up, ActiveRoute: 0, LSPname: 
 FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-1
  ActivePath: FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-10 (primary)
  Node/Link protection desired
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Least-fill
  Autobandwidth
  ^
  MaxBW: 20Gbps
  AdjustTimer: 43200 secs AdjustThreshold: 10%
  Max AvgBW util: 42.739Mbps, Bandwidth Adjustment in 4046 second(s).
  Overflow limit: 3, Overflow sample count: 0
  Underflow limit: 0, Underflow sample count: 130, Underflow Max AvgBW: 
 42.739Mbps
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary   FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-10 State: Up
Priorities: 7 7
Bandwidth: 47.5412Mbps# Presumably, this is the last signaled/reserved 
 bandwidth for this LSP correct?  If yes, what is the SNMP OID for this? Is 
 this mplsPathInfoBandwidth?
^^
OptimizeTimer: 1800
SmartOptimizeTimer: 180
  Include Any: AMR POP BB-JNPRExclude: DONOTINCLUDE
Reoptimization in 824 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 730)
17.0.148.80 S 17.0.148.75 S 17.0.136.103 S 17.0.156.81 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 
 10=SoftPreempt 20=Node-ID):
  17.0.148.2(flag=0x29) 17.0.148.80(flag=9 Label=646346) 
 17.0.136.2(flag=0x29 Label=16324) 17.0.148.75(flag=9 Label=16324) 
 17.0.156.1(flag=0x21 Label=22971) 17.0.136.103(flag=1 Label=22971) 
 17.0.129.1(flag=0x20 Label=3) 17.0.156.81(Label=3)
  Secondary FROM-USNYC3-BBISP-GW2-TO-USSJC2-BB-PE1-VRF-20 State: Dn
Priorities: 7 7
OptimizeTimer: 1800
SmartOptimizeTimer: 180
  Include Any: BB BB-JNPRExclude: DONOTINCLUDE
No computed ERO.
   1028 Feb  6 21:54:00.328 Clear Call
Total 1 displayed, Up 1, Down 0
---snip-


Regards,
Vijesh
Mob:669.777.8502
___
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] MPLS VPN BGP Local Convergence

[Phil Bedard]

There is an older feature called MPLS Egress Protection for L3VPNs which 
perhaps is being replaced by BGP PIC Edge, since they are both PE 
protection mechanisms.  

http://www.juniper.net/documentation/en_US/junos14.1/topics/topic-map/mpls-
egress-protection-layer-3-vpn-services-configuration.html

You can use the same feature for protecting labeled unicast global routes 
for something like Seamless MPLS or Inter-AS Option C setups.  

They also have a feature called L3VPN PE Edge Protection that is 
specifically used to setup a backup path to cover a PE-CE failure.  

http://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/layer
-3-vpn-pe-edge-protection.html



Phil 




On 1/21/15, 10:52 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote:

Right the documentation is concerning the BGP PIC Edge just for MPLS 
L3VPNs and in a context that it is a remedy for only PE failure not the 
CE-PE link failure (I'll assume the draft has been followed though). 
But now I'm thinking since it's configured under the routing options 
-wouldn't it work for all AFs i.e. non VPN traffic as well? 
Has anyone tested that please? 
Or has anyone tested the Junos BGP PIC Edge for CE-PE link failure for 
that matter? 

 
adam
 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Adam Vitkovsky
 Sent: 20 January 2015 23:08
 To: Saku Ytti; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] MPLS VPN BGP Local Convergence
 
 Hi Saku,
 
 Yeah the BGP local convergence is an old one indeed from days where we
 had to run iBGP multipath load sharing to get two paths programed into 
the
 HW.
 However this feature is essential for fast convergence.
 
 This feature prevents from blackholing during BGP convergence in cases
 where you have primary and backup egress PEs and  a PE-CE link fails on 
the
 primary PE.
 While the BGP infrastructure is converging the ingress PEs keep on 
sending
 data towards the primary PE with the failed PE-CE link that would 
otherwise
 drop the packets.
 Primary PE running MPLS VPN BGP Local Convergence feature will keep 
the
 VPN(e.g. per in-vrf-NH) label for the failed link for some time (which 
would
 be otherwise released).
 But the label no longer points to the egress PE-CE in-vrf-NH but now it 
points
 to a NH label on the path towards the backup PE.
 So that's how the Primary PE does kind of local repair till the BGP 
converges
 and ingres PEs start using backup PE as the NH for the VPN prefixes.
 
 Right solving a PE router failure is easy as IGP will notify all PEs in 
no time and
 they can then start using the preinstalled backup path(PIC)  or just 
reprogram
 the chained NHs to point to an alternate forwarding NH which should be
 fairly quick as well.
 
 But with failed CE-PE link all you've got to let everybody know is the 
slow BGP
 process (unless you put your CE-PE links into IGP which is the way it 
was
 done back in the old old days - pure ipv4 BGP core).
 This is where the BGP local convergence feature becomes handy.
 
 adam
  -Original Message-
  From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
 Behalf
  Of Saku Ytti
  Sent: 20 January 2015 18:49
  To: juniper-nsp@puck.nether.net
  Subject: Re: [j-nsp] MPLS VPN BGP Local Convergence
 
  On (2015-01-20 16:57 +), Adam Vitkovsky wrote:
 
   Hi Folks,
  
   Is there an equivalent to the MPLS VPN BGP Local Convergence 
feature
  on Junos please?
   Possibly for non VPN prefixes as well.
 
 
 http://www.juniper.net/documentation/en_US/junos14.2/topics/task/confi
  guration/layer3-vpn-bgp-pic-edge-configuring.html
 
  I don't really recall difference in 'local convergence' and BGP PIC, 
but I
  seem to recall, 'local convergence' didn't install backup path, but
  recalculated it when fault occurred.
  I don't know if this inferior version is available in JunOS or if 
you'd even
  want to run it, if it were.
 
  rant
  Unfortunately only for VPN. Why oh why do we have concept of global
 table
  and
  VRF, INET should in same code path as VRF, with no special treatment.
  Juniper
  still introduced in 14.2 features that work only in global table. 
This feature
  disparity between global and vrf is highly annoying. And I'm sure it 
adds
  development costs to consider these different things. Rather than pay 
one
  time
  cost to redesign the legacy code, vendors opt to pay for decades to 
support
  the old architecture which things they are different things.
  /rant
 
 
  --
++ytti
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
-
--
  This email has been scanned for email related threats and delivered 
safely
 by Mimecast.
  For more information please visit http://www.mimecast.com
 
-

Re: [j-nsp] juniper qfx5100 vs ex9200

[Phil Bedard]

It all comes down to what kind of features and scale you want on the edge 
of the network.   

The QFX5100 is a pretty capable box, it does things the EX9200 doesn't do 
like RSVP-TE.  You aren't going to find anything comparable from another 
vendor, especially if you want MPLS.   

I'd talk to Juniper because they should have some new stuff coming out 
next year which is very decent as well.  

Doug Hanks just wrote a good QFX5100 book and it's pretty cheap on 
O'Reilly if you really want to more about it in depth.  

Phil 

From:  Randy Manning rmann...@packetdesign.com
Date:  Wednesday, December 24, 2014 at 10:37 PM
To:  Phil Bedard phil...@gmail.com, Nitzan Tzelniker 
nitzan.tzelni...@gmail.com
Cc:  Chuck Anderson c...@wpi.edu, juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net
Subject:  Re: [j-nsp] juniper qfx5100 vs ex9200

Who is right? Phil  or Nitzan?  I don’t want to do a layer 3 only platform 
like the MX?  Should I look at Cisco?

Thanks,
-
Randy Manning
Systems Engineer
Packet Design | 7801 N. Capital of Texas Hwy, Suite 230 | Austin, TX 78731
Office: +1.301.395.1772 | Fax: +1.512.865.6950
Visit our Website | Follow us on Twitter | Join us on LinkedIn




From: Phil Bedard phil...@gmail.com
Date: Wednesday, December 24, 2014 at 4:11 PM
To: Nitzan Tzelniker nitzan.tzelni...@gmail.com
Cc: Chuck Anderson c...@wpi.edu, Randall Manning 
rmann...@packetdesign.com, juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] juniper qfx5100 vs ex9200

I think the 9200 actually has less QoS features and less buffers than the 
MX cards, but it depends on which MX cards you have.   The EX9200 
linecards are generally cheaper because it doesn't have the features or 
FIB capacity the MX cards do.

It's exactly the same chassis/midplane/fabric with a slightly modified 
chipset on the linecards, and the linecards are a different color.   The 
MX does L2, VXLAN, OVSDB, OpenFlow, etc.   There is no reason they 
couldn't have made the same linecards for the MX, but it requires more 
software development to deal with interop versions between cards with 
different resources.   It was kind of a mess with the DPC/MPC, maybe that 
was reason enough to say you couldn't mix and match linecards.

Phil 

From: Nitzan Tzelniker nitzan.tzelni...@gmail.com
Date: Wednesday, December 24, 2014 at 1:30 PM
To: Phil Bedard phil...@gmail.com
Cc: Chuck Anderson c...@wpi.edu, Randy Manning 
rmann...@packetdesign.com, juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] juniper qfx5100 vs ex9200

My view 

EX9200 has better qos features, larger buffers 100G interfaces , better L2 
features (QinQ,Vlan per port ... ) ,VxLAN routing 
BTW to prevent SP from using the 9200 as P router it doesn't support RSVP  

For most cases QFX will do the job but if you want MX for your DC but 
80/104 is to small and 240 is to expensive the EX9200 is a great box 

Nitzan


On Wed, Dec 24, 2014 at 6:30 PM, Phil Bedard phil...@gmail.com wrote: 
I believe the QFX5100 will support EVPN, but using VXLAN as the underlying 
forwarding mechanism instead of MPLS.  So technically the P boxes in the 
middle just need to do IP routing and not MPLS.

TBH I never understood the 9200, it reminds me of the 6500/7600 split 
except it's the 9200/MX.

Phil

-Original Message-
From: Chuck Anderson c...@wpi.edu
Sent: ‎12/‎24/‎2014 10:08 AM
To: Randy Manning rmann...@packetdesign.com
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] juniper qfx5100 vs ex9200

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

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

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

On Wed, Dec 24, 2014 at 03:55:30AM +, Randy Manning wrote:
 People,

 Any advice on a distribution layer switch for campus networks?  juniper
 qfx5100 vs ex9200?  I am not sure what the requirements need to be a
 priority.  The core is MX 960 and currently routing.  I am thinking about
 campus distro¹s becoming PE with TE and allowing the core¹s to label
 switch only?  Given the current network and possible change, which
 platform is the best?  Qfx or ex?

 Data centers are working well with q-fabric, but I understand that has
 been abandoned by juniperŠ. Which is sadŠ I liked the eVPN BGP NLRI 
design.


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

Re: [j-nsp] juniper qfx5100 vs ex9200

[Phil Bedard]

I believe the QFX5100 will support EVPN, but using VXLAN as the underlying 
forwarding mechanism instead of MPLS.  So technically the P boxes in the 
middle just need to do IP routing and not MPLS.

TBH I never understood the 9200, it reminds me of the 6500/7600 split except 
it's the 9200/MX. 

Phil

-Original Message-
From: Chuck Anderson c...@wpi.edu
Sent: ‎12/‎24/‎2014 10:08 AM
To: Randy Manning rmann...@packetdesign.com
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] juniper qfx5100 vs ex9200

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

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

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

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

Re: [j-nsp] experience with modeling tool

[Phil Bedard]

Junosphere doesn't do that type of modeling and simulation but WANDL does.  
Juniper may be working on Junosphere/WANDL integration now that they own WANDL. 
They used to support Cariden MATE within Junosphere but stopped when Cisco 
bought Cariden.  

WANDL will certainly do what you want, I would talk to your sales rep about it. 
 The other popular tools are Cariden MATE now owned by Cisco and OpNet now 
owned by Riverbed.  

Cariden was the easiest to use in my previous experience.  

Phil

-Original Message-
From: jjsyed--- via juniper-nsp juniper-nsp@puck.nether.net
Sent: ‎12/‎23/‎2014 7:52 PM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: [j-nsp] experience with modeling tool

Hello,

can somebody give me  feedback on the two tool I am thinking about using and 
cannot decide which one to use. I think the answer depends on what needs to be 
done? I am planning to decommission some services from my backbone and like to 
move over those existing ckt to pt to pt link. I am pretty sure there will be 
change in traffic pattern , flows etc, so I need to know which tool can help me 
or give me good picture of the network in present and future state.  I am 
looking at wandl or Junosphere. 
 
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] juniper qfx5100 vs ex9200

[Phil Bedard]

I think the 9200 actually has less QoS features and less buffers than the 
MX cards, but it depends on which MX cards you have.   The EX9200 
linecards are generally cheaper because it doesn't have the features or 
FIB capacity the MX cards do.

It's exactly the same chassis/midplane/fabric with a slightly modified 
chipset on the linecards, and the linecards are a different color.   The 
MX does L2, VXLAN, OVSDB, OpenFlow, etc.   There is no reason they 
couldn't have made the same linecards for the MX, but it requires more 
software development to deal with interop versions between cards with 
different resources.   It was kind of a mess with the DPC/MPC, maybe that 
was reason enough to say you couldn't mix and match linecards.

Phil 

From:  Nitzan Tzelniker nitzan.tzelni...@gmail.com
Date:  Wednesday, December 24, 2014 at 1:30 PM
To:  Phil Bedard phil...@gmail.com
Cc:  Chuck Anderson c...@wpi.edu, Randy Manning 
rmann...@packetdesign.com, juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net
Subject:  Re: [j-nsp] juniper qfx5100 vs ex9200

My view

EX9200 has better qos features, larger buffers 100G interfaces , better L2 
features (QinQ,Vlan per port ... ) ,VxLAN routing 
BTW to prevent SP from using the 9200 as P router it doesn't support RSVP  

For most cases QFX will do the job but if you want MX for your DC but 
80/104 is to small and 240 is to expensive the EX9200 is a great box 

Nitzan


On Wed, Dec 24, 2014 at 6:30 PM, Phil Bedard phil...@gmail.com wrote:
I believe the QFX5100 will support EVPN, but using VXLAN as the underlying 
forwarding mechanism instead of MPLS.  So technically the P boxes in the 
middle just need to do IP routing and not MPLS.

TBH I never understood the 9200, it reminds me of the 6500/7600 split 
except it's the 9200/MX.

Phil

-Original Message-
From: Chuck Anderson c...@wpi.edu
Sent: ‎12/‎24/‎2014 10:08 AM
To: Randy Manning rmann...@packetdesign.com
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] juniper qfx5100 vs ex9200

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

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

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

On Wed, Dec 24, 2014 at 03:55:30AM +, Randy Manning wrote:
 People,

 Any advice on a distribution layer switch for campus networks?  juniper
 qfx5100 vs ex9200?  I am not sure what the requirements need to be a
 priority.  The core is MX 960 and currently routing.  I am thinking about
 campus distro¹s becoming PE with TE and allowing the core¹s to label
 switch only?  Given the current network and possible change, which
 platform is the best?  Qfx or ex?

 Data centers are working well with q-fabric, but I understand that has
 been abandoned by juniperŠ. Which is sadŠ I liked the eVPN BGP NLRI 
design.


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

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

Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

[Phil Bedard]

The 16x10G MPC is not quite line rate full duplex because the PFE processing 
capacity is a little over 70G total per 4 ports.  If the traffic is internal to 
the PFE it doesn't count towards that.  If your ports are mostly incoming 
traffic or outgoing its not an issue,but if you truly had bidirectional high 
traffic levels you will get about 35G in each direction if it is all headed 
to/from the fabric. 

Also on the MX960 at least the fabric connection is only about 38G so you wont 
get a full 40G line rate in one direction either. 

Phil

-Original Message-
From: Tobias Heister li...@tobias-heister.de
Sent: ‎11/‎30/‎2014 7:08 PM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

Hi,

Am 01.12.2014 um 00:22 schrieb Robert Hass:
 I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960
 routers.

 I need to add 10GE ports, if I will put second 10x10GE MIC in existing
 MPC3E what will be oversubscribe rate ? I'm not sure but docs says about
 200Gbps for MPC3E then It should be wire-speed if docs claims full-duplex
 or 1:2 if docs claims half-duplex.

Afaik the MPC3E has one 130G Trio so two 10x10GE will be oversubribed 200:130

 What is best solution (from price point of view) to have 16 x 10GE in 1
 slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ?

The 16x10GE is line rate (with SCBE and higher) there is also the 32x10 MPC4E 
wich is oversubriced 320:260 on SCBE or line rate on SCBE2.
So depending on your SCB and the need for linerate you have several choices.  
Then just do the math and calculate your per 10G oversub/line rate port price.

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

Re: [j-nsp] Transfer some task from MX to VRR

[Phil Bedard]

On 12/1/14, 2:41 PM, Robert Hass robh...@gmail.com wrote:

I think vMX can forward data.

vMX indeed will be full-featured router. But my questions was related to
move part of control-plane (basically whole BGP part of rpd) to external
server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP
to customers ? Session should be on router or on OpenFlow controller ? OF
v1.3 just has been implemented in JunOS 14.x releases for MX series.

Juniper as far as I know plans on maintaining two versions of the vMX at 
least to start with.  The vRR version is similar to the one used for 
things like lab testing and uses 1 VM with both the vRE and vPFE 
integrated.  The vRR is not meant to be in the forwarding path just like 
the vRR offerings from ALU and Cisco.  You would not really want to use it 
to terminate eBGP sessions.   

There is another higher speed forwarding version of the vMX which requires 
using Intel 10GE NICs.  It doesn't really support high speed 1G since it 
uses the Intel DPDK/SR-IOV specific to those 10G cards.  ALU has the same 
exact thing with their VSR series.  

Now that version of the vMX would be one which could terminate customer 
circuits and EBGP sessions.  The perfect scenario for it is terminating 
lower-speed Ethernet Internet customers since those usually don't require 
much advanced processing like NAT, etc.   

Long-term most of the vendors have plans to externalize the control 
planes.  Juniper has experience with this since they have done it with the 
TX-Matrix and the old EX8200 virtual chassis stuff previously.  I think 
you will see all vendors headed this way though especially when it comes 
to things like subscriber management/bras functionality.  No reason to 
limit those things to a router RE anymore.  


Phil 



BTW. Are anyone participating in vMX beta-trial ?

Rob


On Mon, Dec 1, 2014 at 3:06 PM, Mark Tinka mark.ti...@seacom.mu wrote:

 On Monday, December 01, 2014 03:09:15 PM Eric Van Tol wrote:

  I'm pretty sure the VRR is mostly for solving the problem
  of iBGP session scaling.  If that's not the case, I'm
  sure someone will correct me.

 I think vMX can forward data. It will come down to how well
 it optimizes the CPU, and how good the CPU actually is.

  You don't have much choice with eBGP if you don't want to
  use multihop, unless you want to backhaul every customer
  circuit via L2 to your VRR, in which case the VRR is
  basically the gateway for the customer's circuit.

 Agree.

 Your design can get complicated if you separate routing from
 forwarding for a particular device or downstream-set.

 Mark.

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

Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

[Phil Bedard]

Yes.  We only use 3 ports per group in some situations. We have a couple 
hundred of them deployed. 

Phil

-Original Message-
From: Daniel Stamatov daniel.stama...@interoute.com
Sent: ‎12/‎1/‎2014 9:11 AM
To: Phil Bedard phil...@gmail.com; Tobias Heister 
li...@tobias-heister.de; juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

Huh?
Is this valid for SCBE as well?

Daniel
   

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
Of Phil Bedard
Sent: Monday, December 01, 2014 2:58 PM
To: Tobias Heister; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

The 16x10G MPC is not quite line rate full duplex because the PFE processing
capacity is a little over 70G total per 4 ports.  If the traffic is internal 
to the PFE
it doesn't count towards that.  If your ports are mostly incoming traffic or
outgoing its not an issue,but if you truly had bidirectional high traffic 
levels you
will get about 35G in each direction if it is all headed to/from the fabric.

Also on the MX960 at least the fabric connection is only about 38G so you
wont get a full 40G line rate in one direction either.

Phil

-Original Message-
From: Tobias Heister li...@tobias-heister.de
Sent: ‎11/‎30/‎2014 7:08 PM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs

Hi,

Am 01.12.2014 um 00:22 schrieb Robert Hass:
 I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960
 routers.

 I need to add 10GE ports, if I will put second 10x10GE MIC in existing
 MPC3E what will be oversubscribe rate ? I'm not sure but docs says
 about 200Gbps for MPC3E then It should be wire-speed if docs claims
 full-duplex or 1:2 if docs claims half-duplex.

Afaik the MPC3E has one 130G Trio so two 10x10GE will be oversubribed
200:130

 What is best solution (from price point of view) to have 16 x 10GE in
 1 slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ?

The 16x10GE is line rate (with SCBE and higher) there is also the 32x10 MPC4E
wich is oversubriced 320:260 on SCBE or line rate on SCBE2.
So depending on your SCB and the need for linerate you have several choices.
Then just do the math and calculate your per 10G oversub/line rate port price.

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

Re: [j-nsp] Transfer some task from MX to VRR

[Phil Bedard]

They sell XRv now specifically as a vRR, you can find the deployment guides on 
their website.  

The throughput on it isn't very good and they suggest using the CSR if you 
really want a software router.  The only other thing they have XRv for is 
testing.  

Juniper doesn't really have two tracks, its the same RE software, just think of 
it like using two different line modules in the same router.  I just don't 
think they have quite made it seamless at this point.  

Phil

-Original Message-
From: Mark Tinka mark.ti...@seacom.mu
Sent: ‎12/‎1/‎2014 11:52 AM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Cc: Phil Bedard phil...@gmail.com; Robert Hass robh...@gmail.com
Subject: Re: [j-nsp] Transfer some task from MX to VRR

On Monday, December 01, 2014 05:27:23 PM Phil Bedard wrote:

 Juniper as far as I know plans on maintaining two
 versions of the vMX at least to start with.  The vRR
 version is similar to the one used for things like lab
 testing and uses 1 VM with both the vRE and vPFE
 integrated.  The vRR is not meant to be in the
 forwarding path just like the vRR offerings from ALU and
 Cisco.  You would not really want to use it to terminate
 eBGP sessions.

Don't know about the ALU offering, but Cisco don't have a 
vRR-type solution.

CSR1000v is a full-fledged router. What you can do and how 
much traffic you can forward through it is all controlled by 
what license you buy.

I find this a better use of vendor resources than 
maintaining two separate tracks.

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

Re: [j-nsp] Filtering rib-group imported direct routes?

[Phil Bedard]

Can you apply an import policy to the rib group to weed those out?  Also the 
newer versions of Junos support Cisco PBR like functionality straight from the 
firewall filter instead of having to deal with the instances, so traffic goes 
directly out an interface vs. being subject to LPM in another routing table.  

Phil

-Original Message-
From: Chris Woodfield rek...@semihuman.com
Sent: ‎11/‎15/‎2014 3:14 PM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: [j-nsp] Filtering rib-group imported direct routes?

Hi,

I’m currently managing a setup where we’re at our edge, we're punting packets 
to a routing-instance based on firewall matches in order to separate traffic 
between outside client traffic (which needs to be routed through the LB on 
return) and other internet-facing outbound. We have rib-groups configured for 
our routing-instances to import the direct and local routes, like the below 
(simplified) config example:

routing-options {
interface-routes {
rib-group {
inet fbf-groups;
}
}
...
rib-groups {
fbf-groups {
import-rib [ inet.0 lb1.inet.0 ]
}
}
}
...
firewall {
family inet {
filter BOUNCE_TO_LB
from { 
protocol tcp;
source-port [ 80 443 ];
}
then {
routing-instance lb1;
}
}
}
}
...
routing-instances {
lb1 {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 1.2.3.4;
}
}
}
}

The lb1 routing-instance is simply a default route to the LB's gateway IP 
which is a directly connected interface to the router.

(This design is documented here: 
https://www.juniper.net/documentation/en_US/junos12.3/topics/example/logical-systems-filter-based-forwarding.html)

The problem I'm having is that because this setup imports all direct and local 
routes into the routing instance, packets that are punted to the routing 
instance that are destined for other directly connected hosts bypass the 
default route and get forwarded directly to the end host. For example, if I 
have a host hanging off of interface xe-2/0/0 with address 2.2.3.4/24, and I 
look in the routing-instance's table, I see:

edge-rtr show route table lb1.inet.0   

lb.inet.0: XXX destinations, XXX routes (XXX active, 0 holddown, X hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0  *[Static/5] 37w1d 15:53:29
 to 1.2.3.4 via xe-1/0/0
2.2.3.4/24 *[Direct/0] 11w3d 10:42:47
 via xe-2/0/0.0
2.2.3.1/32 *[Local/0] 11w3d 10:42:47
  Local via xe-2/0/0.0

So a packet with dest IP 2.2.3.4 goes directly to the host instead of going to 
the LB, which means it has the real host IP and not the VIP's IP as its source, 
which means no worky worky.

So the question I have is this - is there a way to filter the direct and local 
routes that are imported into a routing instance? In this case, I'd only want 
the direct route for the subnet containing 1.2.3.4, and no other direct routes.

Alternatively, would it be possible to *not* import any direct routes into the 
routing-instance (i.e. deleting the rib-groups syntax altogether) and instead 
add the direct and/or local route manually to the routing instance, so I can 
ensure that only the direct routes I need to resolve the next hop make it into 
the routing instance?

TIA,

-Chris





___
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 is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Phil Bedard]

It's an odd hardware platform compared to the rest of their offerings. 
Does not support 10G which is really needed these days. It's one of those 
platforms you are leery of them dropping at any time, kind of like the 
EX8200... 

Phil 




On 11/13/14, 11:34 AM, Austin Brower o...@bobman.net wrote:

On Nov 12, 2014, at 10:38 AM, Eric Van Tol blee...@gmail.com wrote:
 On Wed, Nov 12, 2014 at 10:04 AM, Mark Tinka mark.ti...@seacom.mu 
wrote:
 
 Juniper have continued to come short in this area. And no,
 the ACX doesn't cut it.
 
 Agreed.  ACX is just not there.  It baffles me why Juniper has left
 this market untapped.  The mid-range MX is just too expensive and too
 big for our deployments and the lack of LSR functionality in the EX
 won't work for us.

So far, Eric, Mark, and Phil have all stated that the ACX is not the 
right platform for their purposes.

Could you elaborate on why? I've been looking at the ACX with some 
curiosity as a migration tool for some of my fiber constrained sites 
where I have low capacity SONET systems (which are very slow to leave the 
network) and 1Gbps Ethernet switching (utilizing finicky ERPS).

Thanks,
Austin
___
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 is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Phil Bedard]

Maybe vMX is the answer to a 1U MX at this point, depending on the 
throughput you really need.  

Phil 




On 11/13/14, 1:49 PM, Eric Van Tol e...@atlantech.net wrote:

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf 
Of Austin Brower
Sent: Thursday, November 13, 2014 6:35 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] ACX is just not there (was Re: EX4550 L2Circuit/VPN to 
MX80/lt Interface)

So far, Eric, Mark, and Phil have all stated that the ACX is not the 
right platform for their purposes.

Could you elaborate on why? I've been looking at the ACX with some 
curiosity 

For starters, at least when we evaluated it last year, there was no 
switching or IRB support.  The chips are not Trio-based which means poor 
feature parity with our existing MX deployments (it really sucks creating 
separate class-of-service configs for every damn type of device).  
Firewall filters could not match based upon prefixes, but rather only a 
single IP address or port number.  There was also no hierarchical 
queuing, but I was told that it was on the roadmap for 2014.  I have not 
checked to see if that goal was met.  Finally, the cost to reach only 
half the port density of the ME3600X was also an issue.

It's a nice router, but it simply didn't seem to fit within the metro 
ethernet deployment model that we have.  I echo Mark's statement about 
being told that a 1U MX was on the way.  That was three years ago and I 
can't imagine why Juniper won't make one of these.  We have dozens of 
ME3600Xs deployed that I would gladly have used MX gear, assuming they 
didn't want to charge insane license fees for H-QoS and 10GE port 
enabling.

-evt

___
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 is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Phil Bedard]

Yes they don't really fit will with metro fiber rings unless everything is 
indoors, you certainly wouldn't deploy them at a cell tower or outdoor 
enclosure.  Really today the ALU 7210, ACX, ME3600, etc. are cheaper 
anyways.  

The vMX really has two flavors, one for low speed and one for high speed.  
The high speed one uses the Intel DPDK/SR-IOV and can push about 80Gbps 
half duplex doing normal routing.   ALU has the same thing and claims they 
can do 320Gbps half-duplex but 32x10G ports would need like an 8RU server 
:).  ALU a demo coming up with a bunch of servers in a rack managed as a 
single router supporting about 2Tbps of throughput.  They call those vMX, 
vSR, etc. but they aren't such that you could run 50 of them on a server.  
They require direct access to the 10G hardware.

Now the caveat is once you start throwing firewall filters, policing, NAT, 
64-byte packets, etc. the performance drops significantly, but for 512+ 
byte packets it's still pretty good unless you are doing a ton of stuff.  

There are companies like Advantech starting to sell 20 depth NEBS 
compliant carrier servers and servers with more network slots and my 
guess is you'll see more and more of them.  Biggest issue is cooling a 
general CPU which is beefy enough to support the throughput you may need.  
 


The vMX as a vRR works fine now, as does the XRv and vSROS ones from 
Cisco/ALU.  They are all fairly productized at this point.  I believe 
starting in 14.2 the vMX uses the same jinstall packages to upgrade as any 
other MX.  

Sorry for taking this off-topic. :) 

Phil 



On 11/13/14, 4:10 PM, Mark Tinka mark.ti...@seacom.mu wrote:

On Thursday, November 13, 2014 05:44:16 PM Eric Van Tol 
wrote:

  Or am I misunderstanding the vMX?  Not trying to be
 snarky, it's a serious question.  I am not sure where I
 would see the vMX in a production service provider
 network, but I am certainly open to ideas.

I'd deploy vMX as a route reflector. I was actually 
evaluating vRR a few months ago, but it still had a long way 
to go, so went with Cisco's CSR1000v (which is, basically, 
IOS XE) instead.

We run all our route reflectors on CSR1000v, off 1U HP 
servers. Very nice!

Mark.

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

Re: [j-nsp] Trio Bandwidth

[Phil Bedard]

I have the most familiarity with the 16x10GE cards which use 4 Trio chips,
but are similar to the other MPC2 cards.

Each of those Trio chips has 70G of bandwidth shared between the ingress
ports and the fabric like you mentioned.  Traffic going in/out of the same
PFE doesn't count against the 70Gbps, so you can creatively run them at
line-rate.  

There is also a small limitation with bandwidth from that generation Trio
to/from the fabric.  It's dependent on packet size but it's roughly
37Gbps.  You see this if you have 40G coming from the fabric headed
towards the 4 egress ports.
 
Phil 

On 5/30/14, 5:27 PM, Saku Ytti s...@ytti.fi wrote:

On (2014-05-30 11:54 -0700), joel jaeggli wrote:

 the bandwidth is symmetric... the forwarding lookup is only done on the
 ingress linecard.

(Memory) bandwidth is unidir, single Trio has maybe 70Gbps of memory
bandwidth
(it depends on cell alignment, it can be 80Gbps and in artificial scenario
could be lot less than 70Gbps). So if your ingress is 40Gbps you have only
30Gbps of egress.
Lookup performance is about 50-55Mpps, linerate in MPC would require
60Mpps,
so bit shy of that. But again, would really only surface in artificial
scenario.
On MX80 and MX104 it might plausibly be issue in some esoteric but
non-artificial scenario, as you have more 10 ports than 4 on Trio.

 larger microcode size
 
 which impacts the availability of some relatively esoteric features...

No. E model has better oscillator for timing shizzle and double the DDR3
memory on LU chip, which is not going to affect anything as far as I
know, as
it was upgraded to support now de-funct mobilenext product.

-- 
  ++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 finally launches a route reflector platform

[Phil Bedard]

Yeah I think the original use case was someone needed a way to export
Netflow off the PTX which has no native support but no reason it
couldn't be adapted for other uses.

Phil From: Tim Jackson
Sent: 3/6/2014 11:59
To: Julien Goodwin
Cc: juniper-nsp
Subject: Re: [j-nsp] Juniper finally launches a route reflector platform
After reading more about this, this seems to *just* be for the PTX... :(

On Mon, Feb 24, 2014 at 3:13 PM, Julien Goodwin
jgood...@studio442.com.au wrote:
 And in a sensible form factor too.

 http://www.juniper.net/us/en/products-services/routing/cse2000/

 Can think of plenty of other use cases for the box 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS-TP OAM

[Phil Bedard]

That¹s not true.  

http://www.juniper.net/techpubs/en_US/junos/topics/topic-map/mpls-tp-oam-co
nfiguration.html


Junos does support using the non-IP-based BFD OAM using the MPLT-TP
GAL/GACH.   

As for providers deploying MPLS-TP, I certainly don't know of any...

Phil 

On 12/4/13, 12:21 PM, Jerry Jones jjo...@danrj.com wrote:

JUNOS has no TP specific features, all OAM is available

dwdm systems normally use an osc for management

On Dec 4, 2013, at 8:46 AM, Yham yhamee...@gmail.com wrote:

Hi Friends,

I am trying to read about mpls-tp oam features that look probably the key
reason that lead service provider to deploy it.
Someone please tell me what are the key oam features are in mpls-tp that
cannot be deployed in mpls/ip network with or without traffic engineering?

As a network guy unfortunately i dont have much idea how what oam
features/attributes are used in dwdm based transport.


Thanks
Rameez
___
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] RIB - FIB filtering.

[Phil Bedard]

I don't consider a hack, it is what the feature is there for. Of course
it isn't something other vendors support.

Plus I can't think of another way to do it which isn't even more of a
hack.

Phil From: Peter Krupl
Sent: 11/9/2013 8:06
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] RIB - FIB filtering.
Dear group,

I need to advertise host specific routes for black-holing to our
upstream carriers. But it don't
necessarily want to black-hole the same destinations within our own network.

So in order to get our router to advertise, it must think that the
route is active. So i inject a
valid route into our network from our central black-holing BGP router.
But prevent it from entering the FIB
like this:

set policy-options policy-statement export_rib_to_fib term
filter-blackhole-routes from community 9167-blackhole
set policy-options policy-statement export_rib_to_fib term
filter-blackhole-routes then reject
set policy-options policy-statement export_rib_to_fib term
load-balance then load-balance per-packet
set routing-options forwarding-table export export_rib_to_fib


I have tried to search via Google but i have not found any mention of
the above method.
It seems to work.. is this too hackish for production use ?

I could off course also just install a static host route at the edge
router facing the black-holed
destination, but then it's not a centralized solution. Also having to
install access routes for
connected destinations is ugly.



Is this a sane approach ? Your opinion is appreciated. Alternative approaches ?

Kind regards,
Peter Krüpl



___
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] VC question

[Phil Bedard]

The 4500 has a newer module with 64Gbps bi-directional links.  The 4550 you can 
use two of the modules to get the 256 number.

Phil

 On Oct 9, 2013, at 3:29 AM, Georgios Vlachos g.vlac...@kestrel-is.gr 
 wrote:
 
 
 Juniper VC is 32 Gbps per link (2), hence 64 Gbps full duplex actually.
 
 
 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
 Maarten van der Hoek
 Sent: Wednesday, October 09, 2013 9:41 AM
 To: 'Phil Fagan'; 'R S'
 Cc: 'juniper-nsp'
 Subject: Re: [j-nsp] VC question
 
 The Junos is of course a big plus...
 
 However next to this the Thoughput should be higher with the Junipers!
 
 As far as my info goes (not much Cisco equipment over here / sorry) they go
 up to 64 Gps where Juniper can go up to 128 Gbps (EX4200) and EX4550 up even
 to 256 Gbps.
 
 Would of course be interesting to hear if somebody has prove for these
 figures?... :-)
 
 Brgds,
 
 Maarten
 
 -Oorspronkelijk bericht-
 Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens Phil
 Fagan
 Verzonden: woensdag 9 oktober 2013 4:37
 Aan: R S
 CC: juniper-nsp
 Onderwerp: Re: [j-nsp] VC question
 
 Pro=junos
 Con=nonjunos
 
 :-)
 On Oct 8, 2013 10:05 AM, R S dim0...@hotmail.com wrote:
 
 
 
 Is anybody
 able to tell me which are the very technical pro and cons between 
 Juniper VC solution (vccp) against Cisco stack (Stackwise?) and Huwaei 
 stack
 (iStack?) solutions ?
 
 
 
 
 Tks
 
 
 ___
 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

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

Re: [j-nsp] EX4550 version

[Phil Bedard]

This is unrelated somewhat, but what are the current LAG member limits
as well as ECMP limits? Any restrictions on LAG+ECMP?

phil From: Sam
Sent: 7/24/2013 8:46
To: Bouzemarene, Farid (ATS)
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX4550 version
Hi Farid,

From an old case I had open with Juniper:

The EX4550 has an ARP table of maximum 8k entries.
 These entries are tracked in the kernel through something called tokens.
 Each ARP entry is a token.

 Because we have only 8k tokens available, from here we have the maximum 
 number of ARP entries.

 However, because of how the chipset of EX4550 is designed, the MPLS LSPs are 
 also making use of the same tokens.
 But each MPLS LSP is using 8 tokens. Therefore, 1000 LSPs would use all 
 tokens and no ARP can be learned.

 The token usage is scaled up by the number of ECMP next-hops. So 1 LSP with 4 
 ECMP next-hops will take 1*8*4=32 tokens.

--
sam


On 24 Jul 2013, at 11:28, Bouzemarene, Farid (ATS)
farid.bouzemar...@avnet.com wrote:

 Hello,

 Can you clarify the MPLS limits ?

 Thx

 - Message d'origine -
 De : Sam [mailto:sam...@arahant.net]
 Envoyé : Wednesday, July 24, 2013 10:39 AM
 À : Luca Salvatore l...@ninefold.com
 Cc : juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Objet : Re: [j-nsp] EX4550 version

 I used the 12.3R2.5 for quite some time now without any issue. The platform 
 has its limitations (especially related to how MPLS is handled), but if 
 you're just using it for L2 or basic L3 it works just fine.

 --
 sam

 On 24 Jul 2013, at 03:27, Luca Salvatore l...@ninefold.com wrote:

 Hi All,

 Just got a couple of new EX4550 switches... current recommended version is 
 12.2r2.5
 But I just saw tha the 12.2 train is up release 5.3.

 Just wondering what the rest of you guys are running  and if you have any 
 horror stories.
 I'm not doing VC with these guys, they are going to be a pretty simple layer 
 2 aggregation type switch.

 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

___
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 CoS - Pipe mode Short pipe mode

[Phil Bedard]

Not sure how much J-series is in this but a good document covering the
other platforms:  

http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-
collections/config-guide-cos/config-guide-cos.pdf




Phil 

On 7/15/13 5:44 AM, Werner le Grange wernerlegra...@gmail.com wrote:

Greetings

I have a requirement to preserve our clients DiffServe markings over our
MPLS network.

I'm looking for Juniper documentation to implement either (pipe mode or
short pipe mode) on our J-series and M-series routers.

Any useful configuration documentation will be helpful.


-Thanks
Werner
___
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 11.4R1.6 shipping on new EX-series switches,

[Phil Bedard]

 serious problems
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don't think I have once ever run the shipped version of code on a
piece of gear in production. Now if the version is not stable enough to
load a stable version that is another thing.

Heck my car's ECU didn't even come with the latest version with all the
fixes.

Phil From: Jeff Wheeler
Sent: =E2=80=8E6/=E2=80=8E23/=E2=80=8E2013 18:59
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Junos 11.4R1.6 shipping on new EX-series switches,
serious problems
On Sun, Jun 23, 2013 at 6:02 PM, Chris Adams c...@cmadams.net wrote:
 Once upon a time, Gavin Henry ghe...@suretec.co.uk said:
 We're getting two EX4200's and two MX5's delivered this week. Hope
 they have the recommend JTAC versions on them!

 Why do you expect they will?  The recommended releases are not very old;
 it isn't like Juniper (or any other vendor) is going to pull back all
 the stock in the supply chain and reload the OS every time they change
 the recommended release.

I don't expect them to do that.  I just expect a Release version that
isn't so bad, that the CLI is unusable, to be installed on the
switches from the factory.  Sure, it may take some weeks to deplete
all the remaining inventory that still has 11.4R1 on it, and that's
fine.  Continuing to ship a version that is so broken is idiotic.

Yes, as Mark says, customers who have a clue are going to install a
different version anyway.  Not every customer has a clue.  Some might
expect the software that ships on a switch that has been out for 4+
years to basically work right.  The reason it doesn't is they seem to
change the shipping Junos only when a new extended support release
comes out, or when new EX switches come out that they want to be able
to stack with older ones out of the box.  That would be fine if
those releases worked right.

Fix it, EX PMs!  This is a simple problem with a simple solution.

--=20
Jeff S Wheeler j...@inconcepts.biz
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] Best route reflector platform

[Phil Bedard]

I think at some point in the future there will be a virtualized Junos
which can be deployed on a server, with limitations, but should be
something that supports route reflection.

Juniper has JCS today but it's obviously not as small of a box as I would
like.  

Phil 

On 4/15/13 12:20 PM, Jeff Aitken jait...@aitken.com wrote:

On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote:
 ASR1001 with 16GB DRAM. What more do you want, really?

Well, it fails my must run IOS-XR or JUNOS requirement, for starters.
;-)
And seriously, who wants to implement routing policy in IOS?!  Bletch.

What I want is something based on a generic compute platform, ala
JUNOSphere/VIRL.  That lets me scale the control plane as big as I need
to,
avoids wasting money on purpose-built hardware optimized for forwarding,
and comes with the added bonus of using the same OS  policy language
that's already widely deployed in my network, so at least I don't get any
NEW interop issues.  The downside is that neither vendor sells such a
thing
right now, and so we're stuck arguing about which square peg fits best
into
the round hole.  (small ASR9k and MX here, FWIW)

Oh and I also want a two-vendor solution so that I'm (hopefully) not
completely screwed the next time one of them discovers a new attribute-
handling bug.


--Jeff

___
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] Best route reflector platform

[Phil Bedard]

At some point we might see a virtualized Junos especially with all the SDN
talk and various applications Juniper may want to split onto dedicated
computing hardware.  The JCS1200 is still pushed as a RR platform but
that's not exactly cheap, but the new RE has 48G of RAM.  They also
recommend using the PTX as a route reflector since it has a 16G, runs
64-bit Junos, and by default doesn't download BGP routes into the FIB.
Now that's a really expensive route reflector. :)

I would agree right now the MX240 is probably the best option with the 16G
RE.  


Phil 

On 2/25/13 10:32 AM, Saku Ytti s...@ytti.fi wrote:

On (2013-02-25 15:56 +0100), Benny Amorsen wrote:

 On the Cisco side the answer is ASR1k, but it seems less clear-cut with
 Juniper.

It is clear-cut, the answer just isn't satisfactory, MX240.

JNPR has ESX image for SRX firewall. Why not sell ESX image for
route-reflection?
I would prefer blazing fast 1RU PC, but I understand that keeping the HW
inventory refreshed regularly is a cost, and ESX image is much more
practical to sell.

-- 
  ++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 MX2020 operational experience?

[Phil Bedard]

Its not really out, we are getting a demo unit fairly soon. Vendors
have been terrible about announcing gear which isn't available for some
time. From: Brent Sweeny
Sent: 2/8/2013 16:41
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper MX2020 operational experience?
now that the MX2020 has been out for a few months, can anyone share
operational experience with it? how has it gone, after all? How does the
short- to medium-term future look for it and its smaller sister, the 2010?

thanks!
Brent Sweeny, Indiana University
___
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 labeled-unicast announces unusable routes,

[Phil Bedard]

 certainly this is a bug
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I see someone beat me to it but you can specifying inet.3. The docs on
this stuff are really poor but that is how you would want to do it so
you know known MPLS destinations are being advertised. Now if you want
to advertise non MPLS destinations as labeled unicast it does work as
well, nothing says it has to be MPLS switched on the advertising router.

Phil From: Jeff Wheeler
Sent: =E2=80=8E1/=E2=80=8E21/=E2=80=8E2013 6:05
To: Alex Arseniev
Cc: juniper-nsp
Subject: Re: [j-nsp] Junos labeled-unicast announces unusable routes,
certainly this is a bug
On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com wr=
ote:
 Probably not what you want to hear at the moment but it is working as
 designed.

No, it isn't.

Junos BGP is announcing routes it knows, for sure, are invalid.  It
knows that because BGP is making up a wrong label (2^20-1) because it
hasn't allocated one, and it can't announce the route without a label.
 This is an inexcusable bug that is very far from working as
designed.

The documentation is wrong, you cannot configure both AFI=3D1 SAFI=3D1 and
AFI=3D1 SAFI=3D4 on the same BGP session.  If it worked as documented, the
above behavior would not happen, and AFI=3D1 SAFI=3D1 would be available
to use for these routes.  That is not the case.

--
Jeff S Wheeler j...@inconcepts.biz
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] Traffic balancing over LSPs

[Phil Bedard]

Is it all one OSPF area or is the CMTS in an area other than 0? If the
MX480 is an ABR you can restrict the OSPF routes and originate them on
the MX480 as BGP instead using aggregate statements.

Phil From: James Ashton
Sent: 1/17/2013 11:07
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Traffic balancing over LSPs
I have an interesting situation that has me stumped for the moment.

I have an OSPF speaking device (ARRIS CMTS) hanging off from an EX Switch.
That switch is uplinked to an MX480 which is part of the network core.
It has several paths into it from rest of the network.
From several major traffic centers in the network I have 3 LSPs
created to the MX480.
I am running mpls traffic-engineering mpls-forwarding throughout the network.

As the end users hanging off the CMTS are advertised onto the network
via OSPF, and I cannot terminate LSPs on the CMTS, the traffic to
these users is not being forwarded over the LSPs.
I have tested enabling ospf traffic-engineering shortcuts but that
is breaking several paths in the network to legacy areas with odd
configs.

My question is basically, how can I get this traffic into these LSPs
in way that is more manageable at scale than a pile of static routes.


I hope the above is clear,  I am low on Caffeine at the moment.

Thank you in  advance for any help/ideas.

James
___
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] Traffic balancing over LSPs

[Phil Bedard]

This is the way we (and many others) run our core network, there are
very few IGP routes other than loopbacks and interface addresses. If
you need an example let me know but the main command is area-range
x.x.x.x/x restrict.

Phil From: James Ashton
Sent: 1/18/2013 10:13
To: Phil Bedard
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Traffic balancing over LSPs
Phil,
 Thanks, This is an interesting idea.  Not something I had though of.
Seams like a logical solution though.

Ill take a look at it.

Thanks
James

- Original Message -
From: Phil Bedard phil...@gmail.com
To: James Ashton ja...@gitflorida.com, juniper-nsp@puck.nether.net
Sent: Friday, January 18, 2013 8:49:21 AM
Subject: RE: [j-nsp] Traffic balancing over LSPs

Is it all one OSPF area or is the CMTS in an area other than 0? If the
MX480 is an ABR you can restrict the OSPF routes and originate them on
the MX480 as BGP instead using aggregate statements.

Phil From: James Ashton
Sent: 1/17/2013 11:07
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Traffic balancing over LSPs
I have an interesting situation that has me stumped for the moment.

I have an OSPF speaking device (ARRIS CMTS) hanging off from an EX Switch.
That switch is uplinked to an MX480 which is part of the network core.
It has several paths into it from rest of the network.
From several major traffic centers in the network I have 3 LSPs
created to the MX480.
I am running mpls traffic-engineering mpls-forwarding throughout the network.

As the end users hanging off the CMTS are advertised onto the network
via OSPF, and I cannot terminate LSPs on the CMTS, the traffic to
these users is not being forwarded over the LSPs.
I have tested enabling ospf traffic-engineering shortcuts but that
is breaking several paths in the network to legacy areas with odd
configs.

My question is basically, how can I get this traffic into these LSPs
in way that is more manageable at scale than a pile of static routes.


I hope the above is clear,  I am low on Caffeine at the moment.

Thank you in  advance for any help/ideas.

James
___
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] BGP PIC Edge on MX platforms

[Phil Bedard]

I agree it is not quite the same. The hierarchical FIB and next-hop
indirection so the number of prefixes is independent of the
reconvergence time has been in Junos for a long time. That is like the
PIC part.

Junos would rather you use BGP add-path for the ingress PE side to
support multiple egress PEs with faster protection.

I suppose you could also use add path for CE protection, or this
feature. I don't think the config guide is particularly good with
regards to this feature.

Phil From: Jesper Skriver
Sent: 1/1/2013 5:40
To: Phil Bedard
Cc: Robert Hass; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BGP PIC Edge on MX platforms
Disclaimer, I work for cisco and was involved in the idea, design and
implementation of BGP PIC Edge, though here I speak only for myself
and not my employer.

From the Example: Configuring MPLS Egress Protection for Layer 3
VPN Services of

http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/config-guide-vpns/config-guide-vpns.pdf

It looks like this is a very different thing than BGP PIC Edge, it
require manual configuration and designated PLRs.

None of that is required with BGP PIC Edge, which on a per prefix basis
will on the ingreess PEs automatically calculate the primary and repair
egress PE, and setup forwarding structures allowing Prefix Independent
(constant time) Convergence of all affected prefixes when the loopback
of the primary egress PE is withdrawn from the IGP.

Additionally BGP PIC Edge also provides Prefix Independent Convergence
in the case of a PE-CE link failure, or CE node failure, where the
egress PE will redirect traffic to an backup PE/CE, again the backup
PE/CE is automatically pre-calculated on a per prefix basis, so you can
have CE1 be the primary for say 10k prefixes, where CE2 is the backup
for 5k of them and CE3 for the remaining 5k.

Lastly, this all works for prefixes in a L3 VPN or in the global routing
table, as long as the IGP routes are labeled.

/Jesper

On Tue, Jan 01, 2013 at 12:04:15AM -0500, Phil Bedard wrote:
 11.4R3 I believe.  Juniper calls it MPLS Egress Protection for L3VPN

 Phil

 On Dec 31, 2012, at 7:34 PM, Robert Hass robh...@gmail.com wrote:

  Hi
  Is BGP PIC Edge functionality supported on current MX platforms ? (eg.
  JunOS 11.4R6 or 12.x)
 
  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

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP PIC Edge on MX platforms

[Phil Bedard]

11.4R3 I believe.  Juniper calls it MPLS Egress Protection for L3VPN

Phil

On Dec 31, 2012, at 7:34 PM, Robert Hass robh...@gmail.com wrote:

 Hi
 Is BGP PIC Edge functionality supported on current MX platforms ? (eg.
 JunOS 11.4R6 or 12.x)
 
 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] SRLGs in Inter-Area LSPs

[Phil Bedard]

Up until I believe Junos 11.4, Junos did not use the GMPLS IGP extensions
to distribute SRLG information.  All of the SRLG information was
statically configured via the routing-options-fate-sharing configuration.
 The entire database is generally configured on every node if you are
using link or link-node protection, but if you are using active/standby
LSPs you could get away with only confuring it on the head-end nodes.
However I think it is only consulted when computing the ERO to the ASBR,
not after it say received the RESV RRO, so it is probably not much help.

I don't think using the IGP method will work either, I doubt the ABR node
will take into account any SRLG information from the primary LSP path
since there is nothing which tells it the standby LSP is actually a
standby LSP, it doesn't contain the state of the first path to tell it to
compare the second path to.

The original plan to do inter-area RSVP LSPs with the ability to use
completely diverse paths was to add an exclude object to the Path setup
message along with the already defined include so each node along the
line would know which links were to be excluded.  I don't think that ever
made it into Junos though...

On another platform we use MS-PW for P2P L2VPN because it scaled much
higher than RSVP inter-area LSPs, and our very edge nodes did not support
LDPoRSVP or BGP-LU.  For redundancy it requires stitching the service at
potentially four total nodes but you can do 10s of thousands of those.

I would use the same method for multipoint and point-to-point, there is no
difference between the two except another endpoint.

Phil 

On 5/20/12 4:36 AM, Łukasz Dudziński luk...@dudzinscy.org wrote:

Hi,

I didn't know that option before. It seems, it can be very useful in
hierarchic networks. It's a pity that it is poor documented. But it
should be possible to use SRLG since ERO extension is calculated by the
ABR and the ABR has access to TED in both areas. Please, share your lab
results.

Lukasz

On 2012-05-20 08:10, Caillin Bathern wrote:
 Hi Lukasz,

 Thanks for your response.

 I agree that the TED is restricted to an ospf area for CSPF calculation
however using the expand-loose-hop option on the ABRs should enable a
cspf LSP to be set up to the remote area assuming that the ABRs are
loose hops.  The problem I am having is I am not yet sure if the CSPF
conditions (admin groups, SRLGs, etc) will be applied when that
loose-hop expansion (cspf calculation by the ABR to reach the next ABR)
is made by the ABR.

 BGP-LU and the use of NHS attribute for scaling beyond a single area
are definitely in play for multi-point VPNs however for any
point-to-point L2VPNs we feel it would be much easier to generate an
end-to-end dynamic LSP instead.

 I am hoping to try this in the lab soon but I was hoping for any
insight list members might have for this.

 Cheers,
 Caillin

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Lukasz
Dudzinski
 Sent: Sunday, 20 May 2012 7:22 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] SRLGs in Inter-Area LSPs

 Hi,

 I do not have an experience in multi-area MPLS techniques, so I'm not
able to help you too much in that matter. But I'm sure that typically
MPLS Traffic Engineering is restricted to single area of IGP protocol.
 If I understood your mail correctly you try to create a CSPF-based RSVP
LSP between different IGP areas, which is not possible just like that.
 That is because MPLS TE relies on IGP TE database, which (like the link
state database) is restricted to single IGP area. TE-DB is an extension
of link state DB. Such information like Admin Groups, SRLG membership or
BW reservation are stored in TE database. If size of your network force
you to use IGP hierarchy I suggest you to take a look on such things
like LDP-over-RSVP, Seamless MPLS or BGP Labelled Unicast.

 Lukasz


 On 2012-05-18 09:17, Caillin Bathern wrote:
 Hi All,



 I posted this to the J-Net forums but no luck.



 Just wondering if SRLGs are carried through between IGP areas, both
 for OSPF and for IS-IS?



 The scenario for this would be passing a cspf routed RSVP LSP from PE1
 in Area 1 through to PE2 in Area 2. We would maintain a secondary
 standby LSP path for this traffic with exclude-srlg enabled.

 Assuming that the primary path takes the IGP routed path PE1 - ABR1 -
 ABR3 - PE2 then the secondary path will take the path PE1 - ABR2 -
 where?

 If SRLGs are carried through by the IGP then then the path should go
 PE1
 - ABR2 - ABR4 - PE2, however if the SRLGs are not carried through then
 the IGP could in make the secondary path PE1 - ABR2 - ABR3 - PE2 which
 obviously is not a great standby secondary path...



   /--- ABR1 ---| |--- ABR3 ---\

 PE1 (Area1) | Area 0 | (Area2) PE2

   \--- ABR2 ---| |--- ABR4 ---/





 If anybody knows this scenario and can shed some insight it would be
 greatly appreciated.

 Cheers,

 Caillin

Re: [j-nsp] redistributing label between rsvp and ldp

[Phil Bedard]

I'm not aware of a feature to stitch together an LDP LSP to an RSVP LSP
on a mid-point node, to the best of my knowledge.  The P nodes switch
traffic based on the ingress label, when the RSVP tail end node pops the
last label allocated for the RSVP LSP it will expect whatever traffic it
is carrying to terminate locally.   If you are using a feature like
LDPoRSVP the RSVP LSP acts as a virtual interface so to speak which
participates in LDP so it knows where to send the traffic based on the
second LDP label after popping the RSVP label.   Your best bet is to use
RFC3107 labeled BGP but to make that work you'll have to use BGP between
the boundary P nodes and the PE routers.   Each PE will learn the address
for the other PE via labeled BGP with the next-hop set to the boundary
node and then each segment will use RSVP or LDP respectively to get
between the boundary nodes to the PE and vice versa.

There are features, at least with some vendors, to stitch together BGP to
LDP and vice versa since nodes like PE1/PE2 may not support labeled BGP,
but the boundary router doing the stitching needs to keep track of that.

Easier to just run one protocol. :)

Phil  

On 4/29/12 2:52 AM, Uzi Be go...@live.com wrote:


hi -
yeah p3 and p4 support both ldp and rsvp, but pe1 can only run rsvp and
pe 2 can only run ldp.

ce - pe1 - p1 - p2 - p3 -p4 -pe2 - ce
thanks
Andrew

 Date: Sun, 29 Apr 2012 13:04:06 +0800
 Subject: Re: [j-nsp] redistributing label between rsvp and ldp
 From: diogo.montag...@gmail.com
 To: go...@live.com
 
 Does p3 and p4 support both LDP and RSVP ?
 
 ./diogo -montagner
 JNCIE-M 0x41A
 
 
 On Sun, Apr 29, 2012 at 12:45 PM, Uzi Be go...@live.com wrote:
 
  hi,
  I was just testing out to swap labels between two different signaling
protocols (ldp and rsvp). lets say we have two different network, one is
running ldp and the other one is running rsvp (same AS, so no inter-as
options).
  ce - pe1 - p1 - p2 - p3 -p4 -pe2 - ce
  so pe1 - p1 - p2 -p3 are running rsvp and p4-pe2 are running ldp, and
edge ce's are using l3vpn. what are the options to have a labeled path
from pe2 to pe1 (considering that pe1 is not going to run ldp protocol,
and pe2 can't use rsvp so ldp tunneling is not an option here).
  thanks in advance for your comments.
  Andrew
  ___
  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] mx240 vs asr 9006

[Phil Bedard]

Yes thanks for mentioning that.  

My opinion would be to use a MX480 like someone else said just due to the 
increased slot capacity, over the 9006 or 240. 

Phil

On Apr 25, 2012, at 9:33 AM, brad dreisbach br...@ntt.net wrote:

 On Tue, Apr 24, 2012 at 07:31:13PM -0400, Phil Bedard wrote:
 If you are using the newer RSP440 and newer linecards it is substantially 
 higher, 2M+ IPv4.  But you are right the first gen cards the original poster 
 had speced only support 512K in the FIB and we are at 400K+ now in the 
 Internet table.
 
 You can configure the scale profile on the trident based cards to support 1M
 routes on RSP2.  you do sacrifice some L2 scale though, iirc.
 
 default —efficient for deployments that require large Layer 2 MAC tables (up 
 to 512,000 entries) and a relatively small number of Layer 3 routes (less 
 than 512,000).
 
 l3 —efficient for deployments that require more Layer 3 routes (up to 1 
 million) and smaller Layer 2 MAC tables (less than 128,000 entries).
 
 l3xl —efficient for deployments that require a very large number of Layer 3 
 routes (up to 1.3 million) and minimal Layer 2 functionality. Note that the 
 support for up to 1.3 million routes is split into IPv4 scaled support and 
 IPv4/IPV6 scaled support. You can configure up to 1.3 million IPv4 routes, or 
 up to 1 million IPv4 routes with 128,000 IPv6 routes. 
 http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/system_management/configuration/guide/b_sysman_cg42asr9k_chapter_01.html#task_3A082F6CD31D4A238070C3CD7279E67A
 
 -b
 
 
 Phil
 
 On Apr 24, 2012, at 12:41 PM, Doug Hanks a...@juniper.net wrote:
 
 The last time I looked the ASR9K still had a small FIB and tapped out at
 around 500K.
 
 Thank you,
 
 --
 Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
 Sr. Systems Engineer
 Juniper Networks
 
 
 On 4/24/12 8:55 AM, Peter piotr.1...@interia.pl wrote:
 
 Hi
 
 I have to upgrade my bgp routers, i have budget for two options:
 
 1.
 - bundle: MX240BASE-AC-HIGH, MPC1-3D-R-B, MIC-3D-20XGE-SFP,
 MIC-3D-2XGE-XFP; configurable RE, SCB, and PEM
 - better routing engine RE-S-1800X2-8G-UPG-BB + jflow license ( netflow
 v9 or ipfix) S-ACCT-JFLOW-IN
 
 or
 
 2. asr 9006
 - A9K-RSP-4G
 - A9K-MOD80-TR, 80G Modular Linecard, Packet Transport Optimized
 - license for l3 vpn
 
 the price is almost the same. I need:
 
 - ports: from  4x10G line to  max 8x10G, line rate
 - 3 virtual routers with full ip routing table v4
 - 10 virtual routers with ca 10k prefix in routing table v4
 - v6
 - up to 12 full bgp feed
 - netflow v9 or ipfix, sampling max 100/s
 - define counters on logical and physical interfaces, count many times
 to the same counter, one packet could be count to different counters in
 next term
 - access to counters via snmp
 - independent control plane and data plane
 - and few others things on bgp edge
 
 which model will be better ?
 thanks for some advice
 
 regards
 Peter
 
 ___
 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] mx240 vs asr 9006

[Phil Bedard]

If you are using the newer RSP440 and newer linecards it is substantially 
higher, 2M+ IPv4.  But you are right the first gen cards the original poster 
had speced only support 512K in the FIB and we are at 400K+ now in the Internet 
table.  

Phil

On Apr 24, 2012, at 12:41 PM, Doug Hanks a...@juniper.net wrote:

 The last time I looked the ASR9K still had a small FIB and tapped out at
 around 500K.
 
 Thank you,
 
 -- 
 Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
 Sr. Systems Engineer
 Juniper Networks
 
 
 On 4/24/12 8:55 AM, Peter piotr.1...@interia.pl wrote:
 
 Hi
 
 I have to upgrade my bgp routers, i have budget for two options:
 
 1.
 - bundle: MX240BASE-AC-HIGH, MPC1-3D-R-B, MIC-3D-20XGE-SFP,
 MIC-3D-2XGE-XFP; configurable RE, SCB, and PEM
 - better routing engine RE-S-1800X2-8G-UPG-BB + jflow license ( netflow
 v9 or ipfix) S-ACCT-JFLOW-IN
 
 or
 
 2. asr 9006
 - A9K-RSP-4G
 - A9K-MOD80-TR, 80G Modular Linecard, Packet Transport Optimized
 - license for l3 vpn
 
 the price is almost the same. I need:
 
 - ports: from  4x10G line to  max 8x10G, line rate
 - 3 virtual routers with full ip routing table v4
 - 10 virtual routers with ca 10k prefix in routing table v4
 - v6
 - up to 12 full bgp feed
 - netflow v9 or ipfix, sampling max 100/s
 - define counters on logical and physical interfaces, count many times
 to the same counter, one packet could be count to different counters in
 next term
 - access to counters via snmp
 - independent control plane and data plane
 - and few others things on bgp edge
 
 which model will be better ?
 thanks for some advice
 
 regards
 Peter
 
 ___
 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] Double-tagging on EX

[Phil Bedard]

Like others have said, it's not going to happen on any EX switch without
using loopback cables or another switch.  A somewhat cheap solution is to
get an Ethernet NID like an Accedian or Adva box which are pretty good at
VLAN manipulation, but it's another box to manage.

Phil 

On 2/22/12 7:20 AM, Alexander Frolkin a...@eldamar.org.uk wrote:

Hi,

We need to double-tag packets on an EX4200, i.e., untagged packets come
in on one interface, and packets with two VLAN tags come out of another
interface.  So far, everything we tried has failed.  Has anyone figured
out how to do this?

Juniper documentation is useless, as always.


Thanks!


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] anyone running VC with 2 * EX4500?

[Phil Bedard]

I did some lab testing with a 2xEX4500 VC using 10GE interfaces and it
worked fairly well once everything was setup.  For some reason I had some
issues getting things to correctly come up but after rebooting a couple
times everything was fine, even across reboots.  I only tested basic L2
and L3 functionality.  Upgrading the device still requires rebooting
everything.  Starting in 11.4 you can combine 10 EX4500s in a single
stack, but I know you are talking about two, and I don't know about
running 11.4 on them. :)

Phil 

On 2/21/12 5:38 AM, Alexander Bochmann a...@lists.gxis.de wrote:

Hi,

we've been putting off converting our EX4500s to a virtual
chassis for quite some time now. I've seen a few posts about
mixed EX4500/4200 setups, but none with several EX4500s.

Does anyone run something like that? Any special caveats,
and should we wait some more before trying it?

Thanks,

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] Internet routes in MPLS network, global table or own VRF?

[Phil Bedard]

We use RSVP exclusively in our business access and core networks due to markets 
wanting the 50ms protection for services like cell backhaul and CES.   The 
boxes we use are fairly small and cheap and handle RSVP fairly well (not C or J 
but A).  We do break up our access networks into multiple IGP areas and make 
use of MS-PW.  

Phil

On Jan 27, 2012, at 9:56 PM, Mark Tinka mti...@globaltransit.net wrote:

 On Saturday, January 28, 2012 07:59:36 AM Keegan Holley 
 wrote:
 
 Makes sense.  I'm still straddling the line between large
 enterprise and small service provider so I haven't felt
 the resource bite from RSVP everywhere.  Interesting to
 hear that perspective though.  I've seen RSVP work in a
 T-series/CRS based large network though so I guess
 platform choice ($$) and design play a role as well.
 
 Running RSVP in the core is fairly common because there are 
 fewer boxes to deal with, and the aggregation and edge parts 
 of the network can simply run LDP, tunneling that inside an 
 RSVP-based core as needed.
 
 But in some cases (such as BGP-MVPN or end-to-end strict 
 paths), one may need to run RSVP edge to edge, edge to 
 aggregation, edge to core, e.t.c. This isn't always 
 desirable, particularly if you want to make it avaialble as 
 a blanket feature for customers that aren't going to pay 
 additional for it (and why should they, it might not 
 necessarily be adding any real value to them).
 
 In our access, we have a number of ME3600X Ethernet 
 switches. These are pretty powerful devices, but I'd also 
 shudder as to how much RSVP state they can maintain as the 
 network expands.
 
 Besides, as I mentioned before, we like the MPLS topology to 
 follow the IP topology, and LDP does this quite nicely. But 
 if absolutely unavoidable, we will deploy RSVP.
 
 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] Internet routes in MPLS network, global table or own VRF?

[Phil Bedard]

On Jan 26, 2012, at 4:01 PM, Keegan Holley keegan.hol...@sungard.com wrote:

 2012/1/26 Pavel Lunin plu...@senetsy.ru:
 
 
 
 why would FRR LSP's take a route different than what the IGP would
 converge to.
 
 
 Because FRR uses a path from a different entry (PLP) to probably a different
 exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated)
 is a path from head-end to tail-end. Whether this happens often or rare, the
 need to care how your detours are calculated is itself a big enough
 headache.
 
 That's not how FRR works at least for RSVP.  It pretty much just
 re-runs cspf with something removed.  So it's the same route your IGP
 would choose if said thing went dark.  I don't have many obscure
 paths where I wouldn't want traffic to go so I can't really comment on
 your earlier idea.  That being said I've never seen FRR choose a path
 worse than the path the IGP would choose.  It's just preselects that
 path and pre-signals it.  I'm sure there are failure scenarios though.
 
 
 
 What the VRF-based Internet users will definitely notice is (looks like
 RAS
 is tired of telling this story) is ICMP tunneling and consequent hard to
 interpret delay values. People are very suspicious to the numbers. This
 is
 almost impossible to explain, that the numbers, traceroute shows, have
 nothing to do with their kitty-photos-not-loading problem.
 
 Hey kitty photos are serious business especially if you are facebook
 stalking the aforementioned kitty.
 
 
 Absolutely. This is why in case of issues you should not waste time for
 explaining why your core router is 200ms away from the previous hop.
 
 ___
 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] Internet routes in MPLS network, global table or own VRF?

[Phil Bedard]

I think Pavel is speaking of the case where the PLR is more than one hop from 
the ingress node.  It is very topology dependent but you can end up with 
bypasses or detours taking a different path than the IGP especially when its a 
few hops from the ingress node.   Also ring topologies introduce wrapping which 
can add congestion in the opposite direction.  Partial mesh alleviates some of 
that but most networks have some kind of ring element somewhere.  

Phil

On Jan 26, 2012, at 4:01 PM, Keegan Holley keegan.hol...@sungard.com wrote:

 2012/1/26 Pavel Lunin plu...@senetsy.ru:
 
 
 
 why would FRR LSP's take a route different than what the IGP would
 converge to.
 
 
 Because FRR uses a path from a different entry (PLP) to probably a different
 exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated)
 is a path from head-end to tail-end. Whether this happens often or rare, the
 need to care how your detours are calculated is itself a big enough
 headache.
 
 That's not how FRR works at least for RSVP.  It pretty much just
 re-runs cspf with something removed.  So it's the same route your IGP
 would choose if said thing went dark.  I don't have many obscure
 paths where I wouldn't want traffic to go so I can't really comment on
 your earlier idea.  That being said I've never seen FRR choose a path
 worse than the path the IGP would choose.  It's just preselects that
 path and pre-signals it.  I'm sure there are failure scenarios though.
 
 
 
 What the VRF-based Internet users will definitely notice is (looks like
 RAS
 is tired of telling this story) is ICMP tunneling and consequent hard to
 interpret delay values. People are very suspicious to the numbers. This
 is
 almost impossible to explain, that the numbers, traceroute shows, have
 nothing to do with their kitty-photos-not-loading problem.
 
 Hey kitty photos are serious business especially if you are facebook
 stalking the aforementioned kitty.
 
 
 Absolutely. This is why in case of issues you should not waste time for
 explaining why your core router is 200ms away from the previous hop.
 
 ___
 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] MPLS fast convergence without link information

[Phil Bedard]

I know they are somewhat expensive but we use test tools from Spirent
(TestCenter) or Ixia (N2X, etc) which can measure reconvergence times down
to the microsecond.

Phil 

On 1/2/12 3:47 AM, Mark Smith gggla...@gmail.com wrote:

Hi

Thanks for help everybody.

One further question: do you have recommendations of tools to perform
network convergence testing? I.e. generally available sw that is
capable of measuring network outage times in the order of magnitude of
milliseconds?

I have traditionally used linux and fping, something like fping -l -p
10 -i 10 -t 10 to get the low-precision measurement of outage in 10
milliseconds. Does this make sense to you?


On Thu, Dec 29, 2011 at 9:36 PM, Phil Mayers p.may...@imperial.ac.uk
wrote:
 On 12/29/2011 06:48 PM, Mark Smith wrote:

 I would not expect the L2 service provider to be able to tunnel
 ethernet OAM (CCM etc) traffic.


 In general, or in this specific case?

In general at this point. By building your stuff on the assumption
that your subcontractor or partner is able to do something
specific not mentioned in contract you increase the risk of extra
problems and/or work in case something goes wrong or changes.

For example let's assume you lease L2 lines and notice that OAM
traffic is passed fine. You test and build your network to rely on
this functionality. After some time your L2 provider experiences
hardware failure and they decide to replace the failed component with
different model, config, sw version etc. As a result OAM traffic is
not forwarded anymore and you need to do changes to your
configuration. The provider does not tell you anything, because your
service (L2 line) is restored.

Another example might be that you need to change L2 provider to
different one and again they don't forward OAM.

I have seen things like this happen on several occasions and I would
like to avoid them if possible. Also remember the murphy's law: if
(and when) anything goes wrong, it will happen on the worst possible
moment. I.e. in the middle of midsummer night when you (and your
capable colleagues) are 5 ‰ drunk ;/

___
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] Whitebox 10Gb/s capture challenge

[Phil Bedard]

How much traffic is actually on the boxes?  A full 10G or some fraction?  Are 
they in the same datacenter?  There are muxing boxes from onpath,apcon, anue, 
net optics, etc.  which might let you get away with less actual capture 
devices.  Keep in mind some of those solutions are fairly expensive 
themselves... 

Phil

On Jan 9, 2012,s  at 11:05 AM, OBrien, Will obri...@missouri.edu wrote:

 I'm pondering the idea of trying to build a relatively inexpensive 10Gb 
 capture box.
 The simple solution is a dell R710 with 10Gb nics. I have some, they work, 
 but I'd have to spend $50k to get enough of them.
 
 So, my challenge is keeping the price point is something around $1000-$1500 - 
 basically the 10Gb version of a 1u gigE capture system.
 
 In general, I probably don't need to ever write 10Gb/s to disk, but it would 
 be nice load the dice for success.
 My thoughts are a reasonable performance motherboard with 10Gb PCIe nics or a 
 white box mobo with onboard SFP+ ports.
 
 Anyone gone this route?
 
 
 Will O'Brien
 University of Missouri, DoIT DNPS
 Network Systems Analyst - Redacted
 
 obri...@missouri.edu
 
 
 
 
 ___
 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] MPLS fast convergence without link information

[Phil Bedard]

BFD on the IGP session would be the best option.  We currently run ours at 
300x3 on Juniper boxes and lower on some other platforms with better hardware 
processing of BFD packets.   If you are using aggregates something like 802.3ah 
may work better as BFD control traffic has a tendency to just take a single 
link on Junipers.  It is honor miss though whether L2 circuit provider can 
tunnel that traffic. 

Phil

On Dec 29, 2011, at 2:49 AM, Mark Smith  gggla...@gmail.com wrote:

 Hi list
 
 Let's examine an MPLS network where the connections between MPLS
 routers (P and PE) involve L2 devices. The connections might be leased
 L2 pseudowires or something similar. As a consequence the interface
 link state information cannot be used by routers to determine the
 state of the connection or neighboring router. For example consider
 routers A and B. If the connection between them is down, both still
 see interface (fiber or copper) link up. Similarly in case of failure
 of router A, B still sees interface link up. For the sake of
 simplicity, let's assume all routers are Juniper (e.g. MX series),
 IS-IS is used as IGP and RSVP(-TE) as the MPLS signaling protocol.
 
 We would like to achieve the fastest convergence times safely available.
 
 What is the current best practise to accomplish this and what order of
 magnitude are the convergence times?
 
 I have spent some time searching for a solution. I have found these:
 1) enable BFD on the IGP session
 2) enable BFD on the LSPs
 3) enable BFD on the RSVP session
 
 Which one of them (if any) is the best solution?
 
 I also read that BFD might cause IGP to reconverge instead of
 switching the traffic to bypass LSP (when using link-node protection).
 
 Any help and pointers to good material is greatly appreciated.
 
 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] IP/MPLS fast convergence

[Phil Bedard]

LFA relies on the topology to be one in which a failure won't cause a traffic 
to head back the other direction.  So topologies such as rings are not good 
because an adjacent node may send traffic back to a node with an upstream 
failure creating a microloop.  The router will not create a protection path in 
that scenario just use regular convergence. LFA works well in triangle or hub 
and spoke topologies.  You have to be careful with setting metrics as well. 

There has been some work on newer algorithms and ways to notify adjacent nodes 
either inband or out of band of a failure to ensure 100% coverage.   Today I do 
not think any vendor has implemented those features. 

As for the design it really depends on the SLA.  If you do not need 50ms 
Traffic restoration LDP should work fine.  On a metro network IGP convergence 
is pretty fast these days probably less than 500ms. 

Phil

On Dec 21, 2011, at 3:23 PM, Amos Rosenboim a...@oasis-techs.net wrote:

 Hello Serge,
 
 Thanks for sharing your insights, it's valuable.
 Can you explain why only some of the paths are protected ?
 
 Regards,
 
 Amos
 
 Sent from my iPhone
 
 On 21 Dec 2011, at 21:47, Serge Vautour 
 sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca wrote:
 
 Hello,
 
 We did started a greenfield deployment 2 years ago. We had no requirement for 
 FRR and stayed clear of RSVP. We did implement LDP + OSPF LFA since it was 
 just an extra knob and gave us something for free. We used Link Protection.
 
 
 The caveat with LFA is that it will not protect 100% of your paths. A given 
 link failure may re-route some of your traffic via LFA while the rest has to 
 wait for standard OSPF convergence. WANDL did some LFA coverage analysis for 
 us and if I remember correctly based on our topology we have ~70% of paths 
 covered.
 
 
 I ran some tests on our Prod network before it went live. LFA did in fact 
 allow sub-50ms convergence. For paths that weren't covered by LFA in a worst 
 case scenario, I got about 300ms. Not too bad. Junos seems really fast at 
 converging even without LFA. We use MX960s and MX80s.
 
 I hope this helps.
 
 Serge
 
 
 
 
 From: Amos Rosenboim a...@oasis-tech.netmailto:a...@oasis-tech.net
 To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
 Sent: Wednesday, December 21, 2011 2:34:22 PM
 Subject: [j-nsp] IP/MPLS fast convergence
 
 Hello All,
 
 I'm planning a greenfield IP/MPLS network for a mobile operator.
 The requirements are to support MPLS services (mainly L3 VPNs but also some 
 VPLS), enforce  strict but fairly simple CoS model, and support fast 
 convergence.
 No requirement for CSPF based TE.
 
 Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just 
 for the sake of FRR, and tunnel LDP inside these LSPs.
 This way I would get FRR without the burden of full mesh RSVP LSPs.
 
 However in the last two years I read more and more about LFA, IP/LDP FRR and 
 similar technologies.
 
 I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if 
 anyone is actually using this in the field, if so what is the impression.
 
 Regards
 
 Amos
 
 
 ___
 juniper-nsp mailing list 
 juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 ___
 juniper-nsp mailing list 
 juniper-nsp@puck.nether.netmailto: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] vpls loop avoidance

[Phil Bedard]

Coming soon to at least one platform, but haven't heard anything about
Juniper.  The active/standby mechanisms work pretty well but active/active
using something like SPBM or TRILL would be nicer.

Phil 

On 10/12/11 6:36 PM, Robert J. Huey rh...@anzus.com wrote:


Wouldn't it be nice if we had an option to turn on SPB or TRILL inside
the VPLS service? 

rgds,
 --r


On Oct 12, 2011, at 8:05 AM, Chuck Anderson wrote:

 On Tue, Oct 11, 2011 at 04:14:53PM -0400, Keegan Holley wrote:
 STP doesn't seem to work here.  Only cisco PVST which doesn't help me
on an
 EX4200.
 
 PVST+ is supported on EX4200.
 
 edit protocols vstp
 ___
 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] vpls loop avoidance

[Phil Bedard]

Standards-based STP BPDUs are sent untagged, which might be an issue if
the links to your CE switches are tagged only.  Cisco PVST+ sends the
BPDUs with a VLAN tag.


I remember seeing some blurb about not connecting two CE devices to each
other if they are connected to two different PEs with the same site-id.
Is this one switch or two?


Phil 

On 10/11/11 4:14 PM, Keegan Holley keegan.hol...@sungard.com wrote:

2011/10/11 Humair Ali humair.s@gmail.com

 Hi Keegan

 As far as I know , in VPLS, it uses split horizon as loop avoidance
 mechanism , and  you should not see any loop occurring in a VPLS
 setup,(pending the rest of config is correct)


Yes it is BGP signaled so that will solve the loops on the core facing
interfaces.



 The only way you could have a loop in VPLS is when you start having
your CE
 dual homed , where in that case you need to either configure STP , or
you
 could use the primary/backup knob to define which PE is the primary and
 which is the back up.


STP doesn't seem to work here.  Only cisco PVST which doesn't help me on
an
EX4200.  Primary/backup has to do with multihoming which works as well.
I'd
like to know why this works when the site-id's are the same and why the
l2forwarding instance doesn't work.  I'm also curious why cisco pvst works
and none of the standards based protocols.




 On 11 October 2011 20:19, Keegan Holley keegan.hol...@sungard.com
wrote:

 I'm trying to get my handle on vpls loop avoidance and I can't remember
 the
 default behavior regarding site-id's and node-id's.  I remember reading
 about it in one config guide or another but I can't seem to find it
now.
 I'm trying to remember if broadcast, multicast and unknown unicast is
 flooded between PE router interfaces with the same site id's and maybe
 just
 some general guidelines on their behavior.  I'm trying to understand
best
 practices for loop avoidance.  It seems to loop with any standards
based
 STP
 protocol if two or more interfaces are connected to routers configured
 with
 the same site-id.  The behavior I see seems to be the opposite of what
the
 website says.


 
http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-confi
guring-ethernet-switch-as-the-ce-device.html
  ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




 --
 Humair


___
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] Bypass LSP functionality question

[Phil Bedard]

That's not correct.  You should take a look at RFC4090.  A Patherr message
is sent to the head-end node with a flag set to notify it local protection
is in use.  There are also flags in the RESV RRO to notify the head-end
local protection is in use.  The head-end node is smart enough to keep
using the path until it can reserve a new path and do a MBB operation.

Facility bypass wouldn't be very useful if it only protected traffic for a
few ms...:) 

Phil 

On 7/6/11 11:50 AM, David Ball davidtb...@gmail.com wrote:

  Just looking for confirmation of a suspicion here.

  If I have an LSP configured with link-protection on every interface
along the way (creating many-to-one Bypass LSPs, as opposed to 1:1
detours), no secondary standby path defined, and a protected interface
fails, the ingress node will have no ability to perform a
make-before-break, right?  Because the Path Tear messages will be sent
both upstream and downstream from the failed interface?  The bypass
will only help me up until the upstream nodes process the Path Tears
and a new LSP is signalled from the ingress nodeor am I missing
something?

  More familiar with detours, so just checking myself wrt bypasses

Cheers,

David
___
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] [c-nsp] P2MP LSPs :: TailEnd/Bud nodes behavior

[Phil Bedard]

I'm not sure about the MX80 but on the MX960 with a DPC you can dedicate a
PFE on one of the DPCs to be used for tunnel services, but you lose the
Ethernet interfaces.  I believe on the newer MPCs you can do the same and
not lose the Ethernet interfaces.  Not sure about support on the MX80
though you'd have to check with Juniper.

Phil 

On 3/1/11 2:50 AM, Egor Zimin les...@gmail.com wrote:

In my case I have a deal with MX80

2011/3/1 Phil Bedard phil...@gmail.com:
 In the Juniper case you can get around the double replication on the M/T
 by using a tunnel services PIC and using a tunnel interface to terminate
 the P2MP LSP.   Just a limitation of the platforms.

 Phil

 On 2/28/11 10:44 AM, Egor Zimin les...@gmail.com wrote:

Hello, guys

Today I noticed very interesting difference in implementation of P2MP
LSPs by Cisco and Juniper.
The difference is related to explicit/implicit-null behavior of S2L
Sub-LSP tailend routers:
Cisco implementation:
(http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_p2mp
_p
s6922_TSD_Products_Configuration_Guide_Chapter.html)
---
The tailend routers allocate unreserved labels, which are greater than
15 and do not include implicit or explicit null labels.
---

In Juniper's implementation tailend allocates implicit/explicit null
label as a usual.
As a consequence of this, (it looks like) we can have unnecessary
replication before Bud nodes.

For example:
Let's consider this configuration:
###
label-switched-path LSP-P2MP-16--19 {
to 10.245.87.19;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--18 {
to 10.245.87.18;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--15 {
to 10.245.87.15;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--17 {
to 10.245.87.17;
p2mp TREE1;
}
###
 show mpls lsp p2mp ingress
Ingress LSP: 1 sessions
P2MP name: TREE1, P2MP branch count: 4
To  FromState Rt P ActivePath   LSPname
10.245.87.1710.245.87.16Up 0 *
LSP-P2MP-16--17
10.245.87.1510.245.87.16Up 0 *
LSP-P2MP-16--15
10.245.87.1810.245.87.16Up 0 *
LSP-P2MP-16--18
10.245.87.1910.245.87.16Up 0 *
LSP-P2MP-16--19
Total 4 displayed, Up 4, Down 0
###
As you can see, there are four leaves. Three bottom leaves use the
same downstream interface:
###
 show rsvp session p2mp detail | match PATH sentto
  PATH sentto: 10.245.87.146 (xe-0/0/2.0) 4 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 3 pkts
###
 show rsvp session p2mp
Ingress RSVP: 18 sessions
P2MP name: TREE1, P2MP branch count: 4
To  FromState   Rt Style Labelin Labelout
LSPname
10.245.87.1710.245.87.16Up   0  1 SE   -3
LSP-P2MP-16--17
10.245.87.1510.245.87.16Up   0  1 SE   -3
LSP-P2MP-16--15
10.245.87.1810.245.87.16Up   0  1 SE   -   309200
LSP-P2MP-16--18
10.245.87.1910.245.87.16Up   0  1 SE   -   309200
LSP-P2MP-16--19
Total 4 displayed, Up 4, Down 0
###

As you can see, we have two different out labels (3 and 309200) for
the same P2MP LSP. Label 3 is allocated by node 10.245.87.15 because
of PHP.

Can anybody explain, what IETF speaks about this case ? Must tailend
routers allocate unreserved label or not ? I can't find any mention of
this case in RFCs (4875, 4461).

--
Best regards,
Egor Zimin
___
cisco-nsp mailing list  cisco-...@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/






-- 
Best regards,
Egor Zimin


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

Re: [j-nsp] [c-nsp] P2MP LSPs :: TailEnd/Bud nodes behavior

[Phil Bedard]

In the Juniper case you can get around the double replication on the M/T
by using a tunnel services PIC and using a tunnel interface to terminate
the P2MP LSP.   Just a limitation of the platforms.

Phil 

On 2/28/11 10:44 AM, Egor Zimin les...@gmail.com wrote:

Hello, guys

Today I noticed very interesting difference in implementation of P2MP
LSPs by Cisco and Juniper.
The difference is related to explicit/implicit-null behavior of S2L
Sub-LSP tailend routers:
Cisco implementation:
(http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_p2mp_p
s6922_TSD_Products_Configuration_Guide_Chapter.html)
---
The tailend routers allocate unreserved labels, which are greater than
15 and do not include implicit or explicit null labels.
---

In Juniper's implementation tailend allocates implicit/explicit null
label as a usual.
As a consequence of this, (it looks like) we can have unnecessary
replication before Bud nodes.

For example:
Let's consider this configuration:
###
label-switched-path LSP-P2MP-16--19 {
to 10.245.87.19;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--18 {
to 10.245.87.18;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--15 {
to 10.245.87.15;
p2mp TREE1;
}
label-switched-path LSP-P2MP-16--17 {
to 10.245.87.17;
p2mp TREE1;
}
###
 show mpls lsp p2mp ingress
Ingress LSP: 1 sessions
P2MP name: TREE1, P2MP branch count: 4
To  FromState Rt P ActivePath   LSPname
10.245.87.1710.245.87.16Up 0 *
LSP-P2MP-16--17
10.245.87.1510.245.87.16Up 0 *
LSP-P2MP-16--15
10.245.87.1810.245.87.16Up 0 *
LSP-P2MP-16--18
10.245.87.1910.245.87.16Up 0 *
LSP-P2MP-16--19
Total 4 displayed, Up 4, Down 0
###
As you can see, there are four leaves. Three bottom leaves use the
same downstream interface:
###
 show rsvp session p2mp detail | match PATH sentto
  PATH sentto: 10.245.87.146 (xe-0/0/2.0) 4 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 3 pkts
###
 show rsvp session p2mp
Ingress RSVP: 18 sessions
P2MP name: TREE1, P2MP branch count: 4
To  FromState   Rt Style Labelin Labelout LSPname
10.245.87.1710.245.87.16Up   0  1 SE   -3
LSP-P2MP-16--17
10.245.87.1510.245.87.16Up   0  1 SE   -3
LSP-P2MP-16--15
10.245.87.1810.245.87.16Up   0  1 SE   -   309200
LSP-P2MP-16--18
10.245.87.1910.245.87.16Up   0  1 SE   -   309200
LSP-P2MP-16--19
Total 4 displayed, Up 4, Down 0
###

As you can see, we have two different out labels (3 and 309200) for
the same P2MP LSP. Label 3 is allocated by node 10.245.87.15 because
of PHP.

Can anybody explain, what IETF speaks about this case ? Must tailend
routers allocate unreserved label or not ? I can't find any mention of
this case in RFCs (4875, 4461).

-- 
Best regards,
Egor Zimin
___
cisco-nsp mailing list  cisco-...@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


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

Re: [j-nsp] Optimal BFD settings for BGP-signaled VPLS?

[Phil Bedard]

Oops I meant forwarding plane in my original post.   In some of the older
hardware where it's a centralized function and not independent of the
control plane, it helps catch those failures as well.   I believe this
covers most Juniper hardware, unless I'm mistaken.

Phil 

From:  Keegan Holley keegan.hol...@sungard.com
Date:  Mon, 17 Jan 2011 15:22:01 -0500
To:  Thedin Guruge the...@gmail.com
Cc:  Phil Bedard phil...@gmail.com, juniper-nsp@puck.nether.net, Clarke
Morledge chm...@wm.edu
Subject:  Re: [j-nsp] Optimal BFD settings for BGP-signaled VPLS?

I agree except for using the IGP and RSVP for failure detection.  RSVP and
OSPF/ISIS run in the control plane and BFD is designed to run in the
forwarding plane.  Running BFD will diagnose issues where the control plane
is working but the forwarding plane is not.

On Mon, Jan 17, 2011 at 3:13 PM, Thedin Guruge the...@gmail.com wrote:
 Hi,
 
 What i gather is that you have LDP implemented in MPLS level and edge
 routers are dual homed with core routers, why not consider running LDP over
 RSVP, RSVP LSPs will only be per link LSPs between P-PE links. RSVP will
 provide sub second failure times and no need for a dirty full meshed RSVP
 setup. But of course this relies on fast link down detection at a physical
 level as well as by IGP. but you can opt out BFD with BGP.
 
 Thedin
 
 On Mon, Jan 17, 2011 at 4:34 AM, Phil Bedard phil...@gmail.com wrote:
 
  If BGP stability is the main goal, do not use BFD with your BGP sessions.
  Are you using site multi-homing with the connected CE devices or are they
  all single-homed?  I don't know your topology but there may be some
  instances where you would want to run BFD for BGP notification with
  multi-homing.
 
  What hardware are you using?  We are using 300x3 everywhere and while we
  have seen some isolated false positives, things have been relatively
  stable.
 
  Also, I would look at the types of failures you sustain on a regular
  basis.  BFD doesn't make restoration faster, it lets you catch issues
  which may not have otherwise been caught like control plane issues. If you
  do not have a history of that maybe BFD isn't really necessary and may
  cause more problems than it solves.  Link failures and most node failures
  (which cause links to go dark) trigger routing protocol events much faster
  than BFD.  We use it because the routers were keeping the physical links
  up during a reboot and would eventually start dropping traffic.
 
  Phil
 
  On 1/14/11 9:39 PM, Clarke Morledge chm...@wm.edu wrote:
 
  I am trying to determine the optimal Bidirectional Forwarding Detection
  (BFD) settings for BGP auto-discovery and layer-2 signaling in a VPLS
  application.
  
  To simplify things, assume I am running LDP for building dynamic-only
  LSPs, as opposed to RSVP.  Assume I am running IS-IS as the IGP with BFD
  enabled on that, too, interconnecting all of the P and PE routers in the
  MPLS cloud.  I am following the Juniper recommendation of 300 ms mininum
  interval with 3 misses before calling a BFD down event.
  
  The network design has a small set of core routers, each one of these
  routers serves as a BGP route reflector.  All of the core routers have
  inter-meshed connections.  Each core router is only one hop away from the
  other.
  
  On the periphery, I have perhaps dozens of distribution routers.  Each
  distribution router is  directly connected to two or more core routers.
  Each distribution router has a BGP session to these core routers;
  therefore, each distribution router is connected to two route reflectors
  for redundancy.
  
  Given that above, what type of minimum interval BFD setting and miss
  count
  would you configure?  I want to try to get to a sub-second convergence
  during node/link failure, but I do not want to tune BFD too tight and
  potentially introduce unecessary flapping.  I am willing to suffer some
  sporadic loss to the layer-2 connectivity within the VPLS cloud in the
  event of a catastrophe, etc, for a few seconds, but I don't want to
  unnecessarily tear down BGP sessions and wait some 20 to 60 seconds or so
  until BGP rebuilds and redistributes L2 information.
  
  For some time now, I have been playing with 3000 ms interval with 3
  misses
  (that's 9 seconds) as what I thought was a conservative estimate.
  However, I have run into cases where there has been enough router churn
  for various reasons to uneccesarily trip a BFD down event.  My hunch is
  that this router churn is due to buggy JUNOS code, but I don't have
  proof of that yet.  Nevertheless, I want the BGP infrastructure to stay
  solid and ride through transient events in a redundant network.
  
  Are there any factors that I am missing or not thinking thoroughly enough
  about when considering optimal BFD settings?
  
  Thanks.
  
  Clarke Morledge
  College of William and Mary
  Information Technology - Network Engineering
  Jones Hall (Room 18)
  Williamsburg VA 23187

Re: [j-nsp] Optimal BFD settings for BGP-signaled VPLS?

[Phil Bedard]

If BGP stability is the main goal, do not use BFD with your BGP sessions.
Are you using site multi-homing with the connected CE devices or are they
all single-homed?  I don't know your topology but there may be some
instances where you would want to run BFD for BGP notification with
multi-homing.   

What hardware are you using?  We are using 300x3 everywhere and while we
have seen some isolated false positives, things have been relatively
stable.  

Also, I would look at the types of failures you sustain on a regular
basis.  BFD doesn't make restoration faster, it lets you catch issues
which may not have otherwise been caught like control plane issues. If you
do not have a history of that maybe BFD isn't really necessary and may
cause more problems than it solves.  Link failures and most node failures
(which cause links to go dark) trigger routing protocol events much faster
than BFD.  We use it because the routers were keeping the physical links
up during a reboot and would eventually start dropping traffic.

Phil 

On 1/14/11 9:39 PM, Clarke Morledge chm...@wm.edu wrote:

I am trying to determine the optimal Bidirectional Forwarding Detection
(BFD) settings for BGP auto-discovery and layer-2 signaling in a VPLS
application.

To simplify things, assume I am running LDP for building dynamic-only
LSPs, as opposed to RSVP.  Assume I am running IS-IS as the IGP with BFD
enabled on that, too, interconnecting all of the P and PE routers in the
MPLS cloud.  I am following the Juniper recommendation of 300 ms mininum
interval with 3 misses before calling a BFD down event.

The network design has a small set of core routers, each one of these
routers serves as a BGP route reflector.  All of the core routers have
inter-meshed connections.  Each core router is only one hop away from the
other.

On the periphery, I have perhaps dozens of distribution routers.  Each
distribution router is  directly connected to two or more core routers.
Each distribution router has a BGP session to these core routers;
therefore, each distribution router is connected to two route reflectors
for redundancy.

Given that above, what type of minimum interval BFD setting and miss
count 
would you configure?  I want to try to get to a sub-second convergence
during node/link failure, but I do not want to tune BFD too tight and
potentially introduce unecessary flapping.  I am willing to suffer some
sporadic loss to the layer-2 connectivity within the VPLS cloud in the
event of a catastrophe, etc, for a few seconds, but I don't want to
unnecessarily tear down BGP sessions and wait some 20 to 60 seconds or so
until BGP rebuilds and redistributes L2 information.

For some time now, I have been playing with 3000 ms interval with 3
misses 
(that's 9 seconds) as what I thought was a conservative estimate.
However, I have run into cases where there has been enough router churn
for various reasons to uneccesarily trip a BFD down event.  My hunch is
that this router churn is due to buggy JUNOS code, but I don't have
proof of that yet.  Nevertheless, I want the BGP infrastructure to stay
solid and ride through transient events in a redundant network.

Are there any factors that I am missing or not thinking thoroughly enough
about when considering optimal BFD settings?

Thanks.

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


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

Re: [j-nsp] MPLS in the Access

[Phil Bedard]

 PBB seems to be a cool modern acronym with a lot of buzz around, if someone
 has any more or less real experience with it, hey, how about to share your
 thoughts? :)
 
 Another approach can be a large VC ring of EX4200s built with VCE (ethernet)
 links:
 http://www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pdf
 
 Seems to be a reasonable solution when scale of up to 9 nodes in a single
 ring is OK. First EX4200 is known to be more or less stable (in my
 experience), second VCCP is actualy ISIS which is way more interesting than
 most ethernet scaling technologies rooted in LAN. As of my experience,
 Juniper's VC implementation is rather not bad. Moreover they even announced
 EX4500 to support virtual chassis some day, but this is too dreamy by now,
 and no one knows how good EX4500 will be.
 
 Actually I know some vendor producing small devices, which can do VPLS,
 Martini and L3VPN in 1-unit form factor with wire speed performance of 24GE
 with 10GE up-links for price at the level of 2xEX4200-24F. Even the vendor's
 reputation is not that bad. But since I have absolutely no experience with
 them yet and everything is too fuzzy, I'd prefer to follow the Mark's way
 and ask if someone can say something less abstract :)
 

We have over 1000 nodes deployed today in various metros using MPLS in the 
access and 
should have close to 2000 by the end of this year.   Our largest metro is about 
500 nodes today.
  
We are only doing CES and Ethernet services right now but may expand to L3VPN 
relatively 
soon.  

There are vendors who are shipping boxes today with 24x1GE and 2x10GE uplink, 
wire-rate, which 
can do VPLS and P2P Ethernet/CES, but no L3VPN.  However, you can connect into 
a L3VPN virtual 
routed interface via a P2P pseudowire.  The boxes are cheaper than EX4200s...  

In our network the access rings only contain P2P services and all multipoint 
services be it 
VPLS or L3VPN are hosted on larger agg nodes.  One limitation of these boxes is 
they can 
only push 2 labels so they only support 1:1 FRR and not facility backup.  They 
will have 
another box out by the end of the year with more advanced capability.  


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

Re: [j-nsp] JUNOS and MX Trio cards

[Phil Bedard]

When were you evaulating it?  I think both of those two features have been 
available for some time now, almost 2 years.  

Not to say they do not have their own set of issues along with Juniper and 
Cisco... 

Phil 


On Jun 30, 2010, at 4:26 AM, Andrey Zarechansky wrote:

 On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote:
 
 [dd]
 
 
 How unfortunate.  I wonder of Alca-Lu can do better.  Lord knows Cisco could 
 care less  about code quality.  surely some networking vendor must give a 
 sh*t.
 
 Small brief from our ALU equipment evaluation:
 BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward
 traffic for detached neighbour for 30 min
 
 Do you still wonder they can do better?
 
 -- 
 ZA-RIPE||ZA1-UANIC
 ___
 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] l2circuit communities

[Phil Bedard]

A little different scenario but I'm using CBF with a cos next-hop-map to set 
specific lsp-next-hops for CoS classes, also using autobw, and I'm not seeing 
similar behavior.  

One thing I noticed is while the router is doing the MBB/re-signal the 
ActiveRoute value will drop to 0, but then it immediately goes back up to the 
prior value, so it makes you wonder what's going on behind the scenes.

I'm using 9.3R3.8, hope thing isn't something introduced later... 

Are your paths actually changing output interfaces/paths or is it just a BW 
re-signal? 

Phil 


On May 24, 2010, at 3:48 PM, Richard A Steenbergen wrote:

 On Mon, May 24, 2010 at 09:01:05PM +0800, Mark Tinka wrote:
 On Monday 24 May 2010 02:33:08 am Richard A Steenbergen 
 wrote:
 
 Oh and a word of warning before anybody runs out and
 tries this, doing this kind of forwarding-table policy
 to select specific LSPs seems to SIGNIFICANTLY increase
 cpu use, to the point of almost never being  100%:
 
 Might you know why?
 
 Looking at rtsockmon -t, there is a huge and constant flood of rpd route
 changes after applying the LSP mapping install-nexthop to the forwarding
 table policy. 
 
 I picked one prefix at random and followed its updates in rtsockmon with 
 and without the install-nexthop policy enabled. With install-nexthop 
 enabled, over the course of 5 hours this prefix saw route change 
 messages 107 times, like so:
 
 [00:00:35] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1048955 altfwdnhidx=0 filtidx=0
 [00:00:36] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1048955 altfwdnhidx=0 filtidx=0
 [00:10:27] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049583 altfwdnhidx=0 filtidx=0
 [00:10:28] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049583 altfwdnhidx=0 filtidx=0
 [00:11:18] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049828 altfwdnhidx=0 filtidx=0
 [00:11:19] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049828 altfwdnhidx=0 filtidx=0
 [00:40:05] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049079 altfwdnhidx=0 filtidx=0
 [00:40:06] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049079 altfwdnhidx=0 filtidx=0
 [00:40:52] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049799 altfwdnhidx=0 filtidx=0
 [00:40:52] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049799 altfwdnhidx=0 filtidx=0
 [00:40:53] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049799 altfwdnhidx=0 filtidx=0
 [00:50:03] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1048947 altfwdnhidx=0 filtidx=0
 [00:50:04] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1048947 altfwdnhidx=0 filtidx=0
 [00:59:59] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049204 altfwdnhidx=0 filtidx=0
 [01:00:00] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049204 altfwdnhidx=0 filtidx=0
 [01:00:48] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049306 altfwdnhidx=0 filtidx=0
 [01:00:49] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049306 altfwdnhidx=0 filtidx=0
 [01:09:51] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049482 altfwdnhidx=0 filtidx=0
 [01:09:51] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049482 altfwdnhidx=0 filtidx=0
 [01:10:43] rpd  Proute  change  inet 190.152.178.0 tid=0 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049720 altfwdnhidx=0 filtidx=0
 [01:10:44] rpd  Proute  change  inet 190.152.178.0 tid=5 plen=24 
 type=user flags=0x0 nh=indr nhflags=0x84 nhidx=1049720 altfwdnhidx=0 filtidx=0
 
 Without the install-nexthop policy enabled it never saw a single
 message. BGP for the route was also rock solid, nothing ever changed in
 the show route last updated timestamp, and there was no network churn
 at the time. Note the roughly 10 

Re: [j-nsp] Link aggregation and RSVP

[Phil Bedard]

On May 6, 2010, at 10:42 AM, Richard A Steenbergen wrote:
 
 
 One big problem with link agg is that Juniper has no way to adjust the
 RSVP bandwidth of a bundle based on the actual capacity, so for example
 if you have a 60G bundle and you lose a 10G member (or two) RSVP will
 continue trying to pump 60G into the bundle, with the expected Very Bad
 Things (tm) as a result. Of course, if you do lose a member during
 non-peak times the link-agg mechanisms do a much faster job of detecting
 and recovering from the issue than RSVP does, and you end up avoiding a 
 network-wide event with a lot of preemption and resignaling.


It always adjusts the link agg RSVP interface bandwidth based on up member 
links unless you have it set statically.  You do run into a problem however if 
you do not have aggressive session preemption turned on since the RSVP 
interface will actually go into negative bandwidth but the lowest reservable bw 
value OSPF can advertise is 0.  So the sessions on the agg stay on the agg.  
Aggressive preemption boots everything off in order of hold priority.  

Phil  



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

Re: [j-nsp] Loop-free Alternate Paths for IS-IS Routes

[Phil Bedard]

It's new enough you probably won't find too many people with deployment 
experience outside of lab work.   It's something I looked at recently for OSPF 
and I think it's worth lab testing.   It's definitely easier to just turn on 
OSPF/IS-IS/LDP and forget it than maintain RSVP LSPs.  

http://www.juniper.net/us/en/community/junos/live/091103/  is a presentation 
given by Juniper and may answer some of the questions you have. 

There are topologies where it may not be able to find backup paths where MPLS 
FRR can, I think that's the biggest drawback.  There are ways to mitigate that 
concern with some static configuration, but you can't just turn it on and have 
it immediately replace RSVP.Another potential large caveat is lack of SRLG 
information, if you have multiple WDM circuits riding the same fiber span.  

Phil 

On Jan 13, 2010, at 1:48 AM, Stefan Fouant wrote:

 I'm wondering if anyone here has had any experience configuring the
 loop-free alternate paths for IS-IS in JUNOS, as described in the following
 drafts:
 
 - Internet draft draft-ietf-rtgwg-ipfrr-spec-base-12.txt, Basic
 Specification for IP Fast-Reroute: Loop-free Alternates 
 - Internet draft draft-ietf-rtgwg-ipfrr-framework-06.txt, IP Fast Reroute
 Framework
 
 And covered in
 http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/jd0e
 44501.html#jd0e44501.
 
 I'm looking for general guidance towards implementation, and any caveats
 which might be experienced in a typical deployment.  It seems to me that
 using this, we can entirely get rid of Fast Reroute, or Link/Node protection
 within RSVP/MPLS, but perhaps my understanding is a bit off.
 
 I'm also curious what experiences others have had with regards to
 troubleshooting backup paths that might be established as a result of a
 given failure.
 
 Thanks in advance!
 
 Stefan Fouant, CISSP, JNCIE-M/T
 www.shortestpathfirst.net
 GPG Key ID: 0xB5E3803D
 
 
 
 ___
 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] Ethernet Preamble and FCS on EoMPLS

[Phil Bedard]

The FCS is part of the frame... RFC4720 specifies a FCS retention  
indicator TLV, but I don't think it's ever been adopted by a vendor.
Some saw the lack of transparency in delivering the FCS untouched as a  
security issue.  A valid original FCS on the remote end means the  
payload arrived unaltered through the transport network.


Phil


On Sep 25, 2009, at 3:11 PM, Richard A Steenbergen wrote:


On Fri, Sep 25, 2009 at 09:10:41AM -0300, Ruter Guike wrote:

Hi List.

Is Juniper able to include Ethernet preamble and FCS within the  
mpls

packet, on EoMPLS? Is it configurable?

AFAIK, these fields are removed, by default, before encapsulating...


Preamble and FCS are layer 1 overhead, they aren't part of the frame  
and
can't be transported across MPLS or anything else. Not that there  
would
be any point in doing so, they carry no information of value and  
will be

recreated on the other side when transmitted again.

--
Richard A Steenbergen r...@e-gerbil.net   http://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] Multi-Area OSPF network with TED/CSPF

[Phil Bedard]

Look up Inter-area LSPs in the Junos docs.  The short answer is you  
can do it but you need to specify the ABR routers as loose hops in the  
path.


Phil


On Mar 20, 2009, at 1:41 PM, Gomes, Joao (NSN - BR/Sao Paulo) wrote:


Hi,



Is it possible to use the TED to built TE-LSP's in a multi-area OSPF  
network?




I'm aware there will be one TED per OSPF area (as the Type 10 LSA  
has area-flooding scope).


Is it possible to set RSVP to run CSPF over multiple TED's?

What are the restrictions?



Thanks.

Best regards,

João Kluck















___
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] l2circuit or l2vpn

[Phil Bedard]

On Jan 8, 2009, at 4:14 PM, Christopher E. Brown wrote:


David Ball wrote:

 I've found better vendor interop using l2circuit, as someone else on
the list mentioned, and have had them working between JNPR, Foundry,
Cisco, and even lower-end MRV switches.  I find the configuration of
L2circuits simpler in JUNOS as well.  However, if better traffic eng
is what you need, the comments made by others in this thread are very
pertinent as well.
 If you're talking multipoint and using VPLS, BGP-signalled VPLS is
nice in JUNOS because of the autodiscovery, whereas LDP-signalled  
VPLS
requires that you visit every PE that a given VPLS customer touches  
if

you add 1 more site on a new PE (although vendors like Foundry are
adding some kind of autodiscovery to account for this I
think...perhaps Juniper will too).  Also, likely better vendor  
interop

here too, with LDP-signalled.
My $0.02
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



The fun question...


Is there a way to accept many l2circuits and switch traffic between  
them in a VPLS like fashion without burning many physical interfaces?



Example, 15 remotes running l2 circuits from a vlan subint on the  
remote to a central insert box here, that runs a switching  
instance between all the l2circuits within the group _without_ an  
actual physical interface on the central box to terminate each  
l2circuit.



Think poor mans VPLS, where many remotes are available, but only  
support EoMPLS/l2circuit and not true VPLS.






If the aggregation side supports LDP-based VPLS the end node doesn't  
necessarily need to know it's VPLS.  I know vendor A supports doing  
this on their larger agg side devices that support VPLS.  They use an  
internal connector mechanism to tie an Eth PW service into a VPLS  
service.  This allows multipoint connectivity for the spokes, where  
MAC learning is done on the hub and the spokes just blindly send  
traffic out.   You might be able to do something similar with Vendor C  
and the more advanced linecards, since they support connecting a  
virtual switch interface to a remote site via EoMPLS.  Not sure if you  
can connect that to multiple sites though.  The same thing may be  
doable on the MX960 but I've only seen mention of tying a VPLS  
instance to a bridge-domain, not a l2circuit.


Otherwise you are stuck doing the cable out and back in type of trick,  
which should work on the MX960, would probably only require two ports,  
given the ability for the device to bridge vlans together or rewrite  
vlan-ids.


Phil


Phil







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

Re: [j-nsp] Using lo0 address as source in VRRP announcements

[Phil Bedard]

I believe you can set the interface address and the virtual address to  
the same IP on one side.  The router can't source VRRP messages from a  
loopback as source mac of those messages is what's used to tell  
downstream switches who the current master is.


Phil


On Nov 17, 2008, at 10:59 AM, Tore Anderson wrote:


Hi,

I am considering starting using two EX 4200 VCs as the access  
routers on

a bunch of server VLANs in my data centre, replacing a pair of
home-brewn Linux software routers with Keepalived (a VRRP
implementation).

I've come up with the following configuration for VRRP (similar on the
other switch, only using 87.238.63.3/28 instead):

[edit interfaces ge-1/0/0 unit 0 family inet]
[EMAIL PROTECTED] show
address 87.238.63.2/28 {
   vrrp-group 0 {
   virtual-address 87.238.63.1;
   }
}

Now, the bad thing here is that JUNOS apparantly demands that I add a
static address to the interface (87.238.63.2/28), and that I cannot  
add

a netmask to the virtual IP itself (it inherits the mask from the
static address instead).  This means that every network segment  
running

VRRP needs (at least) three addresses is consumed for the virtual
router:  one static per physical router, and one virtual address.

That seems rather wasteful in these days when IP(v4) addresses are
scarce.  With the Linux/Keepalived solution I could simply tell it to
use the loopback address as the source of the VRRP announcements, so
that I only had to reserve one IP address per network segment (the
virtual address, that is).

JUNOS won't let itself be fooled by me using a private address for the
static addresses either, e.g.:

address 169.254.63.2/28 {
   vrrp-group 0 {
   virtual-address 87.238.63.1;
   }
}

...results in the following error during commit:

 'vrrp-group 0'
   virtual address must share same mask with interface ip
error: configuration check-out failed

Not all of my server VLANs have two extra unused addresses, so this  
is a

showstopper for my plans to get rid of the Linux boxes.  Is there any
other way round this apparant JUNOS limitation, I wonder?

Best regards,
--
Tore Anderson
___
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] Why should I *not* buy an MX?

[Phil Bedard]

The only things I don't like as much about the MX is the various  
flavors of DPCs they offer depending on what your application might be  
(queueing options), having to keep track of limitations on certain  
cards (like Cisco), and licensing of certain features.   We've been  
testing the MX960 and have them deployed in a few sites today, and  
they are as solid as the M/T series.   We've tested pretty much  
everything you've listed there with the box in both a core/agg role  
and found no real flaws that weren't software related, meaning they  
affected the M/T as well.


It's a great platform.  It still doesn't compete with the 7600 on  
price for most of the market, considering there are tons of people out  
there that don't need the more expensive ESxx 7600 cards, but for  
those that are looking at 7600 w/ES20/ES40 vs. MX series, I'd take the  
MX.


Phil


On Nov 7, 2008, at 10:57 AM, [EMAIL PROTECTED] wrote:


We've been using Juniper M/T series in service provider scenarios for
a couple of years now, and really like them.  As part of an equipment
life cycle refresh, we're considering replacing our core (campus
enterprise) network with something in the MX series; a la this post:

http://marc.info/?l=juniper-nspm=122008030004203w=1

We are very glass is half empty on our evals; while it seems most
are pretty happy with the MX boxen, I'm trying to find something
show-stopper that would make us go with another product.  We're
wanting basically a campus Ethernet version of an M/T box and all that
that implies (besides just shoveling packets at a non-blocking line
rate, we'd like full MPLS and RSVP/TE support, L2/L3 VPN, multicast,
IPv6, lawful intercept, etc), so I'm curious if anyone's demo'ed an MX
box as a campus core router and tested everything but the kitchen sink
and found something that Juniper says works great, but in actual
practice just isn't quite there yet.

Basically, can someone give me reasons apart from we don't need SONET
or any other WAN interfaces, and it's cheaper per port, why should we
NOT choose an MX box?  Are there any gotchas waiting in the wings for
someone who's used to the full flavored goodness that is the M/T
series?
___
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] Reliable Static Routing

[Phil Bedard]

I think there are things coming with regards to event triggers, etc.  
that may allow this but not as of today, and not as easy to do as on a  
Cisco.  I think this is like the 5th time I've seen someone ask this  
question, sounds like a feature request.


You can accomplish conditional route advertisements by using generated  
routes with a policy that matches on a specific contributing route,  
but you can't say ping a remote address.


Phil

On Jun 24, 2008, at 12:35 AM, Farhan Jaffer wrote:


Hi,

Is there any way of reliable static routing in Juniper Routers?
Similar as Object Tracking in Cisco.

Many Thanks in advance.

-FJ
___
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 mpls mtu

[Phil Bedard]

I think with most of the forwarding engines, the maximum number of  
labels that can be pushed at one time is 3, hence the 12 bytes.


Phil

On Jun 3, 2008, at 9:15 AM, cp wrote:


I hoping someone can provide insight into why by default juniper
calculates mpls mtu at 12 bytes less than the ip mtu?  I've been  
testing

using l3vpn and it seems that mpls mtu pads 8 bytes to its mpls mtu
reducing the ip mtu the inside packet by 8 bytes. Quick example. So if
mpls mtu is 1508 the ip mtu of the packet inside is 1500. That means  
the

ip mtu of the mpls interface is 1520. The only reason I can see
additional bytes needed on top of the l3vpn two is for fast reroute
bypass.  I assume it's for the safety factor although I am probably
missing something. Any information is appreciated.



-Chip













___
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] 2.5 gig SFP modules?

[Phil Bedard]

C/DWDM+Link Aggregation is your best bet.

Phil


On May 21, 2008, at 4:05 PM, Chuck Anderson wrote:

 Has anyone tried to use 2.5 gig SFP's with Juniper M-series as a drop
 in replacement for regular 1 gig SFP's?  The goal is to be able to
 have a 2.5 gig link between an M10i and an M120 over a regional
 optical network.  Does this sort of thing work?

 Thanks,
 Chuck
 ___
 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] BFD over ethernet

[Phil Bedard]

I don't think BFDoEthernet ever really materialized.  The thought was  
to encapsulate BFD messages in 802.3 frames, with a BFD Ethertype.

Phil


On Jan 11, 2008, at 4:27 AM, Bit Gossip wrote:

 I read in a Juniper preso, that BFD can work at layer 2 on a ethernet
 link, but I can not find any reference in the Junos doc. Any idea if
 this is really supported and how to configure it?
 Thanks,
 Bit.

 ___
 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] Re : juniper - cisco l2circuit problem

[Phil Bedard]

You need something other than just the PFC on the MPLS core facing  
side, otherwise
it won't work on a SVI (local switching).

Phil


On May 30, 2007, at 6:05 AM, Atanas Yankov wrote:

 Its Wrong you don't need to OSM modules on SUP720 u can use xconnect
 vlan100 , the problem is was on Juniper side it cannot receive vlan
 interface for attachment circuit :))

 On Fri, 2007-04-06 at 02:17 +, [EMAIL PROTECTED] wrote:
 Christian,

 If you want to use EoMPLS xconnect on a SVI (to allow for local  
 switching as well) then you need a OSM+/SIP400/SIP600/ES20 as the  
 core facing interface. Without one of these modules, you can only  
 configure the xconnext on a sub-interface or main interface.

 Hope this helps,

 - Message d'origine -
 De: Christian Malo [EMAIL PROTECTED]
 Date: Jeudi, Avril 5, 2007 2:57 pm
 Objet: [j-nsp] juniper - cisco l2circuit problem
 À: juniper-nsp@puck.nether.net

 I setup a basic l2circuit between a sup720 and an m20.

 Here's the IOS config and output

 interface GigabitEthernet1/2
 description blahblah
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1,100,127
 switchport mode trunk

 interface Vlan100
 no ip address
 xconnect X.X.Y.110 803 encapsulation mpls

 Local interface: Vl100 up, line protocol up, Eth VLAN 100 up
 Destination address: X.X.Y.110, VC ID: 803, VC status: down
 Output interface: none, imposed label stack {794085}
 Preferred path: not configured
 Default path: active
 Next hop: Invalid ADDR
 Create time: 00:12:29, last status change time: 00:03:35
 Signaling protocol: LDP, peer X.X.Y.110:0 up
 MPLS VC labels: local 38, remote 794085
 Group ID: local 0, remote 0
 MTU: local 1500, remote 1500
 Remote interface description:
 Sequencing: receive disabled, send disabled
 VC statistics:
 packet totals: receive 0, send 0
 byte totals: receive 0, send 0
 packet drops: receive 0, send 0


 JunOS config and output

 unit 518 {
 description blahblah;
 encapsulation vlan-ccc;
 vlan-id 518;
 }

 neighbor X.X.Y.125 {
 interface ge-0/3/0.518 {
 virtual-circuit-id 803;
 description blahblah;
 no-control-word;
 }
 }

 Interface Type St Time last up
 # Up trans
 ge-0/3/0.518(vc 803) rmt Up Apr 5 14:39:41 2007
 1
 Local interface: ge-0/3/0.518, Status: Up, Encapsulation: VLAN
 Remote PE: X.X.Y.125, Negotiated control-word: No
 Incoming label: 794085, Outgoing label: 38
 Time Event
 Interface/Lbl/PE Apr 5 14:39:41 2007 status update timer
 Apr 5 14:39:39 2007 PE route changed
 Apr 5 14:39:39 2007 Out lbl Update
 38
 Apr 5 14:39:39 2007 In lbl Update
 794085 Apr 5 14:39:39 2007 loc intf up
 ge-0/3/0.518



 LDP session comes up ... it works with ethernet-vlan
 configurations but
 the second I try on vlan interfaces, I get that



 thanks for the help.


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

Phil Bedard
[EMAIL PROTECTED]



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

Re: [j-nsp] Issues setting up LACP between M40 and Cisco 6500 CATOS

[Phil Bedard]

You don't need to run a dynamic protocol (PaGP/LACP) to use an  
etherchannel/aggregate interface, just set
mode to on on the Cisco end, and do not run LACP on the Juniper end.

Phil


On May 3, 2007, at 11:32 AM, Dan Benson wrote:

 Nicolaj, that would explain my issue.  Thank you.  I am open to
 suggestions on some form of etherchannel between the cisco and the
 juniper, it was my understanding that the juniper and cisco only  
 support
 LACP as being the common protocol.  Was I wrong in this estimation?
 Thanks.. //db

 Nicolaj Kamensek wrote:
 Dan Benson wrote:

 Hi Dan,

 interfaces ae0   vlan-tagging;
 aggregated-ether-options {
 link-speed 1g;
 lacp {
 active;
 }

 do you have FPC or FPC-E? Active LACP is only possible with the
 enhanced FPC. However, why do you want lacp?

 Regards,
 Nico



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

Phil Bedard
[EMAIL PROTECTED]



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

Re: [j-nsp] BGP Origin Issue

[Phil Bedard]

Are there any other attribute differences between the routes?  What does
a show route detail or show route extensive give you?   The origin  
should
not affect re-advertisement of the route.

Phil


On Apr 19, 2007, at 4:02 PM, Borchers, Mark M. wrote:

 Thanks, but what really has me scratching my head is whether it is  
 a feature
 or a bug that the Juniper does not re-advertise prefixes with
 origin-incomplete to other peers?


 When you redistribute into BGP, the routes will show as
 imcomplete.  I believe
 that is cisco default behavior on redistribution.  To
 circumvent the issue,
 you can create a route-map w/ a 'set origin' on outbound
 announcements.

 On Thursday 19 April 2007 11:22 am, Borchers, Mark M. wrote:
 We have a downstream BGP site announcing 19 prefixes from a
 Cisco router.
 Eleven of the prefixes were configured with network
 statements in his BGP
 config.  The remaining nine were statically null-routed and being
 redistributed into BGP.  Thus, those nine appeared to us on
 an M20 as
 origin incomplete.  None were advertised to other peers.

 Just wondering if this is working as designed or if we have
 a Juniper-Cisco
 BGP interoperability issue.  We are running Junos 7.6R2.6.
 I am aware of
 the role of origin in BGP path selection, but these
 examples include routes
 that are not being announced via any other path.


 Mark Borchers




 NOTICE: This electronic mail transmission may contain confidential
 information and is intended only for the person(s) named.
 Any use, copying
 or disclosure by any other person is strictly prohibited.
 If you have
 received this transmission in error, please notify the
 sender via e-mail.



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




 NOTICE: This electronic mail transmission may contain confidential
 information and is intended only for the person(s) named.  Any use,  
 copying
 or disclosure by any other person is strictly prohibited. If you have
 received this transmission in error, please notify the sender via e- 
 mail.



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

Phil Bedard
[EMAIL PROTECTED]



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

Re: [j-nsp] BGP Origin Issue

[Phil Bedard]

As an aside, you can use network statements with the static routes in  
place, if
you control that box.
Perhaps using a test prefix you can test the behaviour and figure out  
if the origin
attribute plays a part, which it shouldn't.

Phil


On Apr 19, 2007, at 4:40 PM, Borchers, Mark M. wrote:

 Thanks to all responders.  To summarize request for further info:

 1. We do *not* have any origin attributes contained in any inbound or
 outbound policy statements.  We are filtering inbound from  
 downstreams only
 by prefix.  Outbound policy is a mix of as-path and prefix terms.   
 In this
 case, first match would be on an as-path term.

 2. We are receiving all advertisements from the downstream site, both
 origin-incomplete and origin-internal.

 3. All routes are being advertised and received in IBGP ok.

 4. After doing show routes adv bgp it does appear that we are  
 announcing
 all prefixes including origin-incomplete.  It's possible they are  
 being
 rejected by our peers, although I'm pretty confident that most  
 should be
 accepting them.

 Based on the fact that nobody has said Yo dummy, JunOS never re- 
 advertises
 prefixes with origin incomplete, I'm going to do more detailed  
 checking on
 the looking glasses.


 -Original Message-
 From: Angel Bardarov [mailto:[EMAIL PROTECTED]
 Sent: Thursday, April 19, 2007 3:20 PM
 To: Borchers, Mark M.
 Cc: 'juniper-nsp@puck.nether.net'
 Subject: Re: [j-nsp] BGP Origin Issue




 Borchers, Mark M. wrote:
 Thus, those nine appeared to us on an M20 as origin
 incomplete.  None were advertised to other peers.

 In that case the problematic routes are present in the
 routing table of
 your M20. Do you have export policies to you iBGP peers? Can you post
 the output from show route advertising-protocol bgp ...

 Angel




 NOTICE: This electronic mail transmission may contain confidential
 information and is intended only for the person(s) named.  Any use,  
 copying
 or disclosure by any other person is strictly prohibited. If you have
 received this transmission in error, please notify the sender via e- 
 mail.



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

Phil Bedard
[EMAIL PROTECTED]



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