In the Concise Link Descriptions blog post, I described various data formats that you could use to concisely list nodes attached to a link. Today, we’ll focus on a mechanism that helps you spot errors in your topology: a dictionary of links.

Imagine you have a large topology with dozens of links, and you get an error saying, “there is this problem with links[17]”. It must be great fun counting the links to find which one triggered the error, right?

For example, the following topology creates an error because netlab tries to use a /30 prefix on the last link and belatedly figures out it needs one more IP address for the VRRP first-hop gateway:

defaults.device: frr

module: [ gateway ]
gateway.protocol: vrrp

nodes: [ a1, a2, c1, c2 ]
addressing.p2p:
  ipv4: 10.0.42.0/28

links: 
- a1-c1
- a1-c2
- a2-c1
- a2-c2
- c1-c2
- a1:
  a2:
  gateway: True

% netlab up
[ERRORS]  Errors found in topology.yml
[VALUE]   links: Cannot use ipv4 prefix 10.1.0.20/30 to address 2 nodes plus first-hop gateway on links[6]
[DATA]    link data: {'_linkname': 'links[6]', 'gateway': {'id': -2, 'protocol': 'vrrp', 'anycast':
          {'mac': '0200.cafe.00ff', 'unicast': True}, 'vrrp': {'group': 1}, 'ipv4': '10.1.0.22/30'},
          'interfaces': [{'node': 'a1', 'gateway': {'ipv4': '10.1.0.22/30'}}, {'node': 'a2',
          'gateway': {'ipv4': '10.1.0.22/30'}}], 'linkindex': 6, 'node_count': 2, 'type': 'p2p',
          'prefix': {'ipv4': '10.1.0.20/30'}}
[HINT]    Use a custom pool with prefix /29 or shorter on links with default gateways
[FATAL]   Cannot proceed beyond this point due to errors, exiting

I’m pretty sure you have better things to do than counting which link is the sixth one.

The dictionary of links feature allows you to group links with common functionality. For example, our topology has core, access and edge links:

defaults.device: frr

module: [ gateway ]
gateway.protocol: vrrp

nodes: [ a1, a2, c1, c2 ]

links: 
  access:
  - a1-c1
  - a1-c2
  - a2-c1
  - a2-c2

  core:
  - c1-c2

  edge:
  - a1:
    a2:
    gateway: True

It’s much easier to spot errors when using a structured dictionary of links as the link names include the groups you specified in the links data structure:

% netlab up
[ERRORS]  Errors found in topology.yml
[VALUE]   links: Cannot use ipv4 prefix 10.1.0.20/30 to address 2 nodes plus first-hop gateway on links.edge[1]
[DATA]    link data: {'_linkname': 'links.edge[1]', 'gateway': {'id': -2, 'protocol': 'vrrp',
          'anycast': {'mac': '0200.cafe.00ff', 'unicast': True}, 'vrrp': {'group': 1}, 'ipv4':
          '10.1.0.22/30'}, 'interfaces': [{'node': 'a1', 'gateway': {'ipv4': '10.1.0.22/30'}},
          {'node': 'a2', 'gateway': {'ipv4': '10.1.0.22/30'}}], 'linkindex': 6, 'node_count': 2,
          'type': 'p2p', 'prefix': {'ipv4': '10.1.0.20/30'}}
[HINT]    Use a custom pool with prefix /29 or shorter on links with default gateways
[FATAL]   Cannot proceed beyond this point due to errors, exiting

To recap:

• The links data structure in a netlab topology can be a list of links or a dictionary.
• The values of the links dictionary can be lists of links or further dictionaries.
• Very early in the topology transformation process, netlab flattens the links dictionary into a list of links, retaining the dictionary keys in the _linkname element to ease troubleshooting.

Similar topics:

• Concise Link Descriptions
• Simplify netlab Topologies with Link Groups
• Using VLAN and VRF Links