Re: Advanced QoS camera traffic inside VPN on Asus router

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux