11th October 2025

So we're at part 2 of this wonderful journey... and I've discovered more quirks, had fun with OSPF (Open Shortest Path First) and have even started a debate. My inventory also grew again... I bought two more Cisco routers (oh d.ear...) Which meant I rebuilt the lab in a more permanent setup and even added some configurations that will help benefit future learnings. Let's dive into that. Remember, I'm not a qualified network engineer. There's going to be minor errors and I may even revise this page later.

Okay Maxine what did you get now?

A Cisco C899G-LTE-GA which will actually be a permanent addition to the production setup once I'm in a position to move it out of the lab (barring yet another Cisco Router OR I get to the point where it's no longer needed and a Mikrotik goes back in it's place). And we also got a Cisco 2911... WITH A LOT OF EHWIC SERIAL EXPANSION MODULES for some reason (that's just what was there, it was included in a box with other Cisco equipment). Not like I'm going to use those Serial interfaces (you can use them as WAN interfaces and that was the intended usage, each serial does a whopping 8mbps per port synchronous).

Why did you get all of that?

Configuring a Cisco switch is not the same as configuring a Cisco router. Not by a long shot. More so the 3560 immediately outlived it's usefulness and I absolutely needed a router. So I spent $135 to acqure the lot. The C899G-LTE is actually legitimately useful as we can use that in the production network AS a WAN back up in case my UFB connection finally fails (no fault in the 6 years I've had access to Fibre... we will continue counting those years hopefully). It also happily does a gig over wired routing with some basic NAT and ACL so I'm not missing out with performance. The Cisco 2911 was because it was dead cheap, but also it has a ton of expansion so the 2911 could replace the C899G potentially(but the thing is loud, see the embedded video).

VIDEO HERE

Okay so what does the lab look like right now?

Glad you asked! Here's a photo of it.

You'll also notice there's a Raspberry Pi (single board computer) in a 3D printed case. That's basically a terminal server so it's much easier to access the switch and routers (this totally did not cause an outage again... I promise... and I need to buy more rollover cables so I can stop unplugging and reconnecting the RJ45 connector).

Why did you make this change?

Old lab setup was clunky, it wasn't going to be able to expand and it makes labbing complex topics (such as OSPF and BGP) much easier, which also means I can explore beyond the content I'm reading/watching and try my own scenarios (which is only a good thing, the more you practice different scenarios and topics, the better you will do).

Has the lab network diagram changed?

Yup!

This was it's last iteration...

Now it looks something like this.

So the diagram got more complex, but it has more room to grow, to scale and more importantly.. I can do everything in the CCNA, almost any CCNP topics and completely cover the MTCRE (with multi vendor experience as a bonus). I am hoping this is the last change I make (apart from putting this into a rack cabinet... maybe that's an upgrade at another time).

Okay so what is OSPF?

OSPF or Open Shortest Path First is exactly that. It's a dynamic routing protocol that assists with installing routes automatically to other adjacent devices(routers, layer 3 switches, firewalls or even devices themselves) to provide the most open shortest path. Let's take this image that has static routes.

The image description of this is very simple, if I want to talk to any devices on 10.102.1.0/24 I need to go through 10.201.50.2 first over 10.99.3.2. But the problem is that I have to install this route everywhere... ensure it matches on both ends(and with their specific interfaces) and then ensure there's connectivity... what if I want to automate this? That's where OSPF comes into play.

The way OSPF works in the most simplest of ways possible. A desiginated router is going to send a hello to the router it's adjancent to(if that's also configured for OSPF) and it's going to exchange OSPF data in the form of Link Statement Advertisements with it's routing table information. This means I don't need to put in my static routes, however we still need to configure OSPF the right way in order to steer routing the way we want it and we do that by cost and/or by distance (this depends on the vendor, sometimes this isn't calulacted).

This kind of automation is heavily used in enterprise/corporate deployments, ISPs and even datacenters(and is also combined with BGP or Border Gateway Protocol and that is going to get it's own blog page). This does come with it's own complexity and that is the routes we are advertising must be valid on the interfaces otherwise we could be advertising a dead route and our traffic will just get dropped(because there's no where to go).

Okay so what are we advertising?

Let's go back to that previous picture of the network diagram to make a map.

So we have these regions that need their IP subnets advertised as "hey I have these addresses, I know how to get to them" distributed between each router and the core. We have every client on each end point interface (so think of end point interfaces as our hypothetical customers, these IPs are 10.101.0.0/23 for Jafa, 10.102.0.0/23 for Welly, 10.103.0.0/23 for Chur Chur in our map), we also have the routers themselves and their own links to each other, and then our links to the core (and production). Here's a basic Cisco configuration of OSPF from the core side.

router ospf 1
 router-id 1.1.1.1
 network 10.70.20.0 0.0.0.255 area 0
 network 10.99.0.0 0.0.7.255 area 0
 network 10.99.9.0 0.0.0.255 area 1
!  

You'll note that we've omitted the end point customers IPs and that's because we have OSPF setup on those regional routers who will provide information about those routes to us. We know our routers sit on 10.99.9.0/24 network so we only need to know that. You'll also notice they're in area 1 and not area 0 (ideally you'd create an area for each region but for the sake of keeping things simple, we just have two areas to deal with). The concept of having more than one area is known as inter-area routing. Of course you can use areas for more than just regions, you can use areas however you like but normally areas are defined by where they are, what are they serving and so forth. inter-area networks can serve us their routing information providing those networks are also participating in OSPF. The beauty of OSPF is that it's dynamic so if one route goes down for any reason, if we have another router advertising it knows how to get there, then OSPF will update and re-route traffic after it has expired the dead routing information.

So how do we set this up?

So first of all. Read the manual. There are a lot of ways to do this, but also equal amounts to get this wrong. You should also understand your own networks and ensure your routes are updating with OSPF routes over your static routes(you can still use static routes to steer specific traffic away but you can also do the same with OSPF and you should try and influence OSPF through cost weighting to steer it the way you want your traffic to go through).

Let's go back to the configuration on the core router (which is the C899G). From the core:

router ospf 1
 router-id 1.1.1.1
 network 10.70.20.0 0.0.0.255 area 0
 network 10.99.0.0 0.0.7.255 area 0
 network 10.99.9.0 0.0.0.255 area 1
!  

There's 5 key things we need to configure in OSPF.

1. router ospf 1 is the process ID to start OSPF. You can have multiple OSPF processes on every router.
2. router-id is the ID of the router that's broadcasting these networks.
3. Instead of subnet masks we use wildcard masks which are the inverse of subnet masks, so for a /24 network if you used a subnet mask of 255.255.255.0 to define that... you'd actually use 0.0.0.255.
4. Each network should have IP addresses on the interfaces. You'll note that in the configuration above 10.99.9.0 is the network for the regional routers in my network map.
5. Your areas do matter and if you're doing multi vendor setup know that area 0 in Cisco is 0.0.0.0 in Mikrotik. area 2 in Cisco is 0.0.0.2 in Mikrotik. I cannot speak for other vendors.

To replicate the setup that I have (Production Mikrotik as our backbone area 0 > C899G Cisco Core > Regional Routers in area 1) you need to go into configure terminal or shortened to conf t in our Cisco C899G. We can then type the following commands in the above configuration from the core. We want to advertise 10.99.9.0 as that's where our regional routers are, but we also want to advertise ourselves (10.99.0.0) because we want our interface going back to the production network) to perform in OSPF(there are a few types of advertisements but it's beyond the scope of this post, we want a simple configuration that just works).

Mikrotik's configuration is a little different.

On the production side, I have spun up a single ospf-instance using version 2 and a router-id of 0.1.1.1

You'll next configure an area. Area 0 is considered the backbone network in OSPF, which is true in our lab deployment. The lab gets it's internet access via the production router and it is the backbone so we'll configure it like this using our single ospf-instance

Now we can configure our interface template from our production router. I've got a few networks I want the lab network to know but I also have an interface that has an IP that matches the other interface on the C899G so we want to include that as well.

Now let's look at the regional routers' configuration. I'll pick out the Christchurch router for fun. I want to advertise ALL of these networks. Especially the customer pools. So we'll repeat our work on the production router with a couple of tweaks. We will instead use router-id 1.1.1.4 to easily spot where those networks are coming from. And because our regional router is in Area 1 we want to configure our area ID as 0.0.0.1 instead. And then we go hog wild by adding in all of our networks into our single interface template.

And the result? My production router knows where to get to the 10.103.0.0/23 network because the core network also knows about it. So how does the core know about it?

gekkoukan-core#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.99.1.1 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 12 subnets, 5 masks
O        10.1.150.0/24 [110/2] via 10.99.1.1, 4d22h, GigabitEthernet8.99
O        10.101.0.0/23 [110/2] via 10.99.9.2, 00:30:28, Vlan111
O        10.103.0.0/23 [110/1] via 10.99.9.4, 00:07:58, Vlan111
O        10.199.0.0/23 [110/1] via 10.99.9.4, 00:07:58, Vlan111

Yup, it knows because the Christchurch regional router told the core about that network. That's how awesome OSPF is.

Are we done? No. There is a lot of tidying up, lots of explanations, reasons, decisions that I'm leaving out of this blog post and that's because if you want a basic grasp then this post was for you.

So what's next?

I'm heading over to Auckland next weekend to go see the folks at DataVault and Vetta Online, meet more industry peers and even catch up with some friends as well. Probably gonna blog about it but also may just make some Bluesky posts.

👋