Ali Abbas

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 amendment 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 customer’s frame can be easily forwarded through different topology network while appearing to the customer’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

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,

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

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.

Before reading this post, I recommend going over part 1 PHP OPCodes Cached with APC – part 1

In the first part we tackled what OPCodes are and how APC helps us streamline webserver performance by caching recurring script execution.

In this second part, we will mostly look at the APC configuration main variable and thus further understand how the APC engine works.

APC cache size and shared memory

apc.shm_segments

By default this value is set to ’1′; that is so say, there would be only one shared memory segment to allocate to the cache

apc.shm.size

This is the size in MB of each shared memory segment. The default is of 30Mb.

Please note that you cannot set a higher value than the maximum size of shared memory segment defined in your kernel distribution.

cat /proc/sys/kernel/shmmax
33554432

Read more…