網頁

2009年7月29日 星期三

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.
張貼者： 於 沒有留言:
標籤：

SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types

SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types

Updated: 7/6/09 5:26 PM
Solution

Standard virtual server
Performance Layer4 virtual server
Performance HTTP virtual server
Forwarding Layer 2 virtual server
Forwarding IP virtual server
Reject virtual server

Standard virtual server


The BIG-IP LTM TMOS operating system implements a 'full proxy' architecture for virtual servers configured with a TCP profile. By assigning a custom TCP profile to the virtual server, you can configure the BIG-IP LTM to maintain compatibility to disparate server operating systems in the data center. At the same time, the BIG-IP LTM can leverage it’s TCP/IP stack on the client side of the connection to provide independent and optimized TCP connections to client systems.

In a full proxy architecture, the BIG-IP LTM appears as a TCP peer to both the client and the server by associating two independent TCP connections with the end-to-end session. Although certain client information such as the source IP address, or source TCP port may be re-used on the server-side of the connection, the BIG-IP LTM manages the two sessions independently, making itself transparent to the client and server.

The Standard virtual server requires a TCP or UDP profile, and may optionally be configured with HTTP, FTP or SSL, profiles if Layer 7 or SSL processing is required.

The TCP connection set-up behavior for a Standard virtual server varies depending on whether a TCP profile or a TCP and Layer 7 profile such as HTTP, is associated with the virtual server.

Standard virtual server with TCP profile


The TCP connection set-up behavior for a Standard virtual server operates as follows: the three-way TCP handshake occurs on the client side of the connection before the BIG-IP LTM initiates the TCP handshake on the server side of the connection.

A Standard virtual server processes connections using the full proxy architecture. The following TCP flow diagram illustrates the TCP handshake for a Standard virtual server with TCP profile:

Standard virtual server with Layer 7 functionality


If a Standard virtual server is configured with Layer 7 functionality, such as an HTTP profile, the client must send at least one data packet before the server-side connection can be initiated by the BIG-IP LTM.

Note: The BIG-IP LTM may initiate the server-side connection prior to the first data packet for certain Layer 7 applications, such as FTP, in which the user waits for a greeting banner before sending any data.

The TCP connection set-up behavior for a Standard virtual server with Layer 7 functionality operates as follows: the three-way TCP handshake and initial data packet are processed on the client side of the connection before the BIG-IP LTM initiates the TCP handshake on the server side of the connection.

A Standard virtual server with Layer 7 functionality processes connections using the full proxy architecture. The following TCP flow diagram illustrates the TCP handshake for a Standard virtual server with Layer 7 functionality:

Performance Layer4 virtual server


The Performance Layer4 virtual server type uses the Fast L4 profile. Depending on the configuration, the virtual server utilizes the PVA ASIC chip with the PVA Acceleration mode defined as one of the following: full, assisted or none. Irrespective of the PVA acceleration mode used in the profile, the Performance Layer4 virtual server processes connections on a packet-by-packet basis.

The Performance Layer4 virtual server packet-by-packet TCP behavior operates as follows: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM makes the load balancing decision and passes the SYN request to the pool member.

The following TCP flow diagram illustrates the TCP handshake for a Performance Layer4 virtual server:

Performance HTTP virtual server


The Performance HTTP virtual server type uses the Fast HTTP profile. The Performance HTTP virtual server together with the Fast HTTP profile is designed to speed up certain types of HTTP connections and reduce the number of connections opened to the back-end HTTP servers. This is accomplished by combining features from the TCP, HTTP, and OneConnect profiles into a single profile that is optimized for network performance. The Performance HTTP virtual server processes connections on a packet-by-packet basis and buffers only enough data to parse packet headers.

The Performance HTTP virtual server TCP behavior operates as follows: The BIG-IP system establishes server-side flows by opening TCP connections to the pool members. When a client makes a connection to the Performance HTTP virtual server, if an existing server-side flow to the pool member is idle, the BIG-IP LTM system marks the connection as non-idle and sends client request over it.

Performance HTTP virtual server with idle server-side flow


The following TCP flow diagram illustrates the client connection to the Performance HTTP virtual server when an idle server-side flow is found (in this case the idle flow was created by the BIG-IP system):

Performance HTTP virtual server with no idle server-side flow


If an idle server-side flow is not found, the BIG-IP system creates a new server-side TCP connection and sends client request over it.

The following TCP flow diagram illustrates the client connection to the Performance HTTP virtual server when no idle server-side flow is found:

Forwarding Layer 2 virtual server


The Forwarding Layer 2 virtual server type uses the Fast L4 profile. The Forwarding Layer 2 virtual server forwards packets based on the destination L2 Media Access Control (MAC) address, and therefore does not have pool members to load balance. The virtual server shares the same IP address as a node in an associated VLAN. Before creating a Forwarding Layer 2 virtual server, you must define a VLAN group that includes the VLAN in which the node resides. The Forwarding Layer 2 virtual server processes connections on a packet-by-packet basis.

The Forwarding Layer 2 virtual server operates on a packet-by-packet basis with the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM passes the SYN request to the node in the associated VLAN based on the destination MAC address.

The following TCP flow diagram illustrates the TCP handshake for a Forwarding Layer 2 virtual server:

Forwarding IP virtual server


The Forwarding IP virtual server type uses the Fast L4 profile. An IP forwarding virtual server forwards the packet directly to the next hop IP address specified in the client request. Therefore, when the BIG-IP LTM system evaluates the packet for processing, the system looks only at the destination IP address. The Forwarding IP virtual server processes connections on a packet-by-packet basis.

The Forwarding IP virtual server operates on a packet-by-packet basis with the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM passes the SYN request to the next IP address in the associated VLAN based on the destination IP address.

The following TCP flow diagram illustrates the TCP handshake for a Forwarding IP virtual server:


Reject virtual server

The Reject virtual server type causes the BIG-IP system to immediately reject any traffic destined for the virtual server IP address.

The Reject virtual server operates using the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM immediately closes the connection by sending a TCP reset to the client.

The following TCP flow diagram illustrates the TCP behavior for a Reject virtual server:

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

SOL4707: Choosing a profile for HTTP traffic

SOL4707: Choosing a profile for HTTP traffic

Best Practice
Updated: 7/6/09 7:43 PM
Best Practice

In BIG-IP 9.x you can process HTTP traffic using various profiles, including TCP+HTTP, FastHTTP, and FastL4. Each profile, or combination of profiles, offers distinct advantages, limitations, and features.

F5 Networks recommends that you assess the needs of each HTTP virtual server individually, using the following information to determine which profile, or profile combination, will best meet the requirements for each virtual server.

Important: The HTTP profile will work in all cases; however, the HTTP profile places BIG-IP in full Layer 7 inspection mode, which can be unnecessarily intensive when used on simple load balancing virtual servers. Thus, the other profile options provided should be considered in instances where the full Layer 7 engine is not necessary for a particular virtual server.

TCP+HTTP

Profiles: TCP+HTTP

Advantage: The HTTP profile can take full advantage of all of BIG-IP's Layers 4 - 7 HTTP/HTTPS features.

When to use: The HTTP profile is used when any of the following features are required:

  • TCPexpress and content spooling features reduce server load
  • Full OneConnect functionality (including HTTP 1.0 transformations)
  • Layer 7 persistence (cookie, hash, universal, and iRule)
  • Full HTTP iRules logic
  • HTTP FastCache
  • HTTP Compression
  • HTTP pipelining
  • Virtual Server Authentication
  • Redirect Rewriting

Limitations:

  • More CPU-intensive
  • Memory utilization:
    • FastCache:
      Provisions user-defined memory allocation for cache content for each virtual server that utilizes the given HTTP profile with FastCache enabled.
    • Compression:
      Larger buffer sizes can increase memory utilization when compressing large objects.
    • TCP offloading/content spooling:
      Can increase memory utilization in cases where either the client-side or the server-side of the connection is slower than the other. The BIG-IP will hold the data in the buffer until the slower side of the connection is able to retrieve it.

      Note: For more information about the TCP profile, refer to SOL7559: Overview of the TCP profile.

FastHTTP

Profile: FastHTTP

Advantage: Faster than HTTP profile

When to use: FastHTTP profile is recommended when it is not necessary to use persistence and or maintain source IP addresses. FastHTTP also adds a subset of OneConnect features to reduce the number of connections opened to the backend HTTP servers. The FastHTTP profile requires that the clients' source addresses are translated. If an explicit SNAT or SNAT pool is not specified, the appropriate self IP address is used.

Note: Typically, server efficiency increases as the number of SNAT addresses available to the virtual server increases. At the same time, the increase in SNAT addresses available to the virtual server also decreases the likelihood that the virtual server will reach the point of ephemeral port exhaustion (65535 open connections per SNAT address).

Limitations:

  • Requires client source address translation
  • Not compatible with persistence
  • Limited iRules support L4 and are limited to a subset of HTTP header operations, and pool/pool member selection
  • No compression
  • No virtual server authentication
  • No support for HTTP pipelining
  • No TCP optimizations
Note: FastHTTP is optimized for ideal traffic conditions, but may not be an appropriate profile to use when network conditions are less than optimal. For more information about the FastHTTP profile, refer to SOL8024: Overview of the FastHTTP profile.

FastL4

Profile: FastL4

Advantage: Uses PVA to process packets

When to use: FastL4 is limited in functionality to socket level decisions (for example, src_ip:port dst_ip:port). Thus, you can use FastL4 only when socket level information for each connection is required for the virtual server.

Limitations:

  • No HTTP optimizations
  • No TCP optimizations for server offloading
  • SNAT/SNAT pools demote PVA acceleration setting level to Assisted
  • iRules limited to L4 events, such as CLIENT_ACCEPTED and SERVER_CONNECTED
  • No OneConnect
  • Source address or destination address based persistence only
  • No compression
  • No Virtual Server Authentication
  • No support for HTTP pipelining
張貼者： 於 沒有留言:
標籤：

SOL7595: Overview of IP forwarding virtual servers

SOL7595: Overview of IP forwarding virtual servers

Updated: 7/6/09 3:41 PM
Solution

IP forwarding virtual servers are similar to Layer 2 forwarding virtual servers because they do not have pool members to load balance. An IP forwarding virtual server forwards the packet directly to the destination IP address specified in the client request. Therefore, when the BIG-IP LTM system evaluates the packet for processing, the system looks only at the destination IP address.
For example, in the following configuration the host forwarding virtual server allows all service ports and all valid TCP/IP protocols to be forwarded from the external VLAN to the internal destination of 10.0.0.1:

virtual forward_vs {
destination 10.0.0.1:any
ip forward
translate address disable
vlans external enable

In the following configuration example, the network forwarding virtual server allows connections for service port 22 to be forwarded from the external VLAN to any host on the internal VLAN that resides in the 10.0.0.0/24 network:

virtual forward_vs {
destination 10.0.0.0:22
mask 255.255.255.0
ip forward
translate address disable
vlans external enable

Note: For information about Layer 2 forwarding virtual servers, refer to SOL4362: Overview of Layer 2 forwarding virtual servers.

An IP forwarding virtual server is useful when you want to configure the BIG-IP system to pass infrastructure-related traffic, such as ICMP traffic.

Creating an IP forwarding virtual server

To create an IP forwarding virtual server, perform the following procedure:

  1. Log in to the Configuration utility.
  2. Click Local Traffic.
  3. Click Virtual Servers.
  4. Click Create.
  5. Enter a name and an IP address for the virtual server.
  6. Select Forwarding (IP) from the Type drop-down box.
  7. Click Finished.

Note: For more information, refer to SOL5017: Overview of virtual server types.

Emulating stateless IP routing with BIG-IP LTM forwarding virtual servers

The TMOS based full-proxy model is stateful and connection-orientated by nature, in contrast to the stateless IP forwarding typically provided by L3 routers. The BIG-IP LTM must be specifically configured to more closely emulate a standard router's stateless routing behavior by adjusting the virtual server and protocol profile configurations to match your requirements.

For the closest approximation of stateless IP forwarding, F5 recommends creating an IP forwarding wildcard virtual similar to the following example:

virtual vs_wildcard_forwarding {
destination any:any
ip forward
vlans internal enable
profile my_route_friendly_fastl4
}

profile fastL4 route_friendly_fastl4 {
defaults from fastL4
reset on timeout disable
idle timeout 300
loose initiation enable
loose close enable ### Optional (see below) ###
}

This configuration accepts traffic arriving on the internal VLAN and forwards it using the information contained in the system routing table, regardless of whether it is associated with an established connection.

Note: The VLANs on which the forwarding virtual server is enabled may vary depending on your routing requirements and restrictions. The virtual server should be enabled on all VLANs from which it will accept and route traffic.

The FastL4 profile determines how the system handles the connection table entries. Enabling the Loose Initiation option allows the system to initialize a connection when it receives any TCP packet, rather than requiring a SYN packet for connection initiation. It also provides a good alternative to the high overhead of connection mirroring. In the event of a failover, with the Loose Initiation option enabled, the standby BIG-IP system will accept connections midflow and forward as expected. The Loose Close option allows the system to remove a connection when the system receives the first FIN packet from either the client or the server. This will help trim connection table entries as the connection entry can be removed as soon as the connection officially closes and the system need not maintain the connectin table entry.

Note: The Loose Close feature is optional, and may impact system performance since it disables PVA acceleration for the virtual server.

Setting the Idle Timeout allows connections to be removed from the connection table when they are no longer active. F5 Networks recommends using the default timeout of 300 seconds. By disabling Reset on Timeout, connection entries are removed from the connection table once the idle timeout expires, but does not reset the connection. Since this setting prevents the BIG-IP LTM from sending resets when closing an idle connection, it also helps reduce the need of using long idle timeouts for long-lived TCP connections, which may go idle for extended periods of time. For instance, if an application allows for long periods of inactivity (greater than the configured Idle Timeout) with no traffic being exchanged), without this setting, the BIG-IP LTM would close both sides of the connection upon expiration of the timeout. Any subsequent packets sent by the client or server in the same TCP connection would be rejected since the connection is no longer valid on the BIG-IP LTM. However, with Reset on Timeout disabled, the BIG-IP LTM will quietly remove the connection entry and neither the client or server will be aware the communication channel has timed out. When the client or server commences communicating again, the Loose Initiation setting allows the BIG-IP LTM to re-add the connection to the connection table, and the newly arrived packets are forwarded as expected.

Note: F5 Networks does not recommend setting the idle timeout for any virtual server to immediate or indefinite. Setting the timeout to immediate results in constant writing and deletion of connection entries for each datagram, creating undesirable overhead. Setting the timeout to indefinite (or to very large values) results in a connection table that grows until all available memory is consumed, and typically results in an unplanned failover upon memory exhaustion.

Some protocols have different requirements than others. In that case, a more specific virtual server allows you to control traffic handling for specific protocols. A protocol specific virtual can help keep connection table sizes down and if Last Hop is still used, help reduce stale Last Hop information for short-lived connections. For instance, UDP is less stateful than TCP, and does not typically require as long an idle timeout. To set a specific timeout for UDP traffic, you can create the wildcard forwarding virtual server described above, and a protocol-specific forwarding virtual server and profile similar to the following example:

virtual vs_wildcard_forwarding_udp {
destination any:any
ip forward
ip protocol udp
profile udp_fastL4
}

profile fastL4 udp_fastl4 {
defaults from fastL4
idle timeout 5
}

This virtual server only listens for UDP traffic. All other IP protocols will be processed by the more general wildcard forwarding virtual defined previously.

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

SOL9123: Recommended practices for deploying F5 Networks devices remotely

Updated: 7/22/09 3:07 PM
Solution

Note: This Solution only applies to BIG-IP platforms that contain a switch card control processor (SCCP). The BIG-IP platforms affected include the 1500, 3400, 4100, 6400, 6800, 8400, and 8800 platforms.

When deploying devices remotely, F5 Networks recommends the following remote administrative practices:

Configuring serial console access to the unit

Serial console access provides the most highly available method of access to the device. In the event that network access is impaired, the serial console may be the only way to access the device. F5 Networks recommends that you perform all installations and upgrades using the serial console. These procedures require reboots; therefore, network connectivity will be temporarily lost. Performing upgrades and installations using the console allows you to accurately track the progress of the installation, and help prevent interruptions. Additionally, the serial console is the most robust method to secure access during configuration lockout situations.

Note: For diagnostic purposes, F5 Networks may request serial console output. Some system events that do not log to the file system may log to the serial console.

Console access is provided by a terminal server, which usually contains several serial interfaces used to connect to the serial console outputs of devices. These devices typically consist of a PC with a single or multi-port serial interface card, or specialized hardware made for this specific purpose. Consult your Solution's documentation for assistance with the configuration.

Note: For more information about which settings are required for accessing the serial console, refer to SOL7683: Connecting a serial terminal to a BIG-IP system.

A null modem cable is required to connect to the serial console.

Note: For more information about the serial terminal cable requirements, refer to SOL587: Pinouts for serial terminal cables used to connect to F5 products.

Important: The failover cable provided with redundant BIG-IP systems has custom pinouts and cannot be used for connecting to the serial terminal on a BIG-IP system.

Configuring the management port on a separate secure management network

F5 Networks recommends configuring the management on a secure management network. The management port is the only port that is PXE enabled; therefore, it is vital to any recovery attempts. In addition, access to the management port is completely separate, and is not reliant on the Traffic Management Microkernel (TMM) or the main switchboard, which can be useful in certain troubleshooting situations.

Note: For more information, refer to SOL7312: Overview of the management port.

Configuring the SCCP with an additional IP address on the same network as the management port

F5 Networks recommends that you allocate an additional IP address on the same network as the management port for the SCCP. If providing serial console access through a console server is unattainable, F5 Networks recommends configuring an IP address for the SCCP. In the event that the host system becomes unreachable, but network connectivity using the management network is still available, you may gain partial access to the unit using the SCCP. At this point, you can perform a number of important recovery actions using the hostconsh command.

Note: For more information, refer to SOL3454: Overview of the SCCP and SOL3753: Configuring the switch card control processor so that it can be accessed over the network.

Note: For more information, refer to the BIG-IP Network and System Management Guide for your platform.

Configuring a PXE server on the management network

In the event of an unrecoverable file system or image corruption, F5 Networks may request a clean installation of the operating system. If the device is located remotely and someone is not readily available with a USB device, a PXE installation is a fast, reliable way to provide installation services.

Important: F5 Networks does not support the setup or use of any commercial PXE solutions. Consult your Solution's documentation and test thoroughly before deploying.

Note: The PXE installation requires a second machine other than the BIG-IP device to perform the installation. The second machine boots off of a CD created using the BIG-IP ISO image to provide an installation server for the BIG-IP device to access. Usually, this second machine is a laptop or other device on the network, but if the BIG-IP device is remotely located, you may use a generic VMWare Linux host image. The VMWare Linux host image’s interface is bridged to the management network, which can then be dynamically brought up and down as needed. Using a VMware host also allows you to mount and boot from the ISO images directly without having to burning a CD first.

Note: For detailed information about performing a clean installation, refer to the BIG-IP LTM, ASM, GTM, Link Controller, or WebAccelerator Release Notes for the version you are installing.

Note: For more information, refer to SOL3525: Configuring the BIG-IP LTM, GTM, or ASM to boot from a network boot server and SOL3359: Network interface cards supported by the F5 Networks PXE network boot server.

For additional questions about providing the types of services described in this Solution, contact F5 Networks Professional Services.

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

SOL9476: The F5 Networks hardware / software compatibility matrix

Updated: 7/21/09 1:16 PM
Solution

The tables in this Solution list the product software versions, and the latest SCCP, AOM, and EUD versions supported by F5 Networks hardware platforms. The table headings are described as follows:

  • Platform: F5 platform marketing name
  • Type: F5 platform ID
  • Software versions: BIG-IP Software versions supported by the platform (oldest through newest)
  • SCCP: The latest version of SCCP firmware supported by the platform
  • AOM: The latest version of AOM firmware supported by the platform
  • EUD: The latest version of EUD supported by the platform

BIG-IP platforms

Platform Type Software versions SCCP AOM EUD
520 D35 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
540 D35 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
1000 D39 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
2400 D44 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
5100 D51 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
5110 D51 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7 N/A N/A N/A
1500 C36 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
1600 C102 9.4.5 - 9.4.7, 10.0.0 - 10.0.1 N/A 10.1.2 12.3
3400 C62 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
3410 C100 9.4.2 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
3600 C103 9.4.5 - 9.4.7, 10.0.0 - 10.0.1 N/A 10.1.2 12.3
6400 D63 9.0 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
6800 D68 9.0.4 - 9.1.3, 9.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
6900 D104 9.4.6 - 9.4.7, 10.0.0 - 10.0.1 N/A 10.1.2
12.3
8400 D84 9.2.2 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
8800 D88 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1
8900 D106 9.4.7, 10.0.0 - 10.0.1 N/A 10.1.2 12.3
VIPRION J100 9.6 - 9.6.1, 10.0.0 - 10.0.1 12.0.6 N/A 11.1

FirePass platforms

Platform Type Software versions SCCP AOM EUD
600 B10 5.2.2, 5.4.2 N/A N/A N/A
1000 C20 4.0 - 4.1.1, 5.0, 5.2 - 5.2.2, 5.4 - 5.4.2, 5.5 - 5.5.2, 6.0 - 6.0.3 N/A N/A N/A
1200 C21 5.5.1 - 5.5.2, 6.0 - 6.0.3 N/A N/A 11.0.3
4000 D37 4.0 - 4.1.1, 5.0, 5.2 - 5.2.2, 5.4 - 5.4.2, 5.5 - 5.5.2, 6.0 - 6.0.1 N/A N/A N/A
4100 D46 5.2 - 5.2.2, 5.4 - 5.4.2, 5.5 - 5.5.2, 6.0 - 6.0.3 12.0.6 N/A 11.1
4300 D101 6.0.1 - 6.0.3 12.0.6 N/A 11.0.3

WebAccelerator platforms

Platform Type Software versions SCCP AOM EUD
4500 D43 9.4.2 - 9.4.7, 10.0.0 - 10.0.1 N/A N/A 10.1

WANJet platforms

Platform Type Software versions SCCP AOM EUD
200 B20 3.1 - 3.1.2.0, 3.3.2, 4.0 - 2.0.18, 4.2 - 4.2.8 N/A N/A N/A
300 C25 5.0 - 5.0.2 N/A N/A 10.1
400 D41 3.1 - 3.1.2.0, 3.3.2, 4.0 - 4.0.18, 4.2 - 4.2.8, 5.0 - 5.0.2 N/A N/A N/A
500 D100 4.2.4 - 4.2.8, 5.0 - 5.0.2 N/A N/A 10.1

Enterprise Manager platforms

Platform Type Software versions SCCP AOM EUD
500 C36 1.0, 1.2 - 1.2.2, 1.4 - 1.4.1, 1.6, 1.7 12.0.6 N/A 11.0.3
3000 D38 1.2 - 1.2.2, 1.4 - 1.4.1, 1.6, 1.7 N/A N/A 10.1

Secure Access Manager platforms

Platform Type Software versions SCCP AOM EUD
4300 D101 8.0 12.0.6 N/A 11.1

Application Security Manager platforms

Platform Type Software versions SCCP AOM EUD
4100 D46 9.2.4 - 9.2.5, 9.3 - 9.3.1, 9.4 - 9.4.7, 10.0.0 - 10.0.1 12.0.6 N/A 11.1

ARX platforms

Platform Type Software versions SCCP AOM EUD
500
2.7.0 - 2.7.1, 3.2.1 - 3.2.2, 4.0.1 - 4.1.0 N/A N/A N/A
1000
2.7.0 - 2.7.1, 3.2.1 - 3.2.2, 4.0.1 - 4.1.0 N/A N/A N/A
4000
4.0.1 - 4.1.0 N/A N/A N/A
6000
2.7.0 - 2.7.1, 3.2.1 - 3.2.2, 4.0.1 - 4.1.0 N/A N/A N/A
張貼者： 於 沒有留言:
標籤：

SOL9502: BIG-IP hotfix matrix

Updated: 7/22/09 1:58 PM
Solution

The following table lists the latest available hotfix for the corresponding BIG-IP release. The hotfixes are available for download at the F5 Networks Downloads site, or by clicking on the Latest Hotfix link in the table.

BIG-IP Release Latest Hotfix Solution
9.1.1 hotfix-cr69440 N/A
9.1.2 Hotfix-BIG-IP-9.1.2-HF8.im SOL7672
9.1.3 Hotfix-BIG-IP-9.1.3-HF1 SOL8286
9.3 Hotfix-BIG-IP-9.3.0-HF3 SOL9519
9.3.1 Hotfix-BIGIP-9.3.1-69.0-HF6 SOL9794
9.4 Hotfix-BIG-IP-9.4.0-HF4 SOL7839
9.4.1 Hotfix-BIGIP-9.4.1-HF2 SOL9510
9.4.2 None N/A
9.4.3 Hotfix-BIG-IP-9.4.3-HF4 SOL9505
9.4.4 Hotfix BIGIP-9.4.4-94.0-HF3 SOL9092
9.4.5 Hotfix-BIG-IP-9.4.5-HF2 SOL9355
9.4.6 None N/A
9.4.7 None N/A
9.6.1 BIGIP-9.6.1-839.0-HF3 SOL9963
10.0.0 Hotfix-BIGIP-10.0.0-5514.0-HF2 SOL9992
10.0.1 None N/A

For information about downloading software from F5 Networks, refer to SOL167: Downloading software from F5 Networks.

For information about installing a hotfix for version 10.x systems, refer to SOL10025: Managing F5 Networks product hotfixes for BIG-IP version 10.x systems.

For information about installing a hotfix for version 9.x systems, refer to SOL6845: Managing F5 Networks product hotfixes for BIG-IP version 9.x systems.

For information about F5 Networks hotfix policy, refer to SOL4918: Overview of F5 Networks critical issue hotfix policy.

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

Ask F5 - Added and updated documents from 7/19 through 7/25

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
張貼者： 於 沒有留言:
標籤：

中央不幫世運 陳菊感謝「獨漏」

中央不幫世運 陳菊感謝「獨漏」

更新日期:2009/07/28 00:01

2009年高雄世運圓滿落幕，國際世運總會主席朗佛契稱讚這是舉辦最好的一次世運，不居功的高雄市長陳菊感謝各界大力相挺，獨獨沒感謝中央，陳菊接受民視獨家專訪時，道出高雄舉辦世運的辛酸，以及遭到中央不友善對待時，他們如何的自立自強。

國際世運總會主席朗佛契的這番話，讓全台灣的民眾於有榮焉，而對高雄市長陳菊來說，這份榮耀，是屬於大家的，感謝各界支持大力相挺，陳菊獨獨沒感謝中央。

台灣第一次舉辦，規模僅次於奧運的大型國際運動會，陳菊一路走來，嚐遍人間冷暖，甚至，開幕在即，中央還急砍世運預算，8億砍了2億。

絢爛的焰火為2009年世運畫下句點，風光落幕的背後，卻是國家領導人缺席，中央處處刁難地方，台灣在國際舞台上，最成功的一次外交，卻露出中央扯後腿的馬腳。

張貼者： 於 沒有留言:
標籤：
訂閱： 文章 (Atom)

追蹤者