Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[Hugo Slabbert]

On Fri 2017-Nov-03 02:37:30 +, M Abdeljawad  
wrote:



Hi
But the tunnels peering with non juniper firewalls, so I didnt assign st0 
interfaces an IP addresses.And since all st0 interfaces are unnumbered 
then I think one out of them will borrow the external interface IP 
address.


Gotcha.  Not a problem:

Just add `family inet` under the st0 units but do not put any addresses on 
them.  They will be exactly that: IP interfaces with no addresses on them.  
They don't pick up any IP address by default.  Now, if you're generating IP 
unreachables back to the other end, _some_ address will get plopped into 
the source IP field, which will follow usual source address selection 
criteria for the platform.


If you leave it unnumbered, just put `next-hop st0.x` in your static routes 
across to tunnels.


You can actually also cheat and stick whatever /31 you want on there (so 
pick something from your internal ranges) and next-hop to an IP in that 
subnet (e.g. 192.0.2.0/31 on your side, set 192.0.2.1 as the next-hop for 
the route).  It's a point-to-point interface, so Junos will just shove the 
packet across the interface since it has a connected route for that 
next-hop address.  The other party doesn't need to have any addresses 
configured on a virtual tunnel interface on their end for this to work.  
They could even have completely mismatched addresses and it should still 
work.


This also means that if you do generate ICMP unreachables back to the other 
party across the tunnel, they will be sourced from the IP you stick on the 
st0.x interface, in case that helps with any troubleshooting/debugging.


Cheers,

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[M Abdeljawad via juniper-nsp]

Hi
But the tunnels peering with non juniper firewalls, so I didnt assign st0 
interfaces an IP addresses.And since all st0 interfaces are unnumbered then I 
think one out of them will borrow the external interface IP address.


Sent from Yahoo Mail for iPhone


On Friday, November 3, 2017, 4:21 AM, Hugo Slabbert  wrote:


On Fri 2017-Nov-03 00:57:47 +, M Abdeljawad via juniper-nsp 
 wrote:

>Hi
>I want to create three VPN tunnels with third party peers, I want to use 
>route-based VPN with traffic selector as each tunnel has multiple 
>destinations.So can I use multiple st0 interfaces "one for each tunnel"?

Yes; the routed IPSEC tunnels are bound to subinterfaces to st0, so e.g.  
st0.1 (unit 1), st0.2, st0.3, and so forth.  Set that interface or the IP 
on the other end as your next-hop for whatever traffic you want to push 
through that particular tunnel (or run a routing protocol across it if 
that's preferred) and go to town.

>(As I have only one VPN tunnel up out of the three tunnels).

I don't understand this part.  I don't see anything that would prevent you 
from having all of the tunnels up simultaneously unless you want to 
intentionally shut them for some reason.

-- 
Hugo Slabbert      | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E  | also on Signal


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

Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[Hugo Slabbert]

On Fri 2017-Nov-03 00:57:47 +, M Abdeljawad via juniper-nsp 
 wrote:



Hi
I want to create three VPN tunnels with third party peers, I want to use 
route-based VPN with traffic selector as each tunnel has multiple 
destinations.So can I use multiple st0 interfaces "one for each tunnel"?


Yes; the routed IPSEC tunnels are bound to subinterfaces to st0, so e.g.  
st0.1 (unit 1), st0.2, st0.3, and so forth.  Set that interface or the IP 
on the other end as your next-hop for whatever traffic you want to push 
through that particular tunnel (or run a routing protocol across it if 
that's preferred) and go to town.



(As I have only one VPN tunnel up out of the three tunnels).


I don't understand this part.  I don't see anything that would prevent you 
from having all of the tunnels up simultaneously unless you want to 
intentionally shut them for some reason.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

[j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[M Abdeljawad via juniper-nsp]

Hi
I want to create three VPN tunnels with third party peers, I want to use 
route-based VPN with traffic selector as each tunnel has multiple 
destinations.So can I use multiple st0 interfaces "one for each tunnel"?
(As I have only one VPN tunnel up out of the three tunnels).
Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPC5EQ Feedback?

[adamv0025]

> From: Pavel Lunin [mailto:plu...@gmail.com]
> Sent: Wednesday, November 01, 2017 4:08 PM
> 
> 
> 
> There were two versions of MPC3:
> 
> 1. MPC3 non-NG, which has a single XM buffer manager and four LU chips
> (the old good ~65 Mpps LUs as in "classic" MPC1/2/16XGE old trio PFEs).
>
Yeah stay away from those, have fundamental design flaws apart from being 
hugely underpowered (especially with queuing chip enabled). 

> 2. MPC3-NG which is based on exactly the same chipset as MPC5, based on
> XM+XL.
>
Yes the building blocks are the same but the architecture of 5 is completely 
different, it's two XMs talking to common XL. So is it two PFEs or just one 
PFE? If it's two I'd suspect there to be a separate set of VOQs per XM so that 
each XM can backpressure to ingress LC independently. Also if the common XL 
gets oversubscribed does it backpressure to both XMs or just the one 
responsible for most of its cycles? Two discrete arbiters feeding one common XL 
is just asking for trouble. 


> 
> MPC4 is much like MPC3 non-NG though it has two LUs instead of four with a
> new more "performant" microcode.
>
4 is the other way around to 5 it has two gen1 LUs hooked up to one gen2 XM 
(mixing old and new hence Trio 1.5) -again some experiment or need to keep up 
with the competition. 

> 
> XL chip (extended LU), which is present in MPC5/6 and 2-NG/3-NG has also
> multiple ALU cores (four, IIRC) but in contrast to MPC3 non-NG and MPC4
> these cores have a shared memory, so they don't suffer from some
> limitations (like not very precise policers) which you can face with multi-LU
> PFE architectures.
> 
> MPC7 has a completely new single core 400G chip (also present in the
> recently announced MX204 and MX10003).
> This said, I find MPC4 quite not bad in most scenarios. Never had any issues,
> specific to its architecture.
> 
> P. S. Finally this choice is all about money/performance.
> 
As I mentioned in the other discussion most of the folks don't really need to 
dig down to how routers actually work cause either the design does not allow 
the router to get clogged or in cases where ASICs get overloaded customers 
don’t care and understand (...oh I see you had a DDoS situation, yeah that’s 
understandable then that my VPN traffic experienced drops, thank you bye). 
In these cases there's really no point in spending more on the premium kit from 
cisco. 

adam
  

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