Using tc directly to manage rate limiting can be tricky and a little bit complex to understand. I have found that shorewall provides an easy to use and understand interface to achieve the same purpose. The concept is based on devices, rules and classes as represented by the three files in shorewall – tcdevices, tcrules and tcclasses.
The devices basically refer to the interfaces rate limiting should happen; the rules are the different types of traffic that you wish to implement rules for. ie : all inbound http traffic should be given a certain class; And the classes define how the rating is done for that class.
In my example, I have a 10Mb/s connection to the internet that I need to share between office use, external servers such as DNS and HTTP and some other thing such as VPN access. In my /etc/shorewall/tcdevices I have specified my internet facing interface:
#INTERFACE IN-BANDWITH OUT-BANDWIDTHeth2 10mbit 10mbit
I then define some rules such as :
1 0.0.0.0/0 0.0.0.0/0 tcp 20,21,22 1 0.0.0.0/0 0.0.0.0/0 tcp - 20,21,22 2 0.0.0.0/0 0.0.0.0/0 tcp 53 2 0.0.0.0/0 0.0.0.0/0 udp 53
The above ‘tags’ the packets that match the follow rules. So as an example, all ssh traffic is tagged as 1. In my full example I have rules that make up 4 tagged ‘classes’. In the tcclasses file I have the following:
#INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth2 1 10*full/100 full 1 eth2 2 44*full/100 full 2 eth2 3 14*full/100 full 3 eth2 4 28*full/100 full 4 eth2 5 4*full/100 10*full/100 5
What I basically have now is the identification of the type of traffic I want to shape (done by the rules) and over which interface I want to apply the shaping (done by the devices). The classes then determines the amount of bandwidth assigned for each rule.
If you, like me, run a linux firewall you may find your connection doing weird things like taking a long time or sometimes dying completely – often with little to no load on the machine. One thing that is worth looking at is the maximum number of tracked connections that the firewall is maintaining:
# cat /proc/sys/net/ipv4/ip_conntrack_max 16640
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
The above shows that the maximum number of connections has been reached. Once this starts happening, then connections that can no longer be maintained will be dropped – causing all kinds of trouble.
kernel: ip_conntrack: table full, dropping packet.
The way around this is to increase the number of maximum connections. This can be done easily and on the fly by running the following command:
# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count 44796
To make the configuration permanent across reboots the following line must be added to the /etc/sysctl.conf file:
net.ipv4.ip_conntrack_max = 131072
ZDNet have an interesting article – http://blogs.zdnet.com/BTL/?p=28005&tag=nl.e539 10 features that should be in Windows by default that are in Linux.
Here are my 10 –
- SSH. Secure remote connectivity to a machine. How windows admins survive with only having VNC or Terminal server is beyond me.
- Exchange support. Out of the box Windows cannot support exchange. This is absurd. Both Linux and Mac support this out the box.
- A Web server. Being able to throw up a simple page for any reason is really handy at times.
- Syslog. To be able to capture all logs either locally or a centralised logging server.
- Top. A quick text based view on what the hell is eating up all your resources.
- VLC. To this day I still struggle with ‘Codecs’. Nightmare. Install VLC and be done with it – watch any format of video and also play MP3s. It is also a streaming server.
- vi / vim. Edit and notepad just does not cut the mustard.
- KVM. Virtual machine support out of the box.
- LVM. Built in enterprise class volume management system.
- Firefox. Yes, yes I know that windows has a browser… but it is shit.
If IPtables is too daunting for you, then shorewall is probably the easiest way to setup and maintain an iptables based firewall on Linux. Let me go through the basics.
Interfaces & Zones
Shorewall builds some intelligence into your firewall thinking. Networks can be considered as ‘zones’ – i.e. your internet interface (ppp0) could be your ‘web’ zone and your internal network could be considered as your ‘int’ zone. I do not know why shorewall only allows 3 letter zone names… but that is not relevant here.
So – what I am doing is setting up a basic internet sharing firewall. It has 2 zones (web & int) for WWW and internal network. first thing, setup up your interfaces file:
# vi /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS web ppp+ - dhcp,upnp int eth0
Here are my 2 zones – my dialup interface (ppp) and my internal network (eth0). The ‘+’ in ppp+ simply means it is a wildcard (ppp0,ppp1…etc). I have specified dhcp in my options to indicate that this interface gets it’s ipaddress dynamically. See man shorewall-interfaces for more information on interfaces.
For this example – /etc/shorewall/zones is very basic. Unless you are doing IPSEC tunnelling or any other fancy stuff, you can input the following:
# vi /etc/shorewall/zones #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall web - int -
You see that there are three zones in the zones file. The third one is a zone for the firewall itself.
This is where Shorewall makes some sense over other firewalls. Instead of having millions of rules from one zone to another, you can simply specifiy a policy for communication between entire zones. You need not have a separate rules in addition like some firewalls do – Juniper. Here I have setup two policies that allow the Firewall to get to the other zones:
# vi /etc/shorewall/policy #SOURCE DEST POLICY LOG LIMIT CONNECTLIMIT $FW web ACCEPT $FW int ACCEPT
I then want to ensure that the internal zone (int) can get out to the internet (web) and I want to be able to administrate the firewall from my internal zone from any of my internal machines. You may not want the second policy, but I am just putting it in as an example.
int web ACCEPT int $FW ACCEPT
I then want to implement a default drop policy for internet traffic (web) to the firewall or my internal network and it’s a good idea to have a reject ALL ALL rule at the end.
web all ACCEPT all all ACCEPT
So now you have default policies based on your zones. You do not need to manage individual rules for inter-zone traffic.
Masquarade / NAT
Ok this is the part that makes your internet connection sharing work. Effectively what you want to do is have all your internal machines route through you firewall. To do this, you must NAT your internal traffic to your internet interface on your firewall. Shorewall makes this so simple. One line:
# vi /etc/shorewall/masq eth0 192.168.2.0/24 detect
Done. Restart the service – /etc/init.d/shorewall restart. You now have internet sharing for your internal network users through your linux firewall.
The last thing that you may want to do is to have traffic from the web reach a particular machine in the network. For example, you may have a web server on your internal network that want to be accessible from the internet – this simple rule will allow traffic to be forwarded from the firewall to the correct machine on the internal network:
# vi /etc/shorewall/rules DNAT web int:192.168.2.100 tcp 80,443
The rule implements allows traffic from the internet (web) to the internal network machine – 192.168.2.100 on tcp ports 80 and 443.
That is really just a basic introduction to shorewall. To see the syntax of any of the shorewall the man pages are accessible as follows:
# man shorewall-rules
If Snow Leopard can no longer see your Huawei device, you will no doubt need to visit this page – http://www.huaweidevice.com/resource/mini/200910149695/testmobile1014/index.html.
It seemed a little confusing at first, installing the software, but what you need to do is run the installer and when it asks for the application to install, you need to point it towards the mobile partner application on the internal drive.
There is also another method which involves removing some Kext files and then re-installing them, but this way is far easier.
Once done, there are three Huawei interfaces in the network preferences.
One of the challenges that has faced our company, and most probably many other companies, has been the lack of adoption of any inventory management system. When things are done in a hurry, as was our case, key system management tools were completely left out. Its not that they were not thought of, it’s just that they were deemed less important.
Two years down the line, the money dried up and the (greatly exaggerated) profits to back the business cases for expensive proprietary hardware and software have not been forthcoming, the questions are starting to be asked – “What hardware do we actually have?” and “how can we utilize it elsewhere in the environment?”. We also hear on almost a daily basis – “There is no money for hardware next year, we will have to make do with what we have got.” While big plans to roll out ludicrously expensive software platforms are still being entertained and IBM p570 systems are left to rot.
Some of it is amusing and some of it is depressing, especially when useful open source tools performing important tasks like monitoring – which were never present before – are described by top level management as ‘freebies’… :S
One tool that has caught the eye of management though is GLPI. It is a web based inventory / asset management tool written in php using a MySQL db backend. It has a very impressive array of features and is very simple to use.
Our deployment involved integration with the equally excellent OCS. This allows an agent to run on each and every server in our environment to regularly update the inventory information. GLPI then comes along and helps itself to the information collected. It will pick up almost every little detail about the server from the serial number to the speed of the RAM.
GLPI has built in support for LDAP / AD as well as offering POP3 and IMAP as user authentication mechanisms. GLPI also offers the ability to associate assets with documentation and maintenance contracts, capable of alerting when contracts are about to expire. An array of plugins allow for functionality such as IP address management and dynamic architecture diagrams make this application a very very useful tool.
There is also built in help desk support for ticketing. It is very simple but provides the ability for tickets to be logged against assets. GLPI can be configured for managing assets in various locations and various states. For example you could have a server that is not yet deployed and GLPI would be able to capture that it is in storage and where it is physically. This is useful for determining whether servers are in production, testing or QA. GLPI also has support for devices such as modems and phones, providing a handy way of managing resources that have legs.
In an environment where every resource needs to be squeezed to the limit and every asset accurately accounted for, GPLI provides us a comprehensive platform to manage our equipment.
Don’t you just hate it when you go through the Fedora install, specifically select KDE as your desktop manager and yet you are still faced with GDM… It used to be the case where you could edit a sysconfig file, but for reasons best known to the gnome zealots at Fedora, it is well and truly hidden.
Well, fear not. edit :
and change the order of the display managers in the sript.
Total fail imho.