With my Written exam for CCIE: R/S coming up soon (Cisco Live 2015) I figured this would be a good time to back over some basics, and when it comes to OSPF what is more basic than OSPF LSA Types!
LSA Type 1 – These are also known as Router LSA’s, every router participating in OSPF will generate one of these, and Type 1 LSA’s are flooded within the area that the router belongs. So, what is it the Type 1 LSA tells us:
- Certain capabilities, is the router a Border router or ASBR. (Respective E-bit and B-bit)
- Does the router terminate a virtual link (V-bit)
- Number of links
- Link types – PtP, Virtual, etc
- Link Cost/Metric
So lot’s of good information in LSA-1, think of these as a ‘blue-print’ of the router, describing what is has and what it is doing.
LSA Type 2 – Network LSA’s. These LSA types are generated by the DR (Designated Router) and one type-2 LSA is generated for every network with two or more OSPF neighbors. You can expect to find these when you multiple devices connected to a broadcast network (A.K.A. LAN) or on an NMBA network (Frame Relay/DMVPN). Type-2 LSA’s will include information about the attached routers along with information of the network segment. This LSA is just an informative one, letting you know what other Routers you are connected to along, no metric/cost information is included in a Type-2 LSA.
LSA Type 3 – Summary LSA’s. Type-3’s are generated by ABR’s and are used to extend reachable to other OSPF areas. Remember LSA Type-1’s are limited to the area that they originate them in. They also designate Inter-Area connectivity as opposed to Intra-Area connectivity. A good rule of thumb is for every route in the routing table, there should be an associated Type-3 LSA in the OSPF LSDB.
LSA Type 4 – Think of these as Type-3 LSAs however instead of being generated by ABRs they are generated from ASBRs. Type-3 & Type-4 LSA’s use the exact same format, however the differentiating factor is the fact, a Type-4 Link State ID is the Router-ID of the ASBR. (Where-as a Type 3 LSA will/may have a Link State ID of the IP Network)
Similarities in Type-3 & 4 LSAs
- Cost/Metric information is included in these LSAs (unlike Type-2 LSAs but those do serve a different purpose)
- Contain routing prefix/host information for reach-ability purposes.
LSA Type 5 – AS-External LSAs. Type 5 LSAs are also originated by ASBRs and represent external routes from another Autonomous System (or routing protocol) typically done via redistribution. Type-5 LSAs will contain metric/cost information similar to that of Type 3s & 4s, however because this information external from the OSPF routing domain there is some additional information included within this type of LSA.
- External Metric (E-bit) – Designates the external metric of the route. Used for Type-2 External routes, where as Type-1 external routes do not include this information (IE: Set to 0, so the field is included just the value is set to 0)
- Forwarding Address – Specifies where transit traffic should be sent, in some cases this can be (intentionally) set to all 0’s in which case the forwarding address will be that of the Router-ID of the originating router.
- Route Tag – Used to set tagging information of the route itself (typically for mutual redistribution purposes). 32-bit field.
- Remember redistributing static or connected routes also generates Type-5 LSAs, the routes do not always have to originate from another routing protocol.
LSA Type 7 – External LSAs, only found when using NSSA Areas (Not So Stubby Area). So if Type-7 LSAs are only found in NSSAs then how does this reach-ability information make it to other areas? Well the NSSA Border router will translate these Type-7 LSAs to Type-5s for the rest OSPF network/Areas, this is designated by the P-bit / Propagation bit.
Back to studying I go!
Configuration management, without a doubt this is probably one of those things we all do, but to what end do we perform configuration management though? Usually configuration begins and sometimes ends with backing up and storing those configuration files but how much further can or should we go with configuration?
- Backing and storing configuration files – As mentioned before, this is step one. Keeping a copy of your device configuration is one the easiest and quickest ways to restore a device back into service after a physical failure.
That one task, as simple as it sounds it the heart of good configuration management. From that original point we gain the ability to perform many other tasks:
- Configuration comparison – Having the ability to compare two of your previously saved configuration can prove to be an invaluable resource. Let’s say you have dozens or hundreds of remote “cookie-cutter” devices out there and you have a single device acting up, comparing the configuration to a known good configuration can save you much troubleshooting time. Especially when you consider many configuration managers are convenient enough to highlight discrepancies making possible errors stand out like a sore thumb.
- Configuration / Version archival – This point follows suit with comparing configurations, because in most cases you may want to compare configurations from the same device that are from different points in time. Making it easy, to pin-point any recent configurations that could be causing the issue at hand.
- Reacting to configuration changes – Changes are a way a life, if nothing is changing then something is wrong, the tougher part is dealing with a way to manage those changes:
- How do you know when a change occurs? – Many configuration managers will re-act to a device generated syslog or SNMP trap, do you have this configured, are you made aware of changes?
- What do you do when a change occurs? – When this mysterious change occurs how do you re-act, do you acknowledge some type of alert or review some daily/weekly report, perhaps there are some checks and balances to ensure the altered configuration has been backed up after the change or to verify that the change was committed to memory?
- Can you correlate network events with changes? – Do you have any capability of correlating network faults with configuration changes? There are definitely a few of those ‘eye in the sky’ type NMS platforms that are capable of linking device level events to any correlating configuration events on that device. Now, if only we can get a more abstract ability to monitor device groups holistically linking events. In my opinion event correlation exist to some degree with many NMS products, but there is definitely a lot of room for improvement.
- Do you enforce a baseline or set configuration standard? – This one in my mind, is where many tools have lack-luster performance, when you find yourself in a situation with many nodes, you definitely want some ‘checks and balances’ out there. How upsetting is it when you find out that the issue you have been troubleshooting is all because a recent firewall change or routing policy change never got deployed to a particular device? If you can enforce some type of configuration ‘compliance’ or ‘baseline’ I guarantee you, that you solve many headaches before they occur.
- Software Management – While, this might seem outside of the scope of configuration management keeping your software versions in sync can be quite important and detrimental for keeping configurations in Sync
- Software versions – Different software versions may implement different command syntax, this in itself can make configuration & troubleshooting tedious in itself. Different versions may also suffer from different software bugs/caveats into your environment.
- Software licenses – Depending on the vendor and the device, if the incorrect license is applied or the incorrect software train is installed on the device some features may not even be configurable. Nothing is more upsetting then when you are trying to configure a device and you find out a simple license (non-technical) issue is the root cause.
So, there we have some groundwork for configuration management do you have other considerations in regards to configuration management?
One of my favorite questions: ‘What format do you want that certificate in?
Which then forces me to think and try and remember what was so special and different about all the certificate formats again?
We’ll start with:
- PEM – Privacy Enhanced Mail
- Certificate represented in text format. In a Hex/ASCII format BASE64 encoded
- DER Encoded.
- Key – Private Key
- This format is used for storing private keys.
- Found in the .key extension.
- Defined in RFC 2315
- More than a single certificate can be bundled in this format.
- Certificate chains can be included in this format.
- Typically found with .p7b, or p7c extensions.
- More than a single certificate can be bundled in this format.
- With this format both the public and private key can be exported/combined.
- A key difference between PKCS#12 & PKCS#7
- Even certificate chains can be combined into a single file.
- Typically found with .p12 or .pfx extensions
Just a quick run through of the a few certificate types.
Well, I finally took the time to buckle down and take the WCNA – Wireshark Certified Network Analyst. Once I finished up with the exam I can happily say I successfully past the exam which I have to admit is pretty cool. Protocol Analysis is definitely an interesting set of technologies to learn & know, it is also extremely beneficial for troubleshooting certain types of issues.
How I studied:
Having a few years a packet analysis behind me certainly helped, however the Wireshark WCNA Books from Wireshark University are absolutely fantastic!
The network analysis book, while it is expensive is definitely worth it. To me, this book is to protocol analysis; is what Routing TCP/IP Vol I & II is to a CCIE: R/S candidate. It is a large book with great material, a book you can keep on your book shelf at an arms length for years and still use for reference. This book will also cover all the WCNA Exam Objectives, making it an important resource if you are studying for this exam. The other great piece I loved about this book was all the real world case studies, it’s one thing for a book to teach you topic but it’s completely differently for a book to show you how this knowledge is applied in the real world. At the end of each the chapter the book points you toward PCAPs to test your newly learned knowledge which are available for free off the Wireshark book website.
Once you finish with the Network Analysis book, this is where the Prep Guide comes in. I bought the prep guide the weekend before my exam and went through all the questions, using that book to judge where I stand with the objectives. I did pretty well with the Prep Guide, missing maybe 10% of all the 300 questions so I figured it was time to schedule the exam and took it later that week.
I also read through the Wireshark 101 book, which in my opinion is a good book for anyone just starting out with Wireshark or if you want to start customizing wireshark. Which I highly recommend, however if you already familiar with Wireshark I’d skip over this one.
There are also a few great YouTube channels out there, with some great Wireshark videos and even some Sharkfest videos.
Just because I finished the WCNA, does not mean I will stop posting my Wireshark Tid-Bits I’ve still got plenty more of those in store.
Many of us are familiar with the GUI version of Wireshark, but believe it or not but there are also a slew of other command line based utilities that enhance Wireshark and also aid us in capturing and analyzing data. Let’s take a quick look at some of these tools.
- tshark – This is pretty much the CLI equivalent of Wireshark. Allowing you to capture packets like you are using tcpdump, specifing interfaces, filters, etc. It’s definitely worth taking the time to get familiar with tshark.
- dumpcap – This is another CLI equivalent of Wireshark, however this utility writes directly to a file and is less feature-rich then its ‘tshark‘ equivalent. Think of this as the cheap and dirty Wireshark, hop into a system and initiate a dumpcap then boom you have your capture.
- mergcap – As the name implies, this tool allows you to merge multiple captures files into a single capture. Since, Wireshark does have a limitation on processing large file sizes you also have the ability to truncate packets after so many bytes. Similar to what we will do with editcap shortly.
- editcap – This is very nifty, allowing you to do many different things:
- Pick out specific time frames of a packet capture.
- Remove duplicate packets. In case you accidentally captured at multiple locations or fubar-ed your SPAN or TAP locations.
- Truncate packets after so many bytes. This is very handy incase you only want to look at packet headers.
In the below example I am taking an existing PCAPNG file and limit every packet to 40 bytes into a new file filter.pcapng. So you can decrease the file size making it easier for Wireshark process while still keeping the header information. 40-bytes is a bit much but hey it gets the point across.
- capinfos – Provides detailed information about the packet capture in question.
- Average Packet Size
- Time stamp information
- Data rate or packet rate
In the GUI you can get most of this information from the ‘summary‘ -> ‘statistics‘ page which I covered in a previous post, but the CLI version can provide quick and easy access to this information without the need to even launch Wireshark.
Sample output from capinfo is below:
Well, my first draft got lost in the cloud so let’s try this again!
The more you use Wireshark and the more familiar you get with protocols / packet analysis the quicker you realize what you may need to for. Luckily for us, if we know what we are looking for we can configure Wireshark to turn that needle in a haystack into a firework on the middle of Halloween. It does this by giving us the flexibility to control what information Wireshark displays to us and how Wireshark displays that information. The two most useful features we have are profiles and coloring rules, both of these are very powerful features and using both of these features together allows you to take your analyzing skills to the next level.
Profiles – Profiles give us the ability to control what information Wireshark displays to us, and how the information is displayed.
- Affecting the complete layout of the Wireshark display
- What columns are displayed in the Wireshark display
- Which coloring rules are in affect
Now, that we know some of the ways profiles affect Wireshark lets consider a few good use cases for profiles, below are a few profiles I have.
- Wired-VoIP – This profile will call out the DSCP field as specific column to easily keep an eye on QoS marking.
- Remote-Site-VPN – Calls out specific columns for the DF-Bit, IP & TCP length, and more fragment field.
- Wired-Transaction-Time – Contains specific columns for relative time & absolute time, etc.
Those are just a few ways profiles can be leveraged, and remember it is easy enough to flip from one profile to the next. There is no need to even close the current capture or restart Wireshark. This allows to quickly scroll through a single capture looking for key characteristics.
Coloring Rules – These coloring rules define how Wireshark displays the individual packets, it’s these same coloring rules that make re-transmissions show up in red. It’s important to remember that coloring rules are match from top-to-bottom and they will by specific criteria found in the packet. These coloring rules are tied to specific profiles, so you definitely want to keep in mind what profile you are working under.Below are a few of my coloring rules:
- WLAN-RETYU-PACKET – This filter looks to see if the packet is a retransmission of the RF medium. Might be useful if you are troubleshooting a WLAN performance issue.
- FRAG-PACKET – This rule calls out any fragmented packets by keeping an eye out on the ‘More Fragments’ bit. Could be a useful statistics if you working on performance issues in remote IPSec VPN locations.
- Kerberos_MSG – This filter actually picks any kerberos related packets, cause sometimes when Windows says the login failed due a network timeout it might really be due to a kerberos authentication issue. (FYI: Kerberos type 30 messages are errors. So you can be a bit more specific with this filter if desired)
- PC-1500-MTU – This Filter actually matches on two packet fields. First we make sure the packet is a ‘SYN’ packet, and then look to see if the TCP Max Segment Size is at 1460 which ideal for Ethernet networks. Sequentially, there is also a coloring rule for when the PC advertises a MSS that is not 1460. (PCI-NOT-1500-MTU)
Those are just a few examples to show how powerful the coloring rules can be, we can match on any field within the packet regardless of whether it is the Layer 2 MAC address or a piece of data with the application payload. Not mention we can match by multiple fields at the same time, talk about potential! The only thing I want to re-iterate is the matching is top to bottom, so in this example when Wireshark finds a Kerberos message it will hit the first coloring rule and no other even it is a retransmission. That is just something to keep in mind.
You can verify why a coloring rule is in affect by looking at the ‘Frame’ portion of the packet:
From the above, you can see which coloring rule we hit and why we matched this specific coloring. Very useful in the event we ever need to troubleshoot our own coloring rules.
So, now that we spent all this time creating profiles and coloring rules how do we back them up or transfer them to another laptop/desktop? Well, all these configurations can be transferred and backed up by copying only a few folders. If you are running Windows 7, you’ll find this under AppData\Roaming\Wireshark for your specific windows account.
It’s the Profiles folder we really want, once we take a look in there we see our specific profiles. Although you will probably be better off just copying the entire ‘Wireshark’ directory.
I wanted to start off stating Brocade broke one of the biggest barriers with getting involved with SDN and labbing out the technology. Brocade offers a free download of their Vyatta Controller! With this free download you can run a 5x node SDN network for one year, included with 60x days of support! This eliminates a huge obstacle of actually purchasing the software, sure you may still require the hardware but Brocade SDN Solution features support for OpenDaylight/OpenFlow so you do have many different hardware options.
Now, that I got that out of the way my two favorite pieces of the Brocade was 1. The technical overview of the Vyatta controller and it’s architecture, it was great to see how to the services overlay on each other and what makes it tick. Usually when it comes to some type of SDN solution it’s usually presented as some type of application that does magic. In this case however Brocade definitely did their due-diligence to cover how their controller actually functions. The 2nd thing I loved about this presentation was just how frank and up-front the presentation was. My favorite quote of the whole the presentation was “We know how to code, we went to school. We chose not to program we went into networking.” I can’t say how happy I was to hear someone actually say this! However like it was mentioned in the presentation it appears to be a natural evolution of the field.
As the presentation continues, you really get a sense about how far along the Vyatta controller has come along once the conversation steers towards volumetric traffic management. Having the additional and built-in monitoring of the traffic flows with sFlow and OpenFlow addressing a level of application performance management many current-day data centers frankly do not even have in place today just shows how grown up the tool is becoming. This is built upon again with the flexibility to handle elephant flows differently than other typical data flows, if you are not familiar with the term elephant flows these are just traffic flows that transfer a very high amount of traffic (IE: Something like backup traffic). I can’t tell you how many few companies I’ve worked with in the past that have actually taken into account these ‘elephant flows’.
Now, I don’t want to ruin the whole presentation for you, if you have not watched it yet I highly recommend you give it a watch. There also a great slide in there about Ivan! If you think SDN is still a mystery it’s time to get that Vyatta controller downloaded and running! No more excuses!
You can download the Vyatta Controller here.
Brocade’s Networking Field Day #9 videos can be found here: