Rare project developers

[Alexander Gall <>]

On Mon, 14 Mar 2022 12:02:24 +0100, mc36 <> said:

> yeahhh, noticed myself too, just fixed again! :)

Confirmed, thanks.

Now one last thing :)

Putting rare-dev back on Cc as the following might be of interest to
others.

When a Tofino port is shutdown, a "state" message is generated with
the "adm_status" flag set to 0. The implementation in
rare/api/state.py translates this to removing the port from the $PORT
table, which is equivalent to the "port_del" command in UCLI. I think
this is the wrong thing to do because this also causes the counters as
well as the interface's rows in the ifTable/ifXTable MIBs to disappear
as well, when all it should do is to bring down the interface.

What I think should happen is that the state.py module should simply
set the $PORT_ENABLE field to False in the interface's entry in the
$PORT table (corresponding to the "port-dis" UCLI command). This will
actually put the port into the "administratively down" state but leave
the entries in the $PORT and $PORT_STAT tables intact (which, in turn
will also keep the SNMP table entries for the port).

I think a port should only be deleted from the $PORT table when the
"export-port" stanza is deleted.

Maybe something like this: instead of "state" we implement the call
"port" that comes with all the "add", "mod", "del" flavors. "add" and
"del" are emitted when the "export-port" stanza is added/removed. The
"add" command can also set the initial port
configuration. Modifications after creation are translated into
"port_mod" messages, which include setting of the admin status.

What do you think?

-- 
Alex

> On 3/14/22 11:58, Alexander Gall wrote:
>> On Mon, 14 Mar 2022 11:11:24 +0100, mc36 <> said:
>> 
>>> thanks for spotting, just fixed!
>> 
>> Thanks. Now there is a follow-up problem. When the subinterface is
>> created, freerouter correctly generates a "portvlan_add" messgae, e.g.
>> 
>> rx: ['portvlan_add', '773', '152', '123', '\n']
>> 
>> When the subinterface is removed, I would expect the correspoding
>> "portvlan_del" message. Instead, what happens is that a "state"
>> message is generated:
>> 
>> rx: ['state', '773', '0', '0', '0', '0', '0', '\n']
>> 
>> This should only happen for physical interfaces, not for ports in the
>> dynamic range.
>>