Solution for ipv4_forward doesn't run => other problems?

[jyu911]

Hi,

VM was copied from USB during P4 Developer Day 2017, so it should be good.
My problem is the solution doesn't run. After examining the logs, the LPM lookup
resulted in a miss (used the correct ipv4.dstAddr). The table for S1 was populated
during runtime. However, for all the switches, there were errors similar to:

No handlers could be found for logger "thrift.transport.TSlocket"
Could not connect to thrift client on port 909x (x = 0-2)

right after all the table_adds. Search for similar problems only pointed to
a previous deprecation issue, but this should all be the latest. Could there
be some other problems (setup) with VirtualBox I'm using?

Thanks for any pointers. BTW, solution for other exercises don't run
either, so it's probably my setup instead of the code itself. Sorry for
the submission here, if this is the wrong place.

James

[antoninbas]

I don't think the warning No handlers could be found for logger "thrift.transport.TSlocket" is relevant.
Also I don't think this is correct: "The table for S1 was populated during runtime". If the CLI cannot connect to the Thrift server, there is no way the table can be populated...

Did you check if you could run some of these older exercises: https://github.com/p4lang/tutorials/tree/master/examples ?

Our Pythons scripts actually check that the Thrift server can be reached when starting the switches (see https://github.com/p4lang/tutorials/blob/master/P4D2_2017/utils/mininet/p4_mininet.py#L98), so I'm surprised that this error is even possible. Do you see that log message in the output: https://github.com/p4lang/tutorials/blob/master/P4D2_2017/utils/mininet/p4_mininet.py#L146
If you do see it, it means that we were able to connect to the TCP server at some point.

You seem to imply in your question that the switches didn't crash. I don't see how it is possible for the switches to be running without their respective Thrift servers being available.
I think you want to make the switches are running. If they are, you want to make sure that the TCP ports 909x are open, e.g. using netstat. If they are, try to telnet to one of them. If you can go this far, then it should be straightforward to debug. If the ports are not open on the other hand, I have no idea what the problem could be.

[jyu911]

Hi Antonin, Thanks for the comments.  Perhaps my description had parse graph errors somewhereto cause the confusion.  In reality, I also don't think the warnings themselves pinpointexactly what is wrong.  However, they came right after the table_adds and thetables weren't populated correctly which resulted in the LPM miss.  That is the relevanceI hope that may jog someone's memory by mere association.  I also stated the messageindicated the tables were being populated.  That is different than whether the tableswere populated correctly or even at all. Basically, I stated I believe the VM image along with reference code should be good.  So,the likely culprit is the setup instead of any code.  And yes, the switch indeed was runningfine and didn't crash. I will try some of the suggestions.  Appreciate your time. James From: Antonin Bas <notifications@github.com> To: p4lang/tutorials <tutorials@noreply.github.com> Cc: jyu911 <jyu911@yahoo.com>; Author <author@noreply.github.com> Sent: Tuesday, June 6, 2017 4:58 PM Subject: Re: [p4lang/tutorials] Solution for ipv4_forward doesn't run => other problems? (#38) I don't think the warning No handlers could be found for logger "thrift.transport.TSlocket" is relevant. Also I don't think this is correct: "The table for S1 was populated during runtime". If the CLI cannot connect to the Thrift server, there is no way the table can be populated...Did you check if you could run some of these older exercises: https://github.com/p4lang/tutorials/tree/master/examples ?Our Pythons scripts actually check that the Thrift server can be reached when starting the switches (see https://github.com/p4lang/tutorials/blob/master/P4D2_2017/utils/mininet/p4_mininet.py#L98), so I'm surprised that this error is even possible. Do you see that log message in the output: https://github.com/p4lang/tutorials/blob/master/P4D2_2017/utils/mininet/p4_mininet.py#L146 If you do see it, it means that we were able to connect to the TCP server at some point.You seem to imply in your question that the switches didn't crash. I don't see how it is possible for the switches to be running without their respective Thrift servers being available. I think you want to make the switches are running. If they are, you want to make sure that the TCP ports 909x are open, e.g. using netstat. If they are, try to telnet to one of them. If you can go this far, then it should be straightforward to debug. If the ports are not open on the other hand, I have no idea what the problem could be.— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gopchandani]

Having the exact same issue with the VM that has been uploaded for P4D2_2017 (http://p4.org/p4-developer-day-2017/).

Tried telnetting the switches at ports 9090, 9091, 9092, and it gets through.
Still seeing the same error (could not connect to thrift client on port 9090) coming out of simple_switch_CLI.