Networking Terminology – Understand what you say



My intention with this blog post is to highlight a couple of scenarios that you are likely to face as a network engineer. Scenarios where it’s very important that you understand exactly what the words you choose to use actually mean to your co-worker. Whether it’s between a client or an internal discussion between network engineers and management – understanding the network terminology is extremely important!


I often end up discussing how to solve a specific technical problem. When I think about network terminology, I think about how easy it is to confuse someone if you assume that they know what you are talking about. In other words – I need to make sure that I use the correct network terminology so that we both understand each other.


My goal is that after you have read through this post, you will have a better understanding of the challenges that exist when discussing networks as part of your work. It's not as easy as it seems to discuss networking and use the terminology in a way that makes sense. Cisco engineers have a bad habit of assuming that the Cisco terminology is the general networking terminology used. And there is a lot of other networking terminology that is also confusing and easily misunderstood. It's very easy to discuss networking and overlook the fact that you might use the same words – but they mean different things to different engineers.


So this will be a less technical blog where I will mostly focus on some of the networking terminology that often leads to misunderstanding and confusion during discussions.


Why all the talk about Cisco engineers?

If you are working with networking of any kind, everybody has heard about Cisco. Even if you don’t use Cisco equipment in your networks, the engineers managing the networks have probably been Cisco-educated at some point in their career. Most engineers I’ve spoken with have started their networking career using Cisco equipment, regardless of whether they actually ended up using it for their employer or not.


There are many reasons for that, but I believe the main one is because Cisco has done a tremendous job of producing study materials available to the “public mass”. Just to name a few of the things Cisco has made available:

  • Cisco Learning Network
  • Cisco Networking Academy
  • Strong career path & certification paths
  • Cisco Press
  • Cisco Live
  • Cisco documentation (Understanding x technology sections are great!)


Why has Cisco invested so much time (and $) into creating education content?

If you think about it, there are plenty of reasons why any company would want to create such a strong brand that, no matter where you go, everybody has heard about it. So, not to be naive – Cisco does this with some expected return on their investment. In most cases, the materials are made available to get you hooked on Cisco technology and equipment, or to pass a Cisco-specific exam (such as CCNA R&S).


If you are new to networking and begin studying it, you will hear about Cisco. They have created some of the best content available to teach new talents about how networks work.


Many network engineers start their career by reading about networking from content created by Cisco. Whether it’s to study for a Cisco certification exam or to learn about a networking technology, Cisco is there to support you in your studies. This comes with the side effect that once you start working as a network engineer, you [unintentionally] will favor Cisco when making decisions about which networking brand to use. Because one key factor in choosing a vendor is always going to be how well you understand their products.


There is absolutely nothing wrong with that, but let’s consider what’s also included in their exams and in their content.


A lot of networking terminology! Terminology that you must understand to pass their exams! Terminology that is even only used on Cisco equipment, but not by the rest of the industry! Because of this, you will remember the Cisco networking terminology and assume that everyone else understands what you mean! That’s why I talk about Cisco engineers!


I hope that I can at least encourage you to think about these things so you will become better equipped to avoid the confusions that can lead to really bad implementations in your networks!


What is Network Terminology?


I've been thinking about this, and the best way I can explain it is...

All the words we use to describe how interconnected electronic devices transmit and receive information.


That doesn’t sound too bad, does it?


Well….the problem is that there is no standard, so it’s up to each vendor to choose how to use their version of network terminology. This is a very important piece of information to remember when having a discussion with engineers from multiple vendors. Don't make the mistake and assume that every engineer is using the SAME networking terminology, even if it's the same words!


I want to provide you with a few examples where it's possible that if you assume that everybody is using the same networking terminology without verifying it, it can lead to wrong decisions. And to get there, we need to define some common networking terminology first!




I could walk you through a deep technical dive into the technologies I will discuss, but I choose to leave out a lot of technical data and technical explanations for a reason. I want to keep this as simple as possible and just go deep enough to discuss the issue I want to highlight – that networking terminology is easy to mix up and can be very confusing if used incorrectly! I strongly encourage you to do your own research to understand the technologies discussed!


To avoid confusion during this post, I have organized this by what I choose to call “General Networking Terminology” and “Cisco Terminology.


General Network Terminology

There are several technologies used in a network that almost everybody working with networks has heard about. There are too many to cover in this post, so this section will very briefly just cover these technologies:

  • Ethernet
  • Topologies
  • Traffic Flows
  • Bandwidth
  • Virtualization (very briefly)




Ethernet is the most used LAN technology today for interconnecting devices on a network. When sending data over Ethernet, a standard Type II Ethernet frame is 1518 bytes long and carries a MAC header (which includes addressing information about the sender and receiver), a payload (data), and a checksum (CRC).


Ethernet is used to connect different network segments together and is considered a shared medium. That means collisions can occur, so each segment needs to use CSMA/CD* (even with a switch). These segments are called a collision domain*. In a HUB all ports connect to the same network segment*, so each port in a HUB belongs to the same collision domain. Using a switch instead – all switch ports connect to a different network segment, so each switch port is a different collision domain.


When using a switch, it will make a frame forwarding decision based on the destination MAC address used in the MAC-header. Since a switchport is its own collision domain it means a frame will be forwarded between multiple network segments. The frame can be sent as a unicast frame, a multicast frame, or a broadcast frame. A unicast frame is sent to a single destination on the network segment, a multicast frame is sent to a selected group of addresses on the network segment, while a broadcast frame is sent to all hosts on the network segment.


The switch will make the forwarding decision using its CAM table. A unicast frame is forwarded out of a single switch port. A multicast frame is forwarded out of all switch ports that are members of the multicast group (selected group). The broadcast frame will be sent out of all switch ports. The scope of how far the broadcast frame will be forwarded is called the broadcast domain*. But a switch will never forward a frame back out on the same switch port that it was received on.


Ethernet supports multiple topologies and multiple network designs, and if you are not careful, you can end up with a very large multicast group or a very large broadcast domain. Both will impact your overall network performance, so it’s a good general rule to keep your broadcast domain as small as possible.


*Note: Learn more about CSMA/CD, segments, collision domain, and broadcast domain on your own!



A network topology refers to how the network nodes (hosts) are interconnected, including the physical cabling and the logical signaling. A very important skill for any network engineer is the ability to discuss different network topologies. That also includes being able to understand the difference between a physical topology and a logical topology.


In many cases, the physical topology is a star topology, while the logical topology is a bus topology. When I discuss network topologies, I often need to explain the differences between the physical topology and the logical topology to explain a problem. A common mistake is to believe that the physical topology and the logical topology are the same.


“In many cases, the physical topology is a star topology, while the logical topology is a bus topology.” What does this mean?


Physical Topology

The physical topology is easy to understand. Just draw how the devices are actually cabled and wired and you get the physical topology. Examples used today are:


#1. Star Topology                                                      #2. Ring Topology                                          #3. Tree Topology


Logical Topology

It’s much more difficult to try to understand how the logical topology looks. The logical topology is equal to how the communication appears from the perspective of the connected users (hosts).


What impacts the logical topology?


In general, depending on how your network is cabled, it will impact how your logical topology will look.– But what’s often overlooked is that multiple other components also affect your logical topology. Depending on which protocols you are using and how they are configured, you will create different logical topologies.


The most common protocol used in Ethernet is STP* (Spanning Tree Protocol). It’s used to prevent bridge-loops* (often called switch loops). STP will make sure that all redundant connections that can cause a bridge loop will be blocked when you cable multiple switches together. Since STP will block links in that case, it affects the logical topology. The communication path that hosts can take in your network is changed because of the links that STP blocked to avoid bridge loops.


I only mention STP briefly to show that it affects the logical topology and there is much more to learn about how it works. Let's look at an example of how a logical topology looks before STP and after STP.


  Topologies before STP



                              Physical Topology                                      Multiple Logical Topologies


The logical topology between User 1 and User 2 have multiple paths available. User 1 could reach User 2 via multiple paths, for example:




(There are more available paths, which I left out.)


A network cabled like that will not perform well without a protocol to prevent loops caused by the multiple paths available. STP is going to help us block some of the redundant links, and you can configure it and tune it to meet your network requirements. Depending on your STP configuration, you can end up with different logical topologies even if the physical topology remains the same. From the perspective of the connected hosts, STP allows you to build these logical topologies:


In this case, STP can create multiple logical topologies based on a physical topology. It can be tuned and configured according to best practices you want your core switch to be the root bridge* so that traffic will flow over CSW1. This section doesn't cover any of the advanced features of STP or how it works other than to demonstrate that it will affect the logical topology.


STP is not the only protocol that will build a logical topology; there are too many protocols to discuss in this post to cover them all. I’ll just name a few others for reference purposes:

  • EtherChannels (used to hide physical topology for the protocols that build logical topologies)
  • Routing protocols (provides a logical view of interconnected networks and how to reach them)
  • GRE (used to build a “virtual” or logical point-to-point link)

I strongly encourage you to research more protocols than STP to get a better understanding of how logical topologies can be created!



I mentioned that “traffic will flow over CSW1” before. What does that really mean?


When discussing traffic flows, you need to understand the difference between ingress traffic and egress traffic. Traffic usually flows ingress on one interface and egress out another interface. It's also possible that the ingress and egress traffic is using the same interface in advanced topologies. This is what creates the “Tx” and “Rx” counters in your interfaces.


  RFC 3697 defines traffic flow as:

"A sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection."


In other words, it is the direction in which the packets are being forwarded. The flow can be spread across multiple logical paths for redundancy or load-balancing* purposes. Just like STP, there are technologies that can hide the physical topology to create a different logical topology. Talking about interfaces and traffic flows, a port channel (EtherChannel) is one such thing.


To view your ingress- and egress-generated traffic, all you need to do is look at your Tx and Rx counters on your interfaces. On the interface where the traffic is received, you will see an increased Rx counter. Similarly, you will see an increased Tx counter on the interface where the traffic is forwarded out. These are your ingress and egress traffic flows.


There is no difference between a virtual interface* (port channel) and a physical interface as far as how the counters look, but there is a huge difference between the traffic flow over a port channel interface and a physical interface. That’s why you will see generally higher counters on a port channel interface. Here’s an example of a port channel with eight physical links (2.79Gbp/s):


If we look at the individual links in the bundle, we can also see exactly how much each link has been affected by the traffic flows as part of the port channel bundle. Showing only one link as an example (31.80Mbp/s):


This may look confusing at first, but what the port channel interface does is it bundles multiple physical links together in a “channel” and creates one virtual logical interface. In other words, it hides the physical topology to create a logical topology.


What happens with the traffic flows when it's sent over a virtual port channel interface?



Link Aggregation, or simply “LAG,” is the terminology used by most vendors for bundling multiple physical links into a virtual logical one, which Cisco displays as a port channel interface. A port channel is used to provide redundancy for the physical topology by creating a single logical link for your network hosts to communicate through. There are two options to choose from: LAcP (vendor-neutral, most common) or PAgP (cisco proprietary, less common).


Some of you are probably wondering why I mentioned that LAG was used to provide physical topology redundancy and NOT to increase the available bandwidth as well.

It makes sense to think that since you connect multiple links and create a virtual interface that consists of them. The problem is that every single traffic flow generated from your hosts will still use only a single physical link from the bundle.


There are a couple of reasons for that, which mostly involve solving application problems. I will not explain those, but it's a problem for applications that need to be solved. To solve this problem, there is a hashing algorithm involved to figure out which physical link to use from the bundle. It doesn’t matter if you choose LAcP or PAgP – they will both need to use the host flows as the string value to be computed through a hashing algorithm.


And when I say “host flows,” I’m talking about the information contained within a flow, such as source/destination MAC address, source/destination IP address, and source/destination TCP/UDP ports.



Why do we use hashing and what is it?


Hashing is a widely used concept within the IT world. It’s a multi-purpose technique used to generate a value based on a string that is computed through a mathematical function. The mathematical function used is called the hashing algorithm, and the value computed is called the hash value. A hash value is used because as long as you provide the same input string to a hashing algorithm, it will always generate exactly the same output hash value.


We can then use the computed hash value instead of the original string for simplicity. In networks, we run a lot of data through a hashing algorithm to scramble data before we transmit it (encrypt it). But the same technique can also be used to choose a physical link to use when they’re bundled into a logical interface.


Now pay attention to what I said there - The same input string will always generate the same output hash value.


It’s a very big misunderstanding in the networking world that a port channel interface is mainly used to provide active/active forwarding. It’s used to provide redundancy for your physical topology. That means that just because you are creating a virtual port channel interface that consists of 2x10Gbp/s links, it doesn’t spread the load across the links so you get a total of 20Gbp/s available bandwidth for your data flows.


A hashing algorithm is used to decide which physical link to use, and it means that as long as all the same parameters are used in the input string, then the algorithm will ALWAYS choose the same physical link to send your data over. This is done using a XOR function, and I'll provide a brief example of how that works.


It takes a couple of parameters used as input string, then computes the string through a XOR-based hashing algorithm. The computed hash value will then decide which physical link is going to be used. There are many configuration options available to decide manually which parameters to include in the input string to be computed through the hashing algorithm. The default parameters are platform-dependent.


To compute the hash value, a XOR function is performed based on the following:

  • Input parameters from the flow to be hashed.
  • The number of physical links in the port channel bundle.


Consider a flow that’s using Source IP and Destination IP I’ll line them up in binary and then perform a XOR function on the binary values. The number of bits that are used depends on the number of links in the bundle.


Here’s how it works using XOR

SRC: 11000000. 10101000.00000000. 00000001
DST: 11000000. 10101000.00000001. 00000001
XOR: 00000000.00000000.00000001.00000000


The number of links in the bundle determines how many bits will be used from the XOR function. A link means a bit value, so two links are just two binary values. Link 0 or link 1. Only the last bit is needed to decide which link to use if it consists of two links. It's more easily represented like this:


SRC: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxxx1
DST: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxxx1
XOR: xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxx0


With four links in the bundle we also need to use four bits to decide which link to be used. Link 00, Link 01, Link 10, Link 11. The fourth bits will be used and look like this:


SRC: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxx01
DST: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxx01
XOR: xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxx00


As you can see, Link 0 will still be used, since “00” in binary is still 0. But with four links in the bundle we have more links available to be used by the algorithm. So remember it doesn’t help to increase the number of links in a port channel – the same input parameters will still decide to use the same link in the bundle!


In other words, it looks like you have increased bandwidth available with more links in your bundle, but remember how the hashing works!



The last piece I want to talk about is bandwidth. Everybody has heard about bandwidth – it’s increasing everywhere. Some of us are already deploying 100Gbp/s links in their networks. The need for increased bandwidth is driven by more and more data to be transported across a network. I want to highlight two things that can be confusing when talking about bandwidth:

  • Throughput
  • Goodput


Remember when I talked about the Rx and Tx counters before?


That’s going to be your throughput. Your throughput is all the bits that you can transfer through your network. This includes all the needed headers and everything that is transported across your network. So for example, a 10Gbp/s link is capable of 10Gbp/s throughput. You can transfer 10Gbp/s over that link.


But what about goodput?


Goodput is often overlooked, and usually that’s something your end users will want. Goodput is when you take all your throughput data and strip all the headers and all the application layer overheads and just keep the data that you can use…that’s what goodput is! Taking the same example with a 10Gbp/s link, if you transfer a flow at 10Gbp/s and just look at how many of those bits are actually useful to your user sending them, you might end up with 7Gbp/s of goodput.


In that case, you would have about 30% overhead in that flow.


When discussing bandwidth, remember that it’s not all about the speed of the link. Having 8Gbp/s of goodput with 9Gbp/s throughput is better than 10Gbp/s throughput with only 7Gbp/s goodput. So you must consider the goodput and how you can increase the goodput! But that's outside the scope of this post.



I’m sure you’ve heard about VLAN before, so I’m not going to discuss what it is except to mention that it is a virtual version of a local-area network. That means we can configure our switches to only forward frames within our virtual network. We can spread this network to other switches using what Cisco calls trunk ports, or we can spread them using access ports. By default, all switch ports on a Cisco switch do not have any trunk ports, but they have all their switch ports as members of VLAN 1.


I briefly mentioned VLANs because the Cisco VLAN terminology is the number one reason why things can go really wrong if you assume that the Cisco terminology is used everywhere. In short, Cisco decided to use some words that are not easily understood by the rest of the industry. So if you are not careful with these words, you will end up in a lengthy discussion and most likely with a misconfiguration because of it!


Cisco Terminology


This last section is included to highlight why things can be really confusing if you assume that the Cisco terminology is used everywhere. I'll just mention some of the Cisco terminology that is available and use an example based on experience where these can be mixed-up.



I mentioned that we can spread VLANs using something called access ports or trunk ports. This is something that you need to manually configure and define as part of your network implementation. By default Cisco provides us with a base configuration that defines all switch ports as members of VLAN 1. This is what Cisco calls the default VLAN. It’s a term used to describe which VLAN all switch ports belong to by default. With a base configuration out-of-the box, they are all configured as access ports in VLAN 1.



Cisco defines a switch port that is member of a specific VLAN to be an access port in that VLAN. Technically speaking, that means that frames forwarded to this switch port will be sent “untagged” for that VLAN. In my opinion, this is a confusing definition, because the rest of the industry uses the terminology "untagged ports" and "tagged ports" to define what type of frames are sent to/from it.


Consider that when you have a discussion about VLAN implementations. The Cisco terminology “access ports” is not used by other vendors, and it's a high chance they will only understand what untagged/tagged ports mean.



When using Cisco equipment, it means that you can configure a swith port to carry multiple VLANs. When frames from multiple VLANs cross this link, the switch will add a 802.1Q tag to identify which VLAN it originally belonged to. This link will also look at the 802.1Q identifier to know where to forward a frame that is received on this link. This is a Cisco trunk port!


In my opinion this is the most confusing Cisco terminology, because the rest of the industry defines trunking as a way to aggregate multiple links as a trunk link. Cisco uses the trunk port to carry multiple VLANs, while other vendors will call this a tagged port.


Consider how extremely easy it is to mix up LAG with VLAN-tagged ports if you use the word trunking in a networking discussion.



Cisco uses the concept of a native VLAN to define which VLAN that should never contain any 802.1Q VLAN identifier in their frames. Technically, using a Cisco switch means the VLAN will never send any tagged frames across trunk ports, and it also means that if any untagged frames are received on a trunk port, they will be forwarded to the native VLAN.


If you talk with someone that hasn’t studied Cisco, they will usually look like a question mark when you say the term “native VLAN” and in my opinion this is confusing because a frame is always sent “untagged” or “tagged” in a network!



EtherChannel is the Cisco term for bundling multiple physical links into a logical virtual interface called a port channel. It is the same that I mentioned before when I used the term link aggregation (LAG).


If you are having a discussion with other teams outside the networking-area, for example a storage, server or client team - they usually look very confused when hearing this term because they're used to link aggregation. Just remember that this is Cisco terminology if you talk to other vendors or teams!


3 Case examples why it’s important to understand Networking Terminology


If you’ve managed to read all the way down here without falling asleep…then here are my 3 examples of why it’s so very important to understand the network terminology properly before making implementations/decisions! There are of course more cases or scenarios where things can go wrong, but these three will be a good example for this post and the terminology I've discussed.


CASE #1 - VLAN terminology mix-up

You are planning to implement a VLAN change in your network and decide to have a discussion with another engineer. What happens if you are using Cisco VLAN terminology and the other engineer is not used to Cisco terminology?


If you agree to create a trunk port between your switches, then the chances are high that the following happens:
-You end up configuring your end of the switch port as a Cisco trunk port supporting 802.1Q.
-The other engineer end up configuring his end of the switch port as a LAG using LAcP.


Depending on both of your configurations, you might end up with a switch loop. In either case, both of you assumed what a trunk port meant. So the implementation from both ends was not the expected result!


CASE #2 - Misunderstanding how much bandwidth is available

You are told to increase the available bandwidth in your network because users have complained that their bandwidth needs are not enough. You decide that link aggregation/Etherchannel can be used to increase the bandwidth, so you bundle multiple links into a port channel.


What happens when you say that you have doubled the amount of available bandwidth and your users discovers that it’s not working?


Remember that creating a port channel interface does not increase the throughput by the amount of available bandwidth. You need to consider the hashing function and the difference between goodput and throughput to make sure that you provide a good user experience.


CASE #3 - Not considering the needed topologies before placing/moving hosts in your network

During a network overview, it was discovered that some of your links in your network are utilized more often than other links, and you want to spread the load out more evenly due to this. There are multiple options available to address this, but you decide to move hosts around to try and spread out the load.


What happens if you don’t consider the logical topology that the hosts need to use to be able to communicate? For example, what if your hosts require L2 adjacency due to high availability functions?


If you don’t consider the logical topology needs for your hosts, you might end up isolating hosts in two different logical topologies when they need to be in the same logical topology. The end result could be that the applications will fail to work as intended. One example of this would be a high availibility feature of a host for virtual machines. It's highly likely that you can end up isolating two hosts in different L2 topologies so that in case of a host failure, the failover feature doesn't work. This is difficult to troubleshoot because everything would be working until it fails and it's discovered that the failover feature didn't work. I've seen this happen, and it's not a good day at work.


Remember to distinguish between the physical topology and the logical topology. It’s often discussed when faced with problems associated with load-distribution or high availability features!


Final words


I hope that I did at least manage to encourage you to take a step back and think about the terminology you use when you discuss networks with other individuals. Networks are becoming more and more complex, and the time spent discussing incidents, designs, or implementations is increasing because of this. There is good reason to consider the networking terminology you are using to increase the quality of your discussions!


Last but not least, thank you for reading all the way down here, and I wish you all the best in your networking career!