IT Job Advice: Tickets/Work Orders

 I'm going to be honest here, I hate ticket systems. I hate filling out tickets. One thing I was never taught in school when learning IT was that most of the job is actually a bunch of bureaucratic fluff. I mentioned in a previous post that documentation is super important and an easy way to get you some praise at your job. Another piece that requires little technical information but extra stupid paperwork is tickets.

Here's the thing with tickets, I've heard the arguments about tracking work done for historical purposes, using notes for fixing future things, etc. Truth is, I've never seen it used for that at all. Notes are often useless, and often times important historical detail is left off or there's lies in the notes. The truth is they provide on important thing that allows IT managers to negotiate with HR, payroll, and hiring managers, and that is METRICS! That's right, it's all about tracking work hours. So why are the notes needed? To justify the hours the ticket represents.

So how does one be successful with tickets? The first is, add any notes you can, it doesn't even have to be fully technical. You just need to show "I did X task(s) and it took ## hours" in such a way that the hours spent are justified by the task performed. Also, attach any and all communications around the ticket to the ticket. This will also be a good cover for if a task takes too long or if a user lies about something communication-wise.

Another important piece that relates to the metrics ticketing systems offer, is meeting a Service Level Agreement (SLA). Keeping the metrics looking good, or having a documented justification when something is going a bit sideways will get you praise from managers up the chain with everyone concerned about what those metrics mean.

So the simple flow is as follows:

• Tickets track hours
• Notes justify the time spent
• Communication justifies solutions or breaches an SLA

The metrics there can then be used to:

• Justify the job or needs for more people or time
• Justify why an SLA might have been breaches
• Prove the situation was resolved or whatever closeout reason was used

Despite all of these good reasons, tickets still suck. It's time consuming and feels like a waste of time when you could be doing something productive. However, if you want to succeed in IT, fill out tickets as best you can to meet these specific notes and you should be successful at your job.

IT Job Advice: Documentation

Back when I started in IT, specifically back in college, there was a lot of advice I never got. When I got my first real IT job,I'm I thought the most important thing was technical skills. Now, I've learned something very important I wish I knew when I started. There's is a way to make a huge impression very quickly, faster than you can with demonstrating actual technical skills, even with limited technical skills, and secure your way to actually getting promoted. The biggest skill you can have is documentation. 

When I started in IT, I never thought about documenting because a lot of it seemed super simple. After years of pricing what I could do, I got asked about documentation. When I wrote it, I got told it was the first thing they ever read. I didn't understand what they wanted then, but now I know what was wanted. It may sound stupid and annoying, but what a lot of bosses in IT seem to want is easy to follow documentation so that anyone on your team can do the exact same things everyone else can in a pinch. 

This leads to a few different types of documentation you can make. The first is instructions. Given a scenario, follow the steps and even a trained monkey can look like a tech wizard. Another type of documentation is the broader troubleshooting guides. Give some commands or things to test and some dynamic workflow to either get a solution or information for a solution. Then we have diagrams. Explain what is plugged in where, how, why, etc. so that people can find what they need even if they don't really know what the setup should be. We also have the contact list. Who to contact for what with all the information needed. 

By creating documents like this in any format your job might have available, you can get instant praise at any IT job. A common problem occurs, link a document so no one needs to even ask about it repeatedly. Internet goes down, have the number and information on have ready to go with emergency level speed. Need to find where a specific device is plugged into or where a cable goes, check the diagram. Don't know how to troubleshoot some proprietary software your company uses, have a guide ready for your specific use case. 

I never really documented until my current job. Now, I work on a OneNote and SharePoint with a coworker. When a new lead took over, simply linking the document got us praise before we even demonstrated a single technical skill. It's even gone a step further into us attempting to document all the historical changes so we can go back and reference anything that anyone else has done. 

Now let's talk about verbosity and technical level. For emergency info like contacts, cut and dry works. For everything else, assume whoever looks at it, it's their first day on the job. Be specific, hand hold, and if needed, reference other references to detail acronyms, systems, and software. We're taking RFC level verbosity with day 1 technical hand holding. 

This is the advice I wish I had from day 1. Now let's say your job already has documentation, then what? Update everything you come across, full in any missing detail, and always tell people you updated or fixed it. You will get on much easier in your IT career if you document, talk about documenting, constantly respond with new updated documents, and make a workflow all about documenting.

Hope that helps anyone getting stuck in their IT career!

Understanding VLANs

A topic I'd like to cover with Networking is VLANs. To understand a VLAN is very good for getting into networking concepts looking towards it as a profession. Hopefully this article helps you understanding the basic concepts of a VLAN as well as some of the more technical terms related to a VLAN. Let's begin!

1. What is a VLAN?

Definition: Virtual Local Area Network (LAN)

A VLAN is a Virtual LAN that can be used to create a logical separation on network devices. This can allow multiple networks to ride on the same equipment, and even links, providing extra efficiency for networks and adding some extra security (not perfect, but it helps).

When we are talking about efficiency, this is because it helps to control the size of a broadcast domain. This can allow a single piece of equipment the ability to serve multiple requirements for networks without things getting to big that they begin to interfere with each other. This broadcast domain is on Layer 2 of the OSI model. This is where your Media Access Control Address, or MAC address comes into play. You may also see the term Hardware Address, or the least common term EUI-48 (Extended Unique Identifier) 

2. How VLANs Work

As mentioned a VLAN is Layer 2 on the OSI model. The protocols fall under the IEEE 802.1Q protocol. The VLAN is attached to the Ethernet Frame. Now a common misconception is that Ethernet is a cord. Ethernet is a Layer 2 protocol that defines how frames are formatted and transmitted over physical media. It's not just the cabling; it's the entire protocol standard used at Layer 2. The simplest way to put what happens, is we add a 4-byte identifier to the Ethernet frame. 

When devices on a network need to find one another within the same subnet or need to talk to all devices on the same subnet, they will send out broadcasts. On a large network, this can be a lot of traffic. To reduce this, when devices do not need to interact with one another, we use the segmentation methodology by utilizing VLANs. On the network, this traffic will be virtually isolated to devices within the same VLAN.

A quick overview into 802.1Q shows is will insert a 4 byte segment into the Ethernet Frame. The first 16 bits is the Tag Protocol Identifier (TPID), followed by 3 bits of Priority Code Point (PCP, part of 802.1P related to QoS), 1 bit Drop Eligible Indicator (DEI, indicates if frame can be dropped from congestion), and finally 12 bits of VLAN Identifier (VID) which gives 2^12 or 0-4095 of potential values.

3. Types of VLANs

Let's start with a very special VLAN. This is a special VLAN you can never truly get rid of because it is very important, VLAN 1. This VLAN is used for a lot of internal communication on the network such as CDP, LLDP, VTP, and many other protocols. It is also the VLAN used when you have no VLAN explicitly selected for a default VLAN.

Other special VLANs include some reserved VLANs.

• 0 and 4095 - Unusable, reserved for system
• 1 - Remember, you cannot delete this, it's a default
• 1002 through 1005 - Defaults for FDDI and Token Ring

Outside of the reserved VLANs, for best practice you can use any others for data. How you choose to use them is really up to you and however deemed best to setup the internal functions and really just configure them however you want.

Voice VLANs are used for VoIP services. If your equipment allows you to identify a VLAN for a voice function, I highly recommend you set that up. Aside from the optimization they will allow, it also allows the VoIP devices you plug in the chance to discover the VLAN they need if they support that kind of feature. This can help reduce a lot of headaches and even speed up a VoIP device configuring itself.

A Native VLAN is a VLAN on a trunk that is the default VLAN assigned should there not be a tagged VLAN. This is usually going to be the VLAN that is directly interfacing the user devices or anything that does not support tagging its own VLAN. Pay attention to your native VLAN when trunking as it will default to a native VLAN of 1. Also, if the native VLANs do not match, traffic will still pass.

Tagged VLANs are explicitly marked as being on a specific VLAN. By tagging a VLAN, you can have a single interface participate in multiple VLANs where it can be separated out to different segments.

4. Access vs. Trunk Ports

An access port is a port with a single native VLAN usually interfacing an end device. If you are on a Cisco device, you can have an "access" port that also has a voice VLAN. Other devices will use a trunk port with the voice VLAN tagged on that port. A trunk port will also facilitate communication between switches containing multiple VLANs. You will often hear the terms "access port" and "trunk port" when discussing higher level network design.

When it comes to 802.1Q, you will likely see no tagging on a native VLAN, but you need the tagging on the frame for a tagged VLAN. Some switches have an option to force a VLAN to be tagged even if it is a native VLAN.

5. VLAN Configuration

Instead of giving a specific brand example, I'm just going to go over what it needed to configure a VLAN. The reason is, I've worked with too many different brands and I know they can be a bit... too different, and I don't want people to copy-paste and then be confused when it doesn't work. Instead, here's the concepts and you can grab yourself a CLI reference for your brand and good luck!

When configuring a VLAN, the first thing you need to do is make the VLAN. Some devices will let you just apply it to a port, but if the VLAN is not in the global configuration, it does not work. Some devices will not let you add a VLAN unless it is configured.

With your VLANs created, you can then configure your ports. First you need to identify if it will be an access or a trunk port. Then you decide what VLAN(s) you want to assign to that port. Simple as that!

6. Benefits of Using VLANs

• Improved security with isolation.
• Reduced broadcast traffic through segmentation.
• Better organization by function or need or usage.
• Easier network management and scalability by running multiple virtual networks the same devices.

7. Common Mistakes and Gotchas

Always remember to configure your VLAN so it actually exists to be used! Seems simple, but I've seen too many people make that mistake in a rush.

Pay attention to your trunk links. If a tagged VLAN is missing, the traffic will not traverse. If the native VLAN is mismatched, traffic will pass unless you set the switch to force native tagging. This means you risk leaking traffic or hopping VLANs. A scary thought is I have seen this done on purpose, which may lead to traffic working when it should never have worked. Fixing this down the road could lead to a major lift, so do not do it or rely on it. Should also mention that a mismatch can cause issues with Spanning Tree Protocol (STP) and general security issues.

Make sure your VLAN covers the broadcast domain you need. It sounds simple, but that means also taking into consideration how it can affect routing, like when it will need to route on Layer 3 instead of switching on Layer 2.

8. Real-World Use Cases

In the world of technology, segregating traffic is necessary for being efficient and secure. Micro segmentation is even better, but let's start here. When it comes to networking, a VLAN may be used to separate departments, VoIP, Security devices, HVAC systems, fire alarms, IoT devices, WiFi traffic, etc.

If you have two departments in the same business, you may want to prevent departments from seeing and using a printer in a different department, a VLAN can help with this. If VoIP is having an issue with jitter or something about the quality, a VLAN can help you manage this. If you don't want people seeing very discoverable IoT devices, put it on its own VLAN. Security devices should be isolated, so put it on a VLAN. HVAC systems send out a ton of broadcasts, keep it under control on its own VLAN. Fire alarms are critical, secure them on a VLAN. Your WiFi system may need a lot to configure itself and pass traffic, keep it on its own VLAN to help manage it.

There are so many instances a VLAN can be used to make things better, so use them. Just remember to keep track of everything so you can keep traffic flowing and do not accidentally isolate it.

One other thing to consider is what some may call a "no hop" VLAN or an isolated network. All this means is a VLAN that goes nowhere. It's a way to make an isolated traffic segment and just means do not have it leave. I've used VLANs of that design for internal functions that need to move mass amount of data I do not want to interfere with anything. It's also fairly secure if there's no way in or out.

9. VLANs and Layer 3 Boundaries

As I have mentioned, a VLAN is a Layer 2 function. A VLAN is also used for a Layer 3 boundary. This can be achieved on a switch using a Switch Virtual Interface (SVI). I have heard people say it is still Layer 2, but it is not. It is just a virtual Layer 3 interface directly associated with a Layer 2 VLAN.

An SVI can be used as a gateway, for setting up point to points, an access IP to interact with the network device, or anything else you can think you want to use an IP for. If you need to extend your Layer 2 traffic to something outside, you can use the SVI with an IP helper address to facilitate that.

These are good to know, especially when getting more into Layer 3, but for now we can leave it at that.

10. Final Tips and Best Practices

Now the fun part.

Avoid using VLAN 1 in production for normal traffic. VLAN 1 does a lot with discovery, so for security and sanity, keep your traffic off of it. Also remember, even if the device does not show it in the config, it's there. I've been told to delete it before, it's not possible. Best we can do is pretend it isn't there by not passing normal traffic across it.

Management traffic should be on its own VLAN. This is things like your SSH for devices. I also recommend you keep it a flat Layer 2. By keeping your management traffic separate, that means as long as you have that traffic flowing, you can get to your devices remotely and keep it secure since it's virtually separated. By keeping it a flat Layer 2, then you can maintain traffic while working on Layer 3 configurations with less risk. Basically, give it as few chances to fail as possible.

Document your VLANs and use good descriptions. Keep in mind, if there is no Layer 2 connection, you can in theory re-use a VLAN ID without issues. However, once they touch, the traffic flows. So document well. The descriptions just help you keep your sanity.

All of that being said, VLANs are actually a very simple concept with a lot of utility. So keep it simple, obvious, and well documented. Do not overthink it or you may get lost in your own spaghetti mess.

Techs from the Crypt: OSPF Flood Wars!

 It's been a while since I posted anything, but I wanted to try to get back into posting stuff. What better way to start than another tech horror story! Currently I am working as a Senior Network Engineer, a recent promotion I am quite proud of. One of the reasons I earned my current title is due to my involvement in a lot of troubleshooting sessions and overall network improvement. With that, it makes sense strange issues tend to land in my lap. One of these issues that happened to land in my lap was an OSPF Flood War. Not my first one, so I figured easy enough. We had four devices showing up in logs with intermittent connectivity. With a bit of luck and some careful planning, I managed to get on each one and fixed what was showing as duplicates. With solid connectivity restored I closed out the tickets, only took me most of a day since it was a remote site.

The next day, I got a message about another OSPF Flood War message for the same four buildings. Connectivity was still solid. All four buildings had no errors, but the upstream did. I went over the same four buildings and the upstream device multiple times for most of the day. Still no luck what was making the messages show. Digging through everything I could find, I decided to ask around.

One of the new engineers I had helped earlier working on getting phones setup at the same remote site, but on a completely different building. This building did not show up in any of the logs. With no other ideas, I got into the device for the building. It finally revealed itself when I went into the switch. The voice network is on a separate VRF and the point to point VLAN on the uplink was in the voice VRF and the downstream one was on the default. Thus, two VRFs leaked into each other across one device that never showed up in any errors logs. Two days of staring at devices and it was that simple. It was a nice and easy fix of just moving things into the appropriate VRF.

With all that, moving forward I am hoping to work on some more technical posts focused on network, since I guess that's my life now. I may also consider enlisting the help of all the new fancy AI tools and if I do, I will disclose that on the post. Just a consideration because sometimes my thoughts are too boiled down and dry to make a coherent post as opposed to just like a bullet list of information. Just a thought. Hope you enjoyed my story!