The Resume

Any job search begins with a resume. The main goal at this stage is to use it to give your future manager complete information about yourself—as fully as possible, yet clearly and concisely.

The most important thing at this stage is not to fall into the trap of writing “What I WAS DOING.” Instead, write “What I ACCOMPLISHED.”

Bad Example:

• Configuring Cisco switches

• Configuring routers

• Configuring firewalls

Good Example:

• Responsible for supporting the local office network built on Cisco switches. Managed the support of existing infrastructure, installation of new equipment, and replacement of failed devices.

• Configured Cisco routers, ensuring stable VPN connections between remote offices and the central office.

• Responsible for providing network access based on tickets by adding rules to the company firewall.

• Participated in a migration project moving from one vendor’s equipment to more modern models from another manufacturer. Responsible for the transfer and subsequent adjustment of configurations.

After reading your resume, your potential future boss should understand what you did previously and what experience you possess.

You don’t need to write a lot. You don’t need to write a little. Write about yourself and your skills briefly but substantially.

“Tell Me About Yourself”

So, your resume was noticed, and you were invited for an interview.

After a short greeting, you will be asked to talk about your past experience at other companies. Be ready to fit your story about yourself and what you did at your last job into 2–3 minutes. There is no point in going too deep into details—they will ask you about all the interesting specifics later. Explain what position you held, what your duties included, and your main achievements.

If you have absolutely no experience and have just graduated from a university or a bootcamp, talk about what you studied. A description of the course curriculum or a summary of your thesis project will work fine.

“Do You Know This Technology?”

Immediately after (or even during) your “about me” monologue, they will ask you for details regarding your activities, and then smoothly transition to theoretical questions. You will be asked about well-known technologies, configurations, and methods. For example:

• What is the BGP protocol? Why is it needed?

• What is a routing table? What parameters are specified for routes?

• What is Spanning Tree? Why is it needed?

• How does a router differ from a firewall?

• What is needed to build an IPsec VPN tunnel?

Answer with everything you know. If you forget specific timers, terms, or something similar, explain it in your own words—this also demonstrates your general understanding and is valuable.

“What If They Ask About a Topic I Don’t Know?”

Don’t worry! They definitely will! There is a simple and correct answer to this, which sounds something like this: “No, I don’t know this topic. I haven’t had to work with it before. But I would find it VERY interesting to learn. I’ve wanted to for a long time!”

Remember that we gain 80% of our knowledge not while studying in courses, but while working and dealing with tasks on a daily basis.

“Why Are You Looking for a Job?”

After the technical part, they will ask about your attitude toward your previous job and your career goals.

A bad answer to such questions is to tell them what villains surrounded you at your last place (especially the boss) and how hard it was to work with them.

A good answer sounds something like this: “I already did a lot of good and useful work at my last place. I reached a ceiling in my development. I want to grow and develop, but I can’t do that there, so I am looking at companies where I can be useful and am considering offers.”

“What Are Your Salary Expectations?”

The traditional game at every interview! The rules are simple: whoever says a number first loses.

Example answer: “I would, of course, like ‘the more the better.’ But I understand that you have a fixed budget for this position. If I am a good fit for this vacancy, I am ready to consider your offers.”

It is undoubtedly appropriate to name a desired sum yourself if you have a good idea of what such a specialist costs in the labor market, but under no circumstances should you lower your expectations! Remember that the interview is the exact moment when you negotiate your salary! Increasing it while employed is exponentially harder than negotiating it when moving to a new job!

“Your Turn to Ask. What Do You Want to Know?”

Bad answer: “Nothing. I have no questions.”

Good questions that should interest you:

• What are the main tasks for this position for the next six months?

• Can you tell me about the team? Who is on it and whom will I interact with?

• What is the work format: remote, hybrid, or full-time in the office?

• Are there frequent emergencies, or is there a need to stay late for work issues?

• Is corporate equipment provided for work: laptop, phone?

Do not neglect these and other questions. Ask at least a couple of them “out of politeness.” In any case, this gives you more understanding of the place, because right now, not only are they choosing you, but you are choosing them.

After the Interview

Any interview is stressful, even for very experienced specialists. After it, you need to rest, and the next day, with fresh energy, analyze the entire dialogue and identify your strengths and weaknesses.

If you were asked about a technology or function you didn’t know, read about it on the internet for your general development. A short article on Wikipedia or a similar resource is enough to understand the principles. At the next interview, you will already know what to answer!

What’s Next?

Speaking of future interviews: Don’t wait for an answer from this employer; immediately arrange subsequent interviews with others. Your goal is to pass several interviews and receive several job offers at once, then choose the one you like best.

Even if you passed just one interview and were immediately offered a job, still try to talk to at least one or two other places. If you think that only people with little experience and knowledge go through multiple interviews, that is a huge misconception! On the contrary, if you interviewed at a company and they hire you immediately, you likely either got incredibly lucky (unlikely) or you stated salary expectations far below market value, and they want to hire you for cheap as soon as possible.

Don’t overthink it by saying, “But that’s not polite…” You definitely have 1 or 2 weeks to “think it over.” Use them with maximum efficiency for yourself! Aim for anywhere from 3 to 10 interviews. At some, they won’t like you or you won’t fit; at others, you won’t like the employer (this happens much more often than you might imagine). From the remaining ones, you will choose (!) whom to join.

Regardless of the scale of your organization or the hardware you use, glitches happen. Sometimes network access drops, a system crashes, or something else goes wrong. Naturally, when a problem is detected, the responsible staff takes every possible measure to restore functionality as quickly as possible.

After restoration, an analysis of the incident’s causes is conducted, and measures are developed to prevent similar situations in the future. All of this can be described as the “Incident Management Process.”

Typically, companies use one of the following approaches to incident response:

Startups or Small Firms

In the event of any problems or outages, everyone turns to a specific specialist. That person analyzes the situation and resolves the issues.

Mid-sized Business

A larger company where IT infrastructure support is handled by several employees or even departments. In these situations, general chat groups (in Slack, Teams, etc.) are often created where incidents are discussed collectively. The employee who discovers a problem in their area of responsibility provides colleagues with detailed information and shares a subjective estimate of the time needed for recovery.

Enterprise (Large Business)

In large organizations, incident resolution is a fully established process. Critical systems are monitored 24/7. In the event of an incident, the Monitoring and Response team immediately organizes an emergency conference (a “war room”) and invites the relevant specialists. After the incident is resolved, the suspected cause is recorded, and the data is sent to a special commission. Furthermore, incident review board meetings are held periodically to thoroughly analyze every case. Root causes are identified, preventative measures are developed, and employees are assigned to implement them.

While this sounds modern and high-tech, the devil is in the details…

Let’s look more closely at that last option involving the process and the commission analyzing incidents, keeping in mind that all process participants are human.

The Incident Review Board

This board consists of respected employees holding relevant positions. They rightfully occupy these roles and possess a broad outlook, knowledge, and experience. However, obviously, they cannot know everything. They may not always have the competence to make a correct judgment. For example, they might have significant experience in server administration, but the problem occurred in the networking environment—specifically within dynamic routing protocols they have only read or heard about.

On the other hand, their role implies making a decision, even with insufficient knowledge in a specific area.

There is also a third aspect: the psychological one. Most people in leadership positions have a subconscious fear of losing face and publicly admitting they don’t understand the issue.

Over time, a standard behavioral algorithm develops for members of the review board. The analysis of any incident must give them answers to two questions: Who is to blame? and What do we do?

The Engineers

Now let’s look at this process through the eyes of the responsible employee. During the incident, they reacted quickly, eliminated the consequences, and restored their system.

Are they a hero?

Yes, absolutely. But almost immediately after the incident, a colleague or manager asks them to prepare a report describing exactly what happened—naturally, with precise timestamps, all details, and in accordance with the established form.

Even if all causes are known and clear, putting them on paper takes time and effort. But what if it turns out the outage happened because of an action taken by the employee themselves? They are human, too. And they don’t want to feel guilty. So, instead of solving current tasks, they start thinking about how to present the facts to avoid liability.

The larger the organization, the more formalized this process becomes, and the stronger the impression that all these reports and reviews are part of a punishment system for the mere fact that an incident occurred.

Who suffers most from this approach?

Let’s take it as a given that humans make mistakes.
IT specialists responsible for keeping infrastructure running are no exception. Let’s assume a specialist makes a mistake in one out of a thousand operations. A simple typo while configuring equipment might not affect the system at all—for example, if an engineer makes a typo in the description field. But with the same probability, a typo in the configuration logic can lead to the loss of a critical company resource or even the entire infrastructure.

In any case, the more operations a specialist performs, the more mistakes they make. In other words: those who work the most, make the most mistakes, and consequently suffer the most from this attitude toward incidents.

It turns out that the process created to combat incidents actually begins to backfire in some cases:

1. It wastes more employee time, distracting them from daily tasks and increasing the risk of future incidents.

2. It indirectly punishes the hardest workers.

That doesn’t seem quite right, does it?

Criticizing? Propose a Solution!

First and foremost, with any incident management approach, I advise against looking for scapegoats. All participants in the process without exception—users, specialists, managers, and even business owners—should focus on quickly identifying the root causes and eliminating them, rather than finding someone to blame. This is only possible if everyone is confident that telling the truth won’t get them in trouble.

In other words, during any incident, the question should be: “What was done last, and by whom?” And every specialist should answer honestly and without delay: “I did nothing” or “I did X at location Y.” If the incident is caused by human error, this cuts troubleshooting time drastically. If you look deeper, you could say the specialist has a right—or rather, a Privilege—to Make Mistakes.

Judge for yourself. If they are scolded for every slip-up, glitch, or downtime, the natural reaction will be to not touch the system at all. Consequently, they won’t fully understand its capabilities and limitations. This means more time will be needed to react in the event of a system failure.

An experienced specialist is not afraid to make mistakes. Through them, they gain valuable experience and an understanding of the system’s strengths and weaknesses.

At the same time, an experienced specialist never forgets the responsibility and trust placed in them. After all, their actions directly affect the availability of the systems and services entrusted to them, and thus the business as a whole.

The specialist’s motto should be: “You broke it? You fix it!”

Remember Responsibility

Every specialist should know that a single incident caused by their actions will not result in any punishment. However, everyone will expect their active participation in analyzing the causes.

In the case of a repeated incident, the company should consider changing the IT process that might be leading to human error.

Only upon the third recurrence of the same incident involving the same specialist should disciplinary measures be considered.

To summarize:

1. Don’t look for the guilty party. This ultimately leads to an increase in incidents or the time required to resolve them—and consequently, direct losses for the company.

2. Instead, try to minimize the time spent finding the root cause.

3. If the system isn’t working, nobody touched anything, and it’s unclear what to do with it—just reboot it.

Monitoring systems are, without a doubt, a useful and critical tool. Everyone recognizes their necessity. However, for most organizations, implementing these systems is fraught with difficulties. It often happens that engineers spend most of their time maintaining the monitoring system itself rather than having it help them solve problems.

Let me share some personal experience that will likely help many people better understand the problem.

Monitoring “As Usual”

So, management concludes that a monitoring system is critically important and assigns the task of implementing it. An engineer, who is already busy with their core duties—like configuring networks—is told to “deploy a monitoring system.” Often, no one knows how to do this because it’s their first experience in this area. Let’s say the company has a hundred remote branches, and they need to monitor the availability of communication links with each of them. In this situation, they start looking for free solutions, studying available options, and picking one.

Usually, they choose the simplest solution based on checking endpoint availability via ping. After spending significant time installing and configuring it, they expect immediate results. However, the system starts throwing false positives. For example, a remote branch has a primary and a backup link, and the system monitors both. The engineer gets an alert about link issues, checks the availability, and finds that everything is working fine. The monitoring system cried wolf. Despite cases where there are actual problems, most alerts turn out to be false. As a result, instead of helping, the monitoring system simply scatters your focus, leading people to eventually neglect it.

Let’s look at another scenario. In addition to remote sites and links, the central office has critical equipment that needs monitoring. You set up availability checks for devices and their parameters. However, when a real outage occurs in the central office—especially if it affects network equipment—the monitoring system turns out to be useless. How can it transmit information if the infrastructure’s root equipment is down? You will most likely hear about the problem via a phone call or someone yelling, “Everything is broken, go fix it!” After the issue is resolved, the monitoring system will come back online and flood your inbox with thousands of emails about what happened. Very timely, right?

Suppose the company realizes the need for a more advanced monitoring system and chooses a solution with SNMP support. This protocol allows devices to send data about their status—such as CPU load, memory usage, and network interface status—to a centralized collector. After installation and setup, even if you aren’t a specialist in this field, you discover that every device on the network is constantly reporting some kind of “problem.” For instance, one device has constantly high CPU load, another is low on memory. Generally, this state might be normal for that specific device. However, the monitoring system constantly flags issues, demanding attention and verification. The result is the same: a reluctance to react to constant false alarms and a desire to receive only reliable information about real problems. Ultimately, the monitoring system gets less attention than it should.

And the final scenario. Suppose you got really into the setup, and everything is configured perfectly. Data is being sent correctly, and false positives are minimized. But an outage happens after hours. What do you do? If notifications are set up for external communication channels, you’ll get the alert at home. But is it worth driving into work in the middle of the night? If notifications aren’t set, you’ll only find out about the problem in the morning, which leads to lost time and a delayed response.

Monitoring: Successful Use Cases

As a constructive suggestion, I’ll share some experience gained from a professional in the field of monitoring. He told me about several successful cases where a monitoring system was used for good.

The first case involves monitoring a router in a remote office that acts as a gateway for internal networks and has external communication links. Simply tracking external interfaces doesn’t allow you to determine if the entire router has failed. Monitoring internal interfaces also doesn’t give a full picture, as they can be disabled accidentally or intentionally. Checking CPU or memory load might not indicate an outage but rather reflect normal device operation. So, what do you do? The solution is event correlation. Every office has a set of static infrastructure services: a print server, file server, DNS server, email server. Modern monitoring systems allow you to link events; meaning, to determine a router failure, you need to track the failure of all these services within a short timeframe—for example, 15 seconds. Combined with link monitoring, this gives you grounds to call in an engineer and suspect a router failure.

The second case is one of the most illustrative examples demonstrating the value of monitoring systems, even from a financial perspective. A guy who worked in the banking sector told me about this. As you know, banks have an extensive network of service offices, ATMs, and other remote points connected to the central office via communication links.

These links are usually purchased from a large ISP capable of providing coverage for the necessary territory and are secured by a contract. The contract includes an SLA (Service Level Agreement), guaranteeing 24/7 link uptime. All parties agree, the contract is signed, and connectivity is provided.

However, given the scale of the network, the ISP periodically has issues leading to glitches and disconnects. This is where the efficiency of the monitoring system shines. First, the system automatically generated a ticket for the ISP upon detecting a connection break. This ticket, containing the contract number, failure point info, timestamps, and other parameters, was sent to the duty engineer, who only had to confirm it and email it to the ISP’s tech support.

Secondly, the monitoring system kept statistics on all tickets and generated a monthly report reflecting the total downtime of communication channels and details on each incident. This allowed the company to save significant money through penalties for SLA non-compliance. Thus, a win-win situation was created: if there were no failures, the ISP faithfully fulfilled its obligations; otherwise, the bank received compensation for the breach of contract terms.

Afterword

Implementing a monitoring system is a complex and responsible task, requiring not only specialized knowledge but also an understanding of the company’s business processes. Therefore, it is inefficient to assign its setup to engineers who are busy with other tasks.

For the system to work effectively, you need a dedicated specialist to handle its configuration, optimization, and monitoring. Furthermore, you need staff who can react promptly to emerging incidents—a duty shift or specially trained specialists (NOC). With a comprehensive approach, a monitoring system becomes an indispensable tool for the company, significantly simplifying the work of engineers and increasing business efficiency.

Let’s talk about the most interesting topic: salaries for modern IT specialists. Naturally, the figures mentioned here aren’t set in stone, but rather serve as a rough benchmark.

Junior Network Engineer (or simply Network Engineer)

This person has studied the basics of network technologies.
They know what routing is and how switches work.
They have heard of firewalls.
They have a basic understanding of existing IT systems, servers, and virtualization—at the level of “read a couple of articles on Wikipedia or similar resources.”

With this background knowledge, zero experience, but plenty of motivation, they arrive at an interview. After successfully passing it, they start working in a position paying $65,000–$71,000  per year.

At this new job, they handle simple, routine tasks: configuring equipment using pre-made templates, investigating why communication links are down, and fulfilling access requests. They handle other mundane duties. At the same time, thanks to constant practice and hands-on work with hardware, they dive much deeper into the theoretical aspects of how technologies work, while also gaining experience interacting with the company’s specific network equipment.

They work like this for about 2–3 years, gaining invaluable experience and knowledge, after which they begin to qualify for the position of Senior Network Engineer.

Senior Network Engineer

This position brings the engineer $90,000–$110,000 per year. It includes all the same duties as the Junior Network Engineer, but at this level, the specialist is assigned to solve particularly important or complex routine tasks.

Management also starts occasionally assigning them unique new tasks for which no templates or regulations exist within the organization yet.

For example: There are 10 offices, and a VPN tunnel is built with each one. Every office uses the exact same equipment from the same manufacturer. Suddenly, a new office opens, and a similar VPN tunnel needs to be established. However, it turns out the new office bought equipment of the same class, but from a different manufacturer. A VPN tunnel needs to be configured with it.

On the surface, it’s the same task the specialist has solved before. But the use of new, unfamiliar equipment adds complexity.

Furthermore, assuming the engineer is smart, they have continued to study networking theory deeper and broaden their horizons this whole time.

But what does “broaden their horizons” mean? It sounds complex and vague. However, in the modern world, there is a huge number of existing technologies and just as many emerging ones. One way or another, we constantly hear new words and terms. To broaden your horizons, all you need to do is write down any new term you hear in a notebook, and at the end of the day, simply search online for “what is this term and technology anyway.” It doesn’t necessarily have to be about networking—let it be virtualization, databases, or even something new about programming languages. I assure you, if you read just one short article every day, in a year you will accumulate a very solid knowledge base that will help in any field of activity.

Returning to IT salaries, we see a picture where this Senior Network Engineer has 5–6 years of work under their belt, excellent practical skills in equipment configuration, a wealth of theoretical knowledge, and a decent outlook on the world of IT technologies. With all this, they are ready to apply for the position of “Lead Engineer” with a rate of $123,000 per year.

Lead Engineer

These engineers no longer need templates. They clearly know how everything is organized, the optimal way to configure specific equipment, and generally understand how to optimize any given area of their work.

In this role, the engineer begins to solve more and more new, non-standard tasks, most of which boil down to two directions:

1. How to change the existing network so that it meets new tasks, requirements, and conditions.

2. How to introduce new devices into the existing network so that they perform their functions without damaging the company’s existing infrastructure (so-called integration of new technologies).

This can include:

• Replacing old equipment with new or more powerful hardware.

• Installing new systems that had no prior analogue in the organization.

• Complex changes to the network schema itself.

• Other interesting tasks and challenges.

At this point, your horizons begin to expand almost automatically. Every task is a new challenge. New equipment, new integrations into the existing network, and other fascinating aspects.

The next few years in this position turn you into a true professional who knows their business and is ready to squeeze the maximum out of available equipment to benefit the company.

Chief Engineer, Architect, and Project Manager

After approximately 5–7 years of a career, the engineer—now a true professional—faces a choice of three vectors to pursue. Each position allows for a salary between $113,000 and $170,000  per year, but the role the engineer plays will change depending on the chosen path.

If the specialist works in a relatively small company with few employees, their position will likely include all three of these roles. However, in a large organization, these will likely be three separate positions. An engineer can become a Chief Engineer, an Architect, or a Project Manager.

• The Chief Engineer is a direct path of development implying a concentration of effort and experience on the support and maintenance of the existing network. All new projects and implementations pass through this engineer. They are responsible for ensuring everything works normally and that any technical glitches or difficulties are resolved as quickly as possible. Usually, this position is occupied by people with pronounced technical skills, strong memory, knowledge, and practical experience. Often, they do not like excessive communication. They find it much more interesting to tinker with equipment and get the most out of it.

• The Network Architect, conversely, is responsible for network development. This is an engineer with a good imagination, a creative streak, and strategic thinking. They are constantly on trend, trying to learn about new equipment and technologies appearing on the market. Their main task is to design new sections of the network, actively participate in product integrations, draw up schemas for system operations, and so on.
  This role implies much more communication with colleagues, even those who do not understand technical issues very well. The Network Architect needs to understand existing tasks, study all currently available technical solutions, and then choose the most effective one. After that, they work through all theoretical issues and, together with the implementation team, realize the vision, taking responsibility for the final success.

• The Project Manager. This is a person with a massive outlook and experience in the field they manage. This is the least “technical” role at this level, but no less important. This specialist must tie together all existing points of view: the manager setting the task, the network architect proposing a path for execution, and the chief engineer along with the colleagues who will have to configure and support the equipment. The Project Manager must find a common language with everyone and constantly synchronize the actions of the process participants. Communicative, active people who are less interested in technical details and prefer organizational work feel very comfortable in this position.

If we take a non-networking direction—for example, a Systems Engineer—the salary ranges and general scope of duties will be absolutely the same. Only the specific tasks and nuances related to the chosen direction will change.

Router

A router is a device designed primarily to transmit packets based on IP address information. Its job is to receive a packet on one of its interfaces, look in the routing table and decide which interface and which next gateway to send the traffic to.

Almost every router has a basic security feature – the ability to create access rules – Access Control Lists (ACL). In them, you need to specify the source, destination IP addresses, protocol and port and mark whether such traffic is allowed or prohibited. In this way, you can regulate network traffic, limiting unwanted connections.

Example:

from host 192.168.1.10 to host 8.8.8.8 by protocol TCP and port 443 action Allow

Important!

It is important to note that the logic of ACL operation in routers is similar to a stencil that the device applies to an incoming or outgoing packet. If there is a match, it lets the traffic through. If there is no match, it does not let it through.

As an example of using this feature is when you make such a rule for some external IP address of a site on the Internet where malware is located.

However, you should always remember that a router is designed primarily to transmit traffic, not to control it. Its main task is stability and speed of traffic transmission.

Firewall

A firewall is a security device. It is created specifically for traffic control and has a much larger arsenal of capabilities . There are also access lists and they look exactly the same as in routers – source address, destination address, protocol, port and action (allow or deny). The key difference is that the firewall analyzes the state of established sessions for a number of protocols. This technology is called stateful inspection.

The difference in the logic of ACL operation with a router can be clearly seen in the example of the TCP protocol (HTTPS). Let’s imagine that a user in a corporate network goes to some site on the Internet, sending a request. At this point, the router and the firewall will act the same – having received the user’s request, they will look in their rule bases and pass the traffic through themselves.

Then the web server responds to the user’s request and here the logic of the router and the firewall will also work the same – both will pass the response packet. So what’s the difference?

The difference will be when an evil hacker decides to try to hack your network and tries to trick the device by posing as a web server. He will try to send a packet right away, making it a response to a non-existent request. If you have a router, it will contact its rule base, see a match and safely let such a packet through without suspecting anything amiss. Then the hacker can have a possibility to establish a connection with one of the network hosts inside the network and continue to do his dirty deeds.

But the firewall, having received a response packet after a quick analysis, will understand that there were no requests for it. And it will not let such a packet through. It will also make a corresponding entry in the log so that the administrator will definitely pay attention to such attempts.

The firewall has to pay for the ability to work with this and other security functions with its performance. And the conclusion from all this will be that both devices are important and necessary, but each of them has its own area of ​​application. If you need to transfer large volumes of traffic, then you need a router. And if you need to control network traffic, then you can’t do without a firewall.

NGFW

NGFW – Next Generation FireWall. Technology development has led to the fact that equipment manufacturers have the opportunity to combine several security devices into one. A regular firewall is taken as a base, and additional features are added to it in the form of virtual modules, for example, the IPS module – Intrusion Prevention System.

In simple terms, IPS is a module that contains several thousand predefined rules. These rules are called signatures and each of them describes a set of parameters by which malicious traffic can be identified. NGFW compares incoming traffic with this database and applies specified actions to the traffic (permissions, notifications, blocking …)

The Application Control module is also very useful. It allows you to specify in the access rules not the protocol and port, but a specific application. For example, in a regular firewall, to allow SSH traffic, you need to open TCP 22. But some server or service can work using the SSH protocol, but use a non-standard port. For example, 10022 (or any other). This can be done by a developer for some purpose, or used by attackers who are trying to disguise their activity. NGFW with the App Control module will allow you to specify the SSH protocol in the access rule, after which the device will regulate this type of traffic despite the TCP port. More convenient and safe.

Network Antivirus module – allows you to run an antivirus scan for files passing through the device.

URL filtering module – allows you to open Internet access to certain categories of web sites. For example, allow users to read news, use search engines and online stores, while prohibiting adult content, illegal substances and other obscenities.

SSL Inspection module – allows you to decrypt SSL (HTTPS) traffic in order to search for vulnerabilities and malicious activity. NGFW receives a request from a user to access a web resource on the Internet, decrypts it and sends it further on its behalf. Without this module, NGFW cannot look inside such traffic, since the transmitted data is encrypted.

Read more articles about networking In Deltaconfig style

Visit us on Facebook – Deltaconfig

The main task of a switch is to unite devices into a single network. It transmits data received on one of its interfaces to another based on the source and destination MAC address information contained in the transmitted frame.

Their logic is based on the Switching Table. As soon as a new host appears on the network and tries to transmit any information, the switch records that a new MAC address has appeared on one of its interfaces. A switch records this data in the form of a table like this:

Interface X – MAC address Y

When this newly appeared host tries to access some MAC address, for example, a neighboring host, the switch analyzes the information about the destination MAC address and sees if it is in its switching table. As soon as a match is found, the switch only has to transmit it from one interface to another.

If it does not find a match, it will try to send the frame at once through all its interfaces. If the target host is “alive”, it will definitely respond to such a request. And the switch, having seen a response from another MAC address, will enter the data into the switching table and then will simply forward data from one interface to another.

The lifetime of data in switching tables is usually 5 minutes. If both devices stop sending and receiving information from each other, then gradually the data about their MAC addresses will disappear from the table. The process will repeat again as soon as the hosts need to transmit something to each other again.

Read more articles about networking In Deltaconfig style

Visit us on Facebook – Deltaconfig