I find myself in bit of a pain, faced with a massive performance degrade on our centrally located NAS storage. In a nutshell, I've conducted a series of benchmark tests, mainly read/write using different block-sizes, ranging from 4k to 256k. The scenario is as follows:
SMB Client - Windows XP (not SMB v2 capable) - Strictly used for testing purpose
SMB Server - NetApp FAS3170 storage controller
SMB Client by default, is connected to a 1GE interface on a Cat6509/Sup720.
SMB server connected to a Cat4900M through a 20G etherchannel. Switch has 2x10 Gig uplinks, non-bundled.
Both client and server reside inside the same L3/VPN, though on opposite segments, separated by a 4xCat6509/Sup720 full-mesh IP/Mpls core. Both the Cat4900M and the Cat6509 operate strictly as layer2 devices and uses a pair of cat6509/Sup720 dsitribution-switches. Each access-switch connect to its own pair of distributionswitches, so all traffic traverses the Core.
My primary focus evolves around SMB tranfers using small blocksizes, as this constitutes the majority of the transfers from the SMB clients (virtual XenApp servers).
1) When SMB Client and SMB Server are directly adjacent on the same vlan, everything is peachy. Even when I move the client a few switched hops away, nothing changes. And when moving the client to a different vlan on the same distributionblock, though inside the same L3/VPN, only a slight decrease in performance is seen. <5%.
2) But when I move the client across the core to the "real" serversegment and conduct the same benchmark test again, it's a completely different ballgame. Large blocksize-transfers perform mostly the same, only a minor performance degrade is found. But smuller blocksizes, particularly 4k and 8k, drops by 30-50%!!!
The actual number of L3-hops the traffic traverses at any given time is 4. There's nothing to suggest, that either of theese distribution- og coreswitches are congested or experience any kind of hang-up in packet forwarding. Flow-collection from various interfaces show no peaks or other signs of weakness and no other traffic is affected by this. This problem, for now, seems to be isolated to SMB only. And mostly manifests itself, when multible L3-hops are introduced.
I'm aware of some of the limitations on SMB v1 and scalability issues, but as per my understanding, theese mostly concerns SMB across Wan-distances. This is a datacenter enviroment with high-performance equipment, so I'm quite baffled by this. There are no latency issues involved in this, which from what I know, is one of the pitfalls of using SMB.
I've never heard anything about the use of mpls, would introduce theese kinds of problems. We have a third datacenter at another location, that has an a topology almost excatly like this one, only difference is, that we don't use mpls there and the NetApp does not operate at 10G capacity and is connected to a pair of stacked 3750G's. But the number of L3-hops, coincidently, is the same. 4-5, depending on the path chosen.
I release, that this is but of a mouthfull and as such, I don't expect anyone to go into "debug mode" on this. But if anyone has any thoughts, past experiences, suggestions or otherwise, plz let me know. Any feedback would be grately appreciated.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...