Rare project developers

[Alexander Gall <>]

Never mind. I was using an older version of freertr, namely the one I
used in the demo of running RARE on the model. Remember that the ping
worked back then? That was because of this behaviour that freertr
considered the port to be up. Presumably, this demo would no longer
work with the current version.

So can you now please check whether the oper status of your ports on
the model is "UP" (seen from the UCLI) when you expect it to be ? This
is really my main concern for now :)

-- 
Alex


On Tue, 14 Jun 2022 11:46:46 +0200, mc36 <> said:

> hi,
> On 6/14/22 11:27, Alexander Gall wrote:
>> On Tue, 14 Jun 2022 11:09:24 +0200, mc36 <> said:
>> 
>>> hi,
>>> On 6/14/22 10:20, Alexander Gall wrote:
>>>> 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)
>>> so it starts getting more and more interesting:
>> 
>> 
>>> sid(cfg)#show interfaces sdn1 | first 1
>>> % no such interface
>>> sid(cfg)#interface sdn1
>>> sid(cfg-if)#show interfaces sdn1 | first 1
>>> sdn1 is down
>> 
>>> sid(cfg-if)#^Z
>>> sid(cfg)#server p4lang p4
>>> sid(cfg-server)#show interfaces sdn1 | first 1
>>> sdn1 is down
>> 
>>> sid(cfg-server)#export-port sdn1 1
>>> sid(cfg-server)#show interfaces sdn1 | first 1
>>> sdn1 is down
>> 
>>> sid(cfg-server)#show interfaces sdn1 | first 1
>>> sdn1 is down
>> 
>>> sid(cfg-server)#info prtTcp.connectionRcvd:prtTcp.java:756 got future 
>>> acknowledge number p4lang loopback0 9080 -> 10.8.255.1 37192
>>> debug servP4langConn.doNegot:servP4langConn.java:184 fwd0 rx: dynrange 
>>> 666 6666
>>> debug servP4langCfg.sendLine:servP4langCfg.java:1000 fwd0 tx: ports_add 1 
>>> 0 0 0 0
>>> warning servP4langConn.doNegot:servP4langConn.java:239 neighbor 
>>> 10.8.255.1 up
>>> debug servP4langCfg.sendLine:servP4langCfg.java:1000 fwd0 tx: state 1 1 0 
>>> 0 0 0
>>> debug servP4langCfg.sendLine:servP4langCfg.java:1000 fwd0 tx: mtu 1 1500
>>> debug servP4langCfg.sendLine:servP4langCfg.java:1000 fwd0 tx: 
>>> mylabel4_add 1025147 0
>>> sid(cfg-server)#
>>> sid(cfg-server)#show interfaces sdn1 | first 1
>>> sdn1 is down
>> 
>>> sid(cfg-server)#debug servP4langConn.doReports:servP4langConn.java:256 
>>> fwd0 rx: state 1 1
>>> sid(cfg-server)#
>>> sid(cfg-server)#show interfaces sdn1 | first 1
>>> sdn1 is up
>> 
>>> sid(cfg-server)#
>> 
>> This is on an ASIC, not the model, right? The port actually reports
>> going UP, which doesn't happen on the model (at least for me). If this
>> *is* on the model, I'd like to understand why it behaves differently
>> from mine.
> so this test was done by hand ( spot the dynrange 666 6666 :))) )
> just to validate freerouter behaviour... now i spin up my model vm
> on a test case: java -Xmx512m -jar rtr.jar test tester p4lang-rout001 other 
> p4lang301.ini wait
> and as you can see i got 260 state messages almost immediately after the 
> forwarder started:


> r1#show config-differences
> server p4lang p4
>   api-stat
>   exit
> r1#show p4lang p4 api-rx
> message       count  last                 ago
> capabilities  1      2022-06-14 09:41:33  00:02:21
> counter       2200   2022-06-14 09:43:53  00:00:00
> dynrange      1      2022-06-14 09:41:33  00:02:21
> platform      1      2022-06-14 09:41:33  00:02:21
> portname      128    2022-06-14 09:41:33  00:02:21
> state         260    2022-06-14 09:41:34  00:02:20

> r1#



>> 
>>> that is, freerouter, up until it gets the state 1 1 reports the port
>>> down, that is,
>> 
>> 1 is "up", no?
>> 
> yess, that's it....

> so i still keep my opinion, if you got any ping messages, i got the "state 
> <portid> 1" message,
> because if a port stays down, then bfforwarder will send nothing then 
> freerouter will leave the
> sdnX in down state....

> so, could you please try the debug serv p4 rx to see if it reports or not 
> to freerouter?

> thanks,
> cs


>>> unless that message, it's impossible that you pinged anything 
>>> successfully????
>> 
>> I can actually ping as long as freertr thinks the port is up. That's
>> because the model doesn't care about the port oper status and packets
>> can flow in both directions. They only get dropped by freertr once it
>> believes the port is down and re-programs the tables.
>>