I don't think the sniffer approach is going to work at all. Here are some reasons.
35.71 Mpps * 64 bytes =~ 18.x Gbit/s. If you want to measure that amount of traffic (or even half of it), you would need
- a traffic generator with 19 1 Gbit/s interfaces to generate the traffic
- a capture system with 19 1 Gbit/s interfaces to capture the forwarded frames
- the same amount of TAPs
- a capture system that is able to handle that amount of traffic (writing to disk)
- a system that is able to analyze that amount of traffic (lots of RAM and CPU power)
- etc.
- etc.
As you can see, that's not going to work, even for only half of the packet rate.
Even worse: That packet rate (35.71 Mpps) cannot be measured in a real world environment. The switch offers only 24 1 Gibt/s interfaces. If you split them into 12 input interfaces (traffic generator) and 12 output interfaces (sniffer), you would be able to only forward 12 Gibt/s, which is just ~23 Mpps. So, the advertized number is nothing that has been measured (as impossible) it's just a calculated value, used by the marketing department to let the switch look better ;-))
I understand why you might need/check that value, but the sniffer approach is not going to work very well.
I suggest
- to use a (hardware) traffic generator with a sender and a receiver part (on several ports of the switch). However: Such a generator will cost ~ 100-200 times as much as that switch. Even if you rent one, it's still 10-20 times as expensive as the switch.
- use the port statistics of the switch (however: can you trust those values) + that switch does not offer SNMP!!
- believe the values of the vendor -30% 'marketing addition' and -100/400% for 'real world performance' ;-))
++ UPDATE ++
Is there a way to graph an effective forwarding rate on any given port from a wireshark capture?
if you want to do it just for one switch port, it might work. Just do the following
- capture the traffic of one outgoing port, preferably with a TAP
- capture only the first 100 bytes. That's enough to calculate the graphs and won't overload your capture system (writing to disk)
- as long as the capture file isn't too large, you can use the I/O graphs to draw a graph of the packet rate
- the output rate depends on the switch capabilities, but also on the input rate, so make sure you have a packet generator at hand to get enough traffic to forward ;-)
Things to consider:
- use a TAP to get only one direction of traffic, in your case outbound
if you are using a mirror port, there are several (possible) problems
- incoming and outgoing traffic will be mirrored to one 1 Gibt/s interface unless the switch let's you configure the mirror process for only one direction
- If you are using a mirror port, you will never know if you see all frames. The switch could have dropped frames due to an overload or a firmware bug while mirroring the traffic
- port mirroring might have an influence on the CPU usage and thus the forwarding rate (rather unlikely, however I have seen that in the real world)
Regards
Kurt
answered 14 Jan '14, 07:50
Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%
Kurt,
Why are you multiplying a max. forwarding rate of the whole switch 35.71 Mpps by a min frame size of 64 bytes ?
Because that's the values you mentioned in the question ;-)
Performance Switching Capacity
48Gbps (DGS-1100-24) 24 ports * 2 (full duplex 1Gb Up + 1Gb Down) * 1000Mb = 48Gbps
Max. Forwarding Rate
35.71 Mpps (DGS-1100-24) 24 ports * 1.488Mpps = 35.71Mpps
O.K. in my calculation I did not consider the full-duplex nature of every interface. My fault ;-)
Anyway, what is your question?
Is it about checking the vendor values, then part one of my answer applies, even if the calculation did not consider the full-duplex nature.
Is it about measuring the packet rate of one interface, then part two of my answer applies (++ UPDATE ++).
If I follow your advice and capture traffic in each direction individually, should I mirror RX traffic to one port and TX traffic to another port while having two wireshark systems capturing so I can merge the traffic later?
Would I have to enable Jumbo packets on the capturing systems since both endpoints and a switch are set to 9000?
As I don't know what excatly you are trying to measure, I can't answer that question. Please add more details.
I can't answer that question, as it depends on your system. Some NIC drivers will drop Jumbo frames, others won't. You'll have to test it with your systems NICs.
I suspect DGS-1100-24 switch to be dropping packets due to an overload, but as you said in the previous post I would not be able to detect it with port mirroring.
I though a graph would give me some indication of a problem, but since I can only do it on each port individually I would never see the whole picture.
You're probably right. Occasional packet drops within a switch are pretty hard to troubleshoot.
what would be a filter for a packet rate?
There is no 'filter'. You can draw a packet rate graph with I/O graps. 'Packet rate' is the default graph.
Just wanted to be sure the default graph is what I wanted to see.
Thanks