Category Archives

3 Articles

Network

How to upgrade an IRF stack – incompatible firmware

Posted by Maarten Van Driessen on

When upgrading HP Comware switches that are part of an IRF stack, you want to use In Service Software Upgrade (ISSU). This allows you to do a rolling upgrade of the firmware while limiting the impact to just 1 switch in the stack.
ISSU will reboot 1 switch in the stack, wait for it to come back up and then moves on to the next switch.

Types of ISSU

There are 3 types of ISSU:

  • Compatible: This means 2 different software versions can co-exist in the same IRF stack. This is usually for smaller releases, in the same major release
  • Incompatible: Typically you will see this when moving between major releases. Only 1 version can exist in the IRF stack
  • Unknown

Upgrading incompatible firmware

Checking configuration

Before starting the upgrade, you have to check your configuration. Doing an incompatible upgrade means you will create a “split-brain” situation since only 1 version can exist in the same IRF stack.

To prevent this, you have to make sure MAD is configured. You can check this by running the command

This will give you an output like this, in this example MAD BFD is used.

Also, make sure your IRF stack is configured correctly and as desired by running the command

Uploading the image

After you verified that everything is configured correctly, it’s time to upload the image. You can do this using any number of methods. Once the image is uploaded to the master node, you need to copy it to all slave nodes. Increment the slot number if you have more than 2 switches in the stack.

copy new5500.bin slot2#flash:

Once the image is uploaded, you can check the compatibility

Starting the upgrade

It’s time to actually start upgrading. When the command is issued, the slave node will be loaded with the new firmware. The node will then reboot but will not join the IRF stack (remember, only one version can exist), this will create a split-brain situation that will be resolved by MAD. MAD leaves the IRF ports active but will shut down all outgoing interfaces. You might wonder why the IRF interfaces aren’t shut down, this is done to allow you to perform the switchover and continue the upgrade.

Once the slave node has rebooted, you can perform the switchover. This will reboot the current master node and perform the upgrade to the new firmware version. The command will also enable all external interfaces on the node that’s already been upgraded, the new master.

After the node has rebooted, the IRF stack will be fully operational.

If you want the IRF master to be the same as before the upgrade, you can reboot the current master.

 

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Network

Setting up IPSec VPN between Fortigate and Axsguard

Posted by Maarten Van Driessen on

If you’ve ever had the “pleasure” of building an IPSec tunnel between 2 endpoints from different vendors, you’ll know how smooth that usually goes. Today I was building a tunnel between a Fortigate 70D and an Axsguard Gatekeeper, as you can guess, things didn’t go as planned.

Fortigate

Let’s start by creating the tunnel on the Fortigate. Create a new tunnel and select the Custom VPN Tunnel template.

FG-tunnel1

 

Next, fill in all the phase 1 settings. In this example, I’m using 3DES and SHA1. While 3DES is still considered as secure, I would recommend against using it in production, mainly because of the speed. If you want to use the public IP address as the local ID, leave the field empty. Fortigate will automatically send its public IP as the local ID. Keep this in mind when you’re behind a NAT device.

FG-phase1

In the phase 2 settings, you can specify what addresses should be configured on the tunnel. You can choose between a subnet, IP range or a single IP address.

FG-phase2

 

You will still need to configure a route and firewall rules for VPN traffic.

Axsguard

The same principles apply to the configuration of the Axsguard.  One thing to pay attention to is the key lifetime, Fortinet uses seconds to express the lifetime on its devices. Axsguard, on the other hand, uses minutes for the lifetime.

Let’s go ahead and create a new tunnel on the Axsguard. Fill in the local parameters. If you can’t find the settings that correspond to the settings on the Fortigate, you can add them in the IPSec -IKE, and IPSec – ESP menus. Make sure to set the settings exactly the same as on the Fortigate.

Axsguard local parameters

 

Same goes for the remote parameters.

Axsguard remote parameters

 

The Axsguard will automatically create the required firewall rules to allow traffic to pass through the tunnel.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Network

Using VLANs on Fortigate 30D

Posted by Maarten Van Driessen on

While setting up a new Fortigate 30D for a client, I wanted to add a new VLAN for the guest Wi-Fi network. Usually, you just go into NetworkInterfaces and add a new Interface there.

On the 30D however, this option wasn’t there. After changing the device from switch mode to interface mode and back, I figured you can’t do it in the GUI. The only way to do it on a 30D is by using the CLI.

To add a new VLAN, go to the dashboard, open up the CLI and enter these commands:

After running these commands, you’ll also see the VLAN show up in the Network – Interfaces page.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin