Blitz additionals
Blitz retry
pyATS Blitz can retry an include or exclude entry after sleeping for certain interval of time defined using the fields ‘max_time’ & ‘check_interval’ in the action snippet. This is useful for certain scenarios where an ‘execute’ or ‘parse’ action would not have an entry at the time it is invoked but might get the entry after it has waited for certain time.
LAMP provides the ‘blitz_retry’ setting to add the ‘max_time’ & ‘check_interval’ fields to autogenerated Blitz snippets. The value of the setting is in the format of ‘max_time/check_interval’.
Use the set command to set the value of the setting:
(lamp-h2) set blitz_retry 100/10
blitz_retry - was: '0/0'
now: '100/10'
A setting of ‘100/10’ would mean that the Blitz action would retry for a maximum of 100 seconds, checking every 10 seconds thereby giving 10 retries before failing.
Example:
(lamp-h2) execute -i show ip route
2025-09-06 11:18:04: %LAMP-INFO: +..............................................................................+
2025-09-06 11:18:04: %LAMP-INFO: : Execute 'show ip route' on 'h2' :
2025-09-06 11:18:04: %LAMP-INFO: +..............................................................................+
2025-09-06 11:18:04,985: %UNICON-INFO: +++ host2(alias=h2) with via 'a': executing command 'show ip route' +++
show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/24 is directly connected, Ethernet0/0
L 1.1.1.1/32 is directly connected, Ethernet0/0
host2#
2025-09-06 11:18:05: %LAMP-INFO: +..............................................................................+
2025-09-06 11:18:05: %LAMP-INFO: : Collecting INCLUDE Entries :
2025-09-06 11:18:05: %LAMP-INFO: +..............................................................................+
Enter pattern to 'INCLUDE' (Press enter for multiple patterns): 1.1.1.1
(lamp-h2) list 1
- execute:
device: h2
command: show ip route
include:
- 1.1.1.1
max_time: 100
check_interval: 10
(lamp-h2)
Expected failure
pyATS Blitz allows a failed action to be marked as passed by setting the field ‘expected_failure’ to True in the action snippet. This is useful for certain negative scenarios where a command is expected to fail.
LAMP provides the ‘blitz_expected_failure’ setting which when enabled, prompts the user for adding the ‘expected_failure’ field when a command fails.
Enable the setting using the set command:
(lamp-h2) set blitz_expected_failure enabled
blitz_expected_failure - was: disabled
now: enabled
(lamp-h2)
Example:
(lamp-h2) configure -err % feature bgp
2025-09-06 11:27:35: %LAMP-INFO: +..............................................................................+
2025-09-06 11:27:35: %LAMP-INFO: : Configure ['feature bgp'] on 'h2' :
2025-09-06 11:27:35: %LAMP-INFO: +..............................................................................+
2025-09-06 11:27:35,420: %UNICON-INFO: +++ host2(alias=h2) with via 'a': configure +++
config term
Enter configuration commands, one per line. End with CNTL/Z.
host2(config)#feature bgp
feature bgp
^
% Invalid input detected at '^' marker.
host2(config)#end
host2#
Is this an expected failure? Would you like to mark it as such? (Y/n):
(lamp-h2) list 1
- configure:
device: h2
command:
- feature bgp
expected_failure: true
error_pattern:
- '%'
(lamp-h2)
Script abort using continue
pyATS Blitz aborts a script run if an action fails with its ‘continue’ field set to ‘false’.
LAMP provides the ‘blitz_continue’ setting to set the value of ‘continue’ field in all autogenerated Blitz snippets.
Use the set command to set the value of the setting:
(lamp-leaf2) set blitz_continue false
blitz_continue - was: True
now: False
(lamp-leaf2)
Example of an autogenerated snippet with the ‘continue’ field set to ‘false’:
(lamp-h2) configure no logging console
2025-09-06 11:32:54: %LAMP-INFO: +..............................................................................+
2025-09-06 11:32:54: %LAMP-INFO: : Configure ['no logging console'] on 'h2' :
2025-09-06 11:32:54: %LAMP-INFO: +..............................................................................+
2025-09-06 11:32:54,106: %UNICON-INFO: +++ host2(alias=h2) with via 'a': configure +++
config term
Enter configuration commands, one per line. End with CNTL/Z.
host2(config)#no logging console
host2(config)#end
host2#
(lamp-h2) list 1
- configure:
device: h2
command:
- no logging console
continue: false
Blitz group
Certain tags can be associated with a Blitz trigger allowing users to run a group of triggers by specifying the tag. These tags are defined in the ‘groups’ field of the Blitz trigger YAML.
LAMP provides the ‘blitz_group’ setting to prompt user for adding these
tags to a Blitz trigger when saving it using the save command.
Enable the setting using the set command:
(lamp-h2) set blitz_group enabled
blitz_group - was: disabled
now: enabled
Example:
(lamp-h2) save tc.yaml
Do you want to add a blitz group to this testcase? (Y/n):
Enter blitz group (Multiple groups comma separated): basic,ios
2025-09-06 11:40:16: %LAMP-INFO: +..............................................................................+
2025-09-06 11:40:16: %LAMP-INFO: : Generated blitz actions saved to 'tc.yaml' successfully :
2025-09-06 11:40:16: %LAMP-INFO: +..............................................................................+
The saved Blitz trigger YAML would contain the ‘groups’ field set with the tags as shown below:
# tc.yaml
# 06 September 2025
# LAMP Generated testcase
tc:
groups:
- basic
- ios
source:
pkg: genie.libs.sdk
class: triggers.blitz.blitz.Blitz
devices:
- host2
test_sections:
- default:
- execute:
device: host2
command: show ip mroute
Error patterns
Configuration CLI may return errors, but certain specialized error formats are not recognized by pyATS. Users must explicitly define these error patterns either in the testbed YAML file or using the ‘error_pattern’ field in a Blitz action snippet.
LAMP provides the ‘-err’ option to add specific error patterns to each configure command.
Shown below is an example:
(lamp-h2) configure -err % no logging console
2025-09-06 11:35:03: %LAMP-INFO: +..............................................................................+
2025-09-06 11:35:03: %LAMP-INFO: : Configure ['no logging console'] on 'h2' :
2025-09-06 11:35:03: %LAMP-INFO: +..............................................................................+
2025-09-06 11:35:03,637: %UNICON-INFO: +++ host2(alias=h2) with via 'a': configure +++
config term
Enter configuration commands, one per line. End with CNTL/Z.
host2(config)#no logging console
host2(config)#end
host2#
(lamp-h2) list 1
- configure:
device: h2
command:
- no logging console
error_pattern:
- '%'
(lamp-h2)
An example of error patterns with ‘config-prompt’ mode:
(lamp-host1) configure -err ".*%.*" -err "BGP: error processing command"
host1(config)# vrf def test
host1(config-vrf)# rd 100:100
host1(config-vrf)# address-family ipv4
host1(config-vrf-af)# route-target 100:100 stitching
host1(config-vrf-af)# end
(lamp-host1) list -a
default:
- configure:
device: host1
command: |-
!
vrf def test
rd 100:100
address-family ipv4
route-target 100:100 stitching
error_pattern:
- .*%.*
- 'BGP: error processing command'