Skip to content

Conversation

Copy link

Copilot AI commented Nov 7, 2025

Some Cisco switches explicitly show switchport trunk allowed vlan 1 in running config while others omit it (implied default). The cleanup logic was removing this line when present, creating configuration drift that caused setup failures.

Changes

  • Pattern matching: Added VLAN_1_PATTERN constant to match the exact default VLAN 1 configuration
  • Cleanup logic: Modified clean_interface_switchport_config() to skip removing switchport trunk allowed vlan 1 specifically
  • Scope: Only preserves exact VLAN 1 line; ranges like 1,2,3 or 1-3 are still removed as non-default state

Example

# Before: Both lines removed during cleanup
switchport trunk allowed vlan 1    # Removed ❌
switchport trunk allowed vlan 100  # Removed ✓

# After: VLAN 1 preserved as default state
switchport trunk allowed vlan 1    # Preserved ✓
switchport trunk allowed vlan 100  # Removed ✓

This ensures consistent behavior across switch models that handle default VLAN 1 differently in their running config output.

Original prompt

This section details on the original issue you should resolve

<issue_title>Switchport VLAN 1 Default Condition Causing Failures on Setup</issue_title>
<issue_description>
The default state of the config for an interface is on VLAN 1 as switchport. This is the state the Cloudshell returns the port to after it returns the resource to the general pool. However, some switches show that the VLAN1 is set, while others do not (as it is implied). For instance, we have two different switch ports on different switches that have the following configuration after Cloudshell tears down the environment:

CORE_SWITCH(config-if)#do show run interface GigabitEthernet110/1/0/6
Building configuration...

Current configuration : 144 bytes
!
interface GigabitEthernet110/1/0/6
 description KG-255X-06-PT
 switchport
 switchport trunk allowed vlan 1
 switchport mode dynamic auto
end
CORE_SWITCH(config-if)#do show run interface te1/5/10
Building configuration...

Current configuration : 85 bytes
!
interface TenGigabitEthernet1/5/10
 description SPIRENT Port 2/10
 switchport
end

Both of these configurations are actually the same. The second interface is indeed on vlan 1, but it is implied and it doesn't show. We have a mixed bag based on switch and IOS version of what shows with the configuration command.

Due to this, if the switchport trunk allowed vlan 1 shows in the run interface command, Cloudshell setup fails when attempting to setup VLAN connectivity on this port due to the following:
The logic in here runs a check
here and since the switchport ... vlan is present in the config, it fails to identify that all VLANS were cleared thus failing the VLAN connectivity.

We get an error on cloudshell side of the following:

2025-11-06 13:04:52,478 - QS.cisco_switch_pt.Thread-5 - ERROR - Failed to apply VLAN changes () for target cisco_switch_pt/Chassis 1-1/Module 1/GigabitEthernet110-1-0-5. Error: ('CiscoConnectivityFlow', '[FAIL] VLAN(s) ALL removal failed')
Traceback (most recent call last):
  File "C:\ProgramData\QualiSystems\venv\Cisco_IOS_Switch_2G_1_13\lib\site-packages\cloudshell\shell\flows\connectivity\basic_flow.py", line 54, in _wait_futures
    result: ConnectivityActionResult = future.result()
  File "C:\Program Files (x86)\QualiSystems\TestShell\ExecutionServer\python\3\lib\concurrent\futures\_base.py", line 438, in result
    return self.__get_result()
  File "C:\Program Files (x86)\QualiSystems\TestShell\ExecutionServer\python\3\lib\concurrent\futures\_base.py", line 390, in __get_result
    raise self._exception
  File "C:\Program Files (x86)\QualiSystems\TestShell\ExecutionServer\python\3\lib\concurrent\futures\thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "C:\ProgramData\QualiSystems\venv\Cisco_IOS_Switch_2G_1_13\lib\site-packages\cloudshell\networking\cisco\flows\cisco_connectivity_flow.py", line 141, in _remove_vlan
    msg = self._remove_vlan_flow(vlan_range, full_name)
  File "C:\ProgramData\QualiSystems\venv\Cisco_IOS_Switch_2G_1_13\lib\site-packages\cloudshell\networking\cisco\flows\cisco_connectivity_flow.py", line 210, in _remove_vlan_flow
    raise Exception(
Exception: ('CiscoConnectivityFlow', '[FAIL] VLAN(s) ALL removal failed')

Some condition needs to be added to this method to add in the case for if the switchport trunk allowed vlan 1 being present in the config since this is the default state for a switchport on some cisco switch flavors.

Note: If we set the port to routed (no switchport), the reservation does succeed, but on teardown, it places the port configuration back into the default state which has switchport vlan 1 present so all subsequent uses of this port fail.
</issue_description>

<agent_instructions>make sure this fix is very local and only allows this vlan</agent_instructions>

Comments on the Issue (you are @copilot in this section)


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI changed the title [WIP] Fix switchport VLAN 1 default condition causing setup failures Preserve default VLAN 1 configuration during interface cleanup Nov 7, 2025
Copilot AI requested a review from qkalsky November 7, 2025 20:27
Copilot finished work on behalf of qkalsky November 7, 2025 20:27
@danielwaugh-v
Copy link

It seems that that the fix above is still going to cause the issue. The problem lies in the call of the verify_interface_has_no_vlan_assigned method in add_remove_vlan_actions.py. Since that doesn't allow the default vlan configuration of VLAN 1, it will always think that a VLAN is setup on the port, even though it is in the default state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Switchport VLAN 1 Default Condition Causing Failures on Setup

3 participants