ISR Computing -
Content Switching Module Device Management via SNMP and XML
| Method | Description | Comments |
|---|---|---|
| Command Line Interface | The CSM CLI is part of the Catalyst 6500/7600 MSFC CLI. As such, it can be accessed via Telnet or via SSH. | 100% feature support Leverages all IOS CLI features: command aliases, privilege levels, AAA Radius/TACACS+, etc… |
| SNMP/MIB | Two dedicated MIB’s are available to monitor the CSM. SNMP runs on the Catalyst 6500/7600 MSFC, so the MIB’s are accessed via MSFC management IP addresses. | Standard, read-only MIB’s. Not all counters are currently (CSM 4.2) supported, in particular IXP utilization counters are not yet implemented. |
| XML API | The CSM accepts XML commands (described in a DTD) for configuration and monitoring tasks. The XML commands are embedded in HTTP or HTTPS POST messages, and are sent directly to a CSM management IP address. | Full support for configuration commands. Return error codes provide feedback on the success of the XML commands. Limited (as of 4.2) support for show commands. |
| Cisco View Device Manager | Embedded device manager, about 1.5MB footprint, loaded on the Catalyst flash. Integrated in the Catalyst CVDM, is launched in a browser (Java Machine required) and communicates in the back-end with the CSM via Telnet or SSH. | Free, single device manager. Excellent feature support for configuration. Limited monitoring capabilities. Step-by-step wizards. Can provide a text file with the CLI configuration changes. |
| Hosting Solution Engine | Server based multi-device manager, with role based access and domain support to delegate specific actions to different groups of users. Back-end interaction with the managed CSM’s via SNMP and XML API. | Multi device manager. Integrates with AAA groups. Limited feature support, recommended for day-to-day operations (servers in/out of rotation, new real or virtual servers, etc..) rather than for complete CSM configuration. Excellent virtualization, across multiple devices, with restrictions on actions. Excellent reporting capabilities. |
SNMP and MIB’s
THE CSM MIB’S
The CSM specific counters are included in 2 dedicated MIB’s:
| MIB | OID | Full Path |
|---|---|---|
| CISCO-SLB-MIB | 1.3.6.1.4.1.9.9.161 | iso(1).org(3).dod(6).internet(1).private(4). enterprises(1).cisco(9).ciscoMgmt(9).ciscoSlbMIB(161) |
| CISCO-SLB-EXT-MIB | 1.3.6.1.4.1.9.9.254 | iso(1).org(3).dod(6).internet(1).private(4). enterprises(1).cisco(9).ciscoMgmt(9).ciscoSlbExtMIB(254) |
The following 2 pictures illustrate the main structure of the 2 MIB’s:
SNMP Configuration
Since the CSM relies on the IOS SNMP support, you configure SNMP directly from the MSFC CLI, with the following commands:
Catalyst6k#conf t Enter configuration commands, one per line. End with CNTL/Z. Catalyst6k(config)#snmp-server ? chassis-id String to uniquely identify this chassis community Enable SNMP; set community string and access privs contact Text for mib object sysContact context Create/Delete a context apart from default enable Enable SNMP Traps or Informs engineID Configure a local or remote SNMPv3 engineID group Define a User Security Model group host Specify hosts to receive SNMP notifications <-- snipped -->
All the examples that follow assume that the IOS cofiguration includes the command:
snmp-server community public RO
How to interpret the MIB’S
Let’s consider the following simple CSM configuration:
module ContentSwitchingModule 4 vlan 40 server ip address 10.20.220.1 255.255.255.0 ! vlan 32 client ip address 10.202.3.39 255.255.255.224 gateway 10.202.3.33 ! serverfarm FARM4 nat server no nat client real 10.20.220.10 inservice real 10.20.220.20 inservice ! vserver VIP1 virtual 10.202.3.34 tcp www serverfarm FARM4 persistent rebalance inservice
An easy way to retrieve MIB information is the Linux command snmpwalk which you can execute from any device that can reach the Catalyst 6500/7600 with the CSM:
[user@localhost user]$ snmpwalk -v2c -c public 10.202.3.2 1.3.6.1.4.1.9.9.161
Where 10.202.3.2 is one of the Catalyst management IP addresses and 1.3.6.1.4.1.9.9.161 is the OID of the MIB.
The following are the first few lines of the output of a SNMP walk of the CISCO-SLB-MIB:
[user@linux user]$ snmpwalk -v2c -c public 10.202.3.2 .1.3.6.1.4.1.9.9.161 enterprises.9.9.161.1.1.1.1.6.4 = Counter32: 9 enterprises.9.9.161.1.1.1.1.7.4 = Counter64: 9 enterprises.9.9.161.1.1.1.1.8.4 = Counter32: 9 enterprises.9.9.161.1.1.1.1.9.4 = Counter64: 9 enterprises.9.9.161.1.1.1.1.10.4 = Counter32: 9 enterprises.9.9.161.1.1.1.1.11.4 = Counter64: 9 enterprises.9.9.161.1.2.1.1.2.4.5.70.65.82.77.52 = 1 enterprises.9.9.161.1.2.1.1.3.4.5.70.65.82.77.52 = 3 enterprises.9.9.161.1.2.1.1.4.4.5.70.65.82.77.52 = Gauge32: 2 enterprises.9.9.161.1.2.1.1.5.4.5.70.65.82.77.52 = Gauge32: 0 enterprises.9.9.161.1.2.1.1.6.4.5.70.65.82.77.52 = 1 enterprises.9.9.161.1.3.1.1.4.4.5.70.65.82.77.52.10.20.220.10.0 = 2 enterprises.9.9.161.1.3.1.1.4.4.5.70.65.82.77.52.10.20.220.20.0 = 2 enterprises.9.9.161.1.3.1.1.5.4.5.70.65.82.77.52.10.20.220.10.0 = Gauge32: 0 enterprises.9.9.161.1.3.1.1.5.4.5.70.65.82.77.52.10.20.220.20.0 = Gauge32: 0 <-- snipped -->
Understanding the raw data output of this command requires interpreting the MIB definition and converting decimal values to the corresponding ASCII characters.
Let’s take for example the following entry:
enterprises.9.9.161.1.2.1.1.4.4.5.70.65.82.77.52 = Gauge32: 2
The following are the relevant portions of the MIB definition:
ciscoSlbMIB MODULE-IDENTITY
::= { ciscoMgmt 161 }
ciscoSlbMIBObjects OBJECT IDENTIFIER ::= { ciscoSlbMIB 1 }
slbStats OBJECT IDENTIFIER ::= { ciscoSlbMIBObjects 1 }
slbServerFarms OBJECT IDENTIFIER ::= { ciscoSlbMIBObjects 2 }
slbServerFarmTable OBJECT-TYPE
SYNTAX SEQUENCE OF SlbServerFarmTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a table of server farms, each of which is a
group of real servers to be used by SLB for load
balancing. Columnar objects can be modified when the
row is 'active'. Rows can be created and destroyed.
Entries are added to this table via
slbServerFarmRowStatus in accordance with the
RowStatus convention."
::= { slbServerFarms 1 }
slbServerFarmTableEntry OBJECT-TYPE
SYNTAX SlbServerFarmTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular server farm served by
a particular local SLB entity."
INDEX {
slbEntity,
slbServerFarmName
}
::= { slbServerFarmTable 1 }
SlbServerFarmTableEntry ::= SEQUENCE {
slbServerFarmName SlbServerString,
slbServerFarmPredictor SlbPredictor,
slbServerFarmNat SlbNatSetting,
slbServerFarmNumberOfRealServers Unsigned32,
slbServerFarmBindId Unsigned32,
slbServerFarmRowStatus RowStatus
}
slbServerFarmNumberOfRealServers OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of real servers in this server farm."
DEFVAL { 0 }
::= { slbServerFarmTableEntry 4 }
slbEntity OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The SLB instance reference number for this server.
This allows multiple SLB's to exist on the same SNMP
system."
::= { slbStatsTableEntry 1 }
slbServerFarmName OBJECT-TYPE
SYNTAX SlbServerString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of server farm."
::= { slbServerFarmTableEntry 1 }
SlbServerString ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The configured name associated with an SLB object."
SYNTAX OCTET STRING (SIZE (1..15))
Where the slbEntity is the CSM slot number (4, in this example) and the SlbServerString follows standard conventions, whereby the string is made of the length of the name (here 5 characters) , followed by the decimal value of the ASCII characters (70.65.82.77.52 = FARM4)
That explains:
enterprises.9.9.161.1.2.1.1.4.4.5.70.65.82.77.52 = Gauge32: 2
which indicates that the number of real servers (161.1.2.1.1.4) for CSM in slot 4, for farm named FARM4 is indeed 2.
The snmpwalk command is able to interpret the values, if you provide the MIB definition files:
[user@linux user]$ snmpwalk -v2c -M mibs/ -m all -c public 10.202.3.2 .1.3.6.1.4.1.9.9.161 enterprises.cisco.ciscoMgmt.ciscoSlbMIB.ciscoSlbMIBObjects.slbStats.slbStatsTable. slbStatsTableEntry.slbStatsCreatedConnections.4 = Counter32: 9 connections slbStatsTableEntry.slbStatsCreatedHCConnections.4 = Counter64: 9 connections slbStatsTableEntry.slbStatsEstablishedConnections.4 = Counter32: 9 connections slbStatsTableEntry.slbStatsEstablishedHCConnections.4 = Counter64: 9 connections slbStatsTableEntry.slbStatsDestroyedConnections.4 = Counter32: 9 connections slbStatsTableEntry.slbStatsDestroyedHCConnections.4 = Counter64: 9 connections enterprises.cisco.ciscoMgmt.ciscoSlbMIB.ciscoSlbMIBObjects.slbServerFarms.slbServerFarmTable. slbServerFarmTableEntry.slbServerFarmPredictor.4."FARM4" = roundRobin(1) slbServerFarmTableEntry.slbServerFarmNat.4."FARM4" = serverNat(3) slbServerFarmTableEntry.slbServerFarmNumberOfRealServers.4."FARM4" = Gauge32: 2 slbServerFarmTableEntry.slbServerFarmBindId.4."FARM4" = Gauge32: 0 slbServerFarmTableEntry.slbServerFarmRowStatus.4."FARM4" = active(1) enterprises.cisco.ciscoMgmt.ciscoSlbMIB.ciscoSlbMIBObjects.slbRealServers.slbRealTable. slbRealTableEntry.slbRealState.4."FARM4".10.20.220.10.0 = inService(2) slbRealTableEntry.slbRealState.4."FARM4".10.20.220.20.0 = inService(2) slbRealTableEntry.slbRealNumberOfConnections.4."FARM4".10.20.220.10.0 = Gauge32: 0 slbRealTableEntry.slbRealNumberOfConnections.4."FARM4".10.20.220.20.0 = Gauge32: 0
The following picture allows you to compare the graphical representation of the MIB definition with the text output above:
Note: not all the MIB entries are populated, for example in the snmpwalk output above you will not find the slbServerFarmName entry
SlbServerFarmTableEntry ::= SEQUENCE {
slbServerFarmName SlbServerString,
slbServerFarmPredictor SlbPredictor,
slbServerFarmNat SlbNatSetting,
slbServerFarmNumberOfRealServers Unsigned32,
slbServerFarmBindId Unsigned32,
slbServerFarmRowStatus RowStatus
}
slbServerFarmName OBJECT-TYPE
SYNTAX SlbServerString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of server farm."
::= { slbServerFarmTableEntry 1 }
since that is defined as “not-accessible”.
XML API
Introduction and Functionality
Aside for retrieving information via SNMP/MIB, you can also configure the CSM to accept configuration commands or return specific information via a public XML API.
The XML DTD is published on the cisco.com website, in the documentation section for the CSM, and is updated for each new CSM release
When this option is configured, the CSM listens for HTTP POST messages on a specific L4 port (by default port 80) on its management IP addresses (IPs and VLANs from where XML commands should be accepted can be configured by the user).
Note: differently from the SNMP requests, XML commands have to be sent to a CSM management IP address and not to a MSFC or Supervisor IP address.
You can send XML commands to the CSM as body of such POST messages. Multiple commands can be sent as part of the same POST message and multiple POST messages can be sent ove the same TCP connection (leveraging the HTTP 1.1 Connection KeepAlive feature)
CSM code releases prior to 4.2(1) only support configuration commands, while 4.2(1) adds the capability to retrieve statistics and configuration information with “show” commands sent via XML (not all the commands/options are implemented, see below).
When commands are sent to the CSM, the CSM executes them and either modifies its configuration or returns the output for the “show” commands (requires at least code 4.2). In case of specific XML errors, the response document will include an “error” child element, as part of the element which has caused the error (see the errors section below).
Configuration
The XML interface can be enabled from within the xml-config CSM submode of configuration, which supports the following options:
Cat6k#conf t Enter configuration commands, one per line. End with CNTL/Z. Cat6k (config)#mod csm 4 Cat6k (config-module-csm)#xml-config Cat6k (config-slb-xml)#? SLB XML-config client-group use a client access list credentials HTTP credentials default Set a command to its defaults exit exit submode inservice enable configuration via XML no Negate a command or set its defaults port XML config server port vlan VLAN for XML config data
All parameters above are optional, except for the “inservice” command which enables the XML interface (by default the xml interface is “out of service” and the CSM will simply reset new connections received on that IP/port – with a TCP RST)
The remaining options allow you to limit which devices can send XML commands to the CSM (client-group – based on a IOS ACL), on which CSM VLAN these commands can be accepted (i.e. which CSM management IP address should accept incoming HTTP POST messages), which L4port the CSM should listen on for HTTP POST messages and which credentials should the sender of such messages use to authenticate.
Let’s modify the CSM configuration used above for the SNMP/MIB example, enabling the XML interface:
module ContentSwitchingModule 4 vlan 40 server ip address 10.20.220.1 255.255.255.0 ! vlan 32 client ip address 10.202.3.39 255.255.255.224 gateway 10.202.3.33 ! serverfarm FARM4 nat server no nat client real 10.20.220.10 inservice real 10.20.220.20 inservice ! vserver VIP1 virtual 10.202.3.34 tcp www serverfarm FARM4 persistent rebalance inservice ! xml-config port 8080 vlan 32 inservice
The following command allows you to verify the status and counters for the XML interface:
Cat6k#sh mod csm 4 xml-config stats
XML config: inservice, port = 8080, vlan = 32 (10.202.3.39), client list =
connection stats:
current = 0, total = 0
failed = 0, security failed = 0
requests: total = 0, failed = 0
and confirms that the CSM will accept XML commands on IP address 10.202.3.39, port 8080.
As with many other CSM statistics, also these counters can be reset with:
Cat6k#clear mod csm 4 counters
Testing and Examples
The XML API can be tested by sending plain text files (written according to the XML DTD) as HTTP POST messages to the CSM configured to accept XML commands.
A practical tool to generate POST messages is “curl”, which is available for either Windows or Linux. The following examples use curl for Linux, with the following parameters:
- -v verbose
- -H adds or modify a HTTP header in the HTTP request
- -d specify the text file with the data to include in the POST message
Note: the HTTP POST requests need to be sent to URL “xml-config”.
The following example shows how to add a new vserver called “VIPTEST” (assuming it did not exist before).
Let’s create a text file named “xml.txt” which contains the following:
[user@linux user]$ more xml.txt
<config>
<csm_module slot='4'>
<vserver name='TESTVIP'>
<virtual ipaddress='10.202.3.100' protocol='6' port='80'/>
<serverfarm_ref name='FARM4'/>
<idle value='600'/>
</vserver>
</csm_module>
</config>
and let’s execute:
[user@linux user]$ curl -v -H 'Connection: close' -d @xml.txt 10.202.3.39:8080/xml-config
* Connected to 10.202.3.39 (10.202.3.39)
> POST /xml-config HTTP/1.1
User-Agent: curl/7.8 (i386-redhat-linux-gnu) libcurl 7.8 (OpenSSL 0.9.6b) (ipv6 enabled)
Host: 10.202.3.39:8080
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Connection: close
Content-Length: 223
Content-Type: application/x-www-form-urlencoded
* Closing live connection (#0)
The statistics confirm that the command has been received and the connection has been closed (i.e. there are no “current” connections)
Cat6K#sh mod csm 4 xml stats
XML config: inservice, port = 8080, vlan = 32 (10.202.3.39), client list = <none>
connection stats:
current = 0, total = 1
failed = 0, security failed = 0
requests: total = 1, failed = 0
You will notice that the CSM configuration now includes also:
vserver TESTVIP virtual 10.202.3.100 tcp www serverfarm FARM4 idle 600 persistent rebalance no inservice
As expected, the vserver was not put “inservice”, since the xml.txt file did not include any command to change the admin state of the configured vserver. Such state can be changed with the following element described in the DTD:
<!ELEMENT inservice EMPTY> <!ATTLIST inservice sense (yes | no) #IMPLIED >
The following XML commands will access the pre-existing vserver TESTVIP on CSM in slot 4, and put the virtual service “inservice”:
<config>
<csm_module slot='4'>
<vserver name='TESTVIP'>
<inservice sense='yes'/>
</vserver>
</csm_module>
</config>
Similarly, the following XML commands would put the vserver “out of service”:
<config>
<csm_module slot='4'>
<vserver name='TESTVIP'>
<inservice sense='no'/>
</vserver>
</csm_module>
</config>
Errors
Failures in the delivery of the XML commands could be triggered either by errors at the connection level (TCP connection issues, violation of the configured ACL, HTTP authentication problems, etc…) or at the XML configuration level (malformed XML commands/document, invalid XML elements, problems in executing the command either on the CSM itself or in IOS, etc…)
Errors of the first type (connection level) are in general reported in the CSM xml statistics.
As an example, the following command:
[user@linux user]$ curl -v -H 'Connection: close' -d @xml2.txt 10.202.3.39:8080/xml-wrong
would return a 404:
10.202.3.39.8080 > 10.10.1.100.32812: P 1:46(45) ack 515 win 1460 0x0000 4500 0055 0273 0000 3f06 5fd2 0aca 0327 E..U.s..?._....' 0x0010 0a0a 0164 1f90 802c c933 a7be eb15 6162 ...d...,.3....ab 0x0020 5018 05b4 ccd6 0000 4854 5450 2f31 2e31 P.......HTTP/1.1 0x0030 2034 3034 204e 6f74 2046 6f75 6e64 0d0a .404.Not.Found.. 0x0040 436f 6e6e 6563 7469 6f6e 3a20 636c 6f73 Connection:.clos 0x0050 650d 0a0d 0a e....
and the error would be reported as a “failed” connection as well as “failed” request in the CSM XML stats:
Cat6k#sh mod csm 4 xml stats
XML config: inservice, port = 8080, vlan = 32 (10.202.3.39), client list = <none>
connection stats:
current = 0, total = 13
failed = 1, security failed = 0
requests: total = 13, failed = 1
Violation of the security settings (ACL, authentication) would cause the “security failed” counter to increase.
Errors of the second type (XML configuration) are still accounted for as “successful” connections and successful HTTP requests, and would return a 200 OK message, however they would include information on the XML/configuration error in the body of the reply.
Note: successful commands return a 200 OK HTTP message with the message body <?xml.version=”1.0”?>
10.202.3.39.8080 > 10.10.1.100.32811: P 1:59(58) ack 516 win 1460 0x0000 4500 0062 026d 0000 3f06 5fcb 0aca 0327 E..b.m..?._....' 0x0010 0a0a 0164 1f90 802b b911 c5be a883 74c7 ...d...+......t. 0x0020 5018 05b4 2d50 0000 4854 5450 2f31 2e31 P...-P..HTTP/1.1 0x0030 2032 3030 204f 4b0d 0a43 6f6e 6e65 6374 .200.OK..Connect 0x0040 696f 6e3a 2063 6c6f 7365 0d0a 436f 6e74 ion:.close..Cont 0x0050 656e 742d 4c65 6e67 7468 3a20 3233 0d0a ent-Length:.23.. 0x0060 0d0a .. 10.10.1.100.32811 > 10.202.3.39.8080: . ack 59 win 5840 (DF) 0x0000 4500 0028 90fd 4000 4006 9074 0a0a 0164 E..(..@.@..t...d 0x0010 0aca 0327 802b 1f90 a883 74c7 b911 c5f8 ...'.+....t..... 0x0020 5010 16d0 4395 0000 P...C... 10.202.3.39.8080 > 10.10.1.100.32811: P 59:82(23) ack 516 win 1460 0x0000 4500 003f 026e 0000 3f06 5fed 0aca 0327 E..?.n..?._....' 0x0010 0a0a 0164 1f90 802b b911 c5f8 a883 74c7 ...d...+......t. 0x0020 5018 05b4 b891 0000 3c3f 786d 6c20 7665 P.......<?xml.ve 0x0030 7273 696f 6e3d 2231 2e30 223f 3e0d 0a rsion="1.0"?>.. 10.10.1.100.32811 > 10.202.3.39.8080: . ack 82 win 5840 (DF)
An example of a XML configuration error can be the following:
<config>
<csm_module slot='4'>
<vserver name='TESTVIP'>
<inservice sense='maybe'/>
</vserver>
</csm_module>
</config>
which would still return a 200 OK, but would include details of the specific error code encountered:
<?xml version="1.0"?>
<config <csm_module slot="4">
<vserver name="TESTVIP">
<inservice sense="maybe">
<error code="0x10">Invalid attribute sense value in element inservice</error>
</inservice>
</vserver>
</csm_module>
</config>
The following is the list of possible XML configuration errors that the CSM can return and the format in which they are returned:
<!--
**************
In case of error, the response document will include an "error" child element
in the offending element. The error element takes the form:
<!ELEMENT error EMPTY>
<!ATTLIST error
code NMTOKEN #REQUIRED
>
The body of the error element is a description string.
Attribute "code" is a hex value representing a mask of possible error codes:
XML_ERR_INTERNAL = 0x0001 /* internal memory or coding error */
XML_ERR_COMM_FAILURE = 0x0002 /* communication failure */
XML_ERR_WELLFORMEDNESS = 0x0004 /* not a wellformed XML document */
XML_ERR_ATTR_UNRECOGNIZED = 0x0008 /* found an unrecognized attribute */
XML_ERR_ATTR_INVALID = 0x0010 /* found invalid value in attribute */
XML_ERR_ATTR_MISSING = 0x0020 /* required attribute missing */
XML_ERR_ELEM_UNRECOGNIZED = 0x0040 /* found an unrecognized element */
XML_ERR_ELEM_INVALID = 0x0080 /* found invalid element */
XML_ERR_ELEM_MISSING = 0x0100 /* required element missing */
XML_ERR_ELEM_CONTEXT = 0x0200 /* valid element found in wrong place */
XML_ERR_IOS_PARSER = 0x0400 /* IOS unable to parse command */
XML_ERR_IOS_MODULE_IN_USE = 0x0800 /* Another user is configuring CSM */
XML_ERR_IOS_WRONG_MODULE = 0x1000 /* Tried to configure unavailable CSM */
XML_ERR_IOS_CONFIG = 0x2000 /* IOS configuration error */
**************
-->
XML show commands
CSM 4.2 adds support for certain XML show commands. The syntax is defined in the same XML DTD.
Differently from the “configuration” commands, the “show” commands do not modify the configuration, but return in the body of the HTTP reply, the output of the selected show command.
Let’s assume the following CSM configuration:
module ContentSwitchingModule 4 vlan 40 server ip address 10.20.220.1 255.255.255.0 ! vlan 32 client ip address 10.202.3.39 255.255.255.224 gateway 10.202.3.33 ! serverfarm FARM3 nat server no nat client real 10.20.220.30 inservice ! serverfarm FARM4 nat server no nat client real 10.20.220.10 inservice real 10.20.220.20 inservice ! vserver VIP1 virtual 10.202.3.34 tcp www serverfarm FARM4 persistent rebalance inservice ! xml-config port 8080 vlan 32 inservice
The following is an example of the “show” command to query all the serverfarms in the CSM:
<show_serverfarm> </show_serverfarm>
Sending this command with curl generates the following (we use the –i option for curl, so that we can see the HTTP headers of the HTTP reply):
[user@linux user]$ curl -i -v -H 'Connection: close' -d @show3 10.202.3.39:8080/xml-config * Connected to 10.202.3.39 (10.202.3.39) > POST /xml-config HTTP/1.1 User-Agent: curl/7.8 (i386-redhat-linux-gnu) libcurl 7.8 (OpenSSL 0.9.6b) (ipv6 enabled) Host: 10.202.3.39:8080 Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Connection: close Content-Length: 35 Content-Type: application/x-www-form-urlencoded <show_serverfarm></show_serverfarm> HTTP/1.1 200 OK Connection: close Content-Length: 374 <?xml version="1.0"?> * Closing live connection (#0) <show dtd_version="4.2"><csm_module slot="4"/><serverfarm name="FARM4"><predictor value="roundrobin"/><num_reals value="2"/><server_nat/><num_redirect value="0"/><bind_id value="0"/></serverfarm><serverfarm name="FARM3"><predictor value="roundrobin"/><num_reals value="1"/><server_nat/><num_redirect value="0"/><bind_id value="0"/></serverfarm></show>
Or, in a better format:
<show dtd_version="4.2">
<csm_module slot="4"/>
<serverfarm name="FARM4">
<predictor value="roundrobin"/>
<num_reals value="2"/>
<server_nat/>
<num_redirect value="0"/>
<bind_id value="0"/>
</serverfarm>
<serverfarm name="FARM3">
<predictor value="roundrobin"/>
<num_reals value="1"/>
<server_nat/>
<num_redirect value="0"/>
<bind_id value="0"/>
</serverfarm>
</show>
Information on a specific serverfarm can be obtained with the “name” option:
<show_serverfarm name='FARM4'> </show_serverfarm>
The following is the list of the supported show commands as of release 4.2(1)
show_vserver show_serverfarm show_real show_vlan show_conns show_policy show_map show_ft show_status show_probe show_probe_real show_sticky show_natpool show_arp show_variable show_owner show_xml_stats show_memory show_stats show_capp show_gslb show_dfp show_static_nat show_script show_script_task
Note: the “detail” option (specified in the DTD for some show commands) is not yet implemented in release 4.2
The following is the sample output for the comand:
<show dtd_version="4.2"> <csm_module slot="4"/> <stats> <module_connection_stats created="0" destroyed="0" current="0" timed_out="0" failed="0"/> <server_initiated_connection_stats created="0" current="0" failed="0"/> <l4_lb_stats decisions="0" drops="0"/> <l7_lb_stats decisions="0" total_drops="0" max_parse_length_reached_drops="0" cookie_out_of_mem_drops="0" config_version_mismatch_drops="0" bad_ssl2_format_drops="0"/> <l4_l7_lb_stats no_policy_drops="0" no_policy_match_drops="0" no_real_drops="0" acl_denied_drops="0" server_initiated_drops="0"/> <checksum_failure_stats ip="0" tcp="0"/> <redirect_stats connections="0" drops="0"/> <ftp_stats connections="0"/> <mac_frames_stats> <tx_frame_stats unicast="133" multicast="0" broadcast="930" underflow_errors="0"/> <rx_frame_stats unicast="204" multicast="12893" broadcast="13" overflow_errors="0" crc_errors="0"/> </mac_frames_stats> </stats> </show>
Search
Moving your apps to Amazon or Miscrosoft Clouds?
We can help you analyze your existing infrastructure, identify the cost savings we can achieve by migrating to a cloud provider. We can then execute end-to-end migration plan of your infrastructure and bringing down your TCO.
Ready for IPv6 Migration?
The Internet is running out of the equivalent of phone numbers - familiar problem, non-trivial solution.
The world has to move to IPv6, with its 128-bit addresses. But that's easier said than done.
Are you fluent in "Linux"?
Learn Linux from a leading expert and quickly master you Linux skills.
Learn how to simplify your workflow and increase your productivity using tips and techniques of the pros.
Ideal training for Corporate IT Beginners and Advanced IT Admins alike.
Who's Online
We have 3 guests and no members online