Re: [j-nsp] srx ipsec tunnel over mpls l3vpn
gt;ESP Statistics: > > > > Encrypted bytes: 252264 > > > > Decrypted bytes:0 > > > > Encrypted packets: 1618 > > > > Decrypted packets: 0 > > > >AH Statistics: > > > > Input bytes:0 > > > > Output bytes: 0 > > > > Input packets: 0 > > > > Output packets: 0 > > > >Errors: > > > > AH authentication failures: 0, Replay errors: 0 > > > > ESP authentication failures: 0, ESP decryption failures: 0 > > > > Bad headers: 0, Bad trailers: 0 > > > > > > > >root@demo-srx300> show security flow statistics | grep rop > > > >Packets dropped: 15650 > > > > > > > >root@demo-srx300> ping 10.102.199.66 routing-instance one rapid > >interval .1 count 100 > > > >PING 10.102.199.66 (10.102.199.66): 56 data bytes > > > > >... > . > > > > > >--- 10.102.199.66 ping statistics --- > > > >100 packets transmitted, 0 packets received, 100% packet loss > > > > > > > >root@demo-srx300> show security ipsec statistics > > > >ESP Statistics: > > > > Encrypted bytes: 267864 > > > > Decrypted bytes:0 > > > > Encrypted packets: 1718 > > > > Decrypted packets: 0 > > > >AH Statistics: > > > > Input bytes:0 > > > > Output bytes: 0 > > > > Input packets: 0 > > > > Output packets: 0 > > > >Errors: > > > > AH authentication failures: 0, Replay errors: 0 > > > > ESP authentication failures: 0, ESP decryption failures: 0 > > > > Bad headers: 0, Bad trailers: 0 > > > > > > > >root@demo-srx300> show security flow statistics | grep rop > > > >Packets dropped: 15755 > > > > > > > >-Aaron > > > > > > > >___ > >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 > > -- Regards, Craig Askings io Networks ion consulting Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 No Holidays scheduled ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] srx ipsec tunnel over mpls l3vpn
t;10.101.14.197 > >* ? 345680 L 9 6>10.101.14.197 > >* ? 345696 L 9 7>10.101.14.197 > >* ? 345712 L 9 7>10.101.14.197 > >* ? 345728 L 9 6>10.101.14.197 > >* ? 345744 L 9 7>10.101.14.197 > > > >root@demo-srx300> show route table mpls.0 terse | count > >Count: 528 lines > > > >root@demo-srx300> show ldp neighbor > >AddressInterface Label space ID Hold time > >10.101.14.197 ge-0/0/0.0 10.101.0.254:0 10 > > > >root@demo-srx300> > > > > > > > >-Original Message- > >From: Emille Blanc [mailto:emi...@abccommunications.com] > >Sent: Thursday, July 11, 2019 3:04 PM > >To: Aaron Gould; juniper-nsp@puck.nether.net > >Subject: RE: [j-nsp] srx ipsec tunnel over mpls l3vpn > > > >Based on what you described, it sounds like you already got your MPLS/LDP > >running in a packet-mode routing-instance, as otherwise MPLS is dropped on > >an SRX in flow mode. > > > >No obvious ideas with the output provided otherwise. > >Do the flows in your IPSEC instance get created? > > > >-Original Message- > >From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > Of > >Aaron Gould > >Sent: Thursday, July 11, 2019 12:27 PM > >To: juniper-nsp@puck.nether.net > >Subject: [j-nsp] srx ipsec tunnel over mpls l3vpn > > > >Anyone ever done it ? To be clear, I have mpls/ldp/ospf/bgp enabled the > SRX > >such that I have an l3vpn functional into the SRX. > > > > > > > >I have a lo0.99 interface as the external interface used for ike/ipsec. > >Seems that I'm pretty close to getting this done, as i have ike phase 1 up > >and ike phase 2 up, but only seeing encrypted packets as I try to ping > >between the st0.0 interface and the ms-0/0/0.1 inside interface on the > other > >side (mx104 with ms-mic-16g) > > > > > > > >Let me know what I'm missing. > > > > > > > >I'm seeing drops in these to show outputs. which seems to coincide with a > >100-packet ping test... > > > > > > > > > > > >root@demo-srx300> show security flow statistics > > > >Current sessions: 9 > > > >Packets forwarded: 417926 > > > >Packets dropped: 15604 > > > >Fragment packets: 0 > > > >Pre fragments generated: 0 > > > >Post fragments generated: 0 > > > > > > > >root@demo-srx300> show security flow status > > > > Flow forwarding mode: > > > >Inet forwarding mode: flow based > > > >Inet6 forwarding mode: drop > > > >MPLS forwarding mode: drop > > > >ISO forwarding mode: drop > > > >Enhanced route scaling mode: Disabled > > > > Flow trace status > > > >Flow tracing status: off > > > > Flow session distribution > > > >Distribution mode: RR-based > > > >GTP-U distribution: Disabled > > > > Flow ipsec performance acceleration: off > > > > Flow packet ordering > > > >Ordering mode: Hardware > > > > > > > >root@demo-srx300> show security ipsec statistics > > > >ESP Statistics: > > > > Encrypted bytes: 252264 > > > > Decrypted bytes:0 > > > > Encrypted packets: 1618 > > > > Decrypted packets: 0 > > > >AH Statistics: > > > > Input bytes:0 > > > > Output bytes: 0 > > > > Input packets: 0 > > > > Output packets: 0 > > > >Errors: > > > > AH authentication failures: 0, Replay errors: 0 > > > > ESP authentication failures: 0, ESP decryption failures: 0 > > > > Bad headers: 0, Bad trailers: 0 > > > > > > > >root@demo-srx300> show security flow statistics | grep rop > > > >Packets dropped: 15650 > > > > > > > >root@demo-srx300> ping 10.102.199.66 routing-instance one rapid interval > .1 > >count 100 > > > >PING 10.102.199.66 (10.102.199.66): 56 data bytes > > > > > >
Re: [j-nsp] ICMP from SRX accross policy vpn tunnel
Alternative solution. Keep doing route based tunnels, but use traffic selectors. I use it to have the remote end doing policy based ipsec (old cisco cpe as an example) while keeping the SRX as a route (st interface) based ipsec implementation. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-traffic-selectors-in-route-based-vpns.html On Thu, 9 May 2019 at 06:19, Lenny Shovsky wrote: > Wondering how to get ping to work directly from SRX across ipsec policy > tunnels. > > Have no issues dong it with route based tunnels, simply using lo0 with > tunneled subnet address and default-address-selection option, but can't > make it work with policy tunnels. > > Long term goal is to get vpn-monitor option to work. > > Thanks in advance for all your feedback ! > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Regards, Craig Askings io Networks ion consulting Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 No Holidays scheduled ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper finally launches a route reflector platform
Huzzah, I'd been bugging my local Juniper rep to turn the xre200 into a Route Reflector. This looks a much better setup. On 25 February 2014 09:13, Julien Goodwin jgood...@studio442.com.au wrote: And in a sensible form factor too. http://www.juniper.net/us/en/products-services/routing/cse2000/ Can think of plenty of other use cases for the box as well. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX1400 opinions
That does remind me though, if you want to use the ISSU feature when upgrading a SRX HA pair. Make sure you check the protocols will be using are supported. http://kb.juniper.net/InfoCenter/index?page=contentid=KB17946 On 29 April 2013 15:46, Andrew Jones and...@commitconfirmed.com wrote: Scratch that, branch SRX's only! On Mon, Apr 29, 2013 at 3:44 PM, Andrew Jones and...@commitconfirmed.com wrote: You will also need to follow this if adding a New/RMA SRX into a cluster which is 10.4 or older, should save you a few days of troubleshooting :) http://kb.juniper.net/InfoCenter/index?page=contentid=KB23929 On Mon, Apr 29, 2013 at 3:33 PM, Craig Askings caski...@ionetworks.com.au wrote: Hi Jim, On 29 April 2013 05:49, James Howlett jim.howl...@outlook.com wrote: Hi Paul, Thank You very much for the clarification. I will have only one ASBR. As for redundancy I'll go with a single 1400 unit and add a second in the future. Still, a single SRX1400 will be probably more stable then a single J6350. I recently had a client that had a simliar plan to you of a single SRX1400 now to a HA pair later. No BGP though, when we setup the first SRX we configured it as if it was part of a HA pair and left it running in a Active/Lost state. Once we got the second SRX we followed the SRX HA Hardware replacement procedure in the Juniper KB and it all went smoothly with no hiccups or outages. http://kb.juniper.net/InfoCenter/index?page=contentid=KB21134 -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ 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 -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX1400 opinions
Hi Jim, On 29 April 2013 05:49, James Howlett jim.howl...@outlook.com wrote: Hi Paul, Thank You very much for the clarification. I will have only one ASBR. As for redundancy I'll go with a single 1400 unit and add a second in the future. Still, a single SRX1400 will be probably more stable then a single J6350. I recently had a client that had a simliar plan to you of a single SRX1400 now to a HA pair later. No BGP though, when we setup the first SRX we configured it as if it was part of a HA pair and left it running in a Active/Lost state. Once we got the second SRX we followed the SRX HA Hardware replacement procedure in the Juniper KB and it all went smoothly with no hiccups or outages. http://kb.juniper.net/InfoCenter/index?page=contentid=KB21134 -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On 16 April 2013 08:03, Mark Tinka mark.ti...@seacom.mu wrote: What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) You're preaching to the choir. Then again, I wouldn't suggest an ASR9001 for this task either. 8GB is not bad, but you can get 16GB on the ASR1001. Also, the ASR9001 is a PPC-based platform (unlike the Intel Xeon's on the ASR9006/9010), while the ASR1001 is an Intel, if that makes any difference to you. I'd love to see Juniper take the xre200, slap some extra ram into it and call it their route reflector platform. It would be a reasonable compromise between using generic compute and Juniper getting $$$ for selling you some tin. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On 2 April 2013 09:06, Ben Dale bd...@comlinx.com.au wrote: I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. When the ex2200C came out, I considered it as a Metro-E CPE / demarc device. It was missing to many features for that role at the time and lost out to devices targeted for that market such as the T-marc 340 or an ADVA FSP(?). As much as disliked working on the T-marcs, they were cheap and it was easy enough to dump a template on it and never touch them again. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 Release Date
Juniper now want you to buy a Advanced features licence to support Unicast reverse-path forwarding (RPF), this is getting absurd. On 3 February 2013 20:57, Tore Anderson t...@fud.no wrote: * Paul Goyette 12.3 has now been released. http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/ex-series-software-licenses-overview.html#jd0e146 http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series-software-licenses-overview.html#jd0e146 Comparing the above seems to suggest that if you're using e.g. OSPFv2 or VRRP today, you must purchase an Advanced Feature Licence in order to upgrade to 12.3. Is that really the case? Also, what is meant with the phrase with four active interfaces for OSPF? I hope it does not mean that if you're running OSPF on five or more interfaces today, you simply cannot upgrade to 12.3? Best regards, -- Tore Anderson ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LDP on ex4200/3200 series….and 1RU LSR?
On 19 December 2012 20:18, Mark Tees markt...@gmail.com wrote: Hi list. Has anyone heard about if there is ever going to be support for LDP on the ex4200/3200 series? From what I understand the chipset on ex4200/3200 does not support more than one mpls label, so LDP etc is not possible on that hardware. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On Saturday, October 27, 2012, Richard A Steenbergen wrote: I'm still sad that I couldn't get Juniper to bless the XRE200 as an external route reflector, since it's an infinitely more useful form factor than a JCS, but alas lack of common sense knows no bounds. :) I'm glad I'm not the only one who looked at XRE200 and thought it would make a great RR. Like you I didn't have much luck in getting juniper to agree with that. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 to MX80 virtual chassis feature
On 23 October 2012 12:05, Julien Goodwin jgood...@studio442.com.au wrote: As for high speed link to an EX something along those lines has now been announced as Node Unifier for FEX-like support. It's a shame that the sum total of detail on that feature on Juniper's public website is two paragraphs that give very little detail on it. Junos Node Unifier Junos Node Unifier is a platform clustering program for MX Series 3D Universal Edge Routers that centralizes management and automates device configuration to enable the connection of thousands of router and switch ports attached to MX. Junos Node Unifier enables the scaling of applications in the data center and large-scale mobile backhaul operations by supporting multiple connection types at optimal rates. It supports increased interface density for configurations such as port-fan-out, port-multiplexing, and L2 switching, for server port aggregation and L3/MPLS routing access on satellites, while retaining intelligent end device functionality to deliver rich services -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients
Another option is to get the cheapest Areohive Access point and use their Bonjour Gateway (Currently in Beta I believe) to control announcements between vlans. On 11 May 2012 10:09, Jonathan Lassoff j...@thejof.com wrote: On the surface, this looks like a much cleaner way of doing things, provided the client support is there. Thanks for the tip, Joel! Cheers, jof -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
