Rare project developers

[Alexander Gall <>]

To follow up on this: at startup, the forwarder reports the status of
all ports currently active in the data-plane. When sdn1 is not yet
configured, the status of that port is ignored. However, after "reload
warm", sdn1 *is* known and the initial status reported by the
forwarder is accepted as the current status of sdn1. I think that's
the difference there.

-- 
Alex

On Tue, 14 Jun 2022 10:20:29 +0200, Alexander Gall <> said:

> On Tue, 14 Jun 2022 09:46:26 +0200, mc36 <> said:
>> hi,
>> excellent questions... let me start from the easiest to the hardest:
>> -freerouter starts an sdn interface in up when you issue "int sdn1"
>> -for this experiment, "int sdn1" / "log-link" should be configured btw... 
>> :)
>> -upon exporting under "server p4lang", it get's it's underlay so it goes 
>> down

> That doesn't happen. When the port is configured, the oper state is
> never reported back. All I see is (apart from some other "rx" messages
> unrelated to the port state)

> rx: ['ports_add', '0', '10', '2', '1', '0', '\n']
> WARNING:bf_forwarder.py:rx: ['ports_add', '0', '10', '2', '1', '0', '\n']
> Port[0] added
> WARNING:bf_forwarder.py:Port[0] added
> rx: ['state', '0', '1', '10', '2', '1', '0', '\n']
> WARNING:bf_forwarder.py:rx: ['state', '0', '1', '10', '2', '1', '0', '\n']
> Port[0] administrative status set to up
> WARNING:bf_forwarder.py:Port[0] administrative status set to up

> "sh int" shows the port as "up" indefinitely. The forwarder never
> sends a status. My guess is that this is because there are no state
> *transistions* in the data-plane. The oper status is always down.

> Probably a corner-case we haven't covered? I.e. maybe the forwarder
> should report the initial oper state?

>> -as long as the forwarder reports a state from the dataplane...
>> -to see the above, debug serv p4 rx/tx should be enabled too...
>> now the part i clearly not understand is
>> " After a warm reload, it still briefly works, but then sdn1 changes state 
>> to down and never comes back up."
>> because freerouter reports N if an interface is down and no other route 
>> exists...

> Let's assume this problem is fixed. What actually worries me more is
> the fact that the model appears to never mark the port as UP. That
> would mean that freerouter can't work with the model.

> However, since you do use freerouter on the model and you didn't run
> into this problem makes me wonder if there is anything different on my
> system :/

> -- 
> Alex

>> thanks,
>> cs



>> On 6/14/22 08:24, Alexander Gall wrote:
>>> Hi
>>> 
>>> I'm reproducing the demo I've made running the RARE release on the
>>> Tofino model and some questions popped up.
>>> 
>>> For now, I'm still using the built-in JSON ports file with the veths,
>>> i.e. veth0 is connected to Tofino port #0 etc.
>>> 
>>> Baically, what I'm doing is add an interface sdn1 on frontpanel-1/0,
>>> configure an address on it and on veth1 and do a ping. It works, but
>>> I'm actually confused why it works :/
>>> 
>>> The thing is that I've realized for the first time that the OPR
>>> status of the Tofino ports in the model is always DWN, e.g.
>>> 
bf-sde.pm> show -p 1/0
>>> -----+----+---+----+-------+----+--+--+---+---+---+--------+----------------+----------------+-
>>> PORT |MAC |D_P|P/PT|SPEED  |FEC |AN|KR|RDY|ADM|OPR|LPBK    |FRAMES RX 
>>> |FRAMES TX       |E
>>> -----+----+---+----+-------+----+--+--+---+---+---+--------+----------------+----------------+-
>>> 1/0  |15/0|  0|0/ 0|10G    |NONE|Ds|Au|YES|ENB|DWN|  NONE  | 8|           
>>>    10|*
>>> 
>>> This is despite the model logging
>>> 
>>> :06-14 08:07:26.582773:    PORT UP asic 0 port 0
>>> 
>>> AFAICT, this is happening at least for SDE 9.6.x through 9.7.x. For SDE
>>> 9.8.0 and 9.9.0, the OPR status is reported as UP when a port is
>>> connected to it via the JSON port mapping. Can you confirm this?
>>> 
>>> The model seems to ignore the OPR status and forwards packets in both
>>> direction. What confuses me with freerouter is that the port is
>>> reported to be up anyway right after adding the config for sdn1
>>> 
>>> rare(cfg)#vrf definition foo
>>> rare(cfg-vrf)#exit
>>> rare(cfg)#interface sdn1
>>> rare(cfg-if)#vrf forwarding foo
>>> rare(cfg-if)#ipv4 address 192.168.1.1 /24
>>> rare(cfg-if)#exit
>>> rare(cfg)#server p4lang p4
>>> rare(cfg-server)#export-port sdn1 frontpanel-1/0 10 2 1 0
>>> rare(cfg-server)#export-vrf foo 2
>>> rare(cfg-server)#sh int sdn1
>>> sdn1 is up
>>> description:
>>> state changed 3 times, last at 2022-06-14 08:14:27, 00:00:23 ago
>>> last packet input never ago, output never ago, drop never ago
>>> type is sdn, hwaddr=004b.4853.5536, mtu=1500, bw=8000kbps, vrf=foo
>>> ipv4 address=192.168.1.1/24, mask=255.255.255.0, ifcid=545466702
>>> received 0 packets (0 bytes) dropped 0 packets (0 bytes)
>>> transmitted 0 packets (0 bytes) macsec=false sgt=false
>>> 
>>> And ping works
>>> 
>>> rare(cfg)#exit
>>> rare#ping 192.168.1.2 vrf foo
>>> pinging 192.168.1.2, src=null, vrf=foo, cnt=5, len=64, tim=1000,
>>> gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, sweep=false, multi=false
>>> .!!!!
>>> result=80%, recv/sent/lost/err=4/5/1/0, rtt
>>> min/avg/max/sum=16/252/956/2037, ttl min/avg/max=64/64/64, tos
>>> min/avg/max=0/0/0
>>> 
>>> After a warm reload, it still briefly works, but then sdn1 changes
>>> state to down and never comes back up.
>>> 
>>> So my questions are
>>> 
>>> * Is this a bug in the Tofino model up to 9.7?
>>> * Why does freerouter (sort of) still work (i.e. ignoring the
>>> actual oper status)?
>>>