Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces
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
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
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
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?
> 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