Closed mihudec closed 3 years ago
@mihudec Thanks for raising the issue, can u share the out of sh running-config | section ^interface
which is used to generate the out for parsing l2_interface params.
The l2 device (ref version: cisco vios_l2 15.2) I have tried the scenario with doesn’t differentiate the output for allowed vlan/pruning vlan based on add
param.
I can add the logic for parsing the add
param once confirmed.
@justjais Sorry for the late response, the config from the interface is:
interface Ethernet0/2
switchport mode trunk
switchport trunk allowed vlan 1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
switchport trunk allowed vlan add 1500,1502,1504
To my knowledge, this happens on all IOS versions and platforms regardless the terminal width
parameter, when the switchport trunk allowed vlan
line becomes too long. You can spot this behaviour by adding more VLANs, where from certain point the lines start to fold using the add
keyword. This can result in multiple add
lines.
Thanks.
Hi all,
Facing the same issue today for a customer, i came up with a quick fix in module_utils/network/ios/facts/l2_interfaces/l2_interfaces.py:
127 if allowed_vlan:
128 trunk["allowed_vlans"] = allowed_vlan.split(",")
129 allowed_vlan_add = utils.parse_conf_arg(conf, "allowed vlan add")
130 if allowed_vlan_add:
131 trunk["allowed_vlans"] += allowed_vlan_add.split(",")
Would you like a proper merge request?
Hi @el00ruobuob , glad to see I'm not the only one facing this issue. I've done similar patch for myself, however, I believe this issue goes beyond this single module.
The other part of the problem is the way VLAN ranges are compared in ios_l2_interfaces and the way new VLANs are added/removed from configuration. I'm afraid that simple pushing switchport trunk allowed vlan <all vlans go here>
is not the best way to do it, as it may cause a temporary service disruptions on already allowed VLANs (the VLAN might flap when being re-added). I would prefer if the fix addressed this as well and used proper add
and remove
logic.
And the same thing should be incorporated in NXOS modules. I've tried to come up with a PR, but frankly I couldn't tell where exactly it should be fixed. Maybe @justjais has some ideas?
Thanks.
as it may cause a temporary service disruptions on already allowed VLANs (the VLAN might flap when being re-added)
@justjais, Could you confirm or infirm such possibility of service disruption? For something like adding vlans to production trunk interfaces, that's quite a concern.
@el00ruobuob @mihudec apologies for the late reply as I was on PTO and I'll verify the issue again from my end and raise a PR for fixing the same asap.
@justjais Any update on this?
@el00ruobuob excuse me for the delay it's been a busy month, you can expect the update sometime next week.
+1 , any update ?
@phpipam u can expect the fix this week, as supposedly the PR against the issue is not the intended fix.
Hi @justjais , thanks, let me know if I can assist if some testing is needed.
@phpipam @mihudec I've raised the PR to fix the particular issue, plz verify the PR changes if it works as expected and also fixes the issue faced. Excuse me for the delayed fix, it had slipped under the crack.
Hi @justjais, thanks.
I did some test and it seems it works only for first line of switchport trunk allowed vlans add
, if there are more all following lines are ignored.
Interface cfg example:
interface GigabitEthernet1/0/1
description UPLINK
switchport trunk allowed vlan 11,59,67,75,77,81,100,400-408,411-413,415,418
switchport trunk allowed vlan add 461,674,675,696,931,935,951,952,973,974,979
switchport trunk allowed vlan add 982,986,988,993
switchport mode trunk
...
end
As mentioned second add line is excluded:
switchport trunk allowed vlan add 982,986,988,993
This are facts gathered for interface:
- mode: trunk
name: GigabitEthernet1/0/1
trunk:
allowed_vlans:
- '11'
- '59'
- '67'
- '75'
- '77'
- '81'
- '100'
- '400'
- '401'
- '402'
- '403'
- '404'
- '405'
- '406'
- '407'
- '408'
- '411'
- '412'
- '413'
- '415'
- '418'
- '461'
- '674'
- '675'
- '696'
- '931'
- '935'
- '951'
- '952'
- '973'
- '974'
- '979'
@phpipam perfect, thanks for testing out the PR and letting me know of the issue with the fix. I'll update the fix and let you know.
@phpipam I've updated the fix, let me know if that works for you as expected. Thanks again for testing the fix.
HI, seems to be ok 👍 , thanks !
- mode: trunk
name: GigabitEthernet1/0/1
trunk:
allowed_vlans:
- '11'
- '59'
- '67'
- '75'
- '77'
- '81'
- '100'
- '400'
- '401'
- '402'
- '403'
- '404'
- '405'
- '406'
- '407'
- '408'
- '411'
- '412'
- '413'
- '415'
- '418'
- '461'
- '674'
- '675'
- '696'
- '931'
- '935'
- '951'
- '952'
- '973'
- '974'
- '979'
- '982'
- '986'
- '988'
- '993'
SUMMARY
The Facts module for L2 properties does not include allowed VLANs on trunk interfaces when there are multiple allowed ranges. The module only recognizes VLAN ranges in
switchport trunk allowed vlan X
, but not inswitchport trunk allowed vlan add Y
. This result in change every time.ISSUE TYPE
COMPONENT NAME
ios_l2_interfaces L2_InterfacesFacts
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
Fedora 32
Cisco: Any IOS/IOS-XE Switch
STEPS TO REPRODUCE
Playbook:
Device config before running the playbook:
EXPECTED RESULTS
Module parses the current device config correctly, including the line
switchport trunk allowed vlan add 1500,1502,1504
. The module then compares the currently allowed VLANs with the VLANs specified in task and pushes only the difference, preferably usingswitchport trunk allowed vlan add <diff>
. In this exact case, the VLANs configured on the device are identical to the ones specified in task, therefore the task should return ok instead of changed.ACTUAL RESULTS
The module only recognizes the
switchport trunk allowed vlan 1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
and tries to update the allowed VLANs to contain 1500,1502,1504. However, it does it in a strange way, putting together already present VLANs with ALL specified VLANs, producing commandswitchport trunk allowed vlan 1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,1500,1502,1504,1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
. A proper way would be to get want.difference(have) and sendswitchport trunk allowed vlan add 1500,1502,1504
. The difference should be done per individual VLANs, not per ranges.Suggestions
I suggest creating new function in utils for parsing allowed VLANs, maybe something like:
It should be noted that the config
switchport trunk allowed vlan all
will never be present in show running-config only in "show running-config all". Maybe the facts module should return ["1-4094"] for all trunk interfaces with default configuration. Another possibility isswitchport trunk allowed vlan none
, which could make the module return an empty list. In my opinion, theallowed_vlan = None
should be returned only for non-trunking interfaces.Then another function for expanding the VLAN ranges to the list (or set) of integers: