Blargh

Recently some time ago (this blog post has also been lying in draft for a while) someone came to me with a problem they had with a Cisco 7600. It felt sluggish and "show proc cpu" showed that the weak CPU was very loaded. This is how I fixed it. "show proc cpu history" showed that the CPU use had been high for quite a while, and too far back to check against any config changes. The CPU use of the router was not being logged outside of what this command can show. "show proc cpu sorted" showed that almost all the CPU time was spent in interrupt mode. This is shown after the slash in the first row of the output. 15% in this example: Router# show proc cpu sorted CPU utilization for five seconds: 18%/15%; one minute: 31%; five minutes: 42% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 198 124625752 909637916 137 0.87% 0.94% 0.94% 0 IP Input [...] ...

I had this blog post lying around as a draft for a long time. I didn't think it was was "meaty" enough yet, but since I'm no longer a network consultant I don't think it'll become any meatier. So here it goes. Here I will describe the process of L3-to-L2 mapping, or next-hop resolution and how it works with point-to-point circuits like PPP, ATM and Frame relay. It's the process of finding out what to actually do with a packet once the relevant routing table entry has been identified. It's deceptively simpler than on a LAN segment, but since people generally learn Ethernet before they learn point-to-point nowadays I'm writing it anyway. When a packet is to be sent to an address on the same subnet a L3-to-L2 mapping is done to look up the L2 destination address (if any) to apply. The packet is then encapsulated in a L2 frame and sent out the interface. On a normal Ethernet LAN segment ARP is use...

Go has exceptions and return values for error Yes it does. Yes, it really really does. We can discuss this for hours but in the end it boils down to four points: In Go some errors cause stack unrolling, with the possibility to for each step in the call stack register code that runs before the stack is unrolled further, or for the unrolling to stop. In programming languages, that's called "exceptions". Idiomatic use in a language of the feature doesn't affect what the feature is . Saying that Go doesn't have exceptions is like saying Go doesn't have NULL pointers (it has nil pointers). There is no non-tautology definition of exceptions that includes the ones in Python, C++ and Java, but does not include panic/rescue in Go. Go on, try to language lawyer your way into a definition. In spoken/written lang...