Re: [j-nsp] QFX10002 as P Router

[Doug Hanks]

MX isn’t a VoQ system. It actually buffers on both ingress and egress chipsets. 
The QFX10K is a VoQ system and buffers on ingress chip. QFX10K has 384K VoQs 
per PFE. In the case of the QFX10002-72Q that would be a system total of 2.3M.

> On Apr 19, 2016, at 5:31 AM, Adam Vitkovsky  
> wrote:
> 
>> Nitzan Tzelniker
>> Sent: Saturday, April 16, 2016 8:22 PM
>> 
>> 1. Same performance 500G
>> 2. Same memory technology (3d memory architecture ) 3. Both use Virtual
>> output Queue 4. Both announce on the same day
>> 
> Well MXes also have VOQs and... :)
> What is important is how granular the VOQs are. (not mentioning other QOS 
> system design choices that are crucial for a core box in a converged network).
> PTXes have VOQ for of each of the 8 egress port queues -which is to my 
> knowledge the best granularity out there.
> Does QFX have the same?
> 
> *by a converged network I mean one that carries traffic of different 
> priorities.
> 
> 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

[j-nsp] BAJUG4 Announcement

[Doug Hanks]

Hi all,

I’m really happy to announce that the Bay Area Juniper Users Group (BAJUG4) has 
been scheduled for August 28th 2013.

Fun fact:  we were breaking the fire code in our previous events because we had 
so many people attend. For BAJUG4 I have reserved the Aspiration Dome (Juniper 
event center) that’s able to accommodate over 1,000 people, so there shouldn’t 
be any issues :-)

So this time around I’m bringing back the Father of MPLS:  Kireeti Kompella. 
You may recall he joined the SDN startup Contrail a while back. A few of months 
back Juniper acquired Contrail, so thus Kireeti is back :-) The keynote of 
BAJUG4 will be heavily focused on Contrail/SDN with live demos, given by 
Kireeti himself.

I’ll step up to the plate and do a lightning talk myself. I’ll do something 
with L3 CLOS fun. I also need about 5 volunteers for additional lightning 
talks. These are the 10 minute presentations about something cool, fun, whacky 
with regards to networking. Please reply back to me with some ideas and we can 
work something out. I’ll need the presentations to be in 16x9 format because 
our event center has some fancy projectors. I’ll work through all the details 
with you individually.

Please RSVP and signup at:

http://bajug.eventbrite.com

Feel free to forward this invitation to your friends and colleagues. I look 
forward to seeing you there.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Juniper Networks
Twitter: @douglashanksjr






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

Re: [j-nsp] Krt queue high priority

[Doug Hanks]

# set policy-options policy-statement test term 1 then priority ?
Possible completions:
  high Set priority to high
  low  Set priority to low
  medium   Set priority to medium



On 2/24/13 1:06 AM, Darren O'Connor darre...@outlook.com wrote:

Hi all.

If you do a show krt status there is a 'high priority' field. Any idea
how to ensure certain prefixes actually go into this high priority queue
instead of all of the going through the normal queue? Tis would speed up
the programming of certain prefixes into the fib in a failure event.

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] RR cluster

[Doug Hanks]

vanilla ibgp between the RRs would work


On 2/5/13 6:36 PM, Ali Sumsam ali+juniper...@eintellego.net wrote:

Hi All,
I want to configure two RRs in my network.
What should be the relation between two of them?
I want them to send updates to each other and to the RR-Clients.

Regards,
*Ali Sumsam CCIE*
*Network Engineer - Level 3*
eintellego Pty Ltd
a...@eintellego.net ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)410 603 531

facebook.com/eintellego
PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco ­ Brocade - IBM
___
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] How reliable is EX multichassis? 3300 and 8200 switches

[Doug Hanks]

Don't forget to configure NSB to help with LACP and other L2 stuffs.


set ethernet-switching-options nonstop-bridging

On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.com wrote:

Yes so GRES and NSR is configured am correctly then?

The AE is a VC-lag with one member on each switch.

Luca

On 01/11/2012, at 3:56 AM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:

 On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.com wrote:
 
 Yep my mistake.
 However I do have 'set chassis redundancy graceful-switchover'
configured as well as 'set protocols nonestop-routing'
 
 On 31/10/2012, at 11:24 PM, Stefan Fouant
sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net
wrote:
 
 I think you are confusing GRES w/ GR.  NSR and GRES are NOT mutually
exclusive and in fact NSR requires it to function.
 
 'set chassis redundancy graceful-switchover' is GRES, not GR.
 
 What I actually see when the master switch robots is that the AE
interfaces between my devices flaps. I think this causes my OSPF
neighbours to go down.
 
 I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor
10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from
Full to Down due to KillNbr (event reason: interface went down
 
 Which device is the ae interface tied to?  Is it a VC-LAG with members
tied to multiple physical devices, or is it comprised of only links
belonging to a single device?
 
 Stefan Fouant
 JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI
 Systems Engineer, Juniper Networks




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

Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

[Doug Hanks]

Should be hitless. You need to configure GRES + NSR + no-split-detection.


On 10/30/12 4:06 PM, Morgan McLean wrx...@gmail.com wrote:

Can anybody give me an idea regarding typical failover times if the master
in a two switch pair were to die? The quickest I've seen in my testing
with
EX3300's is 45 seconds, just for L2 forwarding to continue working, no
routing. All the ports drop link as well on the secondary switch while
things switch over. I can have my laptop connected to the secondary
switch,
passing traffic up an uplink on the secondary, and if the master dies it
creates a 45 second interruption.

Normal?

Morgan

On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha
giuli...@wztech.com.brwrote:

 Robert,

 It was released by juniper one or two weeks ago I think.

 Take a look:

 
https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/

 MX2010
 MX2020


 
https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/
#specifications

 But I really don't know if it will support virtual chassis without JCS.

 Att,

 Giuliano



 On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote:

 On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha
 giuli...@wztech.com.br wrote:
  Considering the MX family (240, 480 and 960 with TRIO 3D) and the new
 MX-L

 Hi
 What is new MX-L - can you write a little mort ? MX80 successor ?

 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] How reliable is EX multichassis? 3300 and 8200 switches

[Doug Hanks]

GR is mutually exclusive with NSR.


You want NSR.

On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote:

I'm just playing around with this now since I have a few new EX switches
not in production just yet
Have a pretty simple setup with two EX4500 in VC connected to another two
EX4500 in VC mode.  I'm running OSPF between them.

I rebooted the master member while running a ping an it took around 40
seconds to come back up. I noticed that my OSPF  adjacency went down and
the delay was waiting for the OSPF neighbours to come back up.

I  have: 
nonstop-routing configured under routing options
graceful-switchover configured under chassis redundancy
nonstop-bridging configured under ethernet-switching-options

Would graceful-restart be a better config than non-stop routing?

Luca


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean
Sent: Wednesday, 31 October 2012 11:00 AM
To: Ben Dale
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
switches

Neither of these two options show up as a configurable flag:

set routing-options nonstop-routing
set ethernet-switching-options nonstop-bridging

I'm running 11.4R2.14 on the ex3300-48t switches.

Granted, right now the VC is broken so maybe it doesn't allow me to
configure it? I can head to the datacenter and upgrade these two devices
to recommended release and report back tomorrow as well.

Morgan

On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote:

 Hi Morgan,

 On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote:

  Can anybody give me an idea regarding typical failover times if the
 master
  in a two switch pair were to die? The quickest I've seen in my
  testing
 with
  EX3300's is 45 seconds, just for L2 forwarding to continue working,
  no routing. All the ports drop link as well on the secondary switch
  while things switch over. I can have my laptop connected to the
  secondary
 switch,
  passing traffic up an uplink on the secondary, and if the master
  dies it creates a 45 second interruption.
 
  Normal?
 

 Yes, but add the following to your configuration:

 set virtual-chassis no-split-detection(you may already have this)
 set routing-options nonstop-routing
 set ethernet-switching-options nonstop-bridging

 and try again.  In your testing, put a 3rd switch in place with LACP
 and one leg to each member.

 My testing (45/42xx) has shown L2 should be pretty much hitless under
 most circumstances (except if your STP topology needs to re-converge),
 and L3 should around the 1-4 seconds mark (for violent failures of
master RE).

 The worst case scenario though is re-merging a split VC, which can
 take the best part of 45 seconds, so avoid split-brain scenarios
 whenever possible with redundant VCP/VCPe or schedule their repair
 during planned outage windows.

 Cheers,

 Ben




  Morgan
 
  On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha 
 giuli...@wztech.com.brwrote:
 
  Robert,
 
  It was released by juniper one or two weeks ago I think.
 
  Take a look:
 
 
 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20
 00/
 
  MX2010
  MX2020
 
 
 
 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20
 00/#specifications
 
  But I really don't know if it will support virtual chassis without
JCS.
 
  Att,
 
  Giuliano
 
 
 
  On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com
wrote:
 
  On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha
  giuli...@wztech.com.br wrote:
  Considering the MX family (240, 480 and 960 with TRIO 3D) and the
  new
  MX-L
 
  Hi
  What is new MX-L - can you write a little mort ? MX80 successor ?
 
  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




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

Re: [j-nsp] VPLS design - dual homed

[Doug Hanks]

The MX can do this several different ways:

1) VPLS MH - it's a O(n) convergence problem, where n is the number of
VPLS instances
2) MC-LAG A/S - now becomes a O(1) convergence problem


On 10/29/12 4:19 PM, Luca Salvatore l...@ninefold.com wrote:

Hi Guys,

I have a question regarding dual VPLS links.  My topology will look like
this:

MX1-darkfibre--MX2
  |  |
  |  |
MX3-darkfibre--MX4

So above you see that there are dual  links which will create a loop.

How does VPLS handle these types of topologies?  Do I need to just use
spanning tree and have one link in blocking?
Or perhaps use MSTP and send some VLANs down one link and some down the
other?
I will be spanning around 1000 VLANs across these links. They are 10Gb
links, so it seems a shame to have one in a blocking state.

Any other recommendations?  Perhaps M-LAG?
Thanks,

Luca.

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




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

Re: [j-nsp] MX80 no more hash-key option in 12.2?

[Doug Hanks]

Pretty much. enhanced-hash-hey does a lot by default. Harry can elaborate.


On 10/23/12 2:38 AM, Paul Vlaar p...@vlaar.net wrote:

On 23/10/12 12:59 AM, Doug Hanks wrote:
 hash-key = DPC (should never been been on or used on the MX80 - doesn't
 even do anything when configured)
 
 
 enhanced-hash-key = MPC (which works on the MX80 as it's based on Trio)

mx80# set family inet ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  incoming-interface-index  Include incoming interface index in the hash
key
  no-destination-port  Omit IP destination port in the hash key
  no-source-port   Omit IP source port in the hash key
  type-of-service  Include TOS byte in the hash key
[edit forwarding-options enhanced-hash-key]

I can only negate layer-4 information in the settings for that, does
this imply that hashing on source / destination port is now the default
even when I leave this setting out completely?

So if I leave out any enhanced-hash-key setting, I can assume that
traffic is hashed based on IP address, source and destination port?

And does this mean ...

services-loadbalancing {
family inet layer-3-services {
incoming-interface-index;
source-address;
}
}

... that only IPv4 based ECMP hashing is supported across the different
PICs?

Thanks,

~paul




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

Re: [j-nsp] Juniper MX5 vs Brocade CER

[Doug Hanks]

These numbers will change with every hardware release and software
release. I used a generic number with the MX book.

The idea is that as soon as the book hits the shelf, the testing numbers
would have been obsolete anyway (it took Harry and I about 14 months to
write).


Your SE should be more than happy to give you the current scaling results
with the hardware + software combinations.

On 10/22/12 8:24 AM, Saku Ytti s...@ytti.fi wrote:

On (2012-10-22 13:21 +0100), Darren O'Connor wrote:

 It was Doug Hanks that said it. And he wrote the new MX book

I've not read this book. But I find it really shame if book presents
simplified marketing numbers instead of giving reader understanding of the
platform.
Juniper seems much more hesitant than Cisco to provider gritty
architecture
details. Maybe they think it's not relevant to operators, but it is

Knowing how box works helps lot with troubleshooting software defects. It
also helps with defining new products, as it helps deciding when there are
many ways to configure it, which configuration is best fit for the
limitations you have in HW.

-- 
  ++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] MX80 no more hash-key option in 12.2?

[Doug Hanks]

hash-key = DPC (should never been been on or used on the MX80 - doesn't
even do anything when configured)


enhanced-hash-key = MPC (which works on the MX80 as it's based on Trio)

On 10/22/12 5:36 PM, Paul Vlaar p...@vlaar.net wrote:

I just upgraded one of our MX80s to 12.2R1.3, and the following occurs:

mx80# show forwarding-options
[...]
##
## Warning: configuration block ignored: unsupported platform (mx80-48t)
##
hash-key {
family inet {
layer-3;
layer-4;
}
family inet6 {
layer-3;
layer-4;
}
}

It's accepted and works as expected on 11.2R3.3. Anybody else ran into
this? Documentation doesn't suggest it moved elsewhere:

http://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/po
licy-configuring-per-packet-load-balancing.html

To include port data in the flow determination, include the family inet
statement at the [edit forwarding-options hash-key] hierarchy level:

[edit forwarding-options hash-key]
family inet {
layer-3;
layer-4;
}

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




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

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

All you need in this scenario is a simple policer and a firewall filter than. 
Just match the different types of traffic as you described below into different 
terms of a firewall filter, then depending on what you want to do with the 
traffic, police it or discard it.

From: Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Date: Mon, 15 Oct 2012 10:40:41 -0300
To: dhanks dha...@juniper.netmailto:dha...@juniper.net
Cc: EXT - caill...@commtelns.commailto:caill...@commtelns.com 
caill...@commtelns.commailto:caill...@commtelns.com, Serge Vautour 
se...@nbnet.nb.camailto:se...@nbnet.nb.ca, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Hi, After reading your comments, I will try to explain better  what I'm trying 
to achieve. I'm trying to do classification and queueing on an ingress 
interface.

When the wan interface gets rate limit threshold (500mbits), all the traffic 
that is destinated to the high priority destination subnet gets precedence and 
no packet loss or lower packet loss, than the low priority.

The egress traffic to these subnets goes to two different physical interfaces ( 
ge-1/0/5 and ge-1/0/5) So , from what I read from you, the ingress interface 
should see the rate limit of 500mbits gets congestion and then discard 
packets from wan that have destination (address) subnet that differs from the 
high priority subnet.

For instance: If the current wan ingress traffic total is 450mbits and high 
priority traffic is 100mbits, and low priority is 350mbits = no packet discard, 
but if traffic towards high priority subnet is 300mbits and low priority is 
300mbits, then the queuing / scheduler will drop the low priority traffic until 
the sources traffic gets shaped to 200mbits for the low priority and the high 
priority gets 300mbits.

On Linux it's quite simple to achieve.

Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



2012/10/15 Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
If you're having a hard time writing
the proper code-points to a packet, I would assume the packets are
classified correctly.

s/correctly/incorrectly/



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

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

Take the policer out of the IFL and put it into the firewall filter. Should be 
good to go.

From: Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Date: Mon, 15 Oct 2012 11:57:40 -0300
To: dhanks dha...@juniper.netmailto:dha...@juniper.net
Cc: EXT - caill...@commtelns.commailto:caill...@commtelns.com 
caill...@commtelns.commailto:caill...@commtelns.com, Serge Vautour 
se...@nbnet.nb.camailto:se...@nbnet.nb.ca, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Doug,

Like this?


Interface

[edit interfaces ge-1/1/0]
gustavo@BRD01# show
description WAN;
unit 0 {
bandwidth 490m;
family inet {
filter {
input controle;
}
policer {
input gvt;
}
sampling {
input;
output;
}
address 177.99.164.126/30http://177.99.164.126/30;
}
}

[edit interfaces ge-1/1/0]

Policer

[edit firewall policer wan]
gustavo@BRD01# show
if-exceeding {
bandwidth-limit 490m;
burst-size-limit 625k;
}
then discard;

[edit firewall policer wan]


Filter


gustavo@BRD01# show
term clientes {
from {
destination-address {
177.8.x.0/21;
177.x.x.0/22;
177.6x.x.0/22;
177.6x.xx0.0/24;
177.6x.xx1.0/24;
177.6x.xx3.0/24;
177.1x.1x.0/22;
177.1x.1x.0/24;
177.1x.2x.0/21;
177.1x.2x.0/22;
177.1x.2x.0/22;
}
}
then {
loss-priority low;
forwarding-class expedited-forwarding;
 }
}
term resto {
then {
loss-priority high;
forwarding-class best-effort;

}
}

[edit firewall family inet filter controle]




Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



2012/10/15 Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
All you need in this scenario is a simple policer and a firewall filter than. 
Just match the different types of traffic as you described below into different 
terms of a firewall filter, then depending on what you want to do with the 
traffic, police it or discard it.

From: Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Date: Mon, 15 Oct 2012 10:40:41 -0300
To: dhanks dha...@juniper.netmailto:dha...@juniper.net
Cc: EXT - caill...@commtelns.commailto:caill...@commtelns.com 
caill...@commtelns.commailto:caill...@commtelns.com, Serge Vautour 
se...@nbnet.nb.camailto:se...@nbnet.nb.ca, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net

Subject: Re: [j-nsp] WAN input prioritization on MX

Hi, After reading your comments, I will try to explain better  what I'm trying 
to achieve. I'm trying to do classification and queueing on an ingress 
interface.

When the wan interface gets rate limit threshold (500mbits), all the traffic 
that is destinated to the high priority destination subnet gets precedence and 
no packet loss or lower packet loss, than the low priority.

The egress traffic to these subnets goes to two different physical interfaces ( 
ge-1/0/5 and ge-1/0/5) So , from what I read from you, the ingress interface 
should see the rate limit of 500mbits gets congestion and then discard 
packets from wan that have destination (address) subnet that differs from the 
high priority subnet.

For instance: If the current wan ingress traffic total is 450mbits and high 
priority traffic is 100mbits, and low priority is 350mbits = no packet discard, 
but if traffic towards high priority subnet is 300mbits and low priority is 
300mbits, then the queuing / scheduler will drop the low priority traffic until 
the sources traffic gets shaped to 200mbits for the low priority and the high 
priority gets 300mbits.

On Linux it's quite simple to achieve.

Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



2012/10/15 Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
If you're having a hard time writing
the proper code-points to a packet, I would assume the packets are
classified correctly.

s/correctly/incorrectly/




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

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

Yes, that's just what I said in so few words :-)

Classification = ingress
Queuing = egress

From: Serge Vautour sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca
Reply-To: Serge Vautour se...@nbnet.nb.camailto:se...@nbnet.nb.ca
Date: Sun, 14 Oct 2012 10:06:37 -0700
To: dhanks dha...@juniper.netmailto:dha...@juniper.net, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, Gustavo Santos 
gustkil...@gmail.commailto:gustkil...@gmail.com
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Humm. My understand, at least with the command sets I'm use to using, is that 
you do classification on ingress and then queuing and marking on egress. When 
you do classification, the packets are assigned to a  Forwarding Class (FC) 
inside the box. This makes sure the box gives those packets proper treatment 
inside the box and that the packets get assigned to the proper egress interface 
queue. While the packets exit the queue (based on egress schedulers), the 
packet QoS headers are remarked.

Basically, this diagram:

http://www.juniper.net/techpubs/images/g017213.gif

Packets travel through the box based on the outer boxes following the solid 
lines. The dotted lines all point to or from the FC to identify how the 
decision is made.

Serge



From: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
To: Chris Evans chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com; 
Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Sent: Sunday, October 14, 2012 12:09:53 AM
Subject: Re: [j-nsp] WAN input prioritization on MX

How is this weird? You can mark on ingress, but the queuing happens on the
egress interface when it's to be transmitted.


On 10/13/12 6:07 AM, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:

JUNOS does a weird way of marking packets.. It is done on the egress of
the
box, not on ingress (there is an exception in a few newer modules that can
do this). So it is probably working as the other poster mentioned.  Make
sure you take this methodology into consideration as it can hinder your
granularity of CoS with marking vs passing through and
you inadvertently remark traffic you didn't mean to.

On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos
gustkil...@gmail.commailto:gustkil...@gmail.comwrote:

 Doug and Hanks @juniper. I had to left the office and leave
configuration
 as is. On monday I will update you after verify what you have pointed,

 What I can tell is that I didn't have made any modification on the
systems
 default class of service  / mapping configuration.

 Thank you!

 Gustavo Santos
 Analista de Redes
 CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



 2012/10/13 Harry Reynolds ha...@juniper.netmailto:ha...@juniper.net

  Doug raises some good points.
 
  Also, for testing, perhaps add some counters to the terms to aid in
  confirming matches. You may also want to show config | display
  detail/inheritance to see if the prefix list is expanding as you
expect.
 
  Regards
 
 
 
  -Original Message-
  From: 
  juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net
   [mailto:
  juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net]
   On Behalf Of Doug Hanks
  Sent: Friday, October 12, 2012 9:36 PM
  To: Gustavo Santos; 
  juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
  Subject: Re: [j-nsp] WAN input prioritization on MX
 
  I'm sure it's working just fine. Are you checking the egress
interface to
  see if the traffic is being marked and queued properly? A common
mistake
 is
  to check the ingress interface queues.
 
 
  If this doesn't work, we would need to see your entire
class-of-service
  configuration.
 
  On 10/12/12 6:04 PM, Gustavo Santos 
  gustkil...@gmail.commailto:gustkil...@gmail.com wrote:
 
  Hi,
  
  I'm new on Juniper class of service / shaping. I'm reading some tech
  docs from Juniper and a Juniper's  MX book, but it's kind tricky.
  Today I get asked to do a pretty simple configuration, but I tried
some
  settings but none of then worked. Any of you guys can help me with
that?
  
  What I want to achieve is pretty (conceptualy speaking) simple.  I
have
  a Gig interface and want to rate limit the interface at 500Mbits ,
mark
  a destination subnet with expedited forwarding class, mark anything
  else with best effort. I tried the config below but it's not working.
  The rate-limit works but the prioritization isn't.
  
  
  
  
  gustavo@MX5-1 show configuration firewall family inet filter
  wan-control physical-interface-filter; term high-priority {
  from {
  destination-prefix-list {
  high-priority-dst

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

What are you considering packet marking? In Junos you can set the
forwarding-class and loss-priority in about five different places; this is
typically done on the ingress interface, but can also be done on the
egress interface.


Not sure I'm following your scenario of transit traffic (which I
understand) and newly injected traffic (not sure what you're referring to
here).

Why are you trying to use the rewrite tool to mark packets (classify?) or
are you referring to packet marking as writing the correct bits to the
egress packet? Junos rewrite does nothing more than associate a
forwarding-class with a code-point. If you're having a hard time writing
the proper code-points to a packet, I would assume the packets are
classified correctly.

On 10/14/12 8:55 PM, Caillin Bathern caill...@commtelns.com wrote:

More to the point I believe the original commenter was talking about
packet marking, not queuing or classification :)

And here I believe that junos doesn't work well...  If you have a link
that carries both transit and newly injected traffic you are stuffed
when you try to perform a rewrite to correctly mark ingress node traffic
but also try to transparently pass through traffic from a trusted source
using the same FC.

Caillin

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
Sent: Monday, 15 October 2012 2:35 PM
To: Serge Vautour; Chris Evans; Gustavo Santos
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Yes, that's just what I said in so few words :-)

Classification = ingress
Queuing = egress

From: Serge Vautour
sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca
Reply-To: Serge Vautour se...@nbnet.nb.camailto:se...@nbnet.nb.ca
Date: Sun, 14 Oct 2012 10:06:37 -0700
To: dhanks dha...@juniper.netmailto:dha...@juniper.net, Chris Evans
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, Gustavo
Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Humm. My understand, at least with the command sets I'm use to using, is
that you do classification on ingress and then queuing and marking on
egress. When you do classification, the packets are assigned to a
Forwarding Class (FC) inside the box. This makes sure the box gives
those packets proper treatment inside the box and that the packets get
assigned to the proper egress interface queue. While the packets exit
the queue (based on egress schedulers), the packet QoS headers are
remarked.

Basically, this diagram:

http://www.juniper.net/techpubs/images/g017213.gif

Packets travel through the box based on the outer boxes following the
solid lines. The dotted lines all point to or from the FC to identify
how the decision is made.

Serge



From: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
To: Chris Evans
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com; Gustavo
Santos gustkil...@gmail.commailto:gustkil...@gmail.com
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Sent: Sunday, October 14, 2012 12:09:53 AM
Subject: Re: [j-nsp] WAN input prioritization on MX

How is this weird? You can mark on ingress, but the queuing happens on
the egress interface when it's to be transmitted.


On 10/13/12 6:07 AM, Chris Evans
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:

JUNOS does a weird way of marking packets.. It is done on the egress of

the box, not on ingress (there is an exception in a few newer modules
that can do this). So it is probably working as the other poster
mentioned.  Make sure you take this methodology into consideration as
it can hinder your granularity of CoS with marking vs passing through
and you inadvertently remark traffic you didn't mean to.

On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos
gustkil...@gmail.commailto:gustkil...@gmail.comwrote:

 Doug and Hanks @juniper. I had to left the office and leave
configuration  as is. On monday I will update you after verify what
you have pointed,

 What I can tell is that I didn't have made any modification on the
systems  default class of service  / mapping configuration.

 Thank you!

 Gustavo Santos
 Analista de Redes
 CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



 2012/10/13 Harry Reynolds
 ha...@juniper.netmailto:ha...@juniper.net

  Doug raises some good points.
 
  Also, for testing, perhaps add some counters to the terms to aid in

  confirming matches. You may also want to show config | display
  detail/inheritance to see if the prefix list is expanding as you
expect.
 
  Regards
 
 
 
  -Original Message-
  From:
juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.neth
er.net [mailto:
  juniper-nsp-boun

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

If you're having a hard time writing
the proper code-points to a packet, I would assume the packets are
classified correctly.

s/correctly/incorrectly/



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

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

If you want to trust the code-points on ingress traffic, then just use a 
behavior aggregate and place the trusted traffic into the correct 
forwarding-class; no need to re-classify it. Technically you don't even need 
the BA to classify trusted packets, but makes the process more understandable 
and deterministic.

In the scenario with a single CE with two WAN interfaces with different 
code-point schemes, the Junos class-of-service is superior. You simply classify 
the ingress LAN traffic once then on egress - depending on which WAN interface 
is chosen - the rewrite-rules can write the proper code-points.

There's enough optimization in Junos that if an ingress packet has a code-point 
of 100 and the egress rewrite-rule is also 100, it's considered a NOOP 
function. Don't worry, the MX is able to perform line-rate class of service.

From: Huan Pham drie.huanp...@gmail.commailto:drie.huanp...@gmail.com
Date: Mon, 15 Oct 2012 16:09:19 +1100
To: Caillin Bathern caill...@commtelns.commailto:caill...@commtelns.com
Cc: dhanks dha...@juniper.netmailto:dha...@juniper.net, Serge Vautour 
se...@nbnet.nb.camailto:se...@nbnet.nb.ca, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, Gustavo Santos 
gustkil...@gmail.commailto:gustkil...@gmail.com, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Hi Caillin,

I can see your points. You think that it is logical to mark traffic as it comes 
to the router, and leave it untouched, as it leaves your router. This is what I 
used to think of QoS (as I come from the Cisco world). However, I need to 
rethink when getting to know Juniper.

With Juniper way, you can still leave the trusted traffic untouched by 
remarking to the same EXP, or DSCP scheme, as traffic leave your router. I 
mean, we are not stuffed.

I do however see a good point in the Juniper way, which marks traffic as it 
LEAVES the router!

If you have a managed CE with one LAN connection (connected to customer LAN), 
and two WAN connections going to two carriers with 2 different CoS schemes. You 
do need to mark traffic differently to match the ISP ones, depending on which 
interface it take to exit your router (i.e. depending on routing).

If you do mark the traffic as it comes to your router, you are stuffed.

Surely, you can say that, you can still remark your trusted traffic as it 
leaves your router, but it is double marking (you have to do it twice), isn't 
it?

Cheers,

Huan



On Mon, Oct 15, 2012 at 2:55 PM, Caillin Bathern 
caill...@commtelns.commailto:caill...@commtelns.com wrote:
More to the point I believe the original commenter was talking about
packet marking, not queuing or classification :)

And here I believe that junos doesn't work well...  If you have a link
that carries both transit and newly injected traffic you are stuffed
when you try to perform a rewrite to correctly mark ingress node traffic
but also try to transparently pass through traffic from a trusted source
using the same FC.

Caillin

-Original Message-
From: 
juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net]
 On Behalf Of Doug Hanks
Sent: Monday, 15 October 2012 2:35 PM
To: Serge Vautour; Chris Evans; Gustavo Santos
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Yes, that's just what I said in so few words :-)

Classification = ingress
Queuing = egress

From: Serge Vautour
sergevaut...@yahoo.camailto:sergevaut...@yahoo.camailto:sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca
Reply-To: Serge Vautour 
se...@nbnet.nb.camailto:se...@nbnet.nb.camailto:se...@nbnet.nb.camailto:se...@nbnet.nb.ca
Date: Sun, 14 Oct 2012 10:06:37 -0700
To: dhanks 
dha...@juniper.netmailto:dha...@juniper.netmailto:dha...@juniper.netmailto:dha...@juniper.net,
 Chris Evans
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com,
 Gustavo
Santos 
gustkil...@gmail.commailto:gustkil...@gmail.commailto:gustkil...@gmail.commailto:gustkil...@gmail.com
Cc: 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] WAN input prioritization on MX

Humm. My understand, at least with the command sets I'm use to using, is
that you do classification on ingress and then queuing and marking on
egress. When you do classification, the packets are assigned to a
Forwarding Class (FC) inside the box. This makes sure the box gives
those packets proper treatment inside the box and that the packets get
assigned to the proper egress interface queue. While the packets exit
the queue (based on egress schedulers), the packet

Re: [j-nsp] WAN input prioritization on MX

[Doug Hanks]

How is this weird? You can mark on ingress, but the queuing happens on the
egress interface when it's to be transmitted.


On 10/13/12 6:07 AM, Chris Evans chrisccnpsp...@gmail.com wrote:

JUNOS does a weird way of marking packets.. It is done on the egress of
the
box, not on ingress (there is an exception in a few newer modules that can
do this). So it is probably working as the other poster mentioned.  Make
sure you take this methodology into consideration as it can hinder your
granularity of CoS with marking vs passing through and
you inadvertently remark traffic you didn't mean to.

On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos
gustkil...@gmail.comwrote:

 Doug and Hanks @juniper. I had to left the office and leave
configuration
 as is. On monday I will update you after verify what you have pointed,

 What I can tell is that I didn't have made any modification on the
systems
 default class of service  / mapping configuration.

 Thank you!

 Gustavo Santos
 Analista de Redes
 CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



 2012/10/13 Harry Reynolds ha...@juniper.net

  Doug raises some good points.
 
  Also, for testing, perhaps add some counters to the terms to aid in
  confirming matches. You may also want to show config | display
  detail/inheritance to see if the prefix list is expanding as you
expect.
 
  Regards
 
 
 
  -Original Message-
  From: juniper-nsp-boun...@puck.nether.net [mailto:
  juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
  Sent: Friday, October 12, 2012 9:36 PM
  To: Gustavo Santos; juniper-nsp@puck.nether.net
  Subject: Re: [j-nsp] WAN input prioritization on MX
 
  I'm sure it's working just fine. Are you checking the egress
interface to
  see if the traffic is being marked and queued properly? A common
mistake
 is
  to check the ingress interface queues.
 
 
  If this doesn't work, we would need to see your entire
class-of-service
  configuration.
 
  On 10/12/12 6:04 PM, Gustavo Santos gustkil...@gmail.com wrote:
 
  Hi,
  
  I'm new on Juniper class of service / shaping. I'm reading some tech
  docs from Juniper and a Juniper's  MX book, but it's kind tricky.
  Today I get asked to do a pretty simple configuration, but I tried
some
  settings but none of then worked. Any of you guys can help me with
that?
  
  What I want to achieve is pretty (conceptualy speaking) simple.  I
have
  a Gig interface and want to rate limit the interface at 500Mbits ,
mark
  a destination subnet with expedited forwarding class, mark anything
  else with best effort. I tried the config below but it's not working.
  The rate-limit works but the prioritization isn't.
  
  
  
  
  gustavo@MX5-1 show configuration firewall family inet filter
  wan-control physical-interface-filter; term high-priority {
  from {
  destination-prefix-list {
  high-priority-dst;
  }
  }
  then {
  policer limit500;
  loss-priority low;
  forwarding-class expedited-forwarding;
  }
  }
  term else {
  then {
  policer limit500;
  loss-priority high;
  forwarding-class best-effort
 }
  
  
  ( policer limit500)
  physical-interface-policer;
  if-exceeding {
  bandwidth-limit 480m;   (set the value lower to check policer
  working..
  but it wasn't as desired)
  burst-size-limit 625k;
  }
  then discard;
  
  then the filter was applied on the interface family inet filter input
  wan-control
  
  Gustavo Santos
  Analista de Redes
  CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
  ___
  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] WAN input prioritization on MX

[Doug Hanks]

I'm sure it's working just fine. Are you checking the egress interface to
see if the traffic is being marked and queued properly? A common mistake
is to check the ingress interface queues.


If this doesn't work, we would need to see your entire class-of-service
configuration.

On 10/12/12 6:04 PM, Gustavo Santos gustkil...@gmail.com wrote:

Hi,

I'm new on Juniper class of service / shaping. I'm reading some tech docs
from Juniper and a Juniper's  MX book, but it's kind tricky.
Today I get asked to do a pretty simple configuration, but I tried some
settings but none of then worked. Any of you guys can help me with that?

What I want to achieve is pretty (conceptualy speaking) simple.  I have a
Gig interface and want to rate limit the interface at 500Mbits , mark a
destination subnet with expedited forwarding class, mark anything else
with
best effort. I tried the config below but it's not working.  The
rate-limit
works but the prioritization isn't.




gustavo@MX5-1 show configuration firewall family inet filter wan-control
physical-interface-filter;
term high-priority {
from {
destination-prefix-list {
high-priority-dst;
}
}
then {
policer limit500;
loss-priority low;
forwarding-class expedited-forwarding;
}
}
term else {
then {
policer limit500;
loss-priority high;
forwarding-class best-effort
   }


( policer limit500)
physical-interface-policer;
if-exceeding {
bandwidth-limit 480m;   (set the value lower to check policer
working..
but it wasn't as desired)
burst-size-limit 625k;
}
then discard;

then the filter was applied on the interface family inet filter input
wan-control

Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp




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

Re: [j-nsp] mx-class units now advertisement management interface networks in BGP

[Doug Hanks]

So I guess the million dollar question is what does your BGP export policy
look like?

Reply-all with:

- show protocols bgp
- show policy-options policy-statement whatever is being used as an
export BGP policy


On 9/27/12 10:49 AM, Jo Rhett jrh...@netconsonance.com wrote:

I don't know when Juniper broke this, but I was chasing down a different
problem earlier this week and discovered that our Juniper MX80s are
advertising the fxp0 interface's network in BGP announcements. My testing
seems to indicate that it still won't accept packets on other interfaces
for this network, so the historical nature of fxp0 seems to remain the
same. This means it is clearly a bug in the announcements.

It was a bit surprising to find such a rookie mistake coming from
Juniper, but sadder still is the two days of back and forth I've had to
do with Juniper on this topic. They really don't understand BGP at all.

Suggestions:
   1. Who cares it won't be used by this unit.
---um, yeah, I care about the other units receiving it.

   2. Filter it on all recipients.
--sure, let's go ask this of all our peers, instead of fixing the
source

   3. Send me a capture of the announcement from the source
--right, because output from another router showing it on the
received routes from this unit isn't conclusive.

   4. Send me the arp table from the unit
--okay, I'm not even going to dignify this with a response.

So, not even that long ago, I would have argued that it's worth paying
more for Juniper gear just because the technical support response was
more coherent and useful when a bug was found. Juniper seems to have
eroded that completely away now. After two days on this topic I could
have gotten a bug fix out of Cisco. At this point Juniper hasn't even
started the grasp the nature of the problem. This really isn't a good
sign.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet
projects.



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




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

Re: [j-nsp] mx-class units now advertisement management interface networks in BGP

[Doug Hanks]

It's working as designed.

Junos leaves the BGP advertisements in the hands of the operator. What you've 
done is created an export policy that just happens to match fxp0; this isn't 
Junos' fault.

If you want to advertise direct interfaces, but exclude fxp0, you could do 
something like this that you could cut and paste across N routers without 
having to modify (thanks Harry for confirming):

term block-fxp {
from interface fxp0.0;
then reject;
}
term 2 {
from protocol direct;
then accept;
}

From: Jo Rhett jrh...@netconsonance.commailto:jrh...@netconsonance.com
Date: Thu, 27 Sep 2012 13:06:30 -0700
To: Harry Reynolds ha...@juniper.netmailto:ha...@juniper.net, dhanks 
dha...@juniper.netmailto:dha...@juniper.net
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] mx-class units now advertisement management interface 
networks in BGP

Reply to Harry and Doug both since you mostly asked the same question.

On Sep 27, 2012, at 12:13 PM, Harry Reynolds wrote:
It might help if you posted your BGP export policy. IIRC, there is a 
no-readvertise flag available for a static but not aware of any inherent 
blocking of the advertisement of an fxpo address via BGP, more so if your 
export permits it.

To me it is a bug to advertise a route which you won't route packets for. 
Obviously it's your fault if you advertise a route and have a packet filter 
blocking packets -- the routing engine isn't responsible for this. But fxp0 is 
supposedly on its own routing fabric. I can't send packets in ae0 destined for 
something on the fxp0 network.

If a route visible in one routing engine was advertised out by another routing 
engine (with no route-sharing between them) this would be a bug, yes? Why isn't 
fxp0 treated the same way?

Finally, we have the same export policy on every node in our network. Having to 
break that out, and hand-tune every export policy to explicitly deny the fxp0 
interface's routes is a lot of work with zero gain. If for some reason Juniper 
feels that it's important to someone somewhere to announce a route you won't 
accept packets for, why isn't there any easy method to disable this 
nonsensical, nonfunctional, nobody in their right mind would or could use it 
(non)functionality?

Obviously, a feature request for protocol bgp { interface fxp0 { ignore; }} 
would do the trick, but I struggle to believe that you've never seen this 
problem before, and you don't have a better way to prevent this behavior.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



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

Re: [j-nsp] MX80 bridge-domain QinQ question

[Doug Hanks]

See inline.


On 9/19/12 4:09 PM, Jeff Wheeler j...@inconcepts.biz wrote:
The above configuration works.  Unfortunately, I must duplicate the
above stanzas for each CVLAN.  If I try to use vlan-id-list [ 423 424
] on the EX4200-facing port, the IFL sees 0 packets.  For example:

interface xe-0/0/3.423 {
  description customer servers via EX4200;
  encapsulation vlan-bridge;
  vlan-id-list [ 423 424 ];
  family bridge;
}
That commits but xe-0/0/3.423 never sees any packets arrive, and the
BD never learns any MACs from it.  Certainly it doesn't work as I
thought it might.

That's because you defined a BD with a type of default which requires
that any IFL placed into that BD has to have all tags matching to be able
to bridge. If you wish to modify the tags, you have to use the
input-vlan-map and output-vlap-map to do so. Also keep in mind that the MX
will bridge on the C-TAG by default.

Using interface-mode trunk and configuring a vlan-id-list in the BD is
not possible, as far as I can understand, because I can't work out how
to configure the telco-facing IFL to push/pop as needed to get the
outer-tag on it.  It seems I can't use input/output-vlan-mapping in
concert with a BD configured with a vlan-id-list in order to utilize
mode trunk.

You can't use ENT-style IFL (family bridge) configurations with a default
BD (no vlan definition)

You'll just need to define each CTAG as you have been doing.
 



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

Re: [j-nsp] MX80 bridge-domain QinQ question

[Doug Hanks]

Use a SP-style IFL using 802.1ad for telco. Use a SP-style IFL using
802.1q for the EX4200. The BD will automatically pop and push tags for you.


Does that help?

On 9/19/12 1:00 PM, Jeff Wheeler j...@inconcepts.biz wrote:

Dear List,

I am having trouble figuring out how to configure a bridge-domain setup
for
customer traffic with QinQ outer-tags on some interfaces, but not all.  My
topology is as follows:

CE---telco network---MX80---EX4200---CE

In this case, the vlans between MX80 and EX4200 are single-tagged; but an
outer-tag must be pushed toward the telco to direct them to the customer
site.  This is possible by creating a distinct bridge-domain, and logical
interfaces, per each CVLAN.  However, it will not work with vlan-id-lists
or similar, which may allow me to avoid all that extra config per CVLAN.
 Various restrictions on when input/output-vlan-map can be used, etc.
prevent me from configuring it.

Obviously the savvy thing to do is simply push an outer tag using the
EX4200, which then may be swapped as needed; but is it possible to
configure this as I want, without distinct bridge-domain and logical units
per each CVLAN?  The restriction against doing push/pop operations on
outer
tags when vlan-id-list is in use seem to be stopping me.  FYI I have tried
on 10.4 and 11.4 boxes, so I do have interface-mode trunk; but it is
unhelpful given the push/pop limits.

Thanks
-- 
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] Tacacs on Junos

[Doug Hanks]

I totally read this as tacos on Junos and got excited for a moment :(


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

Re: [j-nsp] MX Design

[Doug Hanks]

Running MC-LAG A/A on the two MXs works pretty well. That will provide a
single, logical link using LACP to the EXs.


On 9/13/12 1:55 AM, Johan Borch johan.bo...@gmail.com wrote:

Hi,

I have two mx and two ex connected as follows, L2 on the EX and L2/L3
on MX, MX handles all the routing.


MX -- MX
|   \   /   |
|   /   \   |
EX -- EX
   \/
Access-sw


What is the best way to tie everything together? MSTP all the way up
to MX or is there a better way? How do I transport VLAN's between the
MX, with just tagging the interfaces between or is some kind of MPLS
better?

Regards
Johan
___
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] inline-jflow

[Doug Hanks]

Using fxp0 for inline-jflow has been disabled since 10.2; you need to use
a revenue port as the egress.


On 9/6/12 5:05 AM, moki vom...@gmail.com wrote:

Hello
Does anyone know if inline-jflow support to send traffic via fxp
interface.
I tried to configure inline-jflow with the configuration bellow when the
route to the destination is the fxp interface:
family inet {
output {
flow-server 88.88.88.1 {-- routed via fxp
port 2055;
autonomous-system-type origin;
version-ipfix {
template {
default-temp;
}
}
}
inline-jflow {
source-address 88.88.88.2;
}
}

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


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

Re: [j-nsp] About Juniper Control Plan Policy (CoPP)

[Doug Hanks]

This should walk you through most of your questions:

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

Doug





On 8/22/12 8:35 PM, Md. Jahangir Hossain jrjahan...@yahoo.com wrote:

Dear all friend:

Wishes all are fine.

I quit new in juniper OS platform . i need some information about juniper
Control Plan Policy (CoPP). i read  the RFC 6192 of  Protect Router
Control Plane which is:


http://tools.ietf.org/html/rfc6192#appendix-A.2



After reading the RFC 6192 i have a  little query as like,In cisco router
we put input policy on control plan.

as like;

control-plane service-policy input COPPBut in Juniper router we put input
policy into loopback interface according to this RFC .

Here this is:

interfaces { lo0 { unit 0 { family inet { filter input
protect-router-control-plane; }Based on my question is, how
juniper router loopback interface control all router control plan ? or i
need to put this input filter policy individually on different
interfaces as like:


interfaces{ em0 { unit 0 { family inet { filter input
protect-router-control-plane; }

interfaces { em1 { unit 0 { family inet { filter input
protect-router-control-plane; }
it would be nice for me can anyone please confirm me about this
configuration .








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


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

[j-nsp] BAJUG2

[Doug Hanks]

It's time for the Bay Area Juniper Users Group again.  October 16th 5.30pm.

Sign up for free at http://bajug.eventbrite.com


Thanks,
Doug


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

Re: [j-nsp] BAJUG2

[Doug Hanks]

Should be a good turn out.  For those of you interested and thinking about
scheduling some other business in Sunnyvale so that you can attend, we had
about 130 members for the first BAJUG meeting.

Thanks,
Doug


On 8/10/12 11:11 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote:

On 8/10/2012 2:00 PM, Doug Hanks wrote:
 It's time for the Bay Area Juniper Users Group again.  October 16th
5.30pm.

 Sign up for free at http://bajug.eventbrite.com

Kudos Doug, really good stuff... maybe I'll have to schedule some
training related travel to Sunnyvale so I can attend.

Thanks for setting this up.

-- 
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI
Technical Trainer, Juniper Networks

Follow us on Twitter @JuniperEducate


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

Re: [j-nsp] ASR9001 vs MX80

[Doug Hanks]

Thanks to couple of people pinged me off-list; I accidentally switched
around the MX80.  The MICs are installed where the switch fabric would
have been and the 4x10G are where the MICs would have been.

You essentially get 4x10GE ports for free on the MX80 because there's no
switch fabric and you get the full bandwidth of the Trio chipset on the
MX5, MX10, and MX40; the only restrictions are which ports you can use.



On 8/8/12 4:31 PM, Doug Hanks dha...@juniper.net wrote:

There was no technical reason behind the name of the MX5, MX10 or MX40;
was just a marketing thing.

Technically the MX5, MX10, MX40 or MX80 doesn't even have a switch
fabric.  Everything is done on a single Trio chipset.  Typically the
switch fabric would be connected into the Trio chipset as well, but since
there's no switch fabric on the MX5, MX10, MX40 or MX80 Juniper decided
to plug 4x10GE XFPs where the switch fabric would have connected instead.

Please keep in mind that the *only* restriction on the MX5, MX10 and MX40
are how many ports you can use.  The bandwidth, RIB, FIB, etc have the
exact same scaling numbers as the full blown MX80.


From: Tomasz Mikołajek tmikola...@gmail.commailto:tmikola...@gmail.com
Date: Wednesday, August 8, 2012 9:36 AM
To: Xu Hu jstuxuhu0...@gmail.commailto:jstuxuhu0...@gmail.com
Cc: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net,
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] ASR9001 vs MX80

Hello.
Yes and no. Yes, but befor using Trio Chipset, No because now for example
MX480 system capacity is 1.92 Tbps. If I am wrong, please correct me.

2012/8/8 Xu Hu jstuxuhu0...@gmail.commailto:jstuxuhu0...@gmail.com
Is any reason juniper choose the 5 for mx5, 40 for mx40, 480 for mx480?
The number is for backplane bandwidth?

Thanks and regards,
Xu Hu

On 8 Aug, 2012, at 5:30, Doug Hanks
dha...@juniper.netmailto:dha...@juniper.net wrote:

 Please note there's also the MX5 through MX40 that can be upgraded via a
 license to a full MX80 as well.


 On 8/7/12 1:56 AM, Tima Maryin
timamar...@mail.rumailto:timamar...@mail.ru wrote:

 Hi,

 have a look at:
 https://puck.nether.net/pipermail/juniper-nsp/2012-May/023303.html


 and the whole thread:
 https://puck.nether.net/pipermail/juniper-nsp/2012-April/023068.html


 They are about mx480 vs ASR9006, but most of stuff still applies.



 On 07.08.2012 10:22, William Jackson wrote:
 Hi

 Having used the MX80 in a previous position and now being prompted to
 look at the ASR 9001, I was wondering if any people have operational
 experience with the ASR9001 platform?
 Or any thoughts on comparison.

 These will be used for IPv4/IPv6 eBGP transit and for MPLS L2VPN/VPLS
 drop offs, thus all the VLAN tagging, rewriting shenanigans!!

 thanks

 ___
 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.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] ASR9001 vs MX80

[Doug Hanks]

There was no technical reason behind the name of the MX5, MX10 or MX40; was 
just a marketing thing.

Technically the MX5, MX10, MX40 or MX80 doesn't even have a switch fabric.  
Everything is done on a single Trio chipset.  Typically the switch fabric would 
be connected into the Trio chipset as well, but since there's no switch fabric 
on the MX5, MX10, MX40 or MX80 Juniper decided to plug 4x10GE XFPs where the 
switch fabric would have connected instead.

Please keep in mind that the *only* restriction on the MX5, MX10 and MX40 are 
how many ports you can use.  The bandwidth, RIB, FIB, etc have the exact same 
scaling numbers as the full blown MX80.


From: Tomasz Mikołajek tmikola...@gmail.commailto:tmikola...@gmail.com
Date: Wednesday, August 8, 2012 9:36 AM
To: Xu Hu jstuxuhu0...@gmail.commailto:jstuxuhu0...@gmail.com
Cc: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] ASR9001 vs MX80

Hello.
Yes and no. Yes, but befor using Trio Chipset, No because now for example MX480 
system capacity is 1.92 Tbps. If I am wrong, please correct me.

2012/8/8 Xu Hu jstuxuhu0...@gmail.commailto:jstuxuhu0...@gmail.com
Is any reason juniper choose the 5 for mx5, 40 for mx40, 480 for mx480? The 
number is for backplane bandwidth?

Thanks and regards,
Xu Hu

On 8 Aug, 2012, at 5:30, Doug Hanks 
dha...@juniper.netmailto:dha...@juniper.net wrote:

 Please note there's also the MX5 through MX40 that can be upgraded via a
 license to a full MX80 as well.


 On 8/7/12 1:56 AM, Tima Maryin 
 timamar...@mail.rumailto:timamar...@mail.ru wrote:

 Hi,

 have a look at:
 https://puck.nether.net/pipermail/juniper-nsp/2012-May/023303.html


 and the whole thread:
 https://puck.nether.net/pipermail/juniper-nsp/2012-April/023068.html


 They are about mx480 vs ASR9006, but most of stuff still applies.



 On 07.08.2012 10:22, William Jackson wrote:
 Hi

 Having used the MX80 in a previous position and now being prompted to
 look at the ASR 9001, I was wondering if any people have operational
 experience with the ASR9001 platform?
 Or any thoughts on comparison.

 These will be used for IPv4/IPv6 eBGP transit and for MPLS L2VPN/VPLS
 drop offs, thus all the VLAN tagging, rewriting shenanigans!!

 thanks

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

Re: [j-nsp] ASR9001 vs MX80

[Doug Hanks]

Please note there's also the MX5 through MX40 that can be upgraded via a
license to a full MX80 as well.


On 8/7/12 1:56 AM, Tima Maryin timamar...@mail.ru wrote:

Hi,

have a look at:
https://puck.nether.net/pipermail/juniper-nsp/2012-May/023303.html


and the whole thread:
https://puck.nether.net/pipermail/juniper-nsp/2012-April/023068.html


They are about mx480 vs ASR9006, but most of stuff still applies.



On 07.08.2012 10:22, William Jackson wrote:
 Hi

 Having used the MX80 in a previous position and now being prompted to
look at the ASR 9001, I was wondering if any people have operational
experience with the ASR9001 platform?
 Or any thoughts on comparison.

 These will be used for IPv4/IPv6 eBGP transit and for MPLS L2VPN/VPLS
drop offs, thus all the VLAN tagging, rewriting shenanigans!!

 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] Why is this term working?

[Doug Hanks]

Action modifiers such as count, loss-priority, and forwarding-class
implicitly imply a terminating action of accept.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Solutions Architect ­ EABU
Juniper Networks


On 7/22/12 10:34 AM, John Neiberger jneiber...@gmail.com wrote:

Forgive my Juniper noobiness once again. We have the following term in
a ingress firewall filter for marking:

term netmgmt {
then {
count fec-cs2;
loss-priority high;
forwarding-class MNGMT;

It seems to be working, but I don't know why. If there is no accept,
shouldn't it be dropping the traffic? I know the default action is
accept, but once we use a then statement, don't we have to specify
the accept/reject/discard action? I'm wondering if the
forwarding-class statement has an implied accept or something like
that. I really have no idea.

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


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

[j-nsp] Real-world deployment scenarios for cloud services

[Doug Hanks]

We're looking for people that work directly with wireline
companies that have a large/medium POP presence and offer network services
to end-users such as:

* Cloud services
* Internet services

We're specifically interested in cloud services and the different
deployment scenarios to deliver network services to end-users.  For
example providing cloud services on top of an existing managed MPLS
network service.

I'm looking to capture real-world designs that our customers are using
today.
Perhaps the cloud services can be accessed by the end-user via
a private /24 that's routable within the end-user's L3VPN from the
provider or it's simply a routed VLAN ID on the same wire as the managed
MPLS service.  These real-world deployment scenarios will begin driving
how we implement features moving forward.

Right now I'm focusing on distributed data center architecture.  This is
defined as many different data centers such as POPs that are one-hop away
from end users.

I'll focus on centralized data center from end-users architecture later
down
the road.  This is defined as large, but fewer data centers that primarily
offer network services to customers over the Internet.

I'm looking for the following information:
* What type of cloud services are you offering?
* How is it being delivered to the end-users?
* How do the end-users access it?  Are there any prerequisites such as the
end-user must already purchase managed MPLS.
* A topology of the networks that are relevant to the cloud core,
aggregation, access, and edge.
* Relevant router configurations if possible.  What we're trying to
collect is how are the devices connected, what protocols are being used,
and how is traffic being routed, filtered, and isolated.  That's all.
* Any type of scaling information.  How many end-users per router, VRF,
interface, or any other measurement.


Obviously there are many different methods to do the same thing and
this is what I'm looking to capture.  The goal is to aggregate the
solutions and come up with the most common methods as seen in the field.

If you are someone that works with companies who have distributed
data centers (think traditional wireline service providers) and offers
network services, can you please unicast me?

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Solutions Architect
Juniper Networks






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

Re: [j-nsp] Multi-Chassis AE

[Doug Hanks]

Works just fine on any MPC line card.


On 7/18/12 7:53 PM, Giuliano Medalha giuli...@wztech.com.br wrote:

People,

Does anyone on list has some experience in running multichassis LAG using
the following interface ?

MPC-3D-16XGE-SFPP

This interface has some limitations like LAN-PHY only.

Is it possible to configure virtual chassis with it ?

After configuring virtual chassis it is possible to configure MC AE with
ports in different chassis ?

Thanks a lot,

Giuliano


Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 8112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/
___
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] Issue with MPLS VPN when using mixed LDP and RSVP Backbone !

[Doug Hanks]

Traceoptions enabled under BGP will tell you exactly what's happening to
the prefix when being received.



On 7/11/12 9:19 AM, vaibhava varma svaibh...@gmail.com wrote:

Hi Diogo

Yes the RR Config is fine and the BGP neighbours are negotiated for
inet-vpn. RT I did verify earlier and was correct.

Unfortuantely I do not have the access right now but I will surely get
you the configs and outputs tomorrow morning.

COming back to the LSP between the PE and the RR, as I have mentioned
before I do see the PE1 Lo0 in the inet.3 on PE4 but I do not see the
PE2/RR Lo0 in the inet.3 on PE4. How to solve this issue. I suspect
this is the issue. For this I tried to create a static deafult in
inet.3 to resolve hte PE2/RR Loopback but it did not help. Also to
mention on PE2/RR we are using RSVP only and no LDP as its not allwoed
to use it over there.

Regards
Varma

On Wed, Jul 11, 2012 at 9:45 PM, Diogo Montagner
diogo.montag...@gmail.com wrote:
 Hi,

 Based on this, I would check the bgp configuration between pe2 and
 pe4, and the RR configuration as well on PE2. Check if the inet-vpn
 family is negotiated between both neighbors. If the BGP config looks
 fine, then it points to rtarget.

 The LSP (LDP or RSVP) between PE and RR is required to activate the
 routes on RR. You can use a static def route or rib group to achieve
 the same.

 Pls share the configs and outputs.

 Other thing, check if your lo0 filter is allowing the required
 protocols. But if you have problems here, then you should identify
 them in show bgp summ, show ldp session, sh rsvp session, etc

 Regards

 On 7/12/12, vaibhava varma svaibh...@gmail.com wrote:
 Hi Diogo


 - verify the status of the routes in PE4. Are they being received by
 the BGP neighbor ? Check the protocol NH status.

 Routes are not received by BGP neighbour and I verified this show
 route receive-protcol bgp x.x.x.x(PE2/RR)

 - you need to have an LSP between the PE1 and your RR. Same for PE4
 and RR. But I am assuming this is fine because you see the routes
 being advertised to PE4 from PE2.

 Yes PE2/RR is advertising routes to PE4 and I have verified this with
 show route advertising-protcol bgp x.x.x.x(PE4)


 - on PE4, you need to have a LDP route for PE1. I think this may be
 your issue and this is why I suggested to check with the ping mpls ldp
 command.
 I have the LDP route for PE1 on PE4 and have verified it under the
 inet.3 table. I am yet to check the ping mpls ldp part and will come
 back on that.

 I am still unclear that do we really need an LSP to the RR as RR will
 not overide the NH to itself while reflection ?

 Regards
 Varma

 On Wed, Jul 11, 2012 at 9:26 PM, Diogo Montagner
 diogo.montag...@gmail.com wrote:
 Hi,

 I suggest some steps below:

 - verify the status of the routes in PE4. Are they being received by
 the BGP neighbor ? Check the protocol NH status.

 - you need to have an LSP between the PE1 and your RR. Same for PE4
 and RR. But I am assuming this is fine because you see the routes
 being advertised to PE4 from PE2.

 - on PE4, you need to have a LDP route for PE1. I think this may be
 your issue and this is why I suggested to check with the ping mpls ldp
 command.

 Thanks

 On 7/11/12, vaibhava varma svaibh...@gmail.com wrote:
 Hi Diogo

 They are not hidden and have already verified the route-target.Its
 correctly configured. Any other pointer ?

 Also while using RR do we reallly need the Loopback IP of RR used for
 BGP peering to be present in the inet.3 table of PE coz the RR just
 reflects the route and does not modifies the NH. All we should need
is
 the reachability of the remote PE Loopback IP used for BGP Peering to
 be in the inet.3 at the Local PE. Is that correct ?

 Thanks much for your help on this issue.

 Regards
 Varma

 On Wed, Jul 11, 2012 at 9:07 PM, Diogo Montagner
 diogo.montag...@gmail.com wrote:
 You need check the status of the routes in PE4. If they are hidden
it
 may be a LDP issue. If there is no hidden route then your problem
may
 be wrong route-target selection.

 Thanks

 On 7/11/12, vaibhava varma svaibh...@gmail.com wrote:
 Hi Diogo

 I have not checked that yet but what I did check was that PE2/RR is
 advertising the route via BGP to PE4 and PE4 is not accepting it.
 Right now I do not have access to the setup.

 Please suggest where can be the issue and what more to check apart
 from the one you mentioned and I will check and revert in sometime.

 Regards
 Varma

 On Wed, Jul 11, 2012 at 8:31 PM, Diogo Montagner
 diogo.montag...@gmail.com wrote:
 What happens if you do a ping mpls ldp from PE4-lo0 to PE1-lo0 ?

 On 7/11/12, vaibhava varma svaibh...@gmail.com wrote:
 Dear All

 I was testing a setup whereby I am using mix of LDP and RSVP in
the
 backbone for transporting MPLS VPN Traffic. The setup is
something
 as
 below:

 CE1--PE1--PE2/RR---PE3PE4--CE2

 Now we have a limitation that we can only run LDP between PE4 and
 PE3.
 From PE3 to PE2/RR we have RSVP. From PE3 to PE1 we have 

Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP

[Doug Hanks]

The MX implementation of VCCP uses standard 802.1Q with a vlan-id of 4094.
 I'm sure the EX is the same as well.  The maximum latency is 100ms.

Although I agree having a virtual chassis span a WAN isn't the best idea
ever.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 6/24/12 9:20 AM, Sascha Luck li...@c4inet.net wrote:

James,

On Sun, Jun 24, 2012 at 08:43:22PM +1000, James Jimenez wrote:
I am curious with a EX4200 as to the requirements of the uplink ports
when
attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP
module is unable to be used however I have been told that this does in
fact
work and the documentation may not have caught up yet?

the information I have is that the extended VC links must be optical. .

I am also curious as to the requirements of the fibre uplink ports. If we
are purchasing carrier services does it have to be a dark fibre link or
are
we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We
are hoping to VCT a number of chassis over a 30km distance.

AFAIK, VCCP uses non-standard Ethernet frames and there must not be
any L2 (and up) devices in the VC link path as these devices would drop
the 
VCCP frames.

rgds,
Sascha Luck
___
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] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

[Doug Hanks]

The static discard works just fine, but from what from I recall a simple
static route would not insert the ATOMIC_AGGREGATE into BGP.

For example to advertise 192.168.1.0/24 with ATOMIC_AGGREGATE.

set routing-options static route 192.168.1.1/32 discard (contributing
route)   
set routing-options aggregate route 192.168.1/24 as-path atomic-aggregate
(atomic aggregate)

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 6/22/12 4:26 AM, EXT - plu...@senetsy.ru plu...@senetsy.ru wrote:



 I have a /24 I want to announce, but I don't actually have it anywhere
on
 the network. I NAT some of its IP's on the SRX that has the BGP session
 with our providers.
Static discard is really the best way. Aggregate/generate routes are
also theoretically possible, but if you are not sure you really need
some sort of external dynamism, it's better to nail it down with static
‹ less chances to have your routes damped somewhere after an internal
link flap.

 I've been using static routes with the discard flag, but I don't really
 like the way the SRX handles traffic. It still creates sessions for
traffic
 destined to IP's not used anywhere (hitting the static route) and can be
 easily dos'd because of this.
I saw such a thing a couple of times and it was not because SRX handles
traffic wrongly, but due to some sort of misconfiguration. If a packet
fell under the discard route, the session would not be created
(otherwise you caught a real showstopper bug, but I don't much believe
in this, to be honest). Moreover, in order to have a session established
you also need a security policy permit.

1. Check the route where the packets actually fall under with show
security flow session session-identifier . Very likely that your
packets actually fall under a longer specific route. Say, automatically
generated for proxy-arp or something like.

2. Check the zones, from and to which the sessions are established,
which policy permits the traffic. As of what you describe, policies
should block such traffic anyway.

___
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 IGP fast convergence

[Doug Hanks]

Or just use BFD ...

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 5/29/12 4:54 AM, Mark Tinka mark.ti...@seacom.mu wrote:

On Tuesday, May 29, 2012 12:19:19 PM Wan Tajuddin Wan Hussin
wrote:

 Has anyone deploy this type of setting and successfully
 integrate with Juniper without any issue.

You'll quickly notice that many configurable timers in Cisco
are not available in Junos. However, this isn't a train-
wreck, and they inter-op fairly well.

Juniper spend more time adding fast convergence into the
code without many options, while Cisco do the same but give
you lots of knobs (good and bad thing).

Just make sure you tune your timers appropriately for your
network conditions, taking into account whether you
designing for link or node failure.

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] mapping inet-precedence to a particular queue

[Doug Hanks]

{master}[edit]
jnpr@R1-RE0# set firewall family inet filter test term 1 from precedence ?
Possible completions:
  range  Range of values
  [Open a set of values
  critical-ecp Critical/ECP
  flashFlash
  flash-override   Flash override
  immediateImmediate
  internet-control Internet control
  net-control  Network control
  priority Priority
  routine  Routine


Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks

On 5/26/12 7:30 PM, Uzi Be go...@live.com wrote:


Hi,
I have a customer who is sending traffic with inet-precedence marking and
we want to assign it to appropriates queues according to their marking.
Can someone points me to the firewall filter option that can be used to
identify packet based on the inet-precedence bits and then put that in to
the relevant queue.
like
ingress packet marked inet-precedence from customer:001 -- match
that -- put that into af queue.
By using firewall filter I want to catch the above packets and then put
them into af queue.
ThanksAndrew   
___
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] Troubleshooting output queue drops

[Doug Hanks]

This won't work for transit traffic.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks



On 5/24/12 8:01 AM, Per Granath per.gran...@gcc.com.cy wrote:

Well, this gentleman: http://mccltd.net/blog/?p=1199 has looked at that,
so:

   monitor traffic interface ge-1/0/0 no-resolve matching (ip and (ip[1]
 0xfc)  2 == 20)

would give you DSCP with AF22.



 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of John Neiberger
 Sent: Thursday, May 24, 2012 5:16 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Troubleshooting output queue drops
 
 I have a lot of spiky traffic hitting a particular queue and much of it
is being
 dropped. I want to find out exactly what that traffic is.
 I would guess that some variation of monitor traffic interface would
do the
 trick, but what is the best way to structure that if there is a lot of
traffic and I
 just want to see some examples of what is being dropped in that queue?
Is
 there a regexp that would help limit it by DSCP markings or by queue?
 
 Thanks,
 John
 ___
 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] policer

[Doug Hanks]

Policers are pretty flexible.  It really has to do with how you apply them
to the IFD and IFL.  There are options in the firewall filters and
policers to aggregate or deaggregate traffic.

If you want to police traffic per IP, there's something called a
prefix-action that will let you define various prefix lengths.  For
example you can create an individual logical policer for every /32 in a
/25 network.

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/pref
ix-action.html

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks
Twitter: @douglashanksjr


On 5/3/12 9:44 AM, Mark Jones mjo...@mnsi.net wrote:

Just looking for clarification on the policer use.  If I have a whole
subnet
of ips in say a 10 megabit policer is each ip int eh subnet limited to 10
meg or is the whole subnet limited as a total of all the ips bandwidth?

 

Mark Jones
Operations
Managed Network Systems
London Desk 519-679-5207
Windsor Desk 519-258-2333 x8417
Cell  519-521-8222

 

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


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

[j-nsp] BAJUG

[Doug Hanks]

Hey guys,

Just wanted to announce that I'm trying to put together a first Bay Area
Juniper Users Group meeting (BAJUG).  It will be held 6/7/12 in Sunnyvale.
 Because it's the first meeting I don't have a ton of user-generated
content, so I've tried to bring in some interesting keynote speakers to
talk about some interesting and relevant topics.  I have Kompella and
Beesley lined up to talk about MPLS in the Enterprise and SDN/Openflow.

Please see http://bajug.eventbrite.com/ for more details, the agenda, and
to sign up.  There's no cost and the invitation is open to anyone.  After
the keynotes we have a nice social event with beer and pizza.  I've
arranged for some of our internal experts to join in and meet people.

I hope to see you there.

http://bajug.eventbrite.com/

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks
Twitter: @douglashanksjr


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

Re: [j-nsp] mx240 vs asr 9006

[Doug Hanks]

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

Re: [j-nsp] mx240 vs asr 9006

[Doug Hanks]

The MX using Trio/MPC line cards support inline IPFIX for flow statistics.  No 
services card required.  Just have to be sure your collector supports it.

http://en.wikipedia.org/wiki/IP_Flow_Information_Export

Thank you,

--
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks

From: Serge Vautour sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca
Reply-To: Serge Vautour se...@nbnet.nb.camailto:se...@nbnet.nb.ca
Date: Tue, 24 Apr 2012 10:55:39 -0700
To: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net, 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] mx240 vs asr 9006

Note that the MX requires an MS-DPC card in order to to NetFlow v9.

Serge

From: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net
To: Peter piotr.1...@interia.plmailto:piotr.1...@interia.pl; 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Sent: Tuesday, April 24, 2012 1:41:24 PM
Subject: Re: [j-nsp] mx240 vs asr 9006

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.plmailto: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.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

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

[Doug Hanks]

The MX5 scaling is identical to the MX80.  The only difference is that the
MX5 restricts the physical port usage to MIC0.

3,000,000 IPv4 prefixes in the RIB.
1,000,000 IPv4 unicast in the FIB.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 4/23/12 2:44 AM, Saku Ytti s...@ytti.fi wrote:

On (2012-04-22 23:52 -0700), Md. Jahangir Hossain wrote:

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

This is certainly possible and will scale further, depending of course
what
other things are populated in RLDRAM. Giving exact answer might prove
difficult.
More than likely you'll find control-plane scaling to be insufficient
before you'll be bothered by RDLRAM being filled.

-- 
  ++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] MX80 MPLS config example

[Doug Hanks]

Oldie, but a goodie.  Still relevant for the MX:

http://www.juniper.net/us/en/training/certification/JNCIE_studyguide.pdf

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks
Skype:  douglashanks
925.577.4296






On 4/18/12 7:13 AM, Kevin Wormington kw...@sofnet.com wrote:

Hi,

I'm wanting to transport a layer2 VLAN via MPLS between two MX80s (Trio
based) and on PE1 the customer traffic is coming into the PE interface
as tagged traffic some of which are terminated directly to layer3 as
units on the MX80s interface.  PE2 the traffic will be untagged toward
the customer.  MPLS is not configured at all now on PE1/PE2...does
anyone have any example configs for the simplest config possible to
accomplish this?

JunOS is 10.4R9.2 on both units.

Thanks,

Kevin
___
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] Layer 2 feature on srx

[Doug Hanks]

In the context of packet-mode, the family mpls is analogous to inet.  This
is correct.

I suggest that the OP use set vlan name instead of set bridge-domain
name  Also use set interfaces vlan instead of set interfaces irb

I'm not even sure why the SRX accepted this configuration.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks



On 4/9/12 2:21 PM, Phil Mayers p.may...@imperial.ac.uk wrote:

On 04/09/2012 10:10 AM, bruno wrote:
 not need to zone . coz i set it to packet mode

Your config only shows packet-mode for family mpls. IPv4 will still be
flow mode.
___
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] Hurry Juniper vouchers 100 % off Valid for 100 days !!!!!!!!!!!!!!!!!!!!!

[Doug Hanks]

Those exams are retired anyway.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 3/25/12 7:21 AM, Jose Madrid jmadr...@gmail.com wrote:

To be clear, he is selling these and not just giving them away.

On Sun, Mar 25, 2012 at 10:05 AM, CCIE 2008 ccie...@gmail.com wrote:

 *Hi all*
 *
 *
 *If anyone interested  in  recertify your JNCIP-M, JNCIE-M or JNCIE-ER
 credential,  offering you a voucher for 100% off  Junos-based
 Professional-level (JNCIP) exam price - a $300 value! If you wish to
remain
 Juniper Networks-certified .*
 *
 *


 *Unicast me   fast   if you need  any  .*
 *
 *
 *
 *
 *Best regards*
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
It has to start somewhere, it has to start sometime.  What better place
than here? What better time than now?
___
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] Stacking cable sizes

[Doug Hanks]

The EX4200 comes with the 50CM cable.

The available cables are:

 
 
 
  EX-CBL-VCP-1M
  EX 4200, EX4500 Virtual Chassis
  Port cable 1M length

 
 
  EX-CBL-VCP-3M
  EX 4200, EX4500 Virtual Chassis
  Port cable 3M length

 
 
  EX-CBL-VCP-50CM
  EX 4200, EX4500 Virtual Chassis
  Port cable 0.5M length (Spare)

 
 
  EX-CBL-VCP-5M
  EX 4200, EX4500 Virtual Chassis
  Port cable 5M length


Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 3/15/12 10:37 AM, Keegan Holley keegan.hol...@sungard.com wrote:

The juniper website doesn't seem to have exact lengths or part numbers for
the small, medium and large stacking cables described in the
hardware
guides.  Just wondering if anyone on the list knew the length of each
cable.  I was also curious if the cable that comes with the switch is
small
or medium.

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] ISIS over GRE (1500 MTU)

[Doug Hanks]

Hello,

What you're looking for is allow-fragmentation

http://www.juniper.net/techpubs/en_US/junos11.1/topics/usage-guidelines/ser
vices-configuring-unicast-tunnels.html#configure-packet-reassembly

(although this refers to ms-dpc, the mpc/trio behaves the same)

I labbed this up to confirm:

{master}
jnpr@R1-RE0 show interfaces ae0.1 | match mtu
Protocol inet, MTU: 1500
Protocol iso, MTU: 1497
Protocol multiservice, MTU: Unlimited

{master}
jnpr@R1-RE0 show interfaces gr-2/0/0 | match mtu
  Type: GRE, Link-level type: GRE, MTU: Unlimited, Speed: 1mbps
Protocol inet, MTU: 1476
Protocol iso, MTU: 1516
  Flags: User-MTU

{master}
jnpr@R1-RE0 show configuration interfaces gr-2/0/0
unit 0 {
tunnel {
source 10.8.0.0;
destination 10.8.0.1;
allow-fragmentation;
}
family inet {
address 1.1.1.1/30;
}
family iso {
mtu 1516;
}
}

{master}
jnpr@R1-RE0 show isis adjacency
Interface System L StateHold (secs) SNPA
ae0.1 R2-RE0 2  Up   23
gr-2/0/0.0R2-RE0 2  Up   21


Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks

On 3/12/12 4:49 PM, EXT - li...@beatmixed.com li...@beatmixed.com
wrote:

Wanted to throw this out there to see if anyone else has solved this
problem before me.

I'd like to set up an IS-IS adjacency over an Internet based GRE
tunnel. The tunnel comes up fine in my tests but the IS-IS adjacency
never forms. One can probably safely presume this is due to an MTU
issue -- the 1492 PDU size for IS-IS + 24 for GRE doesn't fit in the
1500 MTU this is all riding over.

Juniper has a technical note which touches upon the issue:

http://kb.juniper.net/InfoCenter/index?page=contentid=KB7848

... so I have some hope the problem is solvable...

I'm using Trio linecards on MX platform. Technically speaking, I don't
want to enable fragmentation of my IP traffic. I'd like for path MTU
discovery to do its thing with that. Not quite sure I actually
understand (from the tech note) what I am supposed to do
configuration-wise to solve this...

Here's a rough outline of my basic config (real simple):

== R1 ==

set chassis fpc 2 pic 3 tunnel-services bandwidth 10g

set interfaces gr-2/3/0 unit 0 tunnel destination x.x.x.3
set interfaces gr-2/3/0 unit 0 tunnel source x.x.y.3
set interfaces gr-2/3/0 unit 0 family inet
set interfaces gr-2/3/0 unit 0 family iso

set protocols isis interface gr-2/3/0.0 point-to-point
set protocols isis interface gr-2/3/0.0 level 1 disable
set protocols isis interface gr-2/3/0.0 level 2 metric 1000

== R2 ==

set chassis fpc 2 pic 3 tunnel-services bandwidth 10g

set interfaces gr-2/3/0 unit 0 tunnel source x.x.y.3
set interfaces gr-2/3/0 unit 0 tunnel destination x.x.x.3
set interfaces gr-2/3/0 unit 0 family inet
set interfaces gr-2/3/0 unit 0 family iso

set protocols isis interface gr-2/3/0.0 point-to-point
set protocols isis interface gr-2/3/0.0 level 1 disable
set protocols isis interface gr-2/3/0.0 level 2 metric 1000


--

Thanks for any thoughts or ideas.

-M
___
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] Logical systems on an M7i

[Doug Hanks]

15.  Should be fine for personal use.  It really just spawns another
instance of rpd.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks



On 2/29/12 9:51 AM, Tom Storey t...@snnap.net wrote:

Hi everyone.

Can anyone provide any pointers for the maximum number of logical
systems one could expect to run on an M7i?

As I understand it, each logical system has its own batch of processes
running on the RE, so I am assuming the number is going to be some
function of how much RAM you have on it.

I am looking at using an M7i or two in a lab, with not very large
tables (basically just the topology of the lab itself), but want to
maximise the number of logical routers I can run to allow for
vast/complex topologies. Ideally I would be able to run 20 logical
systems.

There are quite a few M7i's floating around on ebay with RE-400-768's,
or even RE-400-256's (though RAM should be quite easy to upgrade.) The
maximum number of logical systems per box is supposed to be 15, but
with a RE-400-768, that gives roughly 50mb of RAM to each one,
excluding the overhead for the system itself. How much RAM is required
to run one? Can an RE-400 expand past 768mb?

RE-850-1536 would give about double the RAM for each logical system
and Im sure a decent boost in responsiveness due to faster CPU, but
are about as rare as hens teeth with a price to match.

Price is a big constraint since this will be for personal use, so
while I know the MX80 is a nice box, it is out of my reach
financially. :-)

Thanks,
Tom
___
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?

[Doug Hanks]

Just make sure you're running the right version of code.  I think
EX4500-VC is supported as of 11.1 or 11.2.  You'll also need the VC
modules in back.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 2/21/12 2: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] MTU: old style vs new style trunk configuration on MX80

[Doug Hanks]

It's as expected; you have to use vlan-tagging to add the 4 bytes to the
MTU.  It's a documentation error.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks



On 2/9/12 4:29 PM, Dawid Gajownik gajow...@gmail.com wrote:

Hi!

I've been troubleshooting today MTU issues on my new MX80 router
(actually MX5) with Junos 11.4R1.14. I have noticed that MTU of
interfaces differs if I set trunks with old-style or new-style
configuration.

Documentation 
http://www.juniper.net/techpubs/en_US/junos11.4/topics/example/layer-2-bri
dge-domain-environment-example-interfaces-and-vlans-mx-solutions.html
does not mention it, but with a interface-mode you have to manually
set MTU 4 bytes larger or add vlan-tagging option. Is this a bug in
Junos or documentation is incomplete? On EX4200 with interface-mode I
did not need to add/change anything.

Please take a closer look at ae1 interface:

root@KR-020-r1# show ae0
description ### KR-011-s1 ###;
vlan-tagging;
encapsulation extended-vlan-bridge;
aggregated-ether-options {
   lacp {
   active;
   periodic fast;
   }
}
inactive: unit 0 {
   family bridge {
   interface-mode trunk;
   vlan-id-list [ 708 206 ];
   }
}
unit 206 {
   vlan-id 206;
}
unit 708 {
   vlan-id 708;
}

[edit interfaces]
root@KR-020-r1# show ae1
description ### KR-020-s1 ###;
aggregated-ether-options {
   lacp {
   active;
   periodic fast;
   }
}
unit 0 {
   family bridge {
   interface-mode trunk;
   vlan-id-list [ 708 206 ];
   }
}

[edit interfaces]
root@KR-020-r1# show ae2
description ### KR-020-s2 ###;
mtu 1518;
aggregated-ether-options {
   lacp {
   active;
   periodic fast;
   }
}
unit 0 {
   family bridge {
   interface-mode trunk;
   vlan-id-list [ 708 206 ];
   }
}

[edit interfaces]
root@KR-020-r1# show ae3
description ### KR-020-s3 ###;
vlan-tagging;
aggregated-ether-options {
   lacp {
   active;
   periodic fast;
   }
}
unit 0 {
   family bridge {
   interface-mode trunk;
   vlan-id-list [ 708 206 ];
   }
}

[edit interfaces]
root@KR-020-r1# run show interfaces ae0 | grep MTU
 Link-level type: Extended-VLAN-VPLS, MTU: 1518, Speed: 2Gbps, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source
filtering: Disabled, Flow control: Disabled,
   Protocol bridge, MTU: 1518
   Protocol bridge, MTU: 1518
   Protocol multiservice, MTU: Unlimited

[edit interfaces]
root@KR-020-r1# run show interfaces ae1 | grep MTU
 Link-level type: Ethernet, MTU: 1514, Speed: Unspecified, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source
filtering: Disabled, Flow control: Disabled,
   Protocol bridge, MTU: 1514

[edit interfaces]
root@KR-020-r1# run show interfaces ae2 | grep MTU
 Link-level type: Ethernet, MTU: 1518, Speed: 2Gbps, BPDU Error:
None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
Disabled, Flow control: Disabled,
   Protocol bridge, MTU: 1518

[edit interfaces]
root@KR-020-r1# run show interfaces ae3 | grep MTU
 Link-level type: Ethernet, MTU: 1518, Speed: Unspecified, BPDU
Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source
filtering: Disabled, Flow control: Disabled,
   Protocol bridge, MTU: 1518
   Protocol multiservice, MTU: Unlimited

[edit interfaces]
root@KR-020-r1#

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


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

Re: [j-nsp] Junos Load Balancing Behavior

[Doug Hanks]

It's working just the like documentation says.  It's per-prefix
load-balancing.

If you want per-flow you need to modify the FIB via an export policy.

set policy-options policy-statement fib-per-flow then load-balance
per-packet 
set routing-options forwarding-table export fib-per-flow
Commit

Check your FIB again after that change.


Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 2/2/12 9:01 AM, Devin Kennedy devinkennedy...@hotmail.com wrote:

Hello:

 

I'm looking for some insight on the load balancing behavior that Junos
uses
by default.  We are certifying our Junos platform CE routers (SRX, MX10,
M7i) and not seeing what we expected given the documentation we have.

 

According to the Juniper docs and the old JNCIP study guide, OSPF will
automatically load balance if there are two equal cost routes.  And indeed
in the routing table we have default route advertised via OSPF to a CE
router which shows two next hops (one to each of two PE's).

 

juniper@SRX240-5 show route 0/0 exact

 

inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

0.0.0.0/0  *[OSPF/150] 20:45:21, metric 112, tag 13979

  to 10.7.122.1 via ge-0/0/6.0

 to 10.7.122.2 via ge-0/0/6.0

 

However in the forwarding table there is only one next-hop shown and when
testing traffic flows we don't see any load balancing by default.

 

juniper@SRX240-5 show route forwarding-table destination 0/0

Routing table: default.inet

Internet:

DestinationType RtRef Next hop   Type Index NhRef Netif

defaultuser 0ulst 262142 2

  80:71:1f:c0:3c:81  ucst   584 4
ge-0/0/6.0

defaultperm 0rjct36 4

0.0.0.0/32 perm 0dscd34 2

 

Routing table: __master.anon__.inet

Internet:

DestinationType RtRef Next hop   Type Index NhRef Netif

defaultperm 0rjct   517 1

0.0.0.0/32 perm 0dscd   515 1

 

Everything goes across the one next hop only (the one with the  in front
of
it).  We have to add an export policy to the routing-options
forwarding-table stanza to get it to work.

 

This is from the Junos documentation for OSPF for version 10.4:

 

When several equal-cost routes to a destination exist, traffic is
distributed equally among them.

 

http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/ospf-routin
g-
overview.html

 

Shouldn't the load balancing work by default as the documentation would
lead
one to believe?  Does anyone have any insight into this?  Is the
documentation incorrect and you actually are required to always add a
load-balancing export policy in order to get the desired load-balancing
behavior?

 

 

 

Best Regards,

 

Devin J Kennedy

Juniper Engineer - ATT Labs

 

 

___
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] Time-of-day based traffic conditioning

[Doug Hanks]

That's pretty cool.  Looks like there's some additional knobs as well.

{master}[edit]
jnpr@R1-RE0# set groups dhanks when time 8am to 5pm

{master}[edit]
jnpr@R1-RE0# set groups dhanks when routing-engine re0

{master}[edit]
jnpr@R1-RE0# set groups dhanks snmp community dhanks authorization
read-only 

{master}[edit]
jnpr@R1-RE0# set apply-groups dhanks

{master}[edit]
jnpr@R1-RE0# show snmp

{master}[edit]
jnpr@R1-RE0# show snmp | display inheritance
 'dhanks' was inherited from group 'dhanks'
##
community dhanks {
##
## 'read-only' was inherited from group 'dhanks'
##
authorization read-only;
}

{master}[edit]
jnpr@R1-RE0# show snmp | display inheritance when time 6pm

{master}[edit]jnpr@R1-RE0#



Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks




On 1/10/12 11:28 PM, Phil Shafer p...@juniper.net wrote:

Dale Shaw writes:
Does anyone know of a way to enforce traffic policing or shaping based on
time of day?

Beginning in 11.3, config groups have a conditional application
mechanism, so they are only applied on certain products/models or
at certain time of day ranges.

I'll admit I've never used it, but it's a generic mechanism built
into configuration groups to handle time-of-day-based configuration:

[edit]
cli# show groups tod
when {
time 02:00 to 03:00;
}
system {
host-name in-the-maint-window;
}

Annoyingly, I can find no documentation on it, but it's not hidden.
Google(junos configuration groups when) is not helpful.  A snippet
of internal documentation is appended.  If I find more, I'll post it.

I know it uses our getdate() common function, so 2am == 02:00.

Thanks,
 Phil


--
2.3.5 TIME

This identifies, when this particular config-group needs to be applied on
the
router. It takes start time and optional end time as values. If end time
is
specified, the applied config-group will be removed at the specified end
time.
This will happen everyday on the specified time. If start time is relative
time e.g, 11am and end time is not specified, end time will be taken as
EOD.
If start is absolute time, the applied configuration will remain, unless
the
config-group start time is modified.

The syntax for specificing the time:

time start-time [to end-time];

The time format is -mm-dd.hh:mm (type time).
(Relative has just hh:mm, if 12 hours clock is used, it is needed to
specify
am/pm.)

Example:

groups {
my-group-1 {
// Config-group statements
when {
time 11:00 to 15:00;
}
}
}

The config-group 'my-group-1' config statements will be applied at 11 AM
and
will be removed at 3 PM daily.
___
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] LT interfaces at MX80

[Doug Hanks]

I had no problem enabling 10g worth of tunnel-services on a 3D 20x
1GE(LAN) SFP MIC, but this was on a MX960.  In terms of losing a 10G port,
that's only true for the first generation DPC card.  With Trio/MPC that is
no longer the case and you can retain all of your revenue ports, but at
the loss of 10G in forwarding within the PFE.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 12/28/11 5:52 AM, sth...@nethelp.no sth...@nethelp.no wrote:

  On the 1G MICs there is extra capacity to handle an lt interface, so
  you can configure under chassis, assuming a 20x1G MIC in MIC slot 0:
 
  fpc 1 {
 pic 1 {
 tunnel-services {
 bandwidth 1g;
 }
 }
  }
 
 
 I understood that as MIC has enough capacity so I can also use all 20x1G
 ports on MIC simultaneously with tunneling ?

Yes.

 Can I also use all 1G ports on the MIC if I will change bandwidth to
10g ?

No. If you need 10G lt capacity you'll also need a 10G MIC, *and* for
the 10G lt interface one of the physical 10G ports will no longer be
usable.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
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] LT interfaces at MX80

[Doug Hanks]

You can actually configure 50G worth of tunnel-services on the MX80.  10g
worth on FPC0 and 40G worth on FPC1.  You need to be running Junos 10.2R4.
 All of this without losing any revenue ports, but at the cost of
over-subscribing them.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 12/28/11 3:21 PM, Doug Hanks dha...@juniper.net wrote:

I had no problem enabling 10g worth of tunnel-services on a 3D 20x
1GE(LAN) SFP MIC, but this was on a MX960.  In terms of losing a 10G port,
that's only true for the first generation DPC card.  With Trio/MPC that is
no longer the case and you can retain all of your revenue ports, but at
the loss of 10G in forwarding within the PFE.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 12/28/11 5:52 AM, sth...@nethelp.no sth...@nethelp.no wrote:

  On the 1G MICs there is extra capacity to handle an lt interface, so
  you can configure under chassis, assuming a 20x1G MIC in MIC slot 0:
 
  fpc 1 {
 pic 1 {
 tunnel-services {
 bandwidth 1g;
 }
 }
  }
 
 
 I understood that as MIC has enough capacity so I can also use all
20x1G
 ports on MIC simultaneously with tunneling ?

Yes.

 Can I also use all 1G ports on the MIC if I will change bandwidth to
10g ?

No. If you need 10G lt capacity you'll also need a 10G MIC, *and* for
the 10G lt interface one of the physical 10G ports will no longer be
usable.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
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] MX VPLS Trunk with VLAN rewriting

[Doug Hanks]

It's coming.

On 12/22/11 8:04 AM, Derick Winkworth dwinkwo...@att.net wrote:


I don't have the answer immediately for you, so I apologize.

But I wanted to chime in with a THIS IS WHAT I'M TALKING ABOUT comment.
 The MX is super flexible and has loads of features with respect to
VLANs/BRIDGING/VPLS/PBB etc, but its confusing as shit and the
documentation is not the greatest.

There really ought to be an entire book *just* about this topic.  Written
in a tutorial fashion.  Covering Q-in-Q, VPLS, PBB, VLAN tag
manipulation, bridging features, etc.  All on the MX specifically.  It
needs to cover the various encapsulation types, family bridge, etc.

The MX solution guide isn't making it happen.

Still, I heart the MX immensely.  Especially now that we are finally
seeing quality code on it...  or better quality code anyway.
 
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth/



 From: Sebastian Wiesinger juniper-...@ml.karotte.org
To: Juniper NSP juniper-nsp@puck.nether.net
Sent: Thursday, December 22, 2011 8:34 AM
Subject: [j-nsp] MX VPLS Trunk with VLAN rewriting
 
Hi,

I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.

Example:

  Site 1   VPLS   Site 2
LAN1: vl100   vl10vl200
LAN2: vl301   vl11vl201


I did the following config:

Site1:
interfaces {
  ae2 {
unit 100 {
  encapsulation vlan-vpls;
  vlan-id 100;
  input-vlan-map {
  swap;
  vlan-id 10;
  }
  output-vlan-map swap;
  }
unit 301 {
  encapsulation vlan-vpls;
  vlan-id 301;
  input-vlan-map {
  swap;
  vlan-id 11;
  }
  output-vlan-map swap;
  }
}

routing-instances {
  test-service {
  instance-type vpls;
  vlan-id all;
  interface ae2.100;
  interface ae2.301;
  vrf-target target:65000:10003;
  protocols {
  vpls {
  no-tunnel-services;
  site local-ce {
  site-identifier 1;
  interface ae2.100;
  interface ae2.301;
  }
  mac-flush {
  any-interface;
  }
  }
  }
  }
}


Site2:

interfaces {
  ae2 {
unit 200 {
  encapsulation vlan-vpls;
  vlan-id 200;
  input-vlan-map {
  swap;
  vlan-id 10;
  }
  output-vlan-map swap;
  }
unit 201 {
  encapsulation vlan-vpls;
  vlan-id 201;
  input-vlan-map {
  swap;
  vlan-id 11;
  }
  output-vlan-map swap;
  }
}

routing-instances {
  test-service {
  instance-type vpls;
  vlan-id all;
  interface ae2.200;
  interface ae2.201;
  vrf-target target:65000:10003;
  protocols {
  vpls {
  no-tunnel-services;
  site local-ce {
  site-identifier 2;
  interface ae2.200;
  interface ae2.201;
  }
  mac-flush {
  any-interface;
  }
  }
  }
  }
}


When I try to commit this config I get an error:

[edit routing-instances test-service interface]
  'ae2.100'
interface with input/output vlan-maps cannot be added to a
routing-instance with a vlan-id/vlan-tags configured

JunOS version is 11.2R4

When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.

Any idea what to do? Our Juniper consultant said it would be possible
to do this.

Regards

Sebastian

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


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

Re: [j-nsp] DA rejects

[Doug Hanks]

CDP shows up as policed discards.


On 12/18/11 1:23 PM, Richard A Steenbergen r...@e-gerbil.net wrote:

On Thu, Dec 15, 2011 at 02:11:18PM -0500, randy.tay...@bell.ca wrote:
 I have seen this before facing Cisco device running CDP.  Maybe you
 have something that is running on your box that it does not
 understand.

DA Rejects are when your router receive receives a packet that is
destined for a MAC address that isn't it... This is normal/expected
behavior in small doses, since even on a switched network the unknown
unicast flooding stage of MAC learning will result in a few packets
being sent to ports that weren't actually the correct destinations. If
the router was an ordinary host these would be the type of packets you
would need to turn on promiscuous mode to see.

This is not to be confused with L3 Incompletes, which is what you're
probably thinking about re: CDP. This simply means a packet without a L3
header that the router doesn't know what to do with (since the Juniper
device doesn't speak CDP), and thus discards.

-- 
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] Observing error: device vlan not found

[Doug Hanks]

When using the new-style MX L2 commands, the bridge-domains do not require
you to add the interface.

However you need to use the bridge-domains knob routing-interface to
point to the irb interface.

Also on the MX you need to create interface irb.601 and not vlan.601

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks






On 11/11/11 5:01 AM, Humair Ali humair.s@gmail.com wrote:

arent you missing the interface in your bridge-domain ?

On 11 November 2011 11:46, saurabh sood saurabh...@gmail.com wrote:

 Hello Experts,

 During the configuration for vlan and vlan l3-interfaces we observed
 error: device vlan not found.

 Following is configuration which i did on MX80 (11.2R3):

 interfaces {
ge-0/0/0 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 601;
 }
 }
vlan {
unit 601 {
family inet {
no-redirects;
address 10.20.21.22/24 {
}
}
}
}
 }

 bridge-domains {
default {
description default;
domain-type bridge;
vlan-id 1;
}
vlan-601 {
domain-type bridge;
vlan-id 601;
}
 }

 we are getting:
  show interfaces vlan
 error: device vlan not found

 Please let me know if this is not supported or there is any other
reason.

 Aside, during a test with irb interfaces everything is working fine.

 Thanks in advance!!!

 Regards,

 Sunny
 ___
 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] Unfamiliar with Juniper M10 Config Files

[Doug Hanks]

show route advertising-protocol bgp neighbor IP extensive

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks



On 10/21/11 9:15 AM, Loopback EZ loopb...@ezxyz.com wrote:

I am replacing an old Cisco router with a Brocade MLX as IBGP peer to a
Juniper M10.  I am only getting 250K routes and I have NO filtering
enabled.  I know that the Juniper is receiving a full EBGP route table
but is only passing 250K to any of its internal IBGP peers including the
old Cisco.  Suspect that there is route summarization happening so it
would not overrun an old Cisco SUP module.  Where should I look for
summarization or any other possible cause in the Juniper config?


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


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

Re: [j-nsp] MX80 Questions

[Doug Hanks]

Brendan,

The MX80 can handle about 4,000,000 IPv4 prefixes in the RIB and about
1,000,000 IPv4 prefixes in the FIB.

Thank you,

-- 
Doug Hanks, JNCIE-ENT, JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks

The views expressed here are my own and do not necessarily reflect those
of Juniper Networks




On 8/25/11 9:11 AM, Brendan Regan brendan.bre...@gmail.com wrote:

Hi,

I was wondering if anyone knew how to calculate how many routes can be
taken
in on an MX80 with 2 Full EBGP peers and 1 IBGP peer?

On another note can seem to find it but does anyone know what the 1GB port
is that runs between the RE and the PFE on the MX80 is?

Thanks,
Brendan
___
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] dot1q CCC/MPLS on EX4200 series switches

[Doug Hanks]

It's probably easier to use QinQ.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Matthew S. Crocker
Sent: Sunday, July 17, 2011 7:08 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] dot1q CCC/MPLS on EX4200 series switches


Hello,

 I have a customer handing me a GigE with dot1q tags to my EX4200 switch.  I 
need to carry the GigE/dot1q over a couple other EX4200s and terminate on a 
GigE port of my MX80.   I've read through the docs for building MPLS/ccc 
circuits between the two devices. It isn't clear to me if I need to establish a 
ccc for each vlan (i.e. I will need to know the VLANs the customer is sending 
me).  Or, can I create one CCC that will catch all tags and transport them 
across my MPLS and dump them out the MX80.   I would prefer not having to know 
the VLANs my customer is sending me.
___
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] dot1q CCC/MPLS on EX4200 series switches

[Doug Hanks]

The MX probably has the best support for QinQ I've seen.

-Original Message-
From: Matthew S. Crocker [mailto:matt...@corp.crocker.com] 
Sent: Sunday, July 17, 2011 12:02 PM
To: Doug Hanks
Cc: Matthew S. Crocker; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] dot1q CCC/MPLS on EX4200 series switches


Can the MX80 handle QinQ?

Can I run QinQ for this customer and MPLS in my 10GigE core?  I don't think the 
EX 4200 can do that.

If I wanted to stay MPLS would I need to configure each vlan on the customer 
interface and map it to a unqiue CCC to the other end (EX4200-MX80  
MX80-EX4200)?


- Original Message -
 From: Doug Hanks dha...@juniper.net
 To: Matthew S. Crocker matt...@crocker.com, juniper-nsp@puck.nether.net
 Sent: Sunday, July 17, 2011 2:42:17 PM
 Subject: RE: [j-nsp] dot1q CCC/MPLS on EX4200 series switches
 
 It's probably easier to use QinQ.
 
 Doug
 
 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Matthew S.
 Crocker
 Sent: Sunday, July 17, 2011 7:08 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] dot1q CCC/MPLS on EX4200 series switches
 
 
 Hello,
 
  I have a customer handing me a GigE with dot1q tags to my EX4200
  switch.  I need to carry the GigE/dot1q over a couple other EX4200s
  and terminate on a GigE port of my MX80.   I've read through the
  docs for building MPLS/ccc circuits between the two devices. It
  isn't clear to me if I need to establish a ccc for each vlan (i.e.
  I will need to know the VLANs the customer is sending me).  Or, can
  I create one CCC that will catch all tags and transport them across
  my MPLS and dump them out the MX80.   I would prefer not having to
  know the VLANs my customer is sending me.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 

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

Re: [j-nsp] MX Firewall Capabilities

[Doug Hanks]

The SRX has more headroom for stateful scale and more features.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Tuesday, July 12, 2011 10:19 AM
To: OBrien, Will; sth...@nethelp.no
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX Firewall Capabilities

Nice, and if I decided I want stateful firewalling and IPS, I see I can use the 
DPC card...

Are there any pros/cons to this vs just buying a separate SRX?



-Original Message-
From: OBrien, Will [mailto:obri...@missouri.edu] 
Sent: Tuesday, July 12, 2011 1:04 PM
To: sth...@nethelp.no
Cc: Brendan Mannella; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX Firewall Capabilities

Yup. That is correct. Border filters are no problem without the ms-dpc. 

Sent from my iPad

On Jul 12, 2011, at 12:56 PM, sth...@nethelp.no sth...@nethelp.no wrote:

 Just wondering what the firewalling capabilities are with the MX series vs 
 the SRX. We just would like to have basic firewall (block all incoming 
 ports, allow specifcs). Would we need the MS-DPC to achieve this? The new 
 router will be are trio cards.
 
 As long as you don't need *state* tracking but simply basic filtering
 on ports, IP addresses etc your standard MX cards work just fine - no
 need for MS-DPC.
 
 Steinar Haug, Nethelp consulting, sth...@nethelp.no
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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

[j-nsp] Static AnyCast PIM + MSDP not working

[Doug Hanks]

Hello experts,

I'm new to multicast and I'm having some configuration issues.  I'm configuring 
a static anycast PIM with 2 RPs.  I'm using msdp between the 2 RPs.  I have a 
directly attached multicast source to the first RP, and a directly attached 
multicast receiver on the other RP.  The goal is to create a successful POC 
demonstrating static anycast RPs with multicast source and listener using 
different RPs.

I am unable to ping from SRX100-1 (ping bypass-routing ttl 10 225.0.0.1) to the 
receiver SRX100-2 (igmp static group 225.0.0.1 and sap listener 225.0.0.1).

One thing I noticed is that the RP attached to the multicast source shows the 
S,G, but it isn't using msdp to transfer the group information to the other RP.

What am I doing wrong?

Topology http://i.imgur.com/pU31g.png
J1 http://pastebin.com/8x87Jgy3
J2 http://pastebin.com/SHRKyWBB
SRX100-1 http://pastebin.com/0ug1kZcC
SRX100-2 http://pastebin.com/JL4KeGRw

Thank you,


Doug Hanks
Systems Engineer
JNCIP-M/T #1441



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

Re: [j-nsp] Static AnyCast PIM + MSDP not working

[Doug Hanks]

Stacy,

I disabled PIM on the multicast source.  I also disabled PIM on all of the 
devices management interfaces (172.16.1.0/24).  You were correct as the DR was 
being elected on the broadcast network.

It now works as expected.  Thanks a million!


Doug Hanks
Systems Engineer
JNCIP-M/T #1441

-Original Message-
From: Stacy W. Smith [mailto:st...@acm.org] 
Sent: Tuesday, June 28, 2011 3:31 PM
To: Doug Hanks
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Static AnyCast PIM + MSDP not working

Hi Doug,

Disable PIM completely on SRX100-1. That device is the source of your multicast 
traffic, but doesn't need to participate in PIM, just like a normal mcast 
source would not participate in PIM.

Your output shows that SRX100-1 has become the DR for the link between SRX100-1 
and J1. Since J1 is not the DR on the interface where it's receiving the mcast 
traffic, it's not going to forward mcast traffic and in-turn is not going to 
establish PIM/MSDP state. Disabling PIM on SRX100-1 will avoid this problem.

Also, make sure you add the interface option to the ping you are originating 
on SRX100-1 to force the traffic out the appropriate interface toward J1.

If you still have problems, please include the output of: show multicast route 
extensive, show pim rps extensive, and show pim join extensive on all the 
routers.

--Stacy


On Jun 28, 2011, at 3:50 PM, Doug Hanks wrote:

 Hello experts,
 
 I'm new to multicast and I'm having some configuration issues.  I'm 
 configuring a static anycast PIM with 2 RPs.  I'm using msdp between the 2 
 RPs.  I have a directly attached multicast source to the first RP, and a 
 directly attached multicast receiver on the other RP.  The goal is to create 
 a successful POC demonstrating static anycast RPs with multicast source and 
 listener using different RPs.
 
 I am unable to ping from SRX100-1 (ping bypass-routing ttl 10 225.0.0.1) to 
 the receiver SRX100-2 (igmp static group 225.0.0.1 and sap listener 
 225.0.0.1).
 
 One thing I noticed is that the RP attached to the multicast source shows the 
 S,G, but it isn't using msdp to transfer the group information to the other 
 RP.
 
 What am I doing wrong?
 
 Topology http://i.imgur.com/pU31g.png
 J1 http://pastebin.com/8x87Jgy3
 J2 http://pastebin.com/SHRKyWBB
 SRX100-1 http://pastebin.com/0ug1kZcC
 SRX100-2 http://pastebin.com/JL4KeGRw
 
 Thank you,
 
 
 Doug Hanks
 Systems Engineer
 JNCIP-M/T #1441
 
 
 
 ___
 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] Can per flow load-balancing result in TCP session drops?

[Doug Hanks]

Siva,

The MX80 is a router.  It's packet-based.  It does however have a services card 
that allows for some flow-based use cases.

On a side note, the J Series is both a flow and packet-based device.  If you 
want packet-based functionality, disable the security with delete security; 
set security forwarding-options family mpls mode packet-based  On the flipside 
the J Series has a software forwarding plane while the MX has a hardware 
forwarding plane.

Thank you,

Doug Hanks
Systems Engineer
JNCIP-M/T #1441



-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of MSusiva
Sent: Monday, June 27, 2011 8:07 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Can per flow load-balancing result in TCP session drops?

Hi experts,

Is MX80 a flow based or packet based router?

With asymmetric routing, will the TCP session ever get established. Suppose
if SYN packet goes out through one interface and the SYN+ACK is received on
another interface, will this router drop this SYN+ACK as this behavior is
seen in J series routers.

Thanks,
Siva
JNCIS-M
___
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] How does multihop eBGP work?

[Doug Hanks]

Mike,

By default ebgp sends packets with a ttl=1.  When you enable multihop you can 
override the default and set multihop 5 for example.

Thank you,

Doug Hanks
Systems Engineer
JNCIP-M/T #1441



-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mike Williams
Sent: Friday, June 24, 2011 9:33 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] How does multihop eBGP work?

Hey guys,

I've got a situation I think I need multihop bgp for (logical-systems and 
bridge-domains).
However it bugs me deeply that I don't get multihop BGP.

My biggest bugbear is if my multihop-ebgp peer tells me he know the best way 
to x.x.x.x, the packets I send towards him must be routed by intermediaries, 
will those intermediaries use their tables and hijack my packets down their 
bits of wet string through 15 other ASs and to the moon and back?

Thanks

-- 
Mike Williams
___
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] Frame-relay encapsulation across lt interfaces. still works (trio vs dpcr)?

[Doug Hanks]

You need to be on 11.1 for this feature on MX Trio.

root@P-network show version
Hostname: P-network
Model: mx80-48t
JUNOS Base OS boot [11.1R2.3]
JUNOS Base OS Software Suite [11.1R2.3]
JUNOS Kernel Software Suite [11.1R2.3]
JUNOS Crypto Software Suite [11.1R2.3]
JUNOS Packet Forwarding Engine Support (MX80) [11.1R2.3]
JUNOS Online Documentation [11.1R2.3]
JUNOS Routing Software Suite [11.1R2.3]

root@P-network show configuration logical-systems R1 interfaces lt-0/0/10 unit 
0 {
encapsulation frame-relay;
dlci 100;
peer-unit 1;
family inet {
address 1.1.1.1/30;
}
family inet6 {
address 2006::1/64;
}
}

root@P-network show configuration logical-systems R2 interfaces lt-0/0/10 unit 
1 {
encapsulation frame-relay;
dlci 100;
peer-unit 0;
family inet {
address 1.1.1.2/30;
}
family inet6 {
address 2006::2/64;
}
}

root@P-network ping 1.1.1.2 logical-system R1 PING 1.1.1.2 (1.1.1.2): 56 data 
bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=0.388 ms
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.325 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.337 ms ^C
--- 1.1.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip 
min/avg/max/stddev = 0.325/0.350/0.388/0.027 ms

root@P-network ping 2006::2 logical-system R1
PING6(56=40+8+8 bytes) 2006::1 -- 2006::2
16 bytes from 2006::2, icmp_seq=0 hlim=64 time=0.452 ms
16 bytes from 2006::2, icmp_seq=1 hlim=64 time=0.332 ms
16 bytes from 2006::2, icmp_seq=2 hlim=64 time=0.386 ms
16 bytes from 2006::2, icmp_seq=3 hlim=64 time=0.379 ms ^C
--- 2006::2 ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss round-trip 
min/avg/max/std-dev = 0.332/0.387/0.452/0.043 ms

root@P-network

Thank you,


Doug Hanks
Systems Engineer
JNCIP-M/T #1441



-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Joel Jaeggli
Sent: Wednesday, June 22, 2011 11:57 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Frame-relay encapsulation across lt interfaces. still works 
(trio vs dpcr)?

I was previously using frame-relay encapsulation to carry ipv6 traffic across 
logical tunnel interfaces in an MX.

I was doing it again recently and it doesn't seem to work on trio, either that 
or my memory is foggy.

if someone has a better way to carry ipv6 across an lt-interface these days, 
I'm all ears.

this is related to this discussion some time ago:

http://www.gossamer-threads.com/lists/nsp/juniper/23524

so here's a frame relay lt interface on a 40x1Gbe dpc

root@svo-e2-mx480-re0# run show interfaces lt-4/3/10 
Physical interface: lt-4/3/10, Enabled, Physical link is Up
 Interface index: 282, SNMP ifIndex: 689
 Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited,
 Speed: 1000mbps
 Device flags   : Present Running
 Interface flags: Point-To-Point SNMP-Traps
 Link flags : None
 Physical info  : 13
 Current address: 80:71:1f:94:8e:28, Hardware address: 80:71:1f:94:8e:28
 Last flapped   : 2011-05-08 21:48:35 UTC (6w2d 20:58 ago)
 Input rate : 0 bps (0 pps)
 Output rate: 0 bps (0 pps)

 Logical interface lt-4/3/10.0 (Index 70) (SNMP ifIndex 0) 
   Flags: Point-To-Point SNMP-Traps 0x4000 DLCI 1 Encapsulation: FR-NLPID
   Input packets : 0 
   Output packets: 0
   Protocol inet, MTU: 4470
 Flags: Sendbcast-pkt-to-re
 Addresses, Flags: Is-Preferred Is-Primary
   Destination: 172.19.0.252/31, Local: 172.19.0.252

 Logical interface lt-4/3/10.1 (Index 82) (SNMP ifIndex 0) 
   Flags: Point-To-Point SNMP-Traps 0x4000 DLCI 1 Encapsulation: FR-NLPID
   Input packets : 0 
   Output packets: 0
   Protocol inet, MTU: 4470
 Flags: Sendbcast-pkt-to-re
 Addresses, Flags: Is-Preferred Is-Primary
   Destination: 172.19.0.252/31, Local: 172.19.0.253

root@svo-e2-mx480-re0# run ping 172.19.0.252 
PING 172.19.0.252 (172.19.0.252): 56 data bytes
64 bytes from 172.19.0.252: icmp_seq=0 ttl=64 time=0.069 ms
64 bytes from 172.19.0.252: icmp_seq=1 ttl=64 time=0.039 ms
^C
--- 172.19.0.252 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.039/0.054/0.069/0.015 ms

{master}[edit]
root@svo-e2-mx480-re0# run ping 172.19.0.253
PING 172.19.0.253 (172.19.0.253): 56 data bytes
64 bytes from 172.19.0.253: icmp_seq=0 ttl=64 time=0.353 ms
64 bytes from 172.19.0.253: icmp_seq=1 ttl=64 time=0.295 ms
64 bytes from 172.19.0.253: icmp_seq=2 ttl=64 time=0.303 ms

here it is on trio:

root@svo-e2-mx480-re0# run show interfaces lt-1/3/0 
Physical interface: lt-1/3/0, Enabled, Physical link is Up
  Interface index: 290, SNMP ifIndex: 699
  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited,
  Speed: 1mbps
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps
  Link flags : None
  Physical info  : 13
  Current

Re: [j-nsp] 10G BGP EX vs MX series implementation?

[Doug Hanks]

Correa,

The EX4500 isn't going to support 3x full BGP tables.

You can take a look the MX240 if you want a single box with redundant REs, or 
use (2) MX80s fully meshed.

Thank you,


Doug Hanks
Systems Engineer
JNCIP-M/T #1441



-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Correa Adolfo
Sent: Monday, June 06, 2011 9:21 AM
To: Puck Nether (juniper-nsp@puck.nether.net)
Subject: [j-nsp] 10G BGP EX vs MX series implementation?

Hi, I want to purchase a 10G device that supports

- 4x 10G port

- 3x full BGP table (ISP) plus about 5 BGP customers

- 10x 1G port



I was attracted to buy an MX-80 with it's 4x 10G ports unblocked.



The downside of the MX80 is that it cannot be processor redundant (only from 
240 and up) .



Can a EX4500 handle the BGP part? It is cheaper and I think it can be redundant.

___
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] M120/T320/T640 pitfalls with IPv6?

[Doug Hanks]

Which IPv6 services are you talking about?

IPv6 routing is definitely done in hardware with the ASICs.

http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-
collections/config-guide-cos/id-10110806.html

-- 
Doug Hanks, JNCIP-M/T #1441
Systems Engineer
Juniper Networks





On 6/2/11 2:07 PM, Chris Cappuccio ch...@nmedia.net wrote:

Our Juniper sales rep (3rd party reseller, not Juniper direct) is telling
us that IPv6 features are in software on these older platforms, and
that if you want full speed on IPv6, you need to move to the MX platform.

Is this true?

What do I lose by running IPv6 on a M120, an M20, or a T320/T640 ?  Does
the swithcing board CPU really handle intensive features in software or
is this a buy more hardware request by the sales folks?  Or a little of
both?

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] MX80 Opinions

[Doug Hanks]

Daniel,

I have nothing but good things to say about the MX80.  It's based on the Trio 
chipset which means that the data plane is all ASIC based.  I use it personally 
for creating complex logical topologies using the logical-systems feature.  The 
MX80 is more than enough to meet your requirements below.  The only downside I 
can think of is that it doesn't have dual routing engines.  If that's a 
requirement you have to move up to the MX240 and above.

Thank you,


Doug Hanks
Systems Engineer
JNCIP-M/T #1441




-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Daniel Faubel
Sent: Thursday, June 02, 2011 4:09 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX80 Opinions

Hello all,

Could I get some of your opinions about the MX80 platform? I'm looking for 
positive and negative opinions.  Any gotchas I should know about?

I've always used the Cisco type of CLI, so there will be a learning curve 
there. The traffic volume for this application will be 10-15g/sec of v4 and v6. 
Full BGP tables of each. And there will be some MPLS needed.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX80 Opinions

[Doug Hanks]

On 6/2/11 7:06 PM, Richard A Steenbergen r...@e-gerbil.net wrote:

We actually tested the XRE200 for RR use (since it's a hell of a lot
more sane than a JCS), but they specifically lock it down so you can't
run BGP on it directly. This is the only JUNOS platform which is SMP
enabled right now, and from what I've heard the regular kernel krt isn't
thread safe, so my theory is to make it do SMP they may have had to
disable some of the normal routing operations and only make it capable
of controlling other EX chassis. I'm sure it would make a fine, if very
overpriced, Olive though. :)

The new MX REs run 64-bit Junos.

-- 
Doug Hanks, JNCIP-M/T #1441
Systems Engineer
Juniper Networks


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

Re: [j-nsp] SSH/Telnet session hanging

[Doug Hanks]

I second the MTU recommendation.

-- 
Doug Hanks, JNCIP-M/T #1441
Systems Engineer
Juniper Networks





On 5/31/11 1:37 PM, Alexander Frolkin a...@eldamar.org.uk wrote:

Hi,

 I have a MX240 router installed at a remote location. I am able to
 telnet/SSH the router but when I run a command that needs to return a
 large output (e.g. show log messages or show conf) the session hangs
 and then I have to re-establish the connection.

This sounds a lot like an MTU problem between you and the MX240 --- this
is precisely the kind of behaviour you'd expect to see.

As a temporary workaround, you can try setting the MTU on the
corresponding interface of the box you're SSHing from to something low.


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] MX80 throughput

[Doug Hanks]

Seconded.  The MX80-48T is all line-rate.  It uses ASICs/hardware on the 
forwarding plane.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Joel Jaeggli
Sent: Sunday, May 15, 2011 3:25 PM
To: Dermot Williams
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 throughput


On May 15, 2011, at 2:29 PM, Dermot Williams wrote:

 Hello list,
 
 I'm speccing out a replacement for our aging M10i platform. We're pulling 
 about 3.5Gbps in from our transit providers and sending about 0.5 out. I 
 expect to see this increase to around 10 inbound in the short-term and 
 possibly go to 20 over the next couple of years.
 
 I'm looking at the MX80 platform, specifically the model that has 48 
 electrical GigE ports baked in as opposed to taking MICs. However I've been 
 told that this version doesn't have ASICs and does all of its forwarding in 
 software.

Not sure who told you that. the mx80 has one pfe and no fabric (which it 
doesn't need because there's only one pfe), the 48t which is a fixed 
configuration box is no exception.

 Does anyone have any thoughts on the real-world performance of this box? 
 Would it suffice for the traffic levels I'm talking about?

it should be it's a step up from the m10i along virtually every dimension other 
than the ability to take wan interfaces.


 Thanks,
 
 Dermot Williams
 Imagine Communications Group Ltd.
 --
 Sent using BlackBerry
 ___
 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] In-band ssh access to Juniper EX

[Doug Hanks]

If it's in a virtual-chassis it would be vme0.

Just type show interface terse and see what's there.  Just because it isn't 
in the configuration doesn't mean it isn't there.  You just need to define it.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Masagung Nugroho
Sent: Thursday, March 24, 2011 11:29 PM
To: 'OBrien, Will'; 'Chris Kawchuk'
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] In-band ssh access to Juniper EX

Me0.0 for your management equipment

set interfaces me0 unit 0 family inet address
your-block-ip-address/subnet-mask



Best Regards,
-Masagung Nugroho-
 Network Engineer
Juniper Networks Technical Advisor
JNCIS-JPR#111921


-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of OBrien, Will
Sent: Friday, March 25, 2011 11:09 AM
To: Chris Kawchuk
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] In-band ssh access to Juniper EX

What is in the system services stanza?

On Mar 24, 2011, at 10:59 PM, Chris Kawchuk wrote:

 Should just work. Ensure me0.0 is not defined anywhere in the interfaces
{} stanza.

 i.e.:

 interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching;
}
}

 etc

vlan {
unit 0 {
family inet {
address your-management-ip-here/24;
}
}
}
 }

 routing-options {
static {
route 0.0.0.0/0 next-hop somewhere-useful-on-your-LAN;
}
 }

 vlans {
default {
l3-interface vlan.0;
}
 }

 - Chris.



 On 2011-03-25, at 4:17 AM, Henri Khou wrote:

 Hello,

 I have a Juni EX-4200 with an out-of-band management interface
configured. It works like a charm.
 Then I needed to connect to my switch through the Internet so I have
treied to connect via ssh to a l3-interface but I failed miserably.
 Is there a limitation regarding l3-interace or a configuration statement
that prevent in-band access?

 Thanks

 Henri
 ___
 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] MTU issue between juniper routers

[Doug Hanks]

Hmm. You can do it the good, old fashioned way with ping and the 
do-not-fragment bit ;)

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of meryem Z
Sent: Friday, March 25, 2011 9:59 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MTU issue between juniper routers


Hello Community,

I have the following issue with MTU between some P-PE routers:

- MTU on Ge interface is configured to 4484 on both ends of the links. but ping 
(from P to PE ) greater than 1600 bytes fails.
- I checked interfaces configuration , and also did a show interfaces to 
verify the effective mtu value used. everything is ok.
- i'm suspecting some node on the transmission path between the P and the PE 
configured with the default value of 1500 for GE , but i couldn't find any 
equivalent command to the linux tracepath on juniper routers.


Thanks and have a nice WE.


  
___
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] M7i

[Doug Hanks]

I would suggest the MX80.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of cjwstudios
Sent: Wednesday, March 23, 2011 11:50 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] M7i

Hello Juniper folks :)

I'm setting up a remote metro ethernet site (fiber in a closet) that
will have 2 x 100mb BGP transit feeds and a smattering of IGP feeds.
The traffic will be service provider transit without inspection, NAT
or other services.

Since everything is cost sensitive these days I initially planned on
implementing an ebayish 7206vxr-npe-g1.  Although I was quite happily
slinging the 7206 around 10 years ago I realized tonight that it has
been 10 years and the 7206 platform is well aged.   M7i (M7i 2AC 2FE
w/ RE400,PE-1GE-SFP) are quite common on the secondary market now and
likely more than enough to get started.  Although trunking multiple
metro FE feeds to a single GE port will be frowned upon I may consider
this as an option.

I suppose my questions are whether a base M7i config out of the box
will support this application or if there are better options out
there.  Thank you in advance.

___
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] Recommended FW for MX80

[Doug Hanks]

I don't think we give out recommended releases for MX.  I personally use 
10.4R2.6 with Trio supporting OSPF, ISIS, BGP and MPLS without major issues.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Hahues, Sven
Sent: Thursday, March 24, 2011 10:30 AM
To: 'juniper-nsp@puck.nether.net'
Subject: [j-nsp] Recommended FW for MX80

Hi everyone,

I was just wondering if someone could tell me what the recommended FW for the 
MX 80 was?  I looked on the support site, but I only see recommended releases 
for EX switches, the J series and the SRX line.

Any insight would be appreciated!

Thanks in advance,

Sven


NETWORK SERVICES WILL NEVER ASK FOR YOUR PASSWORD.  You should never give out 
your username or password for any accounts you have, including bank accounts, 
credit card accounts, and other personal or University accounts.  Network 
Services will never contact you using a return e-mail address that is not 
@fgcu.edu.  If you receive a questionable e-mail or an e-mail asking for 
passwords and logon information, DO NOT RESPOND, and please contact the Help 
Desk at 239-590-1188.

___
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] SRX650 Failover Test Issue

[Doug Hanks]

I recommend using a backup-router as well.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Walaa Abdel razzak
Sent: Wednesday, March 23, 2011 1:19 AM
To: Michael Lee; EXT - plu...@senetsy.ru
Cc: juniper-nsp
Subject: Re: [j-nsp] SRX650 Failover Test Issue

Hi Michael

It already configured in a group. Also I was trying to telnet from directly 
connected ip.

groups {
node0 {
system {
host-name FW1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 11.11.11.2/24;
}
}
}
}
}
node1 {
system {
host-name FW2;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 11.11.11.3/24;
}
}
}
}
}
}
apply-groups ${node};

BR,


-Original Message-
From: Michael Lee [mailto:fwis...@gmail.com] 
Sent: Wednesday, March 23, 2011 3:45 AM
To: Pavel Lunin
Cc: Walaa Abdel razzak; juniper-nsp
Subject: Re: [j-nsp] SRX650 Failover Test Issue

Sounds like the interface did not put into group, and should use fxp0 ip instead

Regards

-mike

On Mar 22, 2011, at 12:05, Pavel Lunin plu...@senetsy.ru wrote:

 
 While testing the failover in SRX650 cluster. I have removed the 
 control link between the primary and secondary. The secondary node 
 went to ineligible mode. The secondry FW is still accessible through 
 OoB interface. When I returned back the control link I couldn't reach 
 the FW through OoB interface ge-0/0/0. The only way to access the 
 box is through console and found the secondary firewall is in disable mode.
 Then when I rebooted the whole firewall, it worked normally. Is it 
 normal? And how to reach the secondary firewall remotely in case of 
 control link flap? I have faced the same issue when removing the fab 
 link.
 
 
 
 Looks like a routing issue. Try to check it out with show route a.b.c.d
 command, when you access the disabled box through the console port, 
 where a.b.c.d is IP address of the machine, you are trying to get 
 remote access form. Most probably it will show you something different 
 from a route pointing through fxp0. If this is the case, you need to 
 configure a backup router, which would make the disabled node (which 
 does not run rpd) to route packets to the management station through fxp0.
 
 http://www.juniper.net/techpubs/en_US/junos10.0/information-products/t
 opic-collections/config-guide-system-basics/backup-router-configuring.
 html
 
 BTW, next time you want the public to guess the solution for your 
 issue, try to be a bit more informative in providing basic troubleshooting 
 details. E.
 g. instead of just saying I couldn't reach the FW through OoB 
 interface ge-0/0/0, it would've been better to say something like 
 I checked the whole path from my machine a.b.c.d/24 to the fxp0 
 interface of the node1, which has address w.x.y.z/24 and… I see the 
 packets coming to the penultimate hop router, but the FW's fxp0 
 interface, which is the next and last hop, does [not] respond to ARP 
 requests… Than I tried to ping my machine back from the FW with ping 
 a.b.c.d interface fxp0, and got the following output… than I 
 performed a traceroute… I checked what comes to the
 fxp0 interface with monitor traffic interface fxp0 and saw…, etc.
 
 Otherwise, I'm afraid, this sort of gambling-style troubleshooting, in 
 which you ask us to help you, will not be much effective anyway. 
 Monte-Carlo is a good method but it's too slow in convergence.
 
 --
 Pavel
 ___
 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] 64-bit Junos Install Media

[Doug Hanks]

The 64-bit versions of Junos are the for the new routing engines for the MX 
series.  They're coming with 64-bit processors and SSD hard drives.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Martin T
Sent: Wednesday, March 23, 2011 4:51 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] 64-bit Junos Install Media

Has anyone tried to install for example
install-media64-10.4R3.4-export? I tried to install this on
M10i(RE-850, Intel Pentium III i686) with not much luck as I ended up
in debugging subshell:

ERROR: Package jbundle is not compatible - amd64 vs {i386}
ERROR: jbundle-10.4R3.4-export fails requirements check
Running pre-install for jbundle-10.4R3.4-export...
ERROR: Package jbundle is not compatible - amd64 vs {i386}
ERROR: jbundle-10.4R3.4-export fails pre-install
ERROR: addpackage: error during pkg_add /var/tmp/jbundle64-10.4R3.4-export.tgz
You are now in a debugging subshell (you may not see a prompt)...

It was rather expected as PIII should have no 64bit support.

Which platforms support 64bit JUNOS? Has anyone successfully installed
64bit JUNOS?


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

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

Re: [j-nsp] Tower top switch/router recommendation..

[Doug Hanks]

I hear what you're saying, but again I'm not an expert in QoS, so I can only 
offer limited guidance.  I would love to hear more feedback from the rest of 
the community.

It may be possible to use a policer with the loss-priority knob instead of 
immediately discarding the packets.  So at a high-level the policer would 
accept customer traffic if it doesn't exceed the bandwidth-limit and 
burst-size-limit (which would ensure each customer gets their CIR at all 
times).  Any traffic that exceeds the bandwidth-limit and burst-size-limit 
could be tagged with a loss-priority of high and let the Junos scheduler handle 
it at a port level.

Any QoS expert want to chime in?

Doug

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com] 
Sent: Wednesday, March 23, 2011 12:19 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

Hi Doug,
Seems like filters+policers allows you to specify bandwidth-limit
and burst-size..  

I.e. if you had a pool of 10 mbps.. you could carve it into individual
customer chunks at their... But no way to allow the customer to burst above
that bandwidth-limit to some specified higher BW, only allowed to specify
burst in terms of burst-size..

I need a way to ensure a customer gets their CIR at all times, and if
adequate extra BW available, they can burst to a higher (but limited to a
specified MIR) bandwidth..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com



-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Tuesday, March 22, 2011 6:21 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

I would have to look into it, but you should be able to set a max
bandwidth/transmit under cos then use filters + policers per customer.

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 5:49 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

Hi Doug,
Thanks for responding..

I need to be able to do something like this;

Customer BW Pool of 20 Mbps up and down
Customer A, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available
Customer B, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available..

If both customers attempt 15 Mbps at the same time, the switch should give
each 10 Mbps..

Easy to do in HTB using RATE= and CEIL= statements, but I can't figure out
how to do it in JunOS..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 5:13 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

Maybe someone else can chime in, as I'm not an expert with MIR.

Junos policers use the token bucket algorithm and allow you to configure a
bandwidth-limit and burst-size-limit.

You can create firewall filters to match traffic and apply these filters as
coarse or as granular as you need.

Here's an example of a 1m policer:

policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;

Doug

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com



-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).

CoS is pretty much the same for all Junos devices.  Take a look at the
technical documentation for the EX and CoS.

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html

[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..

I'm wondering if this is something that could be done

Re: [j-nsp] Tower top switch/router recommendation..

[Doug Hanks]

There's also a feature in Junos called prefix-action, which enforces per-prefix 
policing.  However I don't believe it's available on the EX.

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/prefix-action.html

Doug

From: EXT - plu...@senetsy.ru
Sent: Wednesday, March 23, 2011 2:43 PM
To: Peter Kranz
Cc: Doug Hanks; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Tower top switch/router recommendation..


   Seems like filters+policers allows you to specify bandwidth-limit
and burst-size..

I.e. if you had a pool of 10 mbps.. you could carve it into individual
customer chunks at their... But no way to allow the customer to burst above
that bandwidth-limit to some specified higher BW, only allowed to specify
burst in terms of burst-size..

I need a way to ensure a customer gets their CIR at all times, and if
adequate extra BW available, they can burst to a higher (but limited to a
specified MIR) bandwidth..


Peter, what you talk about looks like a policer/shaper per VLAN. If I didn't 
miss something, of course.

EX series won't help you since it only supports policers for incoming (not 
outgoing) traffic and only 8 queues (and consequently 8 different shaper 
instances) per physical port. Of course you can try to do policing on ingress, 
but you'll need to write and maintain a hell of filters to distinguish the 
customers. This means you need to know something other than a VLAN to demux 
them: e. g. their IPs, but this means you have to know it, customers can't use 
overlapping space, etc. Not flexible at all and too much of manual work.

So in order to do what you want, some sort of aggregation router is needed, 
which would support either policers or shapers per outgoing vlan. In case of 
1Gbps... well, maybe the higher J-series or SRX650 in packet mode (or even 
together with the stateful stuff, why not).

Than you can configure something like this:
http://books.google.com/books?id=EGi0zUwhB4QClpg=PA256ots=672B7l6d7Vdq=junos%20policer%20out-of-profilehl=rupg=PA256#v=onepageqf=false

Nothing personal about the book name :)

Two policers, first is for higher bw (say, 10M), which drops exceeding traffic, 
than, if it didn't, the next one (say, 5M), which somehow lowers the packets' 
priority: sets the fw-class, which is than mapped to an appropriate 
low-priority queue, sets the loss-priority, marks them as out-of-profile (AFAIR 
only supported on J/SRX but it's actually more or less the same as mapping to a 
class, which is bound to a lower-priority que,) or something else.

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

Re: [j-nsp] about 10.4R3 on EX

[Doug Hanks]

Yes the resilient dual root partition was implemented to deal with this issue 
on the EX.  I believe this is pretty similar to what the branch SRX do today.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TiM
Sent: Tuesday, March 22, 2011 1:15 PM
To: Kaj Niemi
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] about 10.4R3 on EX

On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote:
 Hi,

 sarcasm
 To whomever who decided to introduce new features in a R3 release, thanks
 ;-( Specifically installing jloader separately is highly appreciated.
 /sarcasm

You'll probably be thanking them when your switch loses power* and when
you restore it, you find your bootable filesystem isn't corrupted.

At least I'm _hoping_ that's what this 4th partition is designed to fix.

Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513

Tim

*Yes, I know you should have a working UPS etc.

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

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

Re: [j-nsp] about 10.4R3 on EX

[Doug Hanks]

Another feature of the dual root partition is that it will allow you to switch 
between software versions using request system software rollback without 
reinstalling the image.  Don't forget in production to keep both the partitions 
in sync with request system snapshot slice

You can check to see what versions are installed on each partition with show 
system snapshot media internal

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
Sent: Tuesday, March 22, 2011 2:45 PM
To: t...@muppetz.com; Kaj Niemi
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] about 10.4R3 on EX

Yes the resilient dual root partition was implemented to deal with this issue 
on the EX.  I believe this is pretty similar to what the branch SRX do today.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TiM
Sent: Tuesday, March 22, 2011 1:15 PM
To: Kaj Niemi
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] about 10.4R3 on EX

On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote:
 Hi,

 sarcasm
 To whomever who decided to introduce new features in a R3 release, thanks
 ;-( Specifically installing jloader separately is highly appreciated.
 /sarcasm

You'll probably be thanking them when your switch loses power* and when
you restore it, you find your bootable filesystem isn't corrupted.

At least I'm _hoping_ that's what this 4th partition is designed to fix.

Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513

Tim

*Yes, I know you should have a working UPS etc.

___
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] EX4200 BPDU on access port

[Doug Hanks]

All the edge knob does is transition the port directly to the FWD state.

{master:0}[edit]
dhanks@EX4500-2# run show spanning-tree interface xe-0/0/38

Spanning tree interface parameters for instance 0

InterfacePort IDDesignated  Designated PortState  Role
 port IDbridge ID  Cost
xe-0/0/38.0128:551  128:551  32768.50c58ea24540  2000  FWDROOT

{master:0}[edit]
dhanks@EX4500-2# set protocols rstp interface xe-0/0/38 edge

{master:0}[edit]
dhanks@EX4500-2# commit
configuration check succeeds commit complete

{master:0}[edit]
dhanks@EX4500-2# run show spanning-tree interface xe-0/0/38

Spanning tree interface parameters for instance 0

InterfacePort IDDesignated  Designated PortState  Role
 port IDbridge ID  Cost
xe-0/0/38.0128:551  128:551  32768.50c58ea24540  2000  FWDROOT

{master:0}[edit]
dhanks@EX4500-2#

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Pavel Dimow
Sent: Tuesday, March 22, 2011 3:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX4200 BPDU on access port

Hi,

I have strange situation where my customer receives bpdu's on his
cisco switch from my ex4200 despite the fact that I have configured my
port as access (default in JUNOS)
and as edge on rstp configuration. Is this normal or I don't have luck
with 10.3 version?
___
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] Tower top switch/router recommendation..

[Doug Hanks]

The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do this, 
although is requires an advanced license for BGP (EX-48-AFL).

CoS is pretty much the same for all Junos devices.  Take a look at the 
technical documentation for the EX and CoS.

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway-pages/ex-series/cos.html

[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..

I'm wondering if this is something that could be done with Junipers;

On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..

Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..

So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..

Possible with Juniper? Is so, what device, and what QOS rules? 

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com




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

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

Re: [j-nsp] Tower top switch/router recommendation..

[Doug Hanks]

Maybe someone else can chime in, as I'm not an expert with MIR.

Junos policers use the token bucket algorithm and allow you to configure a 
bandwidth-limit and burst-size-limit.

You can create firewall filters to match traffic and apply these filters as 
coarse or as granular as you need.

Here's an example of a 1m policer:

policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;

Doug

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com] 
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com



-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).

CoS is pretty much the same for all Junos devices.  Take a look at the
technical documentation for the EX and CoS.

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html

[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..

I'm wondering if this is something that could be done with Junipers;

On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..

Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..

So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..

Possible with Juniper? Is so, what device, and what QOS rules? 

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com




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


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

Re: [j-nsp] Tower top switch/router recommendation..

[Doug Hanks]

I would have to look into it, but you should be able to set a max 
bandwidth/transmit under cos then use filters + policers per customer.

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com] 
Sent: Tuesday, March 22, 2011 5:49 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

Hi Doug,
Thanks for responding..

I need to be able to do something like this;

Customer BW Pool of 20 Mbps up and down
Customer A, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available
Customer B, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available..

If both customers attempt 15 Mbps at the same time, the switch should give
each 10 Mbps..

Easy to do in HTB using RATE= and CEIL= statements, but I can't figure out
how to do it in JunOS..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Tuesday, March 22, 2011 5:13 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

Maybe someone else can chime in, as I'm not an expert with MIR.

Junos policers use the token bucket algorithm and allow you to configure a
bandwidth-limit and burst-size-limit.

You can create firewall filters to match traffic and apply these filters as
coarse or as granular as you need.

Here's an example of a 1m policer:

policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;

Doug

-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com



-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..

The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).

CoS is pretty much the same for all Junos devices.  Take a look at the
technical documentation for the EX and CoS.

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html

[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..

I'm wondering if this is something that could be done with Junipers;

On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..

Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..

So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..

Possible with Juniper? Is so, what device, and what QOS rules? 

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com




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



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

Re: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

[Doug Hanks]

As stated before, you can't have an aggregate interface going to two individual 
switches.

-Original Message-
From: medrees [mailto:medr...@isu.net.sa] 
Sent: Friday, March 18, 2011 10:36 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Doug, All

  Since I have 6509 but without VSS I decided to expand my links using the
same existing model which use one primary link connected to switch and
another backup link to another switch both of them in the same Ethernet
aggregate interface ae0.
 so please confirm this new setup to increase the links I will add one more
primary and one backup links and configure in both switches ether channel
ports but still from the juniper side the same ether aggregate interface
will contain FOUR physical interfaces.

Juniper R1 --- ae0  two primary interfaces -- two interfaces in one
layer-2 ether channel port Po1  Cisco SW1
Juniper R1 --- ae0  two backup interfaces  -- two interfaces in one
layer-2 ether channel port Po1  Cisco SW2

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Wednesday, March 16, 2011 11:02 AM
To: 'Doug Hanks'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Thanks Doug a lot.

-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Wednesday, March 16, 2011 9:35 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Is the Cisco switch you're connecting to a 6509 with VSS?  If so, yes you
can do that.  If not, you won't be able to.

-Original Message-
From: medrees [mailto:medr...@isu.net.sa]
Sent: Tuesday, March 15, 2011 11:31 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Doug

   Thanks for your reply, my question is that is it possible to make
aggregation in two links from juniper side and the other side is connected
to two different Layer-2 Cisco switches for load balance? currently I'm
connected this setup but one physical interface as primary and the other as
backup inside the ae0.


-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Wednesday, March 16, 2011 9:17 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

If I understand your question correctly ...

LACP requires a single signaling plane, so the remote devices need to be a
virtual-chassis, mc-lag, VSS or some other virtualization technology.

If you use a static LAG, there's no signaling at all, and the above still
applies, as the packets have to be reassembled on the remote device.  If the
remote devices truly are separate, you will just end up black holing the
traffic.  In this case just using a routing protocol.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Tuesday, March 15, 2011 11:06 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Expertise

 I'm going to create new Aggregate Ethernet for M10i router to load
balance the traffic among these interfaces and I know that juniper router
can do this aggregation even if the remote side is connected to two
different devices, so in this case I won't deploy LACP and will use the ON
mode , but I'm confused if it will work correctly and what is the operation
mechanism the router use to can force the other side devices to load share
the downstream traffic on aggregated physical interfaces.

So if anyone can help me with documentation or his experience for this task
send to me.

Thanks in advance.


___
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] Load balancing using Ethernet Aggregate interface ae0

[Doug Hanks]

I'm really not sure what you're asking.

Aggregated link protection is for a 1:1 active/backup scenario and can't have 
more than two members, and you still need to do this going to a single switch.

Doug

-Original Message-
From: medrees [mailto:medr...@isu.net.sa] 
Sent: Friday, March 18, 2011 11:11 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Already I have one aggregate and connected to two different switches one
primary and one backup

ge-0/0/0 {  to SW1
gigether-options {
802.3ad {
ae0;
primary;
}
}
}
ge-0/1/0 {   to SW2
gigether-options {
802.3ad {
ae0;
backup;
}
}
}

-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Saturday, March 19, 2011 8:57 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

As stated before, you can't have an aggregate interface going to two
individual switches.

-Original Message-
From: medrees [mailto:medr...@isu.net.sa]
Sent: Friday, March 18, 2011 10:36 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Doug, All

  Since I have 6509 but without VSS I decided to expand my links using the
same existing model which use one primary link connected to switch and
another backup link to another switch both of them in the same Ethernet
aggregate interface ae0.
 so please confirm this new setup to increase the links I will add one more
primary and one backup links and configure in both switches ether channel
ports but still from the juniper side the same ether aggregate interface
will contain FOUR physical interfaces.

Juniper R1 --- ae0  two primary interfaces -- two interfaces in one
layer-2 ether channel port Po1  Cisco SW1 Juniper R1 --- ae0  two
backup interfaces  -- two interfaces in one
layer-2 ether channel port Po1  Cisco SW2

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Wednesday, March 16, 2011 11:02 AM
To: 'Doug Hanks'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Thanks Doug a lot.

-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Wednesday, March 16, 2011 9:35 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Is the Cisco switch you're connecting to a 6509 with VSS?  If so, yes you
can do that.  If not, you won't be able to.

-Original Message-
From: medrees [mailto:medr...@isu.net.sa]
Sent: Tuesday, March 15, 2011 11:31 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Doug

   Thanks for your reply, my question is that is it possible to make
aggregation in two links from juniper side and the other side is connected
to two different Layer-2 Cisco switches for load balance? currently I'm
connected this setup but one physical interface as primary and the other as
backup inside the ae0.


-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Wednesday, March 16, 2011 9:17 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

If I understand your question correctly ...

LACP requires a single signaling plane, so the remote devices need to be a
virtual-chassis, mc-lag, VSS or some other virtualization technology.

If you use a static LAG, there's no signaling at all, and the above still
applies, as the packets have to be reassembled on the remote device.  If the
remote devices truly are separate, you will just end up black holing the
traffic.  In this case just using a routing protocol.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Tuesday, March 15, 2011 11:06 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Expertise

 I'm going to create new Aggregate Ethernet for M10i router to load
balance the traffic among these interfaces and I know that juniper router
can do this aggregation even if the remote side is connected to two
different devices, so in this case I won't deploy LACP and will use the ON
mode , but I'm confused if it will work correctly and what is the operation
mechanism the router use to can force the other side devices to load share
the downstream traffic on aggregated physical interfaces.

So if anyone can help me with documentation or his experience for this task
send to me.

Thanks in advance

Re: [j-nsp] 10.0 or 10.4?

[Doug Hanks]

You have a backup-router configured in the re1 group?

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Zugnoni
Sent: Saturday, March 19, 2011 12:21 PM
To: juniper-nsp
Cc: Richard A Steenbergen
Subject: Re: [j-nsp] 10.0 or 10.4?

After upgrading from 10.1 to 10.4R1.9 on a set of our dual-RE2000 MX960's we 
observed that the re1's fxp's were no longer IP-reachable. Console and session 
to other-route-engine both work fine, as does GRES. Same behavior on multiple 
dual-RE MXs. JTAC has confirmed the group config as OK, but hasn't been able to 
recreate the problem. I'd love to hear from anyone that has seen similar.

Paul Z

On Mar 17, 2011, at 16:52 , Keegan Holley wrote:

 Are these all 10.4R2 bugs or 10.2?
 
 
 PR588115 - Changing the forwarding-table export policy twice in a row
 quickly (while the previous change is still being evaluated) will cause
 rpd to coredump.
 
 PR581139 - Similar to above, but causes the FPC to crash too. Give it
 several minutes before you commit again following a forwarding-table
 export policy change.
 
 PR523493 - Mysterious FPC crashes
 
 PR509303 - Massive SNMP slowness and stalls, severely impacting polling
 of 10.2R3 boxes with a decent number of interfaces (the more interfaces
 the worse the situation).
 
 PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes,
 with extra checks added to prevent it in the future.
 
 PR559679 - Commit script transient change issue, which sometimes causes
 changes to not be picked up correctly unless you do a commit full.
 
 PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will
 drop to Idle following a commit and take 30+ minutes to come back up.
 
 PR554456 - Sometimes netconf connections to EX8200's will result in junk
 error messages being logged to the XML stream, corrupting the netconf
 session.
 
 PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation
 will simply stop working, requiring a hard clear of the neighbor (or
 ironically enough, sometimes just renaming the term in the policy will
 fix it :P) to restore normal evaluation.
 
 PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly,
 resulting in situations where for example ports 4 and 5 on every FPC
 will be able to receive packets but never transmit them. If you continue
 to try and transmit packets down a wedged port (such as would happen if
 the port is configured for L2), it will cause the FPC to crash.
 
 
 ___
 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] SRX policy action to inject a route in a table??

[Doug Hanks]

I'm not aware of any roadmap features that will do this, as we have an existing 
method to do this today.  It's easy enough to divert ingress traffic into a 
different routing-instance with FBF, then just apply stateful policy to it.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge
Sent: Friday, March 18, 2011 6:57 AM
To: Stefan Fouant
Cc: 'juniper-nsp'
Subject: Re: [j-nsp] SRX policy action to inject a route in a table??


On Thu, 17 Mar 2011, Stefan Fouant wrote:

 Hi Clarke, Doug's suggestion of using a firewall-filter with an action of
 then routing-instance is probably the cleanest way to do this.  We call this
 Filter-Based Forwarding or FBF in Juniper speak but this is no different
 from Policy-Based Routing (PBR) on other vendor platforms.  Firewall-filters
 (stateless) are processed before stateful services so this wouldn't be an
 action that you find under the 'security policies' stanza of the
 configuration hierarchy, but rather would be configured under
 'firewall-filters'.

Hi, Stefan,

Yes, the firewall filter idea is a good one, but I was hoping to leverage 
some of the more stateful and/or screen functions that the SRX has to 
achieve the same thing.

The event script concept is intriguing, but the challenge is how to 
trigger the event appropriately.

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] SRX 650 reth interface load balancing

[Doug Hanks]

No that isn't what I mean.  That is exactly what I am saying ;)

The per-packet knob is to allow ECMP for multiple egress interfaces.  In your 
case you have a single egress interface:  reth0.

Doug

-Original Message-
From: Walaa Abdel razzak [mailto:wala...@bmc.com.sa] 
Sent: Thursday, March 17, 2011 12:02 AM
To: Doug Hanks; Stefan Fouant; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] SRX 650 reth interface load balancing

Hi Doug

So, do you mean that there is no need to use the export policy on the
forwarding table and the traffic will be load balanced by default using
LACP? I am using this ECMP policy only for this purpose. as per my
knowledge Juniper is not load balancing the traffic by default unless
there is an explicit configured policy.

BR,


-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Wednesday, March 16, 2011 7:15 PM
To: Stefan Fouant; Walaa Abdel razzak; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] SRX 650 reth interface load balancing

Stefan is spot on regarding the testing method.  You need diverse flows.

The forwarding-table export policy is completely useless in this
scenario.  Your FIB should be showing reth0 as the Netif.  Verify that
your LACP is working with show lacp

If LACP is up, it will handle the hashing of the packets.

Doug 

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stefan Fouant
Sent: Wednesday, March 16, 2011 8:35 AM
To: 'Walaa Abdel razzak'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX 650 reth interface load balancing

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- 
 boun...@puck.nether.net] On Behalf Of Walaa Abdel razzak
 Sent: Wednesday, March 16, 2011 8:31 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] SRX 650 reth interface load balancing
 
 I tried to verify load balancing on the reth interface for SRX 650 
 connected to logical router, but I can see that SRX always use one 
 link although we have two physical links between the router and the 
 active node and one link between the router and the passive node. I am

 pinging directly from router to the FW. I need to load balance through

 the active links. The configuration is as follows:

How are you testing your load-balancing Walaa?  Because Juniper uses a
hash algorithm such that traffic matching a given set of constraints
(Source Address, Destination Address, Source Port, Dest Port, incoming
interface) will always hash to the same path.

In order to properly evaluate if the load-balancing is working properly,
you really need to simulate a large number of diverse flows.

 And the load balance policy:
 
 test@FW1# show routing-options
 forwarding-table {
 export ECMP;
 }
 test@FW1# show policy-options policy-statement ECMP term load-balance 
 {
 then {
 load-balance per-packet;
 }
 }

I already mentioned to you previously that you don't need a load-balance
policy to effect load-balancing on a LAG or RETH interface since these
types of interfaces appear to the system as a single logical interface,
other mechanisms apply.  The above configuration is completely
unnecessary.

Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC

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

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

Re: [j-nsp] SRX 650 reth interface load balancing

[Doug Hanks]

To be more specific, by default Junos will perform ECMP, but it's on a 
per-prefix basis.  For example if you have 100 prefixes with the same two 
egress points, you'll see in the RIB how the chevron goes back and forth across 
the prefixes.  If you have a single prefix or want per flow hashing, this is 
where you add the policy to the FIB to load-balance per-packet.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
Sent: Thursday, March 17, 2011 9:02 AM
To: Walaa Abdel razzak; Stefan Fouant; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX 650 reth interface load balancing

No that isn't what I mean.  That is exactly what I am saying ;)

The per-packet knob is to allow ECMP for multiple egress interfaces.  In your 
case you have a single egress interface:  reth0.

Doug

-Original Message-
From: Walaa Abdel razzak [mailto:wala...@bmc.com.sa] 
Sent: Thursday, March 17, 2011 12:02 AM
To: Doug Hanks; Stefan Fouant; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] SRX 650 reth interface load balancing

Hi Doug

So, do you mean that there is no need to use the export policy on the
forwarding table and the traffic will be load balanced by default using
LACP? I am using this ECMP policy only for this purpose. as per my
knowledge Juniper is not load balancing the traffic by default unless
there is an explicit configured policy.

BR,


-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Wednesday, March 16, 2011 7:15 PM
To: Stefan Fouant; Walaa Abdel razzak; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] SRX 650 reth interface load balancing

Stefan is spot on regarding the testing method.  You need diverse flows.

The forwarding-table export policy is completely useless in this
scenario.  Your FIB should be showing reth0 as the Netif.  Verify that
your LACP is working with show lacp

If LACP is up, it will handle the hashing of the packets.

Doug 

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stefan Fouant
Sent: Wednesday, March 16, 2011 8:35 AM
To: 'Walaa Abdel razzak'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX 650 reth interface load balancing

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- 
 boun...@puck.nether.net] On Behalf Of Walaa Abdel razzak
 Sent: Wednesday, March 16, 2011 8:31 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] SRX 650 reth interface load balancing
 
 I tried to verify load balancing on the reth interface for SRX 650 
 connected to logical router, but I can see that SRX always use one 
 link although we have two physical links between the router and the 
 active node and one link between the router and the passive node. I am

 pinging directly from router to the FW. I need to load balance through

 the active links. The configuration is as follows:

How are you testing your load-balancing Walaa?  Because Juniper uses a
hash algorithm such that traffic matching a given set of constraints
(Source Address, Destination Address, Source Port, Dest Port, incoming
interface) will always hash to the same path.

In order to properly evaluate if the load-balancing is working properly,
you really need to simulate a large number of diverse flows.

 And the load balance policy:
 
 test@FW1# show routing-options
 forwarding-table {
 export ECMP;
 }
 test@FW1# show policy-options policy-statement ECMP term load-balance 
 {
 then {
 load-balance per-packet;
 }
 }

I already mentioned to you previously that you don't need a load-balance
policy to effect load-balancing on a LAG or RETH interface since these
types of interfaces appear to the system as a single logical interface,
other mechanisms apply.  The above configuration is completely
unnecessary.

Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC

___
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] SRX policy action to inject a route in a table??

[Doug Hanks]

You can create a firewall filter and using the routing-instance knob.

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge
Sent: Thursday, March 17, 2011 3:05 PM
To: juniper-nsp
Subject: [j-nsp] SRX policy action to inject a route in a table??

The SRX policy actions (count, deny, log, permit, reject) are helpful, but 
a little limited.  I am wondering if there might be a way to enforce a 
special action such as take the ip address of the source packet and inject 
it into a routing table of some sort.

What I have in mind is some way to use the SRX to grab the IPs of 
misbehaving hosts and put the address in a RIB.  Then I can use routing 
policy to put the route into a BGP feed to a border router that would null 
route traffic to and from that IP address using tricks with Unicast 
Reverse Path Forwarding.

This would be like using the SRX has a simple honeypot to then enforce a 
host address block at the network perimeter.  Of course, there are all 
sorts of dangers and challenges involved, such as making sure you don't 
end up DOS'ing the SRX yourself, etc.  But I still wish there was a clean 
way to proactively do this.

My other option is to just log the packet to somewhere else, parse the 
log, then grab the IP of the offender and populate my BGP feed that way. 
But this could get complicated, too.

It could be a handy feature to do all of this task  on the SRX.

Anybody have any ideas on this?

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] Load balancing using Ethernet Aggregate interface ae0

[Doug Hanks]

If I understand your question correctly ...

LACP requires a single signaling plane, so the remote devices need to be a 
virtual-chassis, mc-lag, VSS or some other virtualization technology.

If you use a static LAG, there's no signaling at all, and the above still 
applies, as the packets have to be reassembled on the remote device.  If the 
remote devices truly are separate, you will just end up black holing the 
traffic.  In this case just using a routing protocol.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Tuesday, March 15, 2011 11:06 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Expertise

 I'm going to create new Aggregate Ethernet for M10i router to load
balance the traffic among these interfaces and I know that juniper router
can do this aggregation even if the remote side is connected to two
different devices, so in this case I won't deploy LACP and will use the ON
mode , but I'm confused if it will work correctly and what is the operation
mechanism the router use to can force the other side devices to load share
the downstream traffic on aggregated physical interfaces.

So if anyone can help me with documentation or his experience for this task
send to me.

Thanks in advance.


___
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] Load balancing using Ethernet Aggregate interface ae0

[Doug Hanks]

Is the Cisco switch you're connecting to a 6509 with VSS?  If so, yes you can 
do that.  If not, you won't be able to.

-Original Message-
From: medrees [mailto:medr...@isu.net.sa] 
Sent: Tuesday, March 15, 2011 11:31 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Doug

   Thanks for your reply, my question is that is it possible to make
aggregation in two links from juniper side and the other side is connected
to two different Layer-2 Cisco switches for load balance? currently I'm
connected this setup but one physical interface as primary and the other as
backup inside the ae0.


-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net] 
Sent: Wednesday, March 16, 2011 9:17 AM
To: medrees; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

If I understand your question correctly ...

LACP requires a single signaling plane, so the remote devices need to be a
virtual-chassis, mc-lag, VSS or some other virtualization technology.

If you use a static LAG, there's no signaling at all, and the above still
applies, as the packets have to be reassembled on the remote device.  If the
remote devices truly are separate, you will just end up black holing the
traffic.  In this case just using a routing protocol.

Doug

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of medrees
Sent: Tuesday, March 15, 2011 11:06 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

Hi Expertise

 I'm going to create new Aggregate Ethernet for M10i router to load
balance the traffic among these interfaces and I know that juniper router
can do this aggregation even if the remote side is connected to two
different devices, so in this case I won't deploy LACP and will use the ON
mode , but I'm confused if it will work correctly and what is the operation
mechanism the router use to can force the other side devices to load share
the downstream traffic on aggregated physical interfaces.

So if anyone can help me with documentation or his experience for this task
send to me.

Thanks in advance.


___
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