> I think Engel may have mis-read my email and thought I was on a trunk > port in which case what he wrote would have been correct. In my case > though I was on an access port. Most of that port's config had been > wiped clean leaving only switchport and mode access. I could avoid the > issue in the future (assuming that the VPN SPA's broken default config > can't be fixed) by assigning all my unused access ints to a dummy VLAN. > That would get them out of VLAN 1 and avoid the problem. I usually > have all unused ints shutdown when not in use but in this case it was an > int I'd previously used for testing and instead wiped the int config > clean but left it up. >
hi all, the problem with this train of thought in my experience is that the dummy vlan (eg 4094 may be a nice choice) may be auto-created upon you typing switchport mode access, switchport access vlan <x> .. (depending on your platform/code) - obviously its easy enough to conf the ports in their default dummy state and then delete vlan 4094 that was auto created at the end - but if you de-provision a port, and return it to the dummy vlan the switch may auto create the vlan in that process. (again depending on platform/code ) one solution to this (in a VTP transparent mode environment) may simply be prevent the dummy vlan from being trunked beyond the access switch, containing the dummy vlan connectivity to the local device. its not going to prevent two ports that have been unshut in the dummy vlan talking to each other on the same device, but they aren't going to be getting very far beyond that. just an idea. ... i like you don't like having ports sitting in vlan 1, regardless of whether they are shut down or not, curious what other people on the list thoughts are on this subject.. kind regards, --matt _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
