Higham, Josh wrote:
Either I'm misunderstanding what you are saying, or this is incorrect.
The native VLAN identifier just dictates what frames are tagged, it
doesn't control whether they are sent. So if the native vlan is 999,
with a default config port is in vlan 1, if the port receives traffic it
will still be sent over the trunk, but tagged with vlan 1 (rather than
untagged if vlan 1 was native).
Changing the native VLAN would not have prevented the problem that
Justin is describing. The only solution to that is making sure that
vlan 1 isn't used in production, so even if frames are generated there
is no destination.
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.
Shutting down the vlan 1 SVI will make sure that no traffic from VLAN 1
is routed, which is a way of enforcing the policy restriction described
above.
I always shut the VLAN 1 SVI on devices that have it by default
(switches for example) and never create it on those that don't. I'm
curious though about shutting down the L2 VLAN though. That would prove
to be helpful. Another helpful thing would be if Cisco would not put an
access port into admin up state if an access VLAN hasn't been explicitly
defined. If a VLAN hasn't been manually defined then IMHO the
interface's config is incomplete and should not be allowed up. Another
option would be if Cisco would add the ability to define the default
VLAN used on all ports that don't have an explicit access VLAN defined.
That would be helpful as well.
Justin
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
