21 September 2025 (My Cisco Journey part 1)

So you're reading this and if you know me very well... I love Mikrotik and I am also MTCNA certified... so how the hell did this happen?

This is the greatest mistake of all time...
Oh god help me.

How this happened is simple. At my full time employment, we get to choose what we learned, so being the network and infrastructure enthusiast that I am... I went full steam ahead on my CCNA certificate or the Cisco Certified Network Associate certificate. Here is exactly what you learn when doing the CCNA.

You're gonna learn today.

The MTCNA covers about 50% of the CCNA, so if you've done the MTCNA... you're about half way there with the CCNA. There are some catches however:

  • MTCNA teaches you a mix of CLI and Winbox, whilst CCNA is PURELY CLI based.
  • MTCNA does not teach you STP (Spanning Tree Protocol), the MTCSWE does. CCNA you are taught this and knowing STP is incredibly important, especially if you're running a multi vendor lab.
  • MTCNA does not teach you VLANs, the MTCSWE does and knowing what VLANs are, trunking, inter-VLAN routing and the reason to use VLANs are, is also very important. CCNA teaches you this.

Does this mean the MTCNA is not worth it? No it is. The objectives of each course is different. CCNA is meant to ready you to throw you into the deep end. MTCNA is a taste test and teaches you to explore.

You bought a lot of gear. What are you doing with it?

I bought that list of Cisco equipment for a few reasons:

  1. One of them was going to be an upgrade for my 1gbps network.
  2. The other two is to build and expand the network lab(where we have fun, experiment, learn, try new things without breaking the production network).
  3. Allows me to understand how each vendor does it and figure out their quirks and secrets(and there's a LOT of quirks and secrets).

Explain to me what this gear is?

Let's start with the Cisco Catalyst 2960X 24PD-L. This replaced my Dell X1018 (which was a hunk of shit). It's a 24 port (it's in the name!) 1gbps RJ45 switch with PoE and 2 10gbps SFP+ which you can use as uplinks. Now for those who just struggled reading this, let's break it down.

24 of the ports on the switch are 1 gigabit, Power over Ethernet enabled over RJ45, your common connector on your router or modem. In Cisco's IOS CLI. They show up like this.

Cisco is really cool when it comes to labelling ports. They do it by the speed of the port

So you can hook up a computer to this and it will run at up to 1 gigabit. But... I also mentioned they were PoE or Power over Ethernet... what the heck is that??? Power over Ethernet is a beautiful messy standard that allows you to power devices over ethernet, a network cable! You'll see this most commonly with Wireless Access Points, Cameras, some IoT devices like smart door bells, sensors and you can even power computers over it like a Raspberry Pi (PoE HAT not included). This was a significant upgrade for me but also taught me a few things that I should have fixed up in the production network(more on that later).

So what's running in the lab? We have a Cisco Catalyst 2960S 48LPS-L and a Catalyst 3560 8-PC-S. The 2960S has 48 RJ45 gigabit ethernet ports that do 1gbps, and 4 SFP 1gbps ports for fibre connectivity. The 3560 has 8 fast ethernet ports and a single 1 gigabit interface that can be used with RJ45 or SFP. You're also probably wondering what the hell fast ethernet is? Fast ethernet was the standard before Gigabit ethernet... it's max throughput speed is 100mbps. which is slower than gigabit ethernet. That's how old some of this gear is, we have standards going back to when 100mbps was all you needed.

Now let's talk more about the lab setup.

The lab network.

In my house there are two locations.These two locations are called Yakushima and Gekkoukan. Yaksuhima is the production side. Gekkoukan is the lab network. I can configure all of the Cisco equipment using what we would call in the IT world "jump boxes."

What the heck is a jump box?

A jump box is a device you remote into, to control and manipulate other devices that are only to be managed from a single device, usually using credentials to get onto the jump box in the first place. Since Cisco loves using serial for their console access, I use a package called tio to access these Cisco switches.

yukari@Tanaka-JumpBox:~$ tio -b 9600 /dev/ttyUSB0
[12:54:56.203] tio 3.9
[12:54:56.203] Press ctrl-t q to quit
[12:54:56.205] Connected to /dev/ttyUSB0

yakushima-1g>

Now your jump box should be able to be reached and treated as if it's an out of band device, incase you break your network. If you don't do this and you make a breaking change... you're gonna have to get physical access to it and revert your change (always have a rollback plan).

Okay, so with all of this gear, what did you actually learn?

I learned a lot... and fixed a lot about my production network along with it. Let's start with VLANs and trunks (this isn't Dragonball Z, so not the character Trunks).

What is a VLAN?

A VLAN is a Virtual Local Area Network, it is also a logical network. It is a defined standard (802.1Q) that packs 4 extra bytes onto every frame and depending on how you configure it, you can use it to separate your networks by floors, departments, isolating particular devices from talking to another network and is something everyone should know (it is not a security feature, you can still discover frames sent on different VLAN headers if you have a device doing packet capturing on the interface and/or you have physical access and you can do port mirroring).

Here are some rules you should know about VLANs.

  • Anything not tagged with a VLAN, VLAN aware devices will still tag that traffic as 1.
  • There are certain VLAN tagging IDs you can't use, such as 0 or 4095.
  • If you have some older Cisco equipment, you can see some other VLANs reserved for older networks which you cannot use.
Token rings baby!
  • You need a router or a very good layer 3 switch to route traffic from one VLAN to another. If you need a router, you'll need to know about trunks, and the concept of "Router On A Stick" or ROAS.

What is a trunk?

A trunk is a mode on a switch where it's told to expect multiple VLANs being switched through it. If you had only a single VLAN and a router, you don't need a trunk. But if you have multiple VLANs and a single router, then you need a trunk.

Let's look at an example of both, and we'll start with VLANs and routing.

This map is going to confuse you at first.

Now, we need to break this map down to explain everything but first we should set the stage and the context.

This is the Gekkoukan lab. This has a mixture of Mikrotik and Cisco gear. The routers are Mikrotik and the switches are Cisco. Our IP addresses for this network are as follows:

  • 10.99.1.1/21 (yes I really did a /21 so I have a IP range of 10.99.0.0 to 10.99.7.255, that's huge!) for the core (this is connected back to the production network using a VLAN of 99, I got 99 problems but a VLAN ain't one). The "core" is a Mikrotik hAP AC2 and for a few watts... it has some serious grunt.
  • Each router connected to the core, also sits in the 10.99.x.x with a VLAN of 99, however Router 1 is 10.99.2.2 and Router 2 is 10.99.3.2.
  • Each router also has a separate VLAN and DHCP server, and each router is assigned certain ports on the Cisco switch with it's matching VLAN. So you can't just plug into the router... you need to know the group of ports on the switch (you can make VLANs completely transparent so the user doesn't need to set a VLAN, if they just plug into a switch, the switch will add the VLAN tag on top of their frame. See the configuration below.
Access ports are only 1 VLAN, Trunks are multiple. Devices do not need to set the VLAN, the switch does it for you transparently.

How do we route this?

Indiana Jones would want a map here...

Now let's explain this map a little more. We have Router 1 and it has end points on VLAN 101 and a subnet of 10.101.1.0/24 (that's 254 usable addresses). Router 2 does not know about Router 1 and it's devices or VLAN 102 and vice versa with Router 1 to Router 2. So how do we get there? We get there with routing. So in that map we have VLAN 101 and VLAN 102. We also have a special IP subnet of 10.250.1.0/28. This acts as our special link to route between each others, without needing to talk to the core(why waste it's resources, when we can link each router together? More on this later.).

This is a routing table and this was taken from Router 2. With this static route in place, it knows how to talk to Router 1 and it's devices. Here is a MTR that will show you how it's taking that route.

MTR should be in your networking toolkit.

We can see that 10.102.1.252 wants to talk to 10.101.1.251, so it sends it's packet to the router, now the router can see the intended destination address in it's packet, so it goes "hey I think know where to send this, I'm gonna talk to 10.201.50.1 and see if it knows where it should go," and it will forward that packet through the route it knows and then 10.201.50.1 goes, "hey this is for 10.101.1.251, I think I know where to send this packet," and because 10.201.50.1 is Router 1, Router 1 knows where 10.101.1.251 is and it sends the packet to 10.101.1.251 and it replies to the ping.

Understanding static routes is important because you can create failover routes so your routers will always know where to send that traffic... now let's look back at that routing table.

Notice how I put the same destination address twice but I'm telling it to use two different addresses? Let's expand that image a little more.

The route with the distance of 2 is not prioritized because it has a longer distance, it is preferred to take the route with the lowest amount of distance

Let's now learn about using distance to create a failover. You saw in the MTR that all traffic is going to 10.201.50.1 if it wants to talk to anyone in the 10.101.1.0/24 network on Router 1... it's distance is set to 1 so it's the first route in line. But what if that link just goes bang? Well without that second route to 10.99.2.2... It's not gonna go anywhere, it's going to drop the packet at Router 2 because Router 2 has no available routes. 10.99.2.2 goes to the core... and the core knows how to talk to Router 1. As an experiment, I'm going to kill the link between each router.

USI = Unreachable, Static, Inactive. So now it fall to the route that has a distance of two and is now Active, Static.

Now Router 2 says, "hey my link to Router 1 via 10.201.50.1 is unreachable, I'm going to use the next available route, which is 10.99.2.2." This route has a distance of 2 How does our MTR look now?

This is a very very primitive version of how a route to an IP/website can just change like that, and you can still get to it. Core is the new hop.

We can still talk to it!

And we can SSH into it! Neat! So now you know how we can route between VLANs using routers and configure static routes to tell routers how to route this traffic, and using distance to create a failover route.

Now let's talk about trunks and the many quirks I found with trunks...

I probably should have prefaced this blog post with a massive disclaimer. I am not an expert in networks, I just happen to be studying it and I came in here with a lot of experience and fundamentals before starting my journey into getting my certificates.

So let's start with what is a trunk? A trunk is simple. A trunk is a mode where you tell a port on a switch or a router "hey expect multiple VLANs coming through your port." Now what I didn't explain earlier was what an access port is, and an access port is a type of mode for a port to expect 1 VLAN only. You can define this to be whatever the hell you want, but a trunk is a mode where you're expecting multiple VLANs to originate from this port. This is where the concept of Router On A Stick comes into play. So what's a Router On A Stick? It's one router, that has one physical connection, to multiple logical networks (VLANs!). So for example... say you have the HR department on VLAN 101 but you have the customer service department on VLAN 102 and your router is not advanced enough to know how to route between those VLANs. You need a trunk and a Router, and you can use a Router On A Stick, to route multiple VLANs back into the switch. Let's crack out draw.io and put this into a picture.

Now our switch, is aware of VLAN 101 and VLAN 102, it's ports are setup but it's not advanced enough to know how to route this, so it needs to talk to a router. So we configure our router to be a trunk and expect VLAN 101 and 102.

So when Server 2 in the customer service department needs to talk to Server 1 in the HR department, it's going to send it's packet to the switch, the switch will see it's got a VLAN ID of 102, it's going to send that packet through the trunk, the router is going to go, "hey I know where Server 1, it's on VLAN 101 and I know which port to use," and it's going to send that packet down the same port that's configured as a trunk with VLAN 101, the switch will then switch that packet to VLAN 101 and Server 1 will receive it.

and now the quirks with trunks and why I had to fix my production network...

So I mentioned that the Cisco 2960X replaced my Dell X1018... well I was already experimenting with VLANs, however Dell does VLANs very differently compared to Cisco. Originally I had 2 access ports, one for untagged traffic, another tagged with 99 for the lab. When I brough the 2960X in and I configured it the same... the lab had no connectivity... So I decided to simplify it... I trunked one port and I removed my second access port. Suddenly it worked! Lab network was back and my production network could talk to my lab network. So how did I do this?

On the Cisco 2960X. I told port 20 to be a trunk, and expect VLAN 1 and 99.

interface GigabitEthernet1/0/20
 switchport trunk allowed vlan 1,99
 switchport mode trunk
!

On my Mikrotik router in the production network, I took my existing bridge, put the port I'm using to upstream my traffic to the 2960X in that bridge and I told the bridge, "hey expect untagged frames and tagged frames."

How you actually trunk in Mikrotik...

So when the Mikrotik saw frames tagged for 99, it knew how to route those. And when it saw VLAN 1 (also untagged), it knew how to route those as well.

Production can talk to the lab!

just because you tag your bridge as vlan aware in proxmox... doesn't mean Cisco will treat it as a trunk...

Now this part of the blog is going to cause either heads to turn or I'm going to get told "you're doing it wrong." As much as I welcome feedback... this is what I had to do to get proxmox to talk to VLAN tagged networks as a trunk... Remember how I said when you tell a port on a switch to be a trunk it should expect multiple VLAN frames?

interface GigabitEthernet1/0/11
 description untagged range
 switchport mode trunk
!

This should work right when you check this check box in Proxmox and restart the networking stack in Proxmox?

That misleading checkbox...

Oh man was I wrong...

gekkoukan-lab-sw1#show int trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/24    on               802.1q         trunking      1
Gi1/0/36    on               802.1q         trunking      1
Gi1/0/48    on               802.1q         trunking      1

Wait why is Gig 11 not showing up as a trunk? Turns out... I needed to define the VLAN IDs of the tagged VLANs I was going to use but also include VLAN 1.

root@yakushima:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.69.42
        gateway 192.168.69.1
        netmask 255.255.255.0
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 1 101 102 199

Notice how I've specified VLAN 1, 101, 102 and 199(199 is a completely different network, more on that in a later blog)? Yeah... I had to essentially make the bridge trunk itself. Just checking VLAN aware was not enough. Once I had that, I could setup VMs across multiple VLANs, all off the one network interface.

VMs on different VLANs!

1 Proxmox node, multiple VMs on different networks. Neat! Oh and Gig 11 is certainly now a trunk.

gekkoukan-lab-sw1#show int trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/11    on               802.1q         trunking      1
Gi1/0/24    on               802.1q         trunking      1
Gi1/0/36    on               802.1q         trunking      1
Gi1/0/48    on               802.1q         trunking      1

So what did you learn?

I learned:

  • I was doing VLANs all wrong and I fixed it.
  • Vendors do things differently. Google people's experiences, research, RTM (READ THE MANUAL).
  • Don't assume a trunk IS a trunk, double check, triple check, test it.
  • VLANs are great for segmentation, but it's not a security feature.
  • Jump boxes are underrated.
  • Draw.io is fantastic at visualizing a network before you implement it.
  • Static routes, when done right, are brilliant.
  • If you have critical services and you didn't plan a maintenance period... You're going to piss off everyone who uses it.
Oops! Technically failed my SLA of 98%

So that's what's going on for me right now... and now I have a Cisco Router coming as I dive into OSPF (Open Shortest Path First), BGP (Border Gateway Protocol) and more advanced routing. I'm also going to do a write up on how I got that working with Mikrotik hardware as well(and I expect to find more quirks here).

Feel free to give me feedback on this blog on my bluesky post, and if you made it all the way to the end... you now know a lot more than you wanted to know. 😉

edit: I added image captions, fixed a few weird sentences and fixed some broken code blocks.