Johannes Weber, a networking and security professional, has done something really cool while preparing for his CCNP SWITCH exam. He has built a lab with some networking equipment, configured it all, and captured network traffic, featuring a variety of level 2 and 3 protocols. He has published his setup, the captured traffic, and a variety of challenges, that helped him to prepare, and which can help others.
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. 😉
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 45 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP.
I think these are great for several reasons:
- A feature-rich and complete networking setup, which is not easily available to everyone.
- A fixed set of data (captured network traffic).
- Plenty of very specific, testable, and verifiable questions.
- Overall, very helpful resource from an experience professional, for anybody who wants to know about networks.
- Overall, a great set of questions and challenges for those interviewing networking candidates.
The lab setup includes the following:
- 1x Cisco Catalyst 2960, (C2960-LANBASEK9-M), Version 15.0(2)SE9
- 2x Cisco Catalyst 2950, (C2950-I6K2L2Q4-M), Version 12.1(22)EA14
- 1x Cisco Catalast 3560, (C3560-IPSERVICESK9-M), Version 12.2(55)SE10
- 3x Cisco Router 2811, (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M9
- 2x old Notebooks, Dell or somewhat, running either Ubuntu or Knoppix Linux
Personally, I am not very involved with networks these days. But even for more me the above setup serves as a reminder of how complex underlying technology infrastructure has got in recent years – hardware, software, protocols, and all.
The History of the URL is a brilliant compilation of ideas and resources, explaining how we got to the URLs we use and love (or hate) today. In fact, the article comes in two parts:
- Domain, protocol, and port
- Path, fragment, query, and auth
Read them in whatever order you prefer. But I guarantee that you’ll have a number of different responses through out, from “Wow! I never knew that” and “I would have never thought of that!” to “No way! I don’t believe it“.
And here is one of the bits that made me smile:
In 1996 Keith Shafer, and several others proposed a solution to the problem of broken URLs. The link to this solution is now broken. Roy Fielding posted an implementation suggestion in July of 1995. The link is now broken.
tus.io, in their own words:
People share more and more photos and videos every day. Mobile networks remain fragile however. Platform APIs are a mess and every project builds its own file uploader. There are a thousand one week projects that barely work, when all we need is one real project. One project done right.
We are going to do this right. We aim to solve the problem of unreliable file uploads once and for all. tus is a new open protocol for resumable uploads built on HTTP. It offers simple, cheap and reusable stacks for clients and servers. It supports any language, any platform and any network.
Chromium blog reports that by the early next year, Chromium (and Chrome) will phase out the support for SPDY and NPN in favor of HTTP/2 and ALPN.
HTTP is the fundamental networking protocol that powers the web. The majority of sites use version 1.1 of HTTP, which was defined in 1999 with RFC2616. A lot has changed on the web since then, and a new version of the protocol named HTTP/2 is well on the road to standardization. We plan to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks.
HTTP/2’s primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.
http2 explained – This document describes http2 at a technical and protocol level. Background, the protocol, the implementations and the future.
- The http2 spec is expected to ship in June 2014 (a month or two away!)
- http2 is heavily based on Google’s SPDY
- http2 is binary
- http2 fixes a lot of issues with HTTP 1.1 (pipelining, head of line blocking, etc)
- http2 brings new features (server push, block, reset)
- http2 will keep the URL schemes (http and https)
- http2 will mostly be implemented for https (via protocol negotiations in TLS)
- http2 already has a variety of implementations: Firefox and Google Chrome (MSIE coming), cURL, Goolge, Twitter, Facebook. Apache and Nginx expected.