Using vconfig to set vlan tagged interface with 802.1p CoS priority bits set

tux This is just quick how-to on setting up vlan interface on a Linux system. As this is in lengths described elsewhere I will stick just to the commands and brief explanations.

The first thing to do is to get the “vlan” package as it is not normally installed. The other bit is the 8021q kernel module which is not normally loaded but is present on Debian-based systems by defualt.

Checking the state of the module:

lsmod | grep 8021q

if this will return empty result you must load the module using mordprobe

modprobe 8021q

and verify again with lsmod as before.

Now the system is ready to get new tagged interfaces

vconfig add eth0 X

Where eth0 is your physical interface and X is the VLAN ID you want the new interface to be tagged with. The command will have an output saying that interface eth0.X has been created. This is great but you also must now somehow specify what pbit setting do you want in there as by default egress traffic is by default priority 0. In order to make lets say ping ICMP packets marked with CoS we must create an egress map for the default priority (o) in which we will re-map it to whatever we want.

vconfig set_egress_map eth0.X 0 7

In this example I have re-mapped the default priority 0 to egress priority 7

This setup can be made permanent by adding the module name in /etc/modules and adding the relevant lines in the interfaces file e.g.:

auto eth0.100
iface eth0.100 inet static
vlan-raw-device eth0


PackEth tutorial part I – The Inetrface and The Packet Builder

PackEthIn my previous post I have mentioned ingenious piece of software called PackEth and I have also promised that will write up a separate article about it as I just think this amazing tool deserves as much attention as I can give it.  So what this software do?  Well let me quote the author ” PackETH is GUI and CLI packet generator tool for Ethernet…It allows you to create and send any possible packet or sequence of packets on the Ethernet link.” I would add that that it is the only tool I have found that actually allows you to assemble Ethernet frames and a IP packets that actually does what you would expect it to do while being multi-platform and incredibly stable. I think I have never seen it crashing which speaks for itself.  This article will focus around version 1.6 as that is the one that has both Linux and Windows versions available. The drawback is that the L3 IPv6 support is not included.


Getting the package is quite simple as it is a a project hosted on sourceforge. There are versions available fro r Windows Linux and MacOS. But if you are using Linux then there is a good chance that the package will be in your repository (is present in Debian stable and most likely in Ubuntu). Installation is simple – in windows just unpack the .zip file and run packeth.exe – And yes it is completely standalone software so no installation no garbage in registry etc. the installation has all libraries included so the folder after unpacking has about 18MB which I think is very reasonable. I would recommend using Linux version as along with Packeth you will be most likely using WireShark as well and that has some issues on L2 in windows. If you are happy with L3 testing only then the OS choice is irrelevant.

The Gui will open in the builder mode which is probably the most useful and most interesting mode of all the ones that are offered. Switching between the mode you can on the top left part of the menu.


In the middle section you can save and load configuration you have made in the past for repeated testing. In the interface button you will have a selection of interface you can use for PackETH – in Linux it is simple ethX interface. Under windows it is bit more complicated as PackETH doesn’t use the “human readable” name a.k.a. local network 1 or similar but instead it uses the system name which looks like this


If you are wondering where is that name coming from it is an ID from WinPcap library and there is no simple way how to find out which ID is which interface but as normally you want to use just one – you can just disable all the others and read the ID in PackETH. The most important thing is – if you are not a superuser (or have permitted access to network cards on the machine) the interface list will be empty.

The send button is simply sending the frame/stream from the interface. The stop button us useful only when you are running continuous streams as in all other cases.

Builder mode

Is the basic and most interesting for me personally as it allows for complete buildup of a L2 frame/ L3 packet / L4 datagram. It has multiple options and parts which make it incredibly handy.

Data Link Layer

Before going into Data Link Layer of the builder – just a small reminder of how ethernet frame looks like:

ethernet frame

In the Link layer section you can choose which standard of Ethernet you want to use for your frame. The majority of Ethernet traffic in networks nowadays is Ethernet Version II (Also known as DIX). In the last data I’ve read about this topic about 5 years ago were showing that Ethernet II is about 95% of all Ethernet traffic. This should be taken in account when you build your frames as the NIC in your PC might not even be able to build 802.3 frame due to driver restrictions. I have seen this on multiple PCs. Also the receiving party might be dropping this type of frames as despite the attempted compatibility not many vendors actually care about this at all.


If you chose the Ethernet version II frame format the ethertype field (also known as DIX type) will become available. This field identifies what protocol is encapsulated in the frame. The current options are:

  • IPv4  – 0800
  • IPv6 – 86DD
  • ARP – 0806
  • User defined – whatever number you can fit in two octets

Be aware that there is no internal logic of PackETH stopping you from selecting let’s say IPv4 DIX type and then building and ARP packet on higher layer which is incredible advantage if you want to test behavior of equipment to invalid types of traffic, but is easy to overlook when you are not after such specialty.

When we’re in the Data Link layer the next after ethertype is 802.1Q and (in)famous QinQ.

As you can see in the  picture of the Ethernet frame the first field in the 802.1Q shim is the TPID which identifies the following data as part of the shim rather than Ethertype. This fields is followed by  PCP (Priority code point) which is defined in 802.1p and is used for CoS. The priority can be selected from the menu – it also tells the standard meaning of the p-bit in question. But be aware that the numeric value actually means nothing as long as the devices passing this traffic are p-bits aware. Also the mapping is based on standard’s recommendations so in every network it can be used as seen fit by the network admins.


The CFI (canonical format identifier) has been deprecated and re-used drop eligibility but generally it can be just ignored as most equipment just ignores it anyway. The filed of interest is the VID which defines the VLAN ID. The problem with it is that it must be written in hexadecimal digits which is not exactly user friendly but should be no big problem.

The biggest topic in this part is the QinQ. Let’s start with the definition of what is QinQ. As the name suggest it is abbreviation for all sorts of nested VLANs (aka 802.1Q in 8021Q). This practice started as totally non-standard behavior and as a result it has been implemented in many different ways before a standard has been written. The major issue is that the standard is fairly new and mos of network vendors actually doesn’t support the standardized version. Fortunately PackETH support all versions that exist plus some more as you can define whatever you want. So what are our options in the TPID field for QinQ for the outer/SP tag ?


  • 0x8100 – the common vlan – as most vendors even nowadays support and do the original 802.1Q in 802.1Q – extremely common – default almost everywhere
  • 0x9100,0x9200 (and missing 0x9300) – proprietary outer/SP tags used by vendors like Cisco an Juniper and is fairly common on decent equipment
  • 0x8a88 – 802.1ad format that almost no-one supports

So the outer tag we must select from a drop-down list and the TPID for the inner/C tag is  always 0x8100 (that is why the filed is grayed out). So the only thing to do is fill in the VIDs for outer tag and the inner-one. The only next step is to select what is the next layer protocol as L2 configuration is finished.

Network Layer

In the network layer you can chose between ARP and IPv4 (ind IPv6 in the newer version) and user defined payload. All of these are quite simple.

This is how IPv4 setup looks like:


Let’s go through the header fields:

  • Version – should be always set to 4 (that’s why it’s called IPv4)
  • Header length – IPv4 has a variable header length due to existence of “options” field at the least significant position (this causes a lot of issues with L3 aware devices and was important driver in IPv6 development) The header length is in increments of 4 Bytes so the most common value of 20 Bytes would be equal to the default value of 5. This field uses hexadecimal numbers so the allowed values are from 1 to F
  • ToS field as originally defined in RFC2474 Is no longer used as ToS (Type of Service) in about 99% of networks and is deprecated in favor of DSCP (Differentiated Services Code Points) and these are options available:

ToS  and DSCP options

As I have never really used ToS for anything I will not really dive into explaining the variables on this place. I might do that in article I am preparing about QoS theory and its implementation in some equipment types.

  • Total length – calculates the total length of the packet and unless you want to check behavior for runt packets keep it on auto so you will generate valid packets
  • Identification – this is completely useless field no 99% cases as it is only used for reassembly of fragmented packets
  • Flags – very important as it allows/disallows fragmentation of the frame – the best practice here is for the packet to be set to 2 (do not fragment), the other option is “more fragments”  anyway this seems to be broken in the 1.6 windows version and all three values are always zeroes


  • Fragment offset – again in my testing I have found no use for playing with fragmented packets
  • TTL – Time to live – number which is decreasing while the packet is being processed through L3 device might get very handy when you need to prove how many hops away your receiver is
  • Protocol – code informing about what higher-level protocol is encapsulated in the IP packet (options ate TCP,UDP,ICMP and IGMP) again this is just a number in the header of the packet and doesn’t prevent mixup with different protocol actually being configured in upper layer.
  • Header checksum – does exactly what you would expect and again – Unless you are testing runts there is no need to uncheck the tick-box that calculates the checksum for you
  • Source and destination addresses – These do not need any comment
  • Options – a barely used field – I don’t think I ever seen it used and I have never used it myself as far as I remember

If you think – that the IPv4 was pretty simple then ARP will look like a piece of cake. I have to say I like the possibility to send fake ARPs around the network as you can easily populate various tables (specifically APR and switching tables on L2/L3 devices) without having the real source in the network. This allows you to see behavior of elements of your network that would be difficult to observe otherwise. Well there is not much to say about it and here is the screen-shot:


As you probably know ARP has been deprecated in IPv6 and it is now a component of the IP protocol itself and is know as neighbor solicitation.

Session Layer

The session layer provides you with following options : UDP, TCP, ICMP ang IGMP. I will cover all of them briefly as I most of the time do not work with L4. Also IGMP and RTP will be covered in greater detail in an upcoming article about multicasting.


Is the most common protocol I am using as most of the data I am normally dealing with are various voice frames. The Protocol itself is minimalistic and so is the possible setup as you can see below:


The one thing I would like to point out is the option to apply some specific patter of your choice (so ti is not random. This is etremely useful if you have a suspicion that a specific frame with (or within) a specific patter inside is causing some troubles in your network.


TCP is unlike UDP statefull so it must have way more options included to accommodate the windowing mechanism and 3 way handshake and some other minor things. There is a very nice article on Wikipedia about TCP and as I normally do not care much about L4 in testing I will not elaborate on the details here. This is hw the GUI looks like with all the options it has:



This is probably the most interesting of all the L4 protocols as you can actually invoke some actions from the network nodes. The main two options are echo request and echo reply which allows you to send ping to specific nodes (which is not that special) but also fake reply which I have found very useful in the past. The other option is to send network unreachable datagram with all the messages but unless you do testing of L4 aware network (like some firewalls) then it is not of  much interest.



The Internet Group Management Protocol is a predominantly last mile protocol used for membership in various multicast groups. IT is widely used for multimedia delivery specifically – IPTV. It exists in 3 versions and V2 is most widely used (at least to my knowledge).  IGMP is rather simple as it has basically only two types of messages – Query (from router) and Report (from client). As you can see all of those are available to you which is ideal when troubleshooting both ends of the multicast network as combined with Wireshark you can emulate the required response.



The other three parts –  Gen-B mode, Gen-S mode and PCAP will be discussed separately in a follow up article as I must try keeping the length on a readable level.

QoS on Huawei equipment – Custom Queunig

Huawei Logo After some time I have finally some energy to publish a bit more of some stuff about Huawei QoS. The following article will be concentrating on Custom Queuing as it is seen on VRP 3.40 on AR series routers (namely AR46 and AR28).

The first important thing to know is what the Custom Queuing actually does. CQ is a scheduling mechanism so it is in the center of simple QoS model ( classify > schedule > shape) and as all scheduling mechanisms it solves the maths of how much of what,  how and when will be dispatched.

Ok so how the CQ actually works? The mechanism used is round robin with percentage (or as in our case queue byte count which is more precise) with dynamic resource allocation.  So let say we will have a scenario that we want to divide line bandwidth in 2:4 ratio. If there will be congestion the ratio will be taken in account and limits will be imposed. If there is no congestion and the “4” queue is not using the whole assigned bandwidth the “2” queue can occupy more than it’s assigned proportion (i.e. 2,5).

The primary goal of this scheduling mechanisms is to redistribute bandwidth equally, but as you can define almost anything you can use it in more flexible manner.

In the below described scenario we will consider two types of traffic – voice and data (what is case of most SMB companies).

I. Find traffic of interest

As first step you should define how your traffic of interest will be recognized, I used just IP sources but you are limited just by the possibilities provided by any ACL type available.

acl number 3001
rule 5 permit ip source 0
acl number 3002
rule 5 permit ip source 0


II. Create CQ List (CQL)

In the CQL you will define the queues themselves and their behavior. We will use just two parameters which are queue lenhgt and serving. The firs parameter sets maximal length of the queue in the round-robin mechanism, the other defines how many bytes will be served when the queue will be accessed.

qos cql 1 queue 1 queue-length 100
qos cql 1 queue 1 serving 2000
qos cql 1 queue 2 queue-length 100
qos cql 1 queue 2 serving 4000
qos cql 1 protocol ip acl 3001 queue 1
qos cql 1 protocol ip acl 3002 queue 2

Small footnote here – CQ can be used only on IP or MPLS protocols as it does not recognize anything else. From the test I did it seems that  IP over FR worked all right.

IV. assign CQL to an interface

This step is very easy just remember the this should be inbound interface.

interface GigabitEthernet0/0/0
ip address dhcp-alloc
qos cq cql 1

V. shape outbound interface (optional)

As you might be in need of shaping (i.e. you use some reserved bandwidth for other purposes). You might need the shaper in place as otherwise the CQ will allow use of all available bandwidth. In my case I just needed a general traffic shaper. As the shaper below is rather non-intelligent you might want to do this in more granular fashion (i.e. create separate “shaping” QoS policy with another set of rules etc.)

interface GigabitEthernet0/0/0.1
ip address
qos gts acl 3001 cir 500000 cbs 250000 ebs 0 queue-length 50

This config actually shapes the traffic matching ACL 3001 to 0.5mbps

And that is the whole thing. This is a very basic setup so you might want to tweak this as the shaping (and some other things) is bit bulky.

QoS operation on AR28 and AR46 with VRP 3.40

Huawei Logo As one of the previous posts was about configuration of AR46 and 28 series routers this one will be kind of a follow-up article about the QoS on these devices or rather some real example.

But as usually first things first – the dry theory of QoS.  As you probably know QoS is abbreviation for quality of service which is more of a concept and bundle of various technologies which arise up as  a workaround for disadvantages of packet networks (especially Ethernet). I will not bother you which much details as you can find much more detailed descriptions on various places like here. I will stick to a simple example I was creating while ago on a request made to me through e-mail. This post is not supposed to be a complete guide through Huawei’s QoS. For the complete QoS overview please wait for the full article that will be posted shortly. This is the scenario I was putting together.

Step I. – Finding the traffic of interest

I personally prefer to do this on ACL basis (as opposed to the per interface  and some others) as this method gives you complete freedom of what and how you select your traffic. As usually it is good practise to use the basic ACLs instead of the advanced as they are less CPU hungry. The important consideration is that this method in general will cause some additional load on your router’s CPU. Let’s say that we would like to define three classes Voice, Data and Default.

acl number 2001 name voice
rule 5 permit ip source 0 destination any
acl number 2002 name data
rule 5 permit ip source destination any
acl number 2003 name default
rule 5 permit ip source any destination any

As usually the better and simpler you ACLs will be  the better performance will your router have. I used source IP addresses as the way of detection of the traffic flows but you can define the rules on whatever ACLs will allow you. There are no limits for QoS.

Step II. – Setting the scheduling mechanism

The decision what scheduling and queuing mechanism you want to use is probably the most important one as  there is at least five types of them. Those ones I’d like to mention are only two PQ (strict priority queuing) or CBWFQ (class based weighted fair queuing). PQ is more simple and better for certain cases where some bandwidth is permanently assigned to some kind of traffic but it has also one huge disadvantage. It is the most bandwidth wasting method you could think of. The other (and default till VRP 3.40 including) is CBWFQ (class based weighted fair queuing) which is somehow more complex but has some serious advantages. Like better bandwidth management etc. (will be seen later on). So for our example we will use CBWFQ.

Step III. -Setting the classifier

As we are using CBWFQ we have to define the classes of the traffic

traffic classifier VOICE operator or
if-match acl 2001
traffic classifier DATA operator or
if-match acl 2002
traffic classifier DEFAULT operator or
if-match acl 2003

So now we had bound the ACLs to the classifier so it could be used later on in the QoS policy.

Step IV. – Setting the traffic behaviour (aka what will happen to the traffic in question)

Traffic behavior can be set either in percentage or in absolute numbers, and to be clear the second option is much better as percentage is just an estimation based on number of packets in some previous period of time. I also used dscp values as the queuing mechanism will take the values in consideration while processing the frames so this is in fast prioritization (the packets will be re-marked no matter what the previous value in TOS field would have been).

traffic behavior VOICE
queue af bandwidth pct 80
traffic behavior DATA
queue dscp af2 bandwidth pct 15
traffic behavior DEFAULT
queue dscp af1 bandwidth pct 5

Step V. – Creating the policy

Here you bind together all the above defined into one policy you will apply later on the interfaces.

qos policy qos
classifier VOICE behavior VOICE
classifier DATA behavior DATA
classifier DEFAULT behavior DEFAULT

So for every classifier just attach desired behaviour and that is it.

Step VI. – Applying the policy

interface Ethernet1/0
ip address
qos apply policy qos inbound

Now your policy is on inbound interface and should be working fine. There is one step missing though and that’s shaping on outbound. This could be done by the following procedure.

Step VII. – Outbound Traffic Shaping (optional)


interface Ethernet1/1
ip address 255.255.255.
qos gts acl 2001 cir 256000 cbs 128000 ebs 0 queue-length 50
qos gts acl 2002 cir 50000 cbs 2500 ebs 0 queue-length 100
qos gts acl 2003 cir 1000 cbs 6250 ebs 0 queue-length 50

As you can notice I used gts (general traffic shaper) for the shaping again matching the same ACL (I could use different but re-using should be more CPU sensitive) with some values which needs to be explained :

  • cir = committed information rate = desired reserved bandwidth,
  • cbs= committed burst size (buffer) = 1/2 cir (recommended, differs by HW and VRP version)
  • ebs= exceeding burs size (overflow buffer) = 0 (unless you have a real need for it)
  • queue-length = max buffer in bytes

Shorter queue is for voice as we do not really want to store delayed voice packets and the longer queue is for less delay sensitive services. These numbers were  created for certain case and if you want to use them you should recalculate them for proper values before using! As you can count this scenario was using a 256K as a guaranteed for voice and 50K for the data and 1K some rubbish traffic.

That’s it. In the next articles I will get to some more complex scenarios, QoS on switches and some tweaks.