To timidly go where many have gone before

Woohoo! We can now do a native boot from ZFS, at least for x86 servers. Live Upgrade doesn't support this yet, and since I use Live Upgrade on both my home system and my laptop, I thought I'd wait a while before giving this a go. But Live Upgrade with ZFS will mostly just involve taking a snapshot and cloning it, so one could hack something together to get similar functionality. Here is someone's experience of having done just that. (Note that this involves using BFU and not doing an OS upgrade like you'd do with Live Upgrade, but it's still pretty interesting.)

I ran across this interesting problem the other day. There are two snippets of snoop output below, the first from the client side and the second from the server side. It's the same packet as seen from both sides (part of a connection to the echo port.) The problem is that the IP and TCP checksums don't match.

ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 1 arrived at 10:53:46.84469
ETHER:  Packet size = 66 bytes
ETHER:  Destination = 0:14:4f:46:17:32,
ETHER:  Source      = 0:14:4f:3f:e6:e8,
ETHER:  Ethertype = 0800 (IP)
ETHER:
IP:   ----- IP Header -----
IP:
[ ... ] 
IP:   Header checksum = 0000
[ ... ]
TCP:  ----- TCP Header -----
TCP:
TCP:  Source port = 34783
TCP:  Destination port = 7 (ECHO)
TCP:  Sequence number = 2814225515
[ ... ]
TCP:  Checksum = 0x24d7
[ ... ]
ECHO:  ----- ECHO:   -----
ECHO:
ECHO:  ""
ECHO:


           0: 0014 4f46 1732 0014 4f3f e6e8 0800 4500    ..OF.2..O?...E.
          16: 0034 2680 4000 4006 0000 0a40 0819 0a40    .4&.@.@....@...@
          32: 0818 87df 0007 a7bd ac6b 0000 0000 8002    .........k......
          48: c1e8 24d7 0000 0204 05b4 0103 0300 0101    .$.............
          64: 0402                                       ..

ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 1 arrived at 10:53:46.84548
ETHER:  Packet size = 70 bytes
ETHER:  Destination = 0:14:4f:46:17:32,
ETHER:  Source      = 0:14:4f:3f:e6:e8,
ETHER:  Ethertype = 0800 (IP)
ETHER:
IP:   ----- IP Header -----
IP:
[ ... ]
IP:   Header checksum = ef93
[ ... ]
TCP:  ----- TCP Header -----
TCP:
TCP:  Source port = 34783
TCP:  Destination port = 7 (ECHO)
TCP:  Sequence number = 2814225515
[ ... ]
TCP:  Checksum = 0xac6f
[ ... ]
ECHO:  ----- ECHO:   -----
ECHO:
ECHO:  ""
ECHO:


           0: 0014 4f46 1732 0014 4f3f e6e8 0800 4500    ..OF.2..O?...E.
          16: 0034 2680 4000 4006 ef93 0a40 0819 0a40    .4&.@.@...@...@
          32: 0818 87df 0007 a7bd ac6b 0000 0000 8002    .........k......
          48: c1e8 ac6f 0000 0204 05b4 0103 0300 0101    ..o............
          64: 0402 b42f ebf7                             .../.

I had sent a very large client-side packet dump to a vendor as part of debugging a problem we were seeing. The engineer on the other side pointed out to me that all of the client-side checksums were wrong, so I played with it a bit to see if he was right. And apparently he was.
After a little bit of digging, I figured out what the problem was. (It was something I'd known before, but I hadn't given it enough attention to realize that this is what I was seeing.) The checksum calculation has been offloaded to the network adapter (for those adapters that support it.) This has been in Solaris for a while, but there have been improvements in the checksum offload in Solaris 10. There's some interesting information about it (and other improvements) here.