quaggOS 0.1a1 released – OSPF/BGP routing solution
Mar 4th
Hi,
I am pleased to announce that quaggOS in alpha version has been released.
quaggOS is a live linux distribution I created which turns a server/pc into a full BGP/OSPF router. This is achieved by using the Quagga routing solution application.
For more information, visit http://quaggOS.org
To download and test the alpha release, click here
QinQ Vlan tagging and S-Vlans
Jan 20th
Pre-requiste: Understanding of the 802.1Q Protocol
The purpose of this post is to shed a light on how QinQ Vlan takes place in a bridged network environment.
Before continuing, it is important to keep in mind that 802.1QinQ or 802.1ad isn’t a defined protocol in itself but a mere ammendment of the already existing 802.1Q protocol.
Having said that, in a nutshell where a single frame can hold a maximum of 4096 tags, QinQ extends the number of maximum tags to 16777216 tags, thus allowing switches to freely manipulate the tags of a single packet. A typical example where QinQ is used is in bridge networks where each customers’s frame can be easily forwarded through different topology network while appearing to the customers’s as a simple bridge with no frame modification.
That is to say, if a corporation has different offices across a region and wishes to build a single logical lan, the corporation can use QinQ and bridge all its sites through their subscribed network provider, without having to alter the existing vlan infrastructure of the customer.
This as said earlier is achievable through QinQ and S-Vlans. To keep it simple, S-Vlans are just the vlan tags that the frames of a customer gets when entering the vlan space of the Service provider and on which forwarding occurs.
For example
Office A is on vlan 1 —- Provider — Office B is on vlan 1
For this to work such as the packet from customerA tagged with vlan 1 be tunneled through the ISP’s bridged network, the ISP must work on a different vlan space and assign a specific S-Vlan ID to the coorporation subscribed to its services.
Office A (vlan1) —- Provider (vlan20) — Office B (vlan 1)
When entering the Provider’s bridge, the frame from OfficeA will be tagged with S-Vlan 20 and be forwarded to OfficeB, once the packet reaches the other edge bridge’s endpoint, it is stripped off the S-vlan and enters the office’s B network.
Now what if I have many vlans? Remember, within the Bridged network, the Vlans aren’t looked at, only the S-vlan is looked at… based on the S-vlan, the provider’s switch makes a decision as to which S-vlan switch end point to forward to, to which the customer-network port is assigned. Only once it arrives at the other endpoint, that it is stripped off from the S-vlan tag and the customer’s own switch does the next step forwarding (based on the vlan tags).
I hope that was informative and will clear out a lot of common misunderstanding on QinQ and S-Vlans.
Cheers
Ideone – compiler pastebin
Nov 24th
A friend of mine, just tossed me this link.. http://ideone.com/
What makes Ideone different from any other pastebin is its compiler feature; Supporting about 20 programing language, you will be able to live compile (of course with some limitations) your code.
Let’s find out the perl version running on that server
print $];
and result?
result: success time: 0s memory: 3248 kB signal: 0 input: no output: 5.008008
Ok… not the 5.010000 I excepted but not too obsolete either.
Have fun,
Denial of Service in PHP
Nov 24th
It was about time, that the PHP team finally included a max_file_uploads directive to limit the number of file upload per request (default is of 20). (cf. http://www.php.net/ChangeLog-5.php#5.3.1)
Until PHP 5.3.1, it was possible to send an X number of file upload request thus creating an X amount of temporary file on the targeted system.. which would cause the web server to crash and the system to overload.
PHP-suhosin has already a max upload option “suhosin.upload.max_uploads” (default to 25), therefore systems with the suhosin patch are protected.
Recommendation is to apply the 5.3.1 release with the patch provided by PHP or to disable file_uploads in php.ini if not using file upload. Keep in mind, you do not need a file upload form on your site to not be vulnerable… all it takes is sending a multipart/form-data mime type to the php script as defined in RCF 1867
The Nagle’s algorithm and TCP throughput
Oct 29th
Who talks about about TCP throughput unfortunately can’t step away from the congestion problem that often occurs in TCP session connections.
There are many TCP Congestion Algorithms, from Window Sliding to Fast Recovery; In this post I will only focus on the Nagle’s algorithm and how applications can be tweaked to either make use of the TCP delay induced by the Nagle’s algorithm or minimize latency for the sake of real time application.
Nagle’s algorithm
The Nagle’s algorithm was developed to prevent congestion due to tinygrams (small packets); that is to say, the % of IP and TCP headers is considerably larger than the packet’s data (MMS)
Remember
MTU = MSS – 40 bytes (20 bytes IP header and 20 bytes TCP header)
The problem is that application which only generates a small fraction of data (small bytes write) such as remote login (X server) would just generate each time a packet with 40 bytes headers (IP/TCP headers) + x byte data. This overhead including the amount of packets which are therefore generated would start clocking the link, especially on links with limited bandwidth.
If I connect remotely to an X server and move the mouse, that amount of information generated will obviously be quite small and thus generate a subsequent amount of small packets.
The Nagle’s algorithm delays the sending of tinygrams by buffering them till an ACK has been received for a packet with outstanding data sent earlier.
The algorithm is laid as followed
if there is new data to send
if the window size >= MSS and available data is >= MSS
send complete MSS segment now
else
if there is unconfirmed data still in the pipe
enqueue data in the buffer until an acknowledge is received
else
send data immediately
end if
end if
end if
ACK delayed
ACK delayed simply implies that the receiver does not need to acknowledge reception of each segment right after their reception. So instead of sending an ACK for each segment, then at some point later on (once the TCP buffer of the recipient is full), to send an ACK with a 0 value and then an ACK update, the recipient would be able to delay the ACK response and thus in one segment inform the sender of the window size.
It is important to note that the ACK delay should not exceed 0.2 seconds (200 ms)… an increased ACK delayed will therefore highly affect the round-trip timing, as much as no ACK delay will cause a high congestion on the network.
Small Scenario
If I were to send 88000 bytes to a remote host, I would technically be sending (88000/1460) ~= 60 packets + 400 bytes, this is of course excluding the TCP/IP headers
With ACK delayed, an ACK will be sent for each 2nd packet received, so using the Nagle’s algorithm, once the ACK of the 60th packets comes back, the 61th packet (441 bytes) will be sent. Now imagine we had a 62th packet? The receiver would still be waiting for the 62th packet in order to send the ACK… Nagle on the other side would not send the 62th packet unless it receives the ACK of the 61th packet…
Now as you can imagine, we would start hitting a deadlock till the ACK delayed timeout kicks in. Network degradation will be foreseen, especially with real-time application.
The issue
Now what would happen in such case if I were to use a remote X server and move the mouse, well Nagle would make sure your TCP buffer fills up to FULL size before sending a packet with a total delay of 200ms between each sent packet due to Delayed ACK… make the calculation, the lag will be highly noticeable 
To prevent using the Nagle’s algorithm, make sure to set TCP_NODELAY in your application configuration.