Auto QoS is a great feature included with the majority of switches running at least the LAN Base feature set. It will likely require some further tweaking after it's setup however it's a great base for applying QoS.
Cisco provides support for it's own telephony devices (surprise, surprise!) through CDP broadcasts. However in my case I am working with a different vendor and since not all switches will provide classification of packets I'm relying on the tagging being performed by the downstream devices.
It's very simple to setup - simply apply the following to the switch ports in scope (i.e. the ones connected to the telephony devices):
conf t
int range gi1/0/1-10
auto qos trust dscp
end
This will instruct the switch ports in scope to trust DSCP markings applied by the downstream devices (as I'm sure you're aware by default DSCP marking are typically stripped.)
The 'auto qos trust dscp' also enables qos globally for us and also applies a few other directives on the interface - so in reality a lot of the setup is performed for you - however in reality it's still crucial that you understand what each directives means!
do show run int gi1/0/1
interface GigabitEthernet1/0/1
switchport access vlan 2000
switchport mode access
speed auto
srr-queue bandwidth share 1 30 35 5
priority-queue out
mls qos trust dscp
auto qos trust dscp
spanning-tree portfast
spanning-tree bpduguard enable
To verify QoS is turned on globally we can review:
show mls qos
and to review interface specific QoS information:
show mls qos interface gi1/0/1
We can also test QoS is successfully prioritising packets with iperf (tagging the traffic with a non zero DSCP value) e.g.:
iperf -c 10.11.12.13 -i 1 -S 0xB8 -t 0
'0xB8' is the hexadecimal equivalent of TOS's 184 - which equates to DSCP's 'ef' / 46. According to the man page (at least in mine) the value must be in hexadecimal TOS form. There is an list of all of them available here.
We can then review the QoS counters for the interface with:
show mls qos interface gi1/0/1 stat
Pages
▼
Wednesday, 29 May 2019
Thursday, 23 May 2019
Cross compile packages for OpenWRT / LEDE
For this tutorial I'll be using Fedora 29 for the build host.
We'll install the necessary dependencies firstly:
sudo dnf install asciidoc binutils bzip2 flex git gawk intltool zlib gmake ncurses openssl-devel patchutils p5-extutils-makemaker unzip wget gettext libxslt zlib-devel boost-jam perl-XML-Parser libusb-devel dev86 sharutils java-1.7.0-openjdk-devel b43-fwcutter zip
The next step is to obtain the OpenWRT SDK which will allows us to cross-compile packages that we require on OpenWRT.
I'll be using a BT Home Hub 5A for this exercise - so I browse the releases:
Under the supplementary section you should find the SDK e.g.
We'll proceed by downloading and extracting it:
The default feeds will be targeted at 17.01.4 and hence be missing fping - however the current master branch has fping available - so we'll add the following line to feeds.conf.default ensure it's indexed / available:
Update the feeds (as defined in feeds.conf.default):
and grab fping with:
We'll generate our config file:
Select 'Network' and ensure the fping package is marked with an 'M' and then save the changes to '.config'
Also make sure that cryptographic signing is disabled (otherwise the build process will fail): 'Global build settings' > Untick 'Cryptographically sign package lists' and hit Save.
We'll now attempt to compile fping:
The binary is created in the following directory:
Finally upload the package via SFTP/SCP to the router and install it with opkg:
We'll install the necessary dependencies firstly:
sudo dnf install asciidoc binutils bzip2 flex git gawk intltool zlib gmake ncurses openssl-devel patchutils p5-extutils-makemaker unzip wget gettext libxslt zlib-devel boost-jam perl-XML-Parser libusb-devel dev86 sharutils java-1.7.0-openjdk-devel b43-fwcutter zip
The next step is to obtain the OpenWRT SDK which will allows us to cross-compile packages that we require on OpenWRT.
I'll be using a BT Home Hub 5A for this exercise - so I browse the releases:
https://downloads.openwrt.org/releases/17.01.4/targets/lantiq/xrx200/
Under the supplementary section you should find the SDK e.g.
lede-sdk-<version-number>-<vendor>-<model>_gcc-<version number>_musl-<version number>.Linux-<architecure>.tar.xz
We'll proceed by downloading and extracting it:
wget https://downloads.openwrt.org/releases/17.01.4/targets/lantiq/xrx200/lede-sdk-17.01.4-lantiq-xrx200_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz
tar xvf lede-sdk-17.01.4-lantiq-xrx200_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz && cd lede-sdk-17.01.4-lantiq-xrx200_gcc-5.4.0_musl-1.1.16.Linux-x86_64
The default feeds will be targeted at 17.01.4 and hence be missing fping - however the current master branch has fping available - so we'll add the following line to feeds.conf.default ensure it's indexed / available:
src-git fping https://github.com/openwrt/packages.git
Update the feeds (as defined in feeds.conf.default):
./scripts/feeds update -a
and grab fping with:
./scripts/feeds install fping
We'll generate our config file:
make menuconfig
Select 'Network' and ensure the fping package is marked with an 'M' and then save the changes to '.config'
Also make sure that cryptographic signing is disabled (otherwise the build process will fail): 'Global build settings' > Untick 'Cryptographically sign package lists' and hit Save.
We'll now attempt to compile fping:
make -j1 V=s
The binary is created in the following directory:
bin/packages/mips_24kc/fping/
Finally upload the package via SFTP/SCP to the router and install it with opkg:
opkg install fping_4.2-1_mips_24kc.ipk
Wednesday, 8 May 2019
Linux: Backup Options
There are countless ways to backup disks easily with Linux - however I'm going to demonstrate some of the more commonly used methods.
Forenote: Always ensure the discs are not in use / mounted while performing the below operations otherwise it is likely that new / changed files will be corrupted and will run into problems with the file system.
Backing up a disk with dd
sudo dd if=/dev/xvda of=/mnt/usbdrive | sync
or better yet we can use a sane block size (dd uses 512 bytes by default):
sudo dd bs=16M if=/dev/xvda of=/mnt/usbdrive | sync
Backing up a disk with dd over ssh
Utilising SSH provides us with encryption - ideal for remote backups e.g. over public networks:
sudo ssh user@remote "dd if=/dev/xvda1 " | dd of=backup.gz
However it does introduce an overhead due to the encryption - so we can pipe it into gzip in order to speed things up:
sudo ssh user@remote "dd if=/dev/xvda1 | gzip -1 -" | dd of=backup.gz
Backing up a mounted system with rsync
Forenote: Always ensure the discs are not in use / mounted while performing the below operations otherwise it is likely that new / changed files will be corrupted and will run into problems with the file system.
Backing up a disk with dd
sudo dd if=/dev/xvda of=/mnt/usbdrive | sync
or better yet we can use a sane block size (dd uses 512 bytes by default):
sudo dd bs=16M if=/dev/xvda of=/mnt/usbdrive | sync
Backing up a disk with dd over ssh
Utilising SSH provides us with encryption - ideal for remote backups e.g. over public networks:
sudo ssh user@remote "dd if=/dev/xvda1 " | dd of=backup.gz
sudo ssh user@remote "dd if=/dev/xvda1 | gzip -1 -" | dd of=backup.gz
Backing up a mounted system with rsync
If the system is currently mounted we can use rsync to perform a backup (ensuring we exclude certain directories such as /dev, /mnt etc):
sudo rsync -aAXv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt
In the above command we employ 'archive' mode that ensures symbolic links, devices, permissions, ownerships, modification times, ACLs, and extended attributes are preserved.
and over rsync over SSH
There are of course many other ways to skin a cat e.g. using netcat (which is significantly faster than dd over SSH - however lacks encryption.)
and over rsync over SSH
sudo rsync -aAXve ssh user@remote:/ --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt
There are of course many other ways to skin a cat e.g. using netcat (which is significantly faster than dd over SSH - however lacks encryption.)
Sources