- What kind of networking jobs are there?
- What are the different networking specialties?
- Routing & Switching
- Voice and Video
- Data Center
- Service Provider
- How do I get into networking?
- Do I need a college degree to be a networker?
- Do I need certifications?
- Do I need to know a programming language?
- What should I list on my resume?
- How much do networkers make?
- How do I find a job?
- Do you have any interview tips?
- What are the negative aspects of networking?
What kind of networking jobs are there?
Computer networking is a vast field, rivaling general IT in the diversity of roles it offers. While all areas of networking share a common fundamental level of knowledge, most networkers find that they gravitate toward one or two specialties through a combination of interest and necessity.
Starting at the entry level, there are IT help desk and network operations center (NOC) positions. Depending on the size and breadth of an organization, these two departments might be combined. Most people entering the field out of high school or college will spend their first few years in one of these roles building real-world experience.
At the next level is network administration or operations, followed by network engineering. What’s the difference? Administration generally refers to the maintenance and operation of an existing network: Configuring switch ports, tweaking the office wireless, upgrading firmware, and so on. Tasks that, while certainly necessary and respectable, don’t require a deep knowledge of the technology involved. In many smaller companies, network administration is considered an extension of systems administration.
The engineering side is where the fun and challenging problems lie, and where you’ll need a healthy mix of knowledge and experience to thrive. Network engineering is often divided into junior and senior roles, though there’s no rule for doing so, and a “senior” engineer at one organization might be considered a junior engineer at another. The titles are only a loose approximation of the skill level or seniority required relevant to other positions within the company.
The top tier is network architecture. At this level you seldom deal with the day-to-day operations of a network, and might never even configure devices except to intervene where a serious issue has arisen. The role of an architect is to develop the network to meet changing business needs across a long timeline. This can include evaluating new products and technologies, authoring high-level network designs, compiling budgets, and so forth. The job of architect is sometimes rolled into a network team manager position.
What we’ve covered so far are just the horizontal tiers of the networking career matrix. There are many vertical disciplines across most tiers as well, such as voice, wireless, security, data center, storage, service provider, or automation. Many networkers tend to gravitate to one or two of these specialties once they’ve mastered the fundamentals. Some vendors, like Cisco and Juniper, maintain certification tracks dedicated to certain specialties. Where you end up is a function of your interests and your employer’s needs.
What are the different networking specialties?
Networking as a field is considerably diverse. Through the late nineties and into the 2000s, networking has grown from an extension of systems administration into a field all its own, and over the past decade or so has come to include a number of subfields pertaining to specific technologies and their applications. While there’s no official definition for any of these, the professional community generally recognizes the following distinctions (many of which you’ll likely recognize from vendor certification tracks).
Routing & Switching
Routing and switching comprise the core competencies of networking. This is where most people start in the field, branching out to other areas of interest. R&S skills alone primarily apply to enterprise networks but serve as the foundation for all other concentrations.
Most people equate security with firewalls and intrusion prevention systems, but to excel in this area requires a refined understanding of security policy and how it can be effectively enforced. This extends beyond hardware to include building VPNs, Denial of Service (DoS) prevention, mitigation of spam and phishing attempts, network access control (NAC), and myriad other technologies employed to protect a network and its users.
Once a tangent of vanilla routing and switching, the ever-increasing demand for wireless networking has given rise to the formation of a dedicated subfield. To excel at wireless networking, you’ll need a thorough understanding of radio theory, controller and access point design, wireless security, client roaming, quality of service controls, and other concepts unique to wireless communication.
Voice and Video
Real-time communications probably entail the largest subfield of networking. In fact, it’s perfectly plausible to dedicate your entire career to working only with voice over IP (VoIP). Voice experts need to be familiar not only with IP networking and VoIP, but to a large degree also the general telecommunications industry, including legacy phone networks. Video teleconferencing, while perhaps not as widely implemented as voice, is a growing market with very similar design requirements.
It might seem strange that “data center” is mentioned as a particular discipline within networking since, after all, most networks incorporate some form of data center. But the density afforded by data centers accommodates technologies not often found elsewhere, including storage networks (SAN), virtualization clusters, and extremely highly available (HA) systems. Data center networks also tend to operate at higher speeds and under much stricter downtime allowances than networks outside of purpose-built facilities.
Service provider networking tends to revolve around long-haul communications and Internet connectivity. Networkers who work for service providers focus more on the paths traffic takes from one network, or autonomous system (AS), to another.
How do I get into networking?
You optimal strategy for pursuing a job in networking depends on your current position in your career. If you’re fresh out of high school or college, your primary concern should be to build real-world experience as quickly as possible. Having an internship under your belt can help put you ahead of other candidates, but you’ll still likely start off with an entry level job at an IT help desk or NOC. This isn’t a bad thing, but most people tend to pursue higher positions as soon as possible not just for the increased compensation, but to escape the unfortunate stress and tedium inherent to these roles.
If you’ve been working in a sister IT field like security or systems administration for a few years and beefing up your network skills, you might be able to land a job as a network administrator or junior network engineer. There might even be opportunity to cross-train into a networking position with your current employer (in which case the biggest challenge can sometimes be finding a suitable replacement for your current role).
If you’re stepping into networking from a different field entirely, the transition is more daunting. Networking – IT in general, really – moves fast and won’t wait for you to catch up. People coming over from unrelated backgrounds can feel overwhelmed by the breadth of new and seemingly ever-changing material to cover. But if you’re genuinely interested in a career in networking, stick with it. As with anything, experience (good and bad) breeds confidence.
Finally, a number of people (myself included) come into the field by way of military service, either having worked in IT during enlistment or commission, or having developed the skills through post-service vocational training.
Do I need a college degree to be a networker?
I hope not. I don’t have one and I’ve been doing this for years. I’ve even been extended offers for positions which clearly listed “bachelor’s degree” under mandatory requirements (these requirements are usually tacked on blindly by HR departments). While a college degree certainly isn’t going to hurt you, the more clued-in hiring managers greatly favor passion and experience over formal education. This is primarily because IT moves faster than college curricula.
For instance, let’s say you enrolled in a four-year degree program in the fall of 2011. At the time, no one had ever heard the term software-defined networking. Yet when you graduate in 2015, it seems that it’s the only thing people are talking about. While you were learning about networking, networking went and changed. Welcome to the world of IT.
And this is assuming you major in something pertinent to computer networking in the first place. Many universities don’t get more granular with their degree programs than computer science or information security, both of which are relevant, but neither of which will teach you how to build and operate a network.
Do I need certifications?
This is topic of much debate and heated opinions throughout IT. The issue is divided primarily into two camps: Those who believe certifications act as proof of competence in a subject, and those who believe that real-world experience trumps formal assessment. As with most debates, actuality lies somewhere in between.
Few people will dispute that certifications offered by vendors (like Cisco and Juniper) and non-profit organizations (like CompTIA and ISC) offer an excellent path for professional development. While the topics they cover don’t always map to practical skills, it’s nice to have a roadmap showing where you’re headed and to acknowledge milestones by way of passing exams. They’re also a great avenue to evaluate your interest in particular specialties. Many people opt to pursue a single track to the expert level while picking up a couple associate-level certifications in other disciplines to break outside their comfort areas.
The downside to certifications is that they are often over-valued. After all, a multiple-choice test is not a great measure of someone’s skill as an analytical thinker. Some certification exams include lab simulations of real designs and problems, but these are necessarily constrained to very narrow parameters.
There’s also the widespread issue of cheating. Ultimately, a certification is just proof of having passed a test, and people cheat at tests. A number of disreputable companies record and sell copies of exam questions, called braindumps, which greatly dilutes the value of a certification. Some individuals even go as far as to pay someone else to take a test for them. In recent years, Cisco and other certification authorities have even begun requiring candidates to be photographed each time they take an exam.
Do I need to know a programming language?
Probably not, but this requirement is highly subject to change with the growing trend toward network automation. And knowing how to code is an invaluable skill even if not a strict requirement of your desired position. If you’re familiar with a particular programming language already, great! Be sure to keep in practice with it, so that even if you end up needing to learn a new language, you’ll already have a programmer’s mindset.
If you’re not already skilled in a programming language, I suggest learning Python. Python is very friendly to the novice programmer; easy to read and easy to write. It’s also very popular among network platforms, and can double as a scripting language to help expedite tedious tasks. Even if you don’t currently have an obvious need to write code, once you learn how, you’ll be amazed at how many opportunities you uncover to make your work more efficient.
For some examples of how easy it is to write useful Python, check out this blog post.
What should I list on my resume?
This topic is very subjective, and answers vary from country to country, but I’ll offer my advice for candidates seeking a job in the US.
To start with, there are the staples: Your name and contact information, current position (if any), education, and so forth. Don’t list your high school; it’s assumed that you have at least a diploma or GED if you’re applying for a job in IT. Include your college degree if you have one, but specify your major only if it’s relevant to the field. (Anything from computer science to business management can apply, but art history, for instance, suggests that your passion lies elsewhere.)
Include any relevant certifications (you can leave out that Red Cross CPR class) you hold, but only if they’re current. If you’re pressed for bullet points and want to list expired certifications, be sure to clearly annotate that they are no longer valid but that you would be willing to renew them as a condition of employment. (If you’re not willing, don’t list them. They’re gone.)
Work history will vary depending on where you’re coming from. If this is your first entry into the working world, list some projects you’ve worked on either in school or on your own time. If you’re crossing over from a field outside of IT, concentrate on skills and responsibilities that are transferable to the position you want. If you’re already working in a sister field, go ahead and list details about your work even if they’re not directly related to networking. A good recruiter or hiring manager will be able to form an idea of your competencies regardless.
Feel free to list out the skills in which you’re proficient, but don’t get carried away. Sometimes it’s beneficial to list out specific protocols and technologies to trigger keyword filters within application processing software, but before long your resume will begin to look like a bowl of alphabet soup. Use acronyms sparingly, and leave out what can be fairly assumed. For example, if you’ve listed experience working with server virtualization, the reader will infer that you know how IEEE 802.1Q works, so there’s no need to list it.
Though it may be tempting, don’t present topics with which you’ve only flirted as skills in which you’re proficient. If you explain that you’re not yet skilled at something but are actively trying to improve, it conveys ambition and potential. But if you inflate your abilities and your bluff gets called in an interview, you’re out for sure. (Remember, anything listed on your resume is fair game in an interview, so be sure to set the interviewer’s expectations appropriately.)
There are several items you want be sure are not included on your resume. The first few should be obvious: Don’t list your date of birth (or any other explicit indicator of age), race, religion, sexual orientation, political affiliations, intention to overthrow the federal government, or medical conditions. Don’t list contact information for your personal references, but have the list ready in a separate file to be furnished upon request. Don’t include any hobbies or interests unless they’re at least partially relevant to the field. (For example, even if you’re applying for a NOC position, it’s reasonable to note an open source software project you’re involved with.) And while it’s perfectly fine and encouraged to note raises and promotions in your work history, don’t explicitly list your compensation.
Oh, and a note about grammar and spelling: This is perhaps the single most important document to your career. Proofread. Again and again. For every typo I find on a resume, I toss the whole thing in the trash. That may sound harsh, but attention to detail is a crucial skill in this field. If composition isn’t your strong suit, get someone else to proofread for you.
One more tip: Don’t save your resume with the file name “Resume.” That’s what everyone else calls their resume, too. Save it as your full name to make it easier for a recruiter juggling hundreds of resumes to pick out.
How much do networkers make?
You didn’t just scroll through this article until you got here, did you? I hope not.
This is the burning question everyone wants to know, for beyond all those books and exams must lie a field of riches just waiting to be harvested, right? The truth is that networking is like any other field: pay and benefits vary greatly from one geographic region to another, from one industry to another, and from one company to another for any given position. It’s a harsh truth, but you’re worth what the market says you’re worth.
There used to be this perception that achieving a given network certification would guarantee a minimum salary. While that may have been true at one time (and it probably wasn’t) it certainly isn’t today. IT is a much more mature field than it used to be: It’s not hard to find someone who knows how a router or switch works. No one is deploying a wireless network for the very first time. Your compensation in this field depends on how well you apply yourself, how aggressively you pursue new opportunities, and, unfortunately, no small amount of luck and timing.
Don’t be discouraged if you hear others boast about their lush salaries. Some people just get lucky. Some people also neglect to mention that they work sixty-hour weeks. And don’t forget to factor in cost of living: A networker making $80,000 in a major city is likely worse off than one making $60,000 in the suburbs. And there may be extenuating circumstances: I was making a six-digit salary in my early twenties. The catch? I was employed a defense contractor in Iraq not too far from people who would have liked very much to kill me.
“Okay, I get it… But how much can I make, really?” Alright, fine. If you want to get a better idea of what to expect with regard to compensation, Indeed.com is a good place to start. You can search for postings by keyword and geographic area, and get a rough idea what the going rate for a position might be. But please keep in mind that these are very generalized, error-prone estimations generated from an incomplete data pool (many posted positions don’t include salary information). The US Bureau of Labor Statistics also publishes national wage data sorted by occupation, if you’re keen to dive into that pile of raw data.
The time of year during which you apply and the current economic state can skew your chances as well:
The chart above shows average salary fluctuation for postings matching “CCNP” over a two-year period. Note how widely the going rate for a CCNP varies from month to month. Unfortunately, you need a job when you need a job.
Finally, don’t forget to account for non-monetary compensation offered, like health insurance, paid vacation, and employer-paid retirement fund contributions. These may not seem like much, especially for young adults, but a 5% employer 401K match or lower than average health insurance deductible can equate to a sizable salary bump when compared against a position with lesser benefits.
How do I find a job?
The first stop for most people is uploading their resume to a major job aggregation sites like Indeed, Monster, and Dice. While these sites are certainly useful, keep in mind that your special, unique resume ends up in a sea with thousands of other special, unique resumes. Also be prepared to ignore solicitations from people offering “franchise opportunities,” “sales positions” (pyramid schemes), or the chance to make thousands a week working from home! Perhaps the worst though is the occasional deadbeat recruiter who hasn’t even bothered to read your resume, and just wants to match a body to a position and collect his or her commission as quickly as possible.
Once you’ve published your resume, start applying to individual openings. And not just through job sites: Many companies, especially smaller ones, don’t even bother posting open positions to aggregators. Search for appealing companies local to your area and check the “careers” page on their corporate site. Easily 80% of these companies you will never hear from again, not even to say “thanks but no thanks,” but try not to get discouraged. Just keep applying.
Unfortunately, the old adage is usually true: It’s not what you know, it’s who you know. The best looking resume in the pile will have a hard time competing with a phone call to a friend already employed in a position of power within the company. Especially at smaller companies, it’s common for managers to ask their staff if they know anyone who would be a good fit for an open position before it’s ever posted for application by the public. This both expedites the hiring process and guarantees that the candidate is of reasonable character. (Few people will recommend hiring someone they don’t want to work with.)
So, now it’s time for that other kind of networking. People networking. Talk to your friends and mentors, see who’s hiring. Hit up Twitter and Facebook every so often and let people know you’re still looking. LinkedIn can be worth a shot as well, so long as you don’t start spamming invitations to people you don’t even know. Whatever channels you choose, remember to make a case for why people should want to hire you, and not just because you want a paycheck. Post a link to your resume if you’re comfortable with it, but always include at least a brief synopsis of where you’re coming from and where you want to go in your career.
Do you have any interview tips?
This advice is pretty standard and available everywhere, but I’m including it here because experience suggests that some people could use a refresher.
Do your research. Learn about the company you’re interviewing with. Find out how long they’ve been in business, where their offices are located, what their core business is, and the challenges they face. Make note of any new products introduced lately that might be a topic of conversation.
Brush up on your resume. Remember that skill you listed on your resume that you haven’t used in three years? Brush up on it before the interview in case it comes up. (Remember, anything listed on your resume is fair game during a technical evaluation.)
Prepare questions. Always have a list of questions ready to ask when the time comes. It’s perfectly acceptable to write these down ahead of time. Ask specific questions about the company and the position, even if only to confirm your assumptions. Skip any topics that were already covered earlier in the interview unless there’s a reason to go into more detail.
Be on time. This is the easiest thing you can do to give a good first impression. Allow yourself plenty of time to arrive at the interview on-time. If you’re going to be late due to circumstances beyond your control (e.g. a traffic accident, zombie infestation, etc.) notify the people you’re meeting with or your recruiter as soon as possible. Arriving late to an interview without prior notice is essentially telling the interviewers that you don’t value their time.
Be confident. A lot of people struggle with this one. Technical interviews can be very intimidating, especially when meeting with a large number of people. Don’t second-guess yourself. Be confident in your answers. But also don’t brag; no one likes a cocky candidate.
Be honest. Trailing on and on in search of the correct answer to a simple question is as painful for the interviewer as it is for you. If you don’t know the answer to a question, say so. Share what you do know offhand about the topic, and describe what your next steps would be to find the answer.
Write a follow-up note. After the interview is over, send a follow-up note to the people you spoke with a day or two later to thank them for their time. Offer more detail on any answers you struggled with during the interview to show that you’re capable of research. This isn’t strictly expected but it does help you stand out as a candidate and reaffirm your interest in the position.
Learn from the experience. Even a terrible interview is experience to be applied at the next one. Make a note of any areas where you think you can improve. Work on these in preparation for the next interview.
What are the negative aspects of networking?
Networking is an awesome job, but like any other field in IT it’s not without significant challenges and frustration. The biggest of these in my experience has been the tendency of colleagues to immediately blame the network for any problem. Internet access feeling sluggish? Must be the network. Web server returning 404s? Sounds like a network problem to me. It’s raining out and you left your car windows down? Damn network guys didn’t warn you.
The tendency of others to fault the network without evidence stems from an ignorance of how the network actually functions. And to a degree, this is understandable; we all have our respective areas of expertise. To many of our colleagues, the network is just this mysterious black box everything plugs into. Packets go in at one point, magic occurs, and they pop back out someplace else.
As such, it’s easy to fault the black box when things don’t go as planned. As a networker, be prepared to “prove it’s not the network” even when there’s no evidence to suggest that it is. Typically a packet capture is enough to satisfy the demand for due diligence on your part. (Of course, it’s always necessary to follow up on even seemingly frivolous accusations, because occasionally it really is the network.)
Another annoying aspect of networking, and IT in general, is that the network doesn’t sleep. It doesn’t have weekends off and it doesn’t go on vacation, and it has absolutely no regard for your time should you choose to. Things can break at any time, and a large enough disruption ensures that your personal schedule will be interrupted very soon thereafter. (Incidentally, not wanting to get woken up at 3 AM is great motivation to carefully design networks to be extremely resilient to failure.)
Most organizations of moderate size maintain an on-call rotation to handle after-hours issues. If placed on-call, you’ll be responsible for any after-hours issues that come up during the duration of your scheduled duty (typically one or two weeks). But the trade-off is that you (probably) won’t be bothered about emergency network issues when you’re not on-call.
While we’re on the topic of after-hours work, even planned changes can be a drag. While you at least know when they’re going to happen, service-impacting maintenance often needs to be scheduled very early in the morning or very late at night, when few customers are likely to be using the service. Downtime windows are generally unavoidable in most small- to medium-sized organizations lacking sufficient redundant infrastructure, but most managers are willing to trade compensatory time off from the regular work day in exchange for after-hours work.
Finally, many people simply find the pace of the field exhausting. Technology is always evolving, and you’ll be expected to keep up. But this is also an aspect of the field to be embraced: There’s always something new to learn, something to get better at. It helps to keep your skills fresh and your mind sharp.
- What are the most popular certifications in networking?
- How much is certification X worth?
- How should I study for certification exams?
- Training Videos
- Instructor-Led Classes
- Exam Simulators
- Lab Practice
- What’s a “brain dump?”
- What is the exam experience like?
- I only just barely passed! Does it still count?
- My employer will pay for me to get a certification. Should I do it?
What are the most popular certifications in networking?
The most popular, or most common, certification track in networking is Cisco’s routing and switching series, which comprises the CCENT, CCNA, CCNP, CCIE. Most networkers obtain the CCENT or CCNA in routing and switching as their first certification, and many progress upward or outward from there. Juniper maintains its own line of certifications roughly in parallel to Cisco’s. Although there isn’t quite as much demand for Juniper certifications at the entry level, the JNCIE is reasonably sought after. There’s also CompTIA, which offers the vendor-neutral Network+ certification, although historically there hasn’t been much meat to this cert.
Of course, a number of other companies also sponsor certification programs pursuant to their own market interests: These just seem to be the most popular. There are also a number of companies and non-profit organizations which offer certifications focused on security, wireless, virtualization, and other niches that are of value to many networkers.
How much is certification X worth?
A lot of newcomers to the field get the idea that a certification will guarantee them a certain position or salary. Unfortunately, this is not the case. Remember, in essence a certification is just a good reference: The certification sponsor is vouching for your abilities to the extent they were evaluated by whatever tests you passed. It has value to a potential employer only if he trusts the integrity of the certification and he is in need of someone with that specific skill set. For example, a Cisco CCNA certification isn’t very appealing to a company whose network is comprised mostly of Juniper routers and switches.
A lot of candidates are disappointed to learn that they aren’t entitled to the same salary as a friend with the same certification. The most commonly overlooked factor in compensation is location: A professional working in New York City might easily take home twice the income of someone doing the same job in a small town, an income disparity driven by regional differences in both demand and cost of living. Also keep in mind that experience generally trumps certification, as skill demonstrated through the execution of real world projects carries much more credibility than a good grade on a test.
While it’s impossible to put an exact dollar value on a certification (regardless of what training companies would have you believe), you can roughly gauge the value of one certification to that of another by checking how frequently each is listed as a requirement on job openings. This is hardly a scientific study, but it can lend a nudge in either direction when deciding which of two certifications would be more beneficial to pursue.
How should I study for certification exams?
There are plenty of study resources out there for just about every certification, and it can be difficult to tell which approach is ideal for you. There are a few core types of training material you’ll want to consider.
Your first step in studying for a certification should be to purchase a book or two pertaining to the topics the certification covers. Just search for the certification name on Amazon and you’re likely to find several titles from various publishers. O’Reilly, Cisco Press, and Sybex (Wiley) are all very well established brands and usually a safe bet. You might also come across gems from lesser-known publishers. Always read customer reviews before purchasing a book, and make sure you’re buying the most recent edition applicable to the exam(s) you plan to take.
Books are recommended as the primary study material for a certification because they provide a thorough overview of the content on which you’ll be tested. They provide an economic method to judge your level of preparedness before spending money on more costly study tools like exam simulators and instructor-led classes. They also provide much more in-depth content for you to establish fundamental competency with the exam material.
Prerecorded training videos such as those from CBT Nuggets, INE, and iPexpert, and others offer a nice compromise between books and live classes, both in content and in price. Some people prefer videos because they tend to focus better when they hear a person talking to them and have something to watch rather than having to trudge through pages of stagnant text. Video training generally doesn’t go into as much detail as books due to time and production constraints, but it can serve as a great refresher for topics you haven’t visited in a while. Video training usually costs more than books but substantially less than live classes.
Live classes or “bootcamps” are the most costly preparation method (some even include a voucher for the certification exam), but they also have the unique advantage of a human instructor who can provide immediate answers to your questions. Most classes run for one or two weeks at a time and need to be scheduled well in advance. Some classes can cost several thousand dollars, so be sure to shop around and check out reviews from prior students before writing a check (or asking your boss to).
One downside to instructor-led classes is that they don’t always operate on your schedule. Some training providers will claim that they run classes regularly, but abruptly reschedule you if they don’t have enough students to justify the cost of hosting the class for a given week. Be sure to get a commitment in writing to the dates you’ve chosen if your schedule isn’t flexible.
If you have no prior experience with the topics to be covered, never start with a live class: You only have a fixed number of hours during which you can take advantage of the instructor, and these are far better spent solidifying existing knowledge and filling in gaps than learning fundamentals. At a minimum, read a book or two on the topics to be covered before scheduling a class so you can hit the ground running on the first day.
Exam simulators are applications which try to replicate the experience of taking an actual certification exam. They contain questions and exercises similar to what you’ll see on the real test, but also provide answers and explanations that help reinforce study. Most offer a timed exam mode, wherein you’ll need to answer a set number of questions correctly to pass. You’ll also have the option to concentrate on specific topics to improve areas of weakness. Some basic simulators come packaged with study books; others are available as standalone products. The standalone simulators can cost several hundred dollars (US), so you’ll need to decide whether they’re worth it.
The most reliable way to evaluate your skills is to try them out on real network gear. Several training companies rent out hosted labs by the hour, or you may decide to build your own (we’ll cover building a home lab in a later article). Lab practice is highly recommended, but only after you’re reasonably familiar with the theory and configuration concerning the features and protocols you want to implement. This is especially important if you decide to rent lab time: You’ll want to avoid wasting time flipping through books while your lab session is in progress.
What’s a “brain dump?”
Some unscrupulous companies have taken to selling pirated copies of actual certification exam questions. They pay individuals to take an exam and write down all the questions they can remember immediately afterward, hence the term brain dump. More advanced schemes go so far as to employ video recording devices to capture the entire exam. The stolen material is reformatted and altered in a half-hearted attempt to obscure its origin, and marketed to prospective test takers as legitimate study material. Brain dumps are widely held responsible for the declining value of IT certifications because they allow individuals to pass exams with little or no comprehension of the material.
You can spot brain dump companies by watching for advertising focused on exam pass rates and low preparation times. They also like to boast about the number of “questions and answers” in their pools, rather than their depth or breadth of coverage. Providers of legitimate training materials will emphasize comprehension of the material and disciplined practice. As with any purchase, research your options and look for reviews from prior customers on neutral forums (not testimonials listed on the vendor’s own web site). Give the company a call and ensure that you can talk to someone knowledgeable about the certification you want to pursue.
For more background on brain dumps, check out this explanation by CertGuard.
What is the exam experience like?
First, are you confident that you’ve mastered all the material on which you’ll be tested? You shouldn’t feel like you’re rushing into the exam. Before scheduling the exam, you should be comfortable answering review questions even before checking the answer choices. If you’ve been using an exam simulator to study, you should be scoring at least 90% consistently (remember that the questions on the exam will differ from those which have become familiar by now). And don’t make the mistake so many people do of ignoring that one nagging topic you just can’t get a handle on: It will show up on the test. Repeatedly.
The majority of certification exams are proctored and can only be taken at a qualified testing center. Once you’re sure you’re ready for the exam, you’ll need to locate a testing center where the exam is administered and schedule a date and time to take it. Determine which testing provider offers the exam you want to take, and use its web site to find a testing center near you. For example, if you’re testing for the CCNA, you’ll need to find a Pearson VUE testing center which offers the appropriate exam. Most locations are not dedicated testing centers, but rather independent businesses which contract as exam proctors on the side. These are usually private IT training companies, community colleges, or consulting firms. Occasionally, the organization’s primary business might be entirely unrelated to IT certifications (a friend of mine once certified at a tax preparation office). Just be sure that the center is properly accredited by the testing provider before scheduling an appointment.
When selecting an exam time, be sure to allow yourself plenty of travel time, especially if it’s far away. If traveling during morning or evening rush hour, be sure to pad your anticipated commute time appropriately. Plan to arrive at least 15 minutes before your scheduled time, or longer if you’re unfamiliar with the area. If you arrive late, you may be refused admission and forced to forfeit the exam cost. (Most testing providers require you to reschedule or cancel your exam no less than 24 hours prior.) You’ll be asked to pay for the full cost of the exam online when you make your appointment.
When the day comes, be sure to grab something to eat before testing, especially if testing in the early morning or right after work. Avoid fast food or anything you don’t normally eat. It’s advisable to skip coffee and energy drinks as the caffeine will only amplify any feelings of anxiety. Remember to take with you a valid government-issued photo ID such as a driver’s license. You might also be asked to furnish a second piece of ID (credit or debit card, library card, college ID, concealed carry permit, passport, etc.) for extra verification.
Once you arrive at the testing center, you’ll be asked to present your ID and sign in. You may have to sign a confidentiality agreement affirming that you won’t share test material. You might also be asked to have your photograph, signature, and even fingerprints taken. (Some certification sponsors have mandated these extra security measures in recent years to combat the growing problem of exam fraud.) You will likely be asked to secure your personal effects (cell phone, wallet, keys, etc.) in a locker while you take the exam. This is to prevent people from accessing hidden notes or recording the exam material.
Stop and reassess your physical condition at this point. Grab a cup of water or hit the restroom now if you think you might need it: Once the exam begins, you won’t be permitted to leave the testing room. The proctor will brief you on the exam, ask if you have any questions, and then you’re on your own!
Exam experiences obviously vary from one test to another, but generally speaking they’re pretty boring. Just take your time to read and digest each question completely. On multiple-choice questions, see if you know the answer without looking at the provided options first. Don’t second-guess yourself and don’t read too much into the question; your gut is usually right. Don’t waste time on questions you don’t know: cut your losses, or (if the exam allows) go back and answer it later. If you experience any technical issues with the exam (the interface freezes, or a diagram gets cut off by the edge of the screen, for example) inform the proctor immediately.
Most exams will reveal your score and pass or fail status within a few seconds after completing the test. Try not to vomit during this interval. Hopefully you’ll be greeted with a happy “PASS” message! But if not, try not to get bummed out; you’ll live to fight another day. Either way, the results at this point are final, and you’re free to go. The proctor should assist in recovering your personal effects and provide a printout of your score before you leave.
A few certifications, such as Cisco’s CCIE, impose considerably more daunting practical lab exams. There have been plenty of stories published by people who have attended a CCIE lab. Here’s a great account by Bob McCouch.
I only just barely passed! Does it still count?
What do you call the guy who graduates bottom of his class in medical school? Doctor.
A lot of test candidates who just barely achieve the minimum passing score by one or two questions feel like they didn’t really earn the certification. Remember that certification exams are boolean in nature: You either passed or you didn’t. And if your score is equal to or greater than the minimum score, you passed. If the exam sponsor wanted the score to be three points higher, it’d be three points higher. Forget about the score and celebrate your accomplishment!
My employer will pay for me to get a certification. Should I do it?
Be careful with this. Many people see this as an opportunity for a free certification, but be sure to weigh the risks against its potential benefits. Many employers require you to front the cost of the exam and reimburse you afterward, but only if you pass. You might fail the exam and get stuck with the bill. This is an acceptable risk if you wanted to pursue the certification anyway, but not if you’re doing so only at the request of your employer.
Also check whether your employer is expecting a written commitment from you in return for sponsoring your study. This isn’t usually a concern for entry-level exams, but studying and testing for some higher-level certifications can cost thousands of dollars, and your employer may rightfully want to ensure you don’t jump ship right after they finish paying for your certification. If you’re not comfortable with this commitment, ask to negotiate a repayment arrangement should you decide to leave the company in the near future.
- Where do IP addresses and domain names come from?
- Did we really run out of IPv4 addresses?
- Can I buy more IP addresses?
- Does IPv6 really provide a bazillion addresses?
- Why does IPv6 use hexadecimal addressing?
- What is IPAM?
- How do I create an IP addressing scheme?
- How does IPv6 subnetting work?
- What prefix length should I use on point-to-point links?
- How should I name devices on my network?
Where do IP addresses and domain names come from?
Ultimate authority over names and addresses on the Internet comes from the Internet Corporation for Assigned Names and Numbers (ICANN), which was originally founded as a not-for-profit corporation created in 1998 as a result of the United States government’s initiative to privatize control of the Internet. According to its bylaws, ICANN has three core responsibilities:
- Coordinate the allocation and assignment of the three sets of unique identifiers for the Internet, which are:
(a) Domain names (forming a system referred to as “DNS”);
(b) Internet protocol (IP) addresses and autonomous system (AS) numbers; and
(c) Protocol port and parameter numbers.
- Coordinate the operation and evolution of the DNS root name server system.
- Coordinate policy development reasonably and appropriately related to these technical functions.
ICANN delegates control over most of the global DNS hierarchy to a number of independent registries which manage the hundreds of top-level domains (TLDs). For example, VeriSign currently maintains the .com and .net TLDs, while .org is maintained by the Public Internet Registry (PIR). (A complete listing of current TLDs and their registries is available here). Each registry is responsible for maintaining the database of domain names belonging to its TLD(s). Note that some TLDs, such as .gov and .edu, impose certain restrictions on organizations which can register domain names.
However, most registries don’t register new domain names to end users directly. This process is delegated to ICANN-accredited registrars. Registrars act as middlemen between an individual or company registering a domain name for use and the registry responsible for the TLD to which the domain name belongs. In exchange for a small fee (usually around ten to thirty US dollars per year depending on the TLD), registrars inform the registry of the creation or modification of the domain name and maintain the relevant contact information for it.
There are literally thousands of commercial registrars which offer domain registration services around the world. Many web hosting providers offer domain registration as part of their hosting services. Some registries, like VeriSign, also function as registrars, but not all. While independent registries are contracted for maintenance of most TLDs, maintenance of the critical root DNS zone is left to a subordinate body of ICANN, the Internet Assigned Numbers Authority (IANA).
In addition to running the DNS root zone, IANA is responsible for delegating the assignment of IPv4 and IPv6 addresses from the global pool via Regional Internet Registries (RIRs), not to be confused with DNS TLD registries. There are five RIRs at the time of this writing, each servicing one or more geographic regions:
An Internet Service Provider (ISP) or end user obtains IP address allocations from its appropriate RIR, or from an intermediate national or local Internet registry. RIRs are also responsible for the assignment of autonomous system (AS) numbers, which are used to uniquely identify an organization on the Internet.
IANA also manages protocol number assignments. By far the most familiar of these are TCP and UDP port numbers. For example, TCP port 80 is assigned for HTTP, whereas UDP port 53 is assigned for DNS. IANA also administers assignments including IP protocols, Internet Control Message Protocol (ICMP) type codes, Simple Network Management Protocol (SNMP) number spaces, and much more.
Did we really run out of IPv4 addresses?
Yes, but we only had a couple decades of warning. On February 3, 2011, ICANN allocated the last five remaining /8 spaces, one to each of the five RIRs. Since then, it has become increasingly difficult to secure new IPv4 space. Many organizations have begun implementing IPv6, but its adoption rate has not been as quickly as has been hoped. And it will be a long time before we actually start moving not just toward IPv6 but away from IPv4.
Can I buy more IP addresses?
In short, yes. I haven’t had much experience with the process personally, but Lindsay Hill has published an excellent account.
Does IPv6 really provide a bazillion addresses?
An IPv6 address is 128 bits long, which in theory yields 2128 unique addresses. People love to make outlandish and pointless analogies using this number (“That’s enough to address every grain of sand on Earth!”) but in practice we’ll end up wasting far more addresses than we use.
For starters, most network segments will be assigned a 64-bit prefix regardless of how many end hosts they contain, to ensure compatibility with SLAAC and to simplify addressing schemes. So even on large multi-access segments we’ll only ever use a few thousand out of 264 possible addresses. The good news is that such waste is nothing to fret about; it’s actually part of how IPv6 is intended to work.
Additionally, the largest allow allocation for most organizations is a /32. If all of your segments are addressed as /64s, that only leaves 32 bits of space in which you have say over how networks are allocated. But hang on: 32 bits is equivalent numerically to the scope of the entire IPv4 world, just for your network! And on top of that, host addresses are essentially free because you’ll never exhaust the space of a /64.
So no, we can’t give every grain of sand on the planet an IPv6 address, as badly as we might want to. But the effectively infinite segment size coupled with the exponentially increased prefix space ensures that you should never find yourself backed into a corner when drafting an addressing scheme.
Why does IPv6 use hexadecimal addressing?
Odds are that you first learned about IPv4 and subnetting, and then moved onto IPv6 and its crazy-long addresses with letters in them. IPv4 addresses are expressed in decimal as 8-bit chunks separated by periods, called as dotted-decimal notation, whereas IPv6 addresses are expressed in hexadecimal as 16-bit chunks separated by colons. Hexadecimal was chosen for IPv6 because it allows for more compact addressing: Every byte is expressed with only two digits. This is in contrast to decimal, which can use up to three digits to express the value of a byte.
Consider the IPv6 address 2001:db8:4000:2d04:0002:55ff:fe47:b3c9. We could express this value in dotted-decimal format as 126.96.36.199.188.8.131.52.0.2.85.255.254.71.179.201, but that takes a lot longer to write or say. We could also express the IPv4 address 192.0.2.75 as c000:024b if we wanted to, but no one would recognize it as an IPv4 address.
Ultimately, both types of address are just binary strings (32 bits for IPv4 and 128 bits for IPv6). They only look different because we choose to write them differently.
What is IPAM?
IP address management (IPAM) entails tracking the allocation and utilization of IP address space on a network. This can be as simple as using a spreadsheet to record the static assignments of individual IPs within a subnet, or as complex as deploying a dedicated IPAM application to manage assignments across a global network. Many IPAM products integrate with DNS and DHCP services to keep these systems synchronized automatically. Most organizations start tracking IP allocations in a spreadsheet and move to a dedicated application as the network grows. There are many open source and commercial IPAM products available to choose from.
How do I create an IP addressing scheme?
Early in your career, you’ll likely be working on networks with established infrastructure and addressing schemes. These might be decent, or they might be terrible, but they’re there. You should always try in earnest to abide by existing schemes and policies where prudent, even if they’re not ideal.
For example, suppose convention has been to allocate a /16 prefix out of the 10.0.0.0/8 RFC 1918 space for every new site on your network, regardless of its size. This approach could be made more efficient by varying the size of new allocations as appropriate to the size of each site, but deviating from the policy now might compromise strategies that were enacted back when the existing scheme was drafted. It might be best to continue with the current obtuse allocation policy until a sufficient effort can be put forth to overhaul addressing across the entire network.
That said, sometimes it’s necessary to develop a new IP addressing design from scratch, whether for a greenfield deployment or to migrate away from a legacy scheme. While it would be impractical to discuss here all of the caveats you might encounter when laying out an address plan, there are a few solid guidelines that should keep you from shooting yourself in the foot.
- Efficient aggregation is key. The ability to efficiently summarize routes is crucial to a healthy, stable network. Allocate networks so that they can be summarized intuitively by function or geographic area. For example, if assigning a campus network out of 172.16.0.0/16, you might assign each building a /20, and number each floor with a /24 within that /20 sequentially. While perhaps not as efficient, this is preferable to numbering all floors sequentially, as that approach weakens your ability to summarize by building.
- Allow for future growth. Your addressing scheme should never be fully allocated at inception; you’ll always want to leave room for growth, whether that means additional buildings or larger segments or whatever. One good strategy is to, for each prefix you allocate, reserve the subsequent prefix for future use. This allows you to simply double the size of any prefix if it needs to expand in the future. So if you allocate 192.168.118.0/24 to a segment, go ahead and reserve 192.168.119.0/24 for future use.
- Never assign networks by “natural” boundaries. It’s a rookie mistake to address networks using natural decimal increments, which are not binary-friendly. For example, numbering networks as 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, etc. The same goes for numbering by VLAN ID. These networks don’t aggregate at all.
- Don’t forget infrastructure! One common pitfall is to painstakingly plan out every access segment, only to realize you’ve completely overlooked the network infrastructure itself. Be sure to set aside address space for point-to-point links, loopbacks, management, and other internal functions. Many people opt to address infrastructure out of a separate parent prefix, especially when using private addressing.
- Plan for IPv4 and IPv6 in parallel. Every segment in your network should have both IPv4 and IPv6 allocations, even if you’re not using IPv6 yet. Planning for IPv6 now will avoid duplicating effort in the future.
How does IPv6 subnetting work?
Technically speaking, there is no such thing as IPv6 subnetting. When IPv4 was first developed, network size was determined by address class. We very quickly realized that this would not scale well, so the subnet mask was introduced just a few years later in 1985 (seeRFC 950) and we’ve been using subnets ever since. However, IPv6 never included the concept of classful networks, so by extension there’s no such thing as an IPv6 subnet. Instead, we refer to IPv6 networks as prefixes (a term which is also appropriate for IPv4 networks).
That said, “subnetting,” or the manipulation of prefix length, works with the exact same logic in IPv6 as it does in IPv4. Extending the prefix length by one bit doubles its size; removing one bit halves it. Although doing the math by hand requires converting addresses to binary (just as with IPv4), networkers are strongly encouraged to allocate addresses along nibble (four-bit) boundaries where feasible. For example, RIRs like ARIN and RIPE only allocate address space as /32, /36, /40, and so on. This allows for easy evaluation of prefix masks, as the mask will not split any hexadecimal characters.
What prefix length should I use on point-to-point links?
Historically, point-to-point links we numbered with IPv4 using /30 prefix lengths. This was because the first and last IP address (as in any subnet) were deemed unusable as endpoint addresses. However, this was an extremely inefficient approach, as only 50% of addresses could be used: Each link consumed twice the IP space needed.
Fortunately, virtually all modern routers support the use of /31 prefixes for point-to-point links, which was first standardized in RFC 3021 back in 2000. This allows us to achieve 100% addressing efficiency, as each link requires and consumes only two IPv4 addresses. For example, the two end points of a link numbered with 192.168.0.0/31 would be 192.168.0.0 and 192.168.0.1. The 192.168.0.0 address might seem unnatural, but rest assured it’s entirely valid with a /31 mask. So is 192.168.0.255/31.
Point-to-point links should be addressed with IPv6 in a similar manner, utilizing a /127 prefix. This was one time considered poor practice, however is now recommended per RFC 6164. Some network operators opt to configure links with a /127 prefix but to only allocate the first /127 out of a /64 for each link, rather than allocating sequential /127s. This keeps the link addressing very clean, since only the first two IPs will ever be used; for example, 2001:db8:ab:cd::/127 and 2001:db8:ab:cd::1/127. This might seem wasteful, however it’s perfectly acceptable and even encouraged to allocate a single /64 per segment regardless of its size.
How should I name devices on my network?
Your approach to network naming will depend largely on personal taste and how much freedom you’re allowed. Sometimes you will be required by policy to adopt the naming scheme of a parent entity or partner company. In other cases, the sheer breadth of your network might necessitate a naming scheme more complex than you’d prefer. While you can’t always control how your network devices are named, here are some tips for creating an organized hierarchy should you be afforded the opportunity.
- Make liberal use of subdomains. If you have a number of small, geographically disparate sites, create a zone for each of them so that the hostnames for similar devices match across sites. For example, mail01.abc-east.example.com and mail01.abc-west.example.com. This prevents individual hostnames from becoming too unwieldy. But while it might make sense to go as far as creating one subdomain per building on a large campus, I’d probably stop short of creating one per floor. You’ll have to decide what degree of granularity is appropriate for your network.
- Names should imply function. Some people like to serialize device names and use an external database to correlate function and location, but that’s a huge pain in the ass if you have to look things up manually. Use names like “web” for HTTP servers, “db” for databases, “dns” for DNS, and so on. Use a generic label like “app” for servers which host multiple applications.
- Never name devices by brand. One rookie mistake is to confuse a device model with its function. For example, don’t name your Cisco ASA firewalls asa1 and asa2. This would requires the devices’ names to be changed if replaced with a different model of firewall (an option you always want to leave open).
- Naming schemes should be predictable. If you know there are four access switches at an office, they should be named something like switch01, switch02, switch03, and switch04, not Homer, Marge, Bart, and Lisa. While I appreciate the Simpsons reference, these names imply nothing about when the switches were installed or the position of each in the network hierarchy. (And what happens if you have to add three more switches? Which characters would you pick next?)
- Add zero padding where appropriate. You might have noticed that I zero-padded the switch names above to two digits even though there are only four switches. Padding offers a high degree of confidence that you’ll be able as many switch as you’ll ever need (up to 99) and still have names sorted properly. Consider what happens if you have eleven switches and don’t pad their numbers: Alphabetically, they would be sorted as switch1, switch10, switch11, switch2, switch3… Zero-padding keeps things tidy.
- Use standardized abbreviations for geographic locations. Many organizations opt to use the three-character International Air Transport Association (IATA) codeassigned to the nearest airport of a site. For example, a site in Ashburn, Virginia, would be designated IAD (the IATA designator for Dulles International Airport). If you have multiple sites in the same region, consider adding a numeric index to the code (IAD1, IAD2, IAD3…). Or if you need further granularity, consider adopting the UN’s LOCODE system, which appends a unique three-character location code to a country’s two-character code. Under LOCODE, the Ashburn site would be designated US-QAS. (The codes aren’t always pretty, but they work.)
- At what OSI layer does protocol X operate?
- What’s the difference between a router and a multilayer switch?
- What’s the difference between forwarding and control planes?
- What’s the difference between MTU and MSS?
- What’s the difference between a VLAN interface and a BVI?
- How do tunnel interfaces work?
- What do NAT terms like “inside local” mean?
- Can I use the network and broadcast addresses in a NAT pool?
- Why do we need IP addresses? Can’t we just use MAC addresses for everything?
- Does QoS provide more bandwidth?
At what OSI layer does protocol X operate?
The Open Systems Interconnection (OSI) model is one of the first things you learn about networking. It’s a seven-layer reference model officially defined in ISO/IEC 7498-1 and reprinted in every certification study book ever published. It serves as a common point of reference when discussing how protocols relate to and inter-operate with one another. For example, we know that TCP is a layer four protocol, and therefore it sits “on top of” IP, which is a layer three protocol.
But what does that really mean? Who decides what layer a protocol belongs to? The OSI model was originally conceived back in the 1970s as a component of the OSI protocol suite, which was positioned as an early competitor to the emerging TCP/IP family of protocols (spoiler alert: TCP/IP won.) Except for a handful of survivors (most notably the IS-IS dynamic routing protocol) OSI protocols are not in common use today. The reference model which was to govern how these protocols operated, however, lives on. So, we end up trying to assign protocols from one family to layers originally defined for another.
For the most part, this works out alright. TCP and UDP ride on top of IP, which rides on top of Ethernet or PPP or whatever. But protocols don’t always fit the mold: MPLS, for example, is sometimes referred to as “layer 2.5” since it neither provides framing nor provides end-to-end addressability. (Unlike IP addresses, MPLS labels are swapped at each hop along a path as a packet transits a network.) Of course, inventing a layer between two other layers defeats the purpose of a standardized reference model in the first place, and just belies how dependent some people are on reducing every logical concept to a number.
Technically speaking, no protocol from the TCP/IP stack has an official assignment to an OSI layer, because they’re not of the same family. Apples and oranges. A reference model is just that: a reference. It helps illustrate the dependencies protocols have on another, and where they sit in relation to one another, but it doesn’t strictly govern their function. To give the concept any more weight than that is to miss its purpose entirely.
But if anyone asks, MPLS is a layer three protocol.
What’s the difference between a router and a multilayer switch?
Back in simpler times, a router was a device that forwarded packets based on their IP addresses and offered a variety of interface types: Ethernet, T1, serial, OC-3, and others. Conversely, a switch was a device which forwarded packets (or frames, if you prefer) based on their MAC addresses and included only Ethernet ports.
Since the early 2000s the industry has seen two major trends which have greatly upset this understanding. First, the introduction of the multilayer switch meant it was possible for a switch not only to forward packets based on IP addresses, but to participate in dynamic routing protocols just like a router. Second, carriers began migrating away from legacy long-haul circuit technologies in favor of Ethernet for its speed and lower cost. In fact it’s fairly common for routers today to consist entirely of Ethernet interfaces, just like their switch counterparts.
So where do we draw the line? Is there even a line anymore? The practical distinction between router and switch boils down to a few key functions:
- Port density. Enterprise-level switches typically come in 24- and 48-port variants, either as standalone devices or as modular chassis. Some are designed as separate physical chassis which can be stacked via a flexible external backplane connection. The goal is to fit as many physical interfaces in as dense a space as possible. A router, by contrast, might have have far fewer individual interfaces split across several field-replaceable modules.
- Speed. Switches are built primarily for speed, which is a function of the hardware chipset sitting behind the ports. It is common for even modest access switches today to support non-blocking line-rate connectivity.
- Intelligence. This is the key reason you might need a router instead of a switch. A router serves as a point of intelligent policy enforcement. This includes functions like network address translation, deep packet inspection (looking beyond the outer protocol headers), stateful firewalling, encryption, and similar more involved operations not supported on a multilayer switch.
That’s the current theory regarding purpose-built hardware, anyway. With the current push toward virtual appliances, commodity hardware is being re-purposed for a variety of roles.
What’s the difference between forwarding and control planes?
This is a source of much confusion for people new to networking. Simply put, the forwarding plane handles moving a packet from point A to point B. The control plane handles functions which determine how the forwarding plane operates.
Let’s say you’ve got a router running OSPF. It exchanges routes with neighboring OSPF routers and builds a table of all the routes on the network. Once the routing table has been built, the router installs the best route for each known destination into its forwarding table. This is a control plane function.
When the router receives an IP packet on an interface, it looks up the destination address of that packet in its forwarding table to determine out which interface the packet should be sent. The packet is then moved in memory to the output buffer of that interface and transmitted onto the wire. This is a forwarding plane function.
See the difference? The forwarding plane handles the reception and transmission of packets, whereas the control plane governs how forwarding decisions are made. Forwarding plane operations are typically done “in hardware,” which is to say they are performed by specialized chipsets requiring little interaction with the device’s general-purpose CPU. Control plane functions, on the other hand, are handled in software by CPU and memory very similar to what’s in your personal computer. This is because control protocols perform very complex functions which don’t usually need to occur in real-time. For example, it’s usually not a big deal if there’s a delay of several milliseconds before installing a new route in the forwarding table. Such a delay could be devastating for the performance of the forwarding plane, however.
What’s the difference between MTU and MSS?
The maximum transmission unit (MTU) of a network protocol dictates the maximum amount of data that can be carried by a single packet. Usually when we talk about MTU we’re referring to Ethernet (although other protocols have their own MTUs). The default Ethernet MTU for most platforms is 1500 bytes. This means that a host can transmit a frame carrying up to 1500 bytes of payload data, which does not include the 14-byte Ethernet header (or 18 bytes if tagged with IEEE 802.1Q) or 4-byte trailer, resulting in a total frame size of 1518 bytes (or 1522 bytes with IEEE 802.1Q). Many network devices support jumbo frames by way of increasing the default MTU as high as 9216 bytes, but this is administratively configurable.
Maximum segment size (MSS) is a measure specific to TCP. It indicates the maximum TCP payload of a packet; essentially it is the MTU for TCP. The TCP MSS is calculated by an operating system based on the Ethernet MTU (or other lower layer protocol MTU) of an interface. Because TCP segments must fit within Ethernet frames, the MSS should always be less than the frame MTU. Ideally, the MSS should be as large as possible after accounting for the IP and TCP headers.
Assuming an Ethernet MTU of 1500 bytes, we can subtract the IPv4 header (20 bytes) and TCP header (another 20 bytes) to arrive at an MSS of 1460 bytes. IPv6, with its longer 40-byte header, would allow an MSS of up to 1440 bytes.
TCP MSS is negotiated once at the initiation of a session. Each host includes its MSS value as a TCP option with its first packet (the one with the SYN flag set), and both hosts select the lower of the two MSS values as the session MSS. Once selected, the MSS does not change for the life of the session.
What’s the difference between a VLAN interface and a BVI?
A VLAN interface, also referred to as a switch virtual interface (SVI) or routed VLAN interface (RVI) is a virtual interface created on a multilayer switch to serve as the routed interface for a VLAN, often to provide a default gateway out of the local subnet. VLAN interfaces typically operate and are configured the same as physical routed interfaces: They can be assigned IP addresses, participate in VRRP, have ACLs applied, and so on. You can think of it as a physical interface inside the switch that’s assigned to a VLAN just like one of the physical ports on the outside of the switch.
A bridge group virtual interface (BVI) serves a similar function, but exists on a router where there is no concept of a VLAN (because all its ports normally function at layer three) instead of a switch. A bridge group is a set of two or more physical interfaces operating at layer two, with all member interfaces sharing a common broadcast domain. The BVI is tied to a bridge group to serve as a single virtual layer three interface for all segments connected to the bridge group. When a router has interfaces operating at both layers two and three it is referred to as integrated routing and bridging (IRB).
While VLAN interfaces are a necessity of multilayer switching, IRB is typically used only in niche designs which call for a layer two domain to span multiple router interfaces, such ason a wireless access point.
How do tunnel interfaces work?
A lot of people struggle to understand the concept behind tunnel interfaces. Remember that a tunnel is just the effect of encapsulating one packet inside another as it passes between two points. Tunnel interfaces are used to achieve this encapsulation for route-based VPNs, which can provide a layer of security or abstraction from the underlying network topology. There are a number of encapsulation methods available, including IPsec, GRE, or just plain IP-in-IP.
Although tunnel interfaces are virtual in nature, they behave just like any other interface when it comes to routing decisions. When a packet is routed “out” a tunnel interface, it is encapsulated and a second routing decision is made based on the new (outer) header. This new packet is then forwarded across the wire to another device. Eventually, the packet reaches the far tunnel endpoint, where its outer header is stripped away. A routing decision is made on the original inner packet, which can be forwarded on to its destination in its original form.
For more detail on the whole process, check out Visualizing Tunnels.
What do NAT terms like “inside local” mean?
An IP address within the context of NAT can be considered one of these four classes:
- Inside global
- Inside local
- Outside local
- Outside global
Unfortunately, these terms are rarely explained in documentation to the satisfaction of the reader. Each term describes two separate attributes of the address: location andperspective. Location is described by the first word in the tuple, either inside or outside. It refers to the “side” of the NAT boundary router in which the address logically exists. In a typical NAT deployment, inside addresses will usually (but not necessarily) be private RFC 1918 addresses, and outside addresses will usually be globally routable (public) IP addresses.
Perspective refers to the side of the NAT boundary from which the address is observed: local or global. If an address is seen by an inside host, it is being observed locally. If an address is seen by an outside host, it is observed globally.
If the terms are still foggy, check out this article on NAT types for a simple example.
Can I use the network and broadcast addresses in a NAT pool?
Yes! Many people assume that because the network and broadcast addresses of a subnet are unusable for host addressing, they cannot be used in a NAT pool. However, a NAT pool has no concept of a subnet mask: This is why you can define NAT pools using arbitrary ranges that don’t conform to binary boundaries (for example, 192.168.0.10 through 192.168.0.20). This includes the IPs which would be designated as the network or broadcast address of a “real” subnet.
Why do we need IP addresses? Can’t we just use MAC addresses for everything?
When you first learned that MAC addresses were intended to be globally unique, you might have wondered why we don’t just use them for addressing traffic end-to-end and skip IP altogether. There are a few very good reasons the Internet evolved to use IP addresses. The first is that not all networks have MAC addresses: The MAC address is unique to the IEEE 802 family of networks. This can be easy to forget on modern networks where nearly everything is Ethernet or some variation on it (like IEEE 802.11 wireless), but this was a much more prominent concern several decades ago when networks were a mishmash of Token Ring, Ethernet, Frame Relay, ATM, and other protocols long since abandoned.
Another reason for IP addresses is that they’re portable. A MAC address is burned into a network adapter and stuck there for life, whereas IP addresses can be changed by an administrator arbitrarily or even assigned dynamically. (Yes, it’s usually possible to reconfigure a NIC to use a MAC different from its burned-in address, but this was not intended use upon Ethernet’s inception.)
However, the most important justification behind IP addresses is that they are aggregatable. That is, a collection of endpoints sharing a common segment can be summarized into a single route. This is not usually possible with MAC addresses, which are assigned pseudo-randomly. Using MAC addresses for end-to-end communication would require every router on the Internet to know the address of every single host on the Internet. This approach obviously would not scale well.
Does QoS provide more bandwidth?
A common misunderstanding concerning Quality of Service (QoS) controls is that they somehow allow you to squeeze more packets through a link. This is not the case. If you have, for instance, an Internet circuit rate-limited to 10 Mbps, you’re never going to be able to send more than 10 Mbps (and probably not quite that much) at a time. The function of QoS is to prefer some classes of traffic over others so that during periods of congestion (when you’re attempting to send more than 10 Mbps across that link), less-important traffic is dropped in favor of passing traffic with higher preference.
QoS controls are usually employed to protect real-time traffic like voice and video conferencing from traffic which is much more tolerant to loss and delay like web, email, and file transfers. They might also be used to prevent large data transfers like server backups from consuming all the throughput available on a network.
Consider a scenario where you have a branch office connected via bonded T1 circuits with an aggregate throughput of 3 Mbps. This link carries both voice and data traffic. If the link becomes congested and both types of traffic suffer, you can implement QoS controls to guarantee a certain portion of the available throughput to voice traffic. Data traffic will be permitted only the portion of throughput not consumed by voice traffic. However, if data traffic is slowed to the point where users complain, QoS can’t help any more. You’ll need to upgrade the circuit (or add a new one) to provide additional throughput.