The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Enhanced Object Tracking (EOT) is not stateful switchover (SSO)-aware and cannot be used with GLBP in SSO mode.
Prerequisites for GLBP
Before configuring GLBP, ensure that the devices can support multiple MAC addresses on the physical interfaces. For each GLBP
forwarder to be configured, an additional MAC address is used.
Information About GLBP
GLBP Overview
GLBP provides automatic device backup for IP hosts configured with a single default gateway on an IEEE 802.3 LAN. Multiple
first-hop devices on the LAN combine to offer a single virtual first-hop IP device while sharing the IP packet forwarding
load. Other devices on the LAN act as redundant GLBP devices that will become active if any of the existing forwarding devices
fail.
GLBP performs a similar function for the user as HSRP and VRRP. HSRP and VRRP allow multiple devices to participate in a virtual
device group configured with a virtual IP address. One member is elected to be the active device to forward packets sent to
the virtual IP address for the group. The other devices in the group are redundant until the active device fails. These standby
devices have unused bandwidth that the protocol is not using. Although multiple virtual device groups can be configured for
the same set of devices, the hosts must be configured for different default gateways, which results in an extra administrative
burden. The advantage of GLBP is that it additionally provides load balancing over multiple devices (gateways) using a single
virtual IP address and multiple virtual MAC addresses. The forwarding load is shared among all devices in a GLBP group rather
than being handled by a single device while the other devices stand idle. Each host is configured with the same virtual IP
address, and all devices in the virtual device group participate in forwarding packets. GLBP members communicate between each
other through hello messages sent every 3 seconds to the multicast address 224.0.0.102, UDP port 3222 (source and destination).
GLBP Packet Types
GLBP uses 3 different packet types to operate. The packet types are Hello, Request, and Reply. The Hello packet is used to
advertise protocol information. Hello packets are multicast, and are sent when any virtual gateway or virtual forwarder is
in Speak, Standby or Active state. Request and Reply packets are used for virtual MAC assignment. They are both unicast messages
to and from the active virtual gateway (AVG).
GLBP Active Virtual Gateway
Members of a GLBP group elect one gateway to be the active virtual gateway (AVG) for that group. Other group members provide
backup for the AVG if the AVG becomes unavailable. The AVG assigns a virtual MAC address to each member of the GLBP group.
Each gateway assumes responsibility for forwarding packets sent to the virtual MAC address assigned to it by the AVG. These
gateways are known as active virtual forwarders (AVFs) for their virtual MAC address.
The AVG is also responsible for answering Address Resolution Protocol(ARP) requests for the virtual IP address. Load sharing
is achieved by the AVG replying to the ARP requests with different virtual MAC addresses.
When the noglbpload-balancingcommand is configured, if the AVG does not have an AVF, it preferentially responds to ARP requests with the MAC address of
the first listening virtual forwarder (VF), which will causes traffic to route via another gateway until that VF migrates
back to being the current AVG.
In the figure below, Router A (or Device A) is the AVG for a GLBP group, and is responsible for the virtual IP address 10.21.8.10.
Router A is also an AVF for the virtual MAC address 0007.b400.0101. Router B (or Device B) is a member of the same GLBP group
and is designated as the AVF for the virtual MAC address 0007.b400.0102. Client 1 has a default gateway IP address of 10.21.8.10
and a gateway MAC address of 0007.b400.0101. Client 2 shares the same default gateway IP address but receives the gateway
MAC address 0007.b400.0102 because Router B is sharing the traffic load with Router A.
Figure 1. GLBP Topology
If Router A becomes unavailable, Client 1 will not lose access to the WAN because Router B will assume responsibility for
forwarding packets sent to the virtual MAC address of Router A, and for responding to packets sent to its own virtual MAC
address. Router B will also assume the role of the AVG for the entire GLBP group. Communication for the GLBP members continues
despite the failure of a device in the GLBP group.
GLBP Virtual MAC Address Assignment
A GLBP group allows up to four virtual MAC addresses per group. The AVG is responsible for assigning the virtual MAC addresses
to each member of the group. Other group members request a virtual MAC address after they discover the AVG through hello messages.
Gateways are assigned the next MAC address in sequence. A virtual forwarder that is assigned a virtual MAC address by the
AVG is known as a primary virtual forwarder. Other members of the GLBP group learn the virtual MAC addresses from hello messages.
A virtual forwarder that has learned the virtual MAC address is referred to as a secondary virtual forwarder.
GLBP Virtual Gateway Redundancy
GLBP operates virtual gateway redundancy in the same way as HSRP. One gateway is elected as the AVG, another gateway is elected
as the standby virtual gateway, and the remaining gateways are placed in a listen state.
If an AVG fails, the standby virtual gateway will assume responsibility for the virtual IP address. A new standby virtual
gateway is then elected from the gateways in the listen state.
GLBP Virtual Forwarder Redundancy
Virtual forwarder redundancy is similar to virtual gateway redundancy with an AVF. If the AVF fails, one of the secondary
virtual forwarders in the listen state assumes responsibility for the virtual MAC address.
The new AVF is also a primary virtual forwarder for a different forwarder number. GLBP migrates hosts away from the old forwarder
number using two timers that start as soon as the gateway changes to the active virtual forwarder state. GLBP uses the hello
messages to communicate the current state of the timers.
The redirect time is the interval during which the AVG continues to redirect hosts to the old virtual forwarder MAC address.
When the redirect time expires, the AVG stops using the old virtual forwarder MAC address in ARP replies, although the virtual
forwarder will continue to forward packets that were sent to the old virtual forwarder MAC address.
The secondary holdtime is the interval during which the virtual forwarder is valid. When the secondary holdtime expires, the
virtual forwarder is removed from all gateways in the GLBP group. The expired virtual forwarder number becomes eligible for
reassignment by the AVG.
GLBP Gateway Priority
GLBP gateway priority determines the role that each GLBP gateway plays and what happens if the AVG fails.
Priority also determines if a GLBP device functions as a backup virtual gateway and the order of ascendancy to becoming an
AVG if the current AVG fails. You can configure the priority of each backup virtual gateway with a value of 1 through 255
using the glbppriority command.
In the "GLBP Topology" figure, if Router A (or Device A)—the AVG in a LAN topology—fails, an election process takes place
to determine which backup virtual gateway should take over. In this example, Router B (or Device B) is the only other member
in the group so it will automatically become the new AVG. If another device existed in the same GLBP group with a higher priority,
then the device with the higher priority would be elected. If both devices have the same priority, the backup virtual gateway
with the higher IP address would be elected to become the active virtual gateway.
By default, the GLBP virtual gateway preemptive scheme is disabled. A backup virtual gateway can become the AVG only if the
current AVG fails, regardless of the priorities assigned to the virtual gateways. You can enable the GLBP virtual gateway
preemptive scheme using the glbppreempt command. Preemption allows a backup virtual gateway to become the AVG, if the backup virtual gateway is assigned a higher
priority than the current AVG.
GLBP Gateway Weighting and Tracking
GLBP uses a weighting scheme to determine the forwarding capacity of each device in the GLBP group. The weighting assigned
to a device in the GLBP group can be used to determine whether it will forward packets and, if so, the proportion of hosts
in the LAN for which it will forward packets. Thresholds can be set to disable forwarding when the weighting for a GLBP group
falls below a certain value, and when it rises above another threshold, forwarding is automatically reenabled.
The GLBP group weighting can be automatically adjusted by tracking the state of an interface within the device. If a tracked
interface goes down, the GLBP group weighting is reduced by a specified value. Different interfaces can be tracked to decrement
the GLBP weighting by varying amounts.
By default, the GLBP virtual forwarder preemptive scheme is enabled with a delay of 30 seconds. A backup virtual forwarder
can become the AVF if the current AVF weighting falls below the low weighting threshold for 30 seconds. You can disable the
GLBP forwarder preemptive scheme using the noglbpforwarderpreempt command or change the delay using the glbpforwarderpreemptdelayminimum command.
GLBP MD5 Authentication
GLBP MD5 authentication uses the industry-standard MD5 algorithm for improved reliability and security. MD5 authentication
provides greater security than the alternative plain text authentication scheme and protects against spoofing software.
MD5 authentication allows each GLBP group member to use a secret key to generate a keyed MD5 hash that is part of the outgoing
packet. A keyed hash of an incoming packet is generated and, if the hash within the incoming packet does not match the generated
hash, the packet is ignored.
The key for the MD5 hash can either be given directly in the configuration using a key string or supplied indirectly through
a key chain. The key string cannot exceed 100 characters in length.
A device will ignore incoming GLBP packets from devices that do not have the same authentication configuration for a GLBP
group. GLBP has three authentication schemes:
No authentication
Plain text authentication
MD5 authentication
GLBP packets will be rejected in any of the following cases:
The authentication schemes differ on the device and in the incoming packet.
MD5 digests differ on the device and in the incoming packet.
Text authentication strings differ on the device and in the incoming packet.
ISSU-GLBP
GLBP supports In Service Software Upgrade (ISSU). ISSU allows a high-availability (HA) system to run in Stateful Switchover
(SSO) mode even when different versions of Cisco IOS software are running on the active and standby Route Processors (RPs)
or line cards.
ISSU provides the ability to upgrade or downgrade from one supported Cisco IOS release to another while continuing to forward
packets and maintain sessions, thereby reducing planned outage time. The ability to upgrade or downgrade is achieved by running
different software versions on the active RP and standby RP for a short period of time to maintain state information between
RPs. This feature allows the system to switch over to a secondary RP running upgraded (or downgraded) software and continue
forwarding packets without session loss and with minimal or no packet loss. This feature is enabled by default.
GLBP SSO
With the introduction of the GLBP SSO functionality, GLBP is stateful switchover (SSO) aware. GLBP can detect when a device
is failing over to the secondary router processor (RP) and continue in its current group state.
SSO functions in networking devices (usually edge devices) that support dual RPs. SSO provides RP redundancy by establishing
one of the RPs as the active processor and the other RP as the standby processor. SSO also synchronizes critical state information
between the RPs so that network state information is dynamically maintained between RPs.
Without SSO-awareness, if GLBP is deployed on a device with redundant RPs, a switchover of roles between the active RP and
the standby RP results in the device relinquishing its activity as a GLBP group member and then rejoining the group as if
it had been reloaded. The GLBP SSO feature enables GLBP to continue its activities as a group member during a switchover.
GLBP state information between redundant RPs is maintained so that the standby RP can continue the device’s activities within
the GLBP during and after a switchover.
This feature is enabled by default. To disable this feature, use the command noglbpsso in global configuration mode.
GLBP Benefits
Load Sharing
You can configure GLBP in such a way that traffic from LAN clients can be shared by multiple devices, thereby sharing the
traffic load more equitably among available devices.
Multiple Virtual Devices
GLBP supports up to 1024 virtual devices (GLBP groups) on each physical interface of a device and up to four virtual forwarders
per group.
Preemption
The redundancy scheme of GLBP enables you to preempt an active virtual gateway (AVG) with a higher priority backup virtual
gateway that has become available. Forwarder preemption works in a similar way, except that forwarder preemption uses weighting
instead of priority and is enabled by default.
Authentication
GLBP supports the industry-standard message digest 5 (MD5) algorithm for improved reliability, security, and protection against
GLBP-spoofing software. A device within a GLBP group with a different authentication string than other devices will be ignored
by other group members. You can alternatively use a simple text password authentication scheme between GLBP group members
to detect configuration errors.
How to Configure GLBP
Customizing GLBP
Customizing the behavior of GLBP is optional. Be aware that as soon as you enable a GLBP group, that group is operating.
It is possible that if you first enable a GLBP group before customizing GLBP, the device could take over control of the group
and become the AVG before you have finished customizing the feature. Therefore, if you plan to customize GLBP, it is a good
idea to do so before enabling GLBP.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Device(config)# interface GigabitEthernet 1/0/1
Specifies an interface type and number, and enters interface configuration mode.
Step 4
ipaddressip-addressmask [secondary]
Example:
Device(config-if)# ip address 10.21.8.32 255.255.255.0
Specifies a primary or secondary IP address for an interface.
Step 5
glbpgrouptimers [msec] hellotime [msec] holdtime
Example:
Device(config-if)# glbp 10 timers 5 18
Configures the interval between successive hello packets sent by the AVG in a GLBP group.
The holdtime argument specifies the interval in seconds before the virtual gateway and virtual forwarder information in the hello packet
is considered invalid.
The optional msec keyword specifies that the following argument will be expressed in milliseconds, instead of the default seconds.
Configures the time interval during which the AVG continues to redirect clients to an AVF. The default is 600 seconds (10
minutes).
The timeout argument specifies the interval in seconds before a secondary virtual forwarder becomes invalid. The default is 14,400 seconds
(4 hours).
Note
The zero value for the redirect argument cannot be removed from the range of acceptable values because preexisting configurations of Cisco IOS software already
using the zero value could be negatively affected during an upgrade. However, a zero setting is not recommended and, if used,
results in a redirect timer that never expires. If the redirect timer does not expire, and the device fails, new hosts continue
to be assigned to the failed device instead of being redirected to the backup.
Configures the device to take over as AVG for a GLBP group if it has a higher priority than the current AVG.
This command is disabled by default.
Use the optional delay and minimum keywords and the seconds argument to specify a minimum delay interval in seconds before preemption of the AVG takes place.
Device(config-if)# glbp 10 client-cache maximum 1200 timeout 245
(Optional) Enables the GLBP client cache.
This command is disabled by default.
Use the number argument to specify the maximum number of clients the cache will hold for this GLBP group. The range is from 8 to 2000.
Use the optional timeoutminutes keyword and argument pair to configure the maximum amount of time a client entry can stay in the GLBP client cache after
the client information was last updated. The range is from 1 to 1440 minutes (one day).
Note
For IPv4 networks, Cisco recommends setting a GLBP client cache timeout value that is slightly longer than the maximum expected
end-host Address Resolution Protocol (ARP) cache timeout value.
Step 11
glbpgroupnameredundancy-name
Example:
Device(config-if)# glbp 10 name abc123
Enables IP redundancy by assigning a name to the GLBP group.
The GLBP redundancy client must be configured with the same GLBP group name so the redundancy client and the GLBP group can
be connected.
Step 12
exit
Example:
Device(config-if)# exit
Exits interface configuration mode, and returns the device to global configuration mode.
Step 13
noglbpsso
Example:
Device(config)# no glbp sso
(Optional) Disables GLBP support of SSO.
Configuring GLBP MD5 Authentication Using a Key String
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Device(config)# interface GigabitEthernet 1/0/1
Configures an interface type and enters interface configuration mode.
Step 4
ipaddressip-addressmask [secondary]
Example:
Device(config-if)# ip address 10.0.0.1 255.255.255.0
Specifies a primary or secondary IP address for an interface.
Configures an authentication key for GLBP MD5 authentication.
The key string cannot exceed 100 characters in length.
No prefix to the key argument or specifying 0 means the key is unencrypted.
Specifying 7 means the key is encrypted. The key-string authentication key will automatically be encrypted if the servicepassword-encryption global configuration command is enabled.
Step 6
glbpgroup-numberip [ip-address [secondary]]
Example:
Device(config-if)# glbp 1 ip 10.0.0.10
Enables GLBP on an interface and identifies the primary IP address of the virtual gateway.
Step 7
Repeat Steps 1 through 6 on each device that will communicate.
—
Step 8
end
Example:
Device(config-if)# end
Returns to privileged EXEC mode.
Step 9
showglbp
Example:
Device# show glbp
(Optional) Displays GLBP information.
Use this command to verify your configuration. The key string and authentication type will be displayed if configured.
Configuring GLBP MD5 Authentication Using a Key Chain
Perform this task to configure GLBP MD5 authentication using a key chain. Key chains allow a different key string to be used
at different times according to the key chain configuration. GLBP will query the appropriate key chain to obtain the current
live key and key ID for the specified key chain.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
keychainname-of-chain
Example:
Device(config)# key chain glbp2
Enables authentication for routing protocols and identifies a group of authentication keys and enters key-chain configuration
mode.
Step 4
keykey-id
Example:
Device(config-keychain)# key 100
Identifies an authentication key on a key chain.
The value for the key-id argument must be a number.
Step 5
key-stringstring
Example:
Device(config-keychain-key)# key-string abc123
Specifies the authentication string for a key and enters key-chain key configuration mode.
The value for the string argument can be 1 to 80 uppercase or lowercase alphanumeric characters; the first character cannot be a numeral.
Step 6
exit
Example:
Device(config-keychain-key)# exit
Returns to key-chain configuration mode.
Step 7
exit
Example:
Device(config-keychain)# exit
Returns to global configuration mode.
Step 8
interfacetypenumber
Example:
Device(config)# interface GigabitEthernet 1/0/1
Configures an interface type and enters interface configuration mode.
Step 9
ipaddressip-addressmask [secondary]
Example:
Device(config-if)# ip address 10.21.0.1 255.255.255.0
Specifies a primary or secondary IP address for an interface.
Text authentication provides minimal security. Use MD5 authentication if security is required.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Device(config)# interface GigabitEthernet 1/0/1
Configures an interface type and enters interface configuration mode.
Step 4
ipaddressip-addressmask [secondary]
Example:
Device(config-if)# ip address 10.0.0.1 255.255.255.0
Specifies a primary or secondary IP address for an interface.
Step 5
glbpgroup-numberauthenticationtextstring
Example:
Device(config-if)# glbp 10 authentication text stringxyz
Authenticates GLBP packets received from other devices in the group.
If you configure authentication, all devices within the GLBP group must use the same authentication string.
Step 6
glbpgroup-numberip [ip-address [secondary]]
Example:
Device(config-if)# glbp 1 ip 10.0.0.10
Enables GLBP on an interface and identifies the primary IP address of the virtual gateway.
Step 7
Repeat Steps 1 through 6 on each device that will communicate.
—
Step 8
end
Example:
Device(config-if)# end
Returns to privileged EXEC mode.
Step 9
showglbp
Example:
Device# show glbp
(Optional) Displays GLBP information.
Use this command to verify your configuration.
Configuring GLBP Weighting Values and Object Tracking
GLBP weighting is used to determine whether a GLBP group can act as a virtual forwarder. Initial weighting values can be
set and optional thresholds specified. Interface states can be tracked and a decrement value set to reduce the weighting value
if the interface goes down. When the GLBP group weighting drops below a specified value, the group will no longer be an active
virtual forwarder. When the weighting rises above a specified value, the group can resume its role as an active virtual forwarder.
Device(config)# track 2 interface GigabitEthernet 1/0/1 ip routing
Configures an interface to be tracked where changes in the state of the interface affect the weighting of a GLBP gateway,
and enters tracking configuration mode.
This command configures the interface and corresponding object number to be used with the glbpweightingtrack command.
The line-protocol keyword tracks whether the interface is up. The iprouting keywords also check that IP routing is enabled on the interface, and an IP address is configured.
Configures the device to take over as AVF for a GLBP group if the current AVF for a GLBP group falls below its low weighting
threshold.
This command is enabled by default with a delay of 30 seconds.
Use the optional delay and minimum keywords and the seconds argument to specify a minimum delay interval in seconds before preemption of the AVF takes place.
GLBP introduces five privileged EXEC mode commands to enable display of diagnostic output concerning various events relating
to the operation of GLBP. The debugconditionglbp,debugglbperrors, debugglbpevents,debugglbppackets, and debugglbpterse commands are intended only for troubleshooting purposes because the volume of output generated by the software can result
in severe performance degradation on the device. Perform this task to minimize the impact of using the debugglbp commands.
This procedure will minimize the load on the device created by the debugconditionglbpor debugglbp command because the console port is no longer generating character-by-character processor interrupts. If you cannot connect
to a console directly, you can run this procedure via a terminal server. If you must break the Telnet connection, however,
you may not be able to reconnect because the device may be unable to respond due to the processor load of generating the debugging
output.
Before you begin
This task requires a device running GLBP to be attached directly to a console.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
nologgingconsole
Example:
Device(config)# no logging console
Disables all logging to the console terminal.
To reenable logging to the console, use theloggingconsole command in global configuration mode.
Step 4
Use Telnet to access a device port and repeat Steps 1 and 2.
Enters global configuration mode in a recursive Telnet session, which allows the output to be redirected away from the console
port.
Displays debugging messages about GLBP conditions.
Try to enter only specific debugconditionglbp or debugglbp commands to isolate the output to a certain subcomponent and minimize the load on the processor. Use appropriate arguments
and keywords to generate more detailed debug information on specified subcomponents.
Enter the specific nodebugconditionglbp or nodebugglbp command when you are finished.
Device(config)# interface GigabitEthernet 0/0/0
Device(config-if)# ip address 10.21.8.32 255.255.255.0
Device(config-if)# glbp 10 authentication text stringxyz
Device(config-if)# glbp 10 ip 10.21.8.10
Example: Configuring GLBP Weighting
In the following example, the device is configured to track the IP routing state of the POS interface 5/0/0 and 6/0/0, an
initial GLBP weighting with upper and lower thresholds is set, and a weighting decrement value of 10 is set. If POS interface
5/0/0 and 6/0/0 go down, the weighting value of the device is reduced.
In the following example, the device is configured to enable GLBP, and the virtual IP address of 10.21.8.10 is specified
for GLBP group 10:
Device(config)# interface GigabitEthernet 0/0/0
Device(config-if)# ip address 10.21.8.32 255.255.255.0
Device(config-if)# glbp 10 ip 10.21.8.10
Additional References for GLBP
Related Documents
Related Topic
Document Title
For complete syntax and usage information for the commands used in this chapter.
See the IP Multicast Routing Commands section of the Command Reference (Catalyst 9400 Series Switches)
Feature History for GLBP
This table provides release and related information for the features explained in this module.
These features are available in all the releases subsequent to the one they were introduced in, unless noted otherwise.
Release
Feature
Feature Information
Cisco IOS XE Gibraltar 16.12.1
Gateway Load Balancing Protocol
GLBP protects data traffic from a failed router or circuit, like HSRP and VRRP, while allowing packet load sharing between
a group of redundant routers.
GLBP MD5 Authentication
MD5 authentication provides greater security than the alternative plain text authentication scheme. MD5 authentication allows
each GLBP group member to use a secret key to generate a keyed MD5 hash that is part of the outgoing packet. A keyed hash
of an incoming packet is generated and, if the hash within the incoming packet does not match the generated hash, the packet
is ignored.
SSO—GLBP
GLBP is now SSO aware. GLBP can detect when a router is failing over to the secondary RP and continue in its current GLBP
group state.
Prior to being SSO aware, GLBP was not able to detect that a second RP was installed and configured to take over in the event
that the primary RP failed. When the primary failed, the GLBP device would stop participating in the GLBP group and, depending
on its role, could trigger another router in the group to take over as the active router. With this enhancement, GLBP detects
the failover to the secondary RP and no change occurs to the GLBP group. If the secondary RP fails and the primary is still
not available, then the GLBP group detects this and re-elects a new active GLBP router.
Cisco IOS XE Cupertino 17.7.1
Gateway Load Balancing Protocol
GLBP MD5 Authentication
SSO—GLBP
These features were implemented on supervisor modules C9400X-SUP-2 and C9400X-SUP-2XL, which were introduced in this release.
Use the Cisco Feature Navigator to find information about platform and software image support.
Feedback