網頁

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

Cisco Access Control Security: AAA Administration Services
Cisco Access Control Security: AAA Administration Services(Delete)
By Brandon James Carroll
Saved Jul 31, 2009
Cisco LAN Switching Configuration Handbook
Cisco LAN Switching Configuration Handbook(Delete)
By David Hucaby, David Jansen, Steve McQuerry
Saved Jul 29, 2009
Designing for Cisco Internetwork Solutions (DESGN) (Authorized CCDA Self-Study Guide) (Exam 640-863)
Designing for Cisco Internetwork Solutions (DESGN) (Authorized CCDA Self-Study Guide) (Exam 640-863)(Delete)
By Diane Teare
Saved Jul 28, 2009
Designing Cisco Network Service Architectures (ARCH) (Authorized Self-Study Guide)
Designing Cisco Network Service Architectures (ARCH) (Authorized Self-Study Guide)(Delete)
By Keith Hutton, Mark Schofield, Diane Teare
Saved Jul 28, 2009
Cisco Router Firewall Security
Cisco Router Firewall Security(Delete)
By Richard Deal
Saved Mar 17, 2009
Cisco LAN Switching Fundamentals
Cisco LAN Switching Fundamentals(Delete)
By David Barnes, Basir Sakandar
Saved Nov 11, 2008
End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs
End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs(Delete)
By Christina Hattingh, Tim Szigeti
Saved Jan 28, 2008
LAN Switch Security: What Hackers Know About Your Switches
LAN Switch Security: What Hackers Know About Your Switches(Delete)
By Christopher Paggen, Eric Vyncke
Saved Jan 28, 2008
End-to-End Network Security: Defense-in-Depth
End-to-End Network Security: Defense-in-Depth(Delete)
By Omar Santos
Saved Jan 28, 2008
張貼者： 於 沒有留言:
標籤：

F5 SOL Summary

如果要將設備設定恢復成工廠預設值, 且版本是v9.0.5 ~ v9.3.x請參考SOL6887
如果要將設備設定恢復成工廠預設值, 且版本是v9.4請參考SOL7550
如果要將設備設定備份或回存的動作,請參考SOL3499
張貼者： 於 沒有留言:
標籤：

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
Solution

This Solution describes how to back up and restore your configuration data using a UCS configuration archive. Unless your configuration has been customized to run programs that are not normally supported on the BIG-IP system, the UCS archive will contain all files required to restore your current configuration to a new system.

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:

  1. Log in to the command line.
  2. 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.

  3. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Relicense the system.

    For information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system.
  7. 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
  8. 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:

  1. 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.
  2. After the system software installs, reboot the system by typing the following command:

    reboot
  3. Connect to the serial port.
  4. From the command line, type the following command:

    config
  5. Follow the prompts to configure the system with an IP address.
  6. 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.
  7. 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.
  8. 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
    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 Step 12 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.
  9. 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.
  10. 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.
  11. Relicense the system.

    Note: For more information about licensing, refer to SOL7752: Overview of licensing the BIG-IP system.
  12. 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
  13. 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
Solution

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:

  1. Log in to the Configuration utility.
  2. Click System.
  3. Click Device Certificates.
  4. Click the Renew button.
  5. Select Self from the Issuer drop-down menu.
  6. Select the appropriate country from the Country drop-down menu.
  7. 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.

  1. Log in to the command line.
  2. Change directories to the /config/httpd/conf/ssl.crt directory by typing the following command:

    cd /config/httpd/conf/ssl.crt

  3. 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

  4. 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

  5. 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

  6. Restart the web server daemon by typing the following command:

    bigstart restart httpd

  7. 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

  8. 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
  9. 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
Solution

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:

SOL10035: Issuing a sys-reset when remote authentication is configured will prevent logging into the system after a reboot

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:

  1. Log in to the command line from the system console.
  2. 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.
  3. Back up the system license file to a remote location.
  4. 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.
  5. From the prompt, type the following command:

    sys-reset

    A message will display indicating that the system reset is complete.
  6. 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:

  1. Log in to the command line from the system console.
  2. Back up the system license file to a remote location.
  3. 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.
  4. From the prompt, type the following command:

    sys-reset

    A message will display indicating that the system reset is complete.
  5. 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
Solution

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:

  1. Log in to the BIG-IP command line.

  2. 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.

  3. 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:

  1. 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.

  2. Log in to the BIG-IP command line.

  3. 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.

  4. 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:

  1. Log in to the command line of the BIG-IP system.

  2. 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
Solution

Note: The following Solution covers the BIG-IP LTM and BIG-IP ASM. For information about updating SSL device certificates on a BIG-IP GTM or BIG-IP Link Controller refer to SOL6353: Updating an SSL certificate on a BIG-IP GTM or BIG-IP Link Controller system.

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

  1. Log in to the BIG-IP LTM or BIG-IP ASM Configuration utility.
  2. Select System.
  3. Select Device Certificates.
  4. Select Renew.
  5. Change Issuer from Certificate Authority to Self.

    Note: As an optional step, you may choose to update any information at this point.

  6. Click Finished.

Versions 9.0 through 9.1.3

  1. Log in to the BIG-IP LTM or BIG-IP ASM Configuration utility.
  2. Select System.
  3. Select Platform.
  4. Select Web Server Certificate.
  5. Select Renew.
  6. Change Issuer from Certificate Authority to Self.

    Note: As an optional step, you may choose to update any information at this point.

  7. 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:

  1. Log in to the command line.
  2. Change directories to the /config/httpd/conf/ssl.crt directory by typing the following command:

    cd /config/httpd/conf/ssl.crt

  3. 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

  4. 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.
  5. 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
Solution

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.

張貼者： 於 沒有留言:
標籤：

SOL9812: Overview of BIG-IP TCP RST behavior

SOL9812: Overview of BIG-IP TCP RST behavior

Updated: 7/7/09 4:10 PM
Solution

The BIG-IP system will close a TCP connection by sending a TCP RST packet to a client and/or pool member under a variety of circumstances. Depending on the specific BIG-IP LTM object, the BIG-IP reset behavior can be adjusted from the default settings by using the Configuration utility or command line.

The BIG-IP LTM may send a TCP RST packet for the following reasons:

Global Settings

  • Adaptive Reaping

    In order to prevent SYN flood attacks, and to preserve memory, the BIG-IP system can prevent new connections by sending a TCP RST packet to the client when memory usage increases beyond the reaper high-water mark setting. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object IP address for which the SYN request was destined.

    Note: For more information, refer to SOL5670: Overview of adaptive connection reaping and SOL7301: Protecting the BIG-IP LTM against denial of service attacks.
  • TM.MaxRejectRate

    The BIG-IP system sends a TCP RST packet in response to a non-SYN packet which matches a virtual server address and port or self IP address and port, but does not match an established connection. The BIG-IP system also sends a TCP RST packet in response to a packet matching a virtual server address or self IP address, but specifying an invalid port. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object address or self IP address for which the packet was destined.

    Note: For more information, refer to SOL9259: Limiting the rate at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets and SOL7317: Overview of port lockdown behavior.

Virtual servers

  • Virtual server connection limits

    When a virtual server connection limit is configured, and the maximum number of concurrent connections is exceeded for the virtual server, the BIG-IP sends a TCP RST packet in response to connection attempts. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.

    Note: For more information, refer to SOL5067: The BIG-IP sends a reset when a virtual server connection limit is reached.
  • Reject virtual servers

    A Reject virtual server always sends a TCP RST packet in response to a connection attempt. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.

    Note: For more information, refer to SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types.

Pools

Profiles

SNATs

Note: Connections processed by a SNAT object are also frequently processed by a virtual server object. The source address of the TCP RST packet will vary depending on whether the connection is processed by a SNAT object alone, or whether the connection is also processed by a virtual server.

Monitors

  • BIG-IP health monitors

    Certain BIG-IP monitors use a TCP RST packet to close the monitor connection quickly. For example, the tcp_half_open monitor performs a simple check on the pool member service by sending a TCP SYN packet to the service port. When the monitor receives the SYN-ACK packet from the pool member, the monitor considers the service to be up, and sends a TCP RST packet to the service instead of completing the three-way handshake. The TCP RST packet is typically sent on the server side of the connection, and the source IP address of the reset is the relevant self IP address of the VLAN.

iRules

  • iRule commands

    An iRule can be configured to close TCP connections using a TCP RST packet. For example, the reject iRule command closes the TCP connection by sending a TCP RST packet to the TCP peer as appropriate for the protocol. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object address with which the iRule is associated.

    Note: For more information, refer to the DevCentral iRule wiki. A separate DevCentral login is required to access this content; you will be redirected to authenticate or register (if necessary).

VLAN groups

  • L2 forwarding proxy (VLAN groups)

    In a VLAN group configuration, traffic that does not match a configuration object, such as a virtual server or SNAT, is handled by the Layer 2 (L2) forwarding proxy. The L2 proxy default will send a TCP RST packet to close L2 forwarding sessions after 300 seconds. The TCP RST packet is sent on the client and/or server side of the connection, and the source IP address of the reset is the self IP address of the VLAN.

    Note: For more information, refer to SOL7606: Overview of BIG-IP LTM idle session timeouts.
張貼者： 於 沒有留言:
標籤：
訂閱： 文章 (Atom)

追蹤者