For the complete documentation index, see llms.txt. This page is also available as Markdown.

lab04-BGP-CLOS

Task Underlay. BGP

Set up BGP in the underlay network to establish IP connectivity between all network devices.

Network diagram

stand-plan

The lab is built using the following role-based device mapping host- linux, leaf - frr, spine - arista

Underlay IP Address Allocation

• Underlay addressing follows the format 10.x.y.z, where:

⁠◦ x = Data Center ID

⁠◦ y = Spine switch ID

⁠◦ z = Sequential host address per leaf connection

• Host addressing uses the 172.16.x.z/24 format, where:

⁠◦ x = Leaf switch ID

⁠◦ z = Sequential host address

⁠◦ Each leaf switch uses .1 as its own IP in the corresponding subnet

• Loopback addressing uses 192.168.a.b/32, where:

⁠◦ a = 1 for spine switches

⁠◦ a = 2 for leaf switches

⁠◦ b = Spine or leaf ID (assigned sequentially)

• IPv6 addressing uses fd00::[IPv4]

Interconnect ipv4 ipv6

Device A
Interface A
IPv4 A
IPv6 A
Device B
Interface B
IPv4 B
IPv6 B

Spine-1

Eth1

10.1.1.0/31

fd00::10:1:1:0/127

Leaf-1

Eth8

10.1.1.1/31

fd00::10:1:1:1/127

Spine-1

Eth2

10.1.1.2/31

fd00::10:1:1:2/127

Leaf-2

Eth8

10.1.1.3/31

fd00::10:1:1:3/127

Spine-1

Eth3

10.1.1.4/31

fd00::10:1:1:4/127

Leaf-3

Eth8

10.1.1.5/31

fd00::10:1:1:5/127

Spine-2

Eth2

10.1.2.0/31

fd00::10:2:1:0/127

Leaf-1

Eth9

10.1.2.1/31

fd00::10:2:1:1/127

Spine-2

Eth2

10.1.2.2/31

fd00::10:2:1:2/127

Leaf-2

Eth9

10.1.2.3/31

fd00::10:2:1:3/127

Spine-2

Eth3

10.1.2.4/31

fd00::10:2:1:4/127

Leaf-3

Eth9

10.1.2.5/31

fd00::10:2:1:5/127

Host-1

Eth1

172.16.1.2/24

fd00::172:16:1:2/116

Leaf-1

Eth1

172.16.1.1/24

fd00::172:16:1:1/116

Host-2

Eth1

172.16.2.2/24

fd00::172:16:2:2/116

Leaf-2

Eth1

172.16.2.1/24

fd00::172:16:2:1/116

Host-3

Eth1

172.16.3.2/24

fd00::172:16:3:2/116

Leaf-3

Eth1

172.16.3.1/24

fd00::172:16:3:1/116

Host-4

Eth1

172.16.4.2/24

fd00::172:16:4:2/116

Leaf-3

Eth2

172.16.4.1/24

fd00::172:16:4:1/116

loopback

Device
Loopback ipv4
loopback ipv6

Spine-1

192.168.1.1

fd00::192:168:1:1

Spine-2

192.168.1.2

fd00::192:168:1:2

Leaf-1

192.168.2.1

fd00::192:168:2:1

Leaf-2

192.168.2.2

fd00::192:168:2:2

Leaf-3

192.168.2.3

fd00::192:168:2:3

AS Numbering Scheme - spine AS 65000 leaf AS 6500x, x - leaf index

AS List below

Device
AS number

Spine-1

65000

Spine-2

65000

Leaf-1

65001

Leaf-2

65002

Leaf-3

65003

Since task doesn't contain instructions for host IP addressing, and both leaf and spine nodes are implemented as routers, host IPs are assigned from separate subnets prior to overlay configuration. This ensures basic connectivity while keeping underlay and overlay roles clearly separated.

Once the overlay is deployed, we’ll place all hosts into a single subnet to emulate Layer 2 connectivity.

Launching a lab in the Netlab

Netlab Usage Notes:

  1. As observed in earlier attempts, BFD does not reliably start from the initial configuration file. To address this, I modified the following module: /usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.yml I added the bfd parameter under the node section to ensure BFD is properly initialized during BGP setup.

bgp.yml
  1. Add to macros /usr/local/lib/python3.10/dist-packages/netsim/ansible/templates/bgp/eos.macro.j2 /usr/local/lib/python3.10/dist-packages/netsim/ansible/templates/bgp/frr.j2 code for bfd

add to eos.macro.j2
add to frr.j2

And after all these tweaks, I realized the obvious: always read the documentation carefully.

That’s how I discovered the bgp.session plugin — which not only enables BFD, but also provides full control over BGP session parameters.

While digging through the docs, I also came across EdgeShark — a built-in tool that allows you to Capture traffic, Inspect routing information, Monitor links directly from Netlab instances.

I’ll showcase its powerful features in the screenshots below. Enabling it takes just two lines.

File Topology For quick reference, here’s the inline listing:

topology.yml

Validating

spine-1
spine-2

Verify ping reachability to all device loopbacks from leaf-2

leaf-2 pings 1st try

And we couldn’t see anyone but ourselves. That’s exactly when EdgeShark came in handy.

It not only shows us a flat list of connections, but also allows us to capture traffic.

We can see that the source address is taken from the outgoing interface. The ICMP request reaches the target host, but the reply cannot be formed, because the receiving leaf has no knowledge of how other leafs are connected to the spine — it only has routes to loopbacks.In FRR, it's not possible to set the source address directly from the vtysh shell for ping. That’s why we run the ping from the system shell, where we can specify the source IP explicitly.

leaf-2 pings 2nd try

Device configuration files:

Spine-1 Spine-2 Leaf-1 Leaf-2 Leaf-3

Last updated