Hello Helen
Yes, you are correct. Even if you configure a trunk with a native VLAN that does not exist, the traffic will successfully be transmitted, and the trunk will operate. However, other features that require native VLANs to function may fail. For example, STP can fail in such a case, as described in this post:
In any case, I labbed this up and attempted to recreate the scenario. Note below:
SW1#show run inter gig 0/1
Building configuration...
Current configuration : 203 bytes
!
interface GigabitEthernet0/1
switchport trunk native vlan 10
switchport mode trunk
end
I configured a trunk on GigabitEtherent 0/1 and configured VLAN 10 as the native VLAN. I then display the configured VLANs in the switch:
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Note that there is no VLAN 10. However, the below command shows that the trunk on Gi0/1 is indeed using VLAN 10 as the native VLAN:
SW1#show inter trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 10
Port Vlans allowed on trunk
Gi0/1 2-4094
Port Vlans allowed and active in management domain
Gi0/1 none
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 none
SW1#
This simply means that when STP, or any other feature that leverages the native VLAN sends an untagged frame to this interface, it will be dropped simply because VLAN 10 does not exist. Remember that the native VLAN configuration on an interface tells the switch onto which VLAN it should place any untagged frames it receives.
So, the trunk will function, but any feature that uses the native VLAN will fail.
I hope this has been helpful!
Laz