Requirement
|
Overview
In [Modular design #001] article we described RARE/freeRtr main components:
- a control plane
- a data plane which can have different "flavor"
- and a message API interface that is tying the 2 components above
Article objective
In most of our past articles, all the components listed above were running on the same host as it is mostly the case on traditional monolithic hardware. In this article we demonstrate that RARE/freeRtr inherently exposes a totally disaggregated model. Practically, what does this means ? We will show in subsequent section that each of the components above can run on different hosts.
Note
While the control plane and the message API interface can be run from any host such as bare metal server, VM or even container, the dataplane of your choice will have to run on specific platform. For example, if you plan to implement a core backbone MPLS router able to switch 6.4 Tbps of packet throughput, the dataplane must be a specific hardware. (e.g. powered by INTEL TOFINO switch ASIC)
Diagram
In this example we will consider 2 routers named DAV0001 and DAV0101 respectively. Both if these routers are establishing an OSPF adjacency between them.
- DAV0001 is a P4 switch powered INTEL TOFINO ASIC
- DAV0101 is a SOHO RARE/freeRtr DELL VEP1445
Let's assume the logical figure below:
[ #002 ] - Modular design
In reality, we will run DAV0001 components in a different host respectively. We assume of course that there is connectivity between each of them.
Verification
Discussion
Conclusion
In this 2nd article you:
- had a showcase on how to implement a fully disaggregated RARE/freeRtr
- even if the control plane and the interface can be run almost anywhere, the dataplane still needs to be specific and adapted to the use case you planned to deploy
- pcapInt tool is a nitty gritty tool used to bind existing ports to a UDP socket tunnel.