 Will work for packetsPosted by stretch in Announcements on Tuesday, 6 Jan 2009 at 6:23 a.m. GMTAfter nearly two years working as a US defense contractor in Iraq, I've decided it's time to move on. The traditional course of action at this point would be to touch up my resume and distribute it among the popular IT job portals. However, since Packet Life has grown pretty popular, I wanted to see if I can use it to attract potential employers lurking in the audience. So, I've written this post as a very informal notice that I'm looking for new work. Could your organization use an unusually motivated network engineer? Or perhaps an in-house instructor who laughs in the face of "adequate" study material? What about an amateur blogger who sits in a dark corner of the office crafting cheat sheets all hours of the day and night? How about all three? If so, I'm your man! What I'm Looking ForI've always felt that networking is far too interesting for an engineer to be confined to some narrow aspect of the field. Ideally I'd like to secure a position which encompasses at least two of the following roles:
Skill level: Seeking a senior-level, non-management position. Location: I'm free to relocate at will. While I would prefer North America, Europe, or Australia, I am willing to relocate just about anywhere (but not Antarctica). Compensation: My goal is 120-150K USD if employed in a major metro area. Of course this is a soft goal and will vary significantly depending on the nature of the position and the area of employment. Start date: Looking to start late February through March. What I Can Do For Your CompanyNetworking is more than a career for me. The Internet has fascinated me since a young age and continues to do so, and that passion directly contributes to my drive and skill as a network engineer. I have never been content knowing only what I do at a given moment, and I find myself constantly seeking to improve even trivial aspects of the networks in my charge. Rather than regurgitate here the normal manifest of skills (this can be found in my resume), I offer a brief overview of what I bring with me:
Contact MeIf you think I'd be a good fit at your organization, please contact me at stretch at packetlife.net (or use the contact form, which works just as well). I have prepared a very general resume, but am also happy to provide tailored revisions for specific positions if approached. Additionally, my work experience is further detailed on my LinkedIn profile. January contestPosted by stretch in Announcements on Monday, 5 Jan 2009 at 12:00 a.m. GMTWhat better way to kick off the new year than with a new packet analysis contest? Following the manner of the last two contests, a packet capture is provided at the end of this post, and you'll have to extract some arbitrary bit of information from it. The challenge this time: find the IOS version running on 172.16.232.10. The usual guidelines apply:
E-mail your entry to stretch at packetlife dot net (or use the contact form), with the word "contest" in the subject. Entries are due by 23:59 UTC on Thursday, 8 January. The answer and contest winners will be announced in a post the following day. Feel free to leave comments on this post until then, but please refrain from discussing answers or giving hints (comments are moderated).
Since the prize for November's contest was Routing TCP/IP volume 1, it's only fitting that the prize this time is Routing TCP/IP volume 2! I've reviewed both volumes (also see my notes) and heavily recommend both. Copies of these books have been graciously donated by Cisco Press. Three correct entries will be chosen at random and each will win a copy. (Unfortunately, winners of the last contest aren't eligible to win again, but participation in the challenge is of course still welcome.) Good luck! IEEE 802.11 Wireless cheat sheetPosted by stretch in Announcements on Saturday, 3 Jan 2009 at 2:05 a.m. GMT
This cheat sheet took considerably longer than average to produce, as I found myself constantly being refamiliarized with the myriad of components which make up wireless networks. Laborious as it was, I'm pretty happy with how it turned out. And thanks to Brandon Carroll for helping review an early draft! As always, if you notice any errors or omissions in the document please be sure to let me know and I'll do my best to get them corrected. I've been pondering an opt-in mailing list for people who want to receive draft copies of cheat sheets and help me review them for errors or omissions. Thoughts? Submarine cable repairPosted by stretch in Random on Friday, 2 Jan 2009 at 12:00 a.m. GMTEver wonder how broken undersea cables get repaired? A few interesting links were posted to the NANOG mailing list last month, including a series of YouTube videos produced by Hibernia Atlantic onboard Global Marine's Cable Innovator. My favorite is this one demonstrating how the individual fibers are prepared and spliced together:
Other videos in the series demonstrate (in no particular order):
Interesting stuff. Alcatel also has a couple nifty Flash videos demonstrating how cables are laid and retrieved for repair. Behind the scenes at PacketlifePosted by stretch in Random on Wednesday, 31 Dec 2008 at 12:00 a.m. GMTOnce in a while I'll get an email from a reader wanting to know how I go about writing articles for the blog. With the year at a close and most people preparing for New Year's celebrations, I figured now might be a good time to discuss how Packetlife works behind the scenes. If Packetlife had any scenery, that is. One of the keys to holding readers' interest in a blog interesting is to always maintain a buffer of content. The idea is that you can write on and off, but still post articles at a regular interval. At times I'll have as much as a week's worth of content written in advance, but on average I stay just a post or two ahead of myself. Another trick which takes some discipline is to maintain a list of potential article topics. Often I'll encounter some technical issue in a lab that I'd like to cover but don't have the time to write about it at the moment, so I'll add it to my "to do" list. If you've ever written in with a suggestion for the blog, I've likely responded that I've added it to this list. I've found that it's crucial that I add a topic to the list the moment I think of it; otherwise the idea tends to quickly evaporate. At the moment my to do list contains well over a hundred article ideas, so rest assured there will be no shortage of content in 2009. Once I've decided what to write about, I start putting words down in a simple text document saved to my workstation. If the article is technical in nature, I write in parallel to performing a lab with Dynamips/GNS3 or real hardware in an effort to ensure the accuracy of the article. I usually save the labs for some time after writing the post as well, in case a comment or question posed by a reader leads me to further investigate some aspect of the lab after the article has been published. A surprising number of readers have inquired as to how I create the numerous topology diagrams which often accompany articles. It's just Visio, guys. =) Most of the drawings are created using publicly available icons (my favorite sets are hosted locally for download). When a drawing has been completed in Visio (running inside a Windows XP virtual machine on my Linux workstation), it's exported in PNG format. I use Gimp (a graphics editor) for any touch-up editing like cropping or splicing a collection of topologies into individual images. The end product(s) are then posted to the blog along with the written content. Once an article has been published, I watch for comments and publish those as well, as soon as I can. Unfortunately comments have to be moderated in such a manner to thwart spambots. The whole process might seem like a lot of work, and, well, it is. You get used to it though, and at least it makes me feel productive. Now it's time to start writing for '09. See you then! Traceroute timeoutsPosted by stretch in Networking on Monday, 29 Dec 2008 at 2:26 a.m. GMTIf you spend a lot of time performing traceroutes to Cisco routers you've probably noticed that they usually end like this: Notice that the second reply from the last hop has timed out. This is easily repeated with subsequent traceroutes, and it is always the second attempt which times out. Strange, eh? The reason for this is IOS' default ICMP rate limiting. Back in May I wrote an article explaining the common "U.U.U" response that results from pinging an unreachable destination, and the same logic is at work here. Inspecting the default ICMP rate limits reveals that ICMP unreachable messages are only sent every 500ms: This rate limiting configuration effectively ignores every other traceroute packet (see the timeline illustration in the previous article). Makes sense, but why do all the requests to routers prior to the last hop receive replies without this problem? Those replies are of a different ICMP type, namely the "TTL exceeded" type. Remember that traceroute works by sequentially incrementing the TTL of UDP (or ICMP on Windows) packets destined for a host and recording the replies received from intermediate routers. All hops except the last one will (or should) return a "TTL exceeded in transit" message, whereas the last hop should return a "destination unreachable/port unreachable" message indicating that it cannot handle the received traffic (UDP traceroute packets are typically addressed to a pseudorandom high port on which the end host is not likely to be listening).
The packet capture attached at the end of this article includes the traffic from the traceroute demonstrated above. Interestingly, we can remove the ICMP rate limit with Now our traceroute from R1 completes fully: However, removing the ICMP rate-limit may open an avenue for denial of service attacks on your routers, so in practice you probably want to leave it applied. Political packetsPosted by stretch in Opinion on Saturday, 27 Dec 2008 at 12:09 a.m. GMTIf you visit the main page of packetlife.net frequently you may have noticed something new in the top right corner.
For those who have shielded themselves from all IT news over the last three months, Cleanfeed) refers to a web content filtering system in place in the UK and and planned to be deployed in Australia soon. While the filter operated in the UK is supposedly limited to blocking only child pornography, the initiative put forth by Senator Stephen Conroy in Australia is much more ambitious. Nocleanfeed.com lists the disturbing details of the plan known to date (references available at the link):
Setting aside the myriad of technical barriers to implementing such a system, the most obvious question is, "who decides what gets blocked?" When a corporation implements a web filter, it does so in accordance with corporate policy -- policy that is set by the owner of the network. But the Internet doesn't belong to any one entity, be it governmental or commercial, so such an authority simply doesn't exist at this scale. In a very Orwellian sense, this filtering initiative appears to want to create that authority out of thin air. Naturally, the vast majority of Aussies oppose the content filter, as do the government's own studies. But why should that stop a conservative minority bent on "protecting the children?" Some thoughts:
Nocleanfeed.com has some good suggestions for Australians wishing to voice their opinions. Good luck, mates! Happy HolidaysPosted by stretch in Random on Wednesday, 24 Dec 2008 at 8:54 a.m. GMT
Disabling MPLS TTL propagationPosted by stretch in Networking on Monday, 22 Dec 2008 at 7:19 a.m. GMTAs you're probably aware, the IP header includes a time-to-live (TTL) field which serves as a hop counter. At every routed hop, the TTL is decremented by one; if the TTL reaches zero before the packet reaches its destination, the packet is discarded and (optionally) an ICMP TTL exceeded message is sent to its source. MPLS labels also have a TTL field:
MPLS routers copy the TTL of an IP packet when it enters a label-switched path (LSP), such that an IP packet with a TTL of 255 receives an MPLS label with a TTL of 255. By default, IOS routers will decrement the MPLS TTL of an MPLS-encapsulated packet in place of the IP TTL, at every label-switched hop.
Cisco calls behavior this TTL propagation. Because the MPLS TTL is copied (or "propagated") from the IP TTL, a traceroute from R1 to R6 in the above topology will list every hop in the path, be it routed or label-switched. (Note that the final leg of the MPLS portion of the path, from R4 to R5, is not label-switched due to penultimate hop popping.)
Cisco IOS provides the option to disable MPLS TTL propagation, with the no mpls ip propagate-ttl command under global configuration. If applied, this command should be applied to all routers in the MPLS domain. With TTL propagation disabled, the MPLS TTL is calculated independent of the IP TTL, and the IP TTL remains constant for the length of the LSP. Because the MPLS TTL never drops to zero, none of the LSP hops (R2-R3 and R3-R4) trigger an ICMP TTL exceeded message and consequently these hops are not recorded in the traceroute from R1:
WastePosted by stretch in Random on Saturday, 20 Dec 2008 at 8:08 a.m. GMTWhile many of the current "green" trends in IT are hype, I'm pretty sure we can do better than this:
What you see here is an 8P8C (not RJ-45) connector, individually packaged and labeled. While sorting through storage at work the other day, I cam across an entire bag of these, probably about a hundred, all individually bagged and labeled. The manufacturer probably used about as much plastic for the packaging as for the connectors themselves. Unfortunately there was no vendor name on the bag, so I can't say who to avoid purchasing from. I can only hope they get a clue. |
Navigation
Armory
Online Toolbox
|
