If you're trying to get solid on BGP and NAT fundamentals in a hands-on, practical way—not just memorizing config commands—this lab is for you.

Objective

The goal of this lab was to set up BGP between three autonomous systems and configure NAT at the edge routers to provide internet access to internal VPCs. Specifically, I wanted to demonstrate the difference between static NAT and dynamic NAT (PAT), and visually confirm NAT translations using Wireshark. The internal LANs were intentionally not advertised in BGP, to force NAT to be the mechanism that allows traffic to reach the internet and return correctly.

Lab Environment and Topology

This was done in EVE-NG using Cisco IOSv routers and VPCS hosts. The setup included four routers:

• EdgeRouter1 (AS 65005) – connects to internal subnet 172.16.10.0/24

• EdgeRouter2 (AS 65010) – connects to internal subnet 172.16.20.0/24

• ISPRouter2 (AS 65005) – serves as a BGP core and handles inter-AS communication

• ISPRouter1 (AS 65015) – simulates the external internet and handles DHCP on the external interface

The VPCs behind EdgeRouter1 and EdgeRouter2 were:

• VPC6 – 172.16.10.2

• VPC7 – 172.16.10.3

• VPC8 – 172.16.20.2

• VPC9 – 172.16.20.3

These were basic simulated endpoints used to generate ICMP traffic for testing NAT.

No configurations were made on the switches—they were just Layer 2 passthroughs. This lab was focused entirely on Layer 3 routing and NAT behavior.

Configuration Summary

BGP Peering with Loopbacks

BGP peering was done between all four routers using Loopback interfaces. This simulated a more stable peering relationship like what you’d expect in production, where physical interfaces may go down but logical peering should persist.

Each router had a Loopback0 interface with a /32 IP address, and static routes were created to make sure those Loopbacks were reachable from their peers. I also used ebgp-multihop and update-source Loopback0 to make sure the sessions could form across multiple hops.

I made a point not to advertise the internal LANs behind EdgeRouter1 and EdgeRouter2. This ensured that the only way for those networks to reach the internet would be through NAT.

Static NAT on EdgeRouter1

I wanted to do a clear, visual demonstration of static NAT using VPC6. I configured a static NAT mapping to translate 172.16.10.2 to a public IP address. That allowed me to show one-to-one translation and confirm that traffic from VPC6 could reach the internet, and that return traffic could find its way back.

ip nat inside source static 172.16.10.2 203.0.113.100

This was then verified using Wireshark, capturing outbound packets from ISPRouter1’s G0/0 interface.

PAT (Dynamic NAT Overload)

Once static NAT was working, I configured PAT on both EdgeRouters so the rest of the VPCs could reach the internet using their respective outside interfaces.

ip access-list extended NAT-LIST
 permit ip 172.16.10.0 0.0.0.255 any

ip nat inside source list NAT-LIST interface GigabitEthernet0/0 overload

The key here was making sure the access list matched the correct internal subnet, the NAT interface roles were set properly (inside vs. outside), and the NAT configuration used the correct overload syntax.

Packet Capture and Verification

To verify that NAT was functioning as expected, I used Wireshark on the G0/0 interface of ISPRouter1. This allowed me to observe ICMP packets as they left the network.

Before configuring NAT, I ran a ping from VPC6 to 8.8.8.8. The packet capture showed that the source IP address was 172.16.10.2—a private address. The ICMP Echo Request went out, but no reply ever came back. That’s expected, because return traffic doesn’t know how to get back to a private RFC 1918 address.

Once static NAT was configured, I repeated the ping. This time, Wireshark showed the source IP had changed to the public NAT address. ICMP Echo Replies came back with no issue.

Same process was repeated after PAT was configured, showing multiple VPCs successfully translating to the router’s public-facing IP.

Troubleshooting Mistakes and Fixes

I don’t edit out mistakes in these labs. They’re part of the process and where the real learning happens. Here’s what I ran into:

Mistake #1: Accidentally Advertised Internal Networks in BGP

Early on, I was deep into BGP config and out of habit, I advertised the internal LANs (172.16.10.0/24 and 172.16.20.0/24) into BGP. I didn’t realize it at first. When I tested NAT by pinging 8.8.8.8 from VPC6, I expected it to fail since NAT hadn’t been configured yet—but it worked.

That stopped me in my tracks.

What I didn’t account for was that BGP had already propagated the internal subnets, so return traffic had a route back. I wasn’t testing NAT—I was just testing basic routing.

To fix it, I went back to the EdgeRouters and removed the BGP advertisements for the internal networks. Then I tested again. This time, the pings failed (as expected), and I could properly demonstrate how NAT was necessary for return traffic. Wireshark confirmed that the packets were going out with the private source IPs and never making it back.

Mistake #2: Used a Subnet Mask Instead of a Wildcard Mask in the ACL

When configuring the NAT ACL for PAT, I mistakenly used a subnet mask (255.255.255.0) instead of a wildcard mask (0.0.0.255). It’s a simple mistake, but it caused a complete failure of NAT.

After applying the configuration, I went back to VPC6 and tried to ping 8.8.8.8 again. Nothing happened. No response, no error—just silence.

At that point, I ran show ip access-list on the router and immediately saw the problem. The ACL wasn’t matching any traffic because the mask was incorrect. Once I corrected it and re-applied the NAT config, everything worked as expected.

These kinds of mistakes are easy to make when you’re in the zone, but catching and fixing them is where the actual learning happens.

Lessons Learned

• Don’t advertise internal NAT networks into BGP if your goal is to demonstrate NAT behavior. Doing so undermines the purpose of NAT by allowing routing to take over.

• Always double-check NAT ACLs. Wildcard masks, not subnet masks.

• Static NAT is useful for fixed one-to-one mappings (e.g., specific servers or hosts that need consistent external access).

• PAT is great for general outbound access and simulates how most home routers work in practice.

• Wireshark is a powerful way to visually confirm that NAT is working. Seeing the source address change before and after NAT helps reinforce what’s happening under the hood.

• Troubleshooting is the best teacher. Making mistakes, recognizing them, and fixing them burns the lesson into memory in a way that reading or watching never could.

Files and Resources

This lab includes full router configurations, a topology screenshot, and the video walkthrough showing everything in action.

• EdgeRouter1.txt

• EdgeRouter2.txt

• ISPRouter1.txt

• ISPRouter2.txt

• Topology Screenshot

• Watch the lab in action on my YouTube channel HERE!

• Find the GitHub Repo for this project including Config Files HERE!

Final Thoughts

I didn’t try to make this perfect. The goal wasn’t a polished demo. The goal was to get hands-on, break things, fix them, and understand what was really happening. This is the kind of lab that builds actual confidence, not just theoretical knowledge.

If you're learning networking, especially BGP and NAT, I highly recommend doing this kind of setup yourself. Don’t just read about it—build it, break it, fix it. That’s where the skills come from.

— Patrick Rivers
Bits of Progress

But what gets overlooked in all that motivational hype are the real challenges you’re going to face along the way.

I’ve been navigating this process myself, shifting from the chemical production and transportation industry to IT and network engineering. And I want to share some of the hardest parts of career transition that rarely get talked about. Because if you’re in the middle of this journey—or thinking about making the leap—knowing what’s ahead can prepare you for the fight.

Let’s get into it.

1. Your Family Responsibilities Dictate Your Options

I started this process in my early 30s. I went back to school around 30 or 31, and now, at 34, I’ve been grinding at this for years. But unlike a fresh college grad, I have real responsibilities—bills to pay, a wife and kids to take care of, and a standard of living I can’t just ignore.

Here’s what that means:

• When you transition to a new field, especially a completely different industry, you often have to take a pay cut to get your foot in the door.

• The size of that pay cut depends on your circumstances—how much flexibility do you have? Can you afford to make less while you gain experience?

• I don’t chase money. I’m doing this because I want to solve interesting problems and do meaningful work. But that doesn’t mean I can work for peanuts. I still have a baseline income I need to maintain.

That’s why entry-level IT jobs were never really an option for me. I tried it once—took a job as a NOC Technician(Network Operations Center Tech), making far less than I needed, thinking I could make up the gap with side gigs.

It didn’t work.

I was driving Uber, doing DoorDash, taking IT gigs on platforms like Field Nation and WorkMarket, but I barely had time to breathe. I couldn’t spend quality time with my family. And worse? I didn’t have the time to learn and develop my skills like I needed to.

That experience made one thing clear: I couldn’t take an entry-level job just to “get my foot in the door.” Instead, I had to be laser-focused on building real, demonstrable skills so I could go straight into a network admin or engineering role.

If you’re in a similar boat—if you have a family, responsibilities, and real financial needs—you have to be more strategic. You need to create your own opportunities, not just wait for someone to give you one.

2. The Competition is Brutal

When you start this journey, it’s easy to think that as long as you work hard, you’ll find an opportunity.

But here’s the truth:

You’re competing with a sea of candidates—young, fresh college grads with degrees, people with years of experience, and others just like you trying to make a transition.

I didn’t take college seriously the first time around. I flunked out of a small community college when I was younger because I wasn’t intentional about my future. By the time I did get serious, I was already behind.

Now, as I compete for mid-level IT jobs, I’m going up against:

• College grads with degrees and internships

• People with several years of IT experience

• IT career changers who might have fewer responsibilities than I do, meaning they can take lower-paying jobs and build experience faster

That means I have to work twice as hard to stand out.

This is why Bits of Progress is so important to me. This isn’t just a content brand—it’s my proof of work. It forces me to:

• Learn deeply and actually master the skills I need

• Document what I’m doing to show my work to potential employers

• Differentiate myself from every other job seeker out there

Someone with a degree and a couple of years of IT experience might be moderately valuable. But for me to compete, I need to be extraordinarily valuable.

That’s the mindset shift you need to have. If you’re up against people with more credentials, you have to bring something else to the table.

3. The Timeline is Always Longer Than You Think

Gurus love to tell you about their fastest success stories.

• “John landed his dream IT job in six months!”

• “Sarah transitioned to cybersecurity in three months!”

They sell you the success story, but they don’t tell you about the blood, sweat, and frustration. They fail to mention the months and years of sacrificed evenings and weekends.

Here’s what no one tells you:

However long you think this is going to take, you might as well double or triple it.

When I started, I thought I’d land a mid-level IT job within a year or two. That was way off.

• I underestimated how much time I’d need to learn real, applicable skills

• I overestimated how much entry-level IT jobs actually paid in my area

• I didn’t realize just how much competition there was for every single role

This journey is longer, harder, and more frustrating than most people expect. But if you stick with it, you will break through.

Why It’s Still Worth It

Despite all of this, I’m still excited about where I’m headed.

Why?

Because this transition isn’t just about getting a better job. It’s about becoming the kind of person who can handle the challenges that come with that job.

If you’re just chasing money, this is going to be miserable. But if you’re chasing work that truly energizes you, the grind is worth it.

Here’s why passion matters:

• It gives you a competitive advantage. If you love the work, you’ll spend extra hours learning, practicing, and honing your skills—while others are watching Netflix.

• It makes the long journey easier. You’ll push through the frustration, rejection, and obstacles because you actually care about the craft.

• It makes you more valuable. Companies need problem solvers, not just people looking for a paycheck. When you love what you do, you naturally become more skilled and sought after.

I don’t go home and waste time. I go home and:

• Build networks.

• Lab new configurations.

• Study cybersecurity principles.

• Sharpen my problem-solving skills.

Not because I have to. Because I want to.

And that’s why I’m confident that, in the long run, I’ll win.

Final Thoughts

If you’re thinking about changing careers, here’s what I want you to take away from this:

1. Be realistic about your financial situation. If you have a family, you can’t afford to take just any job—plan accordingly.

2. Understand the competition. You need to differentiate yourself if you want to stand out.

3. Expect it to take longer than you think. If you assume it’ll be a quick transition, you’ll get discouraged too soon.

This journey isn’t easy. But it’s worth it.

Because at the end of the day, the real reward isn’t just a better job. It’s becoming the person capable of earning that job.

So the question is—are you willing to go through the process?

This lab simulates an enterprise network peering with two ISP routers via BGP, while utilizing a multi-layered, multi-area OSPF topology for internal routing. The goal of this setup is to explore BGP peering, OSPF multi-area configuration, route redistribution, VLAN segmentation, DHCP services, and external DNS integration.

This is part of my Bits of Progress journey, where I document my hands-on networking experience. Rather than a step-by-step tutorial, this blog post presents my thought process, configurations, and the learning experience gained from building this lab.

Lab Topology Overview

Key Components:

1. ISP Routers (BGP AS 65010 & 65020) – Simulate two separate ISPs peering with the enterprise network.

2. Core Routers (BGP AS 65001, OSPF Backbone Area 0) – Serve as the backbone of the enterprise, interconnecting various OSPF areas and managing route redistribution.

3. Access Routers (OSPF Area 1, DHCP Services) – Provide connectivity to end devices in separate VLANs.

4. Access Switches (Layer 2 VLAN Segmentation) – Facilitate communication between clients, servers, and IoT devices.

5. ISP Exchange Router (BGP AS 65050) – Acts as an intermediary router simulating upstream internet access.

Configuration Breakdown

1. BGP Peering & Route Redistribution

The core routers establish BGP sessions with the ISP routers while also redistributing internal OSPF routes into BGP.

CoreRouter1 BGP Configuration:

router bgp 65001
 bgp log-neighbor-changes
 aggregate-address 192.168.0.0 255.255.0.0 summary-only
 aggregate-address 10.0.0.0 255.0.0.0 summary-only
 redistribute ospf 1 match internal external 1 external 2
 neighbor 172.16.2.1 remote-as 65010

• Redistributes OSPF routes into BGP, allowing the enterprise network to advertise summarized internal networks to the ISPs.

• Uses aggregate addressing to reduce the number of advertised routes.

ISPRouter1 & ISPRouter2 BGP Configuration:

router bgp 65010
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.252
 network 172.16.2.0 mask 255.255.255.252
 neighbor 172.16.1.2 remote-as 65020
 neighbor 172.16.2.2 remote-as 65001
 neighbor 172.16.2.2 route-map ADVERTISE-DEFAULT-ROUTE out
 neighbor 172.16.4.1 remote-as 65050

router bgp 65020
 bgp log-neighbor-changes
 network 172.16.3.0 mask 255.255.255.252
 network 172.16.5.0 mask 255.255.255.252
 neighbor 172.16.1.1 remote-as 65010
 neighbor 172.16.3.2 remote-as 65001
 neighbor 172.16.3.2 route-map ADVERTISE-DEFAULT-ONLY out
 neighbor 172.16.5.1 remote-as 65050

• Both ISPs advertise a default route to the enterprise network.

• ISPRouter2 (AS 65020) also peers with ISPRouter1 (AS 65010), forming a redundant external connection.

2. OSPF Multi-Area Design

The enterprise network follows a structured OSPF design with multiple areas for efficient routing and scalability.

CoreRouter1 OSPF Configuration:

router ospf 1
 router-id 1.1.1.1
 network 10.1.0.0 0.0.0.3 area 0
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.2.0 0.0.0.3 area 0
 default-information originate metric-type 1

• OSPF Backbone (Area 0) connects all access routers.

• Advertises the default route to propagate internet access throughout the network.

AccessRouter1 OSPF Configuration:

router ospf 1
 router-id 2.2.1.1
 network 192.168.10.0 0.0.0.255 area 1
 network 192.168.20.0 0.0.0.255 area 1
 network 192.168.30.0 0.0.0.255 area 1

• Belongs to Area 1 and connects local VLANs to the enterprise network.

• Establishes an OSPF adjacency with CoreRouter1.

3. VLANs, Subnets, and DHCP

Each Access Router provides DHCP services for clients, servers, and IoT devices.

AccessRouter1 DHCP Configuration:

ip dhcp pool CLIENTS1
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 8.8.8.8

• Assigns IPs dynamically to devices in VLAN 10 (Clients).

• Uses Google’s DNS (8.8.8.8) for external name resolution.

Testing & Validation

1. BGP Neighbor Verification

Checking BGP peers from CoreRouter1:

CoreRouter1# show ip bgp summary

• Ensures BGP sessions are established with ISP routers.

2. OSPF Neighbor Verification

Checking OSPF neighbors on AccessRouter1:

AccessRouter1# show ip ospf neighbor

• Confirms OSPF adjacencies with CoreRouter1.

3. Route Summarization Check

Checking advertised routes on ISP Routers:

ISPRouter1# show ip bgp

• Confirms that only summarized routes are advertised to the ISPs.

Conclusion

This lab was a great learning experience in BGP peering, OSPF multi-area routing, and network services like VLANs and DHCP. By configuring an ISP environment and enterprise network, I gained hands-on insight into real-world networking scenarios.

This is just one step in my Bits of Progress journey. Stay tuned for more labs and technical deep dives.

📺 Watch the Lab in Action: https://youtu.be/cb68HlbxOk8
📂 Download Config Files: https://github.com/PRivers251/RoutingLab_BGP_OSPF_3-6-25