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? 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 This: 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. -- Tim Connors
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?
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).
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."
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
On 06/07/12 11:50, 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.
If you don't have a *written* agreement between systems & networks on what machines can set what QoS bits for how much traffic then it's network's fault for not treating machines as untrusted and clearing the bits (and from your description also their fault for allowing the congestion to occur in those places). Without that level of detail any QoS policy is worse then useless. (and for that matter without regularly verifying what traffic is in which class it's also worthless) As for capturing ask them to give you a span port so you can verify things, if they can't do that (without good reason) find new network people.
participants (3)
-
Julien Goodwin -
Tim Connors -
Trent W. Buck