Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Update i4800 to 13.1.0.1 Problems?

Hi,

I've tried to update one of our i4800 from 13.0 HF2 to the actual 13.1.0.1 (2 BIG-IP 2200 and some VE's made no problem), but I couldn't get the i4800 to work (after re-activating the license).

Sorry that I can't provide a Snapshot, but I had to go back quickly, and that made big problems too.

I got some messages about AOM (we don't use).

My question: are there any known problems with this hardware and this version?

Thanks

Karl

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Karl,

I have had issues like this before. Have a look at the following:

K00415052: AOM may stop responding during an upgrade on iSeries platforms

https://support.f5.com/csp/article/K00415052

Regards, Morten

0
Comments on this Answer
Comment made 11-Jan-2018 by kgaigl 110

Hello Morten,

thanks for the info, this might be the cause, my machine is running now, but it took about 40 minutes to complete the upgrade (without resetting AOM).

Maybe the Bug will be fixed in the next release.

regards Karl

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

https://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-13-1-0-1.html

"693910-4 3-Major Traffic Interruption for MAC Addresses Learned on Interfaces that Enter Blocked STP State (2000/4000/i2800/i4800 series)"

This only known issue I found for your version and hardware, in the release notes. May not match your problem, but you ask generically about known issues.

0
Comments on this Answer
Comment made 02-Jan-2018 by boneyard 5627

which seems to effect the 2200 also which supposedly went fine.

but Leonardo is right, quite tricky to trouble shoot this with such limited info. it might also just have been the environment, if going back also caused issues. although i understand the situation take a little bit more time to collect the logs and such. most ssh clients will let you log all output, that could be helpful.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Today I've tried it again:

first I upgraded the backup-device, it worked !?

then the primary: after 25 minutes, the Browser-Connection was lost, with the CLI said:

[root@localhost:FW Update Do Not Interrupt - Checking LCD:] config #

after a while:

[root@localhost:FW Update Do Not Interrupt - Checking LCD:] config # 2018 Jan 11                                                              09:15:44 ldb-ara27-rz-00 load_config_files: "/usr/bin/tmsh -n -g load sys confi                                                             g partitions all " - failed. -- Loading schema version: 13.0.0 Loading schema ve                                                             rsion: 13.1.0.1 01070151:3: Rule [/Common/MI-HEADER] error: /Common/MI-HEADER:44                                                             : error: [ltm_rule_L7 feature not licensed][HTTP::header insert X-Forwarded-For                                                              [IP::client_addr]] /Common/MI-HEADER:41: error: [ltm_rule_L7 feature not license                                                             d][HTTP::header replace X-MobileIron-Device-IP-Port "[IP::client_addr]:[TCP::cli                                                             ent_port]"] /Common/MI-HEADER:38: error: [ltm_rule_L7 feature not licensed][HTTP                                                             ::header replace X-MobileIron-Client-Cert-PEM "[lindex $values 1]"] /Common/MI-H                                                             EADER:35: error: [ltm_rule_L7 feature not licensed][HTTP::header replace X-Mobil                                                             eIron-Cert-FingerPrint-MD5 [lindex $values 0]] /Common/MI-HEADER:19: error: [ltm                                                             _rule_L7 feature not licensed][when HTTP_REQUEST {   # if no client cert was pro                                                             vided:   if { [SSL::cert count] < 1 } {     # log local0. "HTTP_REQUEST : cert c                                                             ount=[SSL::cert count]"     SSL::authenticate once     SSL::authenticate depth 9                                                                  SSL::cert mode request     SSL::renegotiate   # if client cert was provided                                                             :   } else {     # set variable &#8220;values&#8221; with the list of 2 stored                                                               Unexpected Error: Loading configuration process failed.

[root@localhost:FW Update Do Not Interrupt - Checking LCD:] config #

now it seems to work

0