Saturday, 12 May 2012

Gratuitous ARP

For many years I knew that in order to start sending traffic to some destination on the network in most cases a host needs to resolve IP address to a physical address. And of course saw ARP packets in Wireshark captures, but didn't pay to much attention to them. And only a couple of years ago some I started asking some questions about the way ARP works.

I was looking into different Network Load Balancing and HA solutions, software ones like BalanceNG and hardware ones like old Nortel Alteons. Most of them are based on playing with MAC addresses transitioning, virtual MACs and virtual IPs. The details of the router redundancy protocols are not relevant in this case, what's important is that after a failover has occurred traffic destined to a failed node's MAC address will not reach the destination. The hosts should somehow re-resolve the MAC for the virtual IP. And as you know hosts keep an ARP cache which is there for a reason. So how does the failover occur almost seamlessly then? That was the question I had at the time.

The answer is a Gratuitous ARP packet. In simple terms this broadcast packet refreshes hosts' ARP cache and allows to immediately switch from using old MAC for some IP to a new MAC. In this post I will mostly collect quotes from standards related to the gratuitous ARP packets.

Sunday, 6 May 2012

Extracting dissected packets details from Wireshark

Here's a short Wireshark tip on how to extract packet details from Wireshark GUI into a text file. In other words how to get this:
Frame 74: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: IntelCor_29:34:97 (00:1f:3b:29:34:97), Dst: ThomsonT_84:7e:4a (00:26:44:84:7e:4a)
Internet Protocol Version 4, Src: (, Dst: (
Transmission Control Protocol, Src Port: 2368 (2368), Dst Port: 80 (80), Seq: 2, Ack: 2, Len: 0
    Source port: 2368 (2368)
    Destination port: 80 (80)
    [Stream index: 6]
    Sequence number: 2    (relative sequence number)
    Acknowledgement number: 2    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgement: Set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
    Window size value: 231
    [Calculated window size: 231]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x5951 [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 73]
        [The RTT to ACK the segment was: 0.000092000 seconds]
from this:
Wireshark packet details
Wireshark packet details window

One may ask -- what's the problem here, can't you just select the window content and use Ctrl+C/Ctrl+V? Well, I was disappointed to learn that no, it's not straightforward. Good news it's still possible.

Saturday, 5 May 2012

S01E01. Pilot

Hey folks. This is my attempt to start a technical blog on all tech things I learn about. Just so you know what I'm planning to cover here, this is a short list of different areas of my professional interest in random order:

  • High load systems
  • Performance and capacity
  • Digital TV
  • Web streaming
  • Linux
  • Tasks automation
  • IP Networks
  • Systems Integration
  • IT infrastructure

There's a number of reasons why I decided to start blogging about tech stuff, but generally I was inspired by this post from Racker Hacker blog.

And a little disclaimer: Obviously English is not my first language so I will be making mistakes. Hope for your understanding. A polite correction is always welcome. ;-)