Skip to Content.

rare-dev - Re: [rare-dev] Experiment backplane routing

Subject: Rare project developers

List archive


Re: [rare-dev] Experiment backplane routing


Chronological Thread 
  • From: Edgard da Cunha Pontes <>
  • To: mc36 <>
  • Cc: , Gabriel Tetzner <>
  • Subject: Re: [rare-dev] Experiment backplane routing
  • Date: Thu, 8 Sep 2022 11:50:07 -0300

Hi Csaba, I hope you are better.

After a few config "baby steps" and a long time, I managed to reach some interesting points, but doubts increased as well.

Below is a brief description of the steps:

1) I created 3 VMs for routers r1, r2 and r5. Besides making connections with internal networks with VirtualBox.
https://github.com/vixphy/freertr-backplane/tree/main/virtualized [Topology]

2) I configured the "server dhcp4 eth1" and the ping works on the 10.12.11.0/24 network between r1 and r2 (which did not happen in the compiled p4lang-rout211.tst example).
http://sources.freertr.org/cfg/p4lang-rout211.tst

3) I made a configuration similar to the p4lang-rout211.tst example, but in this topology I added a NAT interface for management.
https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r1
https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2

4) Using the "tricks" learned in the last email, I was able to verify that there is a pointer to the remote dataplane, but the metrics still haven't changed. I believe I didn't configure R2 correctly.

r1(cfg-server)server p4lang p4                                                  
 dataplanes 2                                                      
 forwarder 0 export-vrf inet                                      
 forwarder 0 export-port sdn11 1 10 0 0 0                          
 forwarder 0 export-port sdn12 2 10 0 0 0                          
 forwarder 0 export-port sdn13 3 10 0 0 0                          
 forwarder 0 export-port sdn14 4 10 0 0 0                          
 forwarder 0 export-port bundle1 dynamic 0 0 0 0                  
 forwarder 0 interconnect ethernet3                                
 forwarder 0 backplane bundle1 1                                  
 forwarder 0 remote 10.11.12.111                                  
 forwarder 1 remote ::                                            
 vrf v9                                                            
 exit                                                              
!


r2(cfg-server)server p4lang p4
 export-vrf inet
 export-port sdn1 0 0 0 0 0
 export-port sdn2 1 0 0 0 0
 export-port sdn3 2 0 0 0 0
 export-port sdn4 3 0 0 0 0
 export-port sdn5 4 0 0 0 0
 interconnect ethernet0
 vrf p4
 exit
!

r1#show p4lang p4 dataplanes                                
fwd  addr          name  clsd  recon  ago    since
0    10.11.12.111  null  3     0      never  1970-01-01 00:59:59
1    ::            null  3     0      never  1970-01-01 00:59:59


5) I couldn't put only one dataplane with the command "dataplanes 1". And I didn't understand why?

Thank you so much for your help so far.

Em ter., 23 de ago. de 2022 às 18:16, mc36 <> escreveu:
hi,

On 8/23/22 22:55, Edgard da Cunha Pontes wrote:
> Hi everyone!
>
> After some time, I came back to this thread.
> I started creating the VMs in the virtualbox (with the one-line installation) to get closer to the RENaaS topology. But I stopped at router r2 and did the following steps:
>
> I created a debian/sid vm and compiled the freeRtr github repository.
> I ran the tests: ./tw.sh p4lang-rout211 other p4lang9.ini

excellent! that's the easiest way to go!

> I accessed routers r1, r5, r6, r7 and r8
>
nicee!

> But I could not access routers r2, r3 and r4.
>
the point is, these are just dataplanes... they even dont have config in the tst file:

r1 controls them, that's the main point of the whole feature... :)
if you're looking at ps aux | grep java, you'll find r1, r5..r8,
and if you ps aux | grep bin you'll see the 3 dataplanes all pointing to r1...

in r1, you'll find similar outputs like, and all the other sho p4 things got that optional (that is, hidden:) parameter

wifi>show p4lang p4 port-names ?
   <cr>
   [num] - forwarder number
   |     - output modifier

wifi>show p4lang p4 port-names 0
2022-08-23 23:01:03
num | name
1   | veth3a
0   | veth6b
2   | veth8b

wifi>show p4lang p4 port-names 1
2022-08-23 23:01:04
num | name
2   | eth0.151
3   | eth0.152
1   | eth0.167
0   | gre4t-cpuport
4   | wlan0
5   | wlan0-1
6   | wlan1

wifi>show p4lang p4 port-names 2
2022-08-23 23:01:05
num | name
3   | eth0.150
2   | eth0.151
1   | eth0.168
0   | gre4t-cpuport
4   | wlan0
5   | wlan0-1
6   | wlan1

wifi>show p4lang p4 port-names 3
2022-08-23 23:01:06
num | name
3   | eth0.150
2   | eth0.152
1   | eth0.166
0   | gre4t-cpuport
4   | wlan0
5   | wlan0-1
6   | wlan1

wifi>




> The goal was to understand the "controller r1 v9 9080 feature bundle mpls route" settings that Gabriel had commented on.
>
> Is there any way to access the compiled configuration of these routers?
>
you configure them from r1... they're just forwarders, instructed by r1...
much like the single box version, you have freerouter and a dataplane...
but here, freerouter got the capability to control more dataplanes at once...
do the spf over the backplane, and propagate the computed tables...

so as i left the lab before the polka experiments: a eu-sized router, made of 4 stacked pizzaboxes...
https://www.cisco.com/c/en/us/products/collateral/routers/carrier-routing-system/data_sheet_c78-726136.html
was the last i knew about with a similar feature, but that was limited to 1 hop, whereas,
rare, thanks to the mpls based backplane, can have arbitrary long chassis chain...

or, you can build an arbitrarily big data center made of tofino boxes,
and you need to configure the whole dc at a single controlling router..
(3+ would be safe enough and that feature is also there: http://sources.freertr.org/cfg/conn-redun.tst
and was configured in the 4 pizzabox as a single stack experiment)

or the same if one finally builds a chassis based tofino switch: you'll have 1 or 2 route processors,
and let's say 8 line cards, and hopefully some forwarding engines: a good design would be horizontal
line cards in the front and vertical forwarding engines in the back, and no backplane but connections...
the line cards could be made of 64x port capable tofino, 32 to the faceplate and 32 toward the forwarding engines...
or even smaller ones based on the 32 port tofino...

br,
cs



Archive powered by MHonArc 2.6.19.

Top of Page