Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Does QoS work even if your modem-router is set to just be a modem? Or does it only apply to routers being routers?

AA send out ZyXel VMG 1312-B10A with QoS set to prioritise small packets even when the device is already preconfigured in modem-only mode. I wonder if this is intentional or just a commonality with the config they use for routers set up as routers, which they do also ship.

I was thinking about how to test it. I thought the Firebrick prioritises short packets so that would muck up testing surely.

There is a but though.

If the Firebrick is set up to limit upstream traffic rates to something just below what each modem can handle when maxed out, set by calculation that is hopefully accurate and wisely chosen, then it will be the Brick that is in control surely, and the Zyxel modem will not get a chance to apply its QoS as packets will always arrive slightly too late. That is my thinking anyway. Is that correct?

Anyway, if that is right, then it will invalidates my tests because the Firebrick is what is being tested, not the ZyXel. Could fix it though, by putting the speed rates way way up in the Brick.

[Weaver]

A test done without all the ZyXel modems deployed gave huge ping times when doing a ping during a backup to the Apple iCloud storage service, so it seems the Firebrick is not doing small packet prioritisation either during uploads. Very disappointing. Am I missing something? (Becoming a Firebrick question though, not a ZyXEL one.)

[johnson]

Forgive me if I'm wrong, but I'm not sure how a device used in bridge mode could perform QoS. It just receives ethernet frames and passes them on, its not aware of their content and so couldnt prioritise small TCP or UDP packets above others.

I'm sorry I can help with the firebrick. What sort of QoS options does it expose to you?

Edit: There is the 802.1p setting that can be between 0 and 2 I believe on BT VDSL, which corresponds to best effort or priority. I guess that suggests awareness of packet sizes with priority reducing latency at the cost of bulk transfer speed?

[Weaver]

If it really is a bridge. I don't know how literally true that is. But they could just implement upper layer protocol snooping, and if this one specific case it isn't real fully fledged QoS it's just smallest packet first, so smallest frame payload first wins would do.

But actually maybe I am being a but mad, if the the Firebrick will not let the ZyXEL control things because it is spacing out/holding back the packets then there is no ingress upstream queue for the ZyXEL to manage.

Am I correct about the Firebrick’s speed limiting preventing the modem from even having a chance to do queue management things anyway?

The Brick is rubbish in terms of QoS, it does not have any facilities at all. It just says that small packets are prioritised and that is their hack to make VoIP work. It notes that this will also benefit DNS and ACKs for example.

[johnson]

it's just smallest packet first, so smallest frame payload first wins would do.

But are smaller higher level packets guaranteed to be put in their own frame/payload? Whats to stop your ICMP request being part of a full payload with part of another packet.

Edit: again forgive my ignorance, maybe fragmentation like this isn't even how PPPoE works

[spring]

https://www.cisco.com/c/en/us/td/docs/wireless/bridge/1400/12-2_11_JA/configuration/guide/brscg/p11qos.pdf

https://www.gargoyle-router.com/phpbb/viewtopic.php?t=3340

https://zeroshell.org/qos/

http://www.tomshardware.com/answers/id-2296671/bridged-modem-router-ethernet-ports-connect-internet.html#r16509993

https://community.ubnt.com/t5/EdgeRouter/Transparent-Traffic-Shaping-over-switch0/td-p/2093704

[johnson]

Gave it a little skim, aren't wireless bridges a pretty different animal to PPPoE ones?

Ok yeah, maybe thats the point you were making:

QoS for Wireless LANs Versus QoS on Wired LANs
The QoS implementation for wireless LANs differ
s from QoS implementations on other Cisco devices.
With QoS enabled, bridges perform the following:
•
They do not classify packets; th
ey prioritize packets based on DSCP value, client type (such as a
wireless phone), or the priority value in the 802.1q or 802.1p tag.
•
They do not match packets using ACL; they use only MQC class-map for matching clauses.
•
They do not construct internal DSCP values; they only support mapping by assigning IP DSCP,
Precedence, or Protocol values to Layer 2 COS values.
•
They carry out EDCF like queuing on the radio egress port only.
•
They do only FIFO queueing on the Ethernet egress port.
•
They support only 802.1Q/P tagged packets. Bridges do not support ISL.

[Weaver]

@johnson were you referring to wireless LAN protocols? This is ordinary wired ethernet across a wired link from a Firebrick router to a ZyXEL modem, so one IP PDU equals one ethernet frame exactly. Wireless has Lx SDU- and PDU aggregation - combining multiple things into one Ln-1 PDU. Was that what you were referring to?

Of course you could just inspect the ethernet mac header itself and determine the length of the ethernet payload.

[Weaver]

We know for certain that some PPPoEoE-speaking devices are not ethernet bridges at all anyway. The Draytek Vigor devices. That would be impossible, as they do not speak PPPoEoA at all, but rather PPPoA RFC2364 instead- their big advantage.

[johnson]

@johnson were you referring to wireless LAN protocols? This is ordinary wired ethernet across a wired link from a Firebrick router to a ZyXEL modem, so one IP PDU equals one ethernet frame exactly. Wireless has Lx SDU- and PDU aggregation - combining multiple things into one Ln-1 PDU. Was that what you were referring to?

Of course you could just inspect the ethernet mac header itself and determine the length of the ethernet payload.

No I was just responding to springs first link (before he edited and added more), its a cisco document on QoS for wireless bridges but has a section on how they differ from normal bridges which can only prioritise based on DSCP or 802.1q/p tagging.

[Weaver]

My apologies. Crossed over - I read them in the wrong order. Neither wireless nor routers are relevant here, this is a modem-only device and the there is no wireless.

[spring]

https://community.cambiumnetworks.com/t5/ePMP-2000-and-1000/QoS-inside-PPP-with-bridge-mode/td-p/62566

https://community.sophos.com/products/unified-threat-management/f/network-protection-firewall-nat-qos-ips/41274/qos-traffic-selectors-in-transparent-mode

https://community.sophos.com/products/unified-threat-management/f/network-protection-firewall-nat-qos-ips/42116/qos-on-bridge-mode/148652#148652


I think you need to buy a transparent traffic shaper, which avoids double nat (non transparent?  ), and put it between the router and modem.

Also about the issues of using PfSense:

from r/PFSENSE

https://www.reddit.com/r/PFSENSE/comments/4nz10x/tired_of_fighting_with_qos/

[johnson]

I think you need to buy a transparent traffic shaper, which avoids double nat (non transparent?  ), and put it between the router and modem.

I dont think so. Many routers are have excellent QoS capable of shaping both egress and ingress.

I guess you mean in order to keep using the firebrick?

[spring]

I dont think so. Many routers are have excellent QoS capable of shaping both egress and ingress.

I guess you mean in order to keep using the firebrick?

Bridge mode, and "QoS", not priority.

Most business-grade, layer-2 switches support VLANs. You configure trunks to carry the multiple VLANs between switches and routers. How to do this, specifically, will depend on the switch model(s). VLAN tags are only used on trunks; frames on access ports are not tagged.

VLAN tagging really has nothing to do with IP QoS. Layer-2 frames have a COS, and layer-3 packets have a TOS, or DSCP. Different frames or packets with the same VLAN tag can have different QoS markings. As Daniel points out in the comment, the COS is only applied on frames with VLAN tags, but tagged frames only exist on trunks, not on access ports. Your switch(es) may support the minimal layer-2 QoS, and you would need to set the switch(es) up to apply COS markings and and queues on the switch(es), but this assumes your switches support layer-2 QoS, which is not normally very robust. Where you will really make a difference is with the layer-3 marking and router queuing based on those markings.

VoIP data traffic is typically set to EF (Expedited Forwarding), but you aren't doing that. Also, VoIP control traffic, on the same VLAN, is usually marked differently. A VoIP phone will, by default, mark its packets correctly, and you only need to trust on the VoIP VLAN. Marking VoIP the same as network control information, 7, is not usually a good thing.

One thing to really understand is that your QoS markings and policies are only good on your network. Unless you have an agreement in place with your ISP ($$$), your ISP will not honor your QoS markings and policies. Also, any other carriers through which your packets travel will not honor your QoS markings or policies, and will likely mark them all to BE (Best Effort). If your VoIP problems are on the Internet, you can try to fix what is on you network, but you will have no control of the packet treatment on the Internet.

"I wouldn't say that tagging has nothing to do with QoS since the 802.1p bits are only set when frames are tagged (802.1Q)." –  Daniel Dib Mar 16 '16 at 21:34

That's true, but I was looking at it from the perspective of IP QoS. The layer-2 QoS is pretty weak in what you can do and how extensively it is supported. It's unlikely that the switches are causing real VoIP problems, it is more likely the queuing, or lack of it, on the routers. –  Ron Maupin♦ Mar 16 '16 at 21:37

Quality of Service (QoS)

Growth of computer networks and subsequently the “Internet” forced NAT hardware developers to refine their packet handling through the NAT. To accomplish this the newer, more sensitive traffic consumer devices borrowed from the older, more developed Telecom functions resulting in a simplified version of QoS designed for the home user. It allowed a user to specify a priority for a given IP address on a pre-selected port number, for outbound (to the internet) traffic. This freed up much of the congestion caused by lower up-link bandwidths being provided by ISPs but was far from perfect in that it was a ‘Best Effort’ technology, meaning that there were no guarantees that the QoS priorities would be respected by the NAT. It also meant that only outbound traffic would be handled according to these new rules as any incoming traffic would already be at the NAT and therefore couldn’t be throttled due to limited RAM and CPU resources.


Traffic Shaping

Once again borrowing from an older Telecom or Enterprise level technology, Traffic Shaping allows the network appliance to partition and reserve sections of internet connection bandwidth while still accelerating lower bandwidth, latency sensitive application packets. Traditionally this was done by statically assigning bandwidth in bit(s) or Megabit(s), and would generally waste the bandwidth if those applications were not being used at that point. This means that unlike QoS, if you have a 15Mb pipe and you reserve 5Mbs for video and no video is being watched, that 5 Mbs is still not available to the greater pool.

802.1q/802.1p are layer-2 constructs. You'll need gear (switches and routers) that understand those bits. – Ricky Beam Mar 16 '16 at 23:01

A device that can be bridged transparently [is there such a router? routing is NAT, and adding another router is double NAT and isn't transparent] and performs queueing. Don't know which because I haven't searched.
Also the https://zeroshell.org/qos/ page looks informative.

I looked on the internet and a router can be made to act as a switch [no nat, no routing, transparent bridge], dunno if it would work for QoS.

Edit: Found the answer to using router as switch for Qos: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=36113
If you have a spare router it's worth a shot.

[johnson]

I have to say, its very hard to follow your posts spring. There are so many links and quotes, then edits to add more information and emphasis. I find it difficult to understand the points you are making.

This thread was started to talk about whether a bridge mode modem was performing any type of QoS, then you suggest adding a "transparent traffic shaper" to avoid double NAT? Did you suggest double NAT as a way to allow the modem to perform QoS instead of the router?

I'm honestly lost.

Router devices before the modem are capable of controlling upstream and downstream to perform QoS even if the links afterwards are not, are you saying thats not the case? I find it hard from reading your posts to know if thats what you are trying to say.