Deploying a community with CrewAI’s MAS (multi-agent system)
For this use-case, complete topology was deployed on a pre-built Debian 12 UTM VM (as a sandbox setting). This was deliberatly chosen because it comes with all related packages like containerlab and docker packages pre-installed. Containerlab helps spin up varied container primarily based networking topologies with ease. Following topology was chosen which consisted of linux containers and Nokia’s SR Linux containers:
Client1 — — Leaf1 — — Spine1 — — Leaf2 — — Client2
The place Client1 and Client2 are linux containers and Leaf1 and Leaf2 are IXR-D2L and Spine1 is IXR-D5 kinds of SR Linux containers.
Following is the summarized workflow of every agent:
- Doc Specialist Agent
Goes over the given web site url and extracts the set up steps, community topology deployment steps and finds node connection directions. Following is the pattern code to create agent, job and its customized instrument:
# Customized instrument to extract content material from a given webpage
class QuickstartExtractor(BaseTool):
identify: str = "WebPage Content material extractor"
description: str = "Get all of the content material from a webpage"def _run(self) -> str:
url = "https://be taught.srlinux.dev/get-started/lab/"
response = requests.get(url)
response.raise_for_status()
return response.textual content
# Create doc specialist Agent
doc_specialist = Agent(
function="Documentation Specialist",
objective="Extract and set up containerlab quickstart steps",
backstory="""Knowledgeable in technical documentation with concentrate on clear,
actionable set up and setup directions.""",
verbose=True,
instruments = [QuickstartExtractor()],
allow_delegation=False
)
# Activity for doc speaclist Agent
doc_task = Activity(
description=(
"From the containerlab quickstart information:n"
"1. Extract set up steps n"
"2. Establish topology deployment steps n"
"3. Discover node connection directions n"
"Current in a transparent, sequential format.n"
),
expected_output="Listing of instructions",
agent=doc_specialist
)
As soon as run, following is an instance output (Closing Reply) from the agent:
# Agent: Documentation Specialist
## Closing Reply:
```bash
# Set up Steps
curl -sL https://containerlab.dev/setup | sudo -E bash -s "all"# Topology Deployment Steps
sudo containerlab deploy -c -t https://github.com/srl-labs/srlinux-getting-started
# Node Connection Directions
ssh leaf1
```
As may be seen, it has clearly extracted the specified steps from the url. That is then handed on to the subsequent agent.
Observe: Including code for all of the brokers will make this text prolonged. Kindly examine my github repo for extra particulars: AI-Agents-For-Networking.
2. Linux Configuration Agent
Executes the instructions obtained from Doc specialist agent. Its given the login particulars for UTM VM and instructed to execute the instructions on that VM. It finishes by checking that each one docker containers all operating. It additionally checks the well being of the VM earlier than performing any containerlab/docker instructions.
The output (Closing Reply) from this agent clearly reveals profitable execution of VM well being checks, containerlab and docker instructions:
# Agent: Linux Command Executor and Docker Orchestrator
## Closing Reply:
1. **System Uptime Test**:
- Output: `14:56:17 up 1 day, 20:25, 60 customers, load common: 0.01, 0.39, 0.86`2. **Disk Utilization Test**:
- Output:
```
Filesystem Measurement Used Avail Use% Mounted on
udev 5.9G 0 5.9G 0% /dev
tmpfs 1.2G 1.3M 1.2G 1% /run
/dev/mapper/debian--vg-root 61G 5.7G 52G 10% /
tmpfs 5.9G 0 5.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda2 456M 92M 340M 22% /boot
/dev/sda1 511M 5.9M 506M 2% /boot/efi
tmpfs 1.2G 0 1.2G 0% /run/person/1000
```
3. **Working Processes Test**:
- Output: (truncated for brevity)
```
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 168128 12792 ? Ss Nov25 1:28 /sbin/init
...
debian 106849 0.0 0.0 8244 4992 pts/0 Ss+ Nov25 0:09 -bash
```
4. **Community Connectivity Test**:
- Output:
```
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of information.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=15.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 acquired, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 15.316/16.778/20.466/2.142 ms
```
5. **Containerlab Set up Test**:
- Containerlab is already put in and is on the newest model (0.59.0).
6. **Topology Deployment Output**:
- Output of the deployed topology:
```
+---+---------+--------------+------------------------------------+---------------+---------+----------------+----------------------+
| # | Title | Container ID | Picture | Variety | State | IPv4 Deal with | IPv6 Deal with |
+---+---------+--------------+------------------------------------+---------------+---------+----------------+----------------------+
| 1 | client1 | ab894528a0e9 | ghcr.io/srl-labs/network-multitool | linux | operating | 172.20.20.4/24 | 3fff:172:20:20::4/64 |
| 2 | client2 | 6f9f0822be5d | ghcr.io/srl-labs/network-multitool | linux | operating | 172.20.20.2/24 | 3fff:172:20:20::2/64 |
| 3 | leaf1 | e7a1a3874600 | ghcr.io/nokia/srlinux:24.7.2 | nokia_srlinux | operating | 172.20.20.3/24 | 3fff:172:20:20::3/64 |
| 4 | leaf2 | ed4399b8f7d6 | ghcr.io/nokia/srlinux:24.7.2 | nokia_srlinux | operating | 172.20.20.5/24 | 3fff:172:20:20::5/64 |
| 5 | spine1 | ada601805590 | ghcr.io/nokia/srlinux:24.7.2 | nokia_srlinux | operating | 172.20.20.6/24 | 3fff:172:20:20::6/64 |
+---+---------+--------------+------------------------------------+---------------+---------+----------------+----------------------+
```
7. **Listing of Working Docker Containers**:
- Output:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ada601805590 ghcr.io/nokia/srlinux:24.7.2 "/tini -- fixuid -q …" 4 minutes in the past Up 4 minutes spine1
6f9f0822be5d ghcr.io/srl-labs/network-multitool "/bin/sh /docker/ent…" 4 minutes in the past Up 4 minutes 22/tcp, 80/tcp, 443/tcp, 1180/tcp, 11443/tcp client2
e7a1a3874600 ghcr.io/nokia/srl-labs/network-multitool "/bin/sh /docker/ent…" 4 minutes in the past Up 4 minutes leaf1
ab894528a0e9 ghcr.io/nokia/srl-labs/network-multitool "/bin/sh /docker/ent…" 4 minutes in the past Up 4 minutes client1
ed4399b8f7d6 ghcr.io/nokia/srlinux:24.7.2 "/tini -- fixuid -q …" 4 minutes in the past Up 4 minutes leaf2
```
All duties accomplished efficiently with the suitable outputs!
3. Community Configuration Specialist Agent
The job of this agent is to know the topology i.e. the variety of nodes and their connectivity. It then must give you ip allocation scheme, generate related interface and routing configuration of linux containers and SR Linux containers alongwith adhering to the ip allocation scheme.
For SR Linux configuration an instance config was given within the immediate. This instance config might have additionally been obtained from a configuration information in pdf format which might have been RAGed by the agent (given the proper instruments).
Within the output of this agent under, it may well clearly be seen that it has succesfully give you ip allocation primarily based on the topology, the related configurations and routes:
# Agent: Senior Community Administrator
## Closing Reply:
# Configuration for client1 (Linux)
```bash
/sbin/ip deal with add 10.1.1.2/24 dev eth1
/sbin/ip route add 10.1.4.2/32 by way of 10.1.1.1
```# Configuration for leaf1 (SRLinux)
```bash
enter candidate non-public
# configure information interfaces
set / interface ethernet-1/1 admin-state allow
set / interface ethernet-1/1 subinterface 0 admin-state allow
set / interface ethernet-1/1 subinterface 0 ipv4 deal with 10.1.1.1/24
set / interface ethernet-1/1 subinterface 0 ipv4 admin-state allow
set / interface ethernet-1/49 admin-state allow
set / interface ethernet-1/49 subinterface 0 admin-state allow
set / interface ethernet-1/49 subinterface 0 ipv4 deal with 10.1.2.1/24
set / interface ethernet-1/49 subinterface 0 ipv4 admin-state allow
# add interfaces to default namespace
set / network-instance default interface ethernet-1/1.0
set / network-instance default interface ethernet-1/49.0
# configure BGP
set / network-instance default protocols bgp admin-state allow
set / network-instance default protocols bgp router-id 1.1.1.1
set / network-instance default protocols bgp autonomous-system 65001
set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state allow
set / network-instance default protocols bgp group ebgp admin-state allow
set / network-instance default protocols bgp group ebgp export-policy [ export-all ]
set / network-instance default protocols bgp group ebgp import-policy [ export-all ]
set / network-instance default protocols bgp neighbor 10.1.2.2 admin-state allow
set / network-instance default protocols bgp neighbor 10.1.2.2 peer-group ebgp
set / network-instance default protocols bgp neighbor 10.1.2.2 peer-as 65002
# create coverage
set / routing-policy coverage export-all default-action policy-result settle for
commit now
```
# Configuration for spine1 (SRLinux)
```bash
enter candidate non-public
# configure information interfaces
set / interface ethernet-1/1 admin-state allow
set / interface ethernet-1/1 subinterface 0 admin-state allow
set / interface ethernet-1/1 subinterface 0 ipv4 deal with 10.1.2.2/24
set / interface ethernet-1/1 subinterface 0 ipv4 admin-state allow
set / interface ethernet-1/2 admin-state allow
set / interface ethernet-1/2 subinterface 0 admin-state allow
set / interface ethernet-1/2 subinterface 0 ipv4 deal with 10.1.3.1/24
set / interface ethernet-1/2 subinterface 0 ipv4 admin-state allow
# add interfaces to default namespace
set / network-instance default interface ethernet-1/1.0
set / network-instance default interface ethernet-1/2.0
# configure BGP
set / network-instance default protocols bgp admin-state allow
set / network-instance default protocols bgp router-id 2.2.2.2
set / network-instance default protocols bgp autonomous-system 65002
set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state allow
set / network-instance default protocols bgp group ebgp admin-state allow
set / network-instance default protocols bgp group ebgp export-policy [ export-all ]
set / network-instance default protocols bgp group ebgp import-policy [ export-all ]
set / network-instance default protocols bgp neighbor 10.1.2.1 admin-state allow
set / network-instance default protocols bgp neighbor 10.1.2.1 peer-group ebgp
set / network-instance default protocols bgp neighbor 10.1.2.1 peer-as 65001
set / network-instance default protocols bgp neighbor 10.1.3.2 admin-state allow
set / network-instance default protocols bgp neighbor 10.1.3.2 peer-group ebgp
set / network-instance default protocols bgp neighbor 10.1.3.2 peer-as 65003
# create coverage
set / routing-policy coverage export-all default-action policy-result settle for
commit now
```
# Configuration for leaf2 (SRLinux)
```bash
enter candidate non-public
# configure information interfaces
set / interface ethernet-1/1 admin-state allow
set / interface ethernet-1/1 subinterface 0 admin-state allow
set / interface ethernet-1/1 subinterface 0 ipv4 deal with 10.1.4.1/24
set / interface ethernet-1/1 subinterface 0 ipv4 admin-state allow
set / interface ethernet-1/49 admin-state allow
set / interface ethernet-1/49 subinterface 0 admin-state allow
set / interface ethernet-1/49 subinterface 0 ipv4 deal with 10.1.3.2/24
set / interface ethernet-1/49 subinterface 0 ipv4 admin-state allow
# add interfaces to default namespace
set / network-instance default interface ethernet-1/1.0
set / network-instance default interface ethernet-1/49.0
# configure BGP
set / network-instance default protocols bgp admin-state allow
set / network-instance default protocols bgp router-id 3.3.3.3
set / network-instance default protocols bgp autonomous-system 65003
set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state allow
set / network-instance default protocols bgp group ebgp admin-state allow
set / network-instance default protocols bgp group ebgp export-policy [ export-all ]
set / network-instance default protocols bgp group ebgp import-policy [ export-all ]
set / network-instance default protocols bgp neighbor 10.1.3.1 admin-state allow
set / network-instance default protocols bgp neighbor 10.1.3.1 peer-group ebgp
set / network-instance default protocols bgp neighbor 10.1.3.1 peer-as 65002
# create coverage
set / routing-policy coverage export-all default-action policy-result settle for
commit now
```
# Configuration for client2 (Linux)
```bash
/sbin/ip deal with add 10.1.4.2/24 dev eth1
/sbin/ip route add 10.1.1.2/32 by way of 10.1.4.1
```
This configuration:
1. Makes use of distinctive subnets for every connection:
- client1-leaf1: 10.1.1.0/24
- leaf1-spine1: 10.1.2.0/24
- spine1-leaf2: 10.1.3.0/24
- leaf2-client2: 10.1.4.0/24
2. Configures BGP with distinctive AS numbers:
- leaf1: AS65001
- spine1: AS65002
- leaf2: AS65003
3. Implements particular routes on purchasers for end-to-end connectivity
4. Follows the precise SRLinux configuration format offered
5. Makes use of correct routing insurance policies for BGP route alternate
4. Senior Community Administrator Agent
This agent will get the configuration generated and applies it to all of the nodes, checks for bgp peering to return up after which lastly executes ping from finish to finish verifying connectivity. Right here the agent will get to the proper present command simply by inferring from the configuration instructions.
Following is the Closing Reply from this agent obtained after profitable configuration and of the community topology and checking finish to finish connectivity:
# Agent: Community Configuration Specialist
## Closing Reply:
# Community Configuration Report## Topology Data
### Units and Interfaces
1. **client1**
- Interface: eth1
- IP: 10.1.1.2/24
- Static route: 10.1.4.2/32 by way of 10.1.1.1
2. **leaf1** (AS65001)
- ethernet-1/1: 10.1.1.1/24 (related to client1)
- ethernet-1/49: 10.1.2.1/24 (related to spine1)
- BGP Router ID: 1.1.1.1
3. **spine1** (AS65002)
- ethernet-1/1: 10.1.2.2/24 (related to leaf1)
- ethernet-1/2: 10.1.3.1/24 (related to leaf2)
- BGP Router ID: 2.2.2.2
4. **leaf2** (AS65003)
- ethernet-1/1: 10.1.4.1/24 (related to client2)
- ethernet-1/49: 10.1.3.2/24 (related to spine1)
- BGP Router ID: 3.3.3.3
5. **client2**
- Interface: eth1
- IP: 10.1.4.2/24
- Static route: 10.1.1.2/32 by way of 10.1.4.1
## Configuration Instructions Executed
All configurations had been efficiently utilized to their respective units as per the offered configuration scripts. The important thing configurations included:
1. Interface IP addressing
2. BGP neighbor relationships
3. Route insurance policies
4. Static routes on consumer machines
## Connectivity Take a look at Outcomes
```
PING 10.1.4.2 (10.1.4.2) 56(84) bytes of information.
64 bytes from 10.1.4.2: icmp_seq=1 ttl=61 time=128 ms
64 bytes from 10.1.4.2: icmp_seq=2 ttl=61 time=8.16 ms
64 bytes from 10.1.4.2: icmp_seq=3 ttl=61 time=4.49 ms
64 bytes from 10.1.4.2: icmp_seq=4 ttl=61 time=5.86 ms
--- 10.1.4.2 ping statistics ---
4 packets transmitted, 4 acquired, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.491/36.620/127.973/52.758 ms
```
The ping take a look at from client1 (10.1.1.2) to client2 (10.1.4.2) was profitable with:
- 100% success price (4/4 packets)
- Common round-trip time: 36.620ms
- No packet loss
This confirms that the BGP configurations are working appropriately and the community is correctly forwarding site visitors between the purchasers via the leaf-spine topology.
AI brokers go above and past automation. They will purpose and attempt to give you options. A easy instance may be if a linux command fails because of permission challenge and the agent has entry to sudo password, subsequent time it’s going to strive with a sudo password to succeed. A posh instance may be incase the bgp peering just isn’t up, then primarily based on the immediate directions they’ll attempt to discover why and even go about fixing it.
Agentic workflows have its challenges they usually require completely different mind-set in comparison with programmatic approaches. To this point the downsides that I’ve encountered embody that it may well take longer (typically method longer) to realize an consequence, runtimes range with every run and outputs can range (this will considerably be managed by higher prompts).
Lastly, for trivial, easy duties like scraping an internet site and executing the given set of instructions, a smaller LLM can be utilized like gpt-4o-mini or llama3.1–7b and so forth. Nevertheless, for duties like designing the community topology, a much bigger LLM is required. Though right here claude-3–5-sonnet was chosen however ideally 70b mannequin ought to suffice. Lastly, it’s important to be very diligent with prompts. They’ll make or break your use-case!