I was browsing through the 255N Facebook group when someone posted this comment that got a good discussion going. There were several great points that were brought up in the conversation and I posted a short answer myself but I thought that the topic deserved a little bit more discussion.
So when I last left you guys I was attending Splunk .conf. My plan was to write each day but I quickly realized how long the day was when you included 9 hours of conference, plus commuting to and from DC each day so screw that.
Today was the first (well sort of) day of the 8th annual Splunk .conf convention here in DC. .conf covers a range of topics, is three days (well really 2.5) long, has over 200 technical sessions, and includes over 6,000 participants. In short, its a bit of a data science nerd orgie.
This is the first of what will be a number of posts on building out parts of a basic mission network. This network will be based on Centos 7 (Linux), with an IPA server (Linux version of Active Directory), have a local patching server, and a number of there features. Today’s article will focus entirely on the basic build of a Centos 7.0 system and will serve as the base system for all of the other lessons in the future
By and large I personally think that most of us are much more comfortable with layer three than any other layer in the OSI model. We deal with it each and every day. We have a number of tools at our disposal which make it very easy for us to see if/when it’s working and just how the data is traveling. To start with though, we have to know just how things are supposed to work.
When I entered the Army in July 1999, I came in as 31F (switch operator). Anyone who worked with MSE will remember that it had almost absolutely no data capabilities, but also that it was extremely easy to troubleshoot. Signal flow for MSE was pretty darn easy to understand. If you understood the idea of how the system worked, the signal flow was easy to follow. With the introduction of JNN and IP data networks to tactical communications, logical and physical said “It’s been fun” and headed their separate ways leaving our operators and even ourselves busy scratching our heads wondering how the hell it all worked.
When there is a problem with the network, time matters. We need to be able to quickly move from device to device in order to identify and rectify the problem. In order for this to occur, we have to know where to go to next, and how to get there.
Let me give you a scenario. You are having some problems on the network that are spread across several devices. You go into the log file of each device and see a bunch of messages with a mix-match of various times that mean absolutely nothing to you. In short, you have no idea what is going on with your network.
As I’ve stated in previous posts, an accurate network diagram can be really important when it comes to troubleshooting and managing the network. In order for a diagram to be of use to us, we have to maintain it which means that we update it every time the network changes. Another important part of a network diagram, is that it uses recognized symbols to depict what it is trying to show. ADRP 1-02 (Terms and Military Symbols) does a great job of providing us with standardized symbols for units of various sizes, terrain features, and even many pieces of equipment, but almost nothing to symbolize current day military communications equipment.
We have all learned an important lesson in life the hard way. When it comes to working on the router or switch, there is often a couple of commands that you discovered after beating your head against the wall for a while that if you had known about them earlier, would have made your life so much easier. These are those commands for me.