What Linux software is capable of marking DSCP on packets based on DPI?
-
My goal is to make VoIP applications the highest priority on my network followed by streaming services using DPI.
I’m already marking some “obvious” packets based on port number with nftables, but I haven’t had success using DPI with nDPI, Suricata.
-
My goal is to make VoIP applications the highest priority on my network followed by streaming services using DPI.
I’m already marking some “obvious” packets based on port number with nftables, but I haven’t had success using DPI with nDPI, Suricata.
Shouldn’t you be marking the traffic at the host as it is put into the network?
-
Shouldn’t you be marking the traffic at the host as it is put into the network?
If I were a VoIP application developer sure, but in this case my role is networking geek.
-
If I were a VoIP application developer sure, but in this case my role is networking geek.
You don’t need to be a developer. Linux has traffic control tc and windows has qos policy management.
-
You don’t need to be a developer. Linux has traffic control tc and windows has qos policy management.
That’s my point — I’m trying to do this from a mini PC I use as a router and not the machine doing the actual VoIP stuff.
-
My goal is to make VoIP applications the highest priority on my network followed by streaming services using DPI.
I’m already marking some “obvious” packets based on port number with nftables, but I haven’t had success using DPI with nDPI, Suricata.
Flow control is really a thing of the past. In production, we mark priority based on source port and destination host at the WAN edge. SMB\NFS replication across the WAN is an example of this. As another commented mentioned, voice should be tagged at the switch later and carried over the network. Tagging at your router is a moot point in residential because your ISP is discarding any DSCP you hand them.
-
Flow control is really a thing of the past. In production, we mark priority based on source port and destination host at the WAN edge. SMB\NFS replication across the WAN is an example of this. As another commented mentioned, voice should be tagged at the switch later and carried over the network. Tagging at your router is a moot point in residential because your ISP is discarding any DSCP you hand them.
Right - and then the ISP will prioritize their own VoIP services traffic within your locally shared block.
-
Flow control is really a thing of the past. In production, we mark priority based on source port and destination host at the WAN edge. SMB\NFS replication across the WAN is an example of this. As another commented mentioned, voice should be tagged at the switch later and carried over the network. Tagging at your router is a moot point in residential because your ISP is discarding any DSCP you hand them.
wrote last edited by [email protected]My internet is crazy fast but what I’m trying to accomplish is this: if the internet bandwidth were to decrease dramatically or become crazy congested, I’d like the router to prioritize some traffic between the LAN and WAN.
Let’s imagine I only have a 20 Mbps connection and I have a someone on a FaceTime call, for sake of argument everyone else is downloading huge software updates. I want the call to be prioritized.
I understand the ISP will drop DSCP but internally my AP will translate that to WMM no? Again, my AP is fantastic but in theory I’d like it to prioritize the call’s packets. Those obviously pass through the router from WAN to LAN so I’m not understanding the argument that this should only be done based on host and port.
-
My internet is crazy fast but what I’m trying to accomplish is this: if the internet bandwidth were to decrease dramatically or become crazy congested, I’d like the router to prioritize some traffic between the LAN and WAN.
Let’s imagine I only have a 20 Mbps connection and I have a someone on a FaceTime call, for sake of argument everyone else is downloading huge software updates. I want the call to be prioritized.
I understand the ISP will drop DSCP but internally my AP will translate that to WMM no? Again, my AP is fantastic but in theory I’d like it to prioritize the call’s packets. Those obviously pass through the router from WAN to LAN so I’m not understanding the argument that this should only be done based on host and port.
wrote last edited by [email protected]Again, your ISP does DSCP markings. They will only benefit you if you are facing congestion issues inside your local network. When that external FaceTime call packet is received by your router, if you receive it at all because your ISP doesn't care about markings, and you are having Internet issues, it's going to reach your end point crazy fast inside your LAN, but I bet the call will drop regardless because the UDP steam is either too jittered, or completely frozen anyway because of the upstream ISP issue.
It's great to configure this to understand the principle, but I've been in the industry long enough to know when QoS is required over a 10MB MPLS pipe, and not required over a 1GB+ pipe. The pipes are so big today that flow control has little use case any longer and can cause more issues and hand holding configuration than necessary.
I guess what I'm trying to say is if you're having issues with your home Internet, you will see it regardless of how much mitigation you try to configure inside your own LAN.
