Foglight Experience Monitor (FxM) has four feeds coming in: eth2, eth3, eth4, eth5. It is exceeding the recommended maximum traffic capture volume as discussed in SOL31887. Referencing SOL38831 to identify if the appliance is overloaded or not, it is found that there is no evidence of any Packets Dropped. This may indicate that the appliance is not overloaded. However, there are missing client segments and server segments.
It is probably not the appliance itself being overloaded with too much traffic. If it was then it is expected to show Packets Dropped. Client Segments Missing and Server Segments Missing are a side-effect of dropping packets.
Probably it is dirty traffic feed. That is, the traffic the appliance is receiving contains gaps. The packets are being dropped by the infrastructure at the tap or the switch and FxM is being given a feed with data gaps, a "dirty feed". This causes the missing client and server segments rates to be high but you could also have 0 packet drops at the appliance. In this scenario, the packet drops are happening at the tap or the switch. The SPAN port (not the appliance) is getting overloaded and dropping a lot of packets in the switch. So, packets are being lost outside of the appliance.
Disconnect three of the four feeds (e.g. eth4). This will lower the traffic level. If the missing client and server segment rates go to zero then we have validated the health of the eth4 feed. You could do the same thing to validate the eth2, eth3 and eth5 feeds as well. At this point, we do now know which one, if any, is giving the dirty feed. It could be that only one of them is bad.
If you validate each feed one-by-one (so that each feed you are looking at does not exceed the recommended traffic volume) and see a zero (or low) client and server segment missing rate then you can conclude that the problem is an appliance overload condition. If so, see RESOLUTION 1. Otherwise, refer to RESOLUTION 2-4 (same as SOL35035).
Cut back on the amount of network traffic that the total appliance (not just per port) is monitoring less than 6,000,000 packets per 5-minute interval. This limit is discussed in SOL31887.
SPAN a smaller number of packets. Reduce the amount of traffic being sent over your SPAN so your switch SPAN port does not get overloaded.
Get a better switch with a better SPAN port.
Use a network tap to feed the streams directly into FxM and bypass the switch's problematic SPAN port.