Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
ilucas
New Contributor

Comcast DSCP trouble?

I've done some research on posts (non fortinet forums) that list the DSCP bits coming from comcast to the local modem/installation as the lowest priority (0x08) and that to fix this I've typically seen commands to make iptables essentially convert those dscp bits to 0x00 to unclassify the incoming traffic and process it without that interference.

 

Has anyone ever implemented this with FortiGate, if they are even affected?

I unfortunately do not have a unit and an open comcast connection to play around with.

 

This is the command I've seen recommended to implement, if it helps:

iptables -t mangle -A PREROUTING -i vlan2 -j DSCP --set-dscp 0

----

FG 200B/30D/60D/80D/100D/200D/300D

FE 200D

---- FG 200B/30D/60D/80D/100D/200D/300D FE 200D
10 REPLIES 10
Huey
New Contributor III

Interesting.  I've been told by someone at Comcast that they intentionally give low priority to basic internet service traffic.  The reasoning used was that they want you to buy the services from them.  Thus, streaming video and voice perform badly unless you buy it from them.

 

I don't see how manipulating DSCP bits will help you tho.  If they are on their game, they will reset those bits on any of your outbound traffic.  The inbound traffic is already trumped by traffic they prioritized.  The only prioritization you will be able to achieve is between your device and the first hop towards the internet.  from there they most likely reset the bits based on various parameters.

Layer8 Consulting

http://www.L8C.com

 

Layer8 Consulting http://www.L8C.com
emnoc
Esteemed Contributor III

I would really be surprised if a ispcarrier will honor  DSCP markups  fully across all boundaries. Typically unless you have QoS contract, they don't s trust anything and once you leave one carrier domain, your TOS/DSCP bits will probably be remarked imho. QoS  and tos/dscp across the internet is not a 100% reliable means.

 

But to answer your question you  can toggle whatever DSCP you want per policy-id, it's quite simple.

 

( e.g forward direction )

 

config firewall policy     edit 47         set srcintf "port1"         set dstintf "wan1"             set srcaddr "all"                          set dstaddr "all"                      set schedule "always"             set service "ANY"                      set logtraffic enable         set diffserv-forward enable         set diffservcode-forward 000001     next end

And the monitor from the cli or pcap;

 

diagnose sys session filter  policy 47

diagnose sys session list | grep tos serial=00941528 tos=01/ff ips_view=0 app_list=0 app=0 serial=00941526 tos=01/ff ips_view=0 app_list=0 app=0 serial=00941524 tos=01/ff ips_view=0 app_list=0 app=0 serial=00941529 tos=01/ff ips_view=0 app_list=0 app=0 serial=00941527 tos=01/ff ips_view=0 app_list=0 app=0 serial=0094151c tos=01/ff ips_view=0 app_list=0 app=0

 

And you can validate by pcap using wireshark/tshark/tcpdump/etc..... on the far-end if the TOS/DSCP is being received or reclassified.

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ilucas
New Contributor

I think maybe I was unclear.

 

The DSCP bits are those being sent FROM the comcast, so would be the receiving end from customer perspective. I do realize that any outgoing data would be rewritten through their equipment. I'm talking about incoming data from a client/customer viewpoint being set with that DSCP so that devices (some, not all) end up prioritizing that traffic as low in their QoS/WMM and it causes problems.

----

FG 200B/30D/60D/80D/100D/200D/300D

FE 200D

---- FG 200B/30D/60D/80D/100D/200D/300D FE 200D
emnoc
Esteemed Contributor III

Explain or provide a topology. But is this correct?

 

 

cust_lan>>>>>FGT>>>>>>COMCAST>>>>INTERNET>>>>>cust

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ilucas
New Contributor

emnoc wrote:

Explain or provide a topology. But is this correct?

 

 

cust_lan>>>>>FGT>>>>>>COMCAST>>>>INTERNET>>>>>cust

 

That topology is correct, but what I'd been seeing is that packets coming from comcast to my fortigate are setting that DSCP bit.

Ingress traffic, traffic bound for the fortigate/lan from the WAN (i.e. comcast).

----

FG 200B/30D/60D/80D/100D/200D/300D

FE 200D

---- FG 200B/30D/60D/80D/100D/200D/300D FE 200D
Dave_Hall
Honored Contributor

So what you are indicating is wanting the DSCP bits reset or zeroed on incoming traffic from WAN to Internal? 

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
ilucas

Dave Hall wrote:

So what you are indicating is wanting the DSCP bits reset or zeroed on incoming traffic from WAN to Internal? 

I'm what's wanting those reset. Or to somehow confirm that their DSCP bits aren't interfering with the way the FortiGate is interpreting the incoming/downstream traffic from comcast.

 

I know that diffserv not being enabled on those policies, it will not forward the DSCP codes into the network, but I'm talking about initial processing when it hits the WAN.

----

FG 200B/30D/60D/80D/100D/200D/300D

FE 200D

---- FG 200B/30D/60D/80D/100D/200D/300D FE 200D
Dave_Hall
Honored Contributor

Office is closing in 5 mins, so haven't had time to look further into this, but there may be something (at the CLI level) for traffic shaping (also Differentiated Services) that you may be able to play around with to reset the DSCP bits.

 

Gotta pack-up...

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
Huey
New Contributor III

ilucas wrote:

Dave Hall wrote:

So what you are indicating is wanting the DSCP bits reset or zeroed on incoming traffic from WAN to Internal? 

I'm what's wanting those reset. Or to somehow confirm that their DSCP bits aren't interfering with the way the FortiGate is interpreting the incoming/downstream traffic from comcast.

 

I know that diffserv not being enabled on those policies, it will not forward the DSCP codes into the network, but I'm talking about initial processing when it hits the WAN.

The Fortigate will ignore DSCP bits unless you tell it to act on them. 

Layer8 Consulting

http://www.L8C.com

 

Layer8 Consulting http://www.L8C.com
Top Kudoed Authors