Maximum throughput
Used when the volume of data transmitted in any period of time is important. There are many types of network applications for which latency is not particularly important but the network throughput is; for example, bulk-file transfers. A network provider might choose to route datagrams with this type of service set via high-latency, high-bandwidth routes, such as satellite connections.
Maximum reliability
Used when it is important that you have some certainty that the data will arrive at the destination without retransmission being required. The IP protocol may be carried over any number of underlying transmission mediums. While SLIP and PPP are adequate datalink protocols, they are not as reliable as carrying IP over some other network, such as an X.25 network. A network provider might make an alternate network available, offering high reliability, to carry IP that would be used if this type of service is selected.
Minimum cost
Used when it is important to minimize the cost of data transmission. Leasing bandwidth on a satellite for a transpacific crossing is generally less costly than leasing space on a fiber-optical cable over the same distance, so network providers may choose to provide both and charge differently depending on which you use. In this scenario, your "minimum cost" type of service bit may cause your datagrams to be routed via the lower-cost satellite route.
Setting the TOS Bits Using ipfwadm or ipchains
The ipfwadm and ipchains commands deal with the TOS bits in much the same manner. In both cases you specify a rule that matches the datagrams with particular TOS bits set, and use the -t argument to specify the change you wish to make.
The changes are specified using two-bit masks. The first of these bit masks is logically ANDed with the IP options field of the datagram and the second is logically eXclusive-ORd with it. If this sounds complicated, we'll give you the recipes required to enable each of the types of service in a moment.
The bit masks are specified using eight-bit hexadecimal values. Both ipfwadm and ipchains use the same argument syntax:
- t andmask xormask
Fortunately the same mask arguments can be used each time you wish to set a particular type of service, to save you having to work them out. They are presented with some suggested uses in Table 9.3.
Table 9.3: Suggested Uses for TOS Bitmasks
| TOS | ANDmask | XORmask | Suggested Use |
|---|---|---|---|
| Minimum Delay | 0x01 | 0x10 | ftp, telnet, ssh |
| Maximum Throughput | 0x01 | 0x08 | ftp-data, www |
| Maximum Reliability | 0x01 | 0x04 | snmp, dns |
| Minimum Cost | 0x01 | 0x02 | nntp, smtp |
Setting the TOS Bits Using iptables
The iptables tool allows you to specify rules that capture only datagrams with TOS bits matching some predetermined value using the -m tos option, and for setting the TOS bits of IP datagrams matching a rule using the -j TOS target. You may set TOS bits only on the FORWARD and OUTPUT chains. The matching and the setting occur quite independently. You can configure all sort of interesting rules. For example, you can configure a rule that discads all datagrams with certain TOS bit combinations, or a rule that sets the TOS bits of datagrams only from certain hosts. Most often you will use rules that contain both matching and setting to perform TOS bit translations, just as you could for ipfwadm or ipchains.
Rather than the complicated two-mask configuration of ipfwadm and ipchains, iptables uses the simpler approach of plainly specifying what the TOS bits should match, or to what the TOS bits should be set. Additionally, rather than having to remember and use the hexadecimal value, you may specify the TOS bits using the more friendly mnemonics listed in the upcoming table.
The general syntax used to match TOS bits looks like:
- m tos -tos mnemonic [other-args] -j target
The general syntax used to set TOS bits looks like:
[other-args] -j TOS -set mnemonic
Remember that these would typically be used together, but they can be used quite independently if you have a configuration that requires it.
| Mnemonic | Hexadecimal |
|---|---|
| Normal-Service | 0x00 |
| Minimize-Cost | 0x02 |
| Maximize-Reliability | 0x04 |
| Maximize-Throughput | 0x08 |
| Minimize-Delay | 0x10 |
Testing a Firewall Configuration
After you've designed an appropriate firewall configuration, it's important to validate that it does in fact do what you want it to do. One way to do this is to use a test host outside your network to attempt to pierce your firewalclass="underline" this can be quite clumsy and slow, though, and is limited to testing only those addresses that you can actually use.
A faster and easier method is available with the Linux firewall implementation. It allows you to manually generate tests and run them through the firewall configuration just as if you were testing with actual datagrams. All varieties of the Linux kernel firewall software, ipfwadm, ipchains, and iptables, provide support for this style of testing. The implementation involves use of the relevant check command.
The general test procedure is as follows:
1. Design and configure your firewall using ipfwadm, ipchains, or iptables.
2. Design a series of tests that will determine whether your firewall is actually working as you intend. For these tests you may use any source or destination address, so choose some address combinations that should be accepted and some others that should be dropped. If you're allowing or disallowing only certain ranges of addresses, it is a good idea to test addresses on either side of the boundary of the range - one address just inside the boundary and one address just outside the boundary. This will help ensure that you have the correct boundaries configured, because it is sometimes easy to specify netmasks incorrectly in your configuration. If you're filtering by protocol and port number, your tests should also check all important combinations of these parameters. For example, if you intend to accept only TCP under certain circumstances, check that UDP datagrams are dropped.