Rare project developers

[mc36 <>]

hi,


On 7/12/22 10:45, Alexander Gall wrote:
> Hi
>
> On Tue, 5 Jul 2022 19:28:51 +0200, mc36 <> said:
>
> > so as nobody likes the magic numbers, and we already have a handshake in 
> > between the dataplane and the control plane,
> > i got the idea that what if the bffwd would tell freerouter all the remaining 
> > mapping of the export-port parameters,
> > like fec, autoneg and flwctrl? then the netadmin would be able to use the 
> > names much like it's already happening with
> > the front-panel port names?
>
> Appreciated :) What would be even better is if the config would show
> the names instead of the translated numbers, e.g. from you example
>
>   sid(cfg-server)#show running-config this
>   server p4lang p4
>     export-port sdn1 sdn1 frontpanel-1/1 10 rs off auto
so the thing is with this, is that when the startup config is parsed,
the dataplane is not connected yet... the other thing is when you swap
the dataplanes: we have dpdk, pcap, xdp, all interchangeable both in
parameters, and so on... but they have different namings for the
interfaces, at least...


> While you're at it, why not extend the mechanism to the other export
> properties like VRFs?  It should not be up to the user to pick the
> number that represents a VRF in a P4 table.
this one is a good idea, i'll play around this a bit...

> Ideally I would like to see the entire "server p4lang" section gone,
> at least as a user-servicable config. I guess the export-port
> functionality could remain there as an exception (once only the
> symbolic names are shown :) I think I've mentioned before that the
> mechanism used by IOS-XR (i.e. "interface preconfigure", "controller
> Optics...") is pretty clever. Maybe something to work towards in the
> future?

this is not a thing to consider for now... once we'll have the vc about 
stacking
(probably today) it'll show the necessity of all these... so for example one 
can
export only parts of their configs to a given dataplane: i have 3 openwrt aps,
running the ebpf/xdp dataplane...

server p4lang p4
 dataplanes 4
 forwarder 0 export-vrf inet 1
 forwarder 0 export-vrf ap 4
 forwarder 0 export-vrf bckpln 9
 forwarder 0 export-vrf open 13
 forwarder 0 export-bridge 1
 forwarder 0 export-bridge 2
 forwarder 0 export-bridge 3
 forwarder 0 export-port sdn0/0 1 0 0 0 0
 forwarder 0 export-port sdn0/1 2 0 0 0 0
 forwarder 0 export-port hairpin11 dynamic 0 0 0 0
 forwarder 0 export-port hairpin91 dynamic 0 0 0 0
 forwarder 0 export-port hairpin92 dynamic 0 0 0 0
 forwarder 0 export-port hairpin41 dynamic 0 0 0 0
 forwarder 0 export-port hairpin22 dynamic 0 0 0 0
 forwarder 0 export-port hairpin12 dynamic 0 0 0 0
 forwarder 0 export-port hairpin31 dynamic 0 0 0 0
 forwarder 0 export-port hairpin32 dynamic 0 0 0 0
 forwarder 0 export-port hairpin21 dynamic 0 0 0 0
 forwarder 0 export-port hairpin42 dynamic 0 0 0 0
 forwarder 0 interconnect ethernet92
 forwarder 0 backplane sdn0/1 10
 forwarder 0 remote 127.0.0.1
 forwarder 0 name p4emu
 forwarder 1 api-stat
 forwarder 1 export-vrf bckpln 9
 forwarder 1 export-bridge 1
 forwarder 1 export-bridge 2
 forwarder 1 export-bridge 3
 forwarder 1 export-port sdn1/1 1 0 0 0 0
 forwarder 1 export-port sdn1/2 2 0 0 0 0
 forwarder 1 export-port sdn1/3 3 0 0 0 0
 forwarder 1 export-port sdn1/4 4 0 0 0 0
 forwarder 1 export-port sdn1/5 5 0 0 0 0
 forwarder 1 export-port sdn1/6 6 0 0 0 0
 forwarder 1 interconnect pwether1
 forwarder 1 backplane sdn1/1 10
 forwarder 1 backplane sdn1/2 10
 forwarder 1 backplane sdn1/3 10
 forwarder 1 remote 10.1.250.41
 forwarder 1 name apl
 forwarder 2 api-stat
 forwarder 2 export-vrf bckpln 9
 forwarder 2 export-bridge 1
 forwarder 2 export-bridge 2
 forwarder 2 export-bridge 3
 forwarder 2 export-port sdn2/1 1 0 0 0 0
 forwarder 2 export-port sdn2/2 2 0 0 0 0
 forwarder 2 export-port sdn2/3 3 0 0 0 0
 forwarder 2 export-port sdn2/4 4 0 0 0 0
 forwarder 2 export-port sdn2/5 5 0 0 0 0
 forwarder 2 export-port sdn2/6 6 0 0 0 0
 forwarder 2 interconnect pwether2
 forwarder 2 backplane sdn2/1 10
 forwarder 2 backplane sdn2/2 10
 forwarder 2 backplane sdn2/3 10
 forwarder 2 remote 10.1.250.37
 forwarder 2 name app
 forwarder 3 api-stat
 forwarder 3 export-vrf bckpln 9
 forwarder 3 export-bridge 1
 forwarder 3 export-bridge 2
 forwarder 3 export-bridge 3
 forwarder 3 export-port sdn3/1 1 0 0 0 0
 forwarder 3 export-port sdn3/2 2 0 0 0 0
 forwarder 3 export-port sdn3/3 3 0 0 0 0
 forwarder 3 export-port sdn3/4 4 0 0 0 0
 forwarder 3 export-port sdn3/5 5 0 0 0 0
 forwarder 3 export-port sdn3/6 6 0 0 0 0
 forwarder 3 interconnect pwether3
 forwarder 3 backplane sdn3/1 10
 forwarder 3 backplane sdn3/2 10
 forwarder 3 backplane sdn3/3 10
 forwarder 3 remote 10.1.250.33
 forwarder 3 name apk
 vrf ap
 exit
!

wifi>
wifi>show bridge 1
2022-07-12 11:04:37
                        | packet               | byte                     |
iface     | fwd  | phys | tx    | rx    | drop | tx      | rx      | drop | 
grp
brprt bvi |      |      |       |       |      |         |         |      |
hairpin11 | true | true | 1288  | 17540 | 0    | 225667  | 1270940 | 0    |
sdn1/4    | true | true | 17546 | 1270  | 38   | 1271938 | 223753  | 1620 |
sdn2/4    | true | true | 11974 | 18    | 38   | 1147368 | 1914    | 1620 |
sdn3/4    | true | true | 11980 | 0     | 38   | 1148366 | 0       | 1620 |


                                               | packet                       
   | byte
addr           | iface     | static | time     | tx         | rx          | 
drop | tx              | rx               | drop
0000.0bad.c0de | hairpin11 | false  | 00:00:58 | 3+95600    | 17540+99422 | 
0+0  | 203+18073769    | 1270940+34504334 | 0+0
9809.cf74.2433 | sdn1/4    | false  | 00:00:14 | 6845+83222 | 1288+77479  | 
0+0  | 348038+31727818 | 225667+15082945  | 0+0


wifi>show bridge 2
2022-07-12 11:04:39
                        | packet               | byte                   |
iface     | fwd  | phys | tx    | rx    | drop | tx     | rx     | drop | grp
brprt bvi |      |      |       |       |      |        |        |      |
hairpin21 | true | true | 0     | 10450 | 0    | 0      | 915420 | 0    |
sdn1/5    | true | true | 10450 | 0     | 8    | 915420 | 0      | 720  |
sdn2/5    | true | true | 10450 | 0     | 8    | 915420 | 0      | 720  |
sdn3/5    | true | true | 10450 | 0     | 8    | 915420 | 0      | 720  |


                                               | packet               | byte
addr           | iface     | static | time     | tx  | rx      | drop | tx  | 
rx       | drop
0000.0bad.c0de | hairpin21 | false  | 00:01:00 | 0+0 | 10450+0 | 0+0  | 0+0 | 
915420+0 | 0+0


wifi>show bridge 3
2022-07-12 11:04:40
                        | packet               | byte                     |
iface     | fwd  | phys | tx    | rx    | drop | tx      | rx      | drop | 
grp
brprt bvi |      |      |       |       |      |         |         |      |
hairpin31 | true | true | 229   | 13310 | 0    | 68796   | 1182357 | 0    |
hairpin41 | true | true | 13310 | 229   | 0    | 1182357 | 68796   | 0    |
sdn1/6    | true | true | 10889 | 0     | 8    | 999756  | 0       | 720  |
sdn2/6    | true | true | 10889 | 0     | 8    | 999756  | 0       | 720  |
sdn3/6    | true | true | 10889 | 0     | 8    | 999756  | 0       | 720  |


                                               | packet                  | 
byte
addr           | iface     | static | time     | tx     | rx      | drop | tx 
      | rx        | drop
0000.0bad.c0de | hairpin31 | false  | 00:01:01 | 0+3296 | 13310+0 | 0+0  | 
0+278190 | 1182357+0 | 0+0


wifi>


as you can see here, only the bridging stuff exported to the openwrts,
first of all because the ebpf/xdp dataplane still have some limitations,
second, i want the routing to happen on the 0th stack member who is a
dpdk node with much more memory to store the tables...

but if we still dont think about stacking, and talking about a regular
tofino based switch, much like our 100glns field test nowadays, i run
my homenet in a vrf on that beast, inline mixed with the tested traffic...
but it uses encrypted l2tp tunnels so if i try to export it anyway, i
would blackhole the traffic completely because l2tp is present in the
dataplane, but it then cannot decrypt the upper layers, etc, etc...
in other words: the l2tp4_add api message will fail, packets will
match, but then the ppp.type will drop the packets in the tofino...



> > here is the small change implementing the above:
> > https://github.com/rare-freertr/freeRtr/csdn1 frontpanel-1/1 10 rs off 
> > autoommit/7ffaa39864c0eb54fa546bb630337fab5dc60d7c
> > the drawback of this commit is the additional complexity in case of gearboxed 
> > switches like the
> > bf2556tx where these magics need to be translated to the gearbox values in 
> > case of gearbox ports...
> > ps: alex, as you're the only one access to a tofino2, could you please verify 
> > if these are the right values on 400g too?
>
> Actually, the values are our own invention :/ BFRT uses strings like
> 'BF_FEC_TYP_FC' or 'BF_SPEED_200G'. They are defined here: 
> https://bitbucket.software.geant.org/projects/RARE/repos/rare/browse/bfrt_python/rare/bf_gbl_env/cst_env.py
> and the translation is here: 
> https://bitbucket.software.geant.org/projects/RARE/repos/rare/browse/bfrt_python/rare/bf_rt_rare/get_str_fec.py
yeahhh, that was the source i used.....

> Tofino2 uses the same names, so should not be a problem, except that
> there are obviously more speed settings.
sounds cool....

> In fact, your change basically makes the numbers obsolete. For
> example, the forwarder now tells freerouter that it should use 3 for
> RS FEC and the user can enter it as "rs". Freerouter then translates
> "rs" to 3 and sends that to freerouter, which immediately translates
> it to "BF_FEC_TYP_RS". We could simply omit the numbers now and only
> use the names.
from freerouter's point of view, nothing changed... it always used the
numbers, and should do so.... let's keep the complexity there and not
in the forwarder...

> BTW, there is no "auto" FEC. It's either none, rs or fc. The value 0,
> which is called "auto" is simply mapped to none. We should get rid of
> it.
tofino accepts that value too... maybe it have a different behavior?

br,
cs