On Fri, 6 Jul 2012, Trent W. Buck wrote:
Tim Connors wrote:
We've got networks people claiming that we're killing their network link with packets claiming to be so high priority that they're swamping VOIP. Previous correspondence with them imply it's ssh and ftp connections that are responsible.
Specifically, they're saying that we're setting DSCP to 0x2, which is not defined. Anyone know how to read the RFCs to say whether we're doing something wrong (we're not doing anything to change ftp, ssh or iptables rules from default settings)? Anyone seen this before?
Can you actually see that when you e.g. tcpdump your egress iface?
It's sorta the most important machine in the bureau, and I didn't want to run disk/cpu hogging software on it to grab what would probably amount to be a metric kilo-shitload of packets. So I'm just trusting the noc's description of the problem.
Indeed, http://bogpeople.com/networking/dscp.shtml has no setting for dscp=0x2. I doubt anything, particularly the alledged ssh, is using the old RFC791/RFC1349 interpretations of bits 3 => 1 = High Throughput; 0 = Normal Throughput
There are >2 choices, see "IPQoS" in ssh_config(5).
Ah thanks. RTFM when google fails you.
http://www.quora.com/How-can-I-identify-interactive-SSH-but-not-SCP-packets shows that ssh/scp use QoS that don't map to any defined DSCP numbers. But that shouldn't be a problem, no? The routers shouldn't kill the network just because a client told them to watch out for the flying elephants.
My knee-jerk reaction was certainly "tell the ISP to fix their fucking QoS algorithm then."
Yeah, that was my knee jerk reaction too. I wonder how well it will go down with the people further up in the foodchain, included in the CC list. -- Tim Connors