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: Fri, 16 Sep 2022 11:33:15 -0300

Hi Csaba! Thanks again for answering me.

My main question remains which configuration to use in R2 (rtr-sw). I'm using a basic p4emu setup, but I haven't figured out how to "point" it to R1 (rtr-sw) yet.

I'm converting the rout211 example to use on two VMs in Virtualbox for now.

Unfortunately it's a beginner level question as I haven't figured out how to configure R2 or the other workers (R3 and R4) yet.


Em sex., 16 de set. de 2022 às 10:31, mc36 <> escreveu:
  could you please verify if the original rout211 works for you?
then adding yiu cinfig ibe by ibe until it breaks?
thanks
cs

On 9/8/22 16:50, Edgard da Cunha Pontes wrote:
> 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 <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 <http://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 <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/r1>
> https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2 <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 < <mailto:>> 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
>     <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 <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