Anyway, the error message given by the OpenSSH client was:

Unable to negotiate with port 22: no matching cipher found. Their offer: des,3des-cbc

These ProCurves are pretty old and their SSH support is rather limited (1024 bit keys for example), so it’s not hugely surprising that their supported ciphers are also old and crappy.
Luckily, with OpenSSH you can specify the cipher(s) that you want to use on the command line when you’re connecting:

ssh -c 3des-cbc

This fixed the issue and lets me connect, but isn’t particularly convenient. However, you can also specify this in your ~/.ssh/config file so that it is applied automatically:

Host <blah>
Ciphers 3des-cbc

Just enter one or more hosts to match against (separated by spaces) and OpenSSH will automatically apply the specified options when connecting to any of them.

The post ProCurve SSH – no matching cipher found first appeared on Spheron1.

• Version 9.00 released 23/06/2016 (http://blog.configserver.com/?p=2716)
• Version 9.01 released 23/06/2016 (http://blog.configserver.com/?p=2718)
• Version 9.02 released 23/06/2016 (http://blog.configserver.com/?p=2720)
• Version 9.03 released 24/06/2016 (http://blog.configserver.com/?p=2722)
• Version 9.04 released 24/06/2016 (http://blog.configserver.com/?p=2724)
• Version 9.05 released 25/06/2016 (http://blog.configserver.com/?p=2726)
• Version 9.06 released 25/06/2016 (http://blog.configserver.com/?p=2728)

7 issues fixed in 6 bugfix releases (9.01 to 9.06) in 2 days! It’s a good job that the automatic update feature works properly…

The post CSF bugs and updates first appeared on Spheron1.

This seems to be nothing more than a thinly veiled attack casting FUD (Fear, Uncertainty and Doubt) at a competitor – a knee-jerk reaction to a threat to their business. It actually reads pretty similarly to their blog post when Juniper originally announced the OCX range (https://cumulusnetworks.com/blog/juniper/). They’ve probably attacked other vendors in a similar manner.

For example, just by going to the main QFX5200 page on the Juniper web site (http://www.juniper.net/us/en/products-services/switching/qfx-series/qfx5200/), I find:

Open access to the standard Junos Linux kernel, enabled by the disaggregated version of the Junos software, allows users to install third-party Linux RPM packages and create guest containers and VMs with central resource management and programmable APIs.

Yes that still needs a little more detail, but it answers at least some of the questions and all it took was a couple of clicks! Imagine what you could find out by actually speaking to someone familiar with the details…

I have a few questions of my own for Cumulus Networks;

1. Did Cumulus Networks actually attempt to find out the answers to any of these points yourselves? If so, were you unable to find the details, or did you just not like what you found so decided to feign ignorance?
2. Will Cumulus Networks put their money where their mouth is and make sure that Cumulus Linux runs on the Juniper QFX5200 series of switches (assuming that Juniper are willing to co-operate)?
3. Does Cumulus Linux currently run on any switches powered by the Broadcom StrataXGS Tomahawk chipset? It doesn’t seem to be listed anywhere on the Cumulus Linux HCL that you so helpfully linked to from your blog post.
4. Does Cumulus Linux currently run on any switches which support 25G, 50G or 100G Ethernet ports? These also seem to be conspicuously absent from the Cumulus Linux HCL.
5. When will Cumulus Networks offer a fully featured MPLS implementation on their Cumulus Linux control plane?

The post Cumulus attacks on Juniper (again) first appeared on Spheron1.

Upgrading from Junos OS Release 10.4R2 or Earlier

To upgrade to Junos OS Release 12.3 from Junos OS Release 10.4R2 or earlier, first upgrade to Junos OS Release 11.4 by following the instructions in the Junos OS Release 11.4 release notes. See Upgrading from Junos OS Release 10.4R2 or Earlier or Upgrading from Junos OS Release 10.4R3 or Later in the Junos OS 11.4 Release Notes .

Unfortunately, Juniper don’t list any Junos releases older than 12.3R1 for the EX4200 (and possibly other EX series) on their download site.

After poking around the Juniper support site for a bit, I found technical bulletin TSB16151 (https://kb.juniper.net/InfoCenter/index?page=content&id=TSB16151), which contains downloads for Junos 11.4R8-S1 on EX2200, EX3200, EX3300, EX4200, EX4500, EX6200, EX8200 and XRE-200.

With this and the jloader files from technical bulletin TSB15524 (http://kb.juniper.net/InfoCenter/index?page=content&id=TSB15524), I was able to complete the upgrade successfully.

The post Upgrading to Junos 12.3 from before 10.4R2 on Juniper EX first appeared on Spheron1.

Not only does installing your own RAM save you a shedload of money compared to the Juniper equivalent part (JXX50-MEM-512M-S), but you can also exceed the “supported” 2GB maximum 4x512MB configuration, which provides additional memory to the control plane. The four memory slots present on a J6350 can take a 1GB DIMM each, however thanks to a 32bit architecture and mapping of the PCI bus into the same address space, you can only actually use 3.5GB of that 4GB.

The J-series routers are picky about what RAM they use however, so I like to stick to Crucial sticks; partly as that’s what Juniper use but mostly because I use Crucial elsewhere for their great customer service and a genuinely quality product. If you want to stick with a 2GB maximum then you can use Crucial part number CT2KIT6464Z40B, which provides 2x512MB sticks. Alternatively, Crucial part number CT2KIT12864Z40B provides 2x1GB sticks, allowing you to max the chassis out at 4GB across all four slots.

Once you’ve got all 4GB of memory installed in the chasis, boot the router up and from the JUNOS operational mode CLI issue the command “show chassis routing-engine” – you should see a total of 3584MB of memory split between 3008MB of control plane memory and 576MB of data plane memory. If you only opted for 2GB of memory then the 2048MB total will be split between 1472MB of control plane memory and 576MB of data plane memory.

Remember, you replace the RAM in your routers at your own risk and doing so will likely void your warranty as well as rending your system unspported by JTAC.

The post 4GB of RAM on a Juniper J-Series router (J6350) first appeared on Spheron1.

If this doesn’t fix the problem, then I’ve had much more success with running the update process from command line, although this does require you to have the new FortiOS image on a TFTP server so that the Fortinet device can download it. Once you have issued the command, the device will download the new image and reboot.

The exact command varies depending on the deice type, for example FortiGate devices have the option of FTP or TFTP downloads, whilst FortiMail devices can only download new FortiOS images via TFTP.

For a FortiGate device:

exec restore image tftp

For a FortiManager device running FortiOS 3.x:

exec restore image

For a FortiManager device running FortiOS 4.x:

exec restore image tftp

For a FortiAnalyser device running FortiOS 3.x:

exec restore image

For a FortiAnalyser device running FortiOS 4.x:

exec restore image tftp

For a FortiMail device running FortiOS 3.x:

exec restore image

For a FortiMail device running FortiOS 4.x:

exec restore image tftp

Depending on the device and FortiOS version, you may have other file transfer options such as FTP available to you. Devices registered with a FortiManager can also update their FortiOS image by downloading a new one from the FortiManager unit.

If you are still having problems getting the new FortiOS firmware image onto your Fortinet device, then you can also download a FortiOS image via TFTP from within the Fortinet bootloader/BIOS using the serial console.

Connect a serial console to your device and reboot it, then interrupt the boot sequence when prompted. In the menu, select the option to download a new FortiOS firmware image and provide the file name, server IP address and local IP address.

Right at the start of the bot process, you should see a message along the line of:

Press any key to display configuration menu…

Once you have pressed a key, then the following configuration menu should appear:

[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B]: Boot with backup firmware and set as default.
[I]: Configuration and information.
[Q]: Quit menu and continue to boot with default firmware.
[H]: Display this list of options.

Enter G,F,B,I,Q,or H:

At the configuration menu, type “G” and press enter and you will be asked to enter the details needed to TFTP a new image to your Fortinet device:

Enter TFTP server address [192.168.1.168]:
Enter local address [192.168.1.188]:
Enter firmware image file name [image.out]:

You will need to be on the same subnet as the TFTP server in order to do this.

The post Fortinet FortiOS firmware upgrade – Upload file is too big or invalid first appeared on Spheron1.

It would seem that in RouterOS 4.x at least, the router is pushing details of all learned routes to any Winbox clients connected and slowing itself to a crawl in the process. I haven’t had a chance to verify if this affects all versions of RouterOS 4.x yet or test it on RouterOS 5.x

The post RouterOS slow learning BGP routes with Winbox open first appeared on Spheron1.

In other words, even with the appropriate rules configured in the firewall policy to allow your traffic to pass through the FortiGate between the interface that it is received on and the interface which that SSL VPN traffic is destined for, the FortiGate unit doesn’t respond.

I have been able to verify that this bug/feature is present in the latest build of FortiOS 3.0, but haven’t been able to test with any of the FortiOS 4.0 releases yet.

In my case, this was a problem because the WAN interface has a private IP address on it with a block of public IP addresses routed to the unit and in use on the LAN interface. In the end I worked around this by routing a single additional public address to the unit and configuring it as a secondary address on the WAN interface with a /32 subnet mask. The SSL VPN could then be accessed from this public IP address.

The post Fortinet SSL VPN interface limitations first appeared on Spheron1.

To work around this, you can either disable the insertion of Option-82 on the switch performing the DHCP snooping with:

no ip dhcp snooping information option

Or alternatively you can configure the Cisco device acting as the DHCP relay to trust DHCP packets with giaddr set to 0.0.0.0. This can either be done on all interfaces with the global command

ip dhcp relay information trust-all

Or on a per-interface basis with

ip dhcp relay information trusted

Remember, if you are applying the trust to a specific interface then it has to be the layer 3 interface with the IP helper on it (such as an SVI) and not the layer 2 interface that the DHCP packets are received on.

The post Cisco DHCP snooping with a Cisco DHCP relay (ip helper) and DHCP option-82 first appeared on Spheron1.

crypto key generate ssh
ip ssh
ip ssh version 2
ip ssh filetransfer

This generates the keys that SSH requires, forces SSH to use the newer version two of the protocol and enables SCP/SFTP support for copying files to and from the flash.

As soon as you enable SSH filetransfer (basically SCP/SFTP) support then TFTP is disabled, but you have to disable telnet access manually in configuration mode with:

no telnet-server

The post SSH on a HP ProCurve first appeared on Spheron1.