Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I know this question has been asked before, but maybe not in this particular context:

I have a setup with a couple of MS2008R2 HyperVisor servers running a number of Ubuntu guests.

Our webproxy runs Ubuntu 12.04 LTS and has a lot of packets pruned. We are using the synthetic LAN driver, and configured with 5 ethernet alias interfaces (eth0:1 - eth0:5).

I have tuned the kernel according to various tips given here (extending buffer memory from 128KB to 16MB) - and no changes whatsoever to the symptom.

I have extended the amount of RX (and TX) descriptors (256 -> 512 resp. 512 -> 1024) on the LAN-card in the HyperV server - still no sign of improvement. Max no of descriptors is 2048 according to Intel (Intel Pro 1Gbps 4 port card). The physical network is based on 1G switches.

The funny thing is that we do not have the impression that anything is performing poorly - every webserver behind the webproxy (reverse proxy/gateway) seems to work as expected.

Here are some key parameters from sysctl:

net.core.wmem_max = 12582912
net.core.rmem_max = 16777216
net.core.wmem_default = 229376
net.core.rmem_default = 229376
net.core.optmem_max = 20480

net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 131072
net.ipv4.tcp_max_tw_buckets = 131072
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 48369        64495   96738
net.ipv4.tcp_wmem = 10240       87380   12582912
net.ipv4.tcp_rmem = 4096        87380   16777216
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_cookie_size = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_thin_dupack = 0

Therefore the question(s): What exactly is happening when these packets are pruned? Are packets just being retransmitted later on, giving the impression that everything is OK? Or do we really have to worry about those pacets being pruned? Could the symptom indicate a backpressure from the firewall (Sonicwall) issuing traffic shaping (@ 100 Mbps)?

Figures are 10K to 20K pruned packetes every 3 minutes (according to our Nagios monitoring) - so actually a lot of pruned packets.

Any tips or answers appreciated! :)

EDIT: We are not using SR-IOV (as this is 2012 stuff I've been told), and we are using some kind of virtual switch (in Windows Server 2008 R2)

share|improve this question
    
Do you use SR-IOV or are those packets going through the virtual switch? And this IS funny - I have no problem gettingt a 10g line saturated from a VM.... so.... this looks funny. –  TomTom Mar 31 at 7:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.