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: mc36 <>
  • To: Edgard da Cunha Pontes <>
  • Cc: , Gabriel Tetzner <>
  • Subject: Re: [rare-dev] Experiment backplane routing
  • Date: Sat, 17 Sep 2022 09:26:04 +0200

hi,
my bad! i did not expected to have such progress alone! :)
so then use a single r1 java vm, surround it with vnX and run the p3emu
there....
each vm will require 2 ethernet connections, 1 for the api 1 for the cpu port
dl.nop.hu/p4emu.zip have such a setup readily available...
br,
cs


On 9/16/22 23:15, Edgard da Cunha Pontes wrote:
Hi Csaba,

if you go with 2 vms then you can have 1 controllers each having multiple
dataplanes for example....
Yes! R1 is the controller (or "master", how am i calling) and R2 is the
worker/dataplane.

In addition to configuring the rout211 example, I understand that it is necessary to configure the R2 server p4lang to indicate that there is a controller (R1), but I still haven't figured out how to do it (or if it is necessary).

Thanks for answering me this far. Some "glimmers" of a solution to the
problem are beginning to emerge.

Em sex., 16 de set. de 2022 s 15:59, mc36 < <>>
escreveu:

hi,
if you go with 2 vms then you can have 1 controllers each having multiple
dataplanes for example....
br
cs


On 9/16/22 16:33, Edgard da Cunha Pontes wrote:
> Hi Csaba! Thanks again for answering me.
>
> My main question remains which configuration to use in R2
<https://github.com/vixphy/freertr-backplane/blob/main/virtualized/r2/rtr-sw.txt

<https://github.com/vixphy/freertr-backplane/blob/main/virtualized/r2/rtr-sw.txt>>
(rtr-sw). I'm using a basic p4emu setup,
> but I haven't figured out how to "point" it to R1
<https://github.com/vixphy/freertr-backplane/blob/main/virtualized/r1/rtr-sw.txt

<https://github.com/vixphy/freertr-backplane/blob/main/virtualized/r1/rtr-sw.txt>>
(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>
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized>>
> <https://github.com/vixphy/freertr-backplane/tree/main/virtualized
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized>
<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> <http://10.12.11.0/24 <http://10.12.11.0/24>>
<http://10.12.11.0/24 <http://10.12.11.0/24> <http://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>
<http://sources.freertr.org/cfg/p4lang-rout211.tst
<http://sources.freertr.org/cfg/p4lang-rout211.tst>>
<http://sources.freertr.org/cfg/p4lang-rout211.tst
<http://sources.freertr.org/cfg/p4lang-rout211.tst>
> <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/r1
<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/r1>
<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>
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2>>
> <https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2
<https://github.com/vixphy/freertr-backplane/tree/main/virtualized/r2>
<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 < <>
< <>> < <> <
<>>>> 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>
>
<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>>
> >
<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>
>
<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>
<http://sources.freertr.org/cfg/conn-redun.tst
<http://sources.freertr.org/cfg/conn-redun.tst>>
> <http://sources.freertr.org/cfg/conn-redun.tst
<http://sources.freertr.org/cfg/conn-redun.tst>
<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