netreplica / nrx Goto Github PK

nrx --init to download templates and example configuration file into $HOME/.nr

Platform for SW => Clab kind

• slug as platform
• name as plaform_name

Also export the following Device data for future use, for example, as Clab type when supported

• Manufacturer slug as vendor
• Manufacturer name as vendor_name
• Model slug as model
• Model name as model_name

Currently, only Cables directly connected to Device Interfaces are exported into a topology. To cover connections via patch panels and circuits, nrx needs to use netbox tracing API.

Requested with a proposed implementation by @frederic-loui
netreplica/templates#12

Create a mechanism to define which kind template should be used for platform values exported from netbox, without using symlinks in the templates. Use of symlinks forces users to maintain custom template repository copies, and this complicates the ability to pull the latest addition to the templates.

Having a single site is nice, but for backbones or other large interconnected networks, having a single topology showing all sites, or multiple sites would be helpful.

• get device config from netbox
• save non-empty device config as a file
• render clab topo with startup-configs
• render cml topo with embedded configs
• parameter to control config rendering
• save configs and interface maps into a subfolder

Direct visualization of netbox data using netreplica/graphite

nrx.py --input netbox --output graphite --site dc1

this should create a file dc1.graphite.json:

rm topology.graphite.json
cp dc1.graphite.json topology.graphite.json
TOPOLOGY="$(pwd)/topology.graphite.json"

To visualize the file

docker run -d -t --rm \
  --mount type=bind,source="${TOPOLOGY}",target=/htdocs/default/default.json,readonly \
  -p 8080:80 \
  --name graphite \
  netreplica/graphite

Open http://localhost:8080/graphite/index.html to see the visualization

To map a folder with clab-{topology.name} subdirectories, use:

CLABDIR=$(pwd)
docker run -d -t --rm \
  -v "${CLABDIR}":/htdocs/lab:ro \
  -p 8080:80 \
  --name graphite \
  netreplica/graphite:nanog86

If a user has a customized platforms_map.yaml it would be better to store it outside of templates folder, so it won't be overwritten or conflict with git.

Since the file is searched through the same methods as the templates, would it have more sense to store the edited file under a custom folder where the custom templates could be stored as well? The custom folder could be placed under .nr by the user, or any other place, and path to it added to nrx.conf.

Alternatively, PLATFORM_MAP key in the nrx.conf could be used as well, as a replacement for -M parameter.

It might be useful to use $HOME/.nr/platform_map.yaml as a default value for PLATFORM_MAP, instead of current platform_map.yaml. [Implementation comment] didn't change the default, since it can be easily accomplished now via the combination if PLATFORM_MAP key in the nrx.conf and $HOME/.nr/platform_map.yaml value.

Is it possible to improve usability of template paths in nrx.conf by leveraging $HOME env var, instead using an absolute path? [Implementation comment] yes, implemented for several path-related parameters.

Currently, when two devices are on different sites and are connected via a circuit, they can't be both exported:

./nrx.py -c main.conf -s colo -o clab -d
...
Debug: Traced sw1 Ethernet21 <-> dc1-spine-1 Ethernet21/1: [[Ethernet21], colo-dc1 <> Ethernet21, [colo-dc1: Termination A], [colo-dc1: Termination Z], colo-dc1 <> Ethernet21/1, [Ethernet21/1]]
Debug: One or both devices for this connection are not in the export graph
...

We need a different way to filter devices using tags instead of site name. For example, if we have a tag wan assigned to sw1 and dc1-spine-1 devices, they should both be exported with a connection between them:

./nrx.py -c main.conf -t wan -o clab -d

Note,-t flag is currently used for --templates and needs to be reassigned for --tags as such usage would be more common, while templates path would more typically be configured in the configuration file. As a flag, -T should be used as a short for --templates

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency MarkupSafe to v2.1.5
• Update dependency urllib3 to v2.2.1
• Update dependency certifi to v2024
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hi, Thanks for nrx development. We are managing a WAN network with mostly one hardware in each site.
What would be your recommandation in order to use nrx in that context ? Would there be in the long run:
1- a mode considering all nodes from a list of sites (e.g. sites=all)
2- consider circuit/uplink connectivity betwwen these sites ?
Thanks/Frederic

Even if two interconnected devices should be present in the exported topology, it is sometimes necessary to limit the list of connections between them to a certain subset. For example, in a multi-tenant setup, some links maybe dedicated for one customer, and other links to another. To filter a list of connections tags could be used.

Requestor: @frederic-loui

When running against a large topology with 10+ devices and many cables the export fails with the error

Error: NetBox API failure at get cables: The request failed with code 414 Request-URI Too Large but more specific details were not returned in json. Check the NetBox Logs or investigate this exception's error attribute.

Hi !
I'm testing nrx against netbox 3.1.11 and i git the output below.

./nrx.py --output clab --config nrx.conf -d
Debug: arguments Namespace(config='nrx.conf', input='netbox', output='clab', api=None, site=None, insecure=None, debug=True, file=None, templates=None)
Debug: returned site data GENEVA
Exporting NetBox 'GENEVA' site from:            https://nbx.rare.nmaas.eu
Debug: Added device: {'id': 12, 'type': 'device', 'name': 'E513-E-YECWH-1', 'node_id': 0, 'platform': 'unknown', 'platform_name': 'unknown', 'vendor': 'unknown', 'vendor_name': 'unknown', 'model': 'wedge-100bf-32qs', 'model_name': 'Wedge 100BF-32QS', 'role': 'gp4l-node', 'device_index': 0}
Debug: E513-E-YECWH-1 Ethernet interfaces:
Debug: E513-E-YECWH-1 : sdn3 : 100gbase-x-qsfp28
Debug: Added device: {'id': 6, 'type': 'device', 'name': 'GVA0001', 'node_id': 2, 'platform': 'unknown', 'platform_name': 'unknown', 'vendor': 'unknown', 'vendor_name': 'unknown', 'model': 'wedge-100bf-32x', 'model_name': 'Wedge 100BF-32X', 'role': 'gp4l-node', 'device_index': 1}
Debug: GVA0001 Ethernet interfaces:
Debug: GVA0001 : sdn2 : 100gbase-x-qsfp28
Error: Exporting from NetBox: object has no attribute "a_terminations"

I'm using rare clab kind so I added rare.j2 in template folder:

        {{ name }}:
            kind: rare
            image: ghcr.io/rare-freertr/freertr-containerlab:latest
            labels:
                graph-icon: switch
                {% include 'clab/labels.j2' %}

Do i miss something ?

As it is a cloud service, should I ask my admin to update to netbox 3.5.0 ?

avoid excessive logging like this:

Debug: [TEMPLATE] Unable to open interface map template 'clab/interface_maps/linux.j2' for platform 'linux' with path ['../../../templates']. Reason: clab/interface_maps/linux.j2