Re: [j-nsp] M-series IPSEC / SP interface and VRF

2013-12-18 Thread Alex Arseniev 
And what happens if You ping a destination IP known via BGP across the 
tunnel but with different src.ip?


ping routing-instance VRFname dst.ip source whatever

This src.ip must be known by/reachable from far end.
HTH
Thanks
Alex

On 17/12/2013 20:40, Scott Harvanek wrote:
BGP is running in the tunnel and the next hop is the far side of the 
tunnel, everything looks correct. All the routes show the far end of 
the tunnel and BGP is established inside the VRF but traffic will not 
pass except of traffic directly between the two endpoints. E.g. 
BGP/ICMP on the tunnel subnet.  I'm at a loss.


I'll pull some info and post it back, maybe someone sees something I 
don't.


Scott H.

On 12/17/13, 12:27 PM, Alex Arseniev wrote:
For the traffic to be encrypted, the BGP nexthop has to point into 
the tunnel which means one of the below:

1/ BGP has to run inside the tunnel, or
2/ You have to have a BGP import policy to change the nexthop to 
tunnel's remote address. If this is eBGP, then also add 
accept-remote-nexthop knob.

HTH
Thanks
Alex

On 17/12/2013 16:08, Scott Harvanek wrote:
So this works to establish the tunnels, the problem is, BGP received 
routes over the tunnel do not function correctly.  The routes are 
properly installed in the VRF but traffic to those destinations does 
not pass correctly. Does anyone have any experience running BGP like 
this on the m-series or does it just not work on next-hop-style?


Thanks,
-SH

On 11/12/13, 1:34 PM, Scott Harvanek wrote:

Yep excellent, I'll give it a whirl, thanks!

Scott H.

On 11/12/13, 1:24 PM, Alex Arseniev wrote:
So, if I understand Your requirement, You want sp-0/0/0.unit in 
VRF, correct?

And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from 
inet.0 or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to 
next-hop-style IPSec and place inside sp-* unit into the VRF 
leaving outside sp-* unit in inet.0.

HTH
Thanks
Alex

On 12/11/2013 16:35, Scott Harvanek wrote:

Alex,

Yea, tried this but it looks like you can't set it to the default 
inet.0 instance, only to things different... the local gw in my 
case is in the default instance and I want the service interface 
in another so unless I'm mistaken it's in default by default and 
this fails?


Scott H.

On 11/12/13, 11:22 AM, Alex Arseniev wrote:

Yes

[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options 
local-gateway ?

Possible completions:
  addressLocal gateway address
  routing-instance Name of routing instance that hosts local 
gateway = CHECK THIS OUT!!!

aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]

HTH
Thanks
Alex

On 12/11/2013 16:05, Scott Harvanek wrote:

Anyone with any ideas on this?

Scott H.

On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface 
where the local gateway is NOT in the same routing-instance as 
the service interface?


Here's what I'm trying to do;

[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]

The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT 
the outside interface on router B, I cannot commit unless the 
outside/local-gateway on the IPSec tunnel is in the same 
routing-instance as the service interface, is there a way 
around this? The SRX devices can do this without issue.


service-set  {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules 
}



___
juniper-nsp mailing 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






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

Re: [j-nsp] Anybody use dual RE in srx3k? SCM only?

2013-12-18 Thread Nicholas Oas 
I manage two SRX-3k chassis clusters with CRMs. The main reason we chose
CRMs in our deployment is to have a secondary control link (EM1) to avoid
split-brain scenario should we lose the link for EM0. We did the same thing
with the data plane (FAB0, FAB1) which of course does not require any
special hardware.

While the CRM is *not *a fully fledged RE, you can console into the RJ45
serial for RE1 and talk to it with a limited set of commands. JTAC directed
me to do this.

In that TAC case, EM1 was refusing to link up. The root cause was not
determined, however our use of non-Juniper optics had something to do with
it. Switching them out with the genuine OEM part (e.g. SRX-SFP-1GE-LX ,
SRX-SFP-1GE-SX) resolved our issue. So my advice when selecting parts for
the EM0/EM1 ports is to use the real deal.

Sidebar, of particular annoyance is the fact that at least as of 12.1,
there is absolutely no diagnostic information whatsoever for optics in
ports EM0/EM1. Normally you can 'show interface diagnostics optics', but
not for these two ports. They also do not show up in 'show chassis
hardware'. I sent our SE an enhancement request to get this added, but if
anyone else finds this annoying I encourage them to do the same. :)

That said we are happy with both clusters. Desirable things like ISSU and
session failover work as intended.




On Tue, Dec 17, 2013 at 4:33 PM, Bill Pfeifer bi...@juniper.net wrote:

 SCM will also keep a chassis alive in case of RE failure (assuming it's in
 a cluster and there's an active RE on the other chassis). I don't believe
 that a second RE is supported in 3k, but that's primarily because the SCM
 does everything that a backup RE would be able to do for less $$$ (so even
 if a second RE were supported, there would be no benefit to paying the
 extra cost of using an RE rather than SCM).
 -Bill

 On 12/16/13 6:12 PM, Santiago Martinez santiago.martinez...@gmail.com
 wrote:

 Hi, the SCM will only allow you to use a secondary control link on the
 srx3600. Juniper sales ing said that they are not planning to add support
 for a second RE on the srx3000 family. if you don't have the SCM the
 second control port will be/stay disable.
 Hope it helps
 Santiago.

  On 16 Dec 2013, at 21:26, OBrien, Will obri...@missouri.edu wrote:
 
  Second REs don't really do anything on SRX... yet.
 
  On the 5800s, I had to add them in order to bring up a secondary control
 link. The only thing they do is init the control plane on the chassis for
 that link to come up.
  I believe it's an artifact from stealing the MX chassis.  I don't think
 it does anything for you on the 3600, since that's a different chassis
 architecture altogether.
 
  Will
 
 
  On Dec 16, 2013, at 3:07 PM, Morgan McLean wrote:
 
  Hi all,
 
  Looking into installing the SCM module into a couple of SRX3600's I
 have in
  production. Notice the diagram from juniper says slot RE1 for SCM. Do
 they
  support running another RE? Just curious if anybody does this, if its
 worth
  it or if its even possible.
 
  --
  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





 ___
 juniper-nsp mailing 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