IRRToolSet 5.1.2 released , error: possibly undefined macro:

Glen Turner Glen.Turner at aarnet.edu.au
Mon Oct 21 23:56:14 UTC 2019


[well rambling, sorry]

Mark Prior wrote:
> 
> It would depend a lot on when you started generating your
> configuration this way. I spent a lot of effort at AS2764 and AS7575
> getting RtConfig to do what I wanted but the only alternative was to
> roll your own code. Bgpq3 is much more recent and if you were
> starting out now it would probably be a better starting place.

Related: migrating from one tool to another is non-trivial. In order to
adequately show that IRRToolSet and Bgpq3 are doing the same thing it's
likely that I'll have to simulate the entire AS7575 network using
Juniper's online services, inject BGP routes into that, and compare old
and new forwarding tables on every router.

BTW, I'd suggest the following workflow if I were deploying a router
network:

 - Git holds YAML files, one describing each service (client, peer,
etc). There are "configuration management databases" (CMDB) you could
use instead, but they don't seem to bring much value.  If you do choose
a CMDB then it must have "inventory plugin" for Ansible.

 - Gitlab runners (or other CI tool like Jenkins) 'compile' all that
YAML/CMDB into Ansible. Bgpq3 is used to expand macros in the YAML into
prefix and AS lists.

 - Ansible uses Netconf if possible, Napalm otherwise, to maintain
routers. CI tool runs every router every night.  If you were brave
you'd use a triggered approach. If you are using a CMDB you might
choose to run bgpq3 at this stage instead of earlier.

 - CI tool reports status into a Slack channel. Upon a failure it
creates a JIRA ticket and puts full details into that.

 - Once done, use Ansible to back up the router's running configuration
into Git. The idea here is that a JIRA ticket ID from a Git commit
comment to the YAML/CMDB propogates through every stage including this
one. So we can track every change to every router's configuration to a
ticket -- that is, every change can be traced to the intent to make a
change. This is called "traceability": it's very useful for operations,
and a keystone of actual real cybersecurity (dating back to the Orange
Book).

The above isn't a recommendation of products (some of the above I'd
swap out in an instant) but product names are great for putting into
Google, and thus getting your head around a concrete automation
workflow.

On a detailed level, you need to choose where to express your router's
BGP policy: in the automation code with the detail supplied from IRR or
in RPSL letting that produce the configuraton.  One of the very
impressive things about using RPSL was the way Mark migrated AS7575
from Cisco to Procket (RIP) to Juniper with low operational risk.  On
the flip side, there's some munging to the generated router
configuration (to add passwords, prefix-limits, etc).

My gut feel is that the choice depends on how complex your policy is,
and how good your Ansible templating is.  A complex policy argues for
RPSL. Good automation templating is an argument for keeping the RPSL
simple and implementing multiple vendors in the templates.  Mark would
have a better feel for this than me.

It's not clear to me how YANG and RPSL will eventually integrate, there
are proposals like [1] but there's no tooling. We might need add one
final router model to IRRToolSet.  Anyway, whatever workflow you build
probably needs to allow for a future with a YANG expression of the
routing policy, in much the same way that at the moment you need to
allow for a YANG expression of interface configuration.

-glen


[1] https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-07



More information about the irrtoolset mailing list