Link Definition Examples

This document contains way too many link definition examples, ranging from simple links to complex topologies emulating bridging loops.

Some examples include the resulting internal data structure (link data dictionary with interfaces list) generated in an early phase of topology transformation process.

Simple Links with No Link Attributes

When you need a connection between lab devices with no extra attributes, use the string format.

Stub Interface

nodes: [ r1 ]
links:
- r1

… creates a link with a single node attached to it. The resulting list has one entry with no other attribute than an interfaces list – list of nodes connected to the link (identified by node attribute):

links:
- interfaces:
  - node: r1

Point-to-Point Interface

Use a-b syntax to create a point-to-point link between nodes A and B:

nodes: [ r1,r2 ]
links:
- r1-r2

Not surprisingly, the intefaces list in the link definition has two nodes (r1 and r2):

- interfaces:
  - node: r1
  - node: r2

Multi-Access Interface

You can extend the string syntax to multiple nodes, for example:

nodes: [ r1,r2,r3 ]
links:
- r1-r2-r3

Result:

- interfaces:
  - node: r1
  - node: r2
  - node: r3

Crazy Scenarios

Finally, it’s perfectly OK to have the same node connected to a link more than once. Here’s a potential bridging loop in case you want to figure out how your device reacts to it:

nodes: [ r1 ]
links:
- r1-r1

Result:

- interfaces:
  - node: r1
  - node: r1

Links with Link or Interface Attributes

You can cover simple lab topologies with the string format, but you’ll quickly get to a point where you’ll want to specify additional link attributes. To do that, you have to use a dictionary format of link description.

A dictionary format is always translated into the canonical format with interfaces list. That format is a bit cumbersome to work with, so you can use a simplified format specifying nodes connected to the link as dictionary keys.

Warning

You cannot use the dictionary format if you want to have the same node attached to a link multiple times.

Stub Link with OSPF Area

Imagine a multi-area OSPF topology where you want to put stub links into different OSPF areas:

module: [ ospf ]
nodes: [ r1 ]
links:
- r1:
  ospf.area: 3

Keys in the link dictionary are checked against node names. Nodes are moved into interfaces list, the other elements are left unchanged.

links:
- interfaces:
  - node: r1
  ospf:
    area: 3

Links with Multiple Nodes

The same approach can be used for point-to-point and multi-access links. The following topology file…

nodes: [ r1,r2,r3 ]
links:
- r1:
  r2:
  r3:
  bandwidth: 3

… generates this data structure:

links:
- bandwidth: 3
  interfaces:
  - node: r1
  - node: r2
  - node: r3

Links with Interface Attributes

Each interface (node-to-link attachment) can have its own attributes specified as a dictionary under the node key. For example, you might want to set OSPF cost and disable BFD for a single node on a multi-access link:

module: [ ospf,bfd ]
nodes: [ r1,r2,r3 ]
links:
- r1:
    ospf.cost: 5
    ospf.bfd: False
  r2:
  r3:
  bandwidth: 3000

The link attributes are retained (as before); the nodes and their attributes are moved into the interfaces list:

links:
- bandwidth: 3000
  interfaces:
  - node: r1
    ospf:
      bfd: false
      cost: 5
  - node: r2
  - node: r3

Complex Scenarios

If you want to have link (or interface) attributes in a complex scenario with multiple connections from a node to a link, you have to use the dictionary-with-interfaces format, for example:

links:
- bandwidth: 3000
  interfaces:
  - node: r1
  - node: r1

You can freely combine all three formats, for example:

nodes: [ r1, r2, r3 ]

links:
- r1
- r1-r2
- r1:
  r3:
  type: lan
- interfaces:
  - node: r1
  - node: r1
  bandwidth: 3000