date:20130701

[j-nsp] VPLS route reflection

2013-07-01 Thread James Jun

Hey all,

So, I've been trying to google for some sample configuration of BGP-signalled 
VPLS setup using route-reflectors, and having some trouble finding one.  All of 
the sample BGP-signaled examples on Juniper site are using full-mesh iBGP 
between PE's with no RR's in the middle.


A pretty simple and straight-forward iBGP topology like this, that we're all 
used to in a typical SP network:

 CE -- PE (rr client) - P (route-reflector) -- P (route-reflector ) 
- PE (rr client) -- CE


So, lacking any config examples, I've just enabled 'family l2vpn signaling;' on 
existing iBGP sessions that are using the above topology.
Unfortunately, the route-reflector / P-router does not reflect the route 
received from PE and vice versa -- it is behaving like non-RR client peer that 
wants full mesh.

When viewing bgp.l2vpn.0 RIB, routers can only see l2vpn NLRI's received from 
directly configured / meshed peer, but cannot see thru a route-reflector (i.e. 
P router cannot see NLRIs from a PE that's attached thru another P serving as 
route-reflector).  Please note that unicast inet.0 and inet6.0 RIBs are also 
carried by same iBGP session transports across the topology -- and those routes 
obviously work flawlessly using route-reflectors.


Setup looks like this on a P router:

bgp {
  group teh-core {
type internal;
family inet {
  unicast; 
}
family inet6 {
  unicast; 
}
family l2vpn {
  signaling; 
}
export mp64-ibgp-export-policy;
peer-as 64552;
neighbor 10.0.0.2 {
  description core1.lab2;
}
neighbor 10.0.0.3 {
  description core1.lab3;
}
  }

  group PE-edge-routers__RR-clients {
type internal;
family inet {
  unicast; 
}
family inet6 {
  unicast; 
}
family l2vpn {
  signaling; 
}
export mp64-ibgp-export-policy;
cluster 10.0.0.1;
peer-as 64552;
neighbor 10.0.1.1 {
  description edge1.lab1;
}
neighbor 10.0.1.2 {
  description edge2.lab1;
}
  }

}


Thanks in advance! 
james
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2200 Series

2013-07-01 Thread Klaus Groeger

You need the EFL (Enhanched Deature License) to run OSPF v1/v2 on 2200, and 
yes, it only supports four interfaces. Don't know if an aggregated IF (ae0 LAG) 
counts as one. 

Link:

http://www.juniper.net/techpubs/en_US/junos11.4/Tonics/concept/ex-series-software-licenses-overview.html

Regards

      Klaus

—
Sent from Mailbox for iPhone

On Mo., Jul 1, 2013 at 16:50, Paulhamus, Jon 
mailto:jpaulha...@iu17.org";>> wrote:
Yes - it's usable with the AFL license, but I'm pretty sure on the EX2200,  it 
only allows 4 interfaces to participate in OSPF.

From: Bill Blackford [mailto:bblackf...@gmail.com]

Sent: Thursday, June 27, 2013 8:19 PM

To: Paulhamus, Jon

Cc: Doug McIntyre; juniper-nsp@puck.nether.net

Subject: Re: [j-nsp] EX2200 Series

> Any features specifically that you're curios about?

Has anyone done/used the VC feature? How stable is it? Does it function in a 
similar manner to that of the EX4200's? How do they handle the loss of a member?

These will be closet stacks, so little need for any L3 functionality. However, 
in the event I bring L3 down to the access layer, is the OSPF implementation 
usable? (my experience has been on 3200/4200's primarily). I believe I read 
something about limitations.

On Thu, Jun 27, 2013 at 4:34 PM, Paulhamus, Jon 
mailto:jpaulha...@iu17.org>> wrote:

We have well approximately 75 of the 2200's and closer to 250 of the 4200's / 
4500's either standalone or in VC. A few bugs along the way with earlier 
code - but now we've stuck with 11.4R5.7 code and all is well.  I've mixed the 
2200's with mostly Cisco, and 3com / HP and have had no issues with 
compatibility other than a few gotchas with VLAN pruning on the Cisco's that we 
easily accounted for.  For what it's worth, we also use SRX's combined with 
Cisco routers and firewalls for VPN's as well without any issues.

Any features specifically that you're curios about?

From: Doug McIntyre [mer...@geeks.org]

Sent: Thursday, June 27, 2013 6:47 PM

To: juniper-nsp@puck.nether.net

Subject: Re: [j-nsp] EX2200 Series

On Thu, Jun 27, 2013 at 03:09:16PM -0700, Bill Blackford wrote:

> I am interested in hearing any feedback about the EX2200. In particular,

> anyone who has done a recent enterprise deployment in a converged and in

> particular, a mixed vendor environment.

I've used the EX2200's, and aside from the "limited" features compared

to the rest of the EX line, they operate exactly the same, just missing

a couple things that are mentioned in the datasheets. Although they

recently (12.x) brought Virtual Chassis to it, I haven't done that yet.

As to mixed vendor, you'd have to state what protocols you are

expecting in a mixed vendor? They do STP and RSTP just fine. They

won't do cisco proprietary protocols, such as CDP or VDP. They have

standards based proprotocols that are equivilent. I've done OSPF and

BGP (still accounting for all switches have limited BGP route space)

with no issues.

Overall, I've had much less problems with the Juniper switches (aside

from some bad releases, especially on the EX4550 line) than my cisco

switches all around. I have had some wonkiness getting especially old

cisco software talking, but the problem has always been on the cisco side.

Usually upgrading the cisco to newer code solved their bugs (ie. LACP).

___

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

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

___

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

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

--

Bill Blackford

Logged into reality and abusing my sudo privileges.

___

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

https://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 AS Lookup Failures

2013-07-01 Thread david.roy

Hi

12.3 runs on several mx960 with mpc4e cards since several months without any 
issue.

Note. We don't use NSR and we use a service release that includes some fix of 
bugs found during our qualification tests in lab.

For me 12.3 is a good release, but in our config.

Envoyé depuis mon Samsung Galaxy Ace d'Orange

Gabriel Blanchard  a écrit :

Just an FYI though, we run 12.3 on MX80s and that's been fine. Anything with 
dual RE seems to be the problem.

On 2013-07-01, at 10:24 AM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

Has anyone else been brave enough to try 12.3 yet to see what the damage is? =)

From: Richard Hesse [mailto:richard.he...@weebly.com]
Sent: Friday, June 28, 2013 5:52 PM
To: Gabriel Blanchard
Cc: Drew Weaver; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Inline jflow AS Lookup Failures

Did you report the crash to Juniper? What was it related to?

-richard

On Fri, Jun 28, 2013 at 7:02 PM, Gabriel Blanchard 
mailto:g...@teksavvy.ca>> wrote:
I tried 12.3. Crashed within 24h

On 2013-06-28, at 2:59 PM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

> How much of a disaster (vs 11.4) are we guessing that 12.3R3 is going to be?
>
> From: Richard Hesse 
> [mailto:richard.he...@weebly.com]
> Sent: Friday, June 28, 2013 2:58 PM
> To: Drew Weaver
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Inline jflow AS Lookup Failures
>
> It's fixed in JunOS 12.3R3 and 13.2R1. It's in PR#820988, but that isn't 
> ready for the public yet.
>
> -richard
>
> On Fri, Jun 28, 2013 at 5:08 PM, Richard Hesse 
> mailto:richard.he...@weebly.com>>>
>  wrote:
> It's totally useless right now. I have a support case open with Juniper on 
> this. I'll post back to the list if we make any headway.
>
> -richard
>
> On Fri, Jun 28, 2013 at 9:51 AM, Drew Weaver 
> mailto:drew.wea...@thenap.com>>>
>  wrote:
> Howdy,
>
> I am wondering if anyone has figured out any way to get inline jflow to send 
> proper dstas/srcas on routers with full tables?
>
> I'm seeing a lot of these incrementing (snipped output):
>
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15775477
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15776293
> What this ends up doing in practice is sending ff ff ff ff (or 4294967295) 
> for the ASN..
>
> Which ends up looking like:
>
> [root@d6 etc]# /usr/local/bin/nfdump -r /var/netflow/nc/nfcapd.current -s 
> dstas/bytes 'router ip 192.168.25.7 and out if 555' -qN
> 2013-06-27 22:23:02.827 52026.907 any  4294967295  996(20.3) 
> 2201(14.9)   420620(17.1)0   64   191
>
> In other words, totally useless.
>
> Any tips?
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net>
> https://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

_

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

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

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

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

2013-07-01 Thread Tim Jackson

interface-switch..

set protocols connections interface-switch BLAH interface ge-4/2/0.144
set protocols connections interface-switch BLAH interface ge-5/4/2.42

Setup each of the 2 interfaces with the right encapsulation
(CCC/VLAN-CCC) and the right push/pop operations..

On Mon, Jul 1, 2013 at 3:11 AM, Sebastian Wiesinger
 wrote:
> Hello,
>
> I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
> the MX is:
>
> Take alle VLAN tagged frames on an Port (CE-facing) and switch
> them to another interface (Core-Facing). On the core-facing interface
> push VLAN 42 on the frames (Q-in-Q).
>
> When frames arrive on the core-facing IF, remove vlan tag 42 and
> switch them to the CE.
>
> I don't need mac-learning for this as this is just p2p switching.
>
> (How) is that achievable?
>
> Regards
>
> Sebastian
>
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inline jflow AS Lookup Failures

2013-07-01 Thread Gabriel Blanchard

Just an FYI though, we run 12.3 on MX80s and that's been fine. Anything with 
dual RE seems to be the problem.

On 2013-07-01, at 10:24 AM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

Has anyone else been brave enough to try 12.3 yet to see what the damage is? =)

From: Richard Hesse [mailto:richard.he...@weebly.com]
Sent: Friday, June 28, 2013 5:52 PM
To: Gabriel Blanchard
Cc: Drew Weaver; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Inline jflow AS Lookup Failures

Did you report the crash to Juniper? What was it related to?

-richard

On Fri, Jun 28, 2013 at 7:02 PM, Gabriel Blanchard 
mailto:g...@teksavvy.ca>> wrote:
I tried 12.3. Crashed within 24h

On 2013-06-28, at 2:59 PM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

> How much of a disaster (vs 11.4) are we guessing that 12.3R3 is going to be?
>
> From: Richard Hesse 
> [mailto:richard.he...@weebly.com]
> Sent: Friday, June 28, 2013 2:58 PM
> To: Drew Weaver
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Inline jflow AS Lookup Failures
>
> It's fixed in JunOS 12.3R3 and 13.2R1. It's in PR#820988, but that isn't 
> ready for the public yet.
>
> -richard
>
> On Fri, Jun 28, 2013 at 5:08 PM, Richard Hesse 
> mailto:richard.he...@weebly.com>>>
>  wrote:
> It's totally useless right now. I have a support case open with Juniper on 
> this. I'll post back to the list if we make any headway.
>
> -richard
>
> On Fri, Jun 28, 2013 at 9:51 AM, Drew Weaver 
> mailto:drew.wea...@thenap.com>>>
>  wrote:
> Howdy,
>
> I am wondering if anyone has figured out any way to get inline jflow to send 
> proper dstas/srcas on routers with full tables?
>
> I'm seeing a lot of these incrementing (snipped output):
>
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15775477
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15776293
> What this ends up doing in practice is sending ff ff ff ff (or 4294967295) 
> for the ASN..
>
> Which ends up looking like:
>
> [root@d6 etc]# /usr/local/bin/nfdump -r /var/netflow/nc/nfcapd.current -s 
> dstas/bytes 'router ip 192.168.25.7 and out if 555' -qN
> 2013-06-27 22:23:02.827 52026.907 any  4294967295  996(20.3) 
> 2201(14.9)   420620(17.1)0   64   191
>
> In other words, totally useless.
>
> Any tips?
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net>
> https://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] Can I do "dumb" Q-in-Q switching on Juniper MX?

2013-07-01 Thread Vincent De Keyzer

Hi,

that one I think I can answer - we just had to do this recently, and used
CCC (
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-mpls-applications/mpls-configuring-layer-2-switching-cross-connects-using-ccc.html
).

With the following, frames are tagged with VLAN 2001 on ge-0/1/1, and
untagged on ge-0/1/9:

interfaces {
ge-0/1/1 {
vlan-tagging;
mtu 4000;
encapsulation vlan-ccc;
unit 2001 {
encapsulation vlan-ccc;
vlan-id 2001;
}
}
ge-0/1/9 {
speed 100m;
link-mode full-duplex;
encapsulation ethernet-ccc;
gigether-options {
no-auto-negotiation;
}
unit 0 {
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 2001;
}
output-vlan-map pop;
family ccc;
}
}
protocols {
connections {
interface-switch ccc {
interface ge-0/1/1.2001;
interface ge-0/1/9.0;
}
}
}

HTH,

Vincent


On 1 July 2013 12:11, Sebastian Wiesinger wrote:

> Hello,
>
> I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
> the MX is:
>
> Take alle VLAN tagged frames on an Port (CE-facing) and switch
> them to another interface (Core-Facing). On the core-facing interface
> push VLAN 42 on the frames (Q-in-Q).
>
> When frames arrive on the core-facing IF, remove vlan tag 42 and
> switch them to the CE.
>
> I don't need mac-learning for this as this is just p2p switching.
>
> (How) is that achievable?
>
> Regards
>
> Sebastian
>
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

2013-07-01 Thread Aaron Dewell

You could do this over CCC on an MPLS core for sure (take the whole port not 
logical interfaces).  If your core is q-in-q though, you can configure your 
customer vlans as a range instead of a single number.  That potentially creates 
issues if multiple customers on the same SVLAN are using the same CVLAN id.  
However, if you use a single SVLAN per customer, then there's no issue.

I'd say it's easier to do this using CCC but YMMV.

Aaron

On Jul 1, 2013, at 4:11 AM, Sebastian Wiesinger wrote:
> Hello,
> 
> I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
> the MX is:
> 
> Take alle VLAN tagged frames on an Port (CE-facing) and switch
> them to another interface (Core-Facing). On the core-facing interface
> push VLAN 42 on the frames (Q-in-Q).
> 
> When frames arrive on the core-facing IF, remove vlan tag 42 and
> switch them to the CE.
> 
> I don't need mac-learning for this as this is just p2p switching.
> 
> (How) is that achievable?
> 
> Regards
> 
> Sebastian
> 
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
>-- Terry Pratchett, The Fifth Elephant
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Inline jflow AS Lookup Failures

2013-07-01 Thread Mark Tinka

On Monday, July 01, 2013 04:24:37 PM Drew Weaver wrote:

> Has anyone else been brave enough to try 12.3 yet to see
> what the damage is? =)

Still on 11.4 here.

The only reason I'd venture into 12.3 or 13 is if the 
hardware requires it.

We're looking to get some new Juniper kit next year, so 
maybe the code is mature by then, or the hardware I'm 
getting will live on 11.4.

Just keeps getting easier and easier :-)...

Mark.

signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inline jflow AS Lookup Failures

2013-07-01 Thread Drew Weaver

Has anyone else been brave enough to try 12.3 yet to see what the damage is? =)

From: Richard Hesse [mailto:richard.he...@weebly.com]
Sent: Friday, June 28, 2013 5:52 PM
To: Gabriel Blanchard
Cc: Drew Weaver; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Inline jflow AS Lookup Failures

Did you report the crash to Juniper? What was it related to?

-richard

On Fri, Jun 28, 2013 at 7:02 PM, Gabriel Blanchard 
mailto:g...@teksavvy.ca>> wrote:
I tried 12.3. Crashed within 24h

On 2013-06-28, at 2:59 PM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

> How much of a disaster (vs 11.4) are we guessing that 12.3R3 is going to be?
>
> From: Richard Hesse 
> [mailto:richard.he...@weebly.com]
> Sent: Friday, June 28, 2013 2:58 PM
> To: Drew Weaver
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Inline jflow AS Lookup Failures
>
> It's fixed in JunOS 12.3R3 and 13.2R1. It's in PR#820988, but that isn't 
> ready for the public yet.
>
> -richard
>
> On Fri, Jun 28, 2013 at 5:08 PM, Richard Hesse 
> mailto:richard.he...@weebly.com>>>
>  wrote:
> It's totally useless right now. I have a support case open with Juniper on 
> this. I'll post back to the list if we make any headway.
>
> -richard
>
> On Fri, Jun 28, 2013 at 9:51 AM, Drew Weaver 
> mailto:drew.wea...@thenap.com>>>
>  wrote:
> Howdy,
>
> I am wondering if anyone has figured out any way to get inline jflow to send 
> proper dstas/srcas on routers with full tables?
>
> I'm seeing a lot of these incrementing (snipped output):
>
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15775477
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15776293
> What this ends up doing in practice is sending ff ff ff ff (or 4294967295) 
> for the ASN..
>
> Which ends up looking like:
>
> [root@d6 etc]# /usr/local/bin/nfdump -r /var/netflow/nc/nfcapd.current -s 
> dstas/bytes 'router ip 192.168.25.7 and out if 555' -qN
> 2013-06-27 22:23:02.827 52026.907 any  4294967295  996(20.3) 
> 2201(14.9)   420620(17.1)0   64   191
>
> In other words, totally useless.
>
> Any tips?
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net>
> https://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] EX2200 Series

2013-07-01 Thread Paulhamus, Jon

Yes - it's usable with the AFL license, but I'm pretty sure on the EX2200,  it 
only allows 4 interfaces to participate in OSPF.

From: Bill Blackford [mailto:bblackf...@gmail.com]
Sent: Thursday, June 27, 2013 8:19 PM
To: Paulhamus, Jon
Cc: Doug McIntyre; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX2200 Series

> Any features specifically that you're curios about?
Has anyone done/used the VC feature? How stable is it? Does it function in a 
similar manner to that of the EX4200's? How do they handle the loss of a member?

These will be closet stacks, so little need for any L3 functionality. However, 
in the event I bring L3 down to the access layer, is the OSPF implementation 
usable? (my experience has been on 3200/4200's primarily). I believe I read 
something about limitations.

On Thu, Jun 27, 2013 at 4:34 PM, Paulhamus, Jon 
mailto:jpaulha...@iu17.org>> wrote:
We have well approximately 75 of the 2200's and closer to 250 of the 4200's / 
4500's either standalone or in VC. A few bugs along the way with earlier 
code - but now we've stuck with 11.4R5.7 code and all is well.  I've mixed the 
2200's with mostly Cisco, and 3com / HP and have had no issues with 
compatibility other than a few gotchas with VLAN pruning on the Cisco's that we 
easily accounted for.  For what it's worth, we also use SRX's combined with 
Cisco routers and firewalls for VPN's as well without any issues.

Any features specifically that you're curios about?

From: Doug McIntyre [mer...@geeks.org]
Sent: Thursday, June 27, 2013 6:47 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX2200 Series

On Thu, Jun 27, 2013 at 03:09:16PM -0700, Bill Blackford wrote:
> I am interested in hearing any feedback about the EX2200. In particular,
> anyone who has done a recent enterprise deployment in a converged and in
> particular, a mixed vendor environment.

I've used the EX2200's, and aside from the "limited" features compared
to the rest of the EX line, they operate exactly the same, just missing
a couple things that are mentioned in the datasheets. Although they
recently (12.x) brought Virtual Chassis to it, I haven't done that yet.

As to mixed vendor, you'd have to state what protocols you are
expecting in a mixed vendor? They do STP and RSTP just fine. They
won't do cisco proprietary protocols, such as CDP or VDP. They have
standards based proprotocols that are equivilent. I've done OSPF and
BGP (still accounting for all switches have limited BGP route space)
with no issues.

Overall, I've had much less problems with the Juniper switches (aside
from some bad releases, especially on the EX4550 line) than my cisco
switches all around. I have had some wonkiness getting especially old
cisco software talking, but the problem has always been on the cisco side.
Usually upgrading the cisco to newer code solved their bugs (ie. LACP).

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

--
Bill Blackford

Logged into reality and abusing my sudo privileges.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

2013-07-01 Thread Sebastian Wiesinger

Hello,

I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
the MX is:

Take alle VLAN tagged frames on an Port (CE-facing) and switch
them to another interface (Core-Facing). On the core-facing interface
push VLAN 42 on the frames (Q-in-Q).

When frames arrive on the core-facing IF, remove vlan tag 42 and
switch them to the CE.

I don't need mac-learning for this as this is just p2p switching.

(How) is that achievable?

Regards

Sebastian


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

Re: [j-nsp] RIB and FIB - Memory for MX with LR

2013-07-01 Thread Mark Tinka

On Saturday, June 29, 2013 12:25:09 PM Saku Ytti wrote:

> For chassis based boxes something like this[0] could
> potentially allow delaying upgrades by reducing FIB
> demand in WAN facing linecards.

For us, one of the more practical reasons of running MPLS in 
the core (a BGP-free core).

Of course, this pushes pressure out to the edge, but at 
least you aren't sweating (ab)out your core.

Mark.

signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] VPLS route reflection

Re: [j-nsp] EX2200 Series

Re: [j-nsp] Inline jflow AS Lookup Failures

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

Re: [j-nsp] Inline jflow AS Lookup Failures

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

Re: [j-nsp] Inline jflow AS Lookup Failures

Re: [j-nsp] Inline jflow AS Lookup Failures

Re: [j-nsp] EX2200 Series

[j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

Re: [j-nsp] RIB and FIB - Memory for MX with LR

12 matches

Site Navigation

Mail list logo

Footer information