SD-WAN

Hello. I have physical 2920 HP switch and I'm using the Floodlight controller. My problem is that when I connected two computers to my switch, they can not ping each other. It seems that Floodlight cant push default flows, and I do not know why.

I installed Floodlight like this:

sudo apt-get install build-essential ant maven python-dev git
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer
sudo apt-get install oracle-java8-set-default
sudo update-alternatives --config java
git clone https://github.com/rizard/floodlight.git
cd floodlight
git submodule init
git submodule update
ant
sudo mkdir /var/lib/floodlight
sudo chmod 777 /var/lib/floodlight
git fetch && git checkout cloudlab-hp-patch
java -jar target/floodlight.jar

My flow tables on Aruba:

I have not added any firewall or ACL rules, nothing. I just installed Floodlight, connected two PCs to the switch, enabled and configured OpenFlow on switch, but they even can't ping each other.

Hi Roger,

If you run the "debug openflow" and "debug destination session" commands on the 2920, it will print OpenFlow debug output to the switch console. That debug output (although terse) will likely identify a flow that's being sent by floodlight and rejected by the switch, or whatever other issue is causing this communication failure.

Ideally, you'd want to have the debug output enabled before the floodlight controller connects (so you can see the handshake) and you'd want to have it enabled when the endpoints are attempting to ping eachother (so you can see what happens to flows that should forward their traffic). If the debug output doesn't identify the problem for you, could you post it here?

It would also be best to run the latest available switch firmware for 2920. Which version are you using?

Shaun

I have newest Aruba firmware: #WB.16.03.0003. I had some troubles with catching the debug messages to file, but tried to make some screenshoots. You were right, it's a great way of checking what's going on, thank you.

However, it is not clear to me. It seems that floodlight installs the drop rules? What's wrong? What can I do about this? How to make it work?

Hi Roger,

Could you post a copy of your switch configuration, along with the output of:

• show openflow
• show openflow instance instance-name
• show openflow instance instance-name flows

Your thread reminded me of another recent thread where another user was attempting to connect Beacon to a 2920. What we noted was that the 2920 does not support the ETH_DST match field in its hardware table. If floodlight is also attempting to use flows which match ETH_DST, that may be the cause of the issue you're seeing.

https://community.hpe.com/t5/Software-Defined-Networking/Using-Hardware-flows-table-with-hp-2920-24g/td-p/6931454

I didn't notice anything strange in the screenshots you posted. The highlighted message "Exiting fail secure mode" just means that the switch has connected to the controller and the connection is no longer in the "failed" state.

Shaun

First of all, thank you for helping me. I will read throught the thread you linked.

show openflow:

show openflow instance instance-name

show openflow instance instance-name flows

And finally, my configuration:

Hello Roger,

Your OpenFlow instance is missing a flow on Table 0 that redirects packets to Table 100 via a GOTO instruction.

This rule is added by the switch by default when the instance is enabled. In your case, the Floodlight controller has come back and first wiped out all the flows on the switch on each table and then added just the flow on Table 100 to steal packets to the controller. Since the packets first do a lookup against Table 0, due to the missing redirection flow to Table 100,  all the packets are being dropped at 0 and you don't see packets coming to 100.

I would ask you to manually add the Table Miss rule back to Table 0 (Any match + Prio=0) with an action to GOTO Table 100.

With that you should start seeing PING packets coming to Table 100.

Thanks!

Abhay

Thank you for help. I tried to push the flow you mentioned:

curl -X POST -d '{"switch":"00:01:94:18:82:25:bc:80", "table":"0",
"name":"TableMiss", "priority":"0",
"instruction_goto_table":"100"}'
http://10.0.1.11:8073/wm/staticentrypusher/json

But it gave me errors in Floodlight: https://gist.github.com/anonymous/73fb635852e9316900f081a7d0b9331a

Hello Roger,

Can you please attach the packet capture for the flow-mod sequence?

The gist output has a lot of flow-mod errors in it and I am finding it difficult to map it to the flow-mod you pushed.

Also,  just enable debug on OpenFlow instance and capture the output when you push the flow and share it as well.

Thanks!

Abhay

Ok, here are logs from Aruba: https://gist.github.com/anonymous/b3a9cdf1be2c024a3318f3f141e4e924.

Firstly, I removed all the rules, and stopped Floodlight. Then, I turned on Floodlight and added this first flow:

curl -X POST -d '{"switch":"00:01:94:18:82:25:bc:80", 
"table":"0", "name":"TableMiss0", 
"priority":"0", 
"instruction_goto_table":"100"}' 
http://10.0.1.11:8073/wm/staticentrypusher/json

After that, I started to get the following errors: https://gist.github.com/anonymous/8ef697b583bcbf494091edcec7329e35

Later, I added another rule:

curl -X POST -d '{"switch":"00:01:94:18:82:25:bc:80", 
"name":"From100ToNormal", 
"table":"100", "cookie":"0", 
"priority":"33000","active":"true",  
"actions":"output=normal"}' 
http://10.0.1.11:8073/wm/staticentrypusher/json

And then errors dissapeared (as you can see in the above gist, exactly at 2017-03-22 15:29:19.517).

Now I'm not sure, what's going on. I  can push other rules, to allow for instance ARP, ICMP, SSH, but this error bothers me a lot.

Hello Roger,

To help you with the problem better, I would again ask you to please share the debug logs on the switch for OpenFlow along with the packet capture of the whole sequence. That would help us analyze the problem better.

The Floodlights shared are not of much use to us since the OpenFlow messages are not dissected and also they don't really tell us why the switch rejected the flow-mod.

To capture debug logs for OpenFlow, just run the following commands and then execute your tests.

switch# debug destination session

switch# debug openflow

Also, please share the output of "show openflow instance <name> flows" after the tests are done.

Since you also mention the errors disappear after adding a rule on table 100, is it possible that the other errors are due to the controller trying to react to packets coming to the controller via its default rule (output=controller) on 100 that is nullified by the addition of the higher priority rule on 100 that just tells the switch to forward any packet per its non-OpenFlow pipeline.

Thanks!

Abhay