Initial switch configuration best practices

alias454

Hi, I have been lurking here for awhile and appreciate all the great information I have been able to pick up from this site. I am currently studying for the CCENT/CCNA R&S using Wendell Odom's book and have a few general questions that may or may not be related to the test itself.

1: In one scenario, two 2950 switches are connected on fa0/8 using a crossover cable. During the initial config, VLAN200 was setup as a MGMT VLAN and assigned an IP (fa0/1). VLAN999 was added for unused ports and placed in a shutdown state. VLAN666 was added to use as the native VLAN on the trunks because I have read in a couple of places that having the native VLAN the same as VLAN1 or the management VLAN is not best practice. From playing around and changing the trunk from dynamic desirable on both sides then dynamic auto on both sides etc., I noticed the trunk port fails to an access mode state on VLAN1 by default. My question is, should the access vlan be left to the default (VLAN1), be set to VLAN666, set to VLAN999, or something completely different?

2: Another scenario, is having a headquarters along with a branch site. When setting up a remote switch, is it okay to use the same VLAN ID that is designated elsewhere? I know subnets have to be different for routing but are there issues if one has MGMT VLAN200 (192.168.10.10/24) defined then at a remote site defines another MGMT VLAN200 (192.168.20.10/24) using a different IP or is it just better to define a different VLAN at the remote site?

Thanks for your time and insights

instant000

alias454 wrote: »

I noticed the trunk port fails to an access mode state on VLAN1 by default. My question is, should the access vlan be left to the default (VLAN1), be set to VLAN666, set to VLAN999, or something completely different?

As you already noted, if the port is in access mode, and an access VLAN hasn't specifically been established, it will default to VLAN1. In this case, you can determine what that access VLAN would be, by setting it ahead of time.

Note: best practice for the trunk, in my opinion, would be to not use DTP, and manually set the trunking to ON.

2: Another scenario, is having a headquarters along with a branch site. When setting up a remote switch, is it okay to use the same VLAN ID that is designated elsewhere? I know subnets have to be different for routing but are there issues if one has MGMT VLAN200 (192.168.10.10/24) defined then at a remote site defines another MGMT VLAN200 (192.168.20.10/24) using a different IP or is it just better to define a different VLAN at the remote site?

As far as VLANs, yes, feel free to re-use those. I'd encourage it. For example, if vlan 80 is always printers, no matter where you go, it saves you that much time.

If you have enough locations, it is entirely possible that some locally significant addresses can be identical. Still, you may find that you have to NAT or something, so that they are presented as unique, so that you may be able to support some form of remote administration.

To ease deployment, you could deploy a site build to always use a certain set of IP addresses. Then, the only thing different per site may be its NAT rules, for example. If you have the info set up in a database ahead of time, you could automate pushing out the configs, if you cared to do so.

True story:
I once worked at an org where there was some equipment that that could only exist at a certain IP address, and either the IP could not be changed, or no one on the deployment team knew how to change it. The company's workaround? ... across every single location, they used a NAT rule for that one IP, and gave it a separate VLAN/gateway off the router.

In a somewhat similar scenario, there was a device that came, by default, with a statically assigned IP, and the device did not use DHCP, either. The only way to change the IP was to console into the device (after modifying the gateway IP so you had connectivity to it), and setting its IP information within a text file, and rebooting the device. The network team really hated to work on this, since there was the potential to brick the device if something was fat-fingered, so sometimes a dispatch would be sent to the store, if it was at a location that was particularly sensitive to downtime. This device was also at every retail location. (I'm not sure why they just didn't do the same NAT kludge for this device ... maybe they figured they could at least change this one to match the scheme, so why not?)

Thanks for your time and insights

You're welcome.


Since you mentioned the failure of the trunk, you may be interested in this document, which might help you a little:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8&ved=0CGIQFjAJ&url=https%3A%2F%2Flearningnetwork.cisco.com%2Fservlet%2FJiveServlet%2FpreviewBody%2F14792-102-1-57313%2FDynamic%2520Trunking%2520Protocol.PDF&ei=Bal7VLi8LYWbNuDNgtAC&usg=AFQjCNHtFiJB8rWeHdFxp8XewWPBNqXQYQ&bvm=bv.80642063,d.eXY

Now, since you started off with asking about best practices, this might whet your appetite a little:
Design Zone for Campus - Cisco

Disclaimer: The information is good and solid, just avoid the marketing jargon (unless you're going for CCDA, in which case it's 100% applicable, I learned that the hard way, LOL.)