Lecture #21 - Asynchronous Transfer Mode (ATM)

ATM is a major traffic carrier used by telecommunication companies. ATM is also the core networking technology used to aggregate and connect ADSL tail circuits to ISPs. ATM provides for virtual circuits and can guarantee Quality of Service (QoS).
Some of the key concepts involved in ATM include:

• The basic unit of transmission is the cell. A cell is 53 bytes in length - 5 bytes of header and 48 bytes of payload. These small, fixed-format cells can be switched very quickly.
• ATM networks are based on connection-oriented cell relay - cells are multiplexed onto higher bitrate channels, but there is no timing relationship between individual cells within a particular connection. Cells may be dropped but are never delivered out of order.
• The telecommunications industry uses ATM as a basis for providing converged services, allowing for the seamless integration of voice (telephony), audio, video-on-demand, video conferencing, video broadcast and data, on the one network.
• ATM is complex. Even the telcos admit it has many unsolved problems.

ATM Background

• Designed in early 1990s, when both bandwidth and networking equipment was relatively expensive, and voice and data convergence was a hot topic in the industry.
• A technology evolved more from the telecommunications industry than the computer/data industry.
• Designed for high-performance mixed network traffic (voice, data, video, and future media applications).
• Designed for bursty traffic.
• Designed to replace all existing analog and digital communication backbone systems.
• A relatively expensive networking technology, mainly used among tier 1 and tier 2 telcos.
• Gigabit Ethernet (a much cheaper technology) has replaced ATM on many networks. ATM is Less popular now.
• Gigabit Ethernet is a natural upgrade path for Fast Ethernet.
• ATM offers QoS, but QoS issues can simply be overcome by providing a bigger pipe?

"Arguably, ATM is unnecessary if bandwidth is cheap and plentiful, and there is no congestion in the network."
"Experience has also shown that over-provisioning bandwidth does not resolve all QoS issues. Hence Gigabit Ethernet is not expected to replace ATM at this time."

ADSL Information

~ New! Broadband Availability Checker - Checks adsl line and exchange status.   ~ Max Speed Calculator - Indication of your maximum speed.   ~ How to get your line stats from your router   ~ How to understand your line stats   ~ Connecting and adsl filters.   ~ Networking and setting up a router   ~ How adsl works.   ~ Different types of adsl - IPStream, Datastream + LLU   ~ DSL Max & Interleaving   ~ How DSLMax works & your bRAS IP Profile information   ~ Troubleshooting and adsl connection problems   ~ Common Faults - Low SNR and REIN faults   ~ Understanding SNR and attenuation   ~ Slow speed problems   ~ MTU Problems and MTU tweaking                                                         

http://www.kitz.co.uk/adsl/index.htm

What is Clonezilla?

You're probably familiar with the popular proprietary commercial package Norton Ghost®. The problem with these kind of software packages is that it takes a lot of time to massively clone systems to many computers. You've probably also heard of Symantec's solution to this problem,Symantec Ghost Corporate Edition® with multicasting. Well, now there is an OpenSource clone system (OCS) solution called Clonezilla with unicasting and multicasting!
Clonezilla, based on DRBL, Partclone and udpcast, allows you to do bare metal backup and recovery. Two types of Clonezilla are available,Clonezilla live and Clonezilla SE (server edition). Clonezilla live is suitable for single machine backup and restore. While Clonezilla SE is for massive deployment, it can clone many (40 plus!) computers simultaneously. Clonezilla saves and restores only used blocks in the harddisk. This increases the clone efficiency. At the NCHC's Classroom C, Clonezilla SE was used to clone 41 computers simultaneously. It took only about 10 minutes to clone a 5.6 GBytes system image to all 41 computers via multicasting!

Perbedaan redirect to proxy memakai dst-nat dan mark-routing

Mungkin selama ini anda tidak pernah menyadari traffic sebuah server yang mengirimkan data atas permintaan ip klien jika menggunakan dst-nat to proxy itu server akan mengirim ke ip proxy bukan langsung ke ip klien yang telah melakukan permintaan tadi

Jadi kita akan mengalami kesulitan jika ingin membuat rule bypass/limit untuk ip server (port 80) yang dari luar yang telah masuk ke ip proxy

td 8117 exploit

http://carnal0wnage.attackresearch.com/
http://www.exploit-db.com/exploits/10276/
http://www.securityfocus.com/archive/1/349085
http://www.cvedetails.com

ultimate.sh

#!/bin/bash
# ultimate.sh for duron
# Based on Wonder Shaper v1.1a
echo "/usr/sbin/ultimate.sh:  "

# Please read the README before filling out these values.
# Set the following values to somewhat less than your actual download
# and upload speed in kilobits.  Also set the device that is to be shaped.

# Run a speed test from netspeed.stanford.edu with no shaping enabled.
# Multiply the reported rates in Kb/s by ~.95 and enter them here:
# Example: DNLINK=4.76M*.95 = 4522
#          UPLINK=444.26K*.95 = 422
# Run the stanford test again.  Note: stanford uses high ports.
# Tweak during heavy upload so that each affected class has a small backlog but
# as few dropped packets as possible.  Interactive must NEVER backlog!
# If heavy downloads affect uploads, tweak IMQ so there is a small backlog but
# as few dropped packets as possible.
# Watch the logs for "some class has too small rate" even with quantum set.
# Stanford is in class 30; egress rate 36% ceil 92%, ingress rate 57% ceil 92%
# Download w/HTB is plenty (5.2x), don't tweak.
# Upload w/UPLINK=470 -> range 416 - 420 = ~85% of uCEIL.  Try for 90% - 91%.

fw_function

#-----------------------
# FONCTIONS Firewall
# guibo@guibo.com
# version 1.2
# tested on slk
#-----------------------

load_module() {
IP_MODULES=`/sbin/lsmod | awk '{print $1}' | /bin/grep '^ip' | grep $1`
if [ -z "$IP_MODULES" ]; then
    if [ -e $PATH_modules/$1.$EXTENSION_module ]; then
            /sbin/insmod $PATH_modules/$1.$EXTENSION_module
            else
            echo " - MUST HAVE Compiled kernel $1 support"
    fi
fi
}

load_module_q() {
IP_MODULES=`/sbin/lsmod | awk '{print $1}'`
if [ -z "$IP_MODULES" ]; then
    if [ -e $PATH_modules_q/$1.$EXTENSION_module ]; then
            /sbin/insmod $PATH_modules_q/$1.$EXTENSION_module
            else
            echo " - MUST HAVE Compiled kernel $1 support"
    fi
fi
}

Traffic Control

Introduction

Linux's traffic control functionality offers a lot of capabilities related to influencing the rate of flow, as well as latency, of primarily outgoing but also in some cases incoming network traffic. It is designed to be a "construction kit" rather than a turn-key system, where complex network traffic policing and shaping decisions can be made using a variety of algorithms. The Linux traffic control code is also often used by academia for research purposes, where is it can be a useful mechanism to simulate and explore the impact of a variety of different network behaviors. See netem for an example of a simulation framework that can be used for this purpose.

Of course, Linux traffic control can also be extremely useful in an IT context, and this document is intended to focus on the practical, useful applications of Linux traffic control, where these capabilities can be applied to solve problems that are often experienced on modern networks.

IPTables U32 Match Tutorial

Introduction

IPTables has always been a relatively flexible and modular firewall; if it can't currently test for a particular packet characteristic, you have the option of writing a test or modifying an existing test. The catch - as with so much of open source - is that most of us aren't programmers.
It turns out we do have an option that doesn't require programming. Don Cohen was kind enough to write an IPTables module that pulls any bytes you'd like out of the packet, does some manipulation, and sees if the result is in a particular range. For example, I can grab the Fragmentation information out of the IP header, throw away everything except the More Fragments flag, and see if that flag is set.
Without writing any C code at all. :-)
What I'll do is introduce the core concepts here, and put in hopefully enough annotated examples that you'll be able to write your own tests.
I won't be focusing on what these fields are, or why you'd want to test them; there are lots of (warning - shameless plug for my employer ahead!) resources for doing that. If you simply need a quick reference for the packet headers, see tcpip.pdf.
All byte positions in this article start counting at 0 as the first byte of the header. For example, in the IP header, byte "0" holds the 4 bit "Version" and 4 bit "IP Header Length", byte "1" holds the "TOS" field, etc.

unix toolbox

This document is a collection of Unix/Linux/BSD commands and tasks which are useful for IT work or for advanced users. This is a practical guide with concise explanations, however the reader is supposed to know what s/he is doing.

squid hardware

Squid has a lot of parameters that are set in a file called squid.conf. These should be tuned according to the application. What I am describing below are changes to the default parameters that we needed for the Frontier application. The normal application for squid is to cache internet web pages, which is a bit different. For web pages there are lots and lots of rather small objects. In our applications there are relatively few objects, but they are much, much bigger. You should use a squid of at least version squid-2.6.X to get collapsed_forwarding (see below). Warning: All versions of squid before September 2009 have a bug that affects Frontier performance, so you should use squid version squid-2.7.STABLE7 or later. If your squid might be feeding other squids then we highly recommend using our version as we have patches that have not yet (as of September 2010 at least) been incorporated by the squid project. UNDER NO CIRCUMSTANCES use version squid-3.X as it is missing features and bug fixes essential to Frontier.

linux network tune

Don't try this yourself, you might break something. These recommendations were from Pete Vogel, who runs a bigger site than you do (can you do 85Mb/s on just one server? .. and he has many!!). Don't change these params unless you understand them. I am working on adding explainations. Amongst other things (like breaking your network connectivity), you might actually make your machine slower if you just blindly use them. In fact, I only set a couple of them. And always best to set one at a time to see if you notice the improvement you are looking for.

mikrotik hardcoded

1. Lan card ada 2
2. Alokasi IP address pada Mikrotik Hotspot Gateway :
- to_hotspot ip public
- to_hotspot 10.10.0.1/16

/ip firewall filter add chain=block-forward action=accept protocol=icmp icmp-options=8:0 limit=1,0 comment=”Allow ICMP”

/ip firewall filter add chain=block-forward action=log tcp-flags=syn protocol=tcp limit=5/1m,0 log-prefix=”Firewalled packet:” comment=”# Log Forward”

/ip firewall filter add chain=block-forward action=log protocol=icmp icmp-options=8:0 limit=10/1h,0 log-prefix=”PING of Death ???” comment=”# Log PING of Death”

/ip firewall filter add chain=block-forward action=drop src-address=169.254.0.0/16 comment=”# Block bad IP address”

/ip firewall filter add chain=block-forward action=drop src-address=224.0.0.0/3

/ip firewall filter add chain=block-forward action=drop src-address=224.0.0.0/4

/ip firewall filter add chain=block-forward action=drop src-address=240.0.0.0/5

/ip firewall filter add chain=block-forward action=drop src-address=248.0.0.0/5

/ip firewall filter add chain=block-forward action=drop src-address=255.255.255.255

/ip firewall filter add chain=block-forward action=drop connection-state=invalid comment=”# Drop invalid connections”

/ip firewall filter add chain=block-input action=accept protocol=icmp icmp-options=8:0 limit=5,0 comment=”# Allow ICMP”

/ip firewall filter add chain=block-input action=log protocol=icmp icmp-options=8:0 limit=10/1h,0 log-prefix=”PING of Death ???” comment=”# Log PING of Death”

/ip firewall filter add chain=block-input action=log tcp-flags=syn protocol=tcp limit=5/1m,0 log-prefix=”Firewalled packet:” comment=”# Log input”

/ip firewall filter add chain=block-input action=drop protocol=icmp comment=”# Block PING of Death”

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=10.0.0.0/8 comment=”# Interface facing Public Internet Inbound Section RFC 1918″

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=202.91.11.6

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=192.168.0.0/16

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=202.91.8.160/29

/ip firewall filter add chain=block-input action=drop src-address=0.0.0.0/8

/ip firewall filter add chain=input action=jump jump-target=block-input comment=”# Jump to block-input”

/ip firewall filter add chain=forward action=jump jump-target=block-forward comment=”# Jump to block-forward”

/ip firewall filter add chain=forward action=jump jump-target=block-ddos protocol=udp comment=”# Jump to block-ddos”

/ip firewall filter add chain=forward action=jump jump-target=block-service comment=”# Jump to block-service”

/ip firewall filter add chain=block-service action=drop p2p=all-p2p comment=”# Block ports you don’t want it insert here ..:: drop p2p ::..”

/ip firewall filter add chain=block-service action=drop out-interface=to_internet dst-port=5050 protocol=tcp comment=”..:: drop yahoo messenger ::..”

/ip firewall filter add chain=block-service action=drop out-interface=to_internet dst-port=6666-7000 protocol=tcp comment=”..:: drop irc ::..”

/ip firewall filter add chain=block-input action=drop src-address=127.0.0.0/8

/ip firewall filter add chain=block-input action=drop src-address=169.254.0.0/16

/ip firewall filter add chain=block-input action=drop src-address=172.16.0.0/12

/ip firewall filter add chain=block-input action=drop src-address=192.0.2.0/24

/ip firewall filter add chain=block-input action=drop src-address=204.152.64.0/23

/ip firewall filter add chain=block-input action=drop src-address=224.0.0.0/3

/ip firewall filter add chain=block-input action=drop src-address=224.0.0.0/4

/ip firewall filter add chain=block-input action=drop src-address=240.0.0.0/5

/ip firewall filter add chain=block-input action=drop src-address=248.0.0.0/5

/ip firewall filter add chain=block-input action=drop src-address=255.255.255.255

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=202.91.8.167 comment=”# Block Smurf Attack on all interface”

/ip firewall filter add chain=block-input action=drop in-interface=to_internet src-address=202.91.11.7

/ip firewall filter add chain=block-input action=drop in-interface=to_hotspot src-address=10.10.255.255

/ip firewall filter add chain=block-input action=drop in-interface=to_proxy src-address=192.168.100.255

/ip firewall filter add chain=block-input action=drop dst-port=113 protocol=tcp comment=”# Block Ident”

/ip firewall filter add chain=block-input action=drop fragment=yes comment=”# Block IP Frags”

/ip firewall filter add chain=block-input action=drop ipv4-options=loose-source-routing comment=”# Blocked source routed packets lsrr and ssrr”

/ip firewall filter add chain=block-input action=drop ipv4-options=strict-source-routing

/ip firewall filter add chain=block-input action=reject reject-with=tcp-reset in-interface=to_internet dst-port=80 protocol=tcp comment=”# Reject connection from internet to port 80”

/ip firewall filter add chain=block-forward action=reject reject-with=tcp-reset tcp-flags=syn,ack connection-state=new protocol=tcp comment=”# Reject Bad TCP”

/ip firewall filter add chain=block-forward action=drop protocol=icmp comment=”# Block PING of Death”

/ip firewall filter add chain=block-input action=drop in-interface=to_internet dst-port=23 protocol=tcp comment=”# Block Telnet come from Internet”

/ip firewall filter add chain=block-input action=drop in-interface=to_hotspot dst-port=23 protocol=tcp comment=”# Block Telnet come from Hotspot”

/ip firewall filter add chain=block-forward action=drop dst-port=137-139 protocol=tcp comment=”# Block Netbios Sessions tcp”

/ip firewall filter add chain=block-input action=drop dst-port=137-139 protocol=tcp comment=”# Block Netbios Sessions tcp”

/ip firewall filter add chain=block-input action=drop dst-port=137-139 protocol=udp comment=”# Block Netbios Sessions udp”

/ip firewall filter add chain=block-forward action=drop dst-port=135-139 protocol=udp comment=”# Block Netbios Sessions udp”

/ip firewall filter add chain=block-ddos action=return limit=16,32

/ip firewall filter add chain=block-ddos action=log log-prefix=”DDOS ATTACK:”

/ip firewall filter add chain=block-ddos action=drop limit=16,32

/ip firewall filter add chain=input action=jump jump-target=block-ddos protocol=udp comment=”# Jump to block-ddos”

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,!ack protocol=tcp comment=”# tcp-flags jumpt to bad-flags”

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=psh,!ack protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=urg,!ack protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,rst protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,syn protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=syn,rst protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,syn,rst,psh,ack,urg,ece,cwr protocol=tcp

/ip firewall filter add chain=tcp-flags protocol=tcp action=jump jump-target=bad-flags tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg,!ece,!cwr

/ip firewall filter add chain=tcp-flags protocol=tcp action=jump jump-target=bad-flags tcp-flags=fin,psh,urg,!syn,!rst,!ack,!ece,!cwr

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,syn,psh,urg,!rst,!ack,!ece,!cwr protocol=tcp

/ip firewall filter add chain=tcp-flags action=jump jump-target=bad-flags tcp-flags=fin,syn,rst,ack,urg,!psh,!ece,!cwr protocol=tcp

/ip firewall filter add chain=input action=jump jump-target=tcp-flags protocol=tcp comment=”# Jump to tcp-flags”

/ip firewall filter add chain=bad-flags action=log log-prefix=”TCP BAD FLAGS:”

/ip firewall filter add chain=bad-flags action=drop

/ip firewall filter add chain=syn-flood action=return tcp-flags=syn,!fin,!rst,!ack protocol=tcp limit=5,10

/ip firewall filter add chain=syn-flood action=return protocol=!tcp

/ip firewall filter add chain=syn-flood action=return tcp-flags=!,syn,!fin,!rst,!ack protocol=tcp

/ip firewall filter add chain=syn-flood action=log log-prefix=”SYN FLOOD:”

/ip firewall filter add chain=syn-flood action=drop

/ip firewall filter add chain=input action=jump jump-target=syn-flood tcp-flags=syn,!fin,!rst,!ack protocol=tcp comment=”# Jump to syn-flood”

/ip firewall filter add chain=block-forward action=drop dst-port=445 protocol=tcp comment=”# Block CIFS tcp”

/ip firewall filter add chain=block-forward action=drop dst-port=135 protocol=tcp comment=”# Block RPC Portmapper”

/ip firewall filter add chain=block-forward action=drop dst-port=135 protocol=udp

/ip firewall filter add chain=block-forward action=drop dst-port=111 protocol=tcp

/ip firewall filter add chain=block-input action=drop dst-port=135 protocol=tcp comment=”# Block RPC Portmapper”

/ip firewall filter add chain=block-input action=drop dst-port=135 protocol=udp

/ip firewall filter add chain=block-input action=drop dst-port=111 protocol=tcp

/ip firewall filter add chain=block-input action=drop dst-port=111 protocol=udp

/ip firewall filter add chain=block-input action=drop dst-port=445 protocol=tcp comment=”# Block CIFS tcp”

/ip firewall filter add chain=block-forward action=drop dst-port=111 protocol=udp

/ip firewall filter add chain=block-forward action=drop dst-port=69 protocol=tcp comment=”# Block TFTP”

/ip firewall filter add chain=block-input action=drop dst-port=69 protocol=tcp comment=”# Block TFTP”

/ip firewall filter add chain=block-input action=drop dst-port=69 protocol=udp

/ip firewall filter add chain=block-input action=drop dst-port=20034 protocol=tcp comment=”# Block Netbus”

/ip firewall filter add chain=block-input action=drop dst-port=20034 protocol=udp

/ip firewall filter add chain=block-input action=drop dst-port=3133 protocol=tcp comment=”# Block Back0riffice”

/ip firewall filter add chain=block-input action=drop dst-port=3133 protocol=udp

/ip firewall filter add chain=block-forward action=drop dst-port=69 protocol=udp

/ip firewall filter add chain=block-forward action=drop dst-port=20034 protocol=tcp comment=”# Block Netbus”

/ip firewall filter add chain=block-forward action=drop dst-port=20034 protocol=udp

/ip firewall filter add chain=block-forward action=drop dst-port=3133 protocol=tcp comment=”# Block Back0riffice”

/ip firewall filter add chain=block-forward action=drop dst-port=3133 protocol=udp

/ip firewall filter add chain=block-input action=drop dst-port=2049 protocol=udp comment=”# Block NFS”

/ip firewall filter add chain=block-input action=drop dst-port=2049 protocol=tcp

/ip firewall filter add chain=block-forward action=drop dst-port=2049 protocol=udp comment=”# Block NFS”

/ip firewall filter add chain=block-forward action=drop dst-port=2049 protocol=tcp

/ip firewall filter add chain=block-service action=drop out-interface=to_internet dst-port=1818 protocol=tcp comment=”# Block Game online”

/ip firewall filter add chain=block-service action=drop out-interface=to_internet dst-port=6112 protocol=tcp

Stop Denial of Service attacks

Taking advantage of a known problem with the Operating System or any running services on the target, a good programmer can build an application that sends some data that causes the targeted system to crash.

The worst case scenario is not when a hacker crashes a service, but when it finds a way to maximize the CPU usage causing a total malfunction on the system.

Of course most of the attacks are not initiated by these kind of programmers, but by "script kiddies" who only read about it, find the program's source over the web and just use it without knowing the mechanisms it uses.

Drop Akses Client Untuk Traceroute

Mungkin karena adanya suatu alasan penting sehingga client dalam suatu jaringan dilarang untuk melakukan traceroute keluar. Jika memang ini harus diperlukan maka, kita harus mempertimbangkannya kembali, mengingat tidak ada yang harus dikhawatirkan terhadap traceroute ini. Kembali kepada permasalahan awal, mungkin dikarenakan adanya suatu alasan yang penting sekali sehingga akses untuk traceroute pada client pun harus di block ~_~

Block TCP Flag rst

Mengapa TCP Flag rst diblock ? Untuk penjelasan lanjutan tentang TCP Flag rst, silahkan dibuka kembali halaman Transmission Control Protocol Flag, jika dirasa tidak diperlukan, maka sebaiknya di block saja karena dikhawatirkan hanya akan menjadi sebab terjadinya kesalahan konfigurasi atau kesalahan-kesalahan lainnya mengingat sifat dasar dari tcp flag rst ini adalah respon atas permintaan pembuatan koneksi.

Mencegah User Agar Tidak Bisa Membuka LAN Setting Pada Window Dengan Hide Tool

Terkadang ada diantara beberapa user yang sekedar iseng mengganti ip-address nya sendiri, entah ingin tahu atau ada maksud lain. Tetapi pada sisi admin dan system hal tersebut sedikit menjengkelkan karena dengan bergantinya ip address tersebut ada beberapa konfigurasi yang tidak berjalan dengan semestinya.

Dengan Aplikasi Hide Tool ini, itu bisa diamankankan dengan menutup dialog box Internet Protocol (TCP/IP) pada LAN Connection Properties.

Bagi anda yang belum mengetahui tentang Hide Tool, silahkan membuka artikel pada blog ini. Download dan install Aplikasi tersebut.

Tipe-Tipe Serangan Denial Of Service Berikut Penangkalnya Pada MikroTik

Denial of service yang biasa disingkat dan disebut DOS (bukan dos-prompt microsoft) merupakan salah satu tipe serangan attacker kearah jaringan yang bertujuan untuk menghentikan sementara atau selamanya fungsi operasi dari sebuah system.

Secara umum ada 4 macam jenis serangan DOS, walaupun tidak menutup kemungkinan terjadinya flood atau jenis serangan DOS lainnya. Sekaligus disini juga akan dituliskan rule penangkalnya pada MikroTik Router dengan asumsi MikroTik RouterOS telah difungsikan sebagai router sebelumnya serta jalur koneksi telah benar (invalid, stabilished, related dan sebagainya). 4 type serangan DOS terdiri dari:

Mikrotik rogue dhcp detection

Mikrotik actually has a rogue detection service you can configure, but as we have found running apartment complexes, it can give you false positives. To combat this, I’ve come up with a new method.
First configure syslog exporting with the DHCP service dumping. Next enable the dhcp client to run on all your inside facing interfaces. I’ve got my Cacti syslog server set to match “dhcp,info,debug dhcp-client%got ip address”, which is the message sent when the dhcp client receives an IP address. Once the syslog server processes the message it sends us an alert.

Mikrotik port knocking with ICMP Ping

Port knocking is a very easy and simple way to secure your network services. There are many ways to use port knocking: using a series of UDP packes towards different ports with some content, or just sending a series of SYN packets on different ports.
These methods usually requires a program to do the task.
Ping, however, is usually available from any device.

implementation prerouting and postrouting

The DNAT target is used to do Destination Network Address Translation, which means that it is used to rewrite the Destination IP address of a packet. If a packet is matched, and this is the target of the rule, the packet, and all subsequent packets in the same stream will be translated, and then routed on to the correct device, host or network. This target can be extremely useful, for example,when you have a host running your web server inside a LAN, but no real IP to give it that will work on the Internet. You could then tell the firewall to forward all packets going to its own HTTP port, on to the real web server within the LAN. We may also specify a whole range of destination IP addresses, and the DNAT mechanism will choose the destination IP address at random for each stream. Hence, we will be able to deal with a kind of load balancing by doing this.

mikrotik nat

Source NAT

If you want to "hide" the private LAN 192.168.0.0/24 "behind" one address 10.5.8.109 given to you by the ISP, you should use the source network address translation (masquerading) feature of the MikroTik router. The masquerading will change the source IP address and port of the packets originated from the network 192.168.0.0/24 to the address 10.5.8.109 of the router when the packet is routed through it.
To use masquerading, a source NAT rule with action 'masquerade' should be added to the firewall configuration:

/ip firewall nat add chain=srcnat action=masquerade out-interface=Public

All outgoing connections from the network 192.168.0.0/24 will have source address 10.5.8.109 of the router and source port above 1024. No access from the Internet will be possible to the Local addresses. If you want to allow connections to the server on the local network, you should use destination Network Address Translation (NAT).

Destination NAT

If you want to link Public IP 10.5.8.200 address to Local one 192.168.0.109, you should use destination address translation feature of the MikroTik router. Also if you want allow Local server to talk with outside with given Public IP you should use source address translation, too.
Add Public IP to Public interface:

/ip address add address=10.5.8.200/32 interface=Public   

Add rule allowing access to the internal server from external networks:

/ip firewall nat add chain=dstnat dst-address=10.5.8.200 action=dst-nat \
	to-addresses=192.168.0.109 

Add rule allowing the internal server to talk to the outer networks having its source address translated to 10.5.8.200:

/ip firewall nat add chain=srcnat src-address=192.168.0.109 action=src-nat \
	to-addresses=10.5.8.200

1:1 mapping

If you want to link Public IP subnet 11.11.11.0/24 to local one 2.2.2.0/24, you should use destination address translation and source address translation features with action=netmap.

/ip firewall nat add chain=dstnat dst-address=11.11.11.1-11.11.11.254 \
	action=netmap to-addresses=2.2.2.1-2.2.2.254

/ip firewall nat add chain=srcnat src-address=2.2.2.1-2.2.2.254 \
	action=netmap to-addresses=11.11.11.1-11.11.11.254  

Port mapping

If you would like to direct requests for a certain port to an internal machine (sometimes called opening a port, port mapping), you can do it like this:

/ip firewall nat add chain=dstnat dst-port=1234 action=dst-nat protocol=tcp to-address=192.168.1.1 to-port=1234 

This rule translates to: when an incoming connection requests TCP port 1234, use the DST-NAT action and redirect it to local address 192.168.1.1 and the port 1234

Saying How To Mangle The Packets

So now we know how to select the packets we want to mangle. To complete our rule, we need to tell the kernel exactly what we want it to do to the packets.

6.1 Source NAT

You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.
Source NAT is specified using `-j SNAT', and the `--to-source' option specifies an IP address, a range of IP addresses, and an optional port or range of ports (for UDP and TCP protocols only).

## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

When AND Why Proxy-ARP

In my training classes, I go to great lengths to teach when and why proxy arp is necessary on an interface.  I have seen (and answered) numerous questions on my mailing lists regarding proxy arp and it seems it is time to create an article that I can just point people to.  I will focus this article on Mikrotik RouterOS (as many of my articles are), but it should be noted that proxy arp is not unique to Mikrotik.
If you do not already understand what ARP is, then you will need to understand that before this article will make much sense.  ARP, which stands for “Address Resloution Protocol”, in simple terms is a mechanism that makes it possible for devices that are on an Ethernet-like network communicate.  Let’s take a very simple example where we have 2 devices plugged into an Ethernet switch using IP addresses 192.168.1.1 for device A and 192.168.1.2 for device B and subnet mask /24 (255.255.255.0).  These devices can communicate at layer 3 directly, because they are in the same subnet.  If Device A needs to send an IP packet to Device B, it will need to send that packet via the Ethernet switch.  This means that the IP packet will need to be framed in an Ethernet frame.  Device A already knows the IP address it needs to communicate with, but it needs a method to determine which MAC (Ethernet address) is associated with that IP address.  This is where ARP comes in.

Breaking a network in two with proxy ARP

Proxy ARP is a technique for splitting an IP network into two separate segments. Hosts on one segment can only reach hosts in the other segment through the router performing proxy ARP. If a router sits between two parts of an IP network and is not running bridging software, then routes to hosts in each segment and proxy ARP are required on the router to allow each half of the network to communicate with the other half.
Occasionally, this technique is incorrectly called proxy ARP bridging. An Ethernet bridge operates on frames and a router operates on packets. The proxy ARP router should have routes to all hosts on both segments. Once the router can reach all locally connected destinations via the correct interfaces, you can begin to configure the proxy ARP functionality.

ARP Cache

The ARP cache is a table which stores mappings between Data Link Layer addresses and Network Layer addresses.
The Data Link Layer addresses are usually MAC addresses and the Network Layer addresses are most frequently IP addresses.
The ARP cache is stored in RAM by the Operating System.

Displaying the ARP cache

Under most versions of Unix and Microsoft Windows, the command `arp -a` will display the ARP cache.

Unix ARP Cache Example

$ arp -a
www.tech-faq.com (192.168.1.2) at 00:34:c4:45:73:21 on fxp0 permanent [ethernet]
fw.tech-faq.com (192.168.1.1) at 00:34:62:a1:c2:00 on fxp0 [ethernet]

Microsoft Windows ARP Cache Example

C:>arp -a
Interface: 192.168.1.101 --- 0x80004
Internet Address Physical Address Type
192.168.1.1 00-0d-6d-bc-a8-6b dynamic
192.168.1.2 00-0e-1c-2b-e5-3c dynamic

Further Reading on the ARP Cache

To learn more about the ARP protocol, read What is ARP?
To learn how to clear the ARP cache, read How do I clear the ARP cache?

http://www.tech-faq.com/arp-cache.html

Post subject: Netmap vs dstnat & srcnat

I am about to replace an old Cisco SOHO Router with a MT RB1100 and want to make sure that I get it right. I have a /30 to the provider with a /28 routed over the /30. The Public IP's in the /28 are assigned (mapped) when needed to various private IP's in some /24 and /22 private subnets. All other IP's in the private /24 are natted to the Public /30. The Cisco didn't care which Public IP's went to which subnets or addresses as they were done with one rule for each mapping as below.

Natting a network range with NETMAP+Iptables

Some times we need to do a 1 to 1 NAT of a network range depending upon a condition (the destination network for example).
For example, you have the 192.168.1.0/24 network and you would like to NAT each IP to its equivalent in 192.168.2.0/24 when the packet travels through the NAT device.
If you use Netfilter as a NAT device or gateway you can use the NETMAP module like this :

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 10.1.1.0/24 -j NETMAP --to 192.168.2.0/24

In the example above, the source address 192.168.1.100 will become 192.168.2.100 while traversing the gateway.
I think that’s clear enough

NETMAP target

Linux Packet Filtering and iptables
Prev	Chapter 11. Iptables targets and jumps	Next

---

11.11. NETMAP target

NETMAP is a new implementation of the SNAT and DNAT targets where the host part of the IP address isn't changed. It provides a 1:1 NAT function for whole networks which isn't available in the standard SNAT and DNAT functions. For example, lets say we have a network containing 254 hosts using private IP addresses (a /24 network), and we just got a new /24 network of public IP's. Instead of walking around and changing the IP of each and every one of the hosts, we would be able to simply use the NETMAP target like -j NETMAP -to 10.5.6.0/24 and voila, all the hosts are seen as 10.5.6.x when they leave the firewall. For example, 192.168.0.26 would become 10.5.6.26.

Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space

The Problem

You have a corporate LAN. You want to set up a VPN (in this case OpenVPN) into the LAN for your road-warriors. However, your LAN is numbered with one of the very common private subnets, such as 192.168/16. Your road-warriors often get addresses in the same private subnet from their coffee-shops, and this breaks things horribly. This is illustrated in the diagram below.
I'm going to use specific IP addresses and interface names on this page, since too often I find when people try to describe the general solution it actually makes it less clear and harder to apply to your own network.

DSMARK queuing discipline

DSMARK queuing discipline was specially designed by Werner Almesberger (C sources indicate that Werner wrote this code), Jamal Hadi Salim and Alexey Kuznetsov to fulfill with the Differentiated Service specifications. It is in charge of packet marking in the DS Linux  implementation.

Its behavior is really very simple when it is compared with some other Linux Traffic Control queuing disciplines. People complain about how to use DSMARK because the available documentation is really highly technical. I will try to clear is this section, as far as my understanding permits this, how to configure and how to use the DSMARK queuing discipline.

GRED queuing discipline

To explain why GRED was invented who's going to do that better than their creators, Werner Almesberger, Jamal Hadi Salim (C sources indicate that Jamal wrote this code) and Alexey Kuznetsov? Reading from their paper "Differentiated Service on Linux" [10], we have:

Finally, we need a queuing discipline to support multiple drop priorities as required for Assured Forwarding. For this, we designed GRED, a generalized RED. Besides four delay priorities, which can again be implemented with already existing components, Assured Forwarding also needs three drop priorities, which is more than the current implementation of RED supports. We therefore added a new queuing discipline which we call "generalized RED" (GRED). GRED uses the lower bits of skb->tc_index to select the drop class and hence the corresponding set of RED parameters. http://opalsoft.net/qos/DS-27.htm

Let's go slowly because this part requires to be studied carefully. We saw in previous section that RED has an inherent mechanism to mark packets randomly. Mark just means to mark packets for notifying senders of incipient congestion, or merely, dropping them. TCP with ECN option enabled can respond to ECN marked packets; TCP without ECN responds only to dropped packets. UDP and other unresponsive flows respond to nothing and packet killing is the only way to control them.   Independently if we mark or drop packets to notify senders about congestion, RED queuing discipline has the advantage that it can do that randomly using a probabilistic approach. Its original design was to be as fair as possible with entering flows, picking packets at random for trying to resolve the clustering nature of TCP behavior, for trying to control the queue length at routers and for trying to notify as soon as possible to the senders about congestion, for them to take correcting actions.   But for DS, we will not use RED this way, instead we want to take advantage of its probabilistic dropping mechanism to implement AF classes. Each of these classes need to support a three level drop precedence being the difference between levels the dropping probability. RED only offer one queue and one dropping probability, then our friends exhanced it to support, because 16 is better than 3 for computers, a 16 level of dropping probabilities just by creating 16 virtual queues with independent parameter setting. That's just GRED. 16 REDs in one, among other little tricks that we will see later.   At this time it would be very nice that a diagram comes to save us of this long-winded speech; here we have one:

Okay, it looks like a full class queue. Each class has its own virtual queue. Also it has some kind of filter to select the queue each packet is going to be placed. Here the tricks begin. Designers extend the packet buffer on Linux to add a new field called tc_index. The packet buffer is accessed using a pointer called skb. Then to access the field they use skb->tc_index. The new field in an integer and its 4-rightmost (least significant) bits are used to select the virtual queue (VQ) where a packet is going to be located when the time of doing this comes.

The real process is really of a tricky nature that for us, simple mortals, it's good enough to know that when the packet is in front of GRED, the 4-rightmost bits of its tc_index field buffer are snooped and accordingly to its value (0, 1, 2, … 15), one of the sixteen VQs is selected to receive the packet. It is very important to be clear that the tc_index field is not on the packet header, but instead, in the memory buffer assigned to manage the packet within the Linux Traffic Control process.

Another queuing discipline, DSMARK, that we will see later, is in charge of copying the DS field in the packet header onto the skb->tc_index field (previously it applies some bitwise operation to the DS field to convert it to a DSCP), and previously to the packet to be dispatched to the interface's driver, of copying back the skb->tc_index field onto the DS field in the packet header (previously it applies an inverse bitwise operation to the skb->tc_index field to convert the DSCP it contains back to a DS). All this mischievous process is executed by the DSMARK queuing discipline and by some mechanism called tc_index classifier, as we will see better, we hope, later on.

To continue let's see in short the GRED parameters; as you hope they are very similar what we saw before when talking about RED, but this time being GRED a multi-RED queue it is configured in two steps. First, the generic parameters are configured to select number of VQs, default VQ and the buffer sharing scheme. tc generic configuration is as follows:

Again, yellows indicate values we have to supply. Let's see this in detail. This command sets our GRED monster as the root queue of ethernet interface 0. <VQs> will be the number of virtual queues we want. If we were trying to assemble an AF class (we need one GRED for each AF class to be implemented), <VQs> parameter should be set to 3. Its value goes from 1 (a simple RED queue) to 16 (a 16 multi-RED queue). Then, 'setup DPs 3' is very nice for us.

Next, we have to select a default queue from our queues. This queue will be selected when 4-rightmost  skb->tc_index bits lay out of the number of VQs we selected. For example, you select 3 virtual queues and a packet arrives with its bits set to 9; this case the packet will be assigned to the default VQ. For our example the last VQ is good enough, then 'default 3' is okay.

Finally, we have an optional parameter [grio]. Adding it we will get what is called a 'Priority Buffer Scheme'. It is something similar what we saw before with PRIO qdisc, but a little bit complicated. Let's see how to explain this. If you set your GRED queuing discipline as 'grio' you can assign a priority to each VQ. Priorities range from 1 to 16 with 1 being the highest. As you remember when reading about RED, discipline behavior depends on the calculated value of the average queue length; let's call this value qave to use the same token used in the GRED C code. When qave is below minimum thresholdwe are in no-drop state. When qave is above minimum threshold and below maximum threshold we are in probabilistic-drop state. When qave is above maximum threshold we are in force-dropstate.

All this means that qave value is crucial to define the queuing behavior. Having defined minimum threshold and maximum threshold as larger qave is, it's going to be higher the packet dropping probability. Then playing with qave value you could implement some kind of priority scheme. How the GRED designers did this? Well, when dealing with a priority 1 VQ the qave value is just its value (just the calculated value based on measurement). But when dealing with a priority 2 VQ its qave value will be its own calculated value plus the qave value of the priority 1 VQ. The qave value of a priority 5 VQ will be its own value plus the qave values of all VQs with higher priority index; this case qave from VQ from priority 4 to priority 1.

I don't like too much this scheme because it seems a little bit confuse for me. Lower priority VQs will have a qave value that will depend of qave of higher priority VQs. Of course, using this scheme we are creating a priority response. Higher priority VQs will be in better position to dispatch a packet than lower ones. But, because thresholds are individually set things complicate further. I feel that we can't control things. Well, it's a matter of personal taste; I prefere the simple scheme where we can define each VQ behaviour based on its own parameters. Anyway below is an example using grio option.

GRED using 'grio' could be used to implement an in-profile and out-of-profile scheme into the same drop precedence. For example, using two VQs with the same drop probability and different priorities. Differentiated Service architecture strength is that it establishes just a framework where we have, as joiners, enough field to play the game we want.

Well, summarizing our GRED generic command configuration could be:

for using the default buffer scheme, and:

for using the priority buffer scheme.

The second step is to set parameters for individual virtual queues. This case, tc is used as follows:

As you see, configuration is very similar what we used before with RED. Now the word 'change' is used instead of 'add' because the queue already exists created by the generic command. This time we are just 'changing' the virtual queue setting.

Comparing with RED new parameters are: DP <vq> where <vq> is the number, from 1 to 16, of the VQ we are configuring; and the optional parameter [ prio <number> ] where <number> is the priority assigned to this VQ. This parameter is to be used only when 'grio' option is used in the generic configuration. Let's see an example with 'grio' option:

To continue we would like to configure one of these 'severe doorman' completely as root on our ethernet interface 0 using a priority scheme. We begin explaining our goal with a diagram:

This is a very simple intranet domain on a 10 Mbps ethernet network. To the left the servers network is implemented under address space 192.168.1/24 having five servers: SQL, WWW, FTP, DNS and MAIL server. To the right the users network is implemented under address space 192.168.2/24 and is connected to the servers network through a Linux Router having the ethernet interface 1 on the servers side and the ethernet interface 0 on the users side. Also we have some VoIP traffic coming from Internet to our users network through the Cisco router. This traffic has to be protected when it reaches our network from some other stronger traffic. Have a look at Voice over IP in this site for more information about these fragile flows.

Our goal is to implement a GRED queing discipline on Linux Router's ethernet interface eth0. Our monster is going to be an eight virtual queues GRED where VQ1 will correspond to the VoIP traffic, VQs 2 to 6 will correspond to DNS, SQL, WWW, FTP, and MAIL server respectively, VQ7 will correspond to UDP flows (other than UDP generated by our DNS server) and VQ8 will be reserved as default for rest of the network flows. We want to prioritize traffic from priority 1 to 8 as follows: VoIP, DNS, SQL, WWW, FTP, MAIL, other UPD and rest of traffic.

We need some expected bandwidth distribution, maximum desired latency, estimated average packet length and packet dropping probability. Using the given customer requeriments and after thinking somewhat we decided to use the following table:

VQ8 will be our default queue. N/A means that we will not apply drop probability to UDP flows. Below you can find an explanation for this.

For each individual flow we will have:

0.01 * Bandwidth Share * Desired Latency * Network Bandwidth Maximum Threshold = -------------------------------------------------------------------                                                                   8 bits/byte* 1000 ms/sec Minimum Threshold = 1/2 * Maximum Threshold Avpkt = Average Packet Length Burst = ( 2 * MinThreshold + MaxThreshold) / ( 3 * Avpkt ) Limit = 4 * MaxThreshold Network Bandwidth (10Mbps) = 10 * 1024 * 1024 bits/sec = 10.485.760 bits/sec

For example, for the SQL flow we will have:

0.01 * 25 * 100 * 10.485.760 Maximum Threshold = ------------------------------- = 32768 bytes                                                  8 * 1000 Minimum Threshold = 1/2 * 32768 = 16384 Avpkt = 1024 Burst = ( 2 * 32768 + 16384 ) / ( 3 * 1024 ) = 27 Limit = 4 * 32768 = 131072

After some calculation we can fill our table completely:     Last column is the number of packets per queue when minimum threshold is almost reached. This value is very important to check that minimum threshold admits at least one entire packet (this means that each type of flow can have at least one packet enqueue in no-drop state). Below total buffer required is calculated as 475005 bytes.   Let's explain now why we set MaxThreshold = MinThreshold (really we can't be set them equal because tc complaints when doing this; but we set them very close) for UDP flows where drop probability is not a matter (in fact we set this to 1 in the configuration script; see below).   When things go nice and all flows approximate to their minimum threshold no packet is dropped and everybody is happy. When going above minimum threshold packets begin to be dropped at random but because UDP flows are unresponsive (they don't adjust their throughput themselve when packets are being dropped) we don't want them to starve TCP flows that are aggresively responsive. Then we set maximum threshold equal to minimum threshold on UDP flows to guarantee them just the minimum threshold occupancy, but not more than this; then for UDP flows every packet will be dropped above the minimum threshold . As you see dropping probability is not a matter in this case because it is zero (0%) when queue occupancy is below common minimum-maximum threshold and 1 (100%) when above.

Okay. We are ready to configure the ethernet interface eth0. Here we have the commands (don't forget that they have to be typed in one line):

Generic GRED setup

VoIP service

DNS server service

SQL server service

WWW server service

FTP server service

MAIL server service

OTHER-UDP services

OTHER services

Checking our GRED queue using 'tc qdisc show' we have:# tc -d -s qdisc show dev eth0 qdisc gred 8002:   DP:1 (prio 1) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 3146b min 393b max 394b ewma 2 Plog 1 Scell_log 5 DP:2 (prio 2) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 5243b min 655b max 656b ewma 2 Plog 1 Scell_log 6 DP:3 (prio 3) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 128Kb min 16Kb max 32Kb ewma 4 Plog 21 Scell_log 10 DP:4 (prio 4) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 41943b min 5243b max 10486b ewma 4 Plog 20 Scell_log 9 DP:5 (prio 5) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 104858b min 13107b max 26214b ewma 4 Plog 19 Scell_log 10 DP:6 (prio 6) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 52429b min 6554b max 13107b ewma 3 Plog 18 Scell_log 9 DP:7 (prio 7) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) limit 31457b min 3932b max 3933b ewma 2 Plog 1 Scell_log 8 DP:8 (prio 8) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 72 (bytes 7488) limit 104858b min 13107b max 26214b ewma 4 Plog 19 Scell_log 10 Sent 7488 bytes 72 pkts (dropped 0, overlimits 0)

Well, first half of the work is done; first half because we have to implement some way of placing different service packets on their specific virtual queues. We are going to do that on ethernet interface eth1 using what is known as an ingress queue. This queue combined with the u32 classifier will be good enough to reach our goal. But first, what is an ingress queue? Lartc [7] has the answer; reading from it:

All qdiscs discussed so far are egress qdiscs. Each interface however can also have an ingress qdisc which is not used to send packets out to the network adaptor. Instead, it allows you to apply tc filters to packets coming in over the interface, regardless of whether they have a local destination or are to be forwarded.

As the tc filters contain a full Token Bucket Filter implementation, and are also able to match on the kernel flow estimator, there is a lot of functionality available. This effectively allows you to police incoming traffic, before it even enters the IP stack.

The ingress qdisc itself does not require any parameters. It differs from other qdiscs in that it does not occupy the root of a device. Attach it like this:

# tc qdisc add dev eth0 ingress

This allows you to have other, sending, qdiscs on your device besides the ingress qdisc.

Very nice and clear. Simple command above creates an ingress queue on device eth0 and numbers it by default as ffff:. We can also number the queue explicitely; for example to create an ingress queue in our Linux router ethernet interface eth1 we just type:

Identifying flows from our servers is very easy; we just use source address as the selection criteria to do this. This way DNS, SQL, WWW, FTP and MAIL internal provided services are easily identified.

UDP protocol packets are also easily identified. Our problem is that it is not as easy to identify properly VoIP packets from other UDP packets. Then we are going to use a trick with the help of netfilter. Nevertheless it is not an infallible solution. Some non-VoIP packets will be accepted by our not so tricky rule. Well, I haven't found a better solution for this. Then we will go ahead with what we have.

There is an iptables extension called  'length patch' by James Morris; have a look to Netfilter Extensions HOWTO [15] for more information. The extension adds a new match that allows you to match a packet based on its length. Because VoIP packets are very small we will match as VoIP packets all UDP packets being their length between 40 and 160 bytes. Some non-VoIP packets are going to trick us, but as I told you before, if you have a better solution please let me know as soon as you can. Also, we will match only port numbers above 5000 that correspond to general applications (current practice within the Unix operating system where port numbers below 1024 can only be used by privileged processes and port numbers between 1024 and 5000 are automatically assigned by the operating system). This way we can filter, for example, DNS UDP (port 53) packets from VoIP UDP packets.

We will mark VoIP packets (and some other UDP dwarfty) entering eth1 using this iptables command:

To place packets on different GRED VQs we will use the u32 classifier. Let's see an example of this monster:

This command will set to 1 the skb->tc_index of packets entering eth1 coming from host 192.168.1.1 (or having 192.168.1.1 as source address). flowid :1 is the instruction that makes this possible. Then when being forwarded to our outgoing eth0 interface those packets will be placed on GRED VQ number 1. (GRED uses the lower bits of skb->tc_index to select the VQ; read this somewhere above) Great!!

What about VoIP packets? We will use a different approach but using the same tool; let's see how:

This time we are using fwmark to select our packets. All of them having their fwmark set to 2 (handle 2 fw) will be set to 4 on their skb->tc_index (flowid :4). And we can set the fwmark using theiptables command above (see command cm-30). Ja, Ja...  We have all those packets controlled, haven't we? Using iptables we mark fwmark for small UDP packets as 2, for example, and then with thefw filter we set the skb->tc_index to 4 for these packets. But this means that they will be put on GRED VQ number 4 when being forwarded to the interface eth0. Great, again!!

And, what to do with other UDP packets? Very easy. UDP is protocol number 17. Then we can use this u32 filter variation:

This rule matches UDP packets putting them on GRED VQ number 5. But observe that now the prio option is 2. Filter are treated following the prio option. prio 1 is treated first, then prio 2, an so on. Then we put our small UDP packets (VoIP) on a prio1 filter to place them on some GRED VQ; this filter will be treated first and all the small UDP packets will be placed on GRED VQ 1, for example. Having next another filter with a higher prio number, we can select rest of UDP packets placing them on another GRED VQ. It's very nice!! Isn't it?

Okay, fellows. Having all these explanations 'on-board' we have here the filter commands for each one of our services:

VoIP service     DNS server service     SQL server service     WWW server service

FTP server service

MAIL server service

OTHER-UDP services

Rest of flows being not catched by our filters will be placed on default VQ number 8.

Well, with this explanation we have finished with GRED. Our next target in our DS tour will be HTB (Hierarchical Token Bucket) queuing discipline, a new qdisc from Martin Devera that was included on Linux beginning with the kernel 2.4.20. I invite you to keep on reading our next sectio

RED queuing discipline

All queuing disciplines we have seen so far (FIFO, PRIO, TBF, SFQ) and also HTB that we will see later, base their queuing algorithm in the well-known FIFO queue. As you remember, in this queuing discipline packets enter the queue at the tail and leave it from the head. This, that could be considered something very simple and natural, pose a serious problem to those flows based on the, de-facto standard, TCP transport protocol.

Problems arise when queues overflow due to bursty of packets. At this moment more packets can not be admitted and they have to be dropped where they are entering, this means, at the tail of the queue. That's the reason why all queuing discipline based on the FIFO queue are known as DropTail queues.

TCP Connection Open

The "three-way handshake" is the procedure used to establish a connection. This procedure normally is initiated by one TCP and responded to by another TCP. The procedure also works if two TCP simultaneously initiate the procedure. When simultaneous attempt occurs, each TCP receives a "SYN" segment which carries no acknowledgment after it has sent a "SYN". Of course, the arrival of an old duplicate "SYN" segment can potentially make it appear, to the recipient, that a simultaneous connection initiation is in progress. Proper use of "reset" segments can disambiguate these cases.
Several examples of connection initiation follow. Although these examples do not show connection synchronization using data-carrying segments, this is perfectly legitimate, so long as the receiving TCP doesn't deliver the data to the user until it is clear the data is valid (i.e., the data must be buffered at the receiver until the connection reaches the ESTABLISHED state). The three-way handshake reduces the possibility of false connections. It is the implementation of a trade-off between memory and messages to provide information for this checking.
The simplest three-way handshake is shown in figure 7 below. The figures should be interpreted in the following way. Each line is numbered for reference purposes. Right arrows (-->) indicate departure of a TCP segment from TCP A to TCP B, or arrival of a segment at B from A. Left arrows (<--), indicate the reverse. Ellipsis (...) indicates a segment which is still in the network (delayed). An "XXX" indicates a segment which is lost or rejected. Comments appear in parentheses. TCP states represent the state AFTER the departure or arrival of the segment (whose contents are shown in the center of each line). Segment contents are shown in abbreviated form, with sequence number, control flags, and ACK field. Other fields such as window, addresses, lengths, and text have been left out in the interest of clarity.

Transmission Control Protocol (TCP)

Transmission Control Protocol is a Transport Layer host-to-host protocol that provides reliable, connection-oriented communication over IP networks.

1. Transmission Control Protocol Characteristics
   1. TCP Data Transfer
   2. TCP Reliability
   3. TCP Flow Control
   4. TCP Multiplexing
   5. TCP Connection Oriented Communication
   6. TCP Precedence and Security
2. Transmission Control Protocol Operation
   1. TCP Segmentation
   2. TCP Connection Establishment
      1. Synchronization
      2. 3-Way Handshake
   3. TCP Reliable Transmission
   4. TCP Connection Teardown
   5. TCP Reassembly
3. Transmission Control Protocol Packet Structure
1. TCP Header
2. Payload Carries Upper Layer Protocols

http://www.inetdaemon.com/tutorials/internet/tcp/index.shtml