RARE user and assistance email list

["mc36" <>]

hi,
good catches, let me explain a bit on these concepts...
freerouter is a control plane, afterall... it contains it's own tcp/ip stack 
and all the routing protocols sitting on top of it...
it is needed to handle and be able to participate at arbitrary level of iso 
architecture: if one interface is configured to
layer2 cross-connect, then that, if an other have a tunnel on top of it, and 
within that tunnel it's a different vrf then that...
all the encapsulations and routing decisions will happen within freerouter, 
and if there is no dataplane involved, then it can
also forward packets in between these interfaces...
since these are happening over a udp socket, the physical interface and the 
freerouter deciding what to send to it can sit several hops away...
(i develop the dataplane vms running remotely, here we had a chat about it: 
https://lists.geant.org/sympa/arc/rare-users/2022-02/msg00076.html )
in case of ovs, freerouter just exports the computed routing tables and there 
is a packet-in/packet-out openflow message to handle
the exception packets and let freerouter handle them properly... these are 
the interface's own ips/32, mostly...
but be warned, ovs in-kernel flow table is very small, everything that falls 
from that very tight table will be handled in
ovs user space processes... it means a kernel-user-kernel switching in 
real-life traffic... very easy to trigger it by starting
some well-feeded torrents, executing nmap 10.0.0.0/8, and friends...! :)
then there we have the tofino asic, where we also export the (routing) 
tables, and the asic routes the packets too, but there is
no such thing like route-cache nor flow table, it does real lpm, mask-match, 
or exact-match lookups on the pre-programmed tables...
in this case we have N frontpanel ports and an N+1 port from the asic's point 
of view, where freerouter sits... we named it
cpuport, where the asic can pass the exception packets to freerouter... the 
frames here are prepended with a 16bit word to
name the frontpanel port where to/from the packet should go to/came from... 
this is the point where freerouter's built-in tcp/ip
stack started paying off: we were able to handle the situation very easily: 
it was just a some lines of code that multiplexes these
frames to sdn interfaces in freerouter, then we can do whatever we want on 
these sdn interfaces in freerouter: do bgp, isis, ospf, whatever!
then we got the dpdk and xdp dataplanes, which are there to show that this 
concept, the cpuport and the messages how freerouter instructs
the dataplanes to add/del/mod in a table works and could do basically 
anything... these dataplanes mimic the asic behavior so they have
similar tables and perform almost the same that the p4 code for the asic...
so from user's point of view, there is no difference if the dataplane is 
dpdk, asic or ovs, the freerouter configuration,
look and feel is the same, they're fully interchangeable, and the expected 
outcome is the same...
we just had a nice chat how the dataplane test cases utilize this property:
https://lists.geant.org/sympa/arc/rare-dev/2022-02/msg00129.html
in the middle of the mail i give a detailed view about the concept...
regards,
cs




On 2/28/22 23:42, Moises R. N. Ribeiro wrote:
> Csaba, (Evenson, Edgard, Rafael Magnos)
>
> Freerouter 101: staring with a non-linear reading of the front page...please, 
> if you have the time, correct my speculations below:
>
> Assuming that Freerouter:
>
> i)   "receives and sends packets through udp sockets", it should not be a 
> problem to sit it on top of an OS where OvS does all the SDN trickery we like;
> ii) by being "independent of underlying* OS capabilities" that might suggest that virtualization platforms (understood as virtualizers and hypervisors) be used regardless and 
> wildly; and
> iii) "internet can be used as backplane for router processes" we could think of Freerouter as destined from birth to serve and suit our "overlay" approach submitted to GEANT 
> innovation...and further still from a disaggregation perspective, where virtual network functions (VNFs) can be "freely" placed out and about and chained to compose a Freerouter 
> instances with this or that functionality...or microservices fragmented and replicated at will.
>
> all that sounds like "heavens on earth", and I expect you to duly confirm my 
> "wishful reading" of your statements... but here comes the catch, I mean, the question:
>
> "External, privileged processes that place traffic to these udp sockets"... It feels like... and smells like... "hooks-socks and alikes" here. And the mechanism/architecture 
> designed to "export forwarding tables to xdp, dpdk or hardware switches via openflow or p4lang" is the key to unlock eventual incompatibilities of OS with specific hook 
> primitives/functionalities...in other words: "Divide to conquer": each "data plane" has its own "privileged processes" to skip differences (in kernel, firmware, and even 
> "telepathy" mismatches :-) etc.) and keep Freerouter agnostic on top... ruling unchallenged just like King Matja   does on his 1000 Forint bill?
>
> Regards,
> Moises


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#232): https://groups.io/g/freertr/message/232
Mute This Topic: https://groups.io/mt/89470723/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-