-
Notifications
You must be signed in to change notification settings - Fork 59
Home
JSNAPy,Junos Snapshot Administrator in Python captures and audit runtime environment of network devices running Junos operating system (Junos OS). It automates network state verification by capturing and validating status of a device. It is used to take pre-snapshots and then post-snapshots after modification and compare them based on test cases provided. It can also be used to audit device's runtime environment against pre-defined criteria.
- Command line tool
- Python Module
- Input components include all yaml files. It consists of main config files, test files, and other files in yaml like mail files.
- Output components include snapshot files in xml or text. Jsnapy will further analyse these files and display output in terminal and log all information in log files.
-
/var/log/jsnapy : It consists of
a) info.log : contain all info messages b) errors.log : contain all error messages c) critical.log : contain all critical messages d) debug.log : contain all debug level messages e) jsnapy.log : default file containing all log messages
-
/etc/jsnapy : It consists of
For
version < 1.3
a) samples: directory consists of sample configs and test files in yaml. b) snapshots: directory containing all snapshots c) testfiles: directory containing all test cases and config files d) jsnapy.cfg: JSNAPy configparser file containing file paths, modify this file to change file paths e) logging.yml: File describing loggging settings. Modify this file if you want to change logging levels or output format
For
version >= 1.3
a) jsnapy.cfg: JSNAPy configparser file containing file paths, modify this file to change file paths b) logging.yml: File describing loggging settings. Modify this file if you want to change logging levels or output format
The testfiles and snapshots will now get stored in the home folder of the user. User will have to create the
path to ~/jsnapy/snapshots and ~/jsnapy/testfiles if they do not exist.
- The default location for jsnapy.cfg and logging.yml is /etc/jsnapy.
- User can change the default lookup location for jsnapy.cfg and logging.yml by setting JSNAPY_HOME environment variable.
- Alternatively, one can keep custom jsnapy.cfg and logging.yml at ~/.jsnapy also.
- Lookup order followed is:
JSNAPY_HOME -> ~/.jsnapy -> /etc/jsnapy
While installing Jsnapy, it creates Jsnapy folder at ~/jsnapy and and ~/var/logs.
-
~/jsnapy is counterpart of /etc/jsnapy: It consists of
a) samples: directory consists of sample configs and test files in yaml. b) snapshots: directory containing all snapshots c) testfiles: directory containing all test cases and config files d) jsnapy.cfg: JSNAPy configparser file containing file paths, modify this file to change file paths e) logging.yml: File describing loggging settings. Modify this file if you want to change logging levels or output format
-
~/var/logs/jsnapy is counterpart of /var/log/jsnapy: It consists of
a) info.log : contain all info messages b) errors.log : contain all error messages c) critical.log : contain all critical messages d) debug.log : contain all debug level messages e) jsnapy.log : default file containing all log messages
-
The default location for jsnapy.cfg and logging.yml is ~/jsnapy.
-
The above rules to customize the config location are valid in windows also.
-
Although there is change in Lookup order:
JSNAPY_HOME -> ~/.jsnapy -> ~/jsnapy
While installing Jsnapy in a Python virtualenv, let's say env it creates Jsnapy folder at env/etc/jsnapy and env/var/logs.
-
env/etc/jsnapy is counterpart of /etc/jsnapy: It consists of
a) samples: directory consists of sample configs and test files in yaml. b) snapshots: directory containing all snapshots c) testfiles: directory containing all test cases and config files d) jsnapy.cfg: JSNAPy configparser file containing file paths, modify this file to change file paths e) logging.yml: File describing loggging settings. Modify this file if you want to change logging levels or output format
-
env/var/logs/jsnapy is counterpart of /var/log/jsnapy: It consists of
a) info.log : contain all info messages b) errors.log : contain all error messages c) critical.log : contain all critical messages d) debug.log : contain all debug level messages e) jsnapy.log : default file containing all log messages
-
The default location for jsnapy.cfg and logging.yml is ~/jsnapy.
-
The above rules to customize the config location are valid in virtualenv also.
-
Although there is change in Lookup order:
JSNAPY_HOME -> ~/.jsnapy -> env/etc/jsnapy
For comparing current snapshot with pre-defined criteria:
- Execute Tests Over Elements with Numeric or String Values
1. all-same: Check if all content values for the specified element are the same. It can also be used to compare
all content values against another specified element.
- all-same: flap-count
checks if all values of node <flap-count> in given Xpath is same or not.
2. is-equal: Check if the value (integer or string) of the specified element matches a given value.
- is-equal: admin-status, down
check if value of node <admin-status> in given Xpath is down or not.
3. not-equal: Check if the value (integer or string) of the specified element does not match a given value.
- not-equal: oper-status, down
check that value of node <oper-status> should not be equal to down.
4. exists: verifies the existence of an XML element in the snapshot.
- exists: no-active-alarm
checks if node </no-active-alarm> is present or not
5. not-exists: verifies xml element should not be present in snapshot
-not-exists: no-active-alarm
checks </no-active-alarm > node should not be present in snapshot.
6. contains: determines if an XML element string value contains the provided test-string value.
- contains: //package-information/name[1], jbase
checks if jbase is present in given node or not.
7. not-contains: determines if an XML element string value does not contain the provided test-string value.
- not-contains: //output, sync_alarm
checks if sync_alarm is present in given node or not.
- Execute Tests Over Elements with Numeric Values
1. is-gt: Check if the value of a specified element is greater than a given numeric value.
- is-gt: cpu-total, 2
checks value of <cpu-total> should be greater than 2
2. is-lt: Check if the value of a specified element is lesser than a given numeric value.
- is-lt temperature, 55
checks value of <temperature> is 55 or not.
3. in-range: Check if the value of a specified element is in the given numeric range.
- in-range memory-buffer-utilization, 20, 70
check if value of <memory-buffer-utilization> is in range of 20, 70
4. not-range: Check if the value of a specified element is outside of a given numeric range.
- not-range: memory-heap-utilization, 5 , 40
checks if value of <memory-heap-utilization> is not in range of 5 to 40
- Execute Tests Over Elements with String Values:
1. contains: determines if an XML element string value contains the provided test-string value.
- contains: //package-information/name[1], jbase
checks if jbase is present in given node or not.
2. not-contains: determines if an XML element string value does not contain the provided test-string value.
- not-contains: //output, sync_alarm
checks if sync_alarm is present in given node or not.
3. is-in: Check if the specified element string value is included in a given list of strings.
- is-in: oper-status, down, up
check if value of <oper-status> in is list (down, up)
4. not-in: Check if the specified element string value is NOT included in a given list of strings.
- not-in :oper-status, down, up
check if value of <oper-status> in not in list (down, up)
For comparing values of Two Snapshots:
1. no-diff: Compare data elements present in both snapshots, and verify if their value is the same.
- no-diff: mastership-state
checks that value of <mastership-state> in two snapshots is not different.
2. list-not-less: Check if the item is present in the first snapshot but not present in the second snapshot.
- list-not-less: interface-name
checks that if <interface-name> is present in first snapshot, then it should also present in
second snapshot.
If nothing is specified, then it will compare all nodes
3. list-not-more: Check if the item is present in the second snapshot but not present in the first snapshot.
-list-not-more address-family/address-family-name
checks that if node is present in second snapshot then it should be present in first snapshot also.
If nothing is specified, then it will compare all nodes.
4. delta: Compare the change in value of an element to a delta.
delta can be specified as:
1. an absolute percentage
2. positive, negative percentage
3. an absolute fixed value
4. a positive negative fixed value
- delta: memory-heap-utilization, 15%
Value of <memory-heap-utilization> should not differ by more than 15% between pre and post snapshots.