About

About

Hi, I’m John Harrington and I’d like to welcome you to the Network Sherpa blog. I’m a network automation engineer living in Dublin, Ireland.

A bit about you and this blog

The goal of this blog is to complement your technical skills, sharing my experiences to help guide you to a more successful networking career.

I hope these resources help you on your career journey.  As always feel free to comment here or on any page and I’ll be in touch. You can also catch me on Twitter:  

A bit about me

I landed a job in a new Irish Mobile Telecoms company, Digifone, after surviving a 3rd-level electronics course in DIT. After three years of operations and engineering I took a break, spending two fantastic years in Sydney, Australia working for Nortel and Optus before the bubble burst in 2002. I worked for O2 when I returned to Ireland, trying my hand at management before finally moving into IP network engineering.

I then spent 8 years in the Amazon.com networking team, data centre and enterprise engineering and few years as a network test engineer. I spent three of those eight years based in Seattle before returning to Ireland once again. I left Amazon in late 2015 to be an independent network consultant, and since then have spent time in Cumulus Networks as a Sales engineer and Facebook. These days I’m a network automation engineer @ Workday.com.

I’ve been exposed to many faces of business, networking and automation.
As Ralph Waldo Emerson once said, “The mind, once stretched by a new idea, never returns to its original dimensions”.

6 thoughts on “About

  1. Have you ever looked the “hsrp-and-ospf-in-lan.cap” for Wireshark. What kind of a network do packets 38 and 39 describe? I’m trying to examine these packets in studying OSPF and struggling to find documentation that can explains some of the Packets in this Wireshark file. Thanks for the help.

    1. Hi Manu,
      I presumed you’re talking about http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=hsrp-and-ospf-in-LAN ??
      It’s hard to give very specific answers here as you haven’t highlighted which parts of the LSA you’re having problems with. Looking at Packet #38 you see two LSAs, one for a type-2 and one for a type-1 (describing itself). In Packet#39 you see a type-1 from the router at the other end of that link, again describing itself and it’s links.
      You can probably derive who the DR on this link by looking at who sends the type-2. Also, look for other both routers reporting their membership of this shared segment with a ‘Transit’ link in their respective Router LSAs. See http://thenetworksherpa.com/ospf-broadcast-interfaces-and-its-lsas/
      As for the other links in the Type-1, there are stubs describing lookbacks, and both stubs and point-to-point links describing an interface connection to another router. See http://thenetworksherpa.com/ospf-making-sense-of-router-lsa-point-to-point-links/ for more details.
      Hopefully that helps. If you need more details, be sure to show me how far you’ve gotten on your own, and where exactly you’re getting confused.

      1. Wow, Thanks for the response. It great that you took the time. its true that Networking people really do network.
        Here what I understand for the examining the wireshark cap file.
        In Packet 1 OSPF is started on Router 192.168.23.2 (RID 10.3.3.3). At this point there is no DR or BDR.
        Up to packet 16, 192.168.23.2 is the only router on this OSPF network.
        At packet 17, Router 192.168.23.1 (RID 10.4.4.4) advertises itself.
        At packet 20, 192.168.23.2 declares itself the DR.
        At Packet 21, 192.168.23.1 declares itself the BDR. 192.168.23.1 has the higher RID number but since it started up after 192.168.23.1 it has to play the backup role.
        At packet 22, 192.168.23.2 as the DR declares itself as the master and starts the DB exchange process.
        At packet 30, 192.168.23.2 the Exstart state is initiated.
        At packet 33, the exchange state is initiated. If you notice the LSA headers are not 24 bytes for the Router-LSA. This is because all of a router’s interfaces must be advertised in a single router-LSA. The fixed part of a router-LSA is 24 bytes in length, with each advertised connection adding an additional 12 bytes. The router-LSA is then 24 + 6 (advertised connection) * 12 = 96 Bytes.
        There are 4 routers and three networks being advertised in the Database. The four routers I understand, but the three networks are not clear. 10.0.252.1 and 192.168.4 are being advertised by 10.1.1.1 . Are these networks in different area? I would assume that 10.1.1.1 is ABR and is advertising it’s know networks.
        I’m not sure what packets 34 and 35 are for, other than to acknowledge that the DB for 192.168.23.2 matchs its neighbors DB table.
        Packet 39 and 39 then advertise the know networks. All the Networks make sense, except for 10.0.250.12 and 10.0.250.3 with a matrix of 1. Are these LANs connected directly to the routers?
        Packets 42 and 43 are acknowledgement of the updates.
        In packet 69, 70 things get crazy. I think that both the DR and BRD are advertizing that they are not receiving hello packets from 10.1.1.1. This happens over and over again is packets 79- 80, 111-112 and so on.
        Once again, thanks so much for your help in this. In analyzing this wireshark file I learned so much more then than simply typing in commands to see if I got the expected outcome.

        1. Hey Manu,
          Apologies for not having time to do a full analysis, but here’s a few notes.
          In the DBD, 10.3.3.3 forwards on the LSA headers for RID 10.1.1.1. So your assumption is correct, and 10.1.1.1 is an ABR, based on the fact that it originates type-3 LSAs. Also note that the loopback of the ABR is advertised as a type-3, therefore the admin has configured the ABR loopback interface as part of area 0.
          Notice that although RID 10.3.3.3 sent these Type-3 headers to RID 10.4.4.4, they weren’t sent to 10.4.4.4 during the update stage. This is because 10.4.4.4 already had those LSAs from the ABR in it’s LSDB, via a direct adjacency with 10.1.1.1.
          In Packet 69 the ABR 10.1.1.1 is withdrawing the prefix 192.168.4.0/24, by sending an updated poisoned LSA. It does this by setting both max-age (3600) and Path LSInfinity (2^24 -1 ) 16777215.
          I know you had a few more questions, but I’ve run out of time for now. I think you’re onto a winning strategy here with the packet decodes. Once you’ve learned OSPF in this way, you’ll have a really strong understanding of OSPF. Best of luck.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.