A collection of note-to-self's
TBF or Token Bucket Filter is a tool from the linux kernel. It can be inserted as a “queueing discipline” for an Ethernet device. TBF is usually employed to limit the bandwidth.
I tried to configure TBF on my Ubuntu 9.10 VMware box, but I got disappointing results: I only got around 100kbps, no matter what I configured. I tried the same setup on a physical server, with the same results.
In 10BASE-T, the Manchester-encoding guaranteed that the line would stay “active” with transitions. 100BASE-TX uses a different approach. This is done by translating every nibble (4bit) block into a 5bit block (4B5B coding). These 5bit blocks are specially designed to have the necessary transitions build in, while only adding 20% overhead, compared to 100% in the Manchester case. The official code-table can be found on page 144 of section 2 of the 802.3 standard.
100BASE-TX requires UTP cables of Cat5 or higher and utilizes 1 pair for Tx and 1 pair for Rx.
10base-T is the oldest Ethernet standard that runs over regular twisted pair cable. 10base-T requires UTP cables of Cat3 or higher, with a total length of maximum 100m. I wanted to figure out if you can generate “hard” packets for Ethernet; packets that somehow may expose problems in the hardware: signals with DC offsets, high frequency signals, low frequency signals, signals where the clock might be hard to track, … This post describes the journey of an ethernet frame from memory to wire.
When looking for documentation on Ethernet, one can easily find that the frame includes a Frame Check Sequence. This is a bunch of bits that allow the receiver to verify the frame. If the frame somehow got corrupted on its way from sender to receiver, the FCS will not match the frame data and the receiver will discard the corrupt frame. Exactly how this FCS is calculated is not that easy to find.
When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:
Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.
Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.
This work by
http://blog.dest-unreach.be/ is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 2.0 Belgium License.