UCS Technology Labs UCS B-Series LAN

Connectivity

Monitoring LAN Connections and

Exposing Hot Spots
Last updated: April 12, 2013

Task
Ensure that statistics are collected for all networking port types at half of their normal rate.
Do not change statistics collection rates for any unimplemented or non-networking collection
policy.
Do change reporting intervals for all implemented statistics (networking or non-networking) to their
lowest (fastest reporting) values.
Create a monitoring statistic that provides alerts when the southbound traffic from the FIs (FI-toIOM) goes above a rate of 25Gbps, and list it as a 'Critical' alarm.
Create a monitoring statistic that provides alerts when the northbound traffic to or from the FIs (FIto-LAN and LAN-to-FI) goes above a rate of 15Gbps, and list it as a 'Major' alarm.
Create a monitoring statistic called "vNIC-1Gb" (to be used later in Service Profiles) that provides
alerts when traffic from a vNIC goes above a rate of 1Gbps, and list it as a 'Warning' alarm.

Configuration

FEEDBACK

Note:
The Fabric Interconnect collects data at every collection interval, but it doesn't
send the values to the UCSM until the reporting interval. For example, if the
collection interval is set to 30 seconds and the reporting interval is set to 2
minutes, the fabric interconnect collects four samples in that 2-minute reporting
interval. Instead of sending four statistics to Cisco UCS Manager, it sends only
the most recent recording along with the average, minimum, and maximum values
for the entire group.
The Collection Policy for "Host" is currently unimplemented in v2.0 (it is meant for
VMs at a later date), so we should not change collection policies for this one.
Also, a "Chassis" does not have any networking components (FEXs/IOMs do, but
not the chassis itself), so we will not change the collection rate here, but we will
change the reporting statistic. For the rest, we will change the collection statistics
to half of their default rate, which is 60 seconds (so we will change them to 30
seconds each), and the reporting interval to its lowest or quickest value, which is
2 minutes.
It is very important to understand how we derive the values that we will be inputting
in our threshold policies. First, we are dealing with thresholds, which implicitly
means that they must be crossed. Second, the way these are implemented in
UCSM may seem a bit strange: We have metrics such as "Tx/Rx Total Bytes,"
but those won't do us much good because they are metrics that will be crossed
once, and then stay above that crossed value, forever increasing - or at least until
the entire system is restarted (which hopefully is never). So we will work mostly
with "Tx/Rx Total Bytes Delta." Next, these are in bytes, not bits, so we must
convert. "Delta" refers to the delta of the collection period or sampling rate, which
we will be changing to the minimum value of 30 seconds; we must determine the
rate in bits per second that we want to measure against, divide that by 8 to get
bytes per second, and multiply that times 30 to get bytes per 30 seconds - that
will be our value.
Delta = bps / 8 (for bytes/sec) * 30 (sampling rate)
In the left navigation pane, click the Admin tab and filter or navigate to Stats Management.

Under Stats Management, click Collection Policy Adapter. In the right pane, change the
Collection Interval to 30 Seconds and the Reporting Interval to 2 Minutes (their lowest
respective values) and click Save Changes.

Under Stats Management, click Collection Policy Chassis. In the right pane, do not change
the Collection Interval, but do change the Reporting Interval to 2 Minutes because the chassis
has no networking ports (FEX does, chassis does not), and click Save Changes.

Under Stats Management, click Collection Policy FEX. In the right pane, change the
Collection Interval to 30 Seconds and the Reporting Interval to 2 Minutes, and click Save
Changes.

Under Stats Management, skip Collection Policy Host and click Collection Policy Port. In
the right pane, change the Collection Interval to 30 Seconds and the Reporting Interval to 2
Minutes, and click Save Changes. A "port" is any port in the actual FIs.

Under Stats Management, click Collection Policy Server. In the right pane, do not change
the Collection Interval, but do change the Reporting Interval to 2 Minutes because the server has
no networking ports (Adapter does, server itself does not), and click Save Changes.

In the left pane, navigate to Fabric >> Internal LAN, right-click thr-policy-default, and click
Create Threshold Class. Internal LAN deals with southbound traffic to and from the FI-to-IOM.
(Note that this task could also be performed from the LAN tab, which you see outlined and
highlighted.)

Choose Ether Tx Stats.

Click Add.

From the drop-down menu, choose Ether Tx Stats Total Bytes Delta, and ensure that the delta
is measured against a normal value of 0.0 bytes. Now for the calculation: The task requires that
FI southbound traffic to the IOM trigger a Critical alarm when it passes 25Gbps, or
25,000,000,000. Divide that by 8 to get 3,125,000,000. Multiply that by the collection interval of

30 to get 93,750,000,000 - the value we'll enter in the Critical Up column. Remember that
thresholds must be exceeded to be triggered, and we must fall back below them to stop
triggering - so choose some slightly lower value for the Down column.
(Remember that the reporting interval is just what gets reported (which is the last collection
interval plus avg, min, max, etc.), but we still measure our deltas against the collection interval,
not the reporting interval.)

Click Finish.

We see our class under the default threshold defined.

In the left pane, navigate to Fabric >> LAN Cloud, right-click thr-policy-default, and click
Create Threshold Class. LAN Cloud deals with northbound traffic to and from the FI-to-LAN.

Choose Ether Tx Stats.

Click Add.

From the drop-down list, choose Ether Tx Stats Total Bytes Delta, and ensure that the delta is
measured against a normal value of 0.0 bytes. The task requires FI northbound traffic to the LAN
to trigger a Major alarm when it passes 15Gbps, so (15,000,000,000 / 8) *30 = 56,250,000,000
is our value for the Up column. Choose some slightly lower value for the Down column.
(Remember that if we had left our default collection interval set at 1 minute, we would be
multiplying our values by 60 rather than 30.)

Click Finish.

We are not done yet; the task requires that we measure both to and from the northbound LAN.
Right-click thr-policy-default under LAN Cloud, and click Create Threshold Class.

Choose Ether Rx Stats.

Click Add.

From the drop-down list, choose Ether Rx Stats Total Bytes Delta, and ensure that the delta is
measured against a normal value of 0.0 bytes. Enter the same value as before (56,250,000,000)
for the Up column and a slightly lower value for the Down column.

Click Finish.

Notice that both classes under the default threshold are now defined.

Finally, we'll create a policy for our vNICs. In the left pane, right-click the root org and click
Create Threshold Policy. vNIC policies are applied to vNICs that are in Service Profiles, which
must belong to orgs, so it makes sense that this is where we will find and create these policies.

Give it a name and click Next.

Click Add.

For Stat Class, choose Vnic Stats.

Click Add.

From the drop-down list, choose Vnic Stats Packets Tx Delta, and ensure that the delta is
measured against a normal value of 0.0 bytes. (1,000,000,000 / 8) *30 = 3,750,000,000 is our
value for the Up column, and a slightly lesser value should be entered for the Down column.

Click Finish.

Click Finish again.

Verification
We can see the values entered for this vNIC.

We can also see the values for any of the policies that we created. We will have to generate a
lot of traffic later to really test these.

^ back to top

Disclaimer (http://www.ine.com/feedback.htm) | Privacy Policy (http://www.ine.com/resources/)

Inc., All Rights Reserved (http://www.ine.com/about-us.htm)

2013 INE