We have a print job that prints to a printer in a different building. The printing is horribly slow. As part of the troubleshooting I want to see if the programmers are sending a lot more data over the WAN than they think they are.
(We once had a job that imported a 1K text file into a small database. Bad programming led to over a GB of data being moved.)
Please be more specific, Steve. Is there a specific port? A specific target? A specific group or subnets of IPs that send data? When you say that printing is slow, have you tried QoS to make sure it has adequate bandwidth? ???
Cheers - Bob
You're right, Steve - not possible. But, I'm confused - I thought you wanted to measure something else that might be hindering that traffic.
Cheers - Bob
It is possible.
Checking bandwidth:
The important issue with UTM is that each enabled proxy is mutually exclusive of the others, with firewall rules being the one used when nothing else activates. For printer traffic, I assume it is going through the firewall rules, unless it is using an IPP connection, in which case it might go through the web proxy. (I am no expert on IPP).
First, you need to create an "Allow" firewall rule that matches your traffic, and enable logging in that rule. This assumes that your default allow rule has logging disabled; an alternative is to enable logging of all allowed traffic.
Then use my code from this post to load the logs into a SQL database.
Once the logs are in a database, just sum across the ItmLength column for traffic that matches your selection criteria. One easy way to do the selection is to select ItmFwRule=value, where the value corresponds to the sequence number assigned to the firewall rule by the GUI. Note that if you add and delete firewall rules, the sequence numbers will change, so Bob Alfson suggests creating some do-nothing rules to act as placeholders, so that you can insert new rules without changing the numbers.
Fragmentation:
Assuming that the link between buildings is a VPN tunnel, you have to worry about MTU. The inside packet needs to be smaller than the outside packet, so that the encryption overhead can be added to the packet without creating a packet split. I think the magic number is about 1380 for an external interface that behaves like Ethernet with 1512 MTU. If the MTU is changed at the UTM, your internal traffic will not be affected at all, and your Internet-bound traffic will adapt and use a few extra packets. Users will not notice the difference. But your VPN user can see a lot of improvement if the packet count is cut in half.
My education on fragmentation came from Cisco. For a thorough analysis of the subject, search their support site for "Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC"
Do you have Asymmetry?
The other issue to consider is asymmetric network configurations (cable service), especially if you have asymmetry at both ends. (I have been badly burned on dual-asymetric VPN connections.) RFC 3449 discusses the theory. Basically, the ACK may not arrive in time, causing retransmits.
Hi Steve,
I know this is a maverick answer, but just use tcpdump & wireshark.
1) ssh-login into the UTM and execute (as root):tcpdump -pn -s 0 -w /tmp/sniff.pcap -i eth0 host A and host B
(change eth0, A, B according your needs)
2) Start your print job and if it's done, stop the tcpdump-job with CTRL-C. Then scp the /tmp/sniff.pcap file to your workstation and open it in wireshark
3) In wireshark check the menu Statistics: Protocol Hierarchy... (Bytes for every protocol), Conversations (Bytes in every direction), Endpoints, IO Graphs (shows packets in a timegraph)
bye Josef
BERGMANN engineering & consulting GmbH, Wien/Austria
