Network Fundamentals Lab 1

[maj.peerenboom (Michael Peerenboom)]

I realize that it’s not what the requirements are, but in my opinion it is good to mention that it is not a good practice. It’s not recommended to use dynamic trunking and its not recommend
to use routing on access switches in a campus network. It makes it more complicated and its prone to more errors. You should not want to teach the wrong practices. That’s the reason I brought this up.

Best regards,
Michael

[lagapidis (Lazarus Agapidis)]

Hello Michael

@maj.peerenboom

Let me start by saying that I’m very satisfied with the Networklessons website. I haven’t found a better website yet. This one truly stands out.

Thanks so much for your kind words. We do our best here, and the feedback we get from users like you helps us to improve continually, so the time you spend in this thread is appreciated!

@maj.peerenboom

I found it confusing having all the information listed one below the other. I was constantly scrolling. That’s why I decided to separate the two and create two labs.

Yes, I understand, it’s not always easy when doing the lab from a long document on a web page on the screen. Separating it into two different labs is a solution, and for learning, that’s fine. Keep in mind that implementing both IPv4 and IPv6 in the same lab is essential as well, as having both protocols running on the same topology is a common real-world scenario. So gaining experience in that is also crucial.

@maj.peerenboom

Furthermore, I struggled for a long time with getting the host PCs to obtain an IP address via DHCP.

In section 4.5.2 DHCP config for the hosts is explained, and is achieved using an IP helper address. OSPF is applied to the ASWs only for the purpose of advertising the loopback and the management SVI, not for the hosts themselves. OSPF is necessary on the DSWs to make the IP helper address reachable.

I see now that the final configs don’t have that OSPF configuration on the ASWs, which I believe is one of the issues that you pointed out, so I will let Rene know to make that correction. In the lab, however, Rene does include the management VLAN and the OSPF configuration for the ASWs as he suggests in this post.

@maj.peerenboom

Furthermore, I find the choice of OSPFV3 a bit unfortunate in combination with IPV4. It makes things a bit more unclear. CCNA (as far as I know) doesn’t mention OSPFV3 in combination with IPV4.

Again, I understand the difficulties that this can bring, but if you have a topology with both IPv4 and IPv6, then you need a protocol to serve them both. You can run OSPFv2 for IPv4 and OSPFv3 for IPv6, or you can run OSPFv3 for both. Learning to implement these technologies together is always helpful to enrich your skillset. Although Cisco doesn’t explicitly mention this in its blueprint, it is always possible that they will add related info, so gaining experience in these kinds of scenarios always helpful.

@maj.peerenboom

Why is it written “show ipv6 ospf neighbor” here? The official documentation describes it differently

Both the show ipv6 ospf neighbor and show ospfv3 neighbor commands are correct, they just behave a bit differently.

The show ipv6 ospf neighbor command displays the IPv6 OSPFv3 adjacencies only. This is an older command, but still valid, from the time when OSPFv3 was IPv6 only. In order to see all address families (IPv4 and IPv6) the show ospfv3 neighbor command is preferred. Since we have both IPv4 and IPv6 addresses being shared in the lab, it may be worth using the show ospfv3 neighbor command. I will make the suggestion to Rene to consider adding that.

@maj.peerenboom

My conclusion, therefore, is that I find the configurations and solutions offered for the ASW switches particularly unclear.

I will let Rene know to look over your suggestions and consider any necessary changes to clarify them.

We really appreciate the time you spent sharing these things with us. Your feedback is invaluable!

I hope this has been helpful!

Laz

[ReneMolenaar]

Hi Michael,

Thanks for sharing all of this. Let me jump in on a couple of things.

@maj.peerenboom

First, the combination of IPV4 and IPV6 in one lab. I’ve separated both labs and the information that is all on one webpage. So, I actually have two labs: an IPV4 and an IPV6 lab. I found it confusing having all the information listed one below the other. I was constantly scrolling. That’s why I decided to separate the two and create two labs.

When I created this lab, the tasks are in order of L2 > L3 > Routing > All other items, and for both IPv4 and IPv6. When you configure IP addressing, I added both IPv4+IPv6.

It could be easier to start with the IPv4 tasks, get them working, and then get back and do all the IPv6 tasks. There is some “context switching” now between IPv4 and IPv6.

@maj.peerenboom

I do not agree with your statement that access
switches should have ospf statements on the management vlan 40. In our company this is not allowed. We call it OOB (out of band) and they are strictly separated from the production network.

This is a thing of in-band vs out-of-band (OOB) management. Having OOB has the advantage that your management traffic is completely separated from the production network. If you mess up something, you won’t have issues that affect the production network or lock yourself out. It might also be required for security reasons. You’ll need additional equipment for this management network. In-band management is effective because you run it on your network, which is already up and running, with the downside that you can affect your production network. If you mess up, you can lock yourself out.

@maj.peerenboom

Access switches should not participate in OSPF areas. They should be stricttly L2 switches. Routing should be done on the distribution layer and above.

This is a design question. On the access layer, you can do L2 or L3. If you use L2 on the access layer, you’ll be able to span VLANs over multiple access layer switches. You’ll have to deal with STP and gateway redundancy protocols like HSRP/VRRP on the distribution layer switches.

You can also run L3 on the access layer switches. VLANs will be local to a single access layer switch, but you won’t need HSRP/VRRP anymore, and you’ll be able to use all links for forwarding because of ECMP.

I’ll go through the lab again to see what I can improve. I think I did something with OSPF on the access layer switches because there’s a chicken-and-egg scenario where if you don’t use routing, the access layer switches require a default gateway, which doesn’t work yet because you would configure HSRP/VRRP on the distribution layer switches. For labs like these I prefer to create tasks where you can go through from A > Z where one task builds on another.

Rene

[CorwynJohnson (Corwyn J)]

Hello, I’m trying to configure the Network Fundamentals Lab but I have a question. What image are you using for the switches?

[lagapidis (Lazarus Agapidis)]

Hello Corwyn

The lab images are shown in the Solution section here.

Specifically:

• Switches: Cisco IOS Software, vios_l2 Software (vios_l2-ADVENTERPRISEK9-M), Experimental Version 15.2(20200924:215240) [sweickge-sep24-2020-l2iol-release 135]
• Routers: Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M6, RELEASE SOFTWARE (fc1)

I hope this has been helpful!

Laz

[jsh3323 (James Harris)]

I’m not currently working. To keep my skills fresh I’m going through this and the other labs available. There are some perceived challenges with the lab. Mostly around wording, order, and design preferences. However, this is to be expected. We don’t all build networks, or labs, the same way.

I also made some assumptions and/or misread things in my haste. For example, I just assumed the SVIs would reside on the core and we’d run L2 all the way down to the access layer. What i realize now is that back in the days before we moved to collapsed cores and spine/leaf we used to place the SVIs at the distribution layer. In hindsight I should’ve read the lab end-to-end before starting it. I should’ve also read the comments.

These mistakes are learning, or in my case, re-learning opportunities. The best Engineers can admit their mistakes, adapt, and learn from them. There’s also a lot to be said about putting yourself in the thought process of others. Asking why someone did something the way they did also presents learning opportunities

Thanks for these labs. Great Job!

[lagapidis (Lazarus Agapidis)]

Hello James

Thanks so much for your comments. It’s always helpful to get into the heads of those engineers who are going over the material on the site.

The way things are written and expressed is always an issue when it comes to networking and determining the requirements, and it’s something we need to address and deal with. As you probably already have experience in this, the decision-makers and the money-handlers are often not networking professionals, and they too must understand, at a higher level, what is being implemented, and why it is necessary, and that is often the greatest challenge of all! As you suggest, it’s a good exercise to use this lab for understanding the initial requirements as well.

Concerning the SVIs, you’ve identified one of the most important architectural concepts in campus network design, which is, where to place SVIs and where to draw the Layer 2/Layer 3 boundary. More about this can be found at this lesson. Your assumption about SVIs at the core is just a different, equally valid design model, depending on the specific situation. But it does stress how important it is to read the requirements fully before starting up, as you have mentioned in your post.

Again, your input and insight are valuable, and I’d like to thank you for sharing!!

I hope this has been helpful!

Laz