The client switchport or the server switchport can be monitored. A third switchport can be configured as a mirror port. This means that this mirror port will receive copies of all packets on the corresponding original port, while the original traffic won't be affected.
For example, on the Catalyst 3560:
Enter configuration mode:
conf t
Define the source and set the session number:
monitor session 1 source interface fa 0/24
Here, the session number can be from 1 to 66, you could also specify a VLAN or an ethernet channel. Also, interface ranges such as fa 0/25 - 26 are possible, and interface list, such as fa 0/24,fa 0/26, if you would like to monitor several clients at the same time. Also by repeating the command you can add ports, or remove using no. Mixing ports and VLANs is not possible in the same session, another restriction is that you cannot use a destination port as a source port.
Define the destination port:
monitor session 1 destination interface gi 0/1
You can use a normal port, but not a VLAN. Similarly to above, a destination port cannot be a source port: a port used here can either be a source or a destination port, and only of one session. Again, you can specify multiple ports like above.
You may want to exit configiration mode and save the config.
You may have a look at your defined session - here multiple ports, tried like above:
#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa0/24,Fa0/25-26
Destination Ports : Fa0/48,Gi0/1
Encapsulation : Native
Ingress : Disabled
You can see an encapsulation here - optionally you can set it to replicate for replicating the source interface encapsulation method, such as by adding encapsulation replicate after the source interface. Furthermore, you can specify a direction (tx, rx, both), filter VLANs and more. The Ingress: Disabled line means that the switch will not accept any frames presented to it by your capture device on a destination port. For such finer details and for further restrictions and default settings have a look at the command reference of the IOS version of your switch.
Once you configured source and destination port, you can capture the traffic using your laptop connected to the destination port, for example with Wireshark.
The number of source sessions can be limited, for example the 3560 supports a maximum of 2.
After the capturing, don't forget to remove this session configuration.
Interface Internal-Data0/0 "", is up, line protocol is up
2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
^^^^^^^^^^^^^^^^^^
0 output errors, 0 collisions, 0 interface resets
You show overruns on the InternalData interfaces, so you are dropping traffic through the ASA. With that many drops, it's not hard to imagine that this is contributing to problem. Overruns happen when the internal Rx FIFO queues overflow (normally because of some problem with load).
EDIT to respond to a question in the comments:
I don't understand why the firewall is overloaded, it is not close to using 10Gbps. Can you explain why we are seeing overruns even when the CPU and bandwidth are low? The CPU is about 5% and the bandwidth either direction never goes much higher than 1.4Gbps.
I have seen this happen over and over when a link is seeing traffic microbursts, which exceed either the bandwidth, connection-per-second, or packet-per-second horsepower of the device. So many people quote 1 or 5 minute statistics as if the traffic is relatively constant across that timeframe.
I would take a look at your firewall by running these commands every two or three seconds (run term pager 0 to avoid paging issues)...
show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop
Now graph out how much traffic you're seeing every few seconds vs drops; if you see massive spikes in policy drops or overruns when your traffic spikes, then you're closer to finding the culprit.
Don't forget that you can sniff directly on the ASA with this if you need help identifying what's killing the ASA... you have to be quick to catch this sometimes.
capture FOO circular-buffer buffer <buffer-size> interface <intf-name>
Netflow on your upstream switches could help as well.
Best Answer
The packet capture feature stores data in pcap format, which can be read by Wireshark and other analysis tools. So, yes, that would probably be more useful for packet analysis than syslog messages.