Re: [j-nsp] apply-path regex for specific interface matching

2014-02-25 Thread Michael Gehrmann
Hi Ben,

I believe this document on the juniper site is what you were looking for.

http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/junos-cli-wildcard-characters-configuration-groups-usage.html

Cheers
Mike

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben 
Dale
Sent: Wednesday, 26 February 2014 9:43 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] apply-path regex for specific interface matching

Hi all,

I'm trying to generate a prefix-list for all CE-facing interfaces on a PE 
(assume L3VPN).

As a test, I'm just trying to match all ge interfaces, but the following 
returns no match at all:

prefix-list CE-LINKS {
apply-path "interfaces ge-<*> unit <*> family inet address <*>"; }

I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I remove 
"ge-", I get all interface prefixes as expected.

I vaguely remember a post here on this a while back, but I haven't been able to 
track it down and google/Juniper docs are not providing any info.

Is anyone aware of 1) a solution, or 2) any docs that go through what regex is 
actually available in apply-path?

Thanks,

Ben

___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://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] apply-path regex for specific interface matching

2014-02-25 Thread Jason Munns
I think the ge- part needs to be inside the <>, so try 

Jason


On 26 February 2014 09:42, Ben Dale  wrote:

> Hi all,
>
> I'm trying to generate a prefix-list for all CE-facing interfaces on a PE
> (assume L3VPN).
>
> As a test, I'm just trying to match all ge interfaces, but the following
> returns no match at all:
>
> prefix-list CE-LINKS {
> apply-path "interfaces ge-<*> unit <*> family inet address <*>";
> }
>
> I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I
> remove "ge-", I get all interface prefixes as expected.
>
> I vaguely remember a post here on this a while back, but I haven't been
> able to track it down and google/Juniper docs are not providing any info.
>
> Is anyone aware of 1) a solution, or 2) any docs that go through what
> regex is actually available in apply-path?
>
> Thanks,
>
> Ben
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://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] apply-path regex for specific interface matching

2014-02-25 Thread Dave Bell
Try .

Dave
On 25 Feb 2014 22:45, "Ben Dale"  wrote:

> Hi all,
>
> I'm trying to generate a prefix-list for all CE-facing interfaces on a PE
> (assume L3VPN).
>
> As a test, I'm just trying to match all ge interfaces, but the following
> returns no match at all:
>
> prefix-list CE-LINKS {
> apply-path "interfaces ge-<*> unit <*> family inet address <*>";
> }
>
> I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I
> remove "ge-", I get all interface prefixes as expected.
>
> I vaguely remember a post here on this a while back, but I haven't been
> able to track it down and google/Juniper docs are not providing any info.
>
> Is anyone aware of 1) a solution, or 2) any docs that go through what
> regex is actually available in apply-path?
>
> Thanks,
>
> Ben
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://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] OSPF Confusion

2014-02-25 Thread Crist Clark
This may be something simple, but I've been staring at it a while and am
confused now. I have a rather simple network,

11

R1 - R2

 \   /20

  \10   /

   \   /

\ /

 \   /

10\ /20

  R3


The numbers are the OSPF metrics for each interface. The R1-R2 link is 10
Gbps. The interface metric is manually set to 1 on R1 and R2. The other two
links are both 1 Gbps media, but the R1-R3 is limited to 500 Mbps and the
R2-R3 to 100 Mbps by their respective carriers. (Well, not really. This is
a lab set up meant to simulate the real network.) I've used the 10 and 20
metrics on the interfaces as shown to tell OSPF something about that.


What I want to happen is all traffic from R3 to go to both R1 and R2 via
the R1-R3 link unless that link is down. With the costs configured as they
are, I would think it would do that, but it's not working for R3.


This is all a NSSA. R3 is distributing a default route into the area. Both
R1 and R2 are importing static routes into the area. The routing on R1 and
R2 works how I want. R2 sees R1 as the best next hop for the default and
all of R1's statics. R1 sees R3 as the default next hop and sees R2 as best
for all of R2's statics.


The problem is that R3 sees R2 as the best next hop for all of the statics
on R2. I don't understand why. The cost of the path from R3 to R2 is lowest
via R1, 11 vs. 20, right?


R3 is a EX4500/4200 chassis running 11.1R3.5. In trying to troubleshoot
this, I'm also a bit baffled by the router LSA that R3 is sending out to
the area. Here's the IP info for the links,


R1-R2:  160.33.151.85-160.33.151.86/30

R1-R3:  10.56.1.14-10.56.1.1/28

R2-R3:  10.56.1.22-10.56.1.17/29


But when I look at the LSA for itself in R3's database,


OSPF database, Area 0.0.0.1

 Type   ID   Adv Rtr   Seq  Age  Opt  Cksum
 Len

Router  *10.56.1.110.56.1.10x8030  2005  0x20 0x9786  48

  bits 0x2, link count 2

  id 10.56.1.1, data 10.56.1.1, Type Transit (2)

Topology count: 0, Default metric: 10

  id 10.56.1.17, data 10.56.1.17, Type Transit (2)

Topology count: 0, Default metric: 20

  Topology default (ID 0)

Type: Transit, Node ID: 10.56.1.17

  Metric: 20, Bidirectional

Type: Transit, Node ID: 10.56.1.1

  Metric: 10, Bidirectional

  Gen timer 00:09:48

  Aging timer 00:26:35

  Installed 00:33:25 ago, expires in 00:26:35, sent 00:33:23 ago

  Last changed 00:36:20 ago, Change count: 22, Ours

It looks like its listing itself in as its neighbors? Wha'?

The other devices' router LSAs look like I expect. BTW, the other two
routers are Palo Alto Networks firewalls.

Like I said, I'm probably missing something easy. Haven't done much OSPF in
JUNOS or tried much traffic shaping before.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] apply-path regex for specific interface matching

2014-02-25 Thread Ben Dale
Hi all,

I'm trying to generate a prefix-list for all CE-facing interfaces on a PE 
(assume L3VPN).

As a test, I'm just trying to match all ge interfaces, but the following 
returns no match at all:

prefix-list CE-LINKS {
apply-path "interfaces ge-<*> unit <*> family inet address <*>";
}

I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I remove 
"ge-", I get all interface prefixes as expected.

I vaguely remember a post here on this a while back, but I haven't been able to 
track it down and google/Juniper docs are not providing any info.

Is anyone aware of 1) a solution, or 2) any docs that go through what regex is 
actually available in apply-path?

Thanks,

Ben

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


Re: [j-nsp] VLAN's on EX4300 with 13.2X50-D15.3

2014-02-25 Thread Tim Durack
Can one run full IGP+MP-BGP VPLS/L2VPN/L3VPN on the ex4300?


On Thu, Feb 20, 2014 at 5:08 PM, Ben Dale  wrote:

>
> On 20 Feb 2014, at 6:00 pm, Per Granath  wrote:
>
> > For the mixed VC, the options are EX42+EX4550 or EX43+QFX.
> >
> > For VC, the EX42 uses VCP-cables, while the EX43 uses QSFP-DAC-cables
> (assuming you do not want to waste your 10G ports).
> >
> > EX42 and EX43 has the same price.
> > EX4550 is somewhat cheaper than QFX.
>
> A word of caution on the "same price" between EX42/43:
>
> If you want to use the EX4300 for L3 (and lets face it, that's probably
> everyone) you'll require the Enhanced Feature License for OSPFv2/3, IGMP
> v1/v2, PIM, VRF-Lite, QinQ and OAM.  EX4200 includes all this in the base
> license.
>
> Both still require the Advanced Feature License for BGP, ISIS and MPLS.
>
> If you want to install the Advanced Feature License on EX4300 though, you
> need to buy both the EFL *and* AFL.
>
> All features are still available for testing without licenses, but you get
> the nag message every minute in syslog.
>
> All that said, being able to VC up to 5 of these things together with a
> dedicated 40G between any two is pretty darn cool.
>
> Ben
>
>
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



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


[j-nsp] Policy base s2s vpn- traffic control- network behind the tunnel

2014-02-25 Thread Tomasz MikoĊ‚ajek
Hi all.
I have a question. Is there aby possiblity to control traffic in the policy
base s2s VPN  were in could configure kind of static route which points to
the network behind the tunnel? Or I have to configure route base tunnel?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Does EX4200 support changing TCP-MSS on transit packets?

2014-02-25 Thread Saku Ytti
On (2014-02-24 17:17 -0800), Yucong Sun wrote:

> nope:  at least for J-series, it will modify all packets passing through
> the device: check this
> 
> http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/session-tcp-maximum-segment-size-for-srx-series-setting-cli.html
> 
> espeically the text in the box.  It is obviously clunky, but without I'm
> stuck with a linux gateway with a iptables rule.

I'm really surprised if that actually works. Since does this mean, you cannot
effectively safely set system MSS without side-effects to transit data?
Seems like huge hammer.

I really hope that is documentation error, since over-loading configuration
statement like that seems downright dangerous.

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