NIPAP API

This module contains the Nipap class which provides most of the backend logic in NIPAP apart from that contained within the PostgreSQL database.

NIPAP contains four types of objects: ASNs, VRFs, prefixes and pools.

VRF

A VRF represents a Virtual Routing and Forwarding instance. By default, one VRF which represents the global routing table (VRF “default”) is defined. This VRF always has the ID 0.

VRF attributes

  • id - ID number of the VRF.

  • vrf - The VRF RDs administrator and assigned number subfields

    (eg. 65000:123).

  • name - A short name, such as ‘VPN Customer A’.

  • description - A longer description of what the VRF is used for.

  • tags - Tag keywords for simple searching and filtering of VRFs.

  • avps - Attribute-Value Pairs. This field can be used to add

    various extra attributes that a user wishes to store together with a VRF.

VRF functions

Prefix

A prefix object defines an IP address prefix. Prefixes can be one of three different types; reservation, assignment or host. Reservation; a prefix which is reserved for future use. Assignment; addresses assigned to a specific purpose. Host; prefix of max length within an assigment, assigned to an end host.

Prefix attributes

  • id - ID number of the prefix.

  • prefix - The IP prefix itself.

  • prefix_length - Prefix length of the prefix.

  • display_prefix - A more user-friendly version of the prefix.

  • family - Address family (integer 4 or 6). Set by NIPAP.

  • vrf_id - ID of the VRF which the prefix belongs to.

  • vrf_rt - RT of the VRF which the prefix belongs to.

  • vrf_name - Name of VRF which the prefix belongs to.

  • description - A short description of the prefix.

  • comment - A longer text describing the prefix and its use.

  • node - Name of the node on which the address is configured.

  • pool_id - ID of pool, if the prefix belongs to a pool.

  • pool_name - Name of pool, if the prefix belongs to a pool.

  • type - Prefix type, string ‘reservation’, ‘assignment’ or ‘host’.

  • status - Status, string ‘assigned’, ‘reserved’ or ‘quarantine’.

  • indent - Depth in prefix tree. Set by NIPAP.

  • country - Two letter country code where the prefix resides.

  • order_id - Order identifier.

  • customer_id - Customer identifier.

  • vlan - VLAN identifier, 0-4096.

  • tags - Tag keywords for simple searching and filtering of prefixes.

  • avps - Attribute-Value Pairs. This field can be used to add

    various extra attributes that a user wishes to store together with a prefix.

  • expires - Set a date and time for when the prefix assignment

    expires. Multiple formats are supported for specifying time, for absolute time ISO8601 style dates can be used and None or the text strings ‘never’ or ‘infinity’ is treated as positive infinity and means the assignment never expires. It is also possible to specify relative time and a fuzzy parser is used to interpret strings such as “tomorrow” or “2 years” into an absolute time.

  • external_key - A field for use by external systems which needs to

    store references to its own dataset.

  • authoritative_source - String identifying which system last

    modified the prefix.

  • alarm_priority - String ‘warning’, ‘low’, ‘medium’, ‘high’ or

    ‘critical’.

  • monitor - A boolean specifying whether the prefix should be

    monitored or not.

  • display - Only set by the search_prefix() and

    smart_search_prefix() functions, see their documentation for explanation.

Prefix functions

Pool

A pool is used to group together a number of prefixes for the purpose of assigning new prefixes from that pool. add_prefix() can for example be asked to return a new prefix from a pool. All prefixes that are members of the pool will be examined for free space and a new prefix, of the specified prefix-length, will be returned to the user.

Pool attributes

  • id - ID number of the pool.

  • name - A short name.

  • description - A longer description of the pool.

  • default_type - Default prefix type (see prefix types above.

  • ipv4_default_prefix_length - Default prefix length of IPv4 prefixes.

  • ipv6_default_prefix_length - Default prefix length of IPv6 prefixes.

  • tags - Tag keywords for simple searching and filtering of pools.

  • avps - Attribute-Value Pairs. This field can be used to add

    various extra attributes that a user wishes to store together with a pool.

Pool functions

ASN

An ASN object represents an Autonomous System Number (ASN).

ASN attributes

  • asn - AS number.
  • name - A name of the AS number.

ASN functions

The ‘spec’

Central to the use of the NIPAP API is the spec – the specifier. It is used by many functions to in a more dynamic way specify what element(s) you want to select. Mainly it came to be due to the use of two attributes which can be thought of as primary keys for an object, such as a pool’s id and name attribute. They are however implemented so that you can use more or less any attribute in the spec, to be able to for example get all prefixes of family 6 with type reservation.

The spec is a dict formatted as:

vrf_spec = {
    'id': 512
}

But can also be elaborated somehwat for certain objects, as:

prefix_spec = {
    'family': 6,
    'type': 'reservation'
}

If multiple keys are given, they will be ANDed together.

Authorization & accounting

With each query an object extending the BaseAuth class should be passed. This object is used in the Nipap class to perform authorization (not yet implemented) and accounting. Authentication should be performed at an earlier stage and is NOT done in the Nipap class.

Each command which alters data stored in NIPAP is logged. There are currently no API functions for extracting this data, but this will change in the future.

Classes

class nipap.backend.Inet(addr)

This works around a bug in psycopg2 version somewhere before 2.4. The __init__ function in the original class is broken and so this is merely a copy with the bug fixed.

Wrap a string to allow for correct SQL-quoting of inet values.

Note that this adapter does NOT check the passed value to make sure it really is an inet-compatible address but DOES call adapt() on it to make sure it is impossible to execute an SQL-injection by passing an evil value to the initializer.

class nipap.backend.Nipap(auto_install_db=False, auto_upgrade_db=False)

Main NIPAP class.

The main NIPAP class containing all API methods. When creating an instance, a database connection object is created which is used during the instance’s lifetime.

add_asn(*args, **kwargs)

Add AS number to NIPAP.

  • auth [BaseAuth]

    AAA options.

  • attr [asn_attr]

    ASN attributes.

Returns a dict describing the ASN which was added.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.add_asn() for full understanding.

add_pool(*args, **kwargs)

Create a pool according to attr.

  • auth [BaseAuth]

    AAA options.

  • attr [pool_attr]

    A dict containing the attributes the new pool should have.

Returns a dict describing the pool which was added.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.add_pool() for full understanding.

add_prefix(*args, **kwargs)

Add a prefix and return its ID.

  • auth [BaseAuth]

    AAA options.

  • attr [prefix_attr]

    Prefix attributes.

  • args [add_prefix_args]

    Arguments explaining how the prefix should be allocated.

Returns a dict describing the prefix which was added.

Prefixes can be added in three ways; manually, from a pool or from a prefix.

Manually
All prefix data, including the prefix itself is specified in the attr argument. The args argument shall be omitted.
From a pool
Most prefixes are expected to be automatically assigned from a pool. In this case, the prefix key is omitted from the attr argument. Also the type key can be omitted and the prefix type will then be set to the pools default prefix type. The find_free_prefix() function is used to find available prefixes for this allocation method, see its documentation for a description of how the args argument should be formatted.
From a prefix
A prefix can also be selected from another prefix. Also in this case the prefix key is omitted from the attr argument. See the documentation for the find_free_prefix() for a description of how the args argument is to be formatted.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.add_prefix() for full understanding.

add_vrf(*args, **kwargs)

Add a new VRF.

  • auth [BaseAuth]

    AAA options.

  • attr [vrf_attr]

    The news VRF’s attributes.

Add a VRF based on the values stored in the attr dict.

Returns a dict describing the VRF which was added.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.add_vrf() for full understanding.

edit_asn(*args, **kwargs)

Edit AS number

  • auth [BaseAuth]

    AAA options.

  • asn [integer]

    AS number to edit.

  • attr [asn_attr]

    New AS attributes.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.edit_asn() for full understanding.

edit_pool(*args, **kwargs)

Update pool given by spec with attributes attr.

  • auth [BaseAuth]

    AAA options.

  • spec [pool_spec]

    Specifies what pool to edit.

  • attr [pool_attr]

    Attributes to update and their new values.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.edit_pool() for full understanding.

edit_prefix(*args, **kwargs)

Update prefix matching spec with attributes attr.

  • auth [BaseAuth]

    AAA options.

  • spec [prefix_spec]

    Specifies the prefix to edit.

  • attr [prefix_attr]

    Prefix attributes.

Note that there are restrictions on when and how a prefix’s type can be changed; reservations can be changed to assignments and vice versa, but only if they contain no child prefixes.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.edit_prefix() for full understanding.

edit_vrf(*args, **kwargs)

Update VRFs matching spec with attributes attr.

  • auth [BaseAuth]

    AAA options.

  • spec [vrf_spec]

    Attibutes specifying what VRF to edit.

  • attr [vrf_attr]

    Dict specifying fields to be updated and their new values.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.edit_vrf() for full understanding.

find_free_prefix(auth, vrf, args)

Finds free prefixes in the sources given in args.

  • auth [BaseAuth]

    AAA options.

  • vrf [vrf]

    Full VRF-dict specifying in which VRF the prefix should be unique.

  • args [find_free_prefix_args]

    Arguments to the find free prefix function.

Returns a list of dicts.

Prefixes can be found in two ways: from a pool of from a prefix.

From a pool The args argument is set to a dict with key from-pool set to a pool spec. This is the pool from which the prefix will be assigned. Also the key family needs to be set to the adress family (integer 4 or 6) of the requested prefix. Optionally, also the key prefix_length can be added to the attr argument, and will then override the default prefix length.

Example:

args = {
    'from-pool': { 'name': 'CUSTOMER-' },
    'family': 6,
    'prefix_length': 64
}
From a prefix
Instead of specifying a pool, a prefix which will be searched for new prefixes can be specified. In args, the key from-prefix is set to the prefix you want to allocate from and the key prefix_length is set to the wanted prefix length.

Example:

args = {
    'from-prefix': '192.0.2.0/24'
    'prefix_length': 27
}

The key count can also be set in the args argument to specify how many prefixes that should be returned. If omitted, the default value is 1000.

The internal backend function find_free_prefix() is used internally by the add_prefix() function to find available prefixes from the given sources. It’s also exposed over XML-RPC, please see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.find_free_prefix() for full understanding.

list_asn(auth, asn=None)

List AS numbers matching spec.

  • auth [BaseAuth]

    AAA options.

  • spec [asn_spec]

    An automous system number specification. If omitted, all ASNs are returned.

Returns a list of dicts.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.list_asn() for full understanding.

list_pool(auth, spec=None)

Return a list of pools.

  • auth [BaseAuth]

    AAA options.

  • spec [pool_spec]

    Specifies what pool(s) to list. Of omitted, all will be listed.

Returns a list of dicts.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.list_pool() for full understanding.

list_prefix(auth, spec=None)

List prefixes matching the spec.

  • auth [BaseAuth]

    AAA options.

  • spec [prefix_spec]

    Specifies prefixes to list. If omitted, all will be listed.

Returns a list of dicts.

This is a quite blunt tool for finding prefixes, mostly useful for fetching data about a single prefix. For more capable alternatives, see the search_prefix() or smart_search_prefix() functions.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.list_prefix() for full understanding.

list_vrf(auth, spec=None)

Return a list of VRFs matching spec.

  • auth [BaseAuth]

    AAA options.

  • spec [vrf_spec]

    A VRF specification. If omitted, all VRFs are returned.

Returns a list of dicts.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.list_vrf() for full understanding.

remove_asn(*args, **kwargs)

Remove an AS number.

  • auth [BaseAuth]

    AAA options.

  • spec [asn]

    An ASN specification.

Remove ASNs matching the asn argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.remove_asn() for full understanding.

remove_pool(*args, **kwargs)

Remove a pool.

  • auth [BaseAuth]

    AAA options.

  • spec [pool_spec]

    Specifies what pool(s) to remove.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.remove_pool() for full understanding.

remove_prefix(*args, **kwargs)

Remove prefix matching spec.

  • auth [BaseAuth]

    AAA options.

  • spec [prefix_spec]

    Specifies prefixe to remove.

  • recursive [bool]

    When set to True, also remove child prefixes.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.remove_prefix() for full understanding.

remove_vrf(*args, **kwargs)

Remove a VRF.

  • auth [BaseAuth]

    AAA options.

  • spec [vrf_spec]

    A VRF specification.

Remove VRF matching the spec argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.remove_vrf() for full understanding.

search_asn(auth, query, search_options=None)

Search ASNs for entries matching ‘query’

  • auth [BaseAuth]

    AAA options.

  • query [dict_to_sql]

    How the search should be performed.

  • search_options [options_dict]

    Search options, see below.

Returns a list of dicts.

The query argument passed to this function is designed to be able to specify how quite advanced search operations should be performed in a generic format. It is internally expanded to a SQL WHERE-clause.

The query is a dict with three elements, where one specifies the operation to perform and the two other specifies its arguments. The arguments can themselves be query dicts, to build more complex queries.

The operator key specifies what operator should be used for the comparison. Currently the following operators are supported:

  • and - Logical AND
  • or - Logical OR
  • equals - Equality; =
  • not_equals - Inequality; !=
  • like - SQL LIKE
  • regex_match - Regular expression match
  • regex_not_match - Regular expression not match

The val1 and val2 keys specifies the values which are subjected to the comparison. val1 can be either any prefix attribute or an entire query dict. val2 can be either the value you want to compare the prefix attribute to, or an entire query dict.

The search options can also be used to limit the number of rows returned or set an offset for the result.

The following options are available:
  • max_result - The maximum number of prefixes to return (default 50).
  • offset - Offset the result list this many prefixes (default 0).

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.search_tag() for full understanding.

search_pool(auth, query, search_options=None)

Search pool list for pools matching query.

  • auth [BaseAuth]

    AAA options.

  • query [dict_to_sql]

    How the search should be performed.

  • search_options [options_dict]

    Search options, see below.

Returns a list of dicts.

The query argument passed to this function is designed to be able to specify how quite advanced search operations should be performed in a generic format. It is internally expanded to a SQL WHERE-clause.

The query is a dict with three elements, where one specifies the operation to perform and the two other specifies its arguments. The arguments can themselves be query dicts, to build more complex queries.

The operator key specifies what operator should be used for the comparison. Currently the following operators are supported:

  • and - Logical AND
  • or - Logical OR
  • equals - Equality; =
  • not_equals - Inequality; !=
  • like - SQL LIKE
  • regex_match - Regular expression match
  • regex_not_match - Regular expression not match

The val1 and val2 keys specifies the values which are subjected to the comparison. val1 can be either any pool attribute or an entire query dict. val2 can be either the value you want to compare the pool attribute to, or an entire query dict.

Example 1 - Find the pool whose name match ‘test’:

query = {
    'operator': 'equals',
    'val1': 'name',
    'val2': 'test'
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM pool WHERE name = 'test'

Example 2 - Find pools whose name or description regex matches ‘test’:

query = {
    'operator': 'or',
    'val1': {
        'operator': 'regex_match',
        'val1': 'name',
        'val2': 'test'
    },
    'val2': {
        'operator': 'regex_match',
        'val1': 'description',
        'val2': 'test'
    }
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM pool WHERE name ~* 'test' OR description ~* 'test'

The search options can also be used to limit the number of rows returned or set an offset for the result.

The following options are available:
  • max_result - The maximum number of pools to return (default 50).
  • offset - Offset the result list this many pools (default 0).

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.search_pool() for full understanding.

search_prefix(auth, query, search_options=None)

Search prefix list for prefixes matching query.

  • auth [BaseAuth]

    AAA options.

  • query [dict_to_sql]

    How the search should be performed.

  • search_options [options_dict]

    Search options, see below.

Returns a list of dicts.

The query argument passed to this function is designed to be able to express quite advanced search filters. It is internally expanded to an SQL WHERE-clause.

The query is a dict with three elements, where one specifies the operation to perform and the two other specifies its arguments. The arguments can themselves be query dicts, i.e. nested, to build more complex queries.

The operator key specifies what operator should be used for the comparison. Currently the following operators are supported:

  • and - Logical AND
  • or - Logical OR
  • equals_any - Equality of any element in array
  • equals - Equality; =
  • not_equals - Inequality; !=
  • less - Less than; <
  • less_or_equal - Less than or equal to; <=
  • greater - Greater than; >
  • greater_or_equal - Greater than or equal to; >=
  • like - SQL LIKE
  • regex_match - Regular expression match
  • regex_not_match - Regular expression not match
  • contains - IP prefix contains
  • contains_equals - IP prefix contains or is equal to
  • contained_within - IP prefix is contained within
  • contained_within_equals - IP prefix is contained within or equals

The val1 and val2 keys specifies the values which are subjected to the comparison. val1 can be either any prefix attribute or a query dict. val2 can be either the value you want to compare the prefix attribute to, or a query dict.

Example 1 - Find the prefixes which contains 192.0.2.0/24:

query = {
    'operator': 'contains',
    'val1': 'prefix',
    'val2': '192.0.2.0/24'
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM prefix WHERE prefix contains '192.0.2.0/24'

Example 2 - Find for all assignments in prefix 192.0.2.0/24:

query = {
    'operator': 'and',
    'val1': {
        'operator': 'equals',
        'val1': 'type',
        'val2': 'assignment'
    },
    'val2': {
        'operator': 'contained_within',
        'val1': 'prefix',
        'val2': '192.0.2.0/24'
    }
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM prefix WHERE (type == 'assignment') AND (prefix contained within '192.0.2.0/24')

If you want to combine more than two expressions together with a boolean expression you need to nest them. For example, to match on three values, in this case the tag ‘foobar’ and a prefix-length between /10 and /24, the following could be used:

query = {
    'operator': 'and',
    'val1': {
        'operator': 'and',
        'val1': {
            'operator': 'greater',
            'val1': 'prefix_length',
            'val2': 9
        },
        'val2': {
            'operator': 'less_or_equal',
            'val1': 'prefix_length',
            'val2': 24
        }
    },
    'val2': {
        'operator': 'equals_any',
        'val1': 'tags',
        'val2': 'foobar'
    }
}

The options argument provides a way to alter the search result to assist in client implementations. Most options regard parent and children prefixes, that is the prefixes which contain the prefix(es) matching the search terms (parents) or the prefixes which are contained by the prefix(es) matching the search terms. The search options can also be used to limit the number of rows returned.

The following options are available:
  • parents_depth - How many levels of parents to return. Set to -1 to include all parents.
  • children_depth - How many levels of children to return. Set to -1 to include all children.
  • include_all_parents - Include all parents, no matter what depth is specified.
  • include_all_children - Include all children, no matter what depth is specified.
  • max_result - The maximum number of prefixes to return (default 50).
  • offset - Offset the result list this many prefixes (default 0).

The options above gives the possibility to specify how many levels of parent and child prefixes to return in addition to the prefixes that actually matched the search terms. This is done by setting the parents_depth and children depth keys in the search_options dict to an integer value. In addition to this it is possible to get all all parents and/or children included in the result set even though they are outside the limits set with *_depth. The extra prefixes included will have the attribute display set to false while the other ones (the actual search result togther with the ones included due to given depth) display set to true. This feature is usable obtain search results with some context given around them, useful for example when displaying prefixes in a tree without the need to implement client side IP address logic.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.search_prefix() for full understanding.

search_tag(auth, query, search_options=None)

Search Tags for entries matching ‘query’

  • auth [BaseAuth]

    AAA options.

  • query [dict_to_sql]

    How the search should be performed.

  • search_options [options_dict]

    Search options, see below.

Returns a list of dicts.

The query argument passed to this function is designed to be able to specify how quite advanced search operations should be performed in a generic format. It is internally expanded to a SQL WHERE-clause.

The query is a dict with three elements, where one specifies the operation to perform and the two other specifies its arguments. The arguments can themselves be query dicts, to build more complex queries.

The operator key specifies what operator should be used for the comparison. Currently the following operators are supported:

  • and - Logical AND
  • or - Logical OR
  • equals - Equality; =
  • not_equals - Inequality; !=
  • like - SQL LIKE
  • regex_match - Regular expression match
  • regex_not_match - Regular expression not match

The val1 and val2 keys specifies the values which are subjected to the comparison. val1 can be either any prefix attribute or an entire query dict. val2 can be either the value you want to compare the prefix attribute to, or an entire query dict.

The search options can also be used to limit the number of rows returned or set an offset for the result.

The following options are available:
  • max_result - The maximum number of prefixes to return (default 50).
  • offset - Offset the result list this many prefixes (default 0).

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.search_asn() for full understanding.

search_vrf(auth, query, search_options=None)

Search VRF list for VRFs matching query.

  • auth [BaseAuth]

    AAA options.

  • query [dict_to_sql]

    How the search should be performed.

  • search_options [options_dict]

    Search options, see below.

Returns a list of dicts.

The query argument passed to this function is designed to be able to specify how quite advanced search operations should be performed in a generic format. It is internally expanded to a SQL WHERE-clause.

The query is a dict with three elements, where one specifies the operation to perform and the two other specifies its arguments. The arguments can themselves be query dicts, to build more complex queries.

The operator key specifies what operator should be used for the comparison. Currently the following operators are supported:

  • and - Logical AND
  • or - Logical OR
  • equals - Equality; =
  • not_equals - Inequality; !=
  • like - SQL LIKE
  • regex_match - Regular expression match
  • regex_not_match - Regular expression not match

The val1 and val2 keys specifies the values which are subjected to the comparison. val1 can be either any prefix attribute or an entire query dict. val2 can be either the value you want to compare the prefix attribute to, or an entire query dict.

Example 1 - Find the VRF whose VRF match ‘65000:123’:

query = {
    'operator': 'equals',
    'val1': 'vrf',
    'val2': '65000:123'
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM vrf WHERE vrf = '65000:123'

Example 2 - Find vrf whose name or description regex matches ‘test’:

query = {
    'operator': 'or',
    'val1': {
        'operator': 'regex_match',
        'val1': 'name',
        'val2': 'test'
    },
    'val2': {
        'operator': 'regex_match',
        'val1': 'description',
        'val2': 'test'
    }
}

This will be expanded to the pseudo-SQL query:

SELECT * FROM vrf WHERE name ~* 'test' OR description ~* 'test'

The search options can also be used to limit the number of rows returned or set an offset for the result.

The following options are available:
  • max_result - The maximum number of prefixes to return (default 50).
  • offset - Offset the result list this many prefixes (default 0).

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.search_vrf() for full understanding.

smart_search_asn(auth, query_str, search_options=None, extra_query=None)

Perform a smart search operation among AS numbers

  • auth [BaseAuth]

    AAA options.

  • query_str [string]

    Search string

  • search_options [options_dict]

    Search options. See search_asn().

  • extra_query [dict_to_sql]

    Extra search terms, will be AND:ed together with what is extracted from the query string.

Return a dict with three elements:
  • interpretation - How the query string was interpreted.
  • search_options - Various search_options.
  • result - The search result.

The interpretation is given as a list of dicts, each explaining how a part of the search key was interpreted (ie. what ASN attribute the search operation was performed on).

The result is a list of dicts containing the search result.

The smart search function tries to convert the query from a text string to a query dict which is passed to the search_asn() function. If multiple search keys are detected, they are combined with a logical AND.

See the search_asn() function for an explanation of the search_options argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.smart_search_asn() for full understanding.

smart_search_pool(auth, query_str, search_options=None, extra_query=None)

Perform a smart search on pool list.

  • auth [BaseAuth]

    AAA options.

  • query_str [string]

    Search string

  • search_options [options_dict]

    Search options. See search_pool().

  • extra_query [dict_to_sql]

    Extra search terms, will be AND:ed together with what is extracted from the query string.

Return a dict with three elements:
  • interpretation - How the query string was interpreted.
  • search_options - Various search_options.
  • result - The search result.

The interpretation is given as a list of dicts, each explaining how a part of the search key was interpreted (ie. what pool attribute the search operation was performed on).

The result is a list of dicts containing the search result.

The smart search function tries to convert the query from a text string to a query dict which is passed to the search_pool() function. If multiple search keys are detected, they are combined with a logical AND.

It will basically just take each search term and try to match it against the name or description column with regex match.

See the search_pool() function for an explanation of the search_options argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.smart_search_pool() for full understanding.

smart_search_prefix(auth, query_str, search_options=None, extra_query=None)

Perform a smart search on prefix list.

  • auth [BaseAuth]

    AAA options.

  • query_str [string]

    Search string

  • search_options [options_dict]

    Search options. See search_prefix().

  • extra_query [dict_to_sql]

    Extra search terms, will be AND:ed together with what is extracted from the query string.

Return a dict with three elements:
  • interpretation - How the query string was interpreted.
  • search_options - Various search_options.
  • result - The search result.

The interpretation is given as a list of dicts, each explaining how a part of the search key was interpreted (ie. what prefix attribute the search operation was performed on).

The result is a list of dicts containing the search result.

The smart search function tries to convert the query from a text string to a query dict which is passed to the search_prefix() function. If multiple search keys are detected, they are combined with a logical AND.

It tries to automatically detect IP addresses and prefixes and put these into the query dict with “contains_within” operators and so forth.

See the search_prefix() function for an explanation of the search_options argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.smart_search_prefix() for full understanding.

smart_search_vrf(auth, query_str, search_options=None, extra_query=None)

Perform a smart search on VRF list.

  • auth [BaseAuth]

    AAA options.

  • query_str [string]

    Search string

  • search_options [options_dict]

    Search options. See search_vrf().

  • extra_query [dict_to_sql]

    Extra search terms, will be AND:ed together with what is extracted from the query string.

Return a dict with three elements:
  • interpretation - How the query string was interpreted.
  • search_options - Various search_options.
  • result - The search result.

The interpretation is given as a list of dicts, each explaining how a part of the search key was interpreted (ie. what VRF attribute the search operation was performed on).

The result is a list of dicts containing the search result.

The smart search function tries to convert the query from a text string to a query dict which is passed to the search_vrf() function. If multiple search keys are detected, they are combined with a logical AND.

It will basically just take each search term and try to match it against the name or description column with regex match or the VRF column with an exact match.

See the search_vrf() function for an explanation of the search_options argument.

This is the documentation of the internal backend function. It’s exposed over XML-RPC, please also see the XML-RPC documentation for nipap.xmlrpc.NipapXMLRPC.smart_search_vrf() for full understanding.

nipap.backend.requires_rw(f)

Adds readwrite authorization

This will check if the user is a readonly user and if so reject the query. Apply this decorator to readwrite functions.