More efficient typology for a home lab to allow for SSH

[FazeDank]

Hi all. This is my first time setting up a home lab and I feel like the current typology I have is extremely inefficient. I have posted my current typology below and will offer a brief explanation of what I have done. Essentially what I have done is I used one interface on each device that would all be on the same subnet. They would then all be connected to a singular switch that would lead to my PC which I would manage the network from. I want to be able to SSH into all the devices without having to constantly plug in and plug out the console cable from each and every one of the devices. Just wondering if there is a better way to do this as I feel like my current typology is wasting a lot of ports and is not realistic to a real world environment. 

[Seb Rupik]

Hi there,

What you have configured would be standard for a top of rack/ end of row management switch with a cable directly connected to provide a locally out of band connection.

When you have a large footprint with devices spread across a campus this design doesn't scale; what you need is an in-band management network, essentially a VLAN which is trunked to every device. As you are using routers which may not support SVIs and have routed interfaces only this will need to be connected to the multi-layer switch via sub-interfaces one of which being the management network. Also as the routers are only running Layer3 connections between themselves, Router1 will need to be connected to a multli-layer switch, or perhaps just keep that Layer2 switch and connect it back to 'multi-layer switch1' as you currently have it.

cheers,

Seb.

[FazeDank]

Hi Seb, thanks for the suggestion!

I am just wondering if I do choose to trunk a VLAN across all devices, would it not be able to route normal non-VLAN traffic?  From my limited understanding a VLAN trunk would only allow for traffic tagged with the VLAN header to pass through. The main reason I chose this type of typology is because the configurations I implement on the devices would not be permanent and would change so I guess I wanted some flexibility in how much I could easily change the network. Mostly I am just testing out CCNA labs with my current setup instead of through packet tracer so I need a high degree of flexibility in my network.

[Seb Rupik · Accepted solution]

Hello again,

You are forgetting the concept of the native VLAN on a trunk link. Essentially a VLAN ID can be defined on a trunk such that frames belong to that VLAN will be transmitted without a VLAN tag and likewise any untagged frames received on that trunk will then use the native VLANs forwarding table for further switching within the switch.

On a sub-interface you can explicitly define a native sub-interface:

!
int gi0/1
  no shut
!
int gi0/1.10
  encapsulation dot1q 10 native
!

Losing access to the management IP of a remote device through misconfiguration of trunk links is the sort of stuff that plays on every engineers mind when actioning changes, so its consideration into your designs would be well placed. That said, if this is just a demo topology where you are testing more vexing routing problems, and the entire configs except the management interface are routinely being trashed, then it is perfectly acceptable to keep your out of band network, even if it isn't very realistic beyond a single building deployment.

cheers,

Seb.