Experimental Features
Experimental features are those features that work, but haven't been thoroughly tested enough to feel confident to use in production.
Rollback Configuration
Starting in version 2.0.2, a featured called rollback configuraiton was introduced. The rollback configuration is exactly what it sounds like. It renders a rollback configuration in the event that a remediation causes a hiccup when being deployed. The rollback configuration does the inverse on a remediation. Instead of a remediation being renedered based upon the generated config, a rollback remediation is rendered from the generated config based upon the running configuration.
A rollback configuration can be rendered once the running and generated configurations are loaded. Below is an example.
>>> from hier_config import Host
>>> host = Host(hostname="aggr-example.rtr", os="ios")
>>> host.load_running_config_from_file("./tests/fixtures/running_config.conf")
>>> host.load_generated_config_from_file("./tests/fixtures/generated_config.conf")
>>> rollback = host.rollback_config()
>>> for line in rollback.all_children_sorted():
... print(line.cisco_style_text())
...
no vlan 4
no interface Vlan4
vlan 3
name switch_mgmt_10.0.4.0/24
interface Vlan2
no mtu 9000
no ip access-group TEST in
shutdown
interface Vlan3
description switch_mgmt_10.0.4.0/24
ip address 10.0.4.1 255.255.0.0
>>>
Unified diff
Starting in version 2.1.0, a featured called unified diff was introduced. It provides a similar output to difflib.unified_diff() but is aware of out of order lines and the parent child relationships present in the hier_config model of the configurations being diffed.
This feature is useful in cases where you need to compare the differences of two network device configurations. Such as comparing the configs of redundant device pairs. Or, comparing running and intended configs.
In its current state, this algorithm does not consider duplicate child differences. e.g. two instances endif
in an IOS-XR route-policy. It also does not respect the order of commands where it may count, such as in ACLs. In the case of ACLs, they should contain sequence numbers if order is important.
In [1]: list(running_config.unified_diff(generated_config))
Out[1]:
['vlan 3',
' - name switch_mgmt_10.0.4.0/24',
' + name switch_mgmt_10.0.3.0/24',
'interface Vlan2',
' - shutdown',
' + mtu 9000',
' + ip access-group TEST in',
' + no shutdown',
'interface Vlan3',
' - description switch_mgmt_10.0.4.0/24',
' - ip address 10.0.4.1 255.255.0.0',
' + description switch_mgmt_10.0.3.0/24',
' + ip address 10.0.3.1 255.255.0.0',
'+ vlan 4',
' + name switch_mgmt_10.0.4.0/24',
'+ interface Vlan4',
' + mtu 9000',
' + description switch_mgmt_10.0.4.0/24',
' + ip address 10.0.4.1 255.255.0.0',
' + ip access-group TEST in',
' + no shutdown']
Future Config
Starting in version 2.2.0, a featured called future config was introduced. It attempts to predict the running config after a change is applied.
This feature is useful in cases where you need to determine what the configuration state will be after a change is applied. Such as:
- Ensuring that a configuration change was applied successfully to a device.
- i.e. Does the post-change config match the predicted future config?
- Providing a future state config that can be fed into batfish, or similar, to predict if a change will cause an impact.
- Building rollback configs. If you have the future config state, then generating a rollback config can be done by simply building the remediation config in the reverse direction rollback = future.config_to_get_to(running)
.
- If you are building rollbacks for a series of config changes, you can feed the post-change-1 future config into the process for determining the post-change-2 future config e.g.
shell
post_change_1_config = running_config.future(change_1_config)
change_1_rollback_config = post_change_1_config.config_to_get_to(running_config)
post_change_2_config = post_change_1_config.future(change_2_config)
change_2_rollback_config = post_change_2_config.config_to_get_to(post_change_1_config)
...
In its current state, this algorithm does not consider: - negate a numbered ACL when removing an item - sectional exiting - negate with - idempotent command blacklist - idempotent_acl_check - and likely others
In [1]: from hier_config import HConfig, Host
...:
...:
...: host = Host("test.dfw1", "ios")
...: running_config = HConfig(host)
...: running_config.load_from_file("./tests/fixtures/running_config.conf")
...: remediation_config = HConfig(host)
...: remediation_config.load_from_file("./tests/fixtures/remediation_config_without_tags.conf")
...: future_config = running_config.future(remediation_config)
...:
...: print("\n##### running config")
...: for line in running_config.all_children():
...: print(line.cisco_style_text())
...:
...: print("\n##### remediation config")
...: for line in remediation_config.all_children():
...: print(line.cisco_style_text())
...:
...: print("\n##### future config")
...: for line in future_config.all_children():
...: print(line.cisco_style_text())
...:
##### running config
hostname aggr-example.rtr
ip access-list extended TEST
10 permit ip 10.0.0.0 0.0.0.7 any
vlan 2
name switch_mgmt_10.0.2.0/24
vlan 3
name switch_mgmt_10.0.4.0/24
interface Vlan2
descripton switch_10.0.2.0/24
ip address 10.0.2.1 255.255.255.0
shutdown
interface Vlan3
mtu 9000
description switch_mgmt_10.0.4.0/24
ip address 10.0.4.1 255.255.0.0
ip access-group TEST in
no shutdown
##### remediation config
vlan 3
name switch_mgmt_10.0.3.0/24
vlan 4
name switch_mgmt_10.0.4.0/24
interface Vlan2
mtu 9000
ip access-group TEST in
no shutdown
interface Vlan3
description switch_mgmt_10.0.3.0/24
ip address 10.0.3.1 255.255.0.0
interface Vlan4
mtu 9000
description switch_mgmt_10.0.4.0/24
ip address 10.0.4.1 255.255.0.0
ip access-group TEST in
no shutdown
##### future config
vlan 3
name switch_mgmt_10.0.3.0/24
vlan 4
name switch_mgmt_10.0.4.0/24
interface Vlan2
mtu 9000
ip access-group TEST in
descripton switch_10.0.2.0/24
ip address 10.0.2.1 255.255.255.0
interface Vlan3
description switch_mgmt_10.0.3.0/24
ip address 10.0.3.1 255.255.0.0
mtu 9000
ip address 10.0.4.1 255.255.0.0
ip access-group TEST in
no shutdown
interface Vlan4
mtu 9000
description switch_mgmt_10.0.4.0/24
ip address 10.0.4.1 255.255.0.0
ip access-group TEST in
no shutdown
hostname aggr-example.rtr
ip access-list extended TEST
10 permit ip 10.0.0.0 0.0.0.7 any
vlan 2
name switch_mgmt_10.0.2.0/24