VLAN in the Cisco network

I'm afraid not. Putting more than one VLAN on an interface implies that you're carrying the VLAN tag with each packet (unless you're using a Cabletron 802.1d trunk). The only way to do that is to use a ISL or

As a general rule of thumb never connect switches and routers together in this manner without setting up a trunk between them (unless you know what you're doing and have a good reason to ignore this rule). I even trunk to the backside of my border routers, just so I have flexibility down the road if I need it. Inevitably you'll reach a point where you want to use more than one VLAN and you'll find that you're design has painted you into a corner. Now you have to take the network down to fix the design problem. It only takes a few minutes longer to set up a trunk port than it does to set up a plan L2 access VLAN port.

Not quite. 802.1Q has a "native" VLAN designated for each interface, and packets for that VLAN are not to be tagged. In the case of exactly two VLANs on the same interface, that would mean that each packet for one of the VLANs would be tagged, but none of the packets for the other VLAN would be tagged.

No, in such a case all you have to do is configure an untagged VLAN on the interface in switchport mode, and then change the port to trunked with that VLAN as the native interface. The packets will continue to be untagged. You can then go to the other end and change it. Once both ends are changed to trunk, you can add additional VLANs. No service interruption is required.

A few corrections on my posting. When I say "packet" I of course mean Ethernet frame. Also, I didn't explicitly say it but the trunk port will have to be configured on both sides of the link. It's a simple setup. You can search Cisco's site for config examples if you need help. This page also contains useful links.

I hate using native VLANs. For some reason it's a concept that many network admins fail to wrap their heads around. I usually avoid it and go with a pure trunk and tagged VLANs for everything. But you're right. This is how it could be technically done. I'd recommend avoiding it though, at least until they have a grasp of basic VLANs.

Walter, you're letting him off too easy. It's a typical case of poor planning and forethought. We're supposed to penalize the admin for not doing it right the first time. :-) Once again you are right, though I would still recommend against native VLANs for the reasons I mentioned above.

I took a co-workers network standards document and modified it heavily. One of the things I have on the to do list for that document is the appropriate use of VLANs. I already have the VLAN naming and number policy outlined. In that doc I'm going to mandate the use of VLANs where ever reasonable. Do it the first time and you won't have to redo it later.

Good info, J

I'm reasonably certain that the native VLAN was invented specifically to make it possible to migrate piecemeal to VLANs. 802.1Q adopted concepts from ISL, which does not have native VLANs, so I figure it must have been added purposefully, based upon lessons learned in the field.

Unfortunately, politics is seldom reasonable.

When I was doing network admin, in theory I had the right to refuse to provide service to switches that were connected without going through proper channels in the selection and deployment of the devices. In practice, I had to have good reason to believe that the device would actually harm the network in order to refuse it.

People bought and connected switches without consulting Networking, and Networking had to deal with the aftermath. For some reason, said people would tend to be vocal if properly dealing with the aftermath would require a service interruption. :( Thus, the RealPolitik of Networking may involve using procedures such as I outlined earlier, of converting an active access link into a trunk.

I think it was added to subdue those that hated the idea of tagged frames. It's really a shame that the IEEE bent over backwards to Cisco by dumbing down the final 1Q drafts to be compatible with Cisco's interpretation of the pre-standard drafts and hacks. A lot was lost that has yet to be regained.

Those 2 words rarely make sense in the same sentence unfortunately. With the right approach to the network overall you can be very successful. Just like with any project you have to engineer project support. You have to get management to sign off on the policy and delegate authoritative control to IT. Your project has to have its "sponsors" to be successful.

Very true. At one client we had outsourced to us we moved them to a new building. In the process we built them a nice network (as compared to the horriffic mess they had before). We had management on our side so when they moved over the new site I did 2 things. I enforced port-based security and limited the ports to a single MAC (I removed this later but it was in place for the first 3 or so weeks). I also walked through the entire building after the movers brought in everyone's desk contents and picked up every single switch and hub I could find. They're all in piles in the IDFs. After the migration everyone commented on how much faster the network was. That won over most of the nay-sayers.

Sponsors and signed-off policies are not always enough. Even law isn't always enough. Reasonability, knowledge, technical correctness and policy (and legal) correctness: none of these have nearly as much weight as persistant (but not -blantatly obviously- wrong) complaints .

As a Network Administrator, you're either a Good Guy or a Bad Guy. The Bad Guy is the one who sets and enforces standards for the good of everyone, thereby limiting what people can do. The Good Guy is the one who "is there to help people" by doing what the users want -- even when (especially when!) that breaks policies and technical standards and slows the network down noticably. Once you have a reputation as a Bad Guy, it's very hard to get rid of, *especially* if the network is running smoothly. [It's only when there is a crisis that the users become aware that you are Doing Something. Problems avoided are problems that Never Existed, and which took no work.]

It only takes one nay-sayer who has to be accomedated or compromised- with :(

(Some days, I envied the BOFH...)