Connecting the world…

not

AeroHive HMOL Redirector issue

When using the HMOL solution from AeroHive, an access-point will discover the correct HiveManager by connecting to staging.aerohive.com. Within the HiveManager management interface you can see which access-points have been redirected to your HMOL. This can be down by checking the Device Access Control List within the Redirector configuration.

Sometimes you will notice that not all the serial numbers are listed on this page. When this is the issue the new access-points will not connect to your HiveManager. You can try to enter the serial numbers yourself by using a csv file or enter the serial number separately. Most times I receive an error message for multiple serial numbers, like shown below.

Same serial number “serial number” already exists. Cannot override the catagory information.

When you receive this error message, you have to redirect the access-point yourself. This can be down very easily. Connect via SSH to an access-point, which is redirected to your HiveManager. Enter the following command and look for the following two lines:

AH-001#show config current
!
capwap client server name <AeroHive HMOL hostname>
capwap client vhm-name <Hive-name>

Now login to the access-point, which aren’t redirected to your HiveManager. You have to retrieve the IP address settings of these access-points and just login with the default username (admin) and password (aerohive). Just paste the 2 commands in the config.

The only thing you need to do now is, sit back and enjoy your coffee.

New Theme

As I already announced on Twitter, I have updated my blog theme. I am very curious about your comments…… should this theme stay or should I revert back to the old one? What would you change at the current theme?

Updated on December 1ste 2009

Yesterday I have been playing with my new theme and eventually I ended up deleting all previous comments…. I also noticed that the WordPress Blog Stats didn’t work anymore, but luckily I found the solution for this. My new theme didn’t contain the wp_footer() function. The function is often used by plugins to insert PHP codes after everything else on your page. According to WordPress.org theme development documentation, you should place the wp_footer() function in the footer, which would be in the footer.php file.

ASDM Error: Unconnected socket not implemented

When you receive the following error, while starting ASDM:

ASDM Error: Unconnected socket not implemented

You should look at your Java versions. When you are using Java 6 Update 10 or higher and ASDM 6.1.5 or lower, you will receive this error. There are two workarounds for this problem:

  1. Downgrade Java to Java 6 Update 7 or lower;
  2. Upgrade ASDM software;

Cisco released an Interim Release (6.1.5.57), which resolves the problem above.

PIX Failover not working

Today I received the question why a PIX failover configuration wasn’t working. The customer accidentally disconnected the power cable from the primary PIX firewall. The secondary PIX firewall became the active one, but multiple DMZ segments weren’t working anymore. After rebooting the PIX firewall and making that the primary one again, the DMZ segments were reachable again.

I started looking at the failover state of the firewall. Entering the commando show failover on the primary PIX resulted in the following output:

This host: Primary – Active
Active time: 5430735 (sec)
Interface outside (1.1.1.1): Normal
Interface inside (2.2.2.1): Normal
Interface DMZ01 (3.3.3.1): Normal
Interface DMZ02 (4.4.4.1): Normal (Waiting)
Interface DMZ03 (5.5.5.1): Normal (Waiting)
Other host: Secondary – Standby Ready
Active time: 5235 (sec)
Interface outside (1.1.1.2): Normal
Interface inside (2.2.2.2): Normal
Interface DMZ01 (3.3.3.2): Normal
Interface DMZ02 (4.4.4.2): Normal (Waiting)
Interface DMZ03 (5.5.5.2): Normal (Waiting)

Interface DMZ02 and DMZ03 were the problem interfaces.

After doing some simple ping test, I noticed the problem interfaces couldn’t ping each other. Looking at the output above the interfaces are in Normal (Waiting) state. Searching the internet resulted in the following:

Failover does not start to monitor the network interfaces until it has heard the second “hello” packet from the other unit on that interface. This takes about 30 seconds. If the unit is attached to a network switch that runs Spanning Tree Protocol (STP), this takes twice the “forward delay” time configured in the switch (typically configured as 15 seconds), plus this 30 second delay. This is because at PIX bootup and immediately following a failover event, the network switch detects a temporary bridge loop. Upon detection of this loop, it stops forwarding packets on these interfaces for the “forward delay” time. It then enters the “listen” mode for an additional “forward delay” time, during which time the switch listens for bridge loops but not forwarding traffic (and thus not forwarding failover “hello” packets). After twice the forward delay time (30 seconds), traffic resumes flowing. Each PIX remains in “waiting” mode until it hears 30 seconds worth of “hello” packets from the other unit. During the time the PIX is passing traffic, it does not fail the other unit based on not hearing the “hello” packets. All other failover monitoring still occurs (that is, Power, Interface Loss of Link, and Failover Cable “hello”).
Source

Here they are talking about the STP configuration. I couldn’t imagine that the problem is lying in the STP configuration. I started tracking the mac-address on the switches to check the physical patching.

The problem was found directly. The patching of the secondary PIX wasn’t correct. The customer had swapped the two interfaces resulting in patching them in the wrong VLAN. After swapping the patches the failover state functions normally, looking at the output below:

This host: Primary – Active
Active time: 5430735 (sec)
Interface outside (1.1.1.1): Normal
Interface inside (2.2.2.1): Normal
Interface DMZ01 (3.3.3.1): Normal
Interface DMZ02 (4.4.4.1): Normal
Interface DMZ03 (5.5.5.1): Normal
Other host: Secondary – Standby Ready
Active time: 5235 (sec)
Interface outside (1.1.1.2): Normal
Interface inside (2.2.2.2): Normal
Interface DMZ01 (3.3.3.2): Normal
Interface DMZ02 (4.4.4.2): Normal
Interface DMZ03 (5.5.5.2): Normal

This proves again how import correct patching is!!!!!