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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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
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
Explain or provide a topology. But is this correct?
cust_lan>>>>>FGT>>>>>>COMCAST>>>>INTERNET>>>>>cust
PCNSE
NSE
StrongSwan
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
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
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
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
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1640 | |
1066 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.