INT: Anomaly on stopping the reference application about p4factory HOT 11 CLOSED

The error messages could be ignored. The mininet script for the demo cleans up any stray processes (docker, monitor, etc.) that may be left over from a previous iteration. The 'cleanup.sh' script is meant as a backup - to reset the system to a clean state in case the demo script crashes in between. In this case, it seems like the mininet script ran fine and hence, the cleanup script complained that there were no stray processes that needed to be cleaned up.

The docker installation instruction in README is outdated. We will fix it.
Meanwhile, can you first check if docker daemon is properly installed by running:

docker images

If it complains being unable to connect to daemon, or so, follow the official docker instructions at http://docs.docker.com/engine/installation/ubuntulinux/

If docker is running fine, you can check the browser console for any error message.
In Chrome, do mouse right click on the web client, select 'Inspect', go to 'Console' tab and look for any connection error messages.

Thanks,
JK

from p4factory.

@jklr
Thanks for your suggestion.

docker images

runs properly on my VM(Ubuntu14.04-3 LTS), and lists that "p4dockerswitch" image

I started the reference application by typing:

cd p4factory/mininet
sudo ./int_ref_topology.py

and the corresponding output:

Starting P4 docker switch spine1
Starting P4 docker switch spine2
Starting P4 docker switch leaf1
Starting P4 docker switch leaf2
Waiting 10 seconds for switches to intialize...
INT Config  spine1
INT Config  spine2
INT Config  leaf1
INT Config  leaf2
Starting quagga on switches
../apps/int/monitor/preprocessor.py 10.0.2.2 > tmp_h2 2>&1 &
../apps/int/monitor/preprocessor.py 10.0.3.3 > tmp_h3 2>&1 &
../apps/int/monitor/preprocessor.py 10.0.1.1 > tmp_h1 2>&1 &
../apps/int/monitor/preprocessor.py 10.0.4.4 > tmp_h4 2>&1 &
Waiting 20 seconds for Quagga to learn routes...
Starting ping mesh sessions
h2 pinging 10.2.1.3
h2 pinging 10.2.1.1
h2 pinging 10.2.1.4
h3 pinging 10.2.1.2
h3 pinging 10.2.1.1
h3 pinging 10.2.1.4
h1 pinging 10.2.1.2
h1 pinging 10.2.1.3
h1 pinging 10.2.1.4
h4 pinging 10.2.1.2
h4 pinging 10.2.1.3
h4 pinging 10.2.1.1
mininet>

After I start the Web client on Google Chrome inside my VM, I ran:

mininet> xterm h1

which is different from

mininet> h1 xterm

as suggested in the #example-1-iperf-test. I think that's a mistake on the README file, am I right?

Then, inside the launched xterm to start a new iperf session:

iperf -c 10.2.1.3 -t 60

I got the output:

--------------------------------------------------------------------------------
Client connecting to 10.2.1.3, TCP port 5001
TCP window size: 85.3 KByte (default)
--------------------------------------------------------------------------------
[   5] local 10.2.1.1 port 59086 connected with 10.2.1.3 port 5001
[ ID] Interval        Transfer            Bandwidth
[   5] 0.0-61.6 sec   7.25 MBytes      987 Kbits/sec

But I cannot see any changes on the Web client, and I cannot find any error on "Google Chrome -> Inspect -> console"

from p4factory.

@hamkuu
You're right about xterm.

We have tested on two vanilla Ubuntu 14.04 VMs, following the same instructions under p4factory and apps/int. The web client on Chromium browser well displayed the topology and the 4 graphs w/ continuous changing hop latencies. you don't need to run the iperf, as the ping mesh keep on generating traffic.

Please check if you have the latest p4factory ('git pull' and 'git submodule update --recursive') and follow the quickstart steps (https://github.com/p4lang/p4factory). Make sure of vxlan driver.

$ lsmod | grep vxlan
vxlan                  40960  0 
ip6_udp_tunnel         16384  1 vxlan
udp_tunnel             16384  1 vxlan

Updating your browser might help too.

sudo apt-get upgrade chromium-browser

from p4factory.

@jklr

I upgraded the p4factory local repo and chromium-browser, nothing seemed improved.

However, I reinstalled the VM(Ubuntu14.04-3 LTS), and ran:

sudo apt-get update

then ran (which I neglected previously):

sudo apt-get upgrade

After that, I followed the instructions as what I previously did, the web client ran as expected.

Problem solved!

After all, thank you! As you reminded me of the word "upgrade" .

from p4factory.

@hamkuu
Glad that you resolved the issue.

Installing Ubuntu 14.04 dependencies by

./install_deps.sh

,as suggested in p4factory README, should have prevented the issue.
Please let us know if you had to 'sudo apt-get upgrade' even after running the 'install_deps.sh' script.
Thanks.

from p4factory.

@jklr

After I ran the "sudo ./install_deps.sh", I did not run "sudo apt-get upgrade".

from p4factory.

@jklr

I am studying the "int_ref_topology.py" file, but I cannot understand some parameters of some functions, e.g. LinkConfig()

I guess those configuration functions are imported from "int_cfg" module. Would you tell me how to find related documentation that can assist my study?

from p4factory.

Similar to other fast-evolving open source projects, there is no separate code reference guide.
int_cfg.py has he high-level configurations in it, the class/function/variable names are mostly self-explanatory. If you want, you can read the codes down to the definitions by back tracking the imported modules.

LinkConfig takes a pair of [node, port] tuples to connect by the link. A node can be either switch or host. It eventually invokes mininet .addLink() function, I believe.
If you're not familiar with mininet, you can start from http://mininet.org/.

from p4factory.

@hamkuu

Unfortunately, there's currently no documentation for the int_cfg module. We'll add it as soon as possible.

Below, I've listed a few of the classes/fields that may appear confusing.
Please let us know if you have more questions.

HostConfig

• Configuration parameters for each mininet host
• Fields
  • vxlan_cfg - The INT demo utilizes VXLAN-GPE encapsulation to transport INT headers and metadata. Each host has a VTEP within it to send/receive VXLAN-GPE packets. The vxlan_cfg for each host specifies parameters to configure this VTEP ( eg: mac, ip, prefix, vni, etc. )

SwitchConfig

• Configuration parameters for each docker switch
• Fields
  • pps - packets per second ( used to rate limit the switch )
  • qdepth - queue depth
  • config_fs - location of the quagga config files ( to configure BGP ) for each switch

LinkConfig

• Specifies the creation of a mininet link between ( 'port1' of 'node1' ) and ( 'port2' of 'node2' )

NetworkManager

• Main driver class
• Methods
  • setupAndStartNetwork() - sets up a mininet network ( as per the configs provided ) and starts it.
  • configINTSourcesAndSinks() - sets up the VTEP within each mininet host
  • configHostRoutesAndArp() - creates a routing table entry within each host to point it to the switch it's connected to

from p4factory.

@JithinThomas

I have a question about the Example 2: routing fail-over test

Start a long-running iperf connection between h1 and h3. Check which spine switch the connection passes through, using the web client UI.

If the connection is going through spine1, shut down the port on leaf2 that is connected to spine1. You can do this by typing "ifconfig swp3 down" in the leaf1 xterm. If it is going through spine2, type "ifconfig swp4 down" instead.

I ran the test several times, as expected, sometimes the flow goes through spine1, and sometimes goes through spine2.

My question is, why is the flow path is unpredictable? How is the flow path actually be selected?

Moreover, after running for a while (10 minutes or so), without my intervention, the flow path could change from "through spine1" to "through spine2". What's the explanation for such behavior?

from p4factory.

Hi,
i am getting following error, could you please give any suggestions

Adding switch spine1
Adding switch spine2
Adding switch leaf1
Adding switch leaf2
Waiting 10 seconds for switches to intialize...
INT Config spine1
Traceback (most recent call last):
File "./int_ref_topology.py", line 131, in
run_cfg(model_dir)
File "./int_ref_topology.py", line 91, in run_cfg
net = mgr.setupAndStartNetwork()
File "/home/suneet/Desktop/p4factory/mininet/int_cfg.py", line 148, in setupAndStartNetwork
self.configSwitches()
File "/home/suneet/Desktop/p4factory/mininet/int_cfg.py", line 238, in configSwitches
self.configSwitch(s)
File "/home/suneet/Desktop/p4factory/mininet/int_cfg.py", line 252, in configSwitch
client.switcht_api_init( device )
File "/home/suneet/Desktop/p4factory/submodules/switch/switchapi/switch_api_thrift/switch_api_rpc.py", line 1565, in switcht_api_init
return self.recv_switcht_api_init()
File "/home/suneet/Desktop/p4factory/submodules/switch/switchapi/switch_api_thrift/switch_api_rpc.py", line 1577, in recv_switcht_api_init
(fname, mtype, rseqid) = iprot.readMessageBegin()
File "/usr/local/lib/python2.7/dist-packages/thrift/protocol/TBinaryProtocol.py", line 134, in readMessageBegin
sz = self.readI32()
File "/usr/local/lib/python2.7/dist-packages/thrift/protocol/TBinaryProtocol.py", line 217, in readI32
buff = self.trans.readAll(4)
File "/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py", line 60, in readAll
chunk = self.read(sz - have)
File "/usr/local/lib/python2.7/dist-packages/thrift/transport/TTransport.py", line 162, in read
self.__rbuf = BufferIO(self.__trans.read(max(sz, self.__rbuf_size)))
File "/usr/local/lib/python2.7/dist-packages/thrift/transport/TSocket.py", line 132, in read
message='TSocket read 0 bytes')
thrift.transport.TTransport.TTransportException: TSocket read 0 bytes

from p4factory.