All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.