Holo Guide ‐ Key files

In the previous section, we created the foundational file structure that will serve as the basis for developing the VRRP protocol.

You may be wondering about the purpose of some—or perhaps all—of the files in that structure. Don’t worry, we're about to explore each one in detail.

We'll focus on the fundamentals of each file's role, but we won't dive into the actual code just yet. That will be reserved for later chapters.

---

packet.rs

Networking protocols inherently involve packet transmission. These packets regularly need to be defined and structured; based on one protocol or another.

This file is responsible for defining and structuring these packets in a way that is idiomatic to Rust. It also contains methods for encoding packets as they leave the device and decoding them as they are received.

Depending on the protocol, supporting methods such as checksums and some verification may be done here; although this is not entirely necessary.

---

network.rs

This file is responsible for managing communication with external networks, handling both outgoing and incoming data.

It performs three key tasks: creating the necessary sockets for communication, sending data, and receiving data. For VRRP, raw sockets are used to send and receive packets. However, protocols like BGP, which operate over TCP, use standard TCP sockets instead. Depending on the specific protocol and designer, the sockets and how they operate may vary.

In VRRP, for instance...w

This is a crucial file that is used across all protocols.

---

tasks.rs

In not too long we will talk about channels, but you can have a brief read about them here.

Basically tokio entities communicate with one another through passing messages around. These messages are passed around via channels, which will be described later. tasks.rs creates the channels that will be used internally between the protocol's entities (in this case VRRP).

If not properly handled, channels can be quite managable so you would be wise to know what channel you are instantiating, where its transmitters are and where its consumers are. We will cover this channels topic in detail in not too long as mentioned.

---

interface.rs

This file serves as the "entry point" for the rest of holo to interact with the specific protocol. For other protocols where the interface is not a key element, this file might be named something like main.rs.

A central feature of this interface file is its main struct, named Interface in this case. This struct implements a trait called ProtocolInstance. This trait is implemented across all protocols in their entrypoints.

The trait specifies how to handle startups, shutdowns, northbound and even southbound messages. I'd urge you to go through this link and read more about it.

---

instance.rs

This refers to a VRRP instance. The main item in this file is a struct called Instance.

In the VRRP YANG model, we can see that each interface can contain multiple VRRP instances, and we have done the same in holo, with relation to the Interface in interface.rs.

These instances what will be used to run the State Machine. They contain key items like advertisement time, master down time, skew time, preempt etc...They are a VRRP specific item and thus will not entirely apply to every other protocol, but if you understand how the VRRP State Machine works, understanding how this file operates will help a long way if you have another state machine you need to implement for another protocol.

The Instance struct also holds timers. It might be beneficial to understand how those work in the long run.

---

southbound.rs

This is the link to the southbound of the system. The southbound is mostly the netlink calls that will be made.

Netlink is contained in holo-routing/netlink.rs and holo-interface/netlink.rs. They are connected to this southbound file via an ibus. The ibus is a connection point between netlink and the rest of the system. Netlink calls may be complicated and hard to navigate thus the addition of this layer that will talk to the protocols.

We will be receiving messages from the kernel when certain events happen (e.g changes in interface status) from this file.

---

Recap: we have been looking at the various files that will exist in all networking protocols inside holo. It would be advisable if you could take a rough look at the files in any protocol of your chosing in holo. Not necessarily understand everything, but grasp the general feel and structure of it.

We will be having description of the files in the northbound directory added later on.

In the meantime, let's move to defining and structuring our errors on error.rs.