2009年7月31日 星期五
2009.7.31 DLG.exe的用途
-------------------------------------------------------------------------------------------------
The Digital Line Detection program monitors the modem to make sure that the phone line is a standard analog phone line. Plugging into a digital phone line could cause damage to the modem.
The purpose of this application is to provide a warning before damage occurs.
簡單的說,就是保護你的Thinkpad的Modem,在被插入數位電話線時會提出警告以避免Modem損毀(可能數位電話線的電壓脈衝較高容易造成Modem損傷,詳細我也不清楚是否真的如此)
-------------------------------------------------------------------------------------------------
數位電話指的應該像是ISDN這類的線路,因為他的電壓較高,誤接確實會導致設備燒毀。
敝人的USB轉RS232轉接線就因為誤接ISDN孔已經燒掉兩條.....
2009.7.31 網路除錯(Troubleshooting)精準度的提升
每當客戶在報修時, 從工程師收到客戶的報修陳述後, 無論客戶陳述的事情有否錯誤, 一直到處理完畢為止, 這中間所經歷過的過程是否有效率?
我們從來就沒有試著讓不同的工程師去處理相同的問題過, 除非是在Lab或考場上, 給不同的工程師一樣的環境一樣的條件一樣的問題. 所以很難知道工程師在除錯時的效率如何?
除錯要精準,我認為要involve到:
- 客戶網路架構的了解
- 設備功能的了解
- 網路理論的了解
- 工作經驗
當上述的要素都備齊時, 除錯的精準度就會提高, 除錯時間就縮短, 效率就會up
當沒有備齊時, 往往都是在try error, 然後一直try到問題解決(但有某些少數的例子,還非得是用try error方式來解決)
2009.7.31 蚊蟲咬一口 發炎差點截肢
蚊蟲咬一口 發炎差點截肢
2009/07/31 04:09
記者歐素美/台中報導
一名一歲多女童因被蚊蟲叮咬引發蜂窩性組織炎,差點截肢,所幸緊急送醫治療,才挽回右腿。台中童綜合醫院小兒科醫師高佳慧表示,入夏後,已接獲10多起幼兒被蚊蟲叮咬,引發蜂窩性組織炎案例,提醒家長防範。
夏天蚊蟲多,許多家長擔心,幼兒被叮咬而感染日本腦炎或登革熱,但醫師表示,幼兒抵抗力較弱,被蚊蟲叮咬後搔抓,即容易引發細菌感染,造成蜂窩性組織炎,甚至併發壞死性筋膜炎或敗血症,嚴重時,可能導致休克死亡。
一 名1歲大的女童日前因高燒39度不退,家長誤以為感冒,至診所治療多日不見好轉,發現女童的右下肢被蚊子叮咬的紅腫愈來愈大,趕緊轉送童綜合醫院小兒感染 科,診斷為嚴重的蜂窩性組織炎,經住院及手術治療,清除壞死化膿組織,抑制細菌蔓延,並施以抗生素治療,才免於截肢,目前已出院。
高佳慧說,4月至今,該院已接獲10多起幼童因蚊蟲叮咬引發蜂窩性組織炎案例,發生部位以手、腳最多,眼睛發生蜂窩性組織炎的患者則集中在5歲以下,提醒家長不要小看蚊蟲叮咬造成的傷害。
高佳慧指出,人的皮膚分為表皮、真皮及皮下組織三層,一般皮膚感染大多侷限在表皮及真皮層,若往下蔓延到皮下組織即稱為蜂窩性組織炎,蜂窩性組織炎好發於小腿及足部,因組織鬆軟,細菌容易沿著血管及淋巴竄行,以致感染快速擴散。
爐主
民國九十八年協助製作了一份信徒名單,按這裏下載
其來有自....是因為...忘記了...
以下轉載自爐主頭家大福頭
爐主頭家大福頭
爐主、副爐、頭家,簡單地說,就是神明所欽點的年度信徒代表。
爐主、副爐、頭家選拔自有參與分擔祭祀費用(俗稱丁口錢)的廟宇信徒,神明會也有這樣的制度,但不是每一間廟都有這種作法,爐主、副爐、頭家最重要的責任就是廟宇該年的祭典籌辦與清潔管理。
因為爐主、副爐、頭家要挨家挨戶收取緣金、丁口錢作為祭典開銷,在人際疏離、缺乏公眾事務參與感的現今功利社會,變成吃力不討好的事,有時不禁讓人怨嘆:信教的(基督宗教徒)有的出錢還比不信教的阿殺力。
民間對於爐主、副爐、頭家這些神明欽點的服務人員又別稱「福頭」,認為他們是「受到神明眷顧關愛,即將消災解厄、飛黃騰達的幸運兒」,因為這群福頭在擔任爐主、副爐、頭家當年為神明揮汗效勞的種種,神明都有看在眼裡、記到心裡、上稟 金闕玉皇大天尊,自然這群弟子們有難神明會暗中相助、財祿遇阻會幫忙疏通,同樣道理,這群弟子如果為惡也會受到處分。
有了管理委員會之類的信徒組織後,爐主、副爐、頭家的角色在各廟更顯不同,大體上民間都還是認為「神選的」要比「人選的」更接近神明,祭典時由這群人代表全體信徒祈祝更能上達天聽。
管理委員會等信徒「社團法人」組織,是源自於台灣光復後國民政府戒嚴時期所雷厲風行的宗教箝制政策,運用的是民國初期還在大陸時所制訂的寺廟監督條例、寺 廟登記規則等法律來管理台灣民間信仰,要求廟宇設置管理委員會或管理人,著實將「神明的廟、眾人效勞」變成「法律保障主權在少數人的廟」,信徒登記的制度 更將信徒區分成「合法有權參與的」與「非法無權參與的」兩種,傳統宮廟事務運作的「眾人都有參與效勞的責任」變成「法律保障少數人金錢主權在握」。這種以 人為主的制度當然就會面臨永恆的「人性挑戰」,也就會有因人事派系問題造成廟務中輟,甚至「合法」主事者敵不過私欲誘惑將廟宇「合法」出售改建為查某間、 賭窟、酒店,大眾奉獻給神明的香油錢被少數人假借廟宇公務所需圖利自己派系樁腳的耳目聲色之愉悅享受、甚至全數中飽私囊、據為己有等等流弊,形成法律保障 的社會不公平、扭曲了民間傳統信仰。
無論法律怎麼定、社會怎麼變,無庸置疑的,到頭來只有真正為神明、公益效勞奉獻的人才會是受到天地神明眷顧的。
2009年7月30日 星期四
Using CAR During DOS Attacks
Using CAR During DOS Attacks
Downloads |
Document ID: 12764
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Rate Limit ICMP/Smurf
Rate Limit TCP SYN Packets
11.1(X)CC
12.0(X)[S/T/M]
CAR Frequently Asked Questions
How to Identify the Values to Use for the CAR Rules to Rate Limit SYN Packets?
How Do I Know if I Restrict too Many SYN Packets?
Can I Enable CAR on a Gigabit Switch Router (GSR)?
Can I Enable Distributed CAR (dCAR) on a Cisco 7500?
Can I Enable CAR on a Cisco 7200?
Other Features and Alternatives
IP Receive ACL
IP Source Tracker
NetPro Discussion Forums - Featured Conversations
Related Information
F5 GTM憑證過期,導致設定(Sync Group)無法同步
F5 Support有文章(ex:SOL7754, SOL6353)講述如何將憑證展期至2,5,10年等
v10開始可以在GUI configuration utility下就能展延. 這是很奇怪的理論, 這種功能竟然不在舊版開放.
以下是處理憑證過期,導致設定無法同步的步驟:
1.兩地各自產生self憑證(此步驟只有在第一次要執行, 以後縱使是憑證過期也不用執行)
2.兩地交換self憑證. 交換後Trusted Device Certificates內會有對方憑證
交換憑證方式有兩種:使用GUI交換, 使用bigip_add交換
使用bigip_add指令, 分別要執行一次自己,執行一次對方的
交換後, 設備要重開機 or 重新啟動httpd及tomcat4(bigstart restart httpd tomcat4)
3.兩地執行iqdump檢查
4.檢查設定後是否同步
Wide IPs設定, 並檢查
Zone Runner設定, 並檢查. 檢查Zone or A record是否有同步
(如果Zone Runner設定項目內無法同步, 則重新啟動zrd (bigstart restart zrd)
5.檢查以上項目運作過程 tail /var/log/gtm
6.往後憑證過期後, 只要執行Device Certificate下的renew, 然後再重複步驟2~4即可.
2009年7月29日 星期三
2009.7.29 Ask F5 - Added and updated documents from 7/19 through 7/25
*Helping F5 Support troubleshoot technical issues*
Refer to the following solution for information about the files you can provide to F5 Support in order to help F5 support troubleshoot technical issues.
SOL2633: Instructions for submitting a support case to F5 Networks https://support.f5.com/kb/en-us/solutions/public/2000/600/sol2633.html
*RSS feeds on Ask F5*
You can receive Ask F5 RSS feeds to stay informed about new documents pertaining to your products. You can configure feeds for specific products, product versions and/or document sets. You can also aggregate multiple feeds in your RSS Reader to display one unified list of all selected documents.
For more information, including instructions to sign up for Ask F5 RSS feeds, refer to:
https://support.f5.com/kb/en-us/pages/rssfaq.html
*Added and updated documents from 7/19 through 7/25*
BIG-IP - New
SOL10339: Auditing a BIG-IP system for time changes https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10339.html
SOL10328: Forcing a file system check on the next system reboot https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10328.html
SOL10316: The pv_ntlm_auth cookie does not include a domain attribute https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10316.html
SOL10315: The BIG-IP WebAccelerator reports incorrect non-cacheable response code https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10315.html
SOL10311: The performance graphs no longer display data after 497 day Linux uptime wraparound https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10311.html
SOL10306: BIG-IP ASM Violation: Illegal Query String or POST Data https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10306.html
SOL10305: The switchboot utility returns an error on VIPRION version 10.x systems https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10305.html
SOL10303: Converting PKCS certificates for use in WebAccelerator https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10303.html
SOL10302: Configuring the BIG-IP WebAccelerator to recognize RealMedia files https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10302.html
SOL10300: Attack signature event thresholds do not function https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10300.html
SOL10289: Reinstalling BIG-IP LTM version 9.6.1 software on the VIPRION platform https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10289.html
SOL10285: The NTLMconnpool cookie does not include a domain attribute https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10285.html
SOL10239: Unsolicited management traffic may not use the intended management address or management routes https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10239.html
BIG-IP - Updated
SOL10167: Overview of the ClientSSL profile https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10167.html
SOL10156: Licensing BIG-IP GTM on one member of a redundant pair https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10156.html
SOL10061: The HTTP/1.0 Requests HTTP profile option is not honored when serving a cached response https://support.f5.com/kb/en-us/solutions/public/10000/000/sol10061.html
SOL10035: Issuing a sys-reset when remote authentication is configured will prevent logging into the system after a reboot https://support.f5.com/kb/en-us/solutions/public/10000/000/sol10035.html
SOL9953: The BIG-IP ASM does not validate XML schema files uploaded to the XML profile https://support.f5.com/kb/en-us/solutions/public/9000/900/sol9953.html
SOL9856: The BIG-IP system does not support time synchronization using SNTP https://support.f5.com/kb/en-us/solutions/public/9000/800/sol9856.html
SOL9842: The BIG-IP system does not properly fragment egress packets when using a FastL4 profile https://support.f5.com/kb/en-us/solutions/public/9000/800/sol9842.html
SOL9755: The Policy Builder does not support some language encodings https://support.f5.com/kb/en-us/solutions/public/9000/700/sol9755.html
SOL9597: Large packet filter names may cause undesired behavior https://support.f5.com/kb/en-us/solutions/public/9000/500/sol9597.html
SOL9502: BIG-IP hotfix matrix
https://support.f5.com/kb/en-us/solutions/public/9000/500/sol9502.html
SOL9477: Requests with an HTTP header size smaller than the maximum allowed in the http-acceleration profile may still fail https://support.f5.com/kb/en-us/solutions/public/9000/400/sol9477.html
SOL9476: The F5 Networks hardware / software compatibility matrix https://support.f5.com/kb/en-us/solutions/public/9000/400/sol9476.html
SOL9384: The sys-reset utility does not correctly process filenames with spaces https://support.f5.com/kb/en-us/solutions/public/9000/300/sol9384.html
SOL9279: BIG-IP automatically translates addresses between IPv4 and IPv6 when necessary https://support.f5.com/kb/en-us/solutions/public/9000/200/sol9279.html
SOL9123: Recommended practices for deploying F5 Networks devices remotely https://support.f5.com/kb/en-us/solutions/public/9000/100/sol9123.html
SOL9118: Overview of the sys-icheck utility https://support.f5.com/kb/en-us/solutions/public/9000/100/sol9118.html
SOL9076: Network failover traffic fails after the TM.PreserveClientPort BigDB key is set to disable https://support.f5.com/kb/en-us/solutions/public/9000/000/sol9076.html
SOL9057: Overview of the BIG-IP LTM network failover protocol https://support.f5.com/kb/en-us/solutions/public/9000/000/sol9057.html
SOL8849: Configuring a virtual server to use the same IP address as a self IP https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8849.html
SOL8835: The BIG-IP redundant pair SCCP firmware requirements https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8835.html
SOL8834: Determining whether the Request Logs, Forensics, or Traffic Learning entries have been cleared https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8834.html
SOL8826: The BIG-IP GTM does not immediately mark down dependent virtual servers https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8826.html
SOL8805: The BIG-IP LTM supports SOAP version 1.1 EAV monitors https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8805.html
SOL8665: BIG-IP redundant pair hardware and software parity requirements https://support.f5.com/kb/en-us/solutions/public/8000/600/sol8665.html
SOL8442: Configuring the BIG-IP system to use an NTP server from the command line https://support.f5.com/kb/en-us/solutions/public/8000/400/sol8442.html
SOL8304: Requests will not update sensitive parameters with metacharacters https://support.f5.com/kb/en-us/solutions/public/8000/300/sol8304.html
SOL8266: BIG-IP ASM Violation: Illegal pattern found in XML data https://support.f5.com/kb/en-us/solutions/public/8000/200/sol8266.html
SOL8217: Updating the BIG-IP ASM attack signatures https://support.f5.com/kb/en-us/solutions/public/8000/200/sol8217.html
SOL7964: Persistence may fail for subsequent requests on Keep-Alive connections https://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html
SOL7741: Associating virtual servers with links https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7741.html
SOL7718: The BIG-IP prohibits configuring the failover IP address on the same network as the management port https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7718.html
SOL7679: Setting the chunking method to rechunk in the HTTP profile causes the BIG-IP LTM to ignore the minimum content-length for compression https://support.f5.com/kb/en-us/solutions/public/7000/600/sol7679.html
SOL7550: Resetting the BIG-IP system configuration to the factory default settings using the sys-reset command https://support.f5.com/kb/en-us/solutions/public/7000/500/sol7550.html
SOL7115: Managing log files on the BIG-IP system https://support.f5.com/kb/en-us/solutions/public/7000/100/sol7115.html
SOL7036: The Linux uptime counter wraps after 497 days https://support.f5.com/kb/en-us/solutions/public/7000/000/sol7036.html
SOL5396: Overview of the client SSL profile timeout settings https://support.f5.com/kb/en-us/solutions/public/5000/300/sol5396.html
SOL4812: Interactive traffic, such as Telnet and SSH, may be slower when passed through BIG-IP https://support.f5.com/kb/en-us/solutions/public/4000/800/sol4812.html
SOL4039: Overview of iQuery communication between BIG-IP / 3-DNS version 4.x and BIG-IP LTM / GTM https://support.f5.com/kb/en-us/solutions/public/4000/000/sol4039.html
SOL3830: Disabling remote LDAP authentication and enable local authentication https://support.f5.com/kb/en-us/solutions/public/3000/800/sol3830.html
SOL3800: Support for Stream Control Transmission Protocol (SCTP) https://support.f5.com/kb/en-us/solutions/public/3000/800/sol3800.html
SOL3669: Overview of management interface routing https://support.f5.com/kb/en-us/solutions/public/3000/600/sol3669.html
SOL3621: Reinstalling BIG-IP LTM, GTM, Link Controller, ASM, PSM, or WebAccelerator https://support.f5.com/kb/en-us/solutions/public/3000/600/sol3621.html
SOL3525: Configuring the BIG-IP system to boot from a network boot server https://support.f5.com/kb/en-us/solutions/public/3000/500/sol3525.html
SOL3122: Configuring BIG-IP to use an NTP server https://support.f5.com/kb/en-us/solutions/public/3000/100/sol3122.html
SOL2788: Specifications of the Fiber Gigabit Ethernet ports included on the BIG-IP 2400 and 5100 platforms https://support.f5.com/kb/en-us/solutions/public/2000/700/sol2788.html
SOL1771: Compatibility of lasthop features with IPv6 addressing https://support.f5.com/kb/en-us/solutions/public/1000/700/sol1771.html
SOL1669: LED indicators on the BIG-IP 520 (D35) and BIG-IP 540 (D35) platforms https://support.f5.com/kb/en-us/solutions/public/1000/600/sol1669.html
SOL148: Converting the current time into the number of seconds since the beginning of the UNIX epoch https://support.f5.com/kb/en-us/solutions/public/0000/100/sol148.html
FirePass - New
SOL10342: Status of cumulative hotfix HF-603-4 https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10342.html
SOL10341: After installing cumulative hotfix HF-603-4, Active Directory authentication and group mapping may fail when nested groups are enabled https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10341.html
SOL10324: User accounts are incorrectly deactivated or deleted when synchronizing the local user database with Active Directory https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10324.html
SOL10317: Change in Behavior: The TunnelServer.exe process continues to run after a Static Application Tunnel closes https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10317.html
SOL10314: After installing cumulative hotfix HF-603-4, Active Directory authentication and group mapping may fail when the memberOf attribute contains multiple values https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10314.html
SOL10310: After installing cumulative hotfix HF-603-3, users must re-install the OPSWAT client components every time they connect https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10310.html
FirePass - Updated
SOL10279: Support for Safari 4.0
https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10279.html
SOL10150: Web browser proxy settings
https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10150.html
SOL9790: Change in Behavior: FirePass now warns users when their Active Directory password is set to expire https://support.f5.com/kb/en-us/solutions/public/9000/700/sol9790.html
SOL3622: Writing JavaScript applications for web sites that are accessed through Portal Access https://support.f5.com/kb/en-us/solutions/public/3000/600/sol3622.html
SOL3551: Web Engine Trace yields no data https://support.f5.com/kb/en-us/solutions/public/3000/500/sol3551.html
ARX - New
SOL10330: CIFS virtual services may fail to start and remain in Starting state after upgrade https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10330.html
SOL10323: The ARX system may experience poor NFS metadata performance https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10323.html
SOL10298: The NVRAM battery status may be inaccurately reported on the ARX 4000 platform https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10298.html
SOL10297: ERROR: UNTAR_REL_ERROR message when attempting to upgrade an ARX system https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10297.html
ARX - Updated
SOL10208: Change in Behavior: Display format change for the number of files used https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10208.html
SOL9651: RAID controller cable may be loose after ARX 6000 System Control Module (SCM) replacement https://support.f5.com/kb/en-us/solutions/public/9000/600/sol9651.html
Data Manager - New
SOL10320: Discovering a Solaris file server fails with a HostNameResolverConverter error https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10320.html
____________________________________________________________________
F5 Networks | 401 Elliott Avenue West | Seattle, Washington 98119
The Leader in Application Traffic Management Ensuring secure and optimized application delivery for global enterprises.
You may unsubscribe from this list at any time by sending a blank email to technews-unsubscribe@lists.f5.com
Cisco Press Wish List
2009.7.31 revised
| |
| |
| |
| |
| |
|
F5 SOL Summary
SOL3499: Backing up and restoring BIG-IP LTM, ASM, GTM, Link Controller, or WebAccelerator configuration files
SOL3499: Backing up and restoring BIG-IP LTM, ASM, GTM, Link Controller, or WebAccelerator configuration files
Updated: 4/14/09 9:54 AM
Note: The F5 Networks Enterprise Manager product is designed to facilitate the configuration management process for multiple systems. For more information, refer to the Enterprise Manager product documentation.
Note: If you are backing up or restoring BIG-IP configuration files prior to replacing an RMA unit, refer to SOL8086: Replacing a BIG-IP 9.x system in a redundant pair without interrupting service and for version 9.4.5 and later, SOL9420: Installing a UCS file containing an encrypted passphrase..
Note: For information about UCS archive files, refer to SOL4423: Overview of UCS archives.
The .ucs file contains the following configuration data:
- All BIG-IP-specific configuration files
- BIG-IP product licenses
- User accounts and password information
- DNS zone files
- Installed SSL certificates and keys
Note: For information about the contents of a UCS archive file, refer to SOL4422: Viewing and modifying the files that are configured for inclusion in a UCS archive.
Backing up your current configuration data
To back up your current configuration data, perform the following procedure:
- Log in to the command line.
- Save the configuration into a UCS archive by typing the following command, replacing
with the filename of your choice: bigpipe config save
Note: F5 Networks recommends that you name the file the same as the BIG-IP host name, because you will need this information before you restore the configuration.
By default, the BIG-IP system will save the UCS archive file in the /var/local/ucs directory.
- Copy the .ucs file to another system.
Note: For specific instructions about copying files to and from the BIG-IP system, refer to SOL175: Transferring files to or from an F5 Networks system.
Important: In addition to user accounts, passwords, and critical system files, the UCS archive file contains the SSL private keys that are used with your SSL proxies. It is important to store the backup UCS archives in an environment that is as secure as where you store your private keys.
Note: The backup process described here may be automated using a cron job and passwordless SSH login to a remote system. Sample scripts and instructions for doing so can be found in the DevCentral codeshare: BIGIPBackupScripts, LTM_Backup_Shell_Script. A separate login is required to access DevCentral content.
Restoring configuration data
To restore the BIG-IP system configuration, perform one of the following two procedures:
- Restoring the configuration data for a system that is currently running system software
- Installing the operating system and restoring the configuration data to a new system
Restoring the configuration data for a system that is currently running system software
If you are using a system that already has system software running, and you do not want to reinstall the software, perform the following procedure:
- Copy the UCS archive file to the system.
Note: For specific instructions about copying files to and from the BIG-IP system, refer to SOL175: Transferring files to or from an F5 Networks system. - Set the hostname of the system to match the hostname of the system on which the UCS archive was created, by typing one of the following commands:
- BIG-IP systems version 9.4.2 and later, type the following command:
bigpipe system hostname - BIG-IP systems versions 9.4.1 and earlier, type the following command:
hostname
Important: If you do not set the hostname to match the original hostname, the configuration restoration will fail. - BIG-IP systems version 9.4.2 and later, type the following command:
- Restore the configuration from the UCS archive, by typing the following command, replacing
with the name of your UCS archive file:
Important: Installing a UCS archive containing configurations for an add-on module, such as BIG-IP WebAccelerator or BIG-IP ASM, will fail if the system is not licensed for the module. If you are restoring a UCS archive containing configurations for a module, you must ensure the system has a valid license before installing the UCS archive. For information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system.
bigpipe config install Note: You may need to type the absolute filename if the UCS archive is not located in the default directory. For more information, refer to SOL9446: Explicit pathname to UCS archive is required with the 'bigpipe config install' command
Important: If you are restoring the backup on a different device than the system on which the backup was created, such as an RMA system, the configuration load may fail with a license error. As a result, a BigDB.dat load error message similar to the following will display:
b config install /var/local/ucs/backup.ucs
Installing full configuration on host bigip1.askf5.com
Saving active configuration...
Creating UCS for config save request...
Dec 8 12:00:00 bigip1 mcpd[2395]: 01070608:0: License is not operational
(expired or digital signature does not match contents).
Loading the new /config/BigDB.dat failed.
01080023:3: Error return while getting reply from mcpd: 0x1070370,
01070370:3: Failover (redundant mode) is not licensed.
After updating your license, run
loaddb -local /config/BigDB.dat.cs
Note: If you did not receive the above error when installing the UCS archive, you can skip to Step 8 below.
Important: If you are restoring a backup from version 9.4.5 or later after reinstalling the operating system, replacing a failed system with a new system, or otherwise moving an existing configuration to a new system), the encrypted passphrase(s) for SSL private keys used in the configuration cannot be decrypted, and an error message similar to the following will display:
BIGpipe client SSL profile creation error:
01070937:3: Master Key decrypt failure - decrypt failure
Note: If you receive the above error when installing the UCS archive, refer to SOL9420: Installing a UCS file containing an encrypted passphrase. - If you are running BIG-IP version 9.x software on a 1500, 3400, 4100, 6400, 6800, or 8400 hardware platform, type the following command to verify that the new or replaced SSH keys from the UCS file are synchronized between the BIG-IP and the SCCP:
keyswap.sh sccp
Note: For more information about synchronizing SSH keys, refer to SOL3759: Synchronizing SSH keys between the BIG-IP host system and the SCCP. - Reboot the system by typing the following command:
reboot
If you installed this system on the same device on which the backup was created, it will load the restored configuration after the system reboots. However, if you restored the backup on a different device, and received the errors noted in Step 3, you will need to perform Steps 6 through 8. - Relicense the system.
For information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system. - Finish loading the BigDB.dat information by typing the following command:
Note: You can skip this step if you did not receive the license error listed in Step 3.
loaddb -local /config/BigDB.dat.cs - Synchronize the BIG-IP system clock with the restored timezone configuration, by typing the following command:
Note: You may skip this step if you are using versions 9.4.2 and later. As of version 9.4.2, the tw_activate_keys command is not used.
tw_activate_keys ntp.timezone
Note: If the system you have restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World after completing this procedure.
Note: For additional information about recovering FIPS information after a system recovery, refer to the Recovering FIPS information after a system failure section in Configuring and Maintaining a FIPS Security Domain.
Installing the operating system and restoring the configuration data to a new system
To install the operating system and restore configuration data to a new system, perform the following procedure:
- Network boot the system software from the CD-ROM drive.
Note: For instructions, refer to SOL4411: Reinstalling BIG-IP or 3-DNS system software from a network boot server. - After the system software installs, reboot the system by typing the following command:
reboot - Connect to the serial port.
- From the command line, type the following command:
config - Follow the prompts to configure the system with an IP address.
- Copy the UCS archive file to the system.
Note: For specific instructions about copying files to and from BIG-IP, refer to SOL175: Transferring files to or from an F5 Networks system. - Set the hostname of the system to match the hostname of the system on which the UCS archive was created, by typing one of the following commands:
- BIG-IP systems version 9.4.2 and later, type the following command:
bigpipe system hostname - BIG-IP systems versions 9.4.1 and earlier, type the following command:
hostname
- BIG-IP systems version 9.4.2 and later, type the following command:
- Restore the configuration from the UCS archive, by typing the following command, replacing
with the name of your UCS archive file:
Important: Installing a UCS archive containing configurations for an add on module, such as BIG-IP WebAccelerator or ASM will fail if the system is not licensed for the module. If you are restoring a UCS archive containing configurations for a module, such as BIG-IP WebAccelerator or ASM, you must ensure the system has a valid license before installing the UCS archive. For information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system.
bigpipe config install
Note: You may need to type the absolute filename if the UCS archive is not located in the default directory. For more information, refer to SOL9446: Explicit pathname to UCS archive is required with the 'bigpipe config install' command
Important: If you are restoring the backup on a different device than the system on which the backup was created, such as an RMA system, the configuration load may fail with a license error. As a result, a BigDB.dat load error message similar to the following will display:
b config install /var/local/ucs/backup.ucs
Note: If you did not receive the above error when installing the UCS archive, you can skip Step 12 below.
Installing full configuration on host bigip1.askf5.com
Saving active configuration...
Creating UCS for config save request...
Dec 8 12:00:00 bigip1 mcpd[2395]: 01070608:0: License is not operational
(expired or digital signature does not match contents).
Loading the new /config/BigDB.dat failed.
01080023:3: Error return while getting reply from mcpd: 0x1070370,
01070370:3: Failover (redundant mode) is not licensed.
After updating your license, run
loaddb -local /config/BigDB.dat.cs
Important: If you are restoring a backup from version 9.4.5 or later after reinstalling the operating system, replacing a failed system with a new system, or otherwise moving an existing configuration to a new system), the encrypted passphrase(s) for SSL private keys used in the configuration cannot be decrypted, and an error message similar to the following will display:
BIGpipe client SSL profile creation error:
01070937:3: Master Key decrypt failure - decrypt failure
Note: If you receive the above error when installing the UCS archive, refer to SOL9420: Installing a UCS file containing an encrypted passphrase. - If you are running BIG-IP version 9.x software on a 1500, 3400, 4100, 6400, 6800, or 8400 hardware platform, type the following command to verify that the new or replaced SSH keys from the UCS file are synchronized between the BIG-IP and the SCCP:
keyswap.sh sccp
Note: For more information, refer to SOL3759: Synchronizing SSH keys between the BIG-IP host system and the SCCP. - Reboot the system by typing the following command:
reboot
If you installed this system on the same device on which the backup was created, after the system reboots, it will load the restored configuration; however, if you restored the backup on a different device, and received the errors noted in Step 8, then perform Steps 11 through 13. - Relicense the system.
Note: For more information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system. - Finish loading the BigDB.dat information by typing the following command
Note: You can skip this step if you did not receive the license error listed in Step 8.
loaddb -local /config/BigDB.dat.cs - Synchronize the BIG-IP system clock with the restored timezone configuration, by typing the following command:
tw_activate_keys ntp.timezone
Note: As of version 9.4.2, the tw_activate_keys command is not used and this step can be skipped for those using versions 9.4.2 and later.
Note: If the system you have restored contains the FIPS 140 HSM, you must now configure the FIPS 140 HSM Security World.
Note: For additional information about recovering FIPS information after a system recovery, refer to the Recovering FIPS information after a system failure section in Configuring and Maintaining a FIPS Security Domain.
SOL6353: Updating an SSL certificate on a BIG-IP GTM or Link Controller system
SOL6353: Updating an SSL certificate on a BIG-IP GTM or Link Controller system
Updated: 6/24/09 11:47 AM
To update the SSL certificate on a BIG-IP GTM or BIG-IP Link Controller system, you must perform the following procedures:
- Renew the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller for another year
- Run the bigip_add script on remote BIG-IP GTM or BIG-IP Link Controller systems
Additionally, you have the option to perform the following procedure:
- Renew and import the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller for longer than one year
Note: Using a third party SSL certificate for iQuery communication is supported beginning with BIG-IP GTM version 9.3. For more information, refer to SOL7717: Change in Behavior: The BIG-IP GTM and BIG-IP Link Controller support third party SSL certificates. Using a third party SSL certificate in previous versions causes BIG-IP GTM iQuery SSL failure. For more information, refer to SOL6692: Using a third party SSL certificate causes BIG-IP GTM iQuery SSL to fail.
Important: As a result of a known issue, the import functionality for trusted device certificates, performed in the Renewing and importing the device certificate on the BIG-IP GTM procedure, stores the certificate in the wrong file. As a result, the Moving trusted device certificates to the proper file procedure is required. For information, refer to SOL6996: The trusted device certificate is imported to the incorrect file.
Renewing the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller for another year
To renew and import the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller, perform the following procedure:
- Log in to the Configuration utility.
- Click System.
- Click Device Certificates.
- Click the Renew button.
- Select Self from the Issuer drop-down menu.
- Select the appropriate country from the Country drop-down menu.
- Click the Finished button.
Running the bigip_add script on remote BIG-IP GTM or BIG-IP Link Controller systems
To run the bigip_add utility on the remote BIG-IP GTM or BIG-IP Link Controller system in a synchronization group in order to obtain the BIG-IP GTM or BIG-IP Link Controller system's new certificate, type the following command from the command line of the remote BIG-IP GTM or BIG-IP Link Controller:
bigip_add
OPTIONAL: Renewing and importing the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller for longer than one year
Note: Beginning in BIG-IP version 10.0.0, self-signed device certificates validity can be adjusted within the Configuration utility. For more information, refer to SOL10233: Change in Behavior: Self-signed device certificates lifetime value can be configured within the Configuration utility.
To renew and import the self-signed device certificate on the BIG-IP GTM or BIG-IP Link Controller for longer than one year, perform the following procedure:
Note: The following procedure is optional and should only be used if you want to extend the expiration time of the self-signed certificate, as this procedure does not allow you to change any information within the certificate other than the expiration date.
- Log in to the command line.
- Change directories to the /config/httpd/conf/ssl.crt directory by typing the following command:
cd /config/httpd/conf/ssl.crt
- Convert the server.crt certificate to a certificate signing request .csr by typing the following command:
openssl x509 -x509toreq -in server.crt -out server.csr -signkey /config/httpd/conf/ssl.key/server.key
- Using the new CSR, specify the number of days for which the certificate should be valid by typing the following command:
openssl x509 -req -in server.csr -signkey /config/httpd/conf/ssl.key/server.key -days <# of days> -out server.crt
- Replace <# of days> with the number of days in year increments for which you want the certificate to be valid. For example, if you want to make the certificate valid for one year, type the following command:
openssl x509 -req -in server.csr -signkey /config/httpd/conf/ssl.key/server.key -days 365 -out server.crt
Additionally, you can use the following quick reference table to select the number of years for which you want the certificate to be valid:
Year(s) Number of Days 1 365 2 730 5 1825 10 3650 -
Restart the web server daemon by typing the following command:
bigstart restart httpd
- Copy the new extended expiration self-signed certificate to the trusted device certificate file by typing the following command:
cat /config/httpd/conf/ssl.crt/server.crt >> /config/big3d/client.crt
- Copy the new extended expiration self-signed certificate to the trusted server certificate file by typing the following command:
cat /config/httpd/conf/ssl.crt/server.crt >> /config/gtm/server.crt - To run the bigip_add script on the remote BIG-IP GTM or BIG-IP LC system in a synchronization group in order to obtain the BIG-IP GTM or BIG-IP Link Controller system's new certificate, type the following command from the command line of the remote BIG-IP GTM or BIG-IP Link Controller:
bigip_add
SOL7550: Resetting the BIG-IP system configuration to the factory default settings using the sys-reset command
SOL7550: Resetting the BIG-IP system configuration to the factory default settings using the sys-reset command
Updated: 7/22/09 2:52 PM
Beginning with BIG-IP LTM version 9.4, you can restore all system configurations to factory default values using the sys-reset command.
Note: The sys-reset command was removed in BIG-IP version 10.0.1.
Note: For information about resetting the BIG-IP system for versions 9.0 through 9.3, refer to SOL6887: Resetting the BIG-IP system configuration to the default settings.
Restoring the BIG-IP LTM to factory default values using the sys-reset command removes all system configuration settings, including the licensing information. All files that are not recorded in the RPM database will also be removed.
The sys-reset command runs the sys-icheck utility, which identifies any unintended modifications to BIG-IP system files. If the sys-icheck utility does not find any system integrity issues, it returns the system to the factory default state.
Note: For more information, refer to SOL9118: Overview of the sys-icheck utility.
Description of the sys-reset command
When you reset the BIG-IP LTM to factory defaults, the sys-reset command performs the following tasks:
- Removes all BIG-IP system configuration and restores the factory default values
- Removes system licensing information
- Resets system passwords and the hostname to default settings
- Removes all files in the /shared partition
- Preserves management interface settings
Syntax options for the sys-reset command
You can perform the following options with the sys-reset command:
Syntax | Syntax function |
-h | Shows help for the sys-reset command |
-p | Ignores all applied hotfixes (not recommended) |
-u | Ignores unrecoverable file errors |
-s | Preserves the /shared partition |
Known Issues
For information regarding known issues affecting the sys-reset utility, refer to the following Solutions:
SOL9384: The sys-reset utility does not correctly process filenames with spaces
Running sys-reset
To run the sys-reset command, perform one of the following procedures based on the configuration of your BIG-IP system:
- A system with multiple partitions
- A system with single partitions
- A system with hotfix packages installed
Running sys-reset on BIG-IP systems with multiple partitions
You can run the sys-reset command on systems with single or multiple partitions. When you run the sys-reset utility on systems with multiple partitions, all BIG-IP system configuration information is removed from the partition on which sys-reset was run. Configuration information on other partitions is not altered.
The following BIG-IP systems contain multiple partitions:
- BIG-IP 520 and 540 (D35)
- BIG-IP 1500 (C36)
- BIG-IP 1600 (C102)
- BIG-IP 3400 (C62)
- BIG-IP 3410 (C100)
- BIG-IP 3600 (C103)
- BIG-IP 6400 (D63)
- BIG-IP 6800 (D68)
- BIG-IP 8400 (D84)
- BIG-IP 8800 (D88)
Note: You must be local to the BIG-IP system with a console connection to perform this procedure.
To run the sys-reset utility on systems with multiple partitions, perform the following procedure:
- Log in to the command line from the system console.
- Boot the BIG-IP system to the partition from which you want to run the sys-reset command.
Note: For more information, refer to SOL5658: Overview of the switchboot utility. - Back up the system license file to a remote location.
- Set the system run level to single user mode by typing the following command:
init 1
Important: The procedure outlined in SOL4178: Booting BIG-IP in single-user mode should not be used to set the machine to single-user mode when running the sys-reset utility. - From the prompt, type the following command:
sys-reset
A message will display indicating that the system reset is complete. - Reboot the device by typing the following command:
reboot
The BIG-IP system configuration has been restored to the factory default values.
Running sys-reset on BIG-IP systems with single partitions
You can run the sys-reset command on systems with single or multiple partitions. When you run the sys-reset utility on systems with a single partition, all BIG-IP system configuration information is removed from the partition.
The following BIG-IP systems contain a single partition:
- BIG-IP 1000 D39
- BIG-IP 2400 D44
- BIG-IP 5100 D51
- BIG-IP 5110 D51
Note: You must be local to the BIG-IP system with a console connection to perform this procedure.
To run the sys-reset utility on systems with a single partition, perform the following procedure:
- Log in to the command line from the system console.
- Back up the system license file to a remote location.
- Set the system run level to single user mode by typing the following command:
Note: This step is not required in BIG-IP version 10.0.0 and later. Proceed to step 4.
init 1
Important: The procedure outlined in SOL4178: Booting BIG-IP in single-user mode should not be used to set the machine to single-user mode when running the sys-reset utility. - From the prompt, type the following command:
sys-reset
A message will display indicating that the system reset is complete. - Reboot the device by typing the following command:
reboot
The BIG-IP system configuration has been restored to the factory default values.
Running sys-reset with the -p option
The sys-reset -p option runs sys-reset ignoring any hotfixes that have been applied to the system.
Note: F5 Networks does not recommended running sys-reset on a system in which a hotfix is installed. If you plan to run the sys-reset utility to restore a system to factory default values, you should first uninstall the hotfix. For more information about managing hotfixes, refer to SOL6845: Managing F5 Networks product hotfixes.
Preserving the /shared partition
By default, the sys-reset utility removes all files in the /shared partition. You can run the sys-reset command and have the system preserve all files in the /shared partition by typing the following sys-reset command:
sys-reset -s
SOL6887: Resetting the BIG-IP system configuration to the default settings
SOL6887: Resetting the BIG-IP system configuration to the default settings
Updated: 4/14/09 11:17 AM
Important: This Solution is valid only for BIG-IP version 9.0.5 through 9.3.x. Use of the bigpipe reset or bigpipe base reset commands on prior versions may result in an inoperable system.
Note: For information about resetting the BIG-IP system for versions 9.4 and higher, refer to SOL7550: Resetting the BIG-IP system configuration to the factory default settings using the sys-reset command.
The BIG-IP system references three discrete sets of configuration settings:
- High level configuration
The high level configuration contains all of the settings that determine how the BIG-IP system processes traffic. These settings are stored in the /config/bigip.conf file.
- Base configuration
The base configuration contains settings that provide network access to the BIG-IP system. These settings are stored in the /config/bigip_base.conf file.
- Configuration database
The configuration database contains system settings that are not saved in the High Level or Base configuration, such as the hostname, high availability configuration settings, Configuration Utility (GUI) customizations, and settings for some network services. These settings are stored in the /config/BigDB.dat file.
Note: The settings contained in the the /config/BigDB.dat file may be viewed using the bigpipe db command.
You can independently reset each of these three configurations back to their default settings, or reset all settings to the default by performing a clean installation of the BIG-IP software. Refer to the following procedures for detailed instructions.
Important: The following procedures will remove your existing configuration. Before you use any of these procedures, you should back up your current configuration as detailed in SOL3499: Backing up and restoring BIG-IP LTM, GTM, or ASM configuration files. If you are performing a clean installation, you should save your backup file to another system prior to re-installing.
Resetting the entire configuration
You can reset the entire BIG-IP configuration by performing a clean installation of the same version of the BIG-IP software. For instructions, refer to the Release Notes for the product and version that you are running.
Resetting the high level configuration
To reset the high level configuration, perform the following procedure:
-
Log in to the BIG-IP command line.
-
Reset the configuration in memory by typing the following command:
bigpipe reset
The configuration contained in memory is now reset to the default settings, but the configuration saved in the /config/bigip.conf file has not been changed.
-
Save the default configuration to the /config/bigip.conf file by typing the following command:
bigpipe save
The configuration contained in the /config/bigip.conf file is now reset to the default settings.
Resetting the base configuration
To reset the base configuration, perform the following procedure:
-
Connect to the serial console port of the BIG-IP system.
Important: You must connect to the serial console port, not over a network connection. Resetting the base configuration resets all management and self IP addresses, and any network connections will be dropped.
-
Log in to the BIG-IP command line.
-
Reset the configuration that is contained in memory by typing the following command:
bigpipe base reset
The configuration contained in memory is now reset to the default settings, but the configuration saved in the /config/bigip_base.conf file has not been changed.
-
Save the default configuration to the /config/bigip_base.conf file by typing the following command:
bigpipe base save
The configuration contained in the /config/bigip_base.conf file is now reset to the default settings.
Resetting the configuration database
To reset the configuration database, perform the following procedure:
-
Log in to the command line of the BIG-IP system.
-
Reset the database by typing the following command:
bigpipe db all reset
The configuration database is now reset to the default settings.
You should now run the initial configuration utility from the Configuration utility and re-license your BIG-IP system.
Note: This procedure does not reset the admin password. For instructions about changing passwords, refer to SOL3350: Changing account passwords for the command line and Configuration utility.
SOL7754: Renewing self-signed device certificates
SOL7754: Renewing self-signed device certificates
Updated: 6/24/09 11:07 AM
Note: The SSL certificate in this Solution is the certificate used by the Configuration utility and is not associated with any certificates used by either the Client or the Server SSL profile.
By default, BIG-IP devices use self-signed SSL certificates for access to the Configuration utility. The certificates are valid for one year; they will indicate their expiration when you access the Configuration utility with a web browser.
If the certificate expires, it will not have any adverse affects, as you can still access the Configuration utility. There are instances in which the expiration of the certificate has adverse effects, such as when BIG-IP LTM and BIG-IP GTM units are configured to communicate with each other. In this case, the BIG-IP GTM is no longer able to communicate with the BIG-IP LTM that contains the expired self-signed certificate. For information regarding the expiration of the certificate affecting BIG-IP LTM and BIG-IP GTM communication, refer to SOL7466: Expiration of a Configuration utility SSL certificate on a BIG-IP LTM system causes the BIG-IP LTM to be marked down on a BIG-IP GTM system.
The Configuration utility can use both third party certificates as well as self-signed certificates. You can update self-signed certificates to increase the expiration period by following the version-specific procedures.
Note: For information about third party certificates used within a BIG-IP LTM and BIG-IP GTM version 9.3 or later environment, refer to Chapter 11 of the Global Traffic Manager and Link Controller: Implementations manual. For information regarding third party certificates used within BIG-IP LTM versions 9.0 through 9.2.5 and BIG-IP GTM version 9.3 or later, refer to SOL7742: Configuring the BIG-IP LTM to use third party SSL certificates in a BIG-IP GTM environment.
Renewing the BIG-IP LTM or BIG-IP ASM certificate for another year
To renew the BIG-IP LTM or BIG-IP ASM certificate for another year, perform one of the following version-specific procedures:
Important: If any information is updated other than the validity date, you must re-import the certificate into the BIG-IP GTM. Otherwise, the certificate is considered invalid because it does not match the certificate on the BIG-IP GTM.
Versions 9.2 through 9.4.7
- Log in to the BIG-IP LTM or BIG-IP ASM Configuration utility.
- Select System.
- Select Device Certificates.
- Select Renew.
- Change Issuer from Certificate Authority to Self.
Note: As an optional step, you may choose to update any information at this point.
- Click Finished.
Versions 9.0 through 9.1.3
- Log in to the BIG-IP LTM or BIG-IP ASM Configuration utility.
- Select System.
- Select Platform.
- Select Web Server Certificate.
- Select Renew.
- Change Issuer from Certificate Authority to Self.
Note: As an optional step, you may choose to update any information at this point.
- Click Finished.
Renewing the BIG-IP LTM or BIG-IP ASM certificate for longer than one year
Note: Beginning in BIG-IP version 10.0.0, you can adjust self-signed device certificates validity within the Configuration utility. For more information, refer to SOL10233: Change in Behavior: Self-signed device certificates lifetime value can be configured within the Configuration utility.
To renew the BIG-IP LTM or BIG-IP ASM certificate for more than one year, perform the following procedure:
- Log in to the command line.
- Change directories to the /config/httpd/conf/ssl.crt directory by typing the following command:
cd /config/httpd/conf/ssl.crt
- Convert the server.crt certificate to a certificate signing request CSR by typing the following command:
openssl x509 -x509toreq -in server.crt -out server.csr -signkey /config/httpd/conf/ssl.key/server.key
- Using the new CSR, specify the number of days for which the certificate should be valid by typing the following command:
openssl x509 -req -in server.csr -signkey /config/httpd/conf/ssl.key/server.key -days <# of days> -out server.crt
Note: Replace <# of days> with the number of days in year increments for which you want the certificate to be valid.
For example, if you want to make the certificate valid for one year, you would type the following command:
openssl x509 -req -in server.csr -signkey /config/httpd/conf/ssl.key/server.key -days 365 -out server.crt
Additionally, you can use the following quick reference table to select the number of years for which you want the certificate to be valid:
Year(s) Number of Days 1 365 2 730 5 1825 10 3650
Note: The number of days in the table do not include additional days for a leap year.
- Restart the web server daemon by typing the following command:
bigstart restart httpd
SOL8665: BIG-IP redundant pair hardware and software parity requirements
SOL8665: BIG-IP redundant pair hardware and software parity requirements
Updated: 7/20/09 3:19 PM
A BIG-IP redundant system consists of two identically provisioned and configured BIG-IP units that allow traffic processing to continue in the event that one of the BIG-IP units in the pair becomes unavailable.
BIG-IP hardware requirements
The BIG-IP units in a redundant system must be running on the same hardware platform. F5 Networks does not support BIG-IP redundant pair configurations that run on different hardware platforms, as this configuration may detrimentally affect traffic management upon failover.
For example, if one BIG-IP system in a redundant pair runs on the 3400 platform, the peer system must also run on the 3400 platform.
BIG-IP host software requirements
The BIG-IP units in a redundant system must run the same host software versions. F5 Networks does not support BIG-IP redundant pair configurations that run different software versions, as this configuration may detrimentally affect traffic management upon failover.
For example, if one BIG-IP system in a redundant pair runs version 9.4.4, the peer system must also run version 9.4.4.
If the existing BIG-IP system runs a later software version, you must upgrade the peer system. For information about upgrading, refer to the BIG-IP LTM Release Notes.
BIG-IP hotfix requirements
In addition to requiring that BIG-IP systems in a redundant pair run the same host software versions, systems in a redundant pair must run the same hotfix version. F5 Networks does not support BIG-IP redundant pair configurations that run different hotfix versions.
For example, if one BIG-IP system in a redundant pair runs Hotfix-BIG-IP-9.4.4-HF1, issued for BIG-IP version 9.4.4, the peer system must also run Hotfix-BIG-IP-9.4.4-HF1, issued for BIG-IP version 9.4.4.
If the existing BIG-IP system runs a later hotfix version, you must upgrade the peer system. For information about upgrading, refer to the BIG-IP LTM Release Notes.
SCCP firmware requirements
For information, refer to SOL8835: BIG-IP redundant pair SCCP firmware requirements.
Important: F5 Networks strongly recommends performing software upgrades during a scheduled maintenance window. When upgrading the units in a redundant system, they will temporarily be running different software. In most cases, failing over to upgrade the second system will be no different from a normal failover. However, depending on the versions involved in the upgrade, some traffic may be disrupted due to changes in profile functionality and any mirroring options that may be configured. Two specific examples of mirroring features that may be impacted are detailed in SOL7225: Overview of the BIG-IP LTM mirroring and network failover transport protocol and SOL9057: Overview of the BIG-IP LTM network failover transport protocol.