[144112] in North American Network Operators' Group
RE: Silently dropping QoS marked packets on the greater Internet
daemon@ATHENA.MIT.EDU (Jeff Saxe)
Fri Sep 2 10:50:04 2011
From: Jeff Saxe <jsaxe@briworks.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Fri, 2 Sep 2011 14:49:32 +0000
In-Reply-To: <4E60E717.5050406@gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I must say, that seems not terribly sporting. :-)=0A=
=0A=
Seriously, I would expect that most public Internet carriers, unless you pa=
id them extra fees to pay attention to the DSCP markings, would completely =
ignore them and treat it all as best-effort traffic, right up to and includ=
ing the last-mile circuit that should be the congestion point at which QoS =
would be most useful to differentiate. I don't think it would be the stated=
policy of any public ISP to drop other-than-zero-marked packets, especiall=
y if it's a transit somewhere that's out of reach of either you or the othe=
r customer you're trying to reach.=0A=
=0A=
But I know from personal experience that some pieces of Ethernet switch gea=
r can have policies, even at Layer 2, which affect traffic in ways that wer=
e not obvious when the human engineers deployed them. I ran into one such p=
roblem while deploying a straight-up Internet service to a customer on some=
GPON gear, and I used a built-in filter to select traffic on a VLAN basis,=
but I didn't realize that the filter also (unconditionally) matched on Lay=
er 2 QoS markings (802.1p in the VLAN tag) at the same time. And my core Et=
hernet switch had QoS globally enabled, which meant that it was snooping at=
the Layer 3 DSCP tag and adapting it (dividing by 8, basically) and placin=
g it into the 802.1p field on the way out the trunk port to the GPON gear.=
=0A=
=0A=
This didn't affect anything until the customer started using a remote backu=
p service -- Mozy, I believe -- which, in a lame attempt to obtain better t=
ransit "for free" from ISPs who accidentally pay attention to markings, mar=
ked its own HTTPS traffic higher than zero. So my customer could reach anyp=
lace on the Internet except for this backup service -- pings to them worked=
, but starting a Web session or a backup to the same exact IP address would=
return no packets. And when I tried from our core (not going through the G=
PON), it worked perfectly. It was a bit of a head-scratcher until we tcpdum=
p'ed the traffic and looked at it carefully. I assume the same thing would =
have happened had one of my customers tried to use a SIP VoIP carrier throu=
gh our Internet.=0A=
=0A=
So, in short, I would guess that your upstream's dropping problem was *prob=
ably* accidental rather than intentional, and if you can bring it to the at=
tention of the right people at that ISP, they'd probably be grateful.=0A=
=0A=
-- Jeff Saxe=0A=
Blue Ridge InternetWorks=0A=
Charlottesville, VA=0A=
=0A=
=0A=
=0A=
=0A=
________________________________________=0A=
From: Jesse McGraw [jlmcgraw@gmail.com]=0A=
Sent: Friday, September 02, 2011 10:24 AM=0A=
To: nanog@nanog.org=0A=
Subject: Silently dropping QoS marked packets on the greater Internet=0A=
=0A=
I've recently run into a hard-to-troubleshoot issue where, somewhere=0A=
out in the greater Internet, someone was silently dropping packets from=0A=
my company that happened to be marked with DSCP AF21. I'd fully expect=0A=
others to either ignore these markings or zero them out but just=0A=
silently dropping them seems unnecessary.=0A=
=0A=
So, how do you guys treat marked packets that come into/through your=0A=
networks?=0A=
=0A=
