Re: [j-nsp] Juniper vMX limitations

[Ben Dale]

> On 30 Jul 2015, at 11:11 pm, Chris Adams  wrote:
> 
> Once upon a time, Phil Bedard  said:
>> I’m sure they’ve had it running in VMWare, but it’s a little more difficult 
>> and you need the Enterprise Plus version of vSphere to get virtual serial 
>> ports. I’d be more comfortable running it under KVM myself.   
> 
> Just an FYI: if you are looking for a KVM-based virtualization setup
> that has more of the functionality of VMWare (not just CLI-based local
> VMs), check out oVirt .

And similarly ProxMox -  - I haven’t 
tried vMX on it yet, but it’s a pretty nice ESX replacement for general purpose 
use


> -- 
> Chris Adams 
> ___
> 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] Proper Break of MPLS RSVP Ring

[Ben Dale]

Hi Levi,

> On 17 Jul 2015, at 5:22 am, Levi Pederson  
> wrote:
> This is displaying it self in my output by not having an RSVP Neighbor
> (neighbor down hellos sent) between C&D (and therefore sending my traffic
> inefficiently 3/4 way around the ring instead of the 1/4 hop it could.
> Last bit of information is that D sees C as a neighbor but is down.  C does
> not even see D as a neighbor at all.

This sounds like an L2 issue, or perhaps a misconfiguration - all nodes should 
be RSVP neighbours in order to be able to signal LSPs across those interfaces.

Check your protocols rsvp config for the logical interfaces between D.

Use monitor traffic interface  on D to confirm that RSVP is 
being sent out of the box.

Check any control-plane filtering/firewall filters you have configured on C 
(though it seems to be receiving just fine from B).

> I'm wondering how RSVP breaks that link.  All the documentation I can find
> are focused on LSP validation/creation and not on Link Breaks to stop layer
> 2 loops (is my assumption).  If one of my intervening links goes own I
> would like to correct it and then move the break to the specified point.
> But the RSVP documentation is rather...limited to only LSPs if I am reading
> it correctly.

RSVP won’t break the link to stop loops (the LSPs will carry service labels 
which may not even be L2 services), it will simply establish the LSP across the 
best/shortest path between endpoints (based on your TE settings), and if this 
becomes unavailable (and depending on your configuration) it will simply 
re-establish over any alternate path (which it sounds like is working well).

Cheers,

Ben

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

Re: [j-nsp] Basic Implementation of VLAN/LogicalPort across MPLS

[Ben Dale]

Hi Levi,

> I've setup an MPLS ring and with your help it's running beautifully. With
> it I can easily make port congruence across the MPLS ring with few issues.
> For example send a single from one side of the MPLS ring to the other if
> the signal lands on a port directly.  I.E a physical interface.

Based on your previous email, I’m assuming your transport labels are all 
RSVP-based.

> Where I'm having trouble now is landing or starting from a logical
> interface such as a VLAN.

For an aggregate interface, make sure you have flexible-ethernet-services 
configure on the physical interface (or vlan-ccc, but if not all units are 
going to be l2circuits, then stick with flexible-ethernet-services), and then 
encapsulation vlan-ccc for all the sub-interfaces you wish to tunnel:

interfaces {
ae0 {
aggregated-ether-options {
lacp {
active;
}
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 10 {
encapsulation vlan-ccc;
vlan-id 10;
}
unit 20 {   
encapsulation vlan-ccc;
vlan-id 20;
}
}
}

To bring up an l2circuit, it’s just a simple matter of assigning and ID to the 
port, and mapping it to a remote PE:

protocols {
l2circuit {
neighbor 1.2.3.4 {<— the far-side PE loopback where you want the 
other end of the tunnel to come out
interface ae0.10 {   <— your local interface
virtual-circuit-id 10;   <— unique identifier
}
}
}
}

Cheers,

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

Re: [j-nsp] MPLS Endpoint Discussion

[Ben Dale]

> On 3 Jul 2015, at 12:25 am, Levi Pederson  
> wrote:
> 
> All,
> 
> I've created simpler MPLS ring between a total of 6 MPLS 4550s.  My
> questions what IP do I use for the Label Switched Path Endpoints. I can't
> seem to find a "best practice."
> 
> Specifically this code
> 
> Obfuscated as I'm a little to literal with my descriptions
> 
> set protocols mpls label-switched-path PE2-to-PE1 to 10.254.1.1
> set protocols mpls label-switched-path PE2-to-PE3 to 10.254.1.6
> set protocols mpls label-switched-path PE2-to-PE4 to 10.254.0.4
> 
> 
> Do I use the /30 that exists between the Legs?
> 
> Or should I use the LoopBack0 ?
> 
> My thought would be Leg itself as it creates the path.  But some documents
> state LoopBack.

Always use loopbacks - if the link goes down (or the preceding node), the 
destination of the LSP goes with it - Junos will not maintain prefixes for 
downed interfaces.  

You mention this being a ring - if you target the LSP to a loopback, your IGP 
will provide an alternative path after a failure.

Cheers,

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

Re: [j-nsp] Log Message

[Ben Dale]

Hi Mohammad,

On 11 Jun 2015, at 4:32 pm, Mohammad Khalil  wrote:

> Hi all
> I have mx480 in place and I am having the below log messages
> Jun  8 18:23:10  CR01-A fpc5 NH: Failed to find nh (1657) for deletion
> Jun  8 18:23:10  CR01-A fpc5 NH: Failed to find nh (1629) for deletion
> Jun  8 18:49:25  CR01-A fpc5 NH: Failed to find nh (1627) for deletion
> Jun  8 18:49:25  CR01-A fpc5 NH: Failed to find nh (1437) for deletion
> Jun  8 18:49:25  CR01-A fpc5 NH: Failed to find nh (1433) for deletion
> Jun  8 18:49:25  CR01-A fpc5 NH: Failed to find nh (1344) for deletion
> Jun  9 00:04:20  CR01-A fpc5 NH: Failed to find nh (1354) for deletion
> Jun  9 00:04:20  CR01-A fpc5 NH: Failed to find nh (1309) for deletion
> Jun  9 06:23:23  CR01-A xntpd[1296]: kernel time sync enabled 6001
> Jun  9 06:40:28  CR01-A xntpd[1296]: kernel time sync enabled 2001
> Jun  9 08:05:51  CR01-A xntpd[1296]: kernel time sync enabled 6001
> Jun  9 08:22:54  CR01-A xntpd[1296]: kernel time sync enabled 2001
> Jun  9 10:22:22  CR01-A xntpd[1296]: kernel time sync enabled 6001
> Jun  9 10:39:28  CR01-A xntpd[1296]: kernel time sync enabled 2001
> 
> I have tried to look for it in , but nothing useful
> Any ideas?
> 
> Thanks in advance
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


This looks like you:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR494528

"Under certain circumstances we will report 'NH: Failed to find nh () for 
deletion' for child links of an aggregate. When an aggregate next-hop is 
deleted we delete all the children next-hops, if the child next-hop is not 
found then the messages is printed. However, this message is cosmetic since the 
child next-hop can be deleted earlier to aggregate next-hop delete."

Resolved in 10.2R4 10.3R3 10.3R4 10.4R2 11.1R1 11.2R1

Cheers,

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

Re: [j-nsp] SRx self-generated traffic

[Ben Dale]

On 18 May 2015, at 11:21 pm, M Abdeljawad via juniper-nsp 
 wrote:

> Hello
> I have three questions related to SRX self-generated traffic
> 1- How to force the SRX self-generated traffic to get out to internet through 
> certain link (suppose I have two internet connections)?

Self-generated traffic will use inet.0 to determine the best path anywhere.  
I'm not aware of any way to perform policy-based routing on self-generated 
traffic, as FBF is applied on ingress.

> 2- Is it possible to carry the self-generated traffic over a VPN tunnel 
> terminated on the SRX?

Yes, however there are some caveats to this approach depending on the specific 
traffic you are generating.  

In general though, you want to have numbered interfaces (eg: your st0.x 
interface has an IP address assigned to it) so that the source IP of the 
traffic is something sane (traffic sourced from an unnumbered tunnel interface 
will otherwise select the underlying interface IP address, which may be public).

Depending on what you are trying to do, you might find this useful:

set system default-address-selection 

This sources all system-generated IP traffic from the loopback interface if one 
is defined.  Depending on which zone your loopback is in, you can then 
configure policies to suit.

> 3-Can we proxy the self-generated traffic to some proxy server?

In the case of traffic like syslog, DNS and software updates then yes this 
should be possible (for various definitions of "proxy").

Cheers,

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

Re: [j-nsp] interoperation between MSTP and old STP

[Ben Dale]

Hi Victor,

On 15 May 2015, at 6:06 pm, Victor Sudakov  wrote:

> Colleagues,
> 
> I have several EX4200 switches with redundant links, all are running
> MSTP with a couple of MSTIs.
> 
> If I include an older switch which can only run old-fashioned STP,
> will they interoperate and still keep the topology loop-free? What if
> it can run STP and RSTP, but not MSTP?

They will interoperate, however there are key differences to be aware of:
- STP/RSTP forms topology with STP bridges regardless of whether correct VLANs 
are trunked on ports - this can mean that topologies may form that isolate VLAN 
segments if you haven't configured trunked ports correctly on all links
- STP/RSTP bridges will treat an MSTP network (regardless of how many switches 
it contains) as single contiguous bridge, so you may find that the ports that 
block in your RSTP network aren't quite where you expected them to be when 
simply counting the radius from the root bridge.  

> 
> A link to some good documentation is also appreciated.
> 
> TIA for any input.

I highly recommend Petr Lapukhov's work here:

http://blog.internetworkexpert.com/2010/02/22/understanding-mstp/

The configuration and outputs are IOS-based and there are a few PVST+ interop 
discussions, but the supporting protocol description and break-down is truly 
excellent.

Cheers,

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

Re: [j-nsp] Passing Traffic over SRX Cluster Fabric

[Ben Dale]

Hi Mahmoud,

On 3 May 2015, at 10:27 pm, M Abdeljawad via juniper-nsp 
 wrote:

> Hi 
> I have two SRX Cluster, and the design requires that the traffic pass through 
> the fabric-link.but noticed some drop on the traffic when traffic pass 
> through the fabric link.
> Is there a limitation for passing traffic over fabric link (the passing 
> traffic size was around 500M, and the fabric link is 10G)
> RegardsMahmoud
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

If you're deliberately running a Z-mode traffic (and even if you're not) you 
need to check that you've set the MTU on the physical interfaces of the fabric 
link to be large enough to take the biggest frame you would receive on your 
reth/revenue interfaces plus overhead.  The recommended/max values are 8900 for 
reth/revenue ports and 9014 for the fabric link.

Reference Guide:
http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/NT260/SRX_HA_Deployment_Guide.pdf

Cheers,

Ben

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

Re: [j-nsp] MX: Hardware-Down for an irb logical unit

[Ben Dale]

Hi Chuck,

On 29 Apr 2015, at 9:32 am, Chuck Anderson  wrote:

> What would cause an irb logical interface unit to stay in
> "Hardware-Down"?  I'm using identical configs on 4 different routers
> (different IPs of course), and one of them won't come up.  There is at
> least one physical interface in the BD that is up.  The irb physical
> interface is up.  There are many other irb logical units that are up
> and working fine, just this one unit that is down.
> 

This is usually caused because there are no physical interfaces up in the 
bridge-domain.  

I notice you've got an aggregated-ethernet interface in there - if you have 
LACP enabled, but no LACP partner, the physical link will stay up, but the 
logical interface will go down, thus taking down your IRB as well.

Cheers,

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

Re: [j-nsp] SRX secure wire and layer 2 pdus

[Ben Dale]

Hi Ross,

On 29 Apr 2015, at 1:43 am, Ross Vandegrift  wrote:

> Hi all,
> 
> The documentation for SRX secure wire has thrown me for a loop.  It
> says: secure wire is a kind of transparent mode, and transparent mode
> interfaces pass all ARP and non-IP broadcast/multicast.  So a secure
> wire should pass BPDUs and LACPDUs.
> 
> I think that's a mistake.  If both secure wire interfaces land on the
> same switch, RSTP/MSTP ought to block one of the interfaces.  Separate
> switches won't help if both are multihomed to common distribution
> switches.  The secure wire will look like two edge interfaces were
> cabled together, and RSTP/MSTP will block.
> 
> I setup a test with two ex4200s and a secure wire between them.  No
> BPDUs or LACPDUs make it across.  Seems good, but now I'm nervous
> that the behavior doesn't match the documentation.
> 
> Have I missed something?  Case is open, but it stalled at the repeat
> the documentation stage.
> 
> https://www.juniper.net/techpubs/en_US/junos12.3x48/topics/concept/layer-2-secure-wire-understanding.html
> 
> Ross
> 

The doco needs a slight update (or better yet, a cross-reference) to the link 
below.  

In the documentation for Transparent Mode, it mentions the Layer 2 bridging 
exceptions on SRX that apply when using a bridge-domain for transparent-mode, 
which is the same method SecureWire uses for tying interfaces together.

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/layer-2/index.html?topic-52744.html

You'll see there that xSTP is specifically called out.

Cheers,

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

Re: [j-nsp] vpls question

[Ben Dale]

On 27 Apr 2015, at 5:57 pm, james list 
mailto:jameslis...@gmail.com>> wrote:

Well indeed OSPF is running also with customer peer in the other side of the 
MPLS cloud (CE2) and PE3/4 (still other side)... and it's due by customer 
requested design to have VPLS and OSPF on the PEs...

So I understand that putting "protocols vpls connectivity-type irb" do not 
solve...

I'm wondering why and the expected behaviour...


If you have a VPLS with two PEs joining to one CE at each site, you've created 
two loops, one at each site.

Standard behaviour is to define both PEs as a single "site" in the VPLS and use 
multi-homing and site-preference to keep one PE-CE interface inactive until 
such time as the other is required as already mentioned.

You can't run OSPF across both links without bringing them both up, which will 
create an L2 loop - these things are mutually exclusive.

The "protocols vpls connectivity-type irb" will keep the instance up if you 
have irbs defined and the PE-CE link goes down, but this doesn't really help 
you though.

It might be time to break out the sock puppets and have a robust discussion 
with your customer.


cheers
James

2015-04-27 0:36 GMT+02:00 Ben Dale 
mailto:bd...@comlinx.com.au>>:
Hi James,

On 27 Apr 2015, at 5:31 am, james list 
mailto:jameslis...@gmail.com>> wrote:

> Hi amarjeet
> Because if PE1 fails there is faster convergence to PE2 due to neighbor
> already established.
>

Is there a reason you wouldn't consider using an L3VPN instead of a VPLS?  It 
seems odd to me that you would be using L3 adjacencies to an L2 service.

If it really is L2 fail-over you are chasing, then Amarjeet is correct - 
multihoming and site-preference are designed for exactly this purpose.

If you customer requires L3 connectivity across your VPLS, you would be better 
off carrying their OSPF across the VPLS and let their CEs form adjacencies with 
each other - that way, you can take care of L2 fail-over, and the customer is 
responsible for L3.

Cheers,

Ben



> Cheers
> James
> Il 24/apr/2015 13:23, "james list" 
> mailto:jameslis...@gmail.com>> ha scritto:
>
>> I have a VPLS multi-homed environment with two MX routers (PE1 and PE2)
>> connected to a single ethernet switch (CE1). I have PE1 configured with
>> site-preference as "primary" and PE2 as "backup".
>>
>>
>> Behind the CE1 there is a router running OSPF with both MX (on irb
>> interface).
>>
>>
>> My goal is to have:
>>
>> 1)Multihoming to prevent loops
>>
>> 2)Let the router run two OSPF neighbor with both PE and not just one
>> with the primary PE.
>>
>> I’m wondering if using:
>>
>>
>> set routing-instances  protocols vpls connectivity-type irb
>>
>>
>> instead of the default (connectivity-type ce) could give me the option to
>> reach my goal number 2) and if I can introduce any drawback.
>>
>>
>> Or if there is another solution keeping 1).
>>
>>
>> I don’t have a lab to test…
>>
>>
>> Any help/feedback is really appreciated.
>>
>>
>> Greetings
>>
>> James
>>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net<mailto: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 question

[Ben Dale]

Hi James,

On 27 Apr 2015, at 5:31 am, james list  wrote:

> Hi amarjeet
> Because if PE1 fails there is faster convergence to PE2 due to neighbor
> already established.
> 

Is there a reason you wouldn't consider using an L3VPN instead of a VPLS?  It 
seems odd to me that you would be using L3 adjacencies to an L2 service.

If it really is L2 fail-over you are chasing, then Amarjeet is correct - 
multihoming and site-preference are designed for exactly this purpose.

If you customer requires L3 connectivity across your VPLS, you would be better 
off carrying their OSPF across the VPLS and let their CEs form adjacencies with 
each other - that way, you can take care of L2 fail-over, and the customer is 
responsible for L3.

Cheers,

Ben



> Cheers
> James
> Il 24/apr/2015 13:23, "james list"  ha scritto:
> 
>> I have a VPLS multi-homed environment with two MX routers (PE1 and PE2)
>> connected to a single ethernet switch (CE1). I have PE1 configured with
>> site-preference as "primary" and PE2 as "backup".
>> 
>> 
>> Behind the CE1 there is a router running OSPF with both MX (on irb
>> interface).
>> 
>> 
>> My goal is to have:
>> 
>> 1)Multihoming to prevent loops
>> 
>> 2)Let the router run two OSPF neighbor with both PE and not just one
>> with the primary PE.
>> 
>> I’m wondering if using:
>> 
>> 
>> set routing-instances  protocols vpls connectivity-type irb
>> 
>> 
>> instead of the default (connectivity-type ce) could give me the option to
>> reach my goal number 2) and if I can introduce any drawback.
>> 
>> 
>> Or if there is another solution keeping 1).
>> 
>> 
>> I don’t have a lab to test…
>> 
>> 
>> Any help/feedback is really appreciated.
>> 
>> 
>> Greetings
>> 
>> James
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] solution to a firewall question

[Ben Dale]

Hi Vijesh,

On 24 Apr 2015, at 1:18 am, Vijesh Chandran  wrote:

> Hi all,
>  I am wondering if we have a solution to this issue.
>  I need two firewall attached to an interface as input-list. e.g.: f1 and f2.
>  Input-list [f1 f2]
>  f1 to match a condition (all tcp port 80) and accept and count that packet.
>  f2 to classify those packets based on code points and push to a forwarding 
> class. Is this possible?
> 
> -Thanks,
> Vijesh
> 

If f2 is only matching on code-points, is there any reason you can't just use a 
class-of-service classifier instead for this functionality?

Cheers,

Ben

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

Re: [j-nsp] SRX550 SRX-GP-8SERIAL

[Ben Dale]

On 15 Apr 2015, at 9:22 am, Herro91  wrote:

> Hi,
> 
> Does anyone know how many 8 port serial GPIM's can be installed into an
> SRX550?

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/gpim-srx-series-overview.html

seems to suggest up to 6 can be installed in the available GPIM slots

Cheers,

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

Re: [j-nsp] Aggregate policer config

[Ben Dale]

On 9 Apr 2015, at 10:22 am, Mark Tees  wrote:

> I would be curious to know if/how the aggregate behaviour works
> between different line cards/PFE.

I was wondering this too, so I did a bit of digging - Page 198 of Doug Hanks' 
MX Series book suggests it doesn't - quoting:

"The same filter can be applied to multiple interfaces at the same time.  By 
default on MX Routers, these filters will sum (or aggregate) their counters and 
policing actions when those interfaces share a PFE."

I've only got MX80s here in the lab just now, which I think share a PFE for 
both FPC 0 and FPC1 - I can apply the same filter/policer to both a 10G and a 
1G interface and get the aggregate bandwidth between interfaces to be dictated 
by the policer.

> Just to clarify here:
> 
> set firewall policer POLICER-800M filter-specific
> set firewall policer POLICER-800M if-exceeding bandwidth-limit 800m
> set firewall policer POLICER-800M if-exceeding burst-size-limit 10m
> set firewall policer POLICER-800M then discard
> 
> This should result in the policer/counter actions being created per
> the filter they are used in but still shared within that filter
> providing "interface-specific" is not used right?

Yes, correct, however I suspect that the policer aggregate would again be per 
PFE.

So, back to the OP's question - you *should* be able to use a single filter, 
provided both your customer's links are on an MPC1 or MPC3E with 1G / 10G MICs.

If that's not the case, then stick with the per-interface 800M policer and just 
apply local-preference to your customers routes as you import them to ensure 
their traffic is always preferred via the 10G link (while it's up), and use 
MED/metric to encourage them to use the 10G link for their outbound.

Cheers,

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

Re: [j-nsp] Aggregate policer config

[Ben Dale]

Aggregate policing should be the default behaviour for a *filter*, as long as 
you don't apply the "interface-specific" knob.

Create a dedicated filter for this customer and apply it to both interfaces.

set firewall family any filter CUST-A-800M term POLICE-800M then policer 
POLICER-800M
set firewall family any filter CUST-A-800M term POLICE-800M then accept

traffic over either interface will contribute to the filter counter.

The policer itself can be generic/re-used by other filters as long as you 
*include* filter-specific.

set firewall policer POLICER-800M filter-specific
set firewall policer POLICER-800M if-exceeding bandwidth-limit 800m
set firewall policer POLICER-800M if-exceeding burst-size-limit 10m
set firewall policer POLICER-800M then discard

Cheers,

Ben

On 8 Apr 2015, at 7:15 am, Matthew Crocker  wrote:

> 
> Hello,
> 
> A customer with two connections to my mx240.  I want to police their total 
> bandwidth to 800mbps. Right now I have a 800mbps policer but that gives them 
> 800mbps on each circuit.
> 
> Customer Interface 1 is a VLAN on a 10G interface
> Customer Interface 2 is a VLAN on a 1G interface
> 
> Each interface has its own /30 IP subnet with a  BGP session on each customer 
> IP
> 
> Customer buys X bandwidth we want to give them X bandwidth over a pair of 
> circuits.  If one circuit goes down the policer needs to be set to the X 
> bandwidth the purchased.
> 
> Thanks
> 
> -Matt
> 
> --
> Matthew S. Crocker
> President
> Crocker Communications, Inc.
> PO BOX 710
> Greenfield, MA 01302-0710
> 
> E: matt...@crocker.com
> P: (413) 746-2760
> F: (413) 746-3704
> W: http://www.crocker.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] EX2200 LLDP Port Info

[Ben Dale]

Hi Bill,

On 27 Mar 2015, at 3:16 am, Bill Blackford  wrote:
> Seems to be undesired behavior. So, far I have not found anything in the
> release notes that would indicate a fix. any thoughts on this from the
> group?

What you're seeing on the EX2200 changes from version to version

11.4R7 ignores the description and sends the logical interface name eg: 
ge-0/1/0.0
12.3R4.6 overrides the interface name with the description eg: "Link to switchA 
- ge-0/0/0"

In fact, the behaviour of LLDP from platform to platform across the whole range 
is pretty inconsistent:

MX80 - 14.2R1.9 (shows ifIndex of neighbouring interface):
Local InterfaceParent InterfaceChassis Id  Port info  
System Name
ge-1/1/2   -   40:b4:f0:49:98:f0   505
ACX1100 
ge-1/0/0   ae0 5c:5e:ab:0e:7f:40   516
MX80-B  
ge-1/1/0   ae0 5c:5e:ab:0e:7f:40   526
MX80-B  
ge-1/1/5   -   5c:5e:ab:0e:7f:40   531
MX80-B  

ACX1100 - 12.3something (shows ifIndex of neighbouring interface, and has no 
Parent interface to identify aggregates)
Local Interface Chassis IdPort info System Name
ge-0/0/45c:5e:ab:0e:60:30 528   MX80-A   
ge-0/0/15c:5e:ab:0e:7f:40 517   MX80-B   
ge-0/0/05c:5e:ab:0e:7f:40 527   MX80-B   

I seem to recall older versions of MX code (11 or 12) used to send the 
description field as well.

As for why - one example I know of is that there is a provider here that uses 
LLDP to send through the Circuit ID of their tails via Port Description, which 
is nice for operations staff on the remote end for ticket logging.

Anyway, you can partially resolve this issue with the following:

set protocols lldp port-id-subtype interface-name

This means that the *sending* LLDP device will now send the interface name in 
the Port ID field instead of the ifindex.  Unfortunately, the "show lldp 
neighbors" command will still only show the value of the Port Description 
field, which will get overridden by the interface description.  Instead you'll 
need to use "show lldp neighbours interface " to see it.

BEFORE:

bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 
...
Neighbour Information:
Chassis type   : Mac address
Chassis ID : b0:a8:6e:8d:5a:40
Port type  : Locally assigned
Port ID: 527   <-
Port description   : Uplink to GD-eng-22c
System name: GD-rck-22c 
   
AFTER:

bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 
.
Neighbour Information:
Chassis type   : Mac address
Chassis ID : b0:a8:6e:8d:5a:40
Port type  : Interface name
Port ID: ge-0/1/0   <-
Port description   : Uplink to GD-eng-22c
System name: GD-rck-22c

To fix this though, I've put together an op script that behaves in a similar 
manner to "show lldp neighbors" except that it lists the Port ID field as well: 
https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax

It works works on the EX22/42 okay, but the EX doesn't seem to support remote 
execution (eg: op url 
https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax) across 
any of the version I've tried: 11.4R7.5, 12.3R2.5, 12.3R4.6, 12.3R6.6, 
13.2X51-D20.2.

On the MX under 14.2R1.9, remote execution works, but the script is a bit 
borked as it seems to be trying to re-use the variable from the previous 
iteration in for-each - let me know if anyone has an better experiences.

Cheers,

Ben

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

Re: [j-nsp] info VC QFX

[Ben Dale]

Hi James,

On 25 Mar 2015, at 1:35 am, james list  wrote:

> Hi folks,
> on QFX VC is there a way to configure VME interface to respond on each
> module of the VC instead to be redirected on the master RE ?
> 
> If yes a little configuration example is appreciated.
> 

I can't speak for QFX VC, but on EX VC this isn't possible.

If you need to get to a specific member (eg: 2), use:

request session member 2

Cheers,

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

Re: [j-nsp] next junos versions

[Ben Dale]

On 10 Mar 2015, at 12:49 am, james list  wrote:

> Hi
> is there a way to know the expected delivery date of the next Junos
> releases ?
> I'd a look to the path finder but I found nothing

You used to be able to set your watch by the four releases a year, now, not so 
much.

The following table shows previous major version release dates (FRS Date).

http://www.juniper.net/support/eol/junos.html

>From 12.x it moved to 3 major releases/year and as of 14.x I believe it's down 
>to two now?  Not counting all the Xversion feature releases for the various 
>platforms.

Cheers,

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

Re: [j-nsp] MX extended DHCP server static address binding

[Ben Dale]

Hi Misak,

> I can successfully describe  host 089 in Pool1 and it will get predefined 
> IP address, but if I do the same for Pool2 to assign host IP address from 
> that pool, host gets random address from Pool1. My  guess is that DHCP server 
> will never consider Pool2 configuration until all Pool1 addresses will be 
> assigned. For me it's a clearly bug in that case.

You are correct:

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/subscriber-management-address-assignment-pool-linking.html

linked pools won't be utilised until the primary pool is depleted, so not 
really a bug, but 

> Please advise how I can assign IP address from Pool2 to host. Juniper MX480, 
> JunOS 14.2R1.9

I don't think this is possible - if you move the host definition into Pool1 
with it's correct IP address, it'll fail the network range bounds check.

The only option I can see would be defining a "network" range that covers both 
Pools (if this is even possible) inside Pool1, then configure two separate 
range definitions inside that to cover your current address ranges.

Cheers,

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

Re: [j-nsp] Exporting DHCP logs to syslog on EX / SRX devices

[Ben Dale]

Hi Laurent,

On 13 Jan 2015, at 4:04 am, Laurent CARON  wrote:

> Hi,
> 
> I'm trying (with no lock so far) to send the DHCP logs to a remote syslog 
> server.
> 
> DHCP logging is the following:
> 
> set system processes dhcp-service traceoptions file dhcp.log
> set system processes dhcp-service traceoptions file size 100240
> set system processes dhcp-service traceoptions flag all
> 
> How can I have the DHCP logs shipped to a remote syslog server ?
> 
> Even: set system syslog host syslog.domain.tld any any
> doesn't export DHCP logs.
> 
> Thanks

Use:

set system tracing destination-override syslog host x.x.x.x

Cheers,

Ben


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

Re: [j-nsp] SRX High-end Packet mode

[Ben Dale]

Hi Mahmoud,

On 18 Dec 2014, at 3:34 am, M Abdeljawad via juniper-nsp 
 wrote:

> I have three questions about packet mode on high-end SRX firewalls
> - Is it supported on SRX high-end firewalls to switch the firewall to packet 
> mode altogether using the below command which supported on branch 
> firewalls;(set security forwarding-options family mpls mode packet-based)

Feature navigator seems to suggest they can support packet-based for IPv6 [1] 
(not MPLS) in 12.1X44, but the SRX Series Book (older) suggest packet-mode is 
branch-only [2]. 

> - Is it supported on SRX high-end firewalls to partially convert some traffic 
> to packet mode (selective packet forwarding using filters)?

I don't believe so

> - Is it possible to operate MPLS on SRX high-end firewalls without enabling 
> packet-mode?

No

Cheers,

Ben

[1] http://pathfinder.juniper.net/feature-explorer/
[2] 
https://books.google.com.au/books?id=2HSLsTJIgEQC&pg=PA163&lpg=PA163&dq=srx+packet-mode+mpls&source=bl&ots=_fxiZyPIyt&sig=tIuoDMgJWzpRyHCiIXyMKU-KNdo&hl=en&sa=X&ei=tgqSVLDtIMv08QX9yIHACw&ved=0CCIQ6AEwATgK#v=onepage&q=srx%20packet-mode%20mpls&f=false




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

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

[Ben Dale]

On 2 Dec 2014, at 12:41 am, Robert Hass  wrote:

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

This is completely doable without the need for Openflow.

The vMX is delivered as two VMs - a vRE and vPFE and logically they communicate 
in the same way as the RE and PFE do in an MX today eg: an internal ethernet 
switch sends control-plane information down to the forwarding engine.

Whether this happens on a single host machine across a vSwitch, or across a 
physical network is now completely irrelevant, normal constraints not 
withstanding (congestion/loss etc).  

It's not a big stretch to imagine being able to one day ditch the vPFE and take 
a bunch of "head-less" MXs (hardware-based) acting as remote FPCs to a pair of 
centralised vREs - like JCS/TXM but on more commoditised server hardware, or 
even a Q-Fabric with MXs as nodes and commodity directors/interconnect.  

Given that control-plane traffic is pretty minimal, and with all the cool FIB 
localisation knobs coming down in 14.x, the scaling/design implications of this 
get pretty interesting.

Heck - it should be possible to one day take the much-maligned MX80 RE and 
replace it with a remote intel-based monster, and get 64-bit Junos in the mix.

Emulating the backplane for inter-FPC traffic is going to be a barrel of fun 
though!

Ben


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

Re: [j-nsp] Best design can fit DC to DC

[Ben Dale]

I recommend you take a good long look at E-VPN:

http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/evpns-overview.html

https://conference.apnic.net/data/37/2014-02-24-apricot-evpn-presentation_1393283550.pdf

http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/whitepaper_c11-731864.html

It is supported in one form or another on MXs, ASRs and ALU boxes and presents 
P2MP services just like a VPLS, only with control-plane based MAC learning, 
active/active multi-homing and a bunch of other goodness which will probably 
spell the end for OTV (which under the hood is essentially MPLS over GRE with 
some smarts), and maybe even replace VPLS and L2VPN/EoMPLS longer term.

OTV limits you to a single platform (N7K only last I looked) from a single 
vendor and you have to anchor your tunnels on your Data Centre switch.  Now 
your interconnect is tied to your DC fabric.  How inconvenient.

Stretching L2 domains over 1000km of wouldn't be my first suggestion either.

I've had a bit of a play with VCF and it seems to work as advertised, but be 
aware of mixed-mode limitations if you need to bring in lots of 1GE ports (eg: 
EX4300) - they don't support TISSU.  Putting 1GE SFPs into a QFX5100 is a 
slightly more expensive workaround though.

Ben

On 5 Nov 2014, at 12:06 pm, Oliver Garraux  wrote:

> I don't think L2 extension is a good idea, but if you have to, OTV is the
> way to do it IMO.  Particularly since you have to support non virtualized
> infrastructure, and may have > 2 sites in the future.  OTV isn't going to
> have sub-second convergence (though I think it might support BFD in the
> future?)
> 
> 35km isn't too bad latency wise.  1000km will be much trickier.  Things
> like storage replication will be more difficult.  And while OTV can easily
> isolate FHRP's to send outbound traffic out the local default gateway,
> traffic tromboning with inbound traffic might be an issue.  (If inbound
> traffic is routed to the "wrong" data center, the extra latency from having
> to go across 1000km to get to the datacenter where the box actually is will
> suck).  I think LISP in theory could help with this, but would involve
> changes to how traffic gets *to* your data centers.
> 
> Also, in general don't overlook the integration of storage / network /
> system stuff.  IE, if you lose all the links between the data centers,
> storage / networking / systems all need to fail over to the same place.  If
> you can, do lots of disruptive testing before going into production.  A
> previous organization I've been with discovered (and fixed) many issues
> with L2 extension through pre-production testing of everything.
> 
> Oliver
> 
> -
> 
> Oliver Garraux
> Check out my blog:  blog.garraux.net
> Follow me on Twitter:  twitter.com/olivergarraux
> 
> On Fri, Oct 31, 2014 at 9:41 AM, R LAS  wrote:
> 
>> Hi all
>> a customer of mine is thinking to renew DC infrastructure and
>> interconnection among the main (DC1) and secondary (DC2), with the
>> possibility in the future to add another (DC3).
>> 
>> Main goal are: sub-second convergence in case of a single fault of any
>> component among DC1 and DC2 (not DC3), to have the possibility to extend L2
>> and L3 among DCs, to provide STP isolation among DCs, to provide ports on
>> the server at eth 1/10Gbs speed.
>> 
>> DC1 and DC2 are 35 km away, DC3 around 1000 km away from DC1 and DC2.
>> 
>> Customer would like to design using Cisco or Juniper and at the end to
>> decide.
>> 
>> Talking about Juniper my idea was to build and MPLS interconnection with
>> MX240 or MX104 in VC among DC1 and DC2 (tomorrow will be easy to add DC3)
>> and to use QFX in a virtual chassis fabric configuration.
>> 
>> Does anybody have these kind of config ?
>> Is it stable QFX ?
>> Any other suggestion/improvement ?
>> 
>> And if you would go with Cisco, what do you propose in this scenario ?
>> 
>> Rgds
>> ___
>> 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] BRAS IPv4/IPv6 Combined Policer & RADIUS Attributes

[Ben Dale]

Hi Darren,

> 
> Our requirement is per below. For example, the bandwidth package is 5Mbps.
> The IPv4 & IPv6 should be policed jointly to bandwidth of 5Mbps rather than
> individual IPv4 or IPv6 family policing. If policing is done individually
> for IPv4 (5Mbps) and for IPv6 (5Mbps), the user is getting bandwidth of
> 10Mbps jointly  which we tried to avoid.


Modify your PPPoE template so that you're applying the filter under 
"$junos-interface-unit" rather than the address family:

PPPOE-IP-PROFILE {
interfaces {
pp0 {
unit "$junos-interface-unit" {
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
filter {
input 5m;
output 5m;
}
family inet {
unnumbered-address "$junos-loopback-interface";
}
family inet6 {
unnumbered-address "$junos-loopback-interface";
}
}
}
}   
}

That will police regardless of the underlying address family.

Cheers,

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

Re: [j-nsp] controlling the source IP for the Dns Proxy feature

[Ben Dale]

I've certainly had no issue with stability using route-based VPN.

As far as multiple subnet (proxy-id / traffic selectors) support, as of 
12.1X46-D10 this is now native in Junos - 

http://kb.juniper.net/InfoCenter/index?page=content&id=KB28820

and is dead simple to configure.

If you're a little gun shy on 12.1X code and are still running old-faithful 
builds like 11.4RLate, then there are a couple of options:

- If your subnets are contiguous, just widen the mask to include them in a 
single crypto-map on the Cisco side (even if that means widening the mask a LOT)

- If your subnets are arbitrarily selected from different RFC1918 blocks 
(DOH!), then create separate P2 bindings for each subnet:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB20543

just be aware that this will only work if the multiple subnets are on the Cisco 
side (which seems to be true in your case)

There are a few other hacks out there using FBF as well.  J-NET has some good 
material:

http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on-route-based-VPN-with-multiple-local/td-p/172002/page/2

Cheers,

Ben

On 16 Oct 2014, at 8:35 am, Andy Litzinger  
wrote:

> I'd happily use route-based vpns if they are supported in my use case.
> Based on Kbs and internet lore, it seemed policy based was the best bet
> for stability.
> 
> My two tunnel endpoint devices are the SRX and a Cisco ASA.
> On the SRX side I've got a single subnet but on the ASA side I've got two
> subnets.  I would happily use a simple policy on the ASA side like 'permit
> ip any  ' if i was confident I wasn't
> going to have squirrely issues with connectivity.
> 
> What do you think?
> 
> -andy
> 
> On 10/15/14 3:22 PM, "Ben Dale"  wrote:
> 
>> Hi Andy,
>> 
>> I have come across this exact issue using the feature.
>> 
>> There was a good reason why we didn't use default address selection that
>> escapes me just now, but I had a slight advantage in that I was using
>> route-based VPNs, so I was able to number the st0 interface with a /32
>> from the corporate range and source my queries from there.
>> 
>> Unfortunately policy-based VPNs are extremely limiting when it comes to
>> things like this.  I can't think of too many scenarios where I'd even use
>> them any more.  If you don't have too many sites, I'd seriously consider
>> migrating them across.
>> 
>> Cheers,
>> 
>> Ben
>> 
>> On 16 Oct 2014, at 1:28 am, Andy Litzinger
>>  wrote:
>> 
>>> Hello,
>>> is anyone out there using the dns-proxy feature for the branch SRX?  Are
>>> there any clever tricks for specifying the source address the SRX uses
>>> to
>>> query name servers?  It does not appear to be a config option.
>>> 
>>> with the default config it appears to use the IP of the outbound
>>> interface.  If I add the config statement 'set system default address
>>> selection' i can influence it to use the lo0.0 address, which can solve
>>> my
>>> issue, but not in a way i prefer.
>>> 
>>> my exact problem is the following:
>>> I have an SRX 220H in a remote office. It has an trust and untrust zone.
>>> users sit on the trust zone and receive dhcp from the SRX and use the
>>> SRX
>>> as their default gateway and dns server.  There is a policy based vpn
>>> that
>>> connects from the untrust zone to our corp HQ.  I have the dns-proxy
>>> config
>>> set up so that if a dns request is going to an intranet zone, e.g.
>>> corp.example.com, then it should use DNS servers that live across the
>>> tunnel in our corp HQ.  If they are looking up anything else, they use
>>> google dns servers.
>>> 
>>> here's the relevant config:
>>> dns-proxy {
>>>   interface {
>>>   ;
>>>   }
>>>   default-domain * {
>>>   forwarders {
>>>   8.8.8.8;
>>>   8.8.4.4;
>>>   }
>>>   }
>>>   default-domain corp.example.com {
>>>   forwarders {
>>>   ;
>>>   ;
>>>   }
>>>   }
>>> }
>>> 
>>> the problem is without the 'default address selection' set the SRX
>>> tries to
>>> use the untrust interface IP as the source IP to query our corp HQ name
>>> servers, but the traffic doesn't enter the tunnel because it doesn't
>>> match
>>> the vpn policy.  And I can't change the policy to allow it because the
>>> untrust int

Re: [j-nsp] controlling the source IP for the Dns Proxy feature

[Ben Dale]

Hi Andy,

I have come across this exact issue using the feature.

There was a good reason why we didn't use default address selection that 
escapes me just now, but I had a slight advantage in that I was using 
route-based VPNs, so I was able to number the st0 interface with a /32 from the 
corporate range and source my queries from there.

Unfortunately policy-based VPNs are extremely limiting when it comes to things 
like this.  I can't think of too many scenarios where I'd even use them any 
more.  If you don't have too many sites, I'd seriously consider migrating them 
across.
 
Cheers,

Ben

On 16 Oct 2014, at 1:28 am, Andy Litzinger  
wrote:

> Hello,
> is anyone out there using the dns-proxy feature for the branch SRX?  Are
> there any clever tricks for specifying the source address the SRX uses to
> query name servers?  It does not appear to be a config option.
> 
> with the default config it appears to use the IP of the outbound
> interface.  If I add the config statement 'set system default address
> selection' i can influence it to use the lo0.0 address, which can solve my
> issue, but not in a way i prefer.
> 
> my exact problem is the following:
> I have an SRX 220H in a remote office. It has an trust and untrust zone.
> users sit on the trust zone and receive dhcp from the SRX and use the SRX
> as their default gateway and dns server.  There is a policy based vpn that
> connects from the untrust zone to our corp HQ.  I have the dns-proxy config
> set up so that if a dns request is going to an intranet zone, e.g.
> corp.example.com, then it should use DNS servers that live across the
> tunnel in our corp HQ.  If they are looking up anything else, they use
> google dns servers.
> 
> here's the relevant config:
> dns-proxy {
>interface {
>;
>}
>default-domain * {
>forwarders {
>8.8.8.8;
>8.8.4.4;
>}
>}
>default-domain corp.example.com {
>forwarders {
>;
>;
>}
>}
> }
> 
> the problem is without the 'default address selection' set the SRX tries to
> use the untrust interface IP as the source IP to query our corp HQ name
> servers, but the traffic doesn't enter the tunnel because it doesn't match
> the vpn policy.  And I can't change the policy to allow it because the
> untrust interface IP is the endpoint of the tunnel.  It looks like the
> source zone of the dns query is junos-host- is it possible maybe to set up
> a junos-host zone to untrust zone NAT when going to corp-hq IP space?
> 
> or is there another clever solution?
> 
> thanks!
> -andy
> ___
> 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 VC Cabling

[Ben Dale]

I've never had any issues doing it either way.  It'll auto-detect the topology, 
even if you have only a single link.

What I have seen though is a bunch of units (at least a couple of months back) 
coming out of the factory booting form the backup image (like the build image 
was corrupt), so it may have nothing to do with your VC build at all.

Just upgrade to JTAC preferred, snapshot all members (and read a long novel 
while you wait for that to finish) and then reboot the whole chassis.


On 1 Oct 2014, at 9:23 am, Skeeve Stevens 
 wrote:

> Hi all,
> 
> We're doing a bunch of 2 x EX4200 in VC.
> 
> Once we connect the VC cables, one of the Junos seems to be corrupted.
> 
> We're currently using the ring X cabling.. but I have seen another option
> for a 2 member stack of | |
> 
> Anyone got any thoughts?
> 
> *
> **   **
> **  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE  **
> **   **
> **  It is possible that the primary copy of JUNOS failed to boot up  **
> **  properly, and so this device has booted from the backup copy.**
> **   **
> **  Please re-install JUNOS to recover the primary copy in case  **
> **  it has been corrupted and if auto-snapshot feature is not**
> **  enabled. **
> **
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
> 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] BGP Peer formatting

[Ben Dale]

On 23 Sep 2014, at 1:48 pm, Phil Shafer  wrote:

> Ben Dale writes:
>> Okay, one small caveat to this script - it looks like the use of mutable 
>> variables (mvar
>> and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not 
>> going to wo
>> rk on older versions of Junos.
>> 
>> I know 11.4 is the trusted choice for most people on MX at the moment, so 
>> when I get som
>> e time I'll attempt a mind-bending re-write using the older immutable var 
>> format.
> 
> In this case, you don't need the mvars.  Let sum() do the iteration:
> 
>for-each ($neighbour-list/bgp-peer) {
> jcs:printf("%-20s%-15s%-12s%-10s%-10s%-10s%-10s%-5s",
>peer-address,
>peer-as,
>peer-state,
>elapsed-time,
>   sum(bgp-rib/active-prefix-count),
>   sum(bgp-rib/received-prefix-count),
>   sum(bgp-rib/accepted-prefix-count),
>description);   
>}
> 
> Thanks,
> Phil

Love your work Phil : )

That's a heck of a lot simpler/cleaner than the recursive monstrosity I've been 
putting together!

Changes have been pulled into github, so if you're running 11.4 or earlier, 
give it another try now.

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

Re: [j-nsp] BGP Peer formatting

[Ben Dale]

On 23 Sep 2014, at 5:57 am, Eugeniu Patrascu 
mailto:eu...@imacandi.net>> wrote:

On Mon, Sep 22, 2014 at 4:24 PM, Phil Shafer 
mailto:p...@juniper.net>> wrote:
Ben Dale writes:
>> https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax

Very cool!

>Hey Phil, when can we have git native in Junos?!  ; )

How about:

op url 
https://raw.githubusercontent.com/dfex/DFEXjunoscripts/master/show-bgp-neat.slax



--- JUNOS 12.1X44-D35.5 built 2014-05-19 22:11:33 UTC

> op url 
> https://raw.githubusercontent.com/dfex/DFEXjunoscripts/master/show-bgp-neat.slax

error: ^


error: 
/var/tmp/tmp_opzhxmSf/...transferring.file.DdJl9A/show-bgp-neat.slax:35:
 error: 
/var/tmp/tmp_opzhxmSf/...transferring.file.DdJl9A/show-bgp-neat.slax:34:
 parse error, unexpected T_BARE before 'set':



Okay, one small caveat to this script - it looks like the use of mutable 
variables (mvar and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's 
actually not going to work on older versions of Junos.

I know 11.4 is the trusted choice for most people on MX at the moment, so when 
I get some time I'll attempt a mind-bending re-write using the older immutable 
var format.

Stay tuned, and thanks again for all the direct feedback!

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

Re: [j-nsp] BGP Peer formatting

[Ben Dale]

On 10 Sep 2014, at 11:32 am, Ben Dale  wrote:

> Failing that, I just hacked up an op script to only show a summarised version 
> from each peer - output here:
> 
> https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.md
> 
> Code here:
> 
> https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax
> 
> The script *should* sum all the prefixes from each RIB into a single 
> summarised number per peer, but I haven't had a chance to test it too 
> thoroughly yet.  Feedback/Pull Requests welcome.
> 

Okay, looks like I managed to upload an incomplete non-working script instead 
of the one I was actually testing on my router.  

Thanks to those who pointed this out!

Corrected version is now up on Github - tested on SRX, ACX and MX (all single 
RE) 

Hey Phil, when can we have git native in Junos?!  ; )


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

Re: [j-nsp] EX9200 DHCP Relay

[Ben Dale]

SELECTING means that an OFFER has been sent to the client (or at least the 
switch thinks it has relayed it), but the REQUEST hasn't come back from the 
client.

I have seen this in some instances where the client is expecting a Unicast 
reply from the relay agent rather than a broadcast or vice-versa - fix with:

set forwarding-options dhcp-relay overrides layer2-unicast-replies

Nice tip on the route-suppression statement William - that one has been 
annoying me for a while with JDHCPd on the SRX...

Cheers,

Ben

On 19 Sep 2014, at 12:01 am, Chris Jones  wrote:

> My DHCP clients are all stuck in SELECTING state. Has anyone ever seen that, 
> or maybe know what causes it?
> 
> root@DVT-EX9200> show dhcp relay binding
> 
> IP addressSession Id  Hardware address   Expires State  
> Interface
> 0.0.0.0   18  00:25:90:3d:76:34  0   SELECTING  irb.30
> 0.0.0.0   19  00:25:90:3d:e5:13  0   SELECTING  irb.30
> 0.0.0.0   17  00:25:90:6d:f0:c3  0   SELECTING  irb.30
> 0.0.0.0   23  d4:be:d9:95:b6:4f  0   SELECTING  irb.16
> 
> 
> 
> 
>> On Sep 16, 2014, at 3:13 PM, William McLendon  wrote:
>> 
>> this is a working DHCP config on EX9200s — make sure you include the 
>> forward-snooped-clients all-interfaces statement, or any transit DHCP packet 
>> that traverses an interface without DHCP relay configured will be eaten by 
>> the EX9200 — its the most asinine thing in the world to have (a carryover 
>> from MX some sort of DHCP security i’m sure), but its completely 
>> undocumented it does this from what i’ve seen.
>> 
>>   dhcp-relay {
>>   forward-snooped-clients all-interfaces;
>>   server-group {
>>   CAMPUS {
>>   192.168.168.168;
>>   }
>>   }
>>   active-server-group CAMPUS;
>>   route-suppression {
>>   destination;
>>   }
>>   group LOCAL-NETS {
>>   interface ge-5/0/0.304;
>>   interface irb.9;
>>   }
>>   }
>> }
>> 
>> 
>> the route-suppression destination statement also prevents it from installing 
>> access-internal host routes and permanent ARP entries for every DHCP lease.
>> 
>> 
>> will
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> Chris Jones, JNCIE-ENT #272 / JNCIP-SP
> SDN Engineer
> www.sdnessentials.com
> Cell: 858-888-0373
> E-Mail: ch...@sdnessentials.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] VPN into M7i

[Ben Dale]

No Panny, the only VPN support on M-Series is IPSEC.

I would recommend a 3rd-party client like Shrewsoft 


On 17 Sep 2014, at 8:55 pm, Panny Malialis  wrote:

> Hello,
> 
> I'm looking for a simple example of a VPN into a Junos device with an ASII 
> pic from a Mac or PC (L2TP/PPTP) but can't seem to find anything?
> 
> Is this even possible?
> 
> Many Thanks
> 
> Panny Malialis
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] BGP Peer formatting

[Ben Dale]

On 10 Sep 2014, at 7:54 am, Scott Harvanek  wrote:

> This is a silly/OCD question;
> 
> I've faced this before and I can't recall how it was "prettied" up...
> 
> If I recall there is a way to pretty up the formatting of show bgp summary;
> 
> Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
> State|#Active/Received/Accepted/Damped...
> XXX.XXX.XXX.XXX   X4463666 120866   0   0 5w3d 
> 9:31:20 Establ
>  inet.0: 272410/510233/510233/0
> 
> To remove the line break / fix the table formatting.  I've tried adjusting 
> screen-width with no joy.
> 
> Halp?

There's a few ways to neaten it, but it's a case of which information you can 
live without:

show bgp summary | except inet 
show bgp group summary | match l:

Failing that, I just hacked up an op script to only show a summarised version 
from each peer - output here:

https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.md

Code here:

https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax

The script *should* sum all the prefixes from each RIB into a single summarised 
number per peer, but I haven't had a chance to test it too thoroughly yet.  
Feedback/Pull Requests welcome.

Cheers,

Ben



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

Re: [j-nsp] rpm / ip-monitoring

[Ben Dale]

Okay, I'm still sure this can be made to work ; )

I'm still a little hazy on your setup though - based on your email:
You have a local line which gets an address via DHCP and a default gateway with 
a preference of 12
You then also receive another default via BGP over an IPSEC tunnel over this 
same local line interface with a preference of 170
You then have an MPLS service/Native VPN which receives another BGP-sourced 
default route, presumably also with a preference of 170

If that is the case, configure a static with high preference (>170) pointing to 
your MPLS service/Native VPN, and override this with the lower preference route 
via your ip-monitoring policy on local-line/Internet failure - it should still 
work exactly as described, unless I'm missing something else?

Ben


On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg 
mailto:matt...@gyllenvarg.se>> wrote:

Ben

Close but no cigar.

The IPsec also receives a default via BGP so that works like a charm. No need 
for interface routing.

The thing is that we use the local line for Internet use, so the primary 
default route goes out that way.
The IPsec is there if the Native VPN line fails.

So, what I want this ip-monitor/rpm to do is fail over the local internet to 
the Native VPN in case the local line is broken some how.

Regards
Mattias



On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale 
mailto:bd...@comlinx.com.au>> wrote:
Hi Mattias,

It is still possible to bend it to your will ; )

I may be misunderstanding your topology, but essentially you have a Primary 
link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL 
connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back 
to your head office.  Are you trying to move the default route to your IPSEC 
tunnel interface, or the underlying "cheap line"?

You could try the following:

Set up a static default with a high metric (so that it will lose to both DHCP 
and BGP) via your IPSEC tunnel/underlying link.  If the underlying link is not 
point-to-point (eg: you will need to know the far-side IP), you can point it 
down your IPSEC tunnel, or anywhere else - it should never actually get used):

set routing-options static route 0.0.0.0/0<http://0.0.0.0/0> next-hop at-1/0/0.0
set routing-options static route 0.0.0.0/0<http://0.0.0.0/0> preference 190

Then in your ip-monitoring policy, you can override this dummy route with a 
better metric than both BGP and DHCP:

set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet
set services ip-monitoring policy Local-Internet-Test then preferred-route 
route 0.0.0.0/0<http://0.0.0.0/0> next-hop at-1/0/0.0
set services ip-monitoring policy Local-Internet-Test then preferred-route 
route 0.0.0.0/0<http://0.0.0.0/0> preferred-metric 1

Now when your test fails (even if BGP does not):

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

0.0.0.0/0<http://0.0.0.0/0> *[Static/1] 00:13:15, metric2 0
> via at-1/0/0.0
[Access-Internal/12] 00:21:45
> to 192.168.1.2 via at-1/0/0.0
[BGP/170] 2d 21:51:10, localpref 100
AS path: 65500 I, validation-state: unverified
> to 172.30.3.2 via ge-0/0/3.0


Cheers,

Ben

On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg 
mailto:matt...@gyllenvarg.se>> wrote:

Even is the default routes are both from dynamic protocols (BGP and DHCP).

For a regular static this is perfect.

No such luck in this sollution.

//Mattias


On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale 
mailto:bd...@comlinx.com.au>> wrote:
Rather than making configuration changes, if you're running recent code (12.1) 
on branch SRX, have a look at the preferred-route option in ip-monitoring.

You can override your default route dynamically based on the RPM failing, 
without having to override config.

The day this is feature (and ip-monitoring in general) is merged back down to 
mainline Junos will be a glorious one...

Cheers,

Ben

On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg 
mailto:matt...@gyllenvarg.se>> wrote:

> I have looked over these and they are the basis of the configuration I am
> using.
>
> The setup is advanced in some senses.
>
> The Primary link is a to an IP-VPN running BGP to the "mpls cloud" of a
> global operator.
> So, from there I get a default that I override with a static OR dynamic
> default to a local Internet connection that also serves as backup via IPsec
> (BGP on top of that too but peers with a HUB node and not the "cloud").
>
> As the local internet is just a cheap line, I do not have the luxury of BGP
> and so must use some other metod like this one.
>
> What I would have want is to have the ip-monitor not actually disable the
> inte

Re: [j-nsp] rpm / ip-monitoring

[Ben Dale]

Hi Mattias,

It is still possible to bend it to your will ; )

I may be misunderstanding your topology, but essentially you have a Primary 
link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL 
connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back 
to your head office.  Are you trying to move the default route to your IPSEC 
tunnel interface, or the underlying "cheap line"?

You could try the following:

Set up a static default with a high metric (so that it will lose to both DHCP 
and BGP) via your IPSEC tunnel/underlying link.  If the underlying link is not 
point-to-point (eg: you will need to know the far-side IP), you can point it 
down your IPSEC tunnel, or anywhere else - it should never actually get used):

set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0
set routing-options static route 0.0.0.0/0 preference 190

Then in your ip-monitoring policy, you can override this dummy route with a 
better metric than both BGP and DHCP:

set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet
set services ip-monitoring policy Local-Internet-Test then preferred-route 
route 0.0.0.0/0 next-hop at-1/0/0.0
set services ip-monitoring policy Local-Internet-Test then preferred-route 
route 0.0.0.0/0 preferred-metric 1

Now when your test fails (even if BGP does not):

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

0.0.0.0/0 *[Static/1] 00:13:15, metric2 0
> via at-1/0/0.0
[Access-Internal/12] 00:21:45
> to 192.168.1.2 via at-1/0/0.0
[BGP/170] 2d 21:51:10, localpref 100
AS path: 65500 I, validation-state: unverified
> to 172.30.3.2 via ge-0/0/3.0


Cheers,

Ben

On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg 
mailto:matt...@gyllenvarg.se>> wrote:

Even is the default routes are both from dynamic protocols (BGP and DHCP).

For a regular static this is perfect.

No such luck in this sollution.

//Mattias


On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale 
mailto:bd...@comlinx.com.au>> wrote:
Rather than making configuration changes, if you're running recent code (12.1) 
on branch SRX, have a look at the preferred-route option in ip-monitoring.

You can override your default route dynamically based on the RPM failing, 
without having to override config.

The day this is feature (and ip-monitoring in general) is merged back down to 
mainline Junos will be a glorious one...

Cheers,

Ben

On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg 
mailto:matt...@gyllenvarg.se>> wrote:

> I have looked over these and they are the basis of the configuration I am
> using.
>
> The setup is advanced in some senses.
>
> The Primary link is a to an IP-VPN running BGP to the "mpls cloud" of a
> global operator.
> So, from there I get a default that I override with a static OR dynamic
> default to a local Internet connection that also serves as backup via IPsec
> (BGP on top of that too but peers with a HUB node and not the "cloud").
>
> As the local internet is just a cheap line, I do not have the luxury of BGP
> and so must use some other metod like this one.
>
> What I would have want is to have the ip-monitor not actually disable the
> interface and just set the admin-distance for it to the worst level.
>
> That way the test would still work as it requests the packet be sent by the
> exact interface, but no other traffic would take this route unless all
> other options are down.
>
> //Mattias
>
>
>
> On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor 
> mailto:darre...@outlook.com>>
> wrote:
>
>> A small topology diagram would help so we could figure out exactly what
>> this interface points to. Not sure if its in the path or not. If it is,
>> then the below comments already state what the problem is.
>>
>> Thanks
>> Darren
>> http://www.mellowd.co.uk/ccie
>>
>>
>>
>>> Date: Wed, 27 Aug 2014 17:52:02 -0700
>>> From: gonna...@gmail.com<mailto:gonna...@gmail.com>
>>> To: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
>>> Subject: Re: [j-nsp] rpm / ip-monitoring
>>>
>>> Instead of disabling the interface, can you just alter routing to avoid
>>> that path, but RPM could still test since that interface would still be
>> up?
>>>
>>> -Mike Gonnason
>>>
>>>
>>> On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen 
>>> mailto:ty...@adap.tv>>
>> wrote:
>>>
>>>> Good point.  I glossed over that a bit.
>>>>
>>>> In that case, you won't even be able 

Re: [j-nsp] rpm / ip-monitoring

[Ben Dale]

Rather than making configuration changes, if you're running recent code (12.1) 
on branch SRX, have a look at the preferred-route option in ip-monitoring.

You can override your default route dynamically based on the RPM failing, 
without having to override config.  

The day this is feature (and ip-monitoring in general) is merged back down to 
mainline Junos will be a glorious one...

Cheers,

Ben

On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg  wrote:

> I have looked over these and they are the basis of the configuration I am
> using.
> 
> The setup is advanced in some senses.
> 
> The Primary link is a to an IP-VPN running BGP to the "mpls cloud" of a
> global operator.
> So, from there I get a default that I override with a static OR dynamic
> default to a local Internet connection that also serves as backup via IPsec
> (BGP on top of that too but peers with a HUB node and not the "cloud").
> 
> As the local internet is just a cheap line, I do not have the luxury of BGP
> and so must use some other metod like this one.
> 
> What I would have want is to have the ip-monitor not actually disable the
> interface and just set the admin-distance for it to the worst level.
> 
> That way the test would still work as it requests the packet be sent by the
> exact interface, but no other traffic would take this route unless all
> other options are down.
> 
> //Mattias
> 
> 
> 
> On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor 
> wrote:
> 
>> A small topology diagram would help so we could figure out exactly what
>> this interface points to. Not sure if its in the path or not. If it is,
>> then the below comments already state what the problem is.
>> 
>> Thanks
>> Darren
>> http://www.mellowd.co.uk/ccie
>> 
>> 
>> 
>>> Date: Wed, 27 Aug 2014 17:52:02 -0700
>>> From: gonna...@gmail.com
>>> To: juniper-nsp@puck.nether.net
>>> Subject: Re: [j-nsp] rpm / ip-monitoring
>>> 
>>> Instead of disabling the interface, can you just alter routing to avoid
>>> that path, but RPM could still test since that interface would still be
>> up?
>>> 
>>> -Mike Gonnason
>>> 
>>> 
>>> On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen 
>> wrote:
>>> 
 Good point.  I glossed over that a bit.
 
 In that case, you won't even be able to test if it's working or not as
>> you
 have disabled it (as Andrew points out).  I suppose you could write a
 script that re-enables the interface every hour or twenty four hours or
 whatever interval, then the RPM probe would just shut it back down if
>> it's
 not fixing, but that seems a bit of a hassle.
 
 --tc
 
 
 On Wed, Aug 27, 2014 at 4:35 PM, Andrew Jones 
>> wrote:
 
> Surely the test will never recover without intervention, as the
>> interface
> it uses gets disabled?
> 
> 
> On 28.08.2014 02:28, Tyler Christiansen wrote:
> 
>> I could be mistaken, but I believe it automatically reverts when the
 test
>> is successful unless you specify no-preempt.
>> 
>> 
>> On Wed, Aug 27, 2014 at 12:50 AM, Mattias Gyllenvarg <
>> matt...@gyllenvarg.se>
>> wrote:
>> 
>> Dear List
>>> 
>>> I have a rpm /ip-monitor setup that is supposed to test the
>> function
 of a
>>> local internet line (ping internet destination).
>>> 
>>> And disable it if it is not responding.
>>> 
>>> This works fine BUT, how do I get it to re-enable when it is
>> working
>>> again.
>>> 
>>> I need this to work with DHCP so I cannot work with a default
>> route.
>>> 
>>> 
>>> **
>>> 
>>> services {
>>>rpm {
>>>probe Internet {
>>>test PING-GOOGLE-DNS {
>>>target address 8.8.8.8;
>>>probe-count 5;
>>>probe-interval 2;
>>>test-interval 20;
>>>thresholds {
>>>total-loss 4;
>>>}
>>>destination-interface fe-0/0/3.0;
>>>}
>>>}
>>>}
>>>ip-monitoring {
>>>policy Local-Internet-Test {
>>>match {
>>>rpm-probe Internet;
>>>}
>>>then {
>>>interface fe-0/0/3 {
>>>disable;
>>>}
>>>}
>>>}
>>>}
>>> }
>>> 
>>> *
>>> 
>>> --
>>> *Med Vänliga Hälsningar / Best Regards*
>>> *Mattias Gyllenvarg*
>>> ___
>>> 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] Viability of EX4300 in a primarily l3 environment?

[Ben Dale]

I believe this to be the case as well - when you run a mixed-mode virtual 
chassis (45/42) you end up moving the entire chassis to the lowest common 
denominator (45xx) and reducing your ARP table size down to 8K along with 
associated routing entries .

There's a nice side-by-side of the whole range here:

http://www.juniper.net/fragment.do?xmlPath=/cn/zh/products-services/switching/ex-series/modules/product-comparison.xml&xslPath=/shared/xsl/product-compare/compare.xsl&compPP=true&height=300

Ben

On 7 Aug 2014, at 3:07 am, Tyler Christiansen  wrote:

> On Wed, Aug 6, 2014 at 6:59 AM, Paul S.  wrote:
> 
>> That lower arp limit is precisely why we're looking at the 4300, though.
>> 
>> Which, by the way, does anyone happen to know if the arp limit stays the
>> same when the 4200s are put into VC mode -- or do they increase at all?
>> 
> ​
> I believe ARP is handled by the RE, so in a virtual chassis, the ARP limit
> would be the same.  I could be wrong, though.
> 
> --tc
> ​
> 
> 
>> On 8/6/2014 午後 10:31, Scott Granados wrote:
>> 
>>> +1 on the 4200.
>>> 
>>> Had very good luck with the 4200 series.  Also had good luck with the
>>> 4300 but there were some bugs.  In a basic operation mode though they are
>>> quite stable.  That being said I was really pleased with the 4200 and you
>>> might want to check them out assuming the lower arp limit isn’t an issue.
>>> 
>>> On Aug 6, 2014, at 7:30 AM, Yucong Sun  wrote:
>>> 
>>> I used ex4200 to do exactly what you did before.  ex4200 releases is
 pretty
 rock solid, feature extensive, although with lower arp entry limits.
 
 Given the price difference maybe you can connect each l2 domain to its
 own
 ex4200 and have them do ospf routing among selves, which maybe give you
 better failure tolerances compare to a single core.
 
 
 On Wed, Aug 6, 2014 at 6:35 PM, Giuliano Cardozo Medalha <
 giuli...@wztech.com.br> wrote:
 
 we are using ex4300 with the last release available
> 
> the setup is pretty simple using virtual chassis, lag, L3 and poe
> 
> it works pretty fine and we do not have any serious problems
> 
> sometimes the poe controller goes down but we have a case oppened in
> jtac
> to try solve it
> 
> Sent from my iPhone
> 
> On 06/08/2014, at 07:15, Sebastian Wiesinger <
>> juniper-...@ml.karotte.org>
>> 
> wrote:
> 
>> * Paul S.  [2014-08-02 05:18]:
>> 
>>> Hi folks,
>>> 
>>> We're considering the EX4300 to run routing (l3) for a few
>>> hypervisors of ours that are connected via l2.
>>> 
>>> Primarily interested due to the rather massive arp limit (64, 000)
>>> on the switch, but we've been told (and searched for ourselves to
>>> find out) that the 4300 platform has been plagued by random issues
>>> since launch.
>>> 
>> I don't have hands-on experience but I looked at the EX4300 platform
>> for a new deployment. If you look at the current release notes:
>> 
>> 
>> http://www.juniper.net/techpubs/en_US/junos13.2/
> information-products/topic-collections/ex-qfx-series/
> release-notes/ex-qfx-series-junos-release-notes-13.2X51-D25.pdf
> 
>> There are a lot of (serious) bugs still getting fixed so I'm not sure
>> how mature this platform is. One big reason for that is probably
>> because EX4300 uses other chips than the rest of the 4xxx series
>> (Broadcom).
>> 
>> 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
> 
> ___
 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
>> 
> 
> 
> 
> -- 
> 
> *Tyler Christiansen | Technical Operations*
> tyler @adap.tv  | www.adap.tv
> *m :* 864.346.4095
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-ns

Re: [j-nsp] config msti vlan range?

[Ben Dale]

Hi Victor,

It's pretty straightforward:

set protocols mstp msti 5 vlan [10-50 60-90]

Cheers,

Ben

On 22 Jul 2014, at 1:22 pm, Victor Sudakov  wrote:

> Colleagues,
> 
> I have now the following configuration:
> 
> admin@sw-km270# show protocols mstp msti 2
> vlan [ management ENERGY NATEKS PASOLINK-Management MNCS ITSO ];
> 
> How do I replace the explicit list of vlans with a range like
> 10500 ?  What's the configuration command syntax?
> 
> I suppose it's a general Junos syntax question (using ranges of
> values) but somehow I cannot find the obvious. Thanks a lot for helping.
> 
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] Could you pls clarify a bit about OAM for link fault management?

[Ben Dale]

Hi Victor,

Something like this should do the trick once you've configured it on both ends:

set protocols oam ethernet link-fault-management action-profile UDLD event 
link-adjacency-loss
set protocols oam ethernet link-fault-management action-profile UDLD action 
syslog
set protocols oam ethernet link-fault-management action-profile UDLD action 
link-down
set protocols oam ethernet link-fault-management interface ge-0/0/23.0 
apply-action-profile UDLD

We had a similar issue to solve at some sites connected via Free-Space Optics 
units.

Cheers,

Ben

On 11 Jul 2014, at 12:45 pm, Victor Sudakov  wrote:

> Colleagues,
> 
> I have pairs of EX4200 switches connected via third party MUXes. When
> the actual physical medium goes down, the MUXes do not shutdown their
> Ethernet interfaces. So I need some sort of point-to-point L2 link fault
> management between the EX4200s.
> 
> I thought OAM could be used for this purpose. However after reading
> http://www.juniper.net/techpubs/en_US/junos9.4/topics/task/configuration/lfm-ethernet-oam-configuring-ex-series-cli.html
> and references therein I am a bit confused. I don't need those
> "remote-loopback" and "allow-remote-loopback" features, profiles and
> other complicated stuff, do I? 
> 
> All I need from OAM is some kind of L2 keepalive. Do you have a good
> configuration example?
> 
> Thanks a lot for any input.
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] warning: dhcp-service subsystem not running - not needed by configuration

[Ben Dale]

Hi Victor,

There are actually two completely different DHCP daemons in Junos now - dhcpd 
and jdhcpd.

When you configure statements under system / services / dhcp you are using 
dhcpd and will need to use:

show system services dhcp server binding
restart dhcp

When you configure statements under system / services / dhcp-local-server you 
are affecting jdhcpd and need to use:

show dhcp server binding 
restart dhcp-service

The two are mutually exclusive (for obvious reasons).

Cheers,

Ben

On 7 Jul 2014, at 8:32 pm, Victor Sudakov  wrote:

> Dave Bell wrote:
>> As per 
>> http://forums.juniper.net/t5/Ethernet-Switching/DHCP-service/td-p/14917
>> 
>> try running
>> 'restart dhcp gracefully'
> 
> I have tried that, makes no difference:
> 
> admin@sw-km337> restart dhcp gracefully
> Dynamic Host Configuration Protocol process started, pid 65064
> 
> {master:0}
> admin@sw-km337> show dhcp server binding
> warning: dhcp-service subsystem not running - not needed by configuration.
> 
> {master:0}
> admin@sw-km337>
> 
> From /var/log/messages:
> 
> Jul  7 17:29:30  sw-km337 mgd[65061]: UI_RESTART_EVENT: User 'admin' 
> restarting daemon 'Dynamic Host Configuration Protocol process'
> Jul  7 17:29:30  sw-km337 init: dhcp (PID 65062) exited with status=0 Normal 
> Exit
> Jul  7 17:29:30  sw-km337 init: dhcp (PID 65064) started
> 
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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 FBR and destination nat

[Ben Dale]

Hi Yuriy,

This exact configuration is documented quite thoroughly in Recipe 12 in the Day 
One: Juniper Ambassadors' Cookbook for Enterprise found here:

http://www.juniper.net/us/en/community/junos/training-certification/day-one/networking-technologies-series/cookbook-for-enterprise/

Credit for this particular one (and the 5 different solutions provided!) goes 
to Peter Klimai! 

Cheers,

Ben

On 26 Jun 2014, at 11:39 pm, Yuriy B. Borysov  wrote:

> Hello!
> 
> I have two connections to the ISP on SRX220H (12.1X45-D15.5). 
> 
> ISP1 - 1.1.1.2 on my side, 1.1.1.1 - gw (int pp0.0)
> ISP2 - 2.2.2.2 on my side, 2.2.2.1 - gw (int pp0.1)
> 
> Default gateway looks in to pp0.1 
> 
> I need to do destination nat to host in lan PC (10.121.0.101) via non 
> default ISP1 (int pp0.0).
> 
> First of all, configure FBR for LAN network via pp0.0:
> 
> routing-options 
> interface-routes {
>rib-group inet all;
>}
> 
> .
> 
> rib-groups {
>all {
>import-rib [ inet.0 cat.inet.0 ];
>   }
> 
> .
> 
> cat {
>instance-type forwarding;
>routing-options {
>   static {
> route 0.0.0.0/0 next-hop pp0.0;
>   }
>   }
> }
> 
> ..
> 
> firewall family inet filter cat
> term route-to-cat {
>from {
>source-address {
>10.121.0.0/24;
>}
>}
>then {
>routing-instance cat;
>}
> }
> term default {
>then accept;
> }
> 
> .
> 
> interfaces ge-0/0/0.99 
> description cctv;
> vlan-id 99;
> family inet {
>mtu 1500;
>filter {
>input cat;
>}
>address 10.121.0.200/24;
> }
> 
> .
> 
> security policies from-zone cctv to-zone untrust 
> policy proxmox-inet {
>match {
>source-address any;
>destination-address any;
>application any;
>}
>then {
>permit;
>}
> }
> 
> security policies from-zone untrust to-zone cctv
> policy cctv-access {
>match {
>source-address any;
>destination-address any;
>application any;
>}
>then {
>permit;
>}
> }
> 
> 
> Everything looks OK, outgoing traffic goes via pp0.0
> 
> After that, configure dest nat:
> 
> pool cctv-rdr {
>address 10.121.0.101/32;
> }
> 
> rule-set cctv-rdr {
>from interface pp0.0;
>rule cctv-rdr { 
>match {
>destination-address 1.1.1.2/32;
>}
>then {
>destination-nat {
>pool {
>cctv-rdr;
>}
>}
>}
>}
> }
> 
> 
> Traffic comes through pp0.0 but returns through pp0.1
> That breaks port forward (due to uplink urpf).
> 
> Where I'm wrong in my configuration?
> 
> Thanks!
> 
> 
> -- 
> WBR, Yuriy B. Borysov
> YOKO-UANIC | YOKO-RIPE
> ___
> 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] Small P Router Recommendations

[Ben Dale]

On 5 Jun 2014, at 12:00 pm, Geoff Crawford  wrote:

> Hi guys!
> 
> I'm a Juniper fan too, but I'll take a non-Juniper answer today. Seems to be 
> an MPLS heavily oriented list, so I figured you guys would know.
> 
> I'm sure we'd all love an EX3200 take could run LDP, pack more than 1 label 
> and do it over aggregated interfaces. Is anyone else making a box that can do 
> that?

If you're after a switch that'll do MPLS/L3VPN, check out the QFX5100.  All 
10/40G though which might not be what you're after.

> 
> Need to aggregate a bunch of SRXs, and drag it back to the office. I was 
> thinking, would there be any ill-effects to building a larger subnet and 
> connecting all the SRXes together with a standard L2 switch, and then have 
> the switch uplink to the closest P router? Sure would be nice for adding more 
> boxes in the future, no need to touch the P.

Why not just run another SRX as a PE and aggregate via that?  The MPLS 
feature-set is pretty comprehensive - L2VPN, VPLS, L3VPN, L2Circuit etc.

> 
> Oh, and have they got L3VPN/VPLS figured out on the ACX yet?

L3VPN works just fine, but L2 services are "coming soon".

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

Re: [j-nsp] OSPF question

[Ben Dale]

On 5 Jun 2014, at 2:35 am, R S  wrote:

> Which can be the reason why among two MX (using irb) running OSPF there are 
> around 100-150 OSPF Link State Update Packet retransmission per day ?
> No link is interrupted, no link is fauly/CRC...
> 
> My customer is receiving traps on its monitoring systems and I've no clear 
> clue about the reason...
> Any reccomendation/experience ?
> 
> Thank you
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

If "something" is happening that often, take a look at:

show ospf log

show ospf statistics

and see if they provide you any hints, but yeah, otherwise traceoptions.

Cheers,

Ben


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

Re: [j-nsp] MX104 with full BGP table problems

[Ben Dale]

> 
> You can cool a Sandy/Ivy Bridge CPU in a laptop at +40C degrees in direct
> sunlight outside (e.g. Panasonic Thoughbook) and they can't cool the same
> type of CPU in a datacenter with ~20-22 degrees ambient temperature and
> very powerful fans that are present in a router? I doubt it that the Xeon
> versions of those CPUs produce much more heat. Factor in the fact that they
> can go all SSD and you can have a very small package that can act as a RE
> (think of a very mini mini version of Intel NUC).

The 104s are rated for use in -40 to +65° C and based on the form-factor are 
designed for use in areas a little less comfortable than your average data 
centre (places where MX80s are not designed to go like de-mountables/cabinets). 

> There has to be another reason for the crappy REs in these routers.

Yeah, I'm kinda surprised the 104s maintained the same CPU, but I guess it 
meant much less code re-spin.  

Looking forward to the day when there is a commonish RE (eg: intel-based) for 
all REs across the fleet.  You would think this would save a pile of 
development work...


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

Re: [j-nsp] ACX1xxx Images

[Ben Dale]

Hi Skeeve,

The ACX1100 AC units have dual PSUs built-in - there are two C16 sockets on the 
front left of the unit.

I can send you a photo, but there is a nice drawing on Page 4 (and 43) of the 
hardware guide:

http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/acx-series/acx1000/hwguide/acx1000-hwguide.pdf

Cheers,

Ben

On 14 May 2014, at 8:56 am, Skeeve Stevens 
 wrote:

> Hey all,
> 
> I am trying to find a picture of the ACX1000 and ACX1100 so I can see how
> they do the redundant power that they claim in the sales information, but
> all the images on the Juniper Image Library and google are of DC units.
> 
> If anyone could shoot me a couple of photos, that would be awesome.
> 
> If someone could also confirm they do redundant power, that would be
> fantastic.
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
> 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> 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] Confusing terminology for LSPs in Junos

[Ben Dale]

On 10 May 2014, at 2:28 pm, Tyler Christiansen  
wrote:

> Look at it from the perspective of where the traffic is entering the LSP,
> not the perspective of the router.
> 
> When the traffic is encapsulated (enters the LSP), that's the ingress LSP.
> When a packet leaves an LSP, that is the egress LSP.  The fact that it
> enters or exits the router (and where it does so) is inconsequential in the
> context of discussing the direction of an LSP.

Following on from Tyler's points, think also on the fact that an LSP is 
uni-directional - ingress for the head-end where the LSP is signalled from and 
where traffic enters and egress for the termination point where traffic exits.  

> On Fri, May 9, 2014 at 8:23 PM, John Neiberger  wrote:
> 
>> I just took a Juniper MPLS and VPNs course and I have a question about the
>> ingress and egress types of LSPs. The terminology makes zero sense to me.
>> The LSP that is used to send traffic is called the ingress LSP, and the LSP
>> used to receive traffic is an egress LSP. How in the heck does that make
>> any sense? It seems exactly backwards. From the perspective of the router,
>> why would egress traffic leave on the ingress LSP and vice versa?
>> 
>> This seems really odd, but I presume there must be a really good reason for
>> it.
>> 
>> 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] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC

[Ben Dale]

Further to Morgan and Andrew's comments, the st0 interface will follow 
whichever interface you have bound to the "external-interface" in your IKE 
Gateway configuration (ge-0/0/0.0 in the AWS example), so if you bind this to a 
reth (and have the st0 interface in the same redundancy group) you'll be golden.



On 6 May 2014, at 10:44 am, Morgan McLean  wrote:

> Andy,
> 
> Assuming you have your own IP space, you put a public address on the
> loopback. Whichever member is active for lo0 will handle the IPSEC if i
> recall.
> 
> Theres some juniper docs on the details. ST0 will always be on which ever
> node is primary.
> 
> Thanks,
> Morgan
> 
> 
> On Mon, May 5, 2014 at 5:37 PM, Andrew Jones  wrote:
> 
>> You don't need to do anything special to make the st0 interface redundant,
>> it will always run on the active node.
>> 
>> 
>> On 06.05.2014 08:38, Andy Litzinger wrote:
>> 
>>> Hi Morgan,
>>> 
>>> I presume that with regards to the loopback you are referring to the
>>> external interface I use as my IPSec peer toward Amazon?
>>> 
>>> what about the internal logical st interface that I need to create in
>>> order
>>> to route my internal traffic into the tunnel?  How do I make that
>>> redundant?
>>> 
>>> thanks!
>>> -andy
>>> 
>>> 
>>> On Mon, May 5, 2014 at 3:30 PM, Morgan McLean  wrote:
>>> 
>>> Use your loopback and put that in a reth.
 
 Thanks,
 Morgan
 
 
 On Mon, May 5, 2014 at 3:23 PM, Andy Litzinger <
 andy.litzinger.li...@gmail.com> wrote:
 
 Hi All,
>  Two related questions.  I have a pair of SRX 3400s in an
> Active/Passive
> cluster.  They rely on an external gateway for internet access (i.e. my
> ISPs don't terminate on the SRXs).  I am setting up redundant tunnels to
> an
> AWS VPC.  Amazon has an example for J-Series (
> 
> http://docs.aws.amazon.com/AmazonVPC/latest/
> NetworkAdminGuide/Juniper.html
> ),
> but I don't think it's for a cluster set-up.
> 
> Here are my questions:
> 
> 1 - If I want to set up a redundant secure tunnel interface (e.g. st0),
> should i bind it to an reth interface?
> 
> 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC?
> Any
> tips or tricks you care to share?
> 
> regards,
> -andy
> ___
> 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] loop detection on EX4200

[Ben Dale]

On 23 Apr 2014, at 1:56 pm, Victor Sudakov  wrote:

> Ben Dale wrote:
>> 
>>> No, LLDP does not work either across the multiplexer. If I configure a
>>> vlan tag on the "default" vlan on the EX42, LLDP starts seeing the
>>> EX42 on the other side.
>>> 
>>> That was the reason I had suggested that the multiplexer did not
>>> forward untagged frames.
>> 
>> That is certainly odd.  Even on a trunked interface with no native-vlan 
>> configured at all, LLDP PDUs should still be sent untagged:
>> 
>> bdale@elow-core-01# show interfaces ge-1/1/5   
>> vlan-tagging;
>> unit 3830 {
>>vlan-id 3830;
>>family inet {
>>address 10.237.18.29/31;
>>}
>>family mpls;
>> }
> 
> This is probably because your interface is in the "vlan-tagging" mode,
> while mine is "family ethernet-switching" mode.

I see the same behaviour on a 4200.  LLDP is always sent untagged:

comlinx@cesw01-all> show configuration interfaces ge-0/0/2  
description "Link to BELL";
unit 0 {
family ethernet-switching;
}

### no VLAN-ID configured on default:

comlinx@cesw01-all> show vlans default  
Name   Tag Interfaces
default   
   ae10.0, ge-0/0/0.0*, ge-0/0/2.0*, ge-0/0/3.0, ge-0/0/11.0
{master:0}

comlinx@cesw01-all> monitor traffic interface ge-0/0/2 layer2-headers matching 
"ether dst 01:80:c2:00:00:0e"  
verbose output suppressed, use  or  for full protocol decode
Address resolution is ON. Use  to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/2, capture size 96 bytes

14:08:16.031851 Out 80:71:1f:e2:17:05 > 01:80:c2:00:00:0e, ethertype LLDP 
(0x88cc), length 74: LLDP, name cesw01-all, length 60
[|LLDP]



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

Re: [j-nsp] loop detection on EX4200

[Ben Dale]

> No, LLDP does not work either across the multiplexer. If I configure a
> vlan tag on the "default" vlan on the EX42, LLDP starts seeing the
> EX42 on the other side.
> 
> That was the reason I had suggested that the multiplexer did not
> forward untagged frames.

That is certainly odd.  Even on a trunked interface with no native-vlan 
configured at all, LLDP PDUs should still be sent untagged:

bdale@elow-core-01# show interfaces ge-1/1/5   
vlan-tagging;
unit 3830 {
vlan-id 3830;
family inet {
address 10.237.18.29/31;
}
family mpls;
}

bdale@elow-core-01# run monitor traffic interface ge-1/1/5 layer2-headers 
matching "ether dst 01:80:c2:00:00:0e"
verbose output suppressed, use  or  for full protocol decode
Address resolution is ON. Use  to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-1/1/5, capture size 96 bytes

13:36:12.180818 Out 5c:5e:ab:0e:7f:15 > 01:80:c2:00:00:0e, ethertype LLDP 
(0x88cc), length 68: LLDP, name elow-core-01, length 54
[|LLDP]


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

Re: [j-nsp] loop detection on EX4200

[Ben Dale]

On 22 Apr 2014, at 2:41 am, Victor Sudakov  wrote:

> Kevin Wormington wrote:
>> Could you not use MSTP or VSTP instead of RSTP?
> 
> Perhaps I'll have to unless I can make the multiplexer forward
> untagged frames.

If the issue is that the multiplexer is not forwarding untagged frames, you'll 
need to use VSTP (aka PVST+).  MSTP will still send PDUs untagged.

If the issue is that the multiplexer is absorbing link-local traffic such as 
STP, then this is a difficult problem to solve.  I would normally suggest using 
something like storm-control with port shutdown, but being that this 
multiplexer will be max 2M of ethernet for the entire interface, tuning storm 
control will be quite difficult (since it is a global setting on EX42).

See if you can get something like LLDP across your multiplexer to a switch on 
the far side - that might point you in the direction of the issue.

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

Re: [j-nsp] SRX550 as MPLS/VPLS platform

[Ben Dale]

Hi Tom,

I'm going through a deployment using a mixture of MX5s and SRX240s PE routers 
right now, and I've been pretty happy with the results.  We're using RSVP-TE 
and BGP to set up L3VPNs, VPLSs and L2VPNs and it's working almost flawlessly. 

So far, the only issues I've encountered with the SRX are:
- BFD at scale - we're seeing sessions flapping when we use BFD on OSPF, the 
RSVP LSP mesh and BGP.  I can't conclusively state it's a CPU issue (our timers 
aren't all that aggressive), but if you were going to scale to any great size, 
this would be something to watch.  As it is, this network only has 12 PEs, but 
I need to do some more lab work to confirm the reason for this.
- Class of Service - the SRX has very limited capabilities compared to the MX - 
if you're looking at providing hierarchical queuing to any of your MPLS 
services, you'll need to move up to MX.  You can use per-unit-schedulers on the 
SRX, but you don't have access to traffic-control-profiles.
- MTUs - if you're using the SFP-1GE PIM (the new generation), the max MTU that 
will commit seems to be 9000.  This isn't a problem in itself, but watch it if 
you're mixing MXs (Max MTU 9192) and OSPF.

Just remember to factor in the advanced BGP license for at least two of your 
SRX550s - you'll need this to support route reflection.

Cheers,

Ben

On 17 Apr 2014, at 5:22 am, Tom Storey  wrote:

> Cost, essentially.
> 
> I have recommended the MX5-MX80 series instead, being a proper routing
> platform,  but was asked to find other options too.
> On 16 Apr 2014 20:07, "Chris Jones"  wrote:
> 
>> Why not an MX instead?
>> 
>> 
>> On Wed, Apr 16, 2014 at 11:41 AM, Tom Storey  wrote:
>> 
>>> Hi everyone.
>>> 
>>> The SRX240 works pretty well as an MPLS/VPLS platform when stuck in
>>> packet mode.
>>> 
>>> I am wondering if the SRX550 operates in a similar way?
>>> 
>>> Has anyone out there used an SRX550 as a slightly more high powered
>>> xPLS platform? Of particular interest it has 10GE modules available
>>> that the SRX240 doesnt have.
>>> 
>>> Thanks.
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>> 
>> 
>> 
>> --
>> Chris Jones
>> JNCIE-ENT #272
>> CCIE# 25655 (R&S)
>> 
> ___
> 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

[Ben Dale]

On 7 Apr 2014, at 6:37 pm, Dave Bell 
mailto:m...@geordish.org>> wrote:

I'm not sure you can do exactly what you are interested in. I would use two 
prefix lists as follows.

policy-options {
prefix-list list1 {
apply-path "interfaces  unit <*> family inet address <*>";
}
prefix-list list2 {
apply-path "interfaces  unit <*> family inet address 
<*>";
}
}


Thanks Dave and Tim - looks like multiple lists will have to do.





On 7 April 2014 02:45, Ben Dale 
mailto:bd...@comlinx.com.au>> wrote:
Dredging up an old thread here, but I have a requirement for an apply-path that 
matches ae* and ge-1/[01]/[0-4] unit * (for a prefix-list).

I must be missing something fundamental about the regex you can use in 
apply-path though, because all combinations I've tried seem to fail.

About as close as I can get to something that actually gives me results is 
"interfaces <[ae|ge-1/0/]*> unit <*> family net address <*>" which isn't all 
that useful.

It doesn't look like apply-path supports any nesting of regexes either eg: 
interfaces <[ae|ge-1/[01]/]*> returns no results at all

Any thoughts?

On 26 Feb 2014, at 1:48 pm, Michael Gehrmann 
mailto:mgehrm...@macquarietelecom.com>> wrote:

> 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<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<mailto: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<mailto:juniper-nsp@puck.nether.net> 
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto: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

[Ben Dale]

Dredging up an old thread here, but I have a requirement for an apply-path that 
matches ae* and ge-1/[01]/[0-4] unit * (for a prefix-list).

I must be missing something fundamental about the regex you can use in 
apply-path though, because all combinations I've tried seem to fail.

About as close as I can get to something that actually gives me results is 
"interfaces <[ae|ge-1/0/]*> unit <*> family net address <*>" which isn't all 
that useful.

It doesn't look like apply-path supports any nesting of regexes either eg: 
interfaces <[ae|ge-1/[01]/]*> returns no results at all

Any thoughts?

On 26 Feb 2014, at 1:48 pm, Michael Gehrmann  
wrote:

> 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] Are IRB interfaces still not functional under SRX?

[Ben Dale]

On the branch at least - if you configure an irb interface, the box will fail 
commit check unless it is in transparent mode and it is only useable for 
management

On 3 Apr 2014, at 7:05 am, Per Westerlund  wrote:

> I'm offline right now, but last time I checked, IRBs with bridge domains (SRX 
> in transparent/L2 mode) were only used for management, no forwarding of 
> transit traffic possible.
> 
> /Per
> 
>> 2 apr 2014 kl. 21:46 skrev Morgan McLean :
>> 
>> Just double checking that IRB interfaces are not able to be used for
>> routing under the SRX3k and 5k series? I have a customer asking to have
>> cabinets uplink directly to the SRX3600 (no cluster), which means I'd have
>> to use bridge domains.
>> 
>> But, I don't think this will even work. Am I correct?
>> 
>> Thanks,
>> Morgan
>> ___
>> 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] Best device to fit for a project

[Ben Dale]

I've always felt that clusters in the branch isn't much of an advantage 
availability-wise when you only have a single WAN service.  You still you have 
to have a way of delivering a single carrier port into two physical boxes, 
which generally involves more hardware (switches) to try and move the SPOF 
closer to the NTU for very little gain.

And if the branch is small enough that you're actually connecting devices 
directly to the SRX (say a 240), then you actually make things more complicated 
than they need to be.

Granted if you trust your branch staff to move a cable for you when node0 dies 
and it saves you a long drive, then it's probably worthwhile.

On 2 Apr 2014, at 3:01 pm, Morgan McLean 
mailto:wrx...@gmail.com>> wrote:

As already mentioned, run an SRX220 cluster (two devices) at each branch, and 
then use something like an SRX1400 for the core. Could even run two of them at 
the core in a cluster and be super fancy :).

Thanks,
Morgan


On Tue, Apr 1, 2014 at 3:40 PM, Ben Dale 
mailto:bd...@comlinx.com.au>> wrote:
Check out AutoVPN as well:

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-autovpn-spoke-authentication-understanding.html

It's hub-and-spoke (as opposed to full-mesh) and a little simpler than GDOI, 
but you do take the overhead of having to managing PKI across your fleet.

Ben

On 1 Apr 2014, at 6:17 pm, Per Westerlund 
mailto:p...@westerlund.se>> wrote:

> Another possibility is a cluster of units to take care of the dual PSU 
> requirement.
>
> For the low end you can mount 2 SRX100 in a 1U tray, and make them a cluster. 
> Will not handle 100Mbps IPsec, but will do 10 Mbps easily, perhaps 50 Mbps 
> depending on how you count and configure (50 bidir is actually 100 in 
> processing power etc). None of the branch SRX have crypto chip, all IPsec is 
> done in CPU, have to watch that.
>
> Clustered 220/240 would take care of dual PSU for 100 Mbps IPsec, but 
> unfortunately two boxes.
>
> I don’t have pricing available and don’t run any of these myself, but what 
> about a small MX5 (or similar) with service-card (MS-MIC) for the hub site? 
> It claims throughput of 9Gbps. Would that fit the bill instead of the bigger 
> SRX boxes?
>
> /Per
>
> PS: With plain IPsec, no internet tunnel requirement, and SRX everywhere, you 
> can use GDOI (Group VPN, Cisco: GET VPN), but unfortunately that does not 
> work with clusters. Can’t have both right now, sorry. Saves lots of problems 
> managing pre-shared keys etc.
>
> 1 apr 2014 kl. 09:36 skrev Ben Dale 
> mailto:bd...@comlinx.com.au>>:
>
>> SRX550 is pretty much your only option in the branch if you require dual 
>> power supply, but is in every other way overspecced (and thus priced) for 
>> the remainder of your branch requirements.  If you can do without the RPS, 
>> then I'd go with either an SRX220 or 240, which will easily handle the 
>> remainder of your requirements.
>>
>> Are you sure you want 7-10GBps of IPSEC?  I'm not sure what market you're 
>> in, but I don't imagine a 10Gbps WAN port is particularly cheap from your 
>> carrier (since you list price as being important).
>>
>> If you absolutely need this much crypto though, then you'll be looking at 
>> somewhere between an SRX650 and an SRX1400 plus appropriate 10G XPM/IOC.
>>
>> As for scalability - no issues - the 650 will support up to 3,000 tunnels 
>> and the 1400 was good for about 15,000 last time I looked - it's probably 
>> gotten better since then.
>>
>> Ben
>>
>> On 1 Apr 2014, at 4:37 pm, R S 
>> mailto:dim0...@hotmail.com>> wrote:
>>
>>> For a project (70 branch offices and 2 Headquarters connected in an 
>>> hub&spoke topology with IPSEC over MPLS among branch and HQ) I’m looking 
>>> for the best device which cover the following items:
>>>
>>> Branch:
>>> Single device
>>> At least two Ethernet interfaces (WAN/LAN)
>>> Ipsec supporting 10-50-100 Mbs
>>> Routing protocols such as BGP-OSPF
>>> NAT
>>> Redundant power supply (some site not but in principle I need it)
>>>
>>> HeadQuarter:
>>> Single device with XE intf
>>> At least two Ethernet interfaces (WAN/LAN)
>>> IPSEC supporting up to 7-10 Gbs of IPSEC (the sum of branches)
>>> Routing protocols such as BGP-OSPF
>>> NAT
>>> Redundant power supply
>>>
>>> Firewall is not needed, MPLS will be runned by the carrier, the devices and 
>>> IPSEC are on-top of MPLS.
>>> I’m looking for the best solution in terms of scalability and price (very 
>>> im

Re: [j-nsp] system archival configuration and filenames

[Ben Dale]

Hi Victor,

This was discussed here a little while back - in short there is no way to 
archive them unzipped them except to have a server-side script monitoring the 
directory you FTP to and doing it for you.

As for the naming, that is odd - the standard format for these files is:

router-name_juniper.conf.n.gz_MMDD_HHMMSS

Cheers,

Ben

On 2 Apr 2014, at 4:11 am, Victor Sudakov  wrote:

> Dear Colleagues,
> 
> I have configured the following:
> 
> admin@sw-us-parabel> show configuration system archival
> configuration {
>transfer-on-commit;
>archive-sites {
>"ftp://cfg@10.14.140.125/ " password "$9$WqR8X-4oGiHm24"; ## 
> SECRET-DATA
>}
> }
> 
> on an EX4200 with JUNOS 12.3R3.4.
> 
> The files which end up on the FTP server look like this: 
> 
> acc_transfer_link_3775
> acc_transfer_link_3811
> acc_transfer_link_3874
> 
> and they come gzipped.
> 
> How can I configure the archived configs to be a) plain text (not gzipped)
> and b) somehow related to the name of the switch?
> 
> Thanks in advance for any ideas.
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Best device to fit for a project

[Ben Dale]

Check out AutoVPN as well:

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-autovpn-spoke-authentication-understanding.html

It's hub-and-spoke (as opposed to full-mesh) and a little simpler than GDOI, 
but you do take the overhead of having to managing PKI across your fleet.

Ben

On 1 Apr 2014, at 6:17 pm, Per Westerlund  wrote:

> Another possibility is a cluster of units to take care of the dual PSU 
> requirement.
> 
> For the low end you can mount 2 SRX100 in a 1U tray, and make them a cluster. 
> Will not handle 100Mbps IPsec, but will do 10 Mbps easily, perhaps 50 Mbps 
> depending on how you count and configure (50 bidir is actually 100 in 
> processing power etc). None of the branch SRX have crypto chip, all IPsec is 
> done in CPU, have to watch that.
> 
> Clustered 220/240 would take care of dual PSU for 100 Mbps IPsec, but 
> unfortunately two boxes.
> 
> I don’t have pricing available and don’t run any of these myself, but what 
> about a small MX5 (or similar) with service-card (MS-MIC) for the hub site? 
> It claims throughput of 9Gbps. Would that fit the bill instead of the bigger 
> SRX boxes?
> 
> /Per
> 
> PS: With plain IPsec, no internet tunnel requirement, and SRX everywhere, you 
> can use GDOI (Group VPN, Cisco: GET VPN), but unfortunately that does not 
> work with clusters. Can’t have both right now, sorry. Saves lots of problems 
> managing pre-shared keys etc.
> 
> 1 apr 2014 kl. 09:36 skrev Ben Dale :
> 
>> SRX550 is pretty much your only option in the branch if you require dual 
>> power supply, but is in every other way overspecced (and thus priced) for 
>> the remainder of your branch requirements.  If you can do without the RPS, 
>> then I'd go with either an SRX220 or 240, which will easily handle the 
>> remainder of your requirements.
>> 
>> Are you sure you want 7-10GBps of IPSEC?  I'm not sure what market you're 
>> in, but I don't imagine a 10Gbps WAN port is particularly cheap from your 
>> carrier (since you list price as being important).  
>> 
>> If you absolutely need this much crypto though, then you'll be looking at 
>> somewhere between an SRX650 and an SRX1400 plus appropriate 10G XPM/IOC.
>> 
>> As for scalability - no issues - the 650 will support up to 3,000 tunnels 
>> and the 1400 was good for about 15,000 last time I looked - it's probably 
>> gotten better since then.
>> 
>> Ben
>> 
>> On 1 Apr 2014, at 4:37 pm, R S  wrote:
>> 
>>> For a project (70 branch offices and 2 Headquarters connected in an 
>>> hub&spoke topology with IPSEC over MPLS among branch and HQ) I’m looking 
>>> for the best device which cover the following items:
>>> 
>>> Branch:
>>> Single device 
>>> At least two Ethernet interfaces (WAN/LAN)
>>> Ipsec supporting 10-50-100 Mbs
>>> Routing protocols such as BGP-OSPF
>>> NAT
>>> Redundant power supply (some site not but in principle I need it)
>>> 
>>> HeadQuarter:
>>> Single device with XE intf 
>>> At least two Ethernet interfaces (WAN/LAN)
>>> IPSEC supporting up to 7-10 Gbs of IPSEC (the sum of branches)
>>> Routing protocols such as BGP-OSPF
>>> NAT
>>> Redundant power supply
>>> 
>>> Firewall is not needed, MPLS will be runned by the carrier, the devices and 
>>> IPSEC are on-top of MPLS.
>>> I’m looking for the best solution in terms of scalability and price (very 
>>> important).
>>> 
>>> Also any advice with experience for the decision is appreciated.
>>> 
>>> Regards
>>>   
>>> ___
>>> 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] Best device to fit for a project

[Ben Dale]

SRX550 is pretty much your only option in the branch if you require dual power 
supply, but is in every other way overspecced (and thus priced) for the 
remainder of your branch requirements.  If you can do without the RPS, then I'd 
go with either an SRX220 or 240, which will easily handle the remainder of your 
requirements.

Are you sure you want 7-10GBps of IPSEC?  I'm not sure what market you're in, 
but I don't imagine a 10Gbps WAN port is particularly cheap from your carrier 
(since you list price as being important).  

If you absolutely need this much crypto though, then you'll be looking at 
somewhere between an SRX650 and an SRX1400 plus appropriate 10G XPM/IOC.

As for scalability - no issues - the 650 will support up to 3,000 tunnels and 
the 1400 was good for about 15,000 last time I looked - it's probably gotten 
better since then.

Ben

On 1 Apr 2014, at 4:37 pm, R S  wrote:

> For a project (70 branch offices and 2 Headquarters connected in an hub&spoke 
> topology with IPSEC over MPLS among branch and HQ) I’m looking for the best 
> device which cover the following items:
> 
> Branch:
> Single device 
> At least two Ethernet interfaces (WAN/LAN)
> Ipsec supporting 10-50-100 Mbs
> Routing protocols such as BGP-OSPF
> NAT
> Redundant power supply (some site not but in principle I need it)
> 
> HeadQuarter:
> Single device with XE intf 
> At least two Ethernet interfaces (WAN/LAN)
> IPSEC supporting up to 7-10 Gbs of IPSEC (the sum of branches)
> Routing protocols such as BGP-OSPF
> NAT
> Redundant power supply
> 
> Firewall is not needed, MPLS will be runned by the carrier, the devices and 
> IPSEC are on-top of MPLS.
> I’m looking for the best solution in terms of scalability and price (very 
> important).
> 
> Also any advice with experience for the decision is appreciated.
> 
> Regards
> 
> ___
> 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] SRX100 LDAP

[Ben Dale]

It's been a long time since I've played with this, but it's not something 
simple like:

set access-profile TPAD

is it?  The Junos doco doesn't mention it, but for some applications you need 
to specifically activate the access-profile.


On 18 Mar 2014, at 8:54 pm, Шепелев Андрей  wrote:

> Hi All !
> 
> I`m trying to made a web portal auth with LDAP integration on SRX 100.
> 
> Here is the config:
> 
> ## Last changed: 2014-03-11 05:44:05 UTC
> version 11.2R4.3;
> system {
>host-name test-srx100.adm.n.tp.ru;
>root-authentication {
>encrypted-password "$1$yo2A3wox$K/.Epl658XW1r4Z9BgDWm0"; ##
> SECRET-DATA
>}
>name-server {
>10.60.0.5;
>8.8.8.8;
>}
>services {
>ssh;
>telnet;
>xnm-clear-text;
>web-management {
>http;
>}
>}
>syslog {
>archive size 100k files 3;
>user * {
>any emergency;
>}
>file messages {
>any critical;
>authorization info;
>}
>file interactive-commands {
>interactive-commands error;
>}
>}
>max-configurations-on-flash 5;
>max-configuration-rollbacks 5;
>license {
>autoupdate {
>url https://ae1.juniper.net/junos/key_retrieval;
>}
>}
>processes {
>general-authentication-service {
>traceoptions {
>file auth-debug;
>flag all;
>}
>}
>}
> }
> interfaces {
>fe-0/0/0 {
>unit 0;
>}
>fe-0/0/1 {
>vlan-tagging;
>unit 101 {
>description Users;
>vlan-id 101;
>family inet {
>address 10.60.0.200/24;
>}
>}
>unit 105 {
>description Management;
>vlan-id 105;
>family inet {
>address 172.20.0.200/24;
>}
>}
>}
>fe-0/0/2 {
>unit 0;
>}
>fe-0/0/3 {
>unit 0;
>}
>fe-0/0/4 {
>unit 0;
>}
>fe-0/0/5 {
>unit 0;
>}
>fe-0/0/6 {
>unit 0;
>}
>fe-0/0/7 {
>unit 0 {
>description ISP1;
>family inet {
>address 46.250.34.22/24;
>}
>}
>}
>vlan {
>unit 0;
>}
> }
> routing-options {
>static {
>route 0.0.0.0/0 next-hop 46.250.34.1;
>route 10.60.0.0/21 next-hop 10.60.0.1;
>route 172.20.0.0/24 next-hop 172.20.0.1;
>}
> }
> protocols {
>stp;
> }
> security {
>screen {
>ids-option untrust-screen {
>icmp {
>ping-death;
>}
>ip {
>source-route-option;
>tear-drop;
>}
>tcp {
>syn-flood {
>alarm-threshold 1024;
>attack-threshold 200;
>source-threshold 1024;
>destination-threshold 2048;
>timeout 20;
>}
>land;
>}
>}
>}
>nat {
>source {
>rule-set trust-to-untrust {
>from zone trust;
>to zone untrust;
>rule source-nat-rule {
>match {
>source-address 0.0.0.0/0;
>}
>then {
>source-nat {
>interface;
>}
>}
>}
>}
>}
>}
>policies {
>from-zone trust to-zone untrust {
>policy trust-to-untrust {
>match {
>source-address any;
>destination-address any;
>application any;
>}
>then {
>permit {
>firewall-authentication {
>pass-through {
>access-profile TPAD;
>web-redirect;
>}
>}
>}
>}
>}
>}
>}
>zones {
>security-zone trust {
>host-inbound-traffic {
>system-services {
>all;
>}
>protocols {
>all;
>}
>}
>interfaces {
>fe-0/0/1.101;
>fe-0/0/1.105;
>}
>}
>security-zone untrust {
>screen untrust-screen;
>host-inbound-traffic {
>system-services {
>all;
>}
>protocols {
>all;
>}
>}
>interfaces {
>fe-0/0/0.0 {
>  

Re: [j-nsp] Disable STP on a port with ELS?

[Ben Dale]

I seem to recall reading that at least on the 4300 ELS, spanning-tree is now no 
longer implicitly enabled on every port, so disable is no longer required 
because it is the default state unless you have explicitly referenced the 
interface.

Would love to confirm this with someone who has access to either 4300, 9200 or 
QFX5100 in front of them

Ben
> On 9 Mar 2014, at 1:49 am, "Chuck Anderson"  wrote:
> 
> Here is another Enhanced Layer 2 Software question.  Is it possible to
> disable STP participation on a port?  The "disable" command seems to
> be missing from these hierarchies, at least on 13.2X51 for QFX5100:
> 
> protocols stp interface <> disable
> protocols rstp interface <> disable
> protocols mstp interface <> disable
> protocols vstp interface <> disable
> ___
> 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] sshd log messages !!

[Ben Dale]

If you're stuck with password-based login (rather than SSH keys), leave 
yourself one go at missing your password, then increase the backoff-factor up 
to 10 to put a 10-second wait for guess number 3:

set system services ssh root-login deny
set system login retry-options backoff-threshold 2
set system login retry-options backoff-factor 10

It won't stop a bot, but it will slow it down a bit.

Phil - while you're at it with Junos enhancements - any chance of giving us a

set system services ssh port <1024-65535>

Yes it's security through obscurity, but it's also low hanging fruit..

Failing that, there is a:

set system login deny-sources

maybe an "allow-sources" might be a bit more useful in this instance?  Less 
sophisticated users tend to shoot themselves in the foot with firewall filters 
quite regularly.

Ben

On 27 Feb 2014, at 8:21 am, Harri Makela  wrote:

> Hi There
> 
> I am constantly getting these log messages for last few days:-
> 
> sshd[21015]: Failed password for root from X.X.103.152 port 21067 ssh2
> sshd[21016]: Received disconnect from X.X.103.152: 11: Normal Shutdown, Thank 
> you for playing
> 
> 
> Are these indicating any brute-force attack ?Thanks
> HM
> 
> 
> 
> 
> On Wednesday, 26 February 2014, 21:15, "juniper-nsp-requ...@puck.nether.net" 
>  wrote:
> 
> Send juniper-nsp mailing list submissions to
> juniper-nsp@puck.nether.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> or, via email, send a message with subject or body 'help' to
> juniper-nsp-requ...@puck.nether.net
> 
> You can reach the person managing the list at
> juniper-nsp-ow...@puck.nether.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of juniper-nsp digest..."
> 
> 
> Today's Topics:
> 
>1. Re: proposed changes to "clear bgp neighbor" (ryanL)
>2. Re: proposed changes to "clear bgp neighbor" (Phil Shafer)
>3. Re: proposed changes to "clear bgp neighbor" (Eric Van Tol)
>4. Re: proposed changes to "clear bgp neighbor" (Jerry Dent)
>5. Re: proposed changes to "clear bgp neighbor" (Brent Sweeny)
>6. Re: proposed changes to "clear bgp neighbor"
>   (Fernando Garcia Fernandez)
>7. Re: proposed changes to "clear bgp neighbor" (ryanL)
>8. Re: proposed changes to "clear bgp neighbor"
>   (Jonas Frey (Probe Networks))
>9. Re: proposed changes to "clear bgp neighbor" (sth...@nethelp.no)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 26 Feb 2014 12:22:51 -0500
> From: ryanL 
> To: p...@juniper.net
> Cc: Juniper for Network Service Providers
> 
> Subject: Re: [j-nsp] proposed changes to "clear bgp neighbor"
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> it's a nice-to-have, maybe? but this sounds more like an opportunity for
> you to sell some JNCIA courses. i mean, how long has junos been around now?
> 
> 
> On Wed, Feb 26, 2014 at 10:36 AM, Phil Shafer  wrote:
> 
>> Juniper users,
>> 
>> We've been asked to make a change the "clear bgp neighbor" command
>> to make the neighbor or "all" argument mandatory.  The root cause
>> is the severe impact of "clear bgp neighbor" and the increasing
>> accidental use of this command without a specific neighbor.
>> 
>> In general, we avoid changing commands to add mandatory arguments,
>> but my feeling is that the impact and severity of this specific
>> command makes this an acceptable occasion for such a change.
>> 
>> I'm looking for feedback about this change.  My working assumption
>> is that "clear bgp neighbor" is a sufficiently rare command and
>> would not be used in automation/scripts, so the impact of making
>> the neighbor/all argument mandatory would be minimal.  Is this
>> assumption accurate?
>> 
>> Thanks,
>>   Phil
>> 
>> [I've set reply-to to myself to avoid impacting the list]
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> --
> 
> Message: 2
> Date: Wed, 26 Feb 2014 13:44:42 -0500
> From: Phil Shafer 
> To: ryanL 
> Cc: Juniper for Network Service Providers
> 
> Subject: Re: [j-nsp] proposed changes to "clear bgp neighbor"
> Message-ID: <201402261844.s1qiiggl031...@idle.juniper.net>
> Content-Type: text/plain
> 
> ryanL writes:
>> it's a nice-to-have, maybe? but this sounds more like an opportunity for
>> you to sell some JNCIA courses. i mean, how long has junos been around now?
> 
> Not selling anything; just trying to solve a problem multiple
> customers have reported and escalated.  I'm a software developer,
> working on the UI code (CLI, MGD, configuration, XML API, scripting)
> for 17+ years.
> 
> JUNOS 3.0 (the first release with the ui code) shipped during the
> summer of 1998, IIRC.
> 
> Thanks,
> Phil
> 
> 
> 
> -

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

[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

[Ben Dale]

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

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

[Ben Dale]

On 20 Feb 2014, at 11:22 am, Mark Tinka  wrote:

> On Wednesday, February 19, 2014 10:47:33 PM Aaron Dewell 
> wrote:
> 
>> The main advantage of the 4300 vs. 4200 is 4x10G uplinks
>> instead of 2, and 40G QSFP+ ports which can be either VC
>> or routed.  It's a lot more flexible platform and much
>> more compatible with others (read: QFX5100) than the
>> EX4200 will ever be.
> 
> Can anyone speak to buffer sizes and whether egress policing 
> is supported?
> 
> Mark.

>From what I've been able to gather, there is a single PFE on them with 5MB 
>shared.

The feature guide suggests port/queue shaping is available and it mentions 
policing under Routing Policy/Packet Filtering features, but I suspect this is 
just the traditional filter-based stuff:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#cos-features-by-platform-table

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

[Ben Dale]

Hi Janusz,

You may want to read through this document too:

http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/getting-started-els.html

there are quite a few changes to the way you're used to doing things with VLANs 
and interfaces on EX4300s, which you'll find incredibly frustrating after using 
any of the other EXs up until now.

Also, upgrade your code to 13.2X50-D18 right now.  No, really.  You'll thank me 
later.  

It's not actually available on the download page, but if you follow the link on 
right where it shows JTAC recommended code which redirects you to the 
password-protected KB Article on recommended versions, which you can then dig 
through to find the link to the specific EX4300 software Technical Services 
Bulletin, which lists the 13-odd critical PRs that seemed to make it out the 
door and finally the link to the actual software...  

or for Hitchhikers fans: "It was on display in the bottom of a locked filing 
cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of 
the Leopard'."

https://download.juniper.net/software/junos/regressed/13.2X50-D18/jinstall-ex-4300-13.2X50-D18-domestic-signed.tgz




On 19 Feb 2014, at 1:44 pm, Janusz Wełna  wrote:

> Hi,
> 
> 
> Why when I have below config:
> 
>  ge-0/0/44 {
>description test;
>unit 0 {
>family ethernet-switching {
>vlan {
>members vlan103;
>}
>storm-control default;
> 
>   unit 103 {
>description test;
>family inet {
>address 10.46.163.1/29;
> 
> 
>vlan103 {
>description test;
>vlan-id 103;
>l3-interface vlan.103;
> 
> 
> 
> 
> I cannot ping from EX4300 10.46.163.1 and I cannot ping 10.46.163.1 from
> server connected to ge-0/0/44
> 
> 
> 
> 
> But when I add below:
> 
> 
> irb {
>unit 103 {
>family inet {
>address 10.46.163.1/29;
> 
> 
> and delete :
> 
> 
> vlan103 {
>description SGI;
>vlan-id 103;
>l3-interface vlan.103
> 
> 
> 
> 
> ping works correctly.
> 
> 
> On EX3300, EX4200 and EX2200 I not need setup irb interface, why I need on
> EX4300 ?
> 
> 
> 
> Br,
> 
> 
> Janusz
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Juniper Product against DDoS

[Ben Dale]

So I had a tech session on the DDoS Secure product a while back and my takeaway 
was that it is targeted at the low'n'slow style of DDoS rather than volumetric 
attacks that products like Arbour et. al. assist with mitigating - at the end 
of the day, you position it logically in front of your servers/LB (it's a 
transparent bridge).

In drastically simplified terms, it uses a truck load of heuristics and other 
magic™ to determine whether requests to your infrastructure are machine-based 
or interactive, and then depending on whether traffic flows are in profile or 
not (servers under load etc.), reacts.  Webcrawlers and other "legit" machine 
traffic are also handled gracefully.

The technology behind it looks quite interesting, and coupled with WebApp 
Secure/Mykonos it is certainly a different take on the typical mod_secure/WAF 
story for any content providers.

It would be nice if product marketing had picked a slightly less evocative name 
though - when someone says DDoS, I'm sure most think instantly of pipe-filling 
packet storms.

Ben 

On 19 Feb 2014, at 1:06 am, Benoit Plessis  wrote:

> Le 18/02/2014 15:46, Samol a écrit :
>> Hi Experts,
>> 
>> Does Juniper provide any DDoS solution ? would you please recommend the
>> product line for this solution if there is?
>> 
>> thanks,
> 
> Hi,
> 
> No expert here but there is the DDoS Secure appliance on there sales
> list, something from
> a company recently bougth (http://www.webscreen-technology.com/).
> 
> It's a dell computer server hardware apparently, with a custom (up to
> where?) software.
> 
> I should receive one shortly so shall see ...
> ___
> 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] AE vs PT , and OSPF neigh not forming

[Ben Dale]

Make sure you have:

host-inbound-traffic protocols ospf 

configured under the security zone for your reth interface

On 23 Jan 2014, at 3:58 pm, Samol  wrote:

> Hi List,
> 
> I've got not another problem with ospf neigh. As the topo below, SRX and MX
> can reach each other by ping, but ospf neig can't form.
> 
> MX (ae0.88)--(pt-1/0/0.0) SRX
> 
> I did the investigation on SRX and I found that SRX is sending/receiving
> ospf hello message.
> 
> Time  FilterAction Interface ProtocolSrc Addr
>  Dest Addr
> 18:37:46  pfe   A  pt-1/0/0.0OSPF172.16.161.1
>  224.0.0.5
> 18:37:44  OSPF-DEBUG A local OSPF172.16.161.2
>  224.0.0.5
> 18:37:38  pfe   A  pt-1/0/0.0OSPF172.16.161.1
>  224.0.0.5
> 18:37:35  OSPF-DEBUG A local OSPF172.16.161.2
>  224.0.0.5
> 18:37:29  pfe   A  pt-1/0/0.0OSPF172.16.161.1
>  224.0.0.5
> 18:37:26  OSPF-DEBUG A local OSPF172.16.161.2
>  224.0.0.5
> 
> However, on MX side, It's sending the hello message, but it's not receiving
> hello message that SRX ACKs. that leads to OSPF state in INIT state on SRX
> side, and no neigh status on MX side. Looking in to ae interface statistics
> , get the result as below :
> 
>Link:
>  ge-1/0/0.88
>Input : 0  0 00
>Output: 62551  0   68045620
>  ge-1/0/1.88
>Input :   882  02879320
>Output: 0  0 00
> 
> it's using one link to send and another to receive. Surely, OSPF message
> that sending from SRX is being dropped somewhere in the middle, however why
> is it not dropping ICMP message ? Any idea is really appreciated.
> 
> Regards,
> 
> 
> 
> -- 
> Samol Khoeurn
> (855) 077 55 64 02 / (855) 067 41 88 66
> Network Engineer
> Cisco: CCNA/CCNP SP/CCIP/
> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> www.linkedin.com/in/samolkhoeurn
> ___
> 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] VLAN sub-ints and VPLS

[Ben Dale]

Hi Tom,

> 
> Great, no more errors, try to commit again:
> 
> # commit
> [edit interfaces ge-0/0/12]
>  'unit 0'
>vlan map ge-0/0/12: input-vlan-map and output-vlan-map are valid
> on untagged interfaces only for ethernet-ccc and ethernet-vpls
> encapsulations
> error: configuration check-out failed
> 
> But you just told me I need to use  tagging? And there is no
> ethernet-vpls encapsulation for units. wtf?
> 
> Maybe its just not possible on an SRX, perhaps it doesnt have the
> smarts, or maybe Im just missing something really obvious.
> 
> Any help appreciated. Cheers!

Switch your physical interface encapsulation to vlan-vpls and try committing 
again

Cheers,

Ben


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

Re: [j-nsp] OSPF neig / SRX cluster / LACP

[Ben Dale]

You'll see in Cooper's blog that both nodes are going back into a *single* EX 
switch with *two* ae interfaces configured - one to each node.

These ae links have two ports allocated to them.

All LACP does is provide redundancy/balancing between ports to the primary node 
- the secondary node will be down from a reth perspective, even if the LACP 
shows as up.

On 16 Jan 2014, at 4:42 pm, Samol  wrote:

> Hi Aaron,
> 
> LACP is running on the reth interface and reth's are up. below is the
> configuration:
> 
> Admin@coolSRX# show interfaces reth1
> vlan-tagging;
> redundant-ether-options {
>redundancy-group 1;
>lacp {
>passive;
>periodic fast;
>}
> }
> 
> this link was successful for this. http://cooperlees.com/blog/?p=401
> 
> 
> 
> 2014/1/16 Aaron Dewell :
>> 
>> reth interfaces are for failover not for bundle.  You can use two LAGs 
>> within a reth interface (multiple interface on a single node in a LAG) but 
>> not across both.  It's up (probably) because you aren't running LACP.  If 
>> you turn on LACP, then various links will be down.  I'm going to guess 
>> that's why the OSPF session from the right MX is down - because the MX is 
>> transmitting to the wrong node for that redundancy-group and it's being 
>> ignored.
>> 
>> On Jan 15, 2014, at 11:52 PM, Samol wrote:
>>> I can't access to the devices at the moment, but basically what we did
>>> was under each routing instance, we just put the interfaces inside the
>>> ospf area. very straight forward configuration of ospf. I have thought
>>> of links LAG from MX should only connect to each node individually.
>>> but it's interesting that LAG are running even though links are
>>> connected two different nodes (this is for Reth interface). But I
>>> tried to use AE interface on SRX cluster, the theory is true that we
>>> can't bundle two links that land on different node. we just can't
>>> commit.  that is the reason we move to Reth.
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> 
>>> 
>>> 2014/1/16 Ben Dale :
>>>> I'm surprised that this is even working at all.
>>>> 
>>>> http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html
>>>> 
>>>> Specifically:
>>>> 
>>>> Note: The redundant Ethernet interface LAG child links from each node in 
>>>> the chassis cluster must be connected to a different LAG at the peer 
>>>> devices. If a single peer switch is used to terminate the redundant 
>>>> Ethernet interface LAG, two separate LAGs must be used in the switch.
>>>> 
>>>> From a single MX a single LAG should got to a single individual node from 
>>>> the chassis cluster.
>>>> 
>>>> Can you paste the OSPF configs from each RI on the SRX and MX-B?
>>>> 
>>>> On 16 Jan 2014, at 2:51 pm, Samol  wrote:
>>>> 
>>>>> what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one link is 
>>>>> on Node0 and another is on node1. both link on SRX are member of Reth.
>>>>> 
>>>>> Admin@coolSRX# show interfaces reth1
>>>>> vlan-tagging;
>>>>> redundant-ether-options {
>>>>>   redundancy-group 1;
>>>>>   lacp {
>>>>>   passive;
>>>>>   periodic fast;
>>>>>   }
>>>>> }
>>>>> 
>>>>> {primary:node0}[edit]
>>>>> Admin@coolSRX# run show lacp interfaces reth1
>>>>> Aggregated interface: reth1
>>>>>   LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  
>>>>> Activity
>>>>> ge-0/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
>>>>> Passive
>>>>> ge-0/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
>>>>> Active
>>>>> ge-9/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
>>>>> Passive
>>>>> ge-9/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
>>>>> Active
>>>>>   LACP protocol:Receive State  Transmit State  Mux State
>>>>> ge-0/0/4  Current   Fast periodic Collecting 
>>>>> distributing
>>>>> ge-9/0/4  Current   Fast periodic Collect

Re: [j-nsp] OSPF neig / SRX cluster / LACP

[Ben Dale]

I'm surprised that this is even working at all.

http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html

Specifically:

Note: The redundant Ethernet interface LAG child links from each node in the 
chassis cluster must be connected to a different LAG at the peer devices. If a 
single peer switch is used to terminate the redundant Ethernet interface LAG, 
two separate LAGs must be used in the switch.

>From a single MX a single LAG should got to a single individual node from the 
>chassis cluster.

Can you paste the OSPF configs from each RI on the SRX and MX-B?

On 16 Jan 2014, at 2:51 pm, Samol  wrote:

> what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one link is on 
> Node0 and another is on node1. both link on SRX are member of Reth. 
> 
> Admin@coolSRX# show interfaces reth1  
> vlan-tagging;
> redundant-ether-options {
> redundancy-group 1;
> lacp {
> passive;
> periodic fast;
> }
> }
> 
> {primary:node0}[edit]
> Admin@coolSRX# run show lacp interfaces reth1 
> Aggregated interface: reth1
> LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  
> Activity
>   ge-0/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
> Passive
>   ge-0/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
> Active
>   ge-9/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
> Passive
>   ge-9/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
> Active
> LACP protocol:Receive State  Transmit State  Mux State 
>   ge-0/0/4  Current   Fast periodic Collecting 
> distributing
>   ge-9/0/4  Current   Fast periodic Collecting 
> distributing
> 
> All interfaces are UP. Reth's on SRX are also up. ae interfaces on MX-A and B 
> are also UP.  
> 
> Regards,
> 
> 
> 
> 2014/1/16 Ben Dale 
> 
> On 16 Jan 2014, at 11:22 am, Samol  wrote:
> >
> > I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
> > for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
> > interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
> > UP.
> >
> 
> Check it in layers:
> - is the reth interface on SRX-B definitely up when you have both links 
> enabled
> show chassis cluster interfaces
> - is your LACP up between MX-B and the cluster - bearing in mind that you 
> cannot have a single  LAG between MX-B and your SRX (it will need to be a LAG 
> to each cluster node)
> show lacp interfaces
> - if the neighbor is only down on one of the RIs, assuming you have a VLAN 
> between the MX and the SRX to carry each RI - double check that the VLAN is 
> actually tagged on both LAGs between the two boxes
> show bridge domain interface aex.0
> 
> Ben
> 
> 
> 
> -- 
> Samol Khoeurn
> (855) 077 55 64 02 / (855) 067 41 88 66
> Network Engineer 
> Cisco: CCNA/CCNP SP/CCIP/
> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> www.linkedin.com/in/samolkhoeurn
> 


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

Re: [j-nsp] OSPF neig / SRX cluster / LACP

[Ben Dale]

On 16 Jan 2014, at 11:22 am, Samol  wrote:
> 
> I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
> for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
> interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
> UP.
> 

Check it in layers:
- is the reth interface on SRX-B definitely up when you have both links enabled
show chassis cluster interfaces
- is your LACP up between MX-B and the cluster - bearing in mind that you 
cannot have a single  LAG between MX-B and your SRX (it will need to be a LAG 
to each cluster node)
show lacp interfaces
- if the neighbor is only down on one of the RIs, assuming you have a VLAN 
between the MX and the SRX to carry each RI - double check that the VLAN is 
actually tagged on both LAGs between the two boxes
show bridge domain interface aex.0

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

Re: [j-nsp] NTP Reflection

[Ben Dale]

On 14 Jan 2014, at 12:31 pm, Mark Tees  wrote:

> What I was referring to was a detailed ACL/Filter for lo0 that only allows
> traffic for enabled services on the routing engine.
> 
> For example if Juniper posted a firewall filter template with all the
> possible services customers could then activate/deactivate what they need
> from the policy and log fails before discarding etc.

What you think you're after is "show system connections" which is more or less 
"netstat -an" and shows all ports that are listening on your RE - you can now 
filter at will.

Providing a list of every service for people to modify is not going to solve 
these problems - "Oh hey, I'm using NTP, I'd better enable all those rules"..

What you actually want is an ACL with ONLY the services you've actually 
configured and understand from the source/destinations you're using them from 
and deny all else - then you *mostly* don't need to worry about this sort of 
thing.

If your employer is too tight to spring for the MX book (worth every cent and 
then some), the following free Day One books will provide everything you're 
after (sign up for a J-Net login if you don't already have one):

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

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

Re: [j-nsp] qfabric 1536k mac address?

[Ben Dale]

At a guess I'd say it's because in Q-Fabric, the "MAC-learning" is performed by 
a similar to a VPLS instance per VLAN rather than traditional per-switch CAM 
tables.  

I imagine this allows for better scalability/optimisation.

The switch CAM would then only need to worry about L2-adjacent QF nodes and 
adjacent hosts.

On 2 Jan 2014, at 5:28 pm, giovanni rana  wrote:

> Hi, during the evaluation of a new data center architecture, how can qfabric 
> support so many Mac addresses? The qfx3500 node supports only 128k Mac 
> tables, how can they get 1536k as declared in the data sheet? Is it because 
> of an optimized use of mac-vlan pairs? 
> Thanks for any answer and happy 2014! 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


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

Re: [j-nsp] Juniper MX104

[Ben Dale]

Yeah, my take on that is that MPC0 is pretty much anything built-in on the 
MX5/80 - eg: the front 10G ports are xe-0/0/0

My guess is that the rear slot is just another MIC slot (slot 1) MPC 0 so 
something like sp-0/1/0 or whatever designation gets used.  

The front MIC slots are ge-1/0/0-19  and ge-1/1/0-19 etc. 

On 13 Nov 2013, at 3:33 pm, Skeeve Stevens 
 wrote:

> Isn't that using the front MIC slot though?
> 
> The rear 'Services Slot' is an MPC slot isn't it?
> 
> Based on the following:
> 
> MS-MIC 16G - MS-MIC with 16 GB of memory provides 9GB of service throughput, 
> occupies single MIC slot on MX5, MX10, MX40, and MX80 3D Universal Edge 
> Routers, as well as on the MPC1, MPC2, and MPC3 cards for the MX2020, MX2010, 
> MX960, MX480, 
> and MX240 3D Universal Edge Router.
> 
> MS-MPC-128 - MS-MPC with 128 GB of memory (32 GB per NPU), provides 60Gbps of 
> service throughput, occupies a single slot in MX2020, MX2010, MX960, MX480, 
> and MX240 3D Universal Edge Routers
> 
> The rear picture of the MX80 at 
> http://www.juniper.net/shared/img/products/mx-series/mx80/mx80-rear-high.jpg
> 
> Says "MPC 0" and "MIC 1" in smaller writing under it.
> 
> From front right slot is also called "1/MIC 1"
> 
> I think we need further clarification.
> 
> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/eintellegonetworks ; linkedin.com/in/skeeve 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud
> 
> 
> On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale  wrote:
> MS-MIC is out for the MX5-80:
> 
> http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf
> 
> doesn't look like there isn't a services port on the back of the 104 though:
> 
> http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg
> 
> maybe you can use one of the front slots?
> 
> On 13 Nov 2013, at 2:52 pm, Skeeve Stevens 
>  wrote:
> 
> > Does anyone know how many users the MX104 will be able to handle though?
> >
> > The 4000 user limit on the MX80 was quite low.
> >
> > Does the MX104 have the services port on the back like the MX80?  I'm 
> > waiting for the CGN Services card which was supposed to be released around 
> > now.
> >
> >
> > ...Skeeve
> >
> > Skeeve Stevens - eintellego Networks Pty Ltd
> > ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> > facebook.com/eintellegonetworks ; linkedin.com/in/skeeve
> > twitter.com/theispguy ; blog: www.theispguy.com
> >
> > The Experts Who The Experts Call
> > Juniper - Cisco - Cloud
> >
> >
> > On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale  wrote:
> > That and I think a lot of the BRAS "migration" functionality (LNS/LAC etc) 
> > was late to the party after being told it wasn't going to happen for 
> > anything lower than the 240.
> >
> > On 13 Nov 2013, at 12:51 pm, Bill Blackford  wrote:
> >
> > > My personal feeling is the MX80 wasn't widely adopted as a lower density
> > > subscriber box given the lack of redundant REs. The MX104 may find it's
> > > niche as a BRAS.
> > >
> > >
> > >
> > >
> > > On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol  wrote:
> > >
> > >> One thing to keep in mind about these boxes is that, like the
> > >> MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit
> > >> scheduling).  I'm confused as to why this is, considering they are
> > >> Trio-based routers, but I digress.  I personally don't think that the
> > >> astronomical cost to enable the 10G ports on all the low-end MX routers 
> > >> is
> > >> worth it, considering they can't even do per-unit scheduling.
> > >>
> > >> -evt
> > >>
> > >>> -Original Message-
> > >>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> > >> Behalf Of
> > >>> joel jaeggli
> > >>> Sent: Tuesday, November 12, 2013 4:00 PM
> > >>> To: Saku Ytti
> > >>> Cc: juniper-nsp@puck.nether.net
> > >>> Subject: Re: [j-nsp] Juniper MX104
> > >>>
> > >>>
> > >>> On Nov 12, 2013, at 12:46 PM, Saku Ytti  w

Re: [j-nsp] Juniper MX104

[Ben Dale]

MS-MIC is out for the MX5-80:

http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf

doesn't look like there isn't a services port on the back of the 104 though:

http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg

maybe you can use one of the front slots?

On 13 Nov 2013, at 2:52 pm, Skeeve Stevens 
 wrote:

> Does anyone know how many users the MX104 will be able to handle though?
> 
> The 4000 user limit on the MX80 was quite low.
> 
> Does the MX104 have the services port on the back like the MX80?  I'm waiting 
> for the CGN Services card which was supposed to be released around now.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/eintellegonetworks ; linkedin.com/in/skeeve 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud
> 
> 
> On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale  wrote:
> That and I think a lot of the BRAS "migration" functionality (LNS/LAC etc) 
> was late to the party after being told it wasn't going to happen for anything 
> lower than the 240.
> 
> On 13 Nov 2013, at 12:51 pm, Bill Blackford  wrote:
> 
> > My personal feeling is the MX80 wasn't widely adopted as a lower density
> > subscriber box given the lack of redundant REs. The MX104 may find it's
> > niche as a BRAS.
> >
> >
> >
> >
> > On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol  wrote:
> >
> >> One thing to keep in mind about these boxes is that, like the
> >> MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit
> >> scheduling).  I'm confused as to why this is, considering they are
> >> Trio-based routers, but I digress.  I personally don't think that the
> >> astronomical cost to enable the 10G ports on all the low-end MX routers is
> >> worth it, considering they can't even do per-unit scheduling.
> >>
> >> -evt
> >>
> >>> -Original Message-
> >>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> >> Behalf Of
> >>> joel jaeggli
> >>> Sent: Tuesday, November 12, 2013 4:00 PM
> >>> To: Saku Ytti
> >>> Cc: juniper-nsp@puck.nether.net
> >>> Subject: Re: [j-nsp] Juniper MX104
> >>>
> >>>
> >>> On Nov 12, 2013, at 12:46 PM, Saku Ytti  wrote:
> >>>
> >>>> On (2013-11-12 20:14 +), Tom Storey wrote:
> >>>>
> >>>>> Why so much just to enable some ports? How do they come up with that
> >>>>> kind of price? Pluck it out of thin air?
> >>>>>
> >>>>> The hardware has been paid for, and I know thats only list pricing,
> >>>>> but it still seems ridiculous.
> >>>>
> >>>> The question might have been rhetoric. But I'll bite.
> >>>>
> >>>> The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But
> >> the
> >>>> volume you can sell them also is very very small, so the margins need
> >> to
> >>> be
> >>>> very high to be able to design and support them.
> >>>> Licensing allows you to sell to larger group of people, people who
> >>> normally
> >>>> would buy smaller/inferior box, now can afford it,  which in turn
> >> allows
> >>> you
> >>>> to reduce your margins, making you more competitive.
> >>>>
> >>>> I actually like it. I wish vendors like Agilent/Ixia, Spirent would
> >> sell
> >>>> test-kit with some sort of 'per hours used' license. Lot of SPs have
> >> need
> >>> for
> >>>> proper testing kit, but only will need them very irregularly. And
> >> renting
> >>> is
> >>>> always such a chore. It's same thing there, BOM is nothing, but volume
> >> is
> >>> even
> >>>> lower, so prices are ridiculously high, consequently proper testing is
> >>> very
> >>>> rarely done by other than telco size SPs.
> >>>
> >>> It's one of those things where you work with account team. if the
> >> commercial
> >>> terms don't work out for most potential buyers, then the product won't be
> >>> successful and either things will change or they won't.
> >>>
> >>>> --
> >>>> ++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
> >>
> >
> >
> >
> > --
> > 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
> 

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

Re: [j-nsp] Juniper MX104

[Ben Dale]

That and I think a lot of the BRAS "migration" functionality (LNS/LAC etc) was 
late to the party after being told it wasn't going to happen for anything lower 
than the 240.

On 13 Nov 2013, at 12:51 pm, Bill Blackford  wrote:

> My personal feeling is the MX80 wasn't widely adopted as a lower density
> subscriber box given the lack of redundant REs. The MX104 may find it's
> niche as a BRAS.
> 
> 
> 
> 
> On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol  wrote:
> 
>> One thing to keep in mind about these boxes is that, like the
>> MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit
>> scheduling).  I'm confused as to why this is, considering they are
>> Trio-based routers, but I digress.  I personally don't think that the
>> astronomical cost to enable the 10G ports on all the low-end MX routers is
>> worth it, considering they can't even do per-unit scheduling.
>> 
>> -evt
>> 
>>> -Original Message-
>>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
>> Behalf Of
>>> joel jaeggli
>>> Sent: Tuesday, November 12, 2013 4:00 PM
>>> To: Saku Ytti
>>> Cc: juniper-nsp@puck.nether.net
>>> Subject: Re: [j-nsp] Juniper MX104
>>> 
>>> 
>>> On Nov 12, 2013, at 12:46 PM, Saku Ytti  wrote:
>>> 
 On (2013-11-12 20:14 +), Tom Storey wrote:
 
> Why so much just to enable some ports? How do they come up with that
> kind of price? Pluck it out of thin air?
> 
> The hardware has been paid for, and I know thats only list pricing,
> but it still seems ridiculous.
 
 The question might have been rhetoric. But I'll bite.
 
 The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But
>> the
 volume you can sell them also is very very small, so the margins need
>> to
>>> be
 very high to be able to design and support them.
 Licensing allows you to sell to larger group of people, people who
>>> normally
 would buy smaller/inferior box, now can afford it,  which in turn
>> allows
>>> you
 to reduce your margins, making you more competitive.
 
 I actually like it. I wish vendors like Agilent/Ixia, Spirent would
>> sell
 test-kit with some sort of 'per hours used' license. Lot of SPs have
>> need
>>> for
 proper testing kit, but only will need them very irregularly. And
>> renting
>>> is
 always such a chore. It's same thing there, BOM is nothing, but volume
>> is
>>> even
 lower, so prices are ridiculously high, consequently proper testing is
>>> very
 rarely done by other than telco size SPs.
>>> 
>>> It's one of those things where you work with account team. if the
>> commercial
>>> terms don't work out for most potential buyers, then the product won't be
>>> successful and either things will change or they won't.
>>> 
 --
 ++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
>> 
> 
> 
> 
> -- 
> 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] 100% CPU HIT on EX4200

[Ben Dale]

You might want to share your Junos version too

Being an EX, follow up Graham's suggestions with:

show log messages (filtered down to times during the event)
show spanning-tree bridge (check Time since last topology change/number of 
changes - this is usually a culprit in pegging CPU)


On 8 Nov 2013, at 10:57 am, Graham Brown  wrote:

> Hi Sam,
> 
> 'show chassis routing-engine' and 'show system processes extensive' are two
> commands to start with, when investigating this issue.
> 
> The second command will show you what process is consuming resources etc.
> 
> HTH,
> Graham
> 
> 
> On 8 November 2013 13:51, Samol  wrote:
> 
>> Hi All,
>> 
>> CPU on EX4200 run up to 100% for a period of time and I have not yet found
>> what caused this. Based on your experiences, what are the things that can
>> cause this and what are the commands to check this ?
>> 
>> Thanks,
>> Sam
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> 
> -- 
> Graham Brown
> Twitter - @mountainrescuer 
> LinkedIn 
> ___
> 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] J-series, hoping packets between routing-instances

[Ben Dale]

Hi Mike,

First.. Yikes!

Second - yes this is possible.  It is perfectly legal to use FBF to bounce 
across routing instances and still match security policy - just ensure your 
security policy includes the source and destination zones for the *ultimate* 
destination of the flow is correct - whether it exists in the instance the 
traffic ends up in is ignored by the flow engine.

On 8 Nov 2013, at 12:37 am, Mike Williams  wrote:

> Hi all,
> 
> I might have painted myself into a corner here, so I'm here looking for 
> options from people far cleverer than I.
> 
> Firstly, a bit of history.
> 
> We're using J6350s, and SRX650s, as "security devices on a stick".
> Our Ms and MXs punt packets into a routing instance on the "security devices" 
> with firewall filters. Those routing instances purposely only use the most 
> basic of static routes possible (10/8, 192.168/16, etc), so we can be certain 
> what zones packets pass through so the policies match.
> 
> That all works fine.
> 
> 
> We're also centralising our inter-site IPSec onto the Js and SRXs, but need 
> OSPF there, so have a second routing-instance and a partial mesh of routed 
> tunnels between them.
> Still, all good.
> Offices and what-not have tunnels tied directly to the IPSec 
> routing-instances 
> and OSPF metrics keep traffic flows sane.
> All hunky dory.
> 
> 
> 
> Now the problem.
> 
> I need to take traffic from servers behind an M/MX have it policy'd by the 
> "security" routing instance, then encrypted by the IPSec routing-instance.
> If I punt traffic into "security", let it come back to the router, then punt 
> it back into "ipsec", everything works as expected.
> However each packet has to pass across the M/MX<->J/SRX link 4 times, in out, 
> in out. Shake it all about.
> 
> Obviously this would be better if we could shortcut the M/MX step in the 
> middle and move packets from "security" to "ipsec", and "ipsec" to "security" 
> directly.
> 
> As "security" doesn't run OSPF/BGP/ISIS/etc adding a static route "next-table 
> ipsec.inet.0" is fine.
> "ipsec" *does* run OSPF though, so I need to do FBF to override that. I've 
> tried a "then routing-instance security" filter applied on output on the 
> interface facing the M/MX, but my traffic get lost somewhere. Security 
> policies from 'input-ipsec-zone' to 'output-security-zone' were added.
> 
> 
> I'm wondering if 'moving' packets from routing-instance to routing-instance 
> on 
> a flow-mode device simply screws up security policies. As one of the input or 
> output interface don't exist in the routing-instance.
> So I figured *routing* packets from routing-instance to routing-instance 
> would 
> be better. Time for some logical tunnels! J-series devices don't support 
> logical tunnels though.
> 
> Argh!
> 
> -- 
> 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] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached

[Ben Dale]

On 24 Oct 2013, at 5:48 pm, pkc_mls  wrote:

> Le 24/10/2013 00:55, Ben Dale a écrit :
>> Can you confirm that you have two "active" port-channels configured on the 
>> Cisco side, one into each SRX? 
> From the docs I found I was assuming a single port-channel could handle all 
> interfaces attached to the same reth on srx.
> 
> For example, if ge-0/0/2, ge-0/0/3, ge-5/0/2, ge-5/0/3 are attached to reth0, 
> can I connect all the ports to the same etherchannel on the stack ?
> 
> 

No, there will be two sub-LAGs formed from the SRX - one on the active node, 
and one on the standby node.  To downstream devices, these appear as distinct 
LACP bundles, even though they are part of the same reth interface on the SRX.

There is a rather wordy explanation of it here, but the Note box in the middle 
of the page is probably a good summary:

http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-interfaces/understand-lacp-in-cc-mode-section.html

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

Re: [j-nsp] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached

[Ben Dale]

On 24 Oct 2013, at 1:12 am, pkc_mls  wrote:

> Hi all,
> 
> I'm running a cluster of srx 240 connected to a pair of cisco 2960 switches 
> with a port channel.
> 
> ESXi servers are also connected to the same stack of cisco switches.
> 
> vlan 1000 with ip 192.168.100.0 is used for out of band management and 
> reachability.
> 
> I'm using a dedicated virtual router to route the traffic from this vlan to 
> other vlans.
> 
> Some virtual machines can be reached but some others can't.
> 
> I upgraded today to 12.1X45-D15.5, as I require vpn termination on loopback 
> interface,
> and I suspect this release to have introduced weirdness into the 
> configuration.
> 
> Does anyone use a pair of srx devices with this release 12.1X45-D15.5 have 
> some issues with
> this kind of configuration ?
> 
> Are there any specific configurations to be used on the port channels 
> connected to the srx on the cisco stack ?
> 
> Best regards.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

Can you confirm that you have two "active" port-channels configured on the 
Cisco side, one into each SRX?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Spanning Tree Inconsistent State

[Ben Dale]

Hi Crist,

It is certainly possible to have blocked ports on a root bridge - consider a 
case where the switch is patched to itself.

Having a root port is a little unusual though?!!.  

Restarting RSTP is going to cause a topology change or two amongst your 
neighbours so try to do it during low traffic.

It might be worth using LLDP to trace out physical connections too just to make 
sure there isn't a cabling issue.

Ben

On 03/10/2013, at 9:50 AM, Crist Clark  wrote:

> I am a little confused about the spanning tree state on an EX4200 VC,
> running 11.4R5.5.
> 
> 
> 
> {master:0}
> cjc@dmz4200> show spanning-tree bridge
> 
> STP bridge parameters
> Context ID  : 0
> Enabled protocol: RSTP
> Root ID   : 32768.88:e0:f3:77:53:81
> Hello time: 2 seconds
> Maximum age   : 20 seconds
> Forward delay : 15 seconds
> Message age   : 0
> Number of topology changes: 20
> Time since last topology change   : 3661899 seconds
> Topology change initiator : xe-0/1/0.0
> Topology change last recvd. from  : 88:e0:f3:74:51:6a
> Local parameters
>   Bridge ID   : 32768.88:e0:f3:77:53:81
>   Extended system ID  : 0
>   Internal instance ID: 0
> 
> {master:0}
> cjc@dmz4200> show spanning-tree interface
> 
> Spanning tree interface parameters for instance 0
> 
> InterfacePort IDDesignated  Designated PortState  Role
>port IDbridge ID  Cost
> ge-0/0/0.0 128:513  128:513  32768.88e0f3775381 2  FWDDESG
> ge-0/0/47.0128:560  128:560  32768.88e0f3775381 2  FWDDESG
> xe-0/1/0.0 128:609  128:609  32768.88e0f3775381  2000  FWDROOT
> xe-0/1/2.0 128:611  128:611  32768.88e0f3775381  2000  FWDDESG
> ge-1/0/0.0 128:625  128:625  32768.88e0f3775381 2  FWDDESG
> ge-1/0/47.0128:672  128:672  32768.88e0f3775381 2  FWDDESG
> xe-1/1/0.0 128:721  128:776  32768.50c58dac4c81  2000  BLKALT
> xe-1/1/2.0 128:723  128:723  32768.88e0f3775381  2000  FWDDESG
> 
> 
> So what I'm confused about is that the "show spanning-tree bridge" output
> says that this switch is the root bridge, yet the per-interface output
> indicates that there are ROOT and ALT ports. Also, the bridge ID for the
> ROOT port is the switch itself? Whereas the ALT port is what I would
> expect, except that it again seems to contradict the idea that this switch
> is the root bridge.
> 
> 
> 
> I think my RSTP on this switch is in some messed up state? When I turn on
> traceoptions for rstp, I see sucpicious stuff like,
> 
> 
> Oct  2 11:26:59.532378 PISM: Port xe-1/1/0.0: IMPOSSIBLE EVENT/STATE
> Combination Occured
> Oct  2 11:26:59.532396 PISM: Event routine returned FAILURE
> Oct  2 11:26:59.532414 MSG: RstPortInfoMachine function returned FAILURE!
> 
> Oct  2 11:26:59.532441 RECV: PortReceiveStateMachine Action returned
> FAILURE!
> 
> Oct  2 11:26:59.532467 MSG: RstPortReceiveMachine function returned FAILURE!
> 
> Oct  2 11:26:59.532493 MSG: RstHandleInBpdu function FAILED!
> 
> Is there a low risk way to reset RSTP on a production switch?
> ___
> 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 Command

[Ben Dale]

Harri,

As per the link below - add "then count" to all your policies (using the 
following apply-group will do this quickly for you):

set groups COUNT-ALL security policies from-zone <*> to-zone <*> policy <*> 
then count
set apply-groups COUNT-ALL

If you install the op-script provided and run it after a month or so, it will 
show you pretty quickly which policies are being used, but if you don't want to 
use an op script, try:

run show security policies detail | match "Policy:|zone|lookups"

Again - the lookups field will only be there if the policy has count enabled.

Cheers,

Ben

On 24/09/2013, at 10:37 PM, Harri Makela  wrote:

> Thanks for lookup
> 
> We have JUNOS Software Release [10.4R5.5] and it doesn`t look like that we 
> have the option indictaed in last mail
> 
> admin@SRX-3600-P> show security policies ?
> Possible completions:
>   <[Enter]>Execute this command
>   detail   Show the detailed information
>   from-zoneShow the policy information matching the given source 
> zone
>   policy-name  Show the policy information matching the given policy 
> name
>   to-zone  Show the policy information matching the given 
> destination zone
>   |Pipe through a command
> {primary:node0}
> admin@SRX-3600-P> show security policies hit
>^
> 
> I can capture all duplicate policies and delete which are not required for 
> same flow but the ones which are not being used and are there for nothing, I 
> would like to delete them. Not sure how I can accomlpish that with a JUNOS 
> command which I have to run in parallel with a shell script.
> 
> Looking forward to get some feedback.
> 
> Thanks
> HM
> 
> 
> 
> From: Ben Dale 
> To: Edward Dore  
> Cc: Harri Makela ; "juniper-nsp@puck.nether.net" 
>  
> Sent: Tuesday, 24 September 2013, 5:45
> Subject: Re: [j-nsp] SRX Command
> 
> After I spent a bit of time building an op script to print policy matches out 
> in a nicely formatted table, I notice that this feature is now available for 
> all policies even without the "then count" action from 12.1:
> 
> show security policies hit-count
> 
> Cheers,
> 
> Ben
> 
> On 24/09/2013, at 8:45 AM, Edward Dore 
>  wrote:
> 
> > You'll need to add the "count" action to the "then" statement on each 
> > security policy if you want to track the number of times that the policy 
> > has been matched.
> > 
> > Edward Dore 
> > Freethought Internet 
> > 
> > On 23 Sep 2013, at 23:08, Harri Makela wrote:
> > 
> >> Hi All
> >> 
> >> Is there any command in SRX which I can use to check "number of times FW 
> >> policy has been used". Actually I want to clear all FW policies which are 
> >> not being used for last 12 months or so.  I don`t know much about 
> >> scripting but can try to get some help if I can think of a command which 
> >> can be rung through different zones combinations.
> >> 
> >> 
> >> Thanks in Advance !
> >> HM
> >> ___
> >> 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 Command

[Ben Dale]

Just blew the dust off it and it still works ; )

http://pastebin.com/xiszACPf

If you're applying this to a chassis cluster, you may need to replace the line:

for-each ($policies-list/security-context/policies) {

with 

for-each ($policies-list/multi-routing-engine-item/security-context/policies) {

Enjoy,

Ben

On 24/09/2013, at 4:43 PM, Maarten van der Hoek  wrote:

> Hi Ben,
> 
> Did you succeed in building that script ?
> (e.g. do you have it somewhere ? ;-) )
> 
> We've been playing with exports and then import in Excel...but still not
> very nice.. 
> A better solution would be nice.
> (we can't you Junos-Space / or so because most deployments are in separate
> Small / Branch offices)
> 
> Brgds,
> 
> Maarten van der Hoek
> 
> -Oorspronkelijk bericht-
> Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens Ben
> Dale
> Verzonden: dinsdag 24 september 2013 6:46
> Aan: Edward Dore
> CC: juniper-nsp@puck.nether.net; Harri Makela
> Onderwerp: Re: [j-nsp] SRX Command
> 
> After I spent a bit of time building an op script to print policy matches
> out in a nicely formatted table, I notice that this feature is now available
> for all policies even without the "then count" action from 12.1:
> 
> show security policies hit-count
> 
> Cheers,
> 
> Ben
> 
> On 24/09/2013, at 8:45 AM, Edward Dore
>  wrote:
> 
>> You'll need to add the "count" action to the "then" statement on each
> security policy if you want to track the number of times that the policy has
> been matched.
>> 
>> Edward Dore
>> Freethought Internet
>> 
>> On 23 Sep 2013, at 23:08, Harri Makela wrote:
>> 
>>> Hi All
>>> 
>>> Is there any command in SRX which I can use to check "number of times FW
> policy has been used". Actually I want to clear all FW policies which are
> not being used for last 12 months or so.  I don`t know much about scripting
> but can try to get some help if I can think of a command which can be rung
> through different zones combinations.
>>> 
>>> 
>>> Thanks in Advance !
>>> HM
>>> ___
>>> 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] SRX Command

[Ben Dale]

It is, but looking at it in the lab quickly, the SNMP statistics counters only 
collect hits against policies that have the count action (even in 12.1).

You'll want:

show snmp mib walk ascii jnxJsPolicyTable

to identify policy and:

show snmp mib walk ascii jnxJsPolicyStatsTable 

to grab the stats.

References:
http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/general/jnx-security-policy-nm-mib.html
http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/general/jnxjspolicystatstable-nm-mib.html
http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/mibs/mib-jnx-js-policy.txt

Cheers,

Ben

On 24/09/2013, at 2:52 PM, Gavin Henry  wrote:

> Hi,
> 
> Is the same info available via SNMP?
> 
> Thanks. 
> 

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

Re: [j-nsp] SRX Command

[Ben Dale]

After I spent a bit of time building an op script to print policy matches out 
in a nicely formatted table, I notice that this feature is now available for 
all policies even without the "then count" action from 12.1:

show security policies hit-count

Cheers,

Ben

On 24/09/2013, at 8:45 AM, Edward Dore  
wrote:

> You'll need to add the "count" action to the "then" statement on each 
> security policy if you want to track the number of times that the policy has 
> been matched.
> 
> Edward Dore 
> Freethought Internet 
> 
> On 23 Sep 2013, at 23:08, Harri Makela wrote:
> 
>> Hi All
>> 
>> Is there any command in SRX which I can use to check "number of times FW 
>> policy has been used". Actually I want to clear all FW policies which are 
>> not being used for last 12 months or so.  I don`t know much about scripting 
>> but can try to get some help if I can think of a command which can be rung 
>> through different zones combinations.
>> 
>> 
>> Thanks in Advance !
>> HM
>> ___
>> 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] Automation of EX code upgrade

[Ben Dale]

If you're talking green fields (out-of-the-box) then there are a couple of ways 
depending on the current Junos release the switch is running:

<12.2 - Automatic Software Download

http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/ex-series-software-automatic-download-upgrading.html

>=12.2 - Zero Touch Provisioning

http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/software-image-and-configuration-automatic-provisioning-understanding.html

Try to stagger upgrades if you can, or learn the effects of having a hundred 
switches hitting a TFTP server for a ~110MB image file.  Neither of these 
methods will display the success of the upgrades though.

If your switches are already deployed, then a better way to do it is with Junos 
Space.  

The nice thing about the Space method is that you can upgrade smaller groups of 
switches at a time, pre-stage the images up to each switch and schedule the 
entire process.  Each upgrade is given a Job ID and that Job ID will return 
success or failure depending on the outcome, even in the pre-staging if you 
don't have room on your flash for the image..

This functionality is built into the base Space platform too, which you can 
download and install with a 60(?)-day trial license.

Cheers,

Ben

On 20/09/2013, at 8:04 AM, Mick Burns  wrote:

> Hey all,
> 
> I am looking for ideas/previous experience in the best way to automate the
> upgrade of multiple (let's say about a hundred units) EX switches in large
> datacenters.  Let's assume here they are a mix of 3200 and 4200 and all of
> them runs the same JunOS release.  Any failure must be quickly identified
> for a manual upgrade.
> 
> Any help or advice is much appreciated.
> Mick B.
> ___
> 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] TCN guard on Juniper EX

[Ben Dale]

Hi Dennis,

The closest thing Junos has at the moment is root-guard, which would stop your 
Netgears assuming root for the topology, but AFAIK TCNs would still be accepted 
and acted upon.

Are your netgear boxes manageable?  You can't force ports into edge mode to 
stop this?

On 11/09/2013, at 8:18 PM, Dennis Hagens  wrote:

> Hi All,
> 
> Is there some way to filter out STP TCN BPDU's on a Juniper EX series switch?
> 
> We have some old Netgears in our office environment (yes, I need to get rid 
> of those) which send TCN's on edge port flaps.
> This causes a lot of reconvergence / mac table flushes on our datacenter 
> switches, which are connected via layer 2 with the office. We currently 
> hooked up an HP switch with TCN  guard to mitigate this, but this introduces 
> a SPOF.
> 
> Any ideas?
> 
> Thanks,
> 
> Dennis Hagens
> ___
> 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 check MAG & SA's cpu and memory

[Ben Dale]

If you boot the device up with a console cable attached, you'll get the BIOS 
dump to serial.  In the case of a MAG2600, it's running an Intel Atom @ 1.6Ghz 
and has 2GB of RAM:

AMIBIOS(C)2006 American Megatrends, Inc.
JPR-PICCOLO-2NBP (B150) V1.3 PN (10/18/2010)
CPU : Genuine Intel(R) CPU N270   @ 1.60GHz
 Speed : 1.60 GHz

The MCH is operating with DDR2-533/CL4 in Single-Channel Mode
Initializing USB Controllers .. Done.
2040MB OK

Cheers,

Ben

On 04/09/2013, at 4:26 PM, 徐见  wrote:

> Hi all:
> 
> As the title said, I want to know SA and MAG’s cpu and memory
> information, 
> 
> I have a box, MAG2600, how do I get them, or where could I get them from
> internet?
> 
> I have checked the datasheets, no message.
> 
> ___
> 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] QinQ termination on branch SRX

[Ben Dale]

Hi Darren,

On 02/09/2013, at 7:34 PM, Darren O'Connor  wrote:

> Does anyone know if this is supported on branch SRX devices yet? The only 
> thing I can find is a thread from two years ago stating 'we are working on 
> it' - 
> http://forums.juniper.net/t5/SRX-Services-Gateway/Terminating-q-in-q-on-a-SRX220h/td-p/104350
> 
> I'm trying to get the equivalent of the Cisco config:
> interface gi0/1.10
> encap dot1q 200 second-dot1q 10
> ip address x.x.x.x
> 


This came in 12.1X44D10:

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-interface-vlan-tagging-configuring.html

You'll need something like this:

bdale@clx-bdr# show interfaces fe-0/0/4  
flexible-vlan-tagging;
unit 50 {
vlan-tags outer 200 inner 10;
family inet {
address 172.17.17.1/24;
}
}

Cheers,

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

Re: [j-nsp] VPN tunnel between OpenSwan and SRX220

[Ben Dale]

Hi Laurent.

Is your ultimate goal to get the GRE running over IPSEC, or just a vanilla 
IPSEC tunnel?  Your configuration will need to change either way:

If you want GRE over IPSEC:

You need to remove the /32 on the st0.0 interface and the Openswan 
rightsourceip and make them a contiguous subnet eg:
172.31.254.41/30 on the Juniper side
172.31.254.42/30 on the Openswan side

Now adjust your GRE configuration to use these addresses for source and 
destination on both ends
Now adjust your remote proxy-id on the SRX  and leftsubnet on Openswan to match 
(just the IPs, leave the mask as /32).

The logic behind this is that you will only encrypt traffic between 
172.31.254.41/32 and 172.31.254.42/32 which will be your GRE tunnelled traffic 
(all other traffic will be wrapped up inside this GRE).  

As an aside - the last time I checked, the SRX seemed to only use the Proxy-ID 
to negotiate the tunnel and then promptly ignored it and allowed you to send 
and receive whatever traffic your routes and policy allowed.

If you're just trying to do vanilla IPSEC tunnels:

Again, change the /32s on the st0.0 and Openswan rightsourceip:
172.31.254.41/30 on the Juniper side (or leave it unnumbered)
172.31.254.42/30 on the Openswan side

Now on the SRX change your proxy-id local to 192.168.123.0/24 and remote to 
whatever is sitting behind the Openswan box (eg: leftsubnet)
On Openswan, change the right-subnet to 192.168.123.0/24 and left-subnet to 
whatever you're trying to tunnel across (or leave it as-is if it's just this 
host, or you're source-natting)

Once you've got this in place and st0.0 comes up, you'll just need to point 
static routes on the SRX side to st0.0 or the Openswan next-hop (172.31.254.42) 
and vice-versa.

If it's still not working, send through the output of:

show security ipsec security-associations

Cheers,

Ben

On 07/08/2013, at 1:55 AM, Laurent CARON  wrote:

> Hi,
> 
> I'm trying to establish a VPN tunnel between a SRX220 and an OpenSwan box.
> 
> SRX is:
> Model: srx220h
> JUNOS Software Release [12.1X44-D20.3]
> 
> OpenSwan: 2.6.37
> 
> Both are currently hooked on a test LAN.
> 
> 192.168.0.18 = openswan box on lan
> 192.168.0.120 = juniper box on lan
> 
> 172.31.254.41 = ipsec on juniper box
> 172.31.254.27 = ipsec on openswan box
> 
> 172.31.255.27 = loopback on juniper box
> 
> Not relevant for now:
> 10.254.2.33 = gre tunnel on openswan side
> 10.254.2.34 = gre tunnel on juniper side
> 
> Here is the config on the Juniper side:
> 
> set interfaces ge-0/0/0 mtu 1514
> set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.120/24
> 
> set interfaces gr-0/0/0 unit 0 tunnel source 172.31.254.41
> set interfaces gr-0/0/0 unit 0 tunnel destination 172.31.254.27
> set interfaces gr-0/0/0 unit 0 family inet address 10.254.2.34/32
> 
> set interfaces lo0 unit 0 family inet address 172.31.255.41/32
> 
> set interfaces st0 unit 0 family inet address 172.31.254.41/32
> 
> set interfaces vlan unit 0 family inet address 192.168.123.1/24
> 
> set routing-options static route 172.31.254.27/32 next-hop st0.0
> 
> set security ike traceoptions file vpn-debug-ike
> set security ike traceoptions flag all
> 
> set security ike proposal ike_aes_128 authentication-method pre-shared-keys
> 
> set security ike proposal ike_aes_128 dh-group group2
> set security ike proposal ike_aes_128 authentication-algorithm sha1
> set security ike proposal ike_aes_128 encryption-algorithm 3des-cbc
> set security ike proposal ike_aes_128 lifetime-seconds 3600
> 
> set security ike policy phase1_aes_128 mode main
> set security ike policy phase1_aes_128 proposals ike_aes_128
> set security ike policy phase1_aes_128 pre-shared-key ascii-text "pwd"
> 
> set security ike gateway RTR-SIEGE-001 ike-policy phase1_aes_128
> set security ike gateway RTR-SIEGE-001 address 192.168.0.18
> set security ike gateway RTR-SIEGE-001 no-nat-traversal
> set security ike gateway RTR-SIEGE-001 external-interface ge-0/0/0.0
> 
> set security ipsec proposal ipsec_aes_128 protocol esp
> set security ipsec proposal ipsec_aes_128 authentication-algorithm 
> hmac-sha1-96
> 
> set security ipsec proposal ipsec_aes_128 encryption-algorithm 3des-cbc
> set security ipsec proposal ipsec_aes_128 lifetime-seconds 3600
> 
> set security ipsec policy phase2_aes_128 proposals ipsec_aes_128
> 
> set security ipsec vpn VPN_TO_SIEGE-001 bind-interface st0.0
> set security ipsec vpn VPN_TO_SIEGE-001 ike gateway RTR-SIEGE-001
> set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity local 
> 172.31.254.41/32
> set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity remote 
> 172.31.254.27/32
> set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity service any
> set security ipsec vpn VPN_TO_SIEGE-001 ike ipsec-policy phase2_aes_128
> set security ipsec vpn VPN_TO_SIEGE-001 establish-tunnels immediately
> 
> set security flow traceoptions file vpn-debug
> set security flow traceoptions flag basic-datapath
> set security flow traceoptions flag packe

Re: [j-nsp] Config archive subtleties

[Ben Dale]

I haven't use this in anger for a while, so apologies if some of this 
functionality is already available, but how about:

- an option to disable compression of the config file
- an option to specify the naming convention used - eg: always back up to a 
single file-name rather than appending the date and let your existing version 
control handle the diffs
- checking it into git/subversion rather than just copying it to upstream 
folder (hey, a guy can dream)


On 08/08/2013, at 5:25 AM, Phil Shafer  wrote:

>> 7 aug 2013 kl. 18:03 skrev Phil Mayers :
>> Recently this fell apart on us, as the SSH key on the server changed and the 
>> archival 
>> transfers started to silently[1] fail.
> 
> Ick.  Silence is deadly.  This (and the other issues) is now PR 910647.
> 
>> All of which has me wondering if the feature is more trouble than it's worth.
> 
> We definitely should be making it more robust and stable, but to
> me the value of catching each commit as a distinct delta is a win.
> It should also have the commit time, user, and commit comment, if
> given.  Having this in a repo means one can ask questions like "who
> has changed config in my network since last Friday?" or "when did
> this statement get added in the first place?".
> 
> What else can we do to make this more worthwhile?
> 
> Thanks,
> Phil
> 
> ___
> 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] LN2600: an 8SFP Branch SRX

[Ben Dale]

I have one here on my desk and on paper, they're basically an SRX240 wrapped in 
7kgs of heatsink (with SFP interfaces). 

Of note though is that they do stack up rather well against unmanageable honey 
badgers:

http://www.flickr.com/photos/junipernetworks/9394081849/

Cheers,

Ben

On 03/08/2013, at 2:12 AM, Phil Fagan  wrote:

> Makes sense; good to see Juniper...and SRX...in that field.
> 
> 
> On Fri, Aug 2, 2013 at 10:08 AM, Eduardo Barrios
> wrote:
> 
>> 
>> Rugged means it's IEEE1613 compliant. For the electric utility companies
>> these devices go in substations so they need to keep forwarding packets
>> when introduced in those environments with higher temperatures and a lot of
>> EMI (Electro Magnetic Interference) - can't blame it on the solar flare
>> theory. ;-)
>> 
>> Also utilities are beginning to run their protective relay protocols
>> through IP networks so they are looking for reliability or risk blowing out
>> $2mil transformers.
>> 
>> I've been testing the LN2600 and yes it does run the SRX code.
>> 
>> HTH,
>> Eduardo
>> 
>> Eduardo Barrios, EIT, JNCIS-SP
>> IP/MPLS Telecommunications Specialist
>> Lower Colorado River Authority  | 3505 Montopolis Dr. |  Austin, TX 78744
>> 512.730.6332 ph
>> 
>> 
>> 
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>> Of Phil Fagan
>> Sent: Friday, August 02, 2013 10:12 AM
>> To: Julien Goodwin
>> Cc: juniper-nsp
>> Subject: Re: [j-nsp] LN2600: an 8SFP Branch SRX
>> 
>> Where do these "rugged" devices usually get put? Just outdoors?
>> 
>> 
>> On Fri, Aug 2, 2013 at 8:05 AM, Julien Goodwin >> wrote:
>> 
>>> Saw this come through on my RSS reader, it's worth a shout out as I'm
>>> sure more people than just me have been wanting a branch SRX with decent
>>> SFP density there's finally an option.
>>> 
>>> http://www.juniper.net/us/en/products-services/routing/ln-series/ln2600/
>>> 
>>> I'm assuming it runs the same branch SRX image as the rest of the line
>>> as that's been true for the LN1000 and this looks like more of the same.
>>> 
>>> It's 48v only which is a shame, and being a rugged device I'm sure it's
>>> "reassuring expensive".
>>> 
>>> Also hidden in the datasheet is a reference to an LN2800 which has not
>>> been announced, but is obviously a similar rugged 1ru box of some sort.
>>> 
>>> 
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>> 
>> 
>> 
>> --
>> Phil Fagan
>> Denver, CO
>> 970-480-7618
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> 
> 
> 
> -- 
> Phil Fagan
> Denver, CO
> 970-480-7618
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


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

Re: [j-nsp] EX4550 version

[Ben Dale]

I believe 12.3R2 still has the bug where the syslog fills up with erroneous 
messages about one or both of the power supplies being removed (12.3R1 
complains about the fan tray AND the power supplies).  This is finally put to 
bed in 12.3R3

Cheers,

Ben

On 24/07/2013, at 7:56 PM, Pierre-Yves Maunier  wrote:

> I'll be deploying a couple of EX4550 doing mainly L3/MPLS stuff (ospf,
> bgp, l3vpn, l2circuit) and I'm going to roll out 12.3R3.4.
> 
> Generally I prefer using at least an R3 release and as Juniper
> promised me that 12.3 would be 'the next 11.4' then I'm going for this
> one.
> 
> 2013/7/24 Luca Salvatore :
>> Hi All,
>> 
>> Just got a couple of new EX4550 switches... current recommended version is 
>> 12.2r2.5
>> But I just saw tha the 12.2 train is up release 5.3.
>> 
>> Just wondering what the rest of you guys are running  and if you have any 
>> horror stories.
>> I'm not doing VC with these guys, they are going to be a pretty simple layer 
>> 2 aggregation type switch.
>> 
>> Thanks.
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


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

Re: [j-nsp] EX4550 version

[Ben Dale]

I pulled one out of the box the other day and whatever it shipped with wouldn't 
bring up 10G DAC cables (Cisco branded) and the backlight on the LCD panel 
didn't work (?!!) until I upgraded it (12.3R3), which fixed both issues.

On 24/07/2013, at 2:49 PM, Mark Tinka  wrote:

> On Wednesday, July 24, 2013 03:27:23 AM Luca Salvatore 
> wrote:
> 
>> Just got a couple of new EX4550 switches... current
>> recommended version is 12.2r2.5 But I just saw tha the
>> 12.2 train is up release 5.3.
>> 
>> Just wondering what the rest of you guys are running  and
>> if you have any horror stories. I'm not doing VC with
>> these guys, they are going to be a pretty simple layer 2
>> aggregation type switch.
> 
> We've been running ours since January this year, and back 
> then, only 12.2R2.4 was available for the chassis.
> 
> Nothing major on our end, just pure Layer 2 aggregation in 
> the core. Haven't seen any problems yet, but our deployment 
> isn't that interesting. I use them mostly for the port 
> speed.
> 
> 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] SRX devices upgraded to 2GB ram

[Ben Dale]

On 24/07/2013, at 12:53 AM, Pavel Lunin  wrote:

> 
> 22.07.2013 19:09, Gavin Henry wrote:
>> This is the info we got from our supplier in UK who is a Juniper Elite
>> partner:
>> 
>> " It's the same functionality and operation, just comes with 2G memory.
>> It's part of a general refresh of the line that Juniper are doing just now
>> to support future applications."
>> 
>> Not sure how close those applications are. Some more UTM apps?
>> 
> 
> That's true, but there is a caveat (apart from the minimal JUNOS version).
> 
> Although I haven't asked local SE, I'm sure the -H2 models won't cluster with 
> the old SRXes. So people planning to upgrade their already installed SRXes to 
> clusters must either speed up or they will need to buy two boxes instead of 
> one. EoL for old models is 31 Dec 2013 but the channels will obviously hold 
> the new models as soon as they get rid of old stocks.
> 

Not even remotely true - I have a 240H and a 240H2 clustered together on my 
desk right beside me - no issues..  

Unscientifically, the H2 does seem to boot faster so make it your primary when 
you can ; )   

This transition isn't that big a deal - it's happened plenty of times in the 
past.  J-Series with 256MB RAM and flash anyone?

Ben


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

Re: [j-nsp] limitation to vrrp-group inheritance on MX?

[Ben Dale]

Hi Clarke,

Even though you have vrrp-inherit-from enabled, the interfaces are still 
participating in VRRP, albeit at a much slower rate (just enough to keep 
downstream ARP refreshed) so the MX is still allocating a specific VRRP MAC per 
group and thus the 255 limit still applies per interface.

See 
http://www.juniper.net/techpubs/en_US/junos11.4/topics/task/configuration/vrrp-inheritance-for-a-group-configuring.html

And in particular:

"the groups that are inheriting the state do send out VRRP advertisements once 
every 2 to 3 minutes so as to facilitate MAC address learning on the switches 
placed between the VRRP routers."

Cheers,

Ben

On 23/07/2013, at 7:18 AM, Clarke Morledge  wrote:

> It looks like there is a limitation as to the number of times you can inherit 
> settings from a particular vrrp-group on a single interface, but is this 
> correct?
> 
> Assume you have a single vlan with multiple IP subnets configured. However, 
> all you need is to have a single vrrp-group where all of the other IP subnets 
> can inherit vrrp config information from, let's say, the vrrp group with the 
> preferred address.  For example:
> 
> [edit interfaces irb unit 100]
> MX# show
> family inet {
>address 192.168.37.3/25 {
>preferred;
>vrrp-group 100 {
>priority 125;
>accept-data;
>virtual-address 192.168.37.1;
>}
>}
>address 192.168.38.3/25 {
>vrrp-group 101 {
>virtual-address 192.168.38.1;
>vrrp-inherit-from {
>active-interface irb.100;
>active-group 100;
>}
>}
>}
>address 192.168.39.3/25 {
>vrrp-group 102 {
>virtual-address 192.168.39.1;
>vrrp-inherit-from {
>active-interface irb.100;
>active-group 100;
>}
>}
>}
> }
> 
> 
> For each IP address configured on the IRB interface (associated with one 
> particular vlan), you must have a DIFFERENT vrrp-group configured, even 
> though the "inheriting" addresses are only effectively using the vrrp-group 
> number as unique identifiers and place holders.
> 
> If you try to use the SAME vrrp-group number for each address; e.g. "100", 
> you get a configuration error upon commit:
> 
> "Duplicate interface: irb unit: 100 vrrp-group: 100 for address:."
> 
> Vrrp has a limitation as to the nunmber of groups available per vlan, 255. 
> Granted, having more than 255 addresses per interface is a lot, but it seems 
> arbitrary that the MX limits you to only having 255 IP subnets per vlan that 
> can use VRRP.
> 
> Having a maximum of 255 VRRP active groups per vlan makes sense, as this is 
> what the VRRP standard specifies, but when you have a bunch of basically 
> "inactive" groups that inherit from one active group, it seems bizarre that 
> Junos says, "NOPE, you can only have a maximum of 254 placeholders for 
> inactive vrrp groups per interface."
> 
> Am I misunderstanding something here?
> 
> 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] Vlan question MX

[Ben Dale]

On 09/07/2013, at 8:00 AM, Tom Storey  wrote:

> The thing thats confusing me is, who on earth presents a service to a
> customer as a tagged service? Ive never come across such a thing.
> 
> If you're plugged in to a router interface on the providers side, why is
> there a need to add VLAN tagging on top? Similarly, if you're plugged in to
> a switch, normally the switch port is just an access port, not a trunk.
> 
> Someone help me out here... :-)

dot1p for MetroE services?  There might be a big gap between you and the PE, 
and the access network may be standardised to allow E-Line/E-LAN etc. on top of 
L3VPN tails.


> 
> 
> On 8 July 2013 22:47, Michael Loftis  wrote:
> 
>> vlan-tagging tells JunOS to treat the interface as multiple separate
>> L3 interfaces, identified by VLAN ID.  Their end is almost certainly
>> similarly configured (maybe as a MPLS PE)
>> 
>> On Mon, Jul 8, 2013 at 10:26 AM, Keith  wrote:
>>> Have this setup in the lab on some srx's but want to get some info
>>> on this.
>>> 
>>> We have an upstream provider that we use a config:
>>> 
>>> set interfaces ge-0/1/0 vlan-tagging
>>> set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
>>> set interfaces ge-0/1/0 unit 1500 vlan-id 1500
>>> set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30
>>> 
>>> 
>>> We are turning up a second connection to them that will be terminated on
>> a
>>> 10G
>>> link and want us to use the same thing, vlan 1500, just a different IP
>>> address.
>>> 
>>> Will this cause a problem by having the same vlan id on both links to the
>>> same provider? (I am guessing we are being terminated on different
>> routers
>>> on their side).
>>> 
>>> My lab router didn't complain so I'm guessing its probably ok.
>>> 
>>> Thanks,
>>> Keith
>>> 
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> 
>> --
>> 
>> "Genius might be described as a supreme capacity for getting its possessors
>> into trouble of all kinds."
>> -- Samuel Butler
>> ___
>> 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] Advice on a 100Gbps+ environment

[Ben Dale]

The QFX3600 is probably a little expensive for L2, but 64x 10GE ports in a 1RU 
ToR (or 16x 40GE, or a combination in the middle) is pretty solid.  

According to the docs they also support link aggregation up to 32 members[1].  
Would be interesting to know if this allows 40GE ports to be used natively in 
an aggregated ethernet...

[1] 
http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/qfx-series-software-features-overview.html#high-availability-features-by-platform-table

> 
> On Tue, Jul 2, 2013 at 11:00 AM, Morgan McLean  wrote:
> 
>> Wow, this thread snowballed into quite the MX80 debate. For the record, I
>> run two in production where I am employed full time and they perform
>> beautifully, though woefully underutilized.
>> 
>> Using static routes and /32's as peering endpoints is a great option I
>> skimmed over, I'll see if the upstream can do this...they should.
>> 
>> Unfortunately, the customer signed the contract for bandwidth with
>> inteliquent; we have existing 10G with telia and 10G with cogent along with
>> a couple existing 10G from inteliquent, but I'm not sure if they'll stay.
>> So I didn't really have much say...I think the price point was more
>> important than the benefits of signing to a few carriers. In short, I'm
>> working on that.
>> 
>> This traffic should be mostly web.
>> 
>> Sorry, I meant to say OSPF and ECMP. I would like to be able to run the
>> VRRP at the end of row and extend L3 as far as I can, but I guess the
>> customer wants to be able to spread machines in the same environments among
>> multiple rows, which is understandable, but that means I need to run L2
>> from distribution to access. Each row needs 100gbps useable, so I suppose 4
>> x 40GBE LAGs would do the trick nicely. If my client doesn't want to spend
>> the money in that area...
>> 
>> Any good aggregation switch suggestions? Juniper is doesn't provide good
>> ports for $ in the switching realmcustomer balked at the cost for a
>> four port 40G blade on a 9200. Might check out brocade..
>> 
>> Thanks,
>> Morgan
>> 
>> 
>> On Tue, Jul 2, 2013 at 8:13 AM, Christian de Balorre <
>> cdebalo...@neotelecoms.com> wrote:
>> 
>>> Slow control-plane. No RE redundancy. More limited rib & fib than regular
>>> MX. Cryptic licensing scheme.
>>> Otherwise nothing really wrong.
>>> 
>>> Christian
>>> 
>>> Le 02/07/2013 15:55, Drew Weaver a écrit :
>>> 
>>> And what is wrong with the MX80 as a peering/transit router for up to
 80Gbps of traffic?
 
 Thanks,
 -Drew
 
 
 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-bounces@**puck.nether.net<
>> juniper-nsp-boun...@puck.nether.net>]
 On Behalf Of Dobbins, Roland
 Sent: Tuesday, July 02, 2013 9:01 AM
 To: juniper-nsp Puck
 Subject: Re: [j-nsp] Advice on a 100Gbps+ environment
 
 
 On Jul 2, 2013, at 7:19 PM, Mark Tinka wrote:
 
 Says who?
> 
 Doh - MX*480*, not MX*80*.  My mistake.
 
 --**--**
 ---
 Roland Dobbins  // 
 
  Luck is the residue of opportunity and design.
 
   -- John Milton
 
 
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsp<
>> 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<
>> 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<
>> https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>> 
>> 
>> 
>> 
>> --
>> Thanks,
>> Morgan
>> ___
>> 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] similar ASA feature (RRI) on SRX

[Ben Dale]

On 25/06/2013, at 7:08 AM, "OBrien, Will"  wrote:

> You can just point the route at the st0.x interface. When it's down, the 
> route won't install in the table.
> 
> 

Just watch this in 11.4R5.5 (and others nearby) - there was a bug introduced 
that kept the state of the tunnel sub-interface up even once the security 
associations were cleared.  Fixed in 12.1R4 (at least).



> On Jun 24, 2013, at 3:57 PM, Alberto Santos wrote:
> 
> Hi,
> 
> it looks like a possibility, but the remote IP address keeps changing because 
> it is dialup connection. can't monitor the next hop.
> 
> 
> BR
> 
> 
> Alberto Santos
> CCIE #26648
> JNCIS-SP - ITIL-F
> "...Fix your DNS, make it dual-stack, take your mail server and make it 
> dual-stack, take your web server and make it dual-stack..." by Randy 
> Bush/RIPE IPv6
> 
> 
> On 24 June 2013 13:15, OBrien, Will 
> mailto:obri...@missouri.edu>> wrote:
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB24362
> 
> On Jun 24, 2013, at 8:38 AM, Alberto Santos wrote:
> 
>> Hi there,
>> 
>> I'm swapping a cisco ASA and I found myself stuck on how configure any
>> similar to cisco RRI(reverse route injection) feature on junos,I'm load
>> balacing with a BigIP between them and I need to know where the tunnel is
>> active in order to advertise it on OSPF, has anyone experience any in the
>> past? please send your thoughts, just keep in my that I can't run any IGP
>> over the tunnel .
>> 
>> 
>> BR/Alberto
>> ___
>> 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