Re: [j-nsp] Maximum IPsec (st0) tunnels for SRX-series
Hi Ben, On Mon, May 6, 2013 at 10:33 AM, Ben Dale wrote: > As long as your tunnels don't breach the IPSEC Throughput numbers, you should > be right™. > > I have a few SRX240s out there with upwards of 500 tunnels on them, some > dynamic routing (3 core sites only), and they're sitting at around 50% CPU. > They're all running DPD with intervals of 10 and 3 (which I think is as low > as you can go). That's a good point. I'll want to run OSPF over all tunnels, so it's not just IPsec/IKE that'll be wanting control plane resources. The biggest branch SRX I've currently got with the most tunnels is a pair of SRX650s with 40 tunnels each (all w/OSPF p2p adjacencies, albeit with default timers). Control plane CPU sits steady at 20% all day. An SRX240 with only 12 tunnels sits at 40% but I recall this being "normal" due to some strange control plane utilisation metric due to the way flowd works on these boxes. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Maximum IPsec (st0) tunnels for SRX-series
As long as your tunnels don't breach the IPSEC Throughput numbers, you should be right™. I have a few SRX240s out there with upwards of 500 tunnels on them, some dynamic routing (3 core sites only), and they're sitting at around 50% CPU. They're all running DPD with intervals of 10 and 3 (which I think is as low as you can go). The scaling numbers I've seen for SRX1400s (for route-based VPNs) are the same as SRX3600s, and about double what the data sheet numbers currently show. Ben On 06/05/2013, at 10:02 AM, Dale Shaw wrote: > Hi all, > > Just looking for some real-world experience with the maximum practical > number of IPsec tunnel (st0) interfaces supported on SRX-series -- > everything from low end/branch up to high end. > > The data sheets say: > > SRX100: 128 > SRX110: 128 > SRX210: 256 > SRX220: 512 > SRX240: 1,000 > SRX550: 2,000 > SRX650: 3,000 > SRX1400: ? > SRX3x00: 7,500 > SRX5x00: 15,000 > > Those are some pretty hefty numbers as you move up the product family > but as we all know, sometimes data sheets are pure fantasy, dreamt up > by sales/marketing types after lavish and expensive liquid lunches. > > I just wanted to know if anyone's seen control planes turn into molten > goop trying to wrangle, say, 100-150 tunnels. > > (I'm not worried about forwarding performance as all I'm looking at > doing is fully-meshing an existing enterprise WAN where the SRX boxen > are doing a great job shuffling packets (er, I mean flows) around.) > > cheers, > Dale > ___ > 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
[j-nsp] Maximum IPsec (st0) tunnels for SRX-series
Hi all, Just looking for some real-world experience with the maximum practical number of IPsec tunnel (st0) interfaces supported on SRX-series -- everything from low end/branch up to high end. The data sheets say: SRX100: 128 SRX110: 128 SRX210: 256 SRX220: 512 SRX240: 1,000 SRX550: 2,000 SRX650: 3,000 SRX1400: ? SRX3x00: 7,500 SRX5x00: 15,000 Those are some pretty hefty numbers as you move up the product family but as we all know, sometimes data sheets are pure fantasy, dreamt up by sales/marketing types after lavish and expensive liquid lunches. I just wanted to know if anyone's seen control planes turn into molten goop trying to wrangle, say, 100-150 tunnels. (I'm not worried about forwarding performance as all I'm looking at doing is fully-meshing an existing enterprise WAN where the SRX boxen are doing a great job shuffling packets (er, I mean flows) around.) cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Urgent advice needed...possible CWDM module conflict, can't keep link.
Hi Morgan, we had troubles on EX4500 with certain xWDM SFP+ (toggling link states like you described) and/or neighbor combinations as well. In our case we could fix it with the SFP+ vendor* engineering department as they offered a modified product. HTH, /Rene * Contact me off-list for more details.. On 5/5/13 11:55 AM, Morgan McLean wrote: Hi all. I'm doing some work migrating from some brocade routers to a couple MX480's. The client currently uses CWDM between two sites, and the brocades handle the SFP's fine. We popped them into the MX480's and link came up and down a few times according to logs (though I could never catch it in an up state with show commands), the green light came on and off a bunch, but link never came. An EX4500 at the other end, which was previously interfacing with the brocade fine, showed tons of link up/ down events in the logs, much more than the MX showed. Is this a sign of an optic incompatibility on the MX side? There was enough signal for sure, and the brocades are able to operate with it so obviously it wouldn't be signal related. Any tips would be helpful. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPC(MX80) + DPCE-R firewall filter cpacity
Oh, and I've forgotten the procedure, but you can query the card directly through shell to check on memory allocation. On May 5, 2013, at 3:08 PM, Peter Krupl wrote: > Hi Group, > > I have googled and checked the KB for som time, but I'm unable to find > anything usable... > > The question is: > Is it safe to apply a firewall filter on an interface with 1700 "from > source-address x.x.x.x/y" criteria ? > Could I do it on several interfaces, what about interface speciffic filters ? > I assume that the limit must be in the Trio or Ichip on each DPC or MPC, > right ? > How can I check resource usage ? > > > Kind regards, > Peter Krüpl > Network Specialist > Tel: +45 88805242 > Siminn Danmark A/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] MPC(MX80) + DPCE-R firewall filter cpacity
You can definitely do this. There's room for several hundred filter statements on the R blades. I had policers (as firewall filters) configured for a couple of /16s on a /24 basis for scale. When I added a third /16 I hit a limit where I couldn't apply changes without restarting the card, if that gives you a sense of scale. (keep in mind that each policer was configured twice - once for each direction. When I did hit the limit, the problem wasn't that it couldn't handle the terms, it was that making changes re-writes the filter to the card in another set of memory, then processing switches over to the new set. The card couldn't handle the double entry of all those terms in the firewall memory - which is a finite amount. Again, even after going way over, a reset of the blade would succeed in writing the filter and using it. Hope that gives you an idea. On May 5, 2013, at 3:08 PM, Peter Krupl wrote: > Hi Group, > > I have googled and checked the KB for som time, but I'm unable to find > anything usable... > > The question is: > Is it safe to apply a firewall filter on an interface with 1700 "from > source-address x.x.x.x/y" criteria ? > Could I do it on several interfaces, what about interface speciffic filters ? > I assume that the limit must be in the Trio or Ichip on each DPC or MPC, > right ? > How can I check resource usage ? > > > Kind regards, > Peter Krüpl > Network Specialist > Tel: +45 88805242 > Siminn Danmark A/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
[j-nsp] MPC(MX80) + DPCE-R firewall filter cpacity
Hi Group, I have googled and checked the KB for som time, but I'm unable to find anything usable... The question is: Is it safe to apply a firewall filter on an interface with 1700 "from source-address x.x.x.x/y" criteria ? Could I do it on several interfaces, what about interface speciffic filters ? I assume that the limit must be in the Trio or Ichip on each DPC or MPC, right ? How can I check resource usage ? Kind regards, Peter Krüpl Network Specialist Tel: +45 88805242 Siminn Danmark A/S ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Urgent advice needed...possible CWDM module conflict, can't keep link.
This is what the optic diagnostic looked like last night. Physical interface: xe-2/0/1 Laser bias current: 68.304 mA Laser output power: 1.1930 mW / 0.77 dBm Module temperature: 25 degrees C / 77 degrees F Module voltage: 3.2660 V Receiver signal average optical power : 0.1097 mW / -9.60 dBm I'll have to check on what the calculated attenuation (Haven't done this before), and what the specs of the optic are. I wasn't able to run this at the EX4500 side because we lost connectivity to the site. But, I'm guessing the problem is on the MX side. Thanks, Morgan On Sun, May 5, 2013 at 3:58 AM, Pierre-Yves Maunier wrote: > If the optics support DOM (Digital Optic Monitoring), what is the received > signal power when you issue the following command ? > > show interface diagnostics optic ge-X/X/X ? > > Then compare it to the specs of the optic, maybe when you moved the optic > and fiber you added some attenuation of the fiber and maybe you were > already out of the specs and you were lucky it worked before. > > On my side I never had issues with non-juniper optics in Juniper > equipments in general. And I would say, if it worked in a broke-ade, it > should work in a Juniper. > > What I would do is to do a show interface diagnostics optic ge-X/X/X on > both side : > > I'd calculate the attenuation between TX Site A and RX Site B and compare > it to the dark fibre calculated attenuation + the mux/demux insertion loss > + 1 dB per patchcord (0.5 per connector) > I'd do the same with TX Site B and RX Site A to see if you have a physical > fiber problem. > > If the optical levels are fine, it might be related to the SFPs. > > > > 2013/5/5 Morgan McLean > >> Hi all. >> >> I'm doing some work migrating from some brocade routers to a couple >> MX480's. The client currently uses CWDM between two sites, and the >> brocades >> handle the SFP's fine. >> >> We popped them into the MX480's and link came up and down a few times >> according to logs (though I could never catch it in an up state with show >> commands), the green light came on and off a bunch, but link never came. >> An >> EX4500 at the other end, which was previously interfacing with the brocade >> fine, showed tons of link up/ down events in the logs, much more than the >> MX showed. >> >> Is this a sign of an optic incompatibility on the MX side? There was >> enough >> signal for sure, and the brocades are able to operate with it so obviously >> it wouldn't be signal related. >> >> Any tips would be helpful. >> >> -- >> Thanks, >> Morgan >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> 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
Re: [j-nsp] Urgent advice needed...possible CWDM module conflict, can't keep link.
It looks like you're using SFP+ ? Are you sure it's CWDM ? Usually 10G modules are DWDM because the wavelengths around 1550nm are better in terms of attenuation. Can you give the brand and model of the WDM optics you're using so we can check -9.6 dBm in reception is within the acceptable power range for reception. 2013/5/5 Morgan McLean > This is what the optic diagnostic looked like last night. > > Physical interface: xe-2/0/1 > Laser bias current: 68.304 mA > Laser output power: 1.1930 mW / 0.77 dBm > Module temperature: 25 degrees C / 77 degrees > F > Module voltage: 3.2660 V > Receiver signal average optical power : 0.1097 mW / -9.60 dBm > > I'll have to check on what the calculated attenuation (Haven't done this > before), and what the specs of the optic are. I wasn't able to run this at > the EX4500 side because we lost connectivity to the site. But, I'm guessing > the problem is on the MX side. > > Thanks, > Morgan > > > On Sun, May 5, 2013 at 3:58 AM, Pierre-Yves Maunier wrote: > >> If the optics support DOM (Digital Optic Monitoring), what is the >> received signal power when you issue the following command ? >> >> show interface diagnostics optic ge-X/X/X ? >> >> Then compare it to the specs of the optic, maybe when you moved the optic >> and fiber you added some attenuation of the fiber and maybe you were >> already out of the specs and you were lucky it worked before. >> >> On my side I never had issues with non-juniper optics in Juniper >> equipments in general. And I would say, if it worked in a broke-ade, it >> should work in a Juniper. >> >> What I would do is to do a show interface diagnostics optic ge-X/X/X on >> both side : >> >> I'd calculate the attenuation between TX Site A and RX Site B and compare >> it to the dark fibre calculated attenuation + the mux/demux insertion loss >> + 1 dB per patchcord (0.5 per connector) >> I'd do the same with TX Site B and RX Site A to see if you have a >> physical fiber problem. >> >> If the optical levels are fine, it might be related to the SFPs. >> >> >> >> 2013/5/5 Morgan McLean >> >>> Hi all. >>> >>> I'm doing some work migrating from some brocade routers to a couple >>> MX480's. The client currently uses CWDM between two sites, and the >>> brocades >>> handle the SFP's fine. >>> >>> We popped them into the MX480's and link came up and down a few times >>> according to logs (though I could never catch it in an up state with show >>> commands), the green light came on and off a bunch, but link never came. >>> An >>> EX4500 at the other end, which was previously interfacing with the >>> brocade >>> fine, showed tons of link up/ down events in the logs, much more than the >>> MX showed. >>> >>> Is this a sign of an optic incompatibility on the MX side? There was >>> enough >>> signal for sure, and the brocades are able to operate with it so >>> obviously >>> it wouldn't be signal related. >>> >>> Any tips would be helpful. >>> >>> -- >>> Thanks, >>> Morgan >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> 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
Re: [j-nsp] Urgent advice needed...possible CWDM module conflict, can't keep link.
If the optics support DOM (Digital Optic Monitoring), what is the received signal power when you issue the following command ? show interface diagnostics optic ge-X/X/X ? Then compare it to the specs of the optic, maybe when you moved the optic and fiber you added some attenuation of the fiber and maybe you were already out of the specs and you were lucky it worked before. On my side I never had issues with non-juniper optics in Juniper equipments in general. And I would say, if it worked in a broke-ade, it should work in a Juniper. What I would do is to do a show interface diagnostics optic ge-X/X/X on both side : I'd calculate the attenuation between TX Site A and RX Site B and compare it to the dark fibre calculated attenuation + the mux/demux insertion loss + 1 dB per patchcord (0.5 per connector) I'd do the same with TX Site B and RX Site A to see if you have a physical fiber problem. If the optical levels are fine, it might be related to the SFPs. 2013/5/5 Morgan McLean > Hi all. > > I'm doing some work migrating from some brocade routers to a couple > MX480's. The client currently uses CWDM between two sites, and the brocades > handle the SFP's fine. > > We popped them into the MX480's and link came up and down a few times > according to logs (though I could never catch it in an up state with show > commands), the green light came on and off a bunch, but link never came. An > EX4500 at the other end, which was previously interfacing with the brocade > fine, showed tons of link up/ down events in the logs, much more than the > MX showed. > > Is this a sign of an optic incompatibility on the MX side? There was enough > signal for sure, and the brocades are able to operate with it so obviously > it wouldn't be signal related. > > Any tips would be helpful. > > -- > 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
[j-nsp] Urgent advice needed...possible CWDM module conflict, can't keep link.
Hi all. I'm doing some work migrating from some brocade routers to a couple MX480's. The client currently uses CWDM between two sites, and the brocades handle the SFP's fine. We popped them into the MX480's and link came up and down a few times according to logs (though I could never catch it in an up state with show commands), the green light came on and off a bunch, but link never came. An EX4500 at the other end, which was previously interfacing with the brocade fine, showed tons of link up/ down events in the logs, much more than the MX showed. Is this a sign of an optic incompatibility on the MX side? There was enough signal for sure, and the brocades are able to operate with it so obviously it wouldn't be signal related. Any tips would be helpful. -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
