Problem with upgrade to 10.1

Can you edit the bigip.conf and change the moodle_http monitor to use a specific destination port. You can then reload the config using 'b load' and edit the config further using the GUI.

 

 

Aaron

Thanks Aaron.

 

 

The monitors were configured to use * and the nodes were set to take their monitoring method from the pool, so i guess that's what caused this.

 

 

I'm at a bit of a loss as to why those monitors were working for one or two years, I didn't think they'd load at all. I'll have to configure new monitors with specific ports.

 

 

We've had some serious issues from this. All our sites suffered intermittent loss of service, which we narrowed down to servers at one data centre. Although I'd forced the upgraded F5 offline and disabled its interfaces the active F5 was still trying to contact it every second. It wasn't until I shut down the upgraded F5 that the active box knew it was alone and started doing all of the work.

 

 

I imagine I'll now have to isolate the upgraded F5 from the network, create the new monitors, then shut down the active box to test it out when I can get some more downtime.

Posted By ringoseagull on 08/10/2010 03:58 AM

 

Thanks Aaron.

 

 

The monitors were configured to use * and the nodes were set to take their monitoring method from the pool, so i guess that's what caused this.

 

 

I'm at a bit of a loss as to why those monitors were working for one or two years, I didn't think they'd load at all. I'll have to configure new monitors with specific ports.

 

 

We've had some serious issues from this. All our sites suffered intermittent loss of service, which we narrowed down to servers at one data centre. Although I'd forced the upgraded F5 offline and disabled its interfaces the active F5 was still trying to contact it every second. It wasn't until I shut down the upgraded F5 that the active box knew it was alone and started doing all of the work.

 

 

I imagine I'll now have to isolate the upgraded F5 from the network, create the new monitors, then shut down the active box to test it out when I can get some more downtime.

 

 

Shall I assume you upgraded from 9.x to 10.1 and are using network failover? The transport protocol changed a bit so both units would think they are active/active. As far as your monitor situation goes, that never should have worked. You're telling your monitor to check the port on which your pool member is listening. In this case, your pool member is listening on all ports so your monitor doesn't know what to check.

Posted By Chris Miller on 08/10/2010 06:08 AM

 

 

Shall I assume you upgraded from 9.x to 10.1 and are using network failover? The transport protocol changed a bit so both units would think they are active/active. As far as your monitor situation goes, that never should have worked. You're telling your monitor to check the port on which your pool member is listening. In this case, your pool member is listening on all ports so your monitor doesn't know what to check.

 

That's right, I was expecting them both to go active and to have to separate them at network level. it's the monitoring issue which is odd. I hadn't looked at these before, all done long before I joined the organisation.

 

 

Looking at the active unit still running 9.4.7 I can see that the default http monitor is set to * All Ports.

 

The pool members are configured to use the same method as the pool.

 

 

So we're running this on live for most of our virtual servers even though the F5 shouldn't have accepted it. How is this possible?

 

 

 

 

 

I imagine different versions apply different logic during the config load portion of boot. I've had iRules on 9.x that used incorrect syntax and blocked a config load on 10.x. In reality, your monitor shouldn't really be working. If you change your HTTP monitor to *all ports for a pool member that's listening on all ports, how on earth will the monitor know against which port it should send the request?