* Advanced QoS camera traffic inside VPN on Asus router
@ 2018-04-27 12:50 Daniel Santos
2018-04-28 8:24 ` Andy Furniss
0 siblings, 1 reply; 2+ messages in thread
From: Daniel Santos @ 2018-04-27 12:50 UTC (permalink / raw)
To: lartc
Hello List,
I have a difficult QoS issue to solve on a DSL-AC52U router.
I have some ip cameras on a network which send out massive traffic to a
video server on another side of a layer 2 VPN.
This VPN carries other data SSH/RDP/VNC which needs to be prioritized
over the ip camera traffic and to complicate things
there are regular network protocols which are non-vpn SSH/RDP/VNC again
and pretty much everything else which also
needs to be prioritized against the camera traffic.
Is this even possible to merge the queue of 2 interfaces into one and
prioritize by that?
To make it even more complex the traffic from the Camera-(ra0 2Ghz wifi)
> VPN (tap15) is bridged.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.d017c30d90f0 no ra0
elan.1
elan.2
elan.3
elan.4
rai0
tap15
Therefore the packets never enter the mangle chain.
I don't care about any services on the camera therefore I could just put
that whole IP to the lowest priority QoS queue.
For example:
iptables -t mangle -I FORWARD -s 10.0.0.10 -j MARK --set-mark 1
iptables -t mangle -I PREROUTING -s 10.0.0.10 -j MARK --set-mark 1
Has absolutely no effect.
ebtables -I FORWARD -p IPv4 -o tap15+ -s 00:18:39:6b:ab:12 -j DROP
works using the camera's Wifi mac:
Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-p IPv4 -s 0:18:39:6b:ab:12 -o tap15+ -j DROP , pcnt = 160 -- bcnt =
35702
Ebtables however it seems is not able to mark the packets :(
It has an option: mark - "Matches frames with the given unsigned mark
value." but it is a matching not marking.
What is the best solution/workaround for this issue?
The only one I can think of is to setup a second VPN tunnel between the
2 locations (same router<>same server) on a different port and put that
second VPN tunnel into the lowest priority traffic.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Advanced QoS camera traffic inside VPN on Asus router
2018-04-27 12:50 Advanced QoS camera traffic inside VPN on Asus router Daniel Santos
@ 2018-04-28 8:24 ` Andy Furniss
0 siblings, 0 replies; 2+ messages in thread
From: Andy Furniss @ 2018-04-28 8:24 UTC (permalink / raw)
To: lartc
Daniel Santos wrote:
> Hello List,
>
> I have a difficult QoS issue to solve on a DSL-AC52U router.
> I have some ip cameras on a network which send out massive traffic to a
> video server on another side of a layer 2 VPN.
> This VPN carries other data SSH/RDP/VNC which needs to be prioritized
> over the ip camera traffic and to complicate things
> there are regular network protocols which are non-vpn SSH/RDP/VNC again
> and pretty much everything else which also
> needs to be prioritized against the camera traffic.
>
> Is this even possible to merge the queue of 2 interfaces into one and
> prioritize by that?
In theory you could try ifb with traffic directed to it from > 1
interface by adding tc rules on those interfaces.
On egress first add eg. prio on said interfaces just so you can add tc
rules (default pfifo_fast won't allow this)
I haven't done this on such a complicated setup, but try searching
around for examples, it may work for you.
Consider turning off GRO/TSO/whatever with ethtool so you see real
rather than aggregated packets.
I haven't tried for ages, so don't have any hard examples.
It should be possible to mark with tc actions, the actual classification
you do on a redirect to ifb type rule
doesn't get seen by a qdisc on ifb, it is reinstated when(if) the packet
returns.
>
> To make it even more complex the traffic from the Camera-(ra0 2Ghz wifi)
> > VPN (tap15) is bridged.
>
> # brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.d017c30d90f0 no ra0
> elan.1
> elan.2
> elan.3
> elan.4
> rai0
> tap15
>
> Therefore the packets never enter the mangle chain.
> I don't care about any services on the camera therefore I could just put
> that whole IP to the lowest priority QoS queue.
>
> For example:
>
> iptables -t mangle -I FORWARD -s 10.0.0.10 -j MARK --set-mark 1
> iptables -t mangle -I PREROUTING -s 10.0.0.10 -j MARK --set-mark 1
>
> Has absolutely no effect.
>
> ebtables -I FORWARD -p IPv4 -o tap15+ -s 00:18:39:6b:ab:12 -j DROP
>
> works using the camera's Wifi mac:
>
> Bridge chain: FORWARD, entries: 1, policy: ACCEPT
> -p IPv4 -s 0:18:39:6b:ab:12 -o tap15+ -j DROP , pcnt = 160 -- bcnt = 35702
>
> Ebtables however it seems is not able to mark the packets :(
> It has an option: mark - "Matches frames with the given unsigned mark
> value." but it is a matching not marking.
>
> What is the best solution/workaround for this issue?
>
> The only one I can think of is to setup a second VPN tunnel between the
> 2 locations (same router<>same server) on a different port and put that
> second VPN tunnel into the lowest priority traffic.
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-04-28 8:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-27 12:50 Advanced QoS camera traffic inside VPN on Asus router Daniel Santos
2018-04-28 8:24 ` Andy Furniss
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.