Hi:

The UCS ecosystem leverages a port aggregation solution to chassis I/O, namely, the FEX modules.

The  FEX modules are not fully featured switches. Nor do they possess any  forwarding policy intelligence at all. Instead, the FEX modules deploy a  "pinning" approach in which downlinks (those that face the blade  server's NIC's, LOMs, mezzanine cards) are mapped to an uplink port  (those that face a 6100 Fabric Interconnect) to form what can be  described as an aggregator group.

The  result is a simplified approach to blade I/O in which the traffic  patterns are predictable and failover is deterministic. Moreover, there  is no need to configure STP because the ports are uplinked in a manner  as to preclude any possibility of a bridging loop.

This  having been said, is there some merit to the argument that this port  aggregation design places a hole in the middle of a QoS deployment since  the scheduling of packets on the uplink ports facing the 6100 Fabric  Interconnect is not performed in a manner that recognizes priority?

To  elaborate a bit more, one can have a VMware deployment and leverage  NetIOC or perhaps configure QoS on a 1000v switch (whose uplink ports  are mapped to a port on the Palo VIC) and configure QoS on the VIC, and  then on the 6100 Fabric Interconnect. But, since the FEX is not  scheduling traffic to the 6100 Fabric Interconnect according to any  priority, the QoS deployment has a hole in the middle, so to speak.

Thoughts?