opennetworkinglab / flowvisor Goto Github PK

View Code? Open in Web Editor NEW

164.0 164.0 67.0 15.2 MB

FlowVisor - A network hypervisor

License: Other

Shell 4.11% Perl 0.17% Python 7.50% Java 87.64% C 0.58%

flowvisor's People

Contributors

Stargazers

Watchers

flowvisor's Issues

flowDB feature has a memory leak

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: Next
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Rob Sherwood Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: gec12
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Running flowvisor with flowDB enabled causes it to run out of memory. These logs seem to matter;
Jun 15 12:47:00 openflow5 flowvisor: INFO-classifier-dpid=00:00:00:12:e2:78:67:65: flowDB: ignoring unmatched flowRemoved:ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=d8:d3:85:65:33:d5,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.102.112,nw_src=10.42.102.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=8]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_naxos-33102_ID__endpoint_stanford_edu_76_dpid=00:00:00:12:e2:78:67:65: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=d8:d3:85:65:33:d5,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan 0xffff,dl_vpcp=0,nw_dst=10.42.102.112,nw_src=10.42.102.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=8]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_production_dpid=00:00:00:12:e2:78:67:65: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=d8:d3:85:65:33:d5,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.102.112,nw_src=10.42.102.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=8]
Jun 15 12:47:00 openflow5 flowvisor: INFO-classifier-dpid=00:00:00:12:e2:78:31:f5: flowDB: ignoring unmatched flowRemoved: ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=1,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_naxos-33101_ID__endpoint_stanford_edu_75_dpid=00:00:00:12:e2:78:31:f5: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=1,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_production_dpid=00:00:00:12:e2:78:31:f5: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=1,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]
Jun 15 12:47:00 openflow5 flowvisor: INFO-classifier-dpid=00:00:00:12:e2:78:67:65: flowDB: ignoring unmatched flowRemoved: ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_naxos-33101_ID__endpoint_stanford_edu_75_dpid=00:00:00:12:e2:78:67:65: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]
Jun 15 12:47:00 openflow5 flowvisor: WARN-slicer_production_dpid=00:00:00:12:e2:78:67:65: flowrewriteDB: tried to remove non-existent flow ofmsg:v=1;t=FLOW_REMOVED;l=88;x=0;OFMatch[in_port=4,dl_dst=00:26:b9:8b:bd:f0,dl_src=00:14:d1:19:43:f4,dl_type=0x800,dl_vlan=0xffff,dl_vpcp=0,nw_dst=10.42.101.96,nw_src=10.42.101.91,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=0]

Comments
Comment by Rob Sherwood [ 23/Jun/11 ]
bumped to Blocker because I want this fixed for the next release
Comment by Nick Bastin [ 27/Jun/11 ]
You are free to fix it without it being a blocker.. This doesn't actually prevent FV from working in lots of environments, so I don't see it as a blocking issue.
Comment by Rob Sherwood [ 06/Jul/11 ]
possibly related, but the tests-flowdb.py regression test just failed on me... just once... for no known reason. Could be a race condition in the test, but... documenting a little just in case.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-94

Queue_stats: FV doesn't filter the ports for a slice

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Tatsuya Yabe Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
After a controller has sent 'queue_stats_request' with 'all_ports' to a switch via FV and the switch sends back 'queue_stats_reply' with all the port it has, FV should filter and select the ports for the slice depending on which ports the slice owns, but FV just passes through the entire message.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-171

dl_vlan only accepts in decimal and only prints in hex

Status: In Progress
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Improvement Priority: Major
Reporter: Nick Bastin Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Not a big deal, but listFlowSpace prints my VLAN match as "dl_vlan=0x64" while changeFlowSpace requires that I enter it as "dl_vlan=100."
I should probably have said that I actually prefer the decimal representation of the VLAN number.
/Chris
Proposed resolution:
add support to read by hex
add feature to fvctl to pick output format

Comments
Comment by Nick Bastin [ 31/May/11 ]
So it turns out that the printing by hex is buried in openflowj, not in flowvisor (since we use a raw OFMatch structure), we probably should just cover this structure so we can accept and print both formats.
Comment by Ali Al-Shabibi [ 10/Oct/11 ]
The output format is set by the config field flowvisor!output_base (or FVConfig.OUTPUT_BASE). You can set it to any int value you want. The FVMatch class will take care of converting the bases correctly and report (or accept as input) any base you want. As long as you enter something valid for that base. The default is base 10.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-33

Log level settings in config.json and /scripts/fvlog.config do not work as expected.

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: 0.8.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Masayoshi Kobayashi Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
on openflow1.stanford.edu (Debian lenny)

Description
If I set log level to INFO in config.json (the log level in /scripts/fvlog.config is "DEBUG, system" (default setting)) and run without "-l", I see all the log message on all login windows and syslog file. If I change the log level of fvlog.config to "INFO, system", then no log message shows up either on syslog file or any login window.

Comments
Comment by Ali Al-Shabibi [ 06/Mar/12 ]
We'll probably want to go with a logging facade here, ie. slf4j.
Comment by William Snow [ 01/Oct/12 ]
Being worked by Sumanth

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-169

flowvisor should send PortStatus messages when the port part of a slice's flowspace changes

Status: Reopened
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Rob Sherwood Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Current, when a slice's flowspace changes, e.g., adds port 2 on $dpid, the flowvisor silently updates it's internal state but does not notify the controller that it has a new port. This somewhat breaks the openflow semantics. Better would be if for each port add/delete, flowvisor sent a corresponding PortStatus message.
The appropriate function to mod would be FVSlicer.updatePortList() which calcs the difference between old and new ports after a config update. This bug could be addressed in ~4 lines or so.

Comments
Comment by Ali Al-Shabibi [ 06/Feb/12 ]
From what I can tell the flowvisor notifies the controller of the new port. Actually it forward the Port Status message to the controller.
After updating it's internal state, flowvisor does this:
for (FVSlicer fvSlicer : fvClassifier.getSlicers()) {
try { fvSlicer.handleEvent(new ConfigUpdateEvent(fvSlicer, FVConfig.FLOWSPACE)); } catch (UnhandledEvent e) { FVLog.log(LogLevel.CRIT, fvSlicer, "tried to process ConfigUpdateEvent, but got: " + e); }
...
for (FVSlicer fvSlicer : fvClassifier.getSlicers()) {
if (fvSlicer.portInSlice(port)) { fvSlicer.sendMsg(this, fvClassifier); }
}
I am going to mark this as resolved, it someone disagrees then say so.
Comment by Rob Sherwood [ 06/Feb/12 ]
I'm a little slow on the context, but I think this is a different case.
I think the point of this bug is if you update the flowspace to add
a new port, FV should send a new port message (even though none came
from the switch), because the controller would have no idea that there
is a new port there.
Make sense?
Comment by Ali Al-Shabibi [ 06/Feb/12 ]
oh yeah. You are right. Reopening issue....

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-127

Implement all XMLRPC functionality in the JSON api

Status: Open
Project: Flowvisor
Component/s: RPC
Affects Version/s: 0.8.1
Fix Version/s: None

Description
We should design out this API, and then implement it.

Comments
Comment by Ali Al-Shabibi [ 09/Feb/12 ]
Changes available at https://openflow.stanford.edu/display/DOCS/API+Changes

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-158

flowvisor reports a DPID twice with getSliceStats

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Bug Priority: Major
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
My rule of last resort points to my "beacon" slice. There are 2 OpenFlow? switches currently up on my network. DPID 00:5c:00:26:f1:1c:42:00 has an uplink to my non-OpenFlow? core switch (10 GB/s link) and nothing else. DPID 00:04:00:26:f1:1c:29:00 has a 1 GB/s uplink to the core switch and 3 Asterix demo machines, but nothing else. Both switches are HP 5406zl boxes running the latest (as of last week) OF firmware. Here is what getSliceStats shows:
root@flowvisor:/var/local/src/flowvisor# fvctl --passwd-file=/root/.fvp getSliceStats beacon
Got reply:
---Sent---
slicer_beacon_dpid=00:5c:00:26:f1:1c:42:00 :: ECHO_REQUEST=2,PACKET_IN=65204,HELLO=75,FLOW_REMOVED=6789
slicer_beacon_dpid=00:5c:00:26:f1:1c:42:00 :: ECHO_REQUEST=2,PACKET_IN=32152,HELLO=38,FLOW_REMOVED=3275
slicer_beacon_dpid=00:04:00:26:f1:1c:29:00 :: ECHO_REQUEST=2,PACKET_IN=98290,HELLO=114,FLOW_REMOVED=10346
Total :: ECHO_REQUEST=6,PACKET_IN=195646,HELLO=227,FLOW_REMOVED=20410
---Recv---
Total ::
---Drop---
slicer_beacon_dpid=00:5c:00:26:f1:1c:42:00 :: PACKET_IN=74991
slicer_beacon_dpid=00:5c:00:26:f1:1c:42:00 :: PACKET_IN=37224,FLOW_REMOVED=1
slicer_beacon_dpid=00:04:00:26:f1:1c:29:00 :: PACKET_IN=115029,FLOW_REMOVED=3
Total :: PACKET_IN=227244,FLOW_REMOVED=4

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-32

fix `make install` to complain if the install user/group doesn't exist

Status: In Progress
Project: Flowvisor
Component/s: Build
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Bug Priority: Major
Reporter: Nick Bastin Assignee: Anne Struble
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 5 minutes
Original Estimate: Not Specified

Description
too confusing for people

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-16

need to flush old flow entries

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Bug Priority: Minor
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
When you delete a slice, not only should you flush the flow entries from the FV's flowtable, you should probably also flush them from the switch. The first now works, but FV does not yet flush them from the switch.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-13

look into niky's weird flowmod expansion

The weird expansion that we saw, is that although the flow_mod as given it was allowed by the flowspace rules, the FV installed 3 extra flows. In particular in the FV there were the following rules for a slice :
rule 60: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9080]],actionsList=[Slice:smartre=4],id=[104771450],priority=[150],]
rule 61: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9080]],actionsList=[Slice:smartre=4],id=[104773029],priority=[150],]
rule 62: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9081]],actionsList=[Slice:smartre=4],id=[104774619],priority=[150],]
rule 63: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9081]],actionsList=[Slice:smartre=4],id=[104776183],priority=[150],]
rule 64: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9082]],actionsList=[Slice:smartre=4],id=[104777748],priority=[150],]
rule 65: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9082]],actionsList=[Slice:smartre=4],id=[104779388],priority=[150],]
I assume that all these rules are connected with OR, i.e. if the packet match any of these rules it will be given the the smartre slice.
When the controller of the slice tries to install a flow of the type tp_src=9080 and tp_dst=* then this according to rule 61 is allowed, and it doesn't conflict with any
other rules, so it should be installed as is, however I think that multiple rules are installed :
tp_src=9080 and tp_dst=9080 (from rule 60)
tp_src=9080 and tp_dst=9081 (from rule 62)
tp_src=9080 and tp_dst=9082 (from rule 64)
and
tp_src=9080 and tp_dst=* (from rule 61)
The first three flows are redundant. I am not convinced that this is a bug, but given that the last rule includes the other three then only the last one should be installed. You can imagine that if there are more wildcards in the flow then the number of flows that are installed might grow significantly.
Also out of curiosity, what will happen if there is a different slice that has a higher priority rule for only one of tp_dst, let's say the aster*X tp_dst 10001? Will the FV install a flow for all the possible tp_dst other than 10001, or there is a way to install a flow that would negate a port, i.e. tp_dst!=10001?

Comments
Comment by Niky Riga [ 16/Aug/11 ]
I was able to reproduce this problem, in a simpler setting. I used the same setup described above so the description is still valid (minus the flowspace rule numbers). I have captured FV's configuration file and the tcpdumps between the flowvisor and the controller and the flowvisor and the switches, which are attached here.
When the controller tries to install a flow that wildcards everything but the TP_SRC field (e.g pkt 45 in fv_ctrl.pcap), the fv installs 4 flows at the same priority (last 4 flowmods in pkt 103 in fv_sw.pcap) where the first 3 are redundant since the fourth one covers them and the fourth is actually the correct flowmod based to the flowspace.

Comment by William Snow [ 01/Oct/12 ]
This needs to be turned into a test case before closing

Original Jira issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-44

new passwd prompt gets NPE if non-terminal

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Bug Priority: Major
Reporter: Nick Bastin Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
fvctl listFlowSpace | less
causes an NPE
Just need to test and prompt

Comments
Comment by Nick Bastin [ 11/Jun/11 ]
This has the proper behaviour for me on Ubuntu 10.10, so I'm moving this to long term until someone can report an environment where this happens.
Comment by Rob Sherwood [ 04/Jul/11 ]
I believe this was partially fixed in:
commit 59104f6c62cca32fac3bc53a8015c7caeb0d353a
Author: Rob Sherwood [email protected]
Date: Thu Mar 17 20:54:01 2011 -0700
made fvctl not throw NPE when called fvctl | less
System.console() returns null if called without
a direct tty... or something. Default to print
to stderr and for some reason it doesn't echo
the password characters.
But I left the bug open because while it works in the fvctl | less case, it still echo's the passwd in the fvctl > output case. Weird, huh?

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-34

fvctl changePasswd improvements

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Josh Smift Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: changepasswd-improve.txt

Description
fvctl changePasswd should (a) prompt you to confirm the new password if you run it interactively, in case you mistyped the new password; (b) allow you to run it non-interactively.

Comments
Comment by Masahiko Takahashi [ 10/Sep/12 ]
Hope this patch helps:

diff -r 8ef46d07f084 src/org/flowvisor/api/FVCtl.java
--- a/src/org/flowvisor/api/FVCtl.java Mon Sep 10 14:11:44 2012 -0700
+++ b/src/org/flowvisor/api/FVCtl.java Mon Sep 10 15:31:08 2012 -0700
@@ -62,6 +62,7 @@
new APICmd("changeSlice", 3, " "),
new APICmd("deleteSlice", 1, ""),
new APICmd("changePasswd", 1, ""),

  new APICmd("changePasswd2", 2, "<slicename> <new_passwd>"),
new APICmd("getSliceInfo", 1, "<slicename>"),
new APICmd("addQueue", 3, "<dpid> <slicename> <queue#>"),
new APICmd("removeQueue", 2, "<dpid> <slicename>"),

@@ -439,6 +440,11 @@
public void run_changePasswd(String sliceName) throws IOException,
XmlRpcException {
String passwd = FVConfig.readPasswd("New password: ");

  String confirm = FVConfig.readPasswd("Retype new password: ");

```
  if (!passwd.equals(confirm)) {
```

      System.out.println("doesn't match");

```
      return;
```

  }
Boolean reply = (Boolean) this.client.execute("api.changePasswd",
        new Object[] { sliceName, passwd });
if (reply == null) {

@@ -451,6 +457,20 @@
System.err.println("failed!");
}

public void run_changePasswd2(String sliceName, String passwd) throws IOException,
XmlRpcException {

  Boolean reply = (Boolean) this.client.execute("api.changePasswd",

          new Object[] { sliceName, passwd });

```
  if (reply == null) {
```

      System.err.println("Got 'null' for reply :-(");

```
      System.exit(-1);
```
```
  }
```
```
  if (reply)
```
```
      System.out.println("success!");
```
```
  else
```
```
      System.err.println("failed!");
```
}
public void run_addQueue(String dpid, String sliceName, String queue)
throws IOException, XmlRpcException {
Boolean reply = (Boolean) this.client.execute("api.addQueue",
diff -r 8ef46d07f084 src/org/flowvisor/config/SliceImpl.java
--- a/src/org/flowvisor/config/SliceImpl.java Mon Sep 10 14:11:44 2012 -0700
+++ b/src/org/flowvisor/config/SliceImpl.java Mon Sep 10 15:31:08 2012 -0700
@@ -62,7 +62,7 @@
" passwd_salt, controller_hostname, controller_port, contact_email, drop_policy, lldp_spam) " +
"VALUES(?,?,?,?,?,?,?,?,?,?,?)";
private static String DELETESLICE = "DELETE FROM Slice WHERE " + SLICE + " = ?";
private static String SCRYPT = "UPDATE Slice SET " + CRYPT + " = ? AND " + SALT +
private static String SCRYPT = "UPDATE Slice SET " + CRYPT + " = ?, " + SALT +
" = ? WHERE " + SLICE + " = ?";

private static String FLOWVISOR = "SELECT id from " + Flowvisor.FLOWVISOR + " WHERE " + Flowvisor.CONFIG + " = ?";

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-174

bugfix: duplicate dpids

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Bug Priority: Major
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: ilabs-11
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Do something more intelligent when multiple switches connect with the same datapath id. Soltions: drop second (ugly) or virtualize second (uglier).

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
still an issue in 0.7.x ; should probably have a bigger claxon than syslog... but minimally, we should add a check that sends an FVLog.log(Level.ALERT, " DUplicate ID detected: $DPID from both $IP1:$PORT1 and $IP2:PORT2"
Comment by William Snow [ 01/Oct/12 ]
This needs to be turned into a test case before closing.

unhack longer lldp hack

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Improvement Priority: Major
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
made flowvisor name long enough to not have 60 byte packets, to hot fix kk's problem...
Need a better long term fix

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
Potentially still an issue; some switches do bad (802.1 spanlen?) things with ethernet packets that are below a certain size (60 bytes seems to be a magic number, including ethernet header). With the LLDP's that the FV sends, it's less of an issue because we send a properly formatted LLDP packet with a bunch of stuff in the payload, but someone who understands ethernet before ethernetII should look at this and verify that we don't have a problem.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-53

make "port alread bound" fatal error clearer to the user

Status: In Progress
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
If you run flowvisor and one of the ports (either OF control or XMLRPC server) is already bound, the error to the user is not very clear:
Starting FlowVisor?
--- Setting logging level to NOTE
respawning too fast -- DYING

Comments
Comment by Nick Bastin [ 10/Sep/11 ]
Really there are a lot of reasons that you can see "respawning too fast – DYING", we should make them all clear to the user rather than just bailing out.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-30

SSL parameters are on the command line including password!

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Rob Sherwood Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
ps auxww |grep -i flowvisor :
[snip]
-Djavax.net.ssl.keyStore=/usr/local/etc/flowvisor/mySSLKeyStore
-Djavax.net.ssl.keyStorePassword=CHANGEME_PASSWD
it's not really that bad because the file is read-only by the flowvisor user and the password is only for the key in the ssl file which isn't used by anything, but still... should be coded up as an internally listed property with maybe the password in the config file.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-115

Make /etc/init.d/flowvisor more configurable

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Josh Smift Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Put anything that you want to be a user-settable variable into a config file that /etc/init.d can read, like /etc/default/flowvisor on Ubuntu (and, I think, other Debian-like systems), /etc/sysconfig/flowvisor on Red Hat (and derivatives), etc, so you can change FV_USER and FV_CONFIG, without modifying /etc/init.d.

Comments
Comment by Josh Smift [ 28/Aug/12 ]
We talked about this on IRC, and concluded that we liked the idea of having the package create the user that it wants to run as (FLOWVISOR-149), in which case that doesn't really need to be configurable (because it's no longer the responsibility of the admin to create a user); and FV_CONFIG is gone anyway, now that config info is in a DB. So, I think this ticket can be closed as wontfix (or whatever the appropriate JIRA thing is).

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-148

clean up API code

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
rewrite everything to use lookupSlice and lookupClassifier internal calls (code reduction)
move all API methods to synchronized and stop manually marshalling API params/responses

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-39

Implement a "make install.fast"

Status: Open
Project: Flowvisor
Component/s: Build, Packaging
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Improvement Priority: Minor
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
make install gets really annoying about the 5th time you've run it in a day when you're testing bugfixes and the like (or when someone else installed the last version and you don't know what options they chose). There should be a make install.fast which doesn't ask you any questions and just uses the same answers that were used the last time it was run.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-85

Assign queue to slice

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Yiannis Yiakoumis Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
In the old FV one could assign a queue to a slice to implement bandwidth isolation. The new one doesn't seem to do this. It's necessary in order to keep the applications unaware of the fact that they run on a slice, and enforce isolation among slices.

Comments
Comment by Ali Al-Shabibi [ 01/Feb/12 ]
need to update openflowj delivered with flowvisor to support enqueue action. Also this falls in the category of resource limits. There is a small list of resources we would like to slice, which can be found here https://openflow.stanford.edu/display/DOCS/Resource+and+Slice+limits. User/developer input is welcome as always.
Comment by Masahiko Takahashi [ 20/Jul/12 ]
There are two issues for supporting queue. One is, as Ali pointed out, OpenFlowJ needs to be updated for parsing QueueGetConfig{Request,Reply} messages. And the other is, to achieve bandwidth isolation between slices, FlowVisor should add ENQUEUE action to a FlowMod or PacketOut message received from a controller.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-147

implied flowspace

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
if a user specified an ip-based flowspace, then imply that ethtype = IP
same with tcp/udp/icmp with ip_proto
In general, need to add more usability to the config process.

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
this is still an issue with 0.7.x;
for example, when someone inserts a flowspace rule with an IP field specified, we should consider (there are pros and cons) forcing the dl_type to ETHER_IP. OVS forces a bunch of these things by default and we should consider doing it as well. Some switches act very differently about this (needs to be investigated).
Comment by Josh Smift [ 06/Jul/11 ]
This is somewhat related to https://openflow.stanford.edu/bugs/browse/FLOWVISOR-35, ja?
If you force it to ETHER_IP, will that cause the rule to miss ARP?

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-65

when expanding flowmods, only copy bufferid to first flowmod, all others should get BUFFER_ID_NONE (-1)

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Rob Sherwood Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 1
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
See title (very small problem).
The symptoms are slice controllers receiving OFPBRC_BUFFER_UNKNOWN (type=1 code=8) errors when using flowvisor and no errors without flowvisor.
The relevant code and (untested) fix is in: src/org/flowvisor/message/FVFlowMod.java :

boolean isFirstExpansion = true;
for (FlowIntersect intersect : intersections) {
if (intersect.getFlowEntry().hasPermissions(
fvSlicer.getSliceName(), SliceAction.WRITE)) {
expansions++;
FVFlowMod newFlowMod = (FVFlowMod) this.clone();
// replace match with the intersection
newFlowMod.setMatch(intersect.getMatch());
if ( isFirstExpansion ) { + isFirstExpansion = false; + } else { + newFlowMod.setBufferId(BUFFER_ID_NONE); + }
// update flowDBs
fvSlicer.getFlowRewriteDB().processFlowMods(original,
newFlowMod);
fvClassifier.getFlowDB().processFlowMod(newFlowMod,
fvClassifier.getDPID(), fvSlicer.getSliceName());
// actually send msg
fvClassifier.sendMsg(newFlowMod, fvSlicer);
}
}
For details:
https://mailman.stanford.edu/pipermail/openflow-discuss/2011-September/002687.html

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-133

implement isolation for all of_actions (include set_dl_dst)

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
Srini,
I don't know if this might cause a problem, but I thought that you might want to know about it (being that flowvisor logged it as a "CRIT" error). It looks like flowvisor is spitting out the referenced syslog message in response to a FLOW_MOD message from your controller. I grep'd all 'Oct 14 16:15:*' flowvisor messages from the syslog file with flowvisor in DEBUG logging mode. The file can be found at:
http://www.cs.princeton.edu/~tengi/OpenFlow/flowvisor.debug.log.20101014T1615
The easiest way to find an example is, using your favorite editor, to go to the bottom of the file and search backwards for CRIT. Please let me know if I should be concerned about these messages or if I should just ignore them.

In addition, snac is having trouble displaying bandwidth stats (again), and I'm seeing a bunch of

flowvisor: WARN: msg failed sanity check: ofmsg:v=1;t=STATS_REQUEST;l=56;x=0;st=FLOW

messages in the messages file. I'm guessing that these are related, but I can't tell from the syslog message. Unfortunately, none of these messages showed up in the 1 minute slice I collected above. Is there a preferred debugging technique I should use to better track this down?

Note that 'git log' in the flowvisor source directory starts off with:

commit dd1e8c90f65c3992629ccfef70e143ead07673f7
Author: Rob Sherwood rob.sherwood@...
Date: Fri Oct 8 17:09:36 2010 -0700
fixed #183: prune ports from port_stats that are not in slice
untested
commit d8a057a920c98894f79bd02ef9d94a8ba2eb5b7e
Author: Rob Sherwood rob.sherwood@...
Date: Fri Oct 8 17:03:57 2010 -0700

Release flowvisor-0.6.beta4

/Chris

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-27

Create per-switch config parameters

Status: Open
Project: Flowvisor
Component/s: Config
Affects Version/s: 0.8
Fix Version/s: Long Term

Type: Improvement Priority: Major
Reporter: Nick Bastin Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Some parameters would be useful to have on a per-switch basis (timeout values, per-slice FLOOD permissions, etc.). Also this would allow us a place to configure a DPID for a non-passive open.

Comments
Comment by Rob Sherwood [ 08/Jul/11 ]
if you look at the flood-perms patch that I made, a flood-perms enabled config will have a .switches.default.flood_perms entry as a step towards this. It also looks (I think) for .switches.$dpid.flood_perms, so IMHO this is the right path to follow.
Comment by Nick Bastin [ 08/Jul/11 ]
I was thinking something a little less annoying to type, like:
{ "DPID" : "00:00:00:00:00:00:01:52",
"Config" : {
"flood_perms" : ...,
"session_timeout" : 5000, // ms
"stp_mode" : "HP"
}
}
etc.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-109

Handle multiple slices in config file that have same controller

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Improvement Priority: Minor
Reporter: Anne Struble Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Handle multiple slices in config file that have same controller (Branch off of flowvisor-47, which fixes this issue when encountered through rpc interface)

Comments
Comment by Rob Sherwood [ 03/Jun/11 ]
Just so I understand, the concern here is that while we have prevented duplicate controller URLs from ending up in the config from the RPC calls, they could still show up in the config through other means (e.g., editted by hand)?
If yes, I would say this is not a serious issue and more, this duplicate controller URL prevention was a feature to prevent users from shooting themselves in the foot, but there are certain, almost pathological situations where we might want to allow it, so hand editted config might be reasonable there.
Did I understand correctly?
Comment by Nick Bastin [ 03/Jun/11 ]
Yes, the only remaining problem is if you go behind RPC's back and configure this by hand. IMO, if users edit the config file by hand, they get what they deserve..
Comment by Yiannis Yiakoumis [ 12/Oct/11 ]
Just got a newer version of FV and got into this, which causes me issues. In my case the controller handles multiple (small) networks. So, I have 10 independent APs, which all go through the same FV and they end up to the same controller. But still, I want to keep them as separate slices, as they are different networks.
I use the RPC to create/delete slices dynamically, and this currently blocks me.
Thoughts??

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-91

too much useful logging still goes to stderr instead of FVlog

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Description
logs from the XMLRPC webserver, errors from the JVM and other stuff go to stderr... so much so that we automatically capture stderr in the init.d script. But, this opens us to bugs (like what just happened today) where if the disk fills up, all of FV comes to a crashing halt blocked on writing to stderr (I think).
Anyway, this should be addressed; even though it's likely multiple issues.

Comments
Comment by William Snow [ 01/Oct/12 ]
Sumanth is working this one.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-107

slice names longer than 255 will break lldp

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
shouldn't be a problem, but apparently 'Crazy Load Balancer ID_urn_publicid_IDN+openflow_stanford+ch+slice+e4a916b4-4c54-4e7a-98af-08f91bcc62f2_127_0_0_1%3A8001' is a valid slice name
though under 255 characters

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
this bug has to do with how LLDP packets are virtualized, i.e., we add a trailer on to the end of them. In the trailer, the slice's name is listed with a variable length string up to 255 bytes in length. Not clear that this is a big problem, but if it does get truncated, LLDP's will get lost.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-14

Install script should have modularized init script handling for different platforms

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
We need to handle things like upstart, etc.

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
started collecting other platform init scripts in ./utilities/

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-86

Online CLI help doesn't work

Status: Open
Project: Flowvisor
Component/s: UI Tools
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Type: Bug Priority: Minor
Reporter: Nick Bastin Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: opnk11
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
help or ? only work at the top level. It'd be nice if you could hit ? anywhere ala Cisco IOS and get live help.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-83

add QoS queue rewriting

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: Next
Fix Version/s: Next

Type: Improvement Priority: Critical
Reporter: Rob Sherwood Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Old flowvisor had the ability to rewrite output:X to queue:Y,port:X ; need to add this feature to new FV
add a queue field into the slice permissions of a flowspace entry, e.g.,
"Slice:alice=4" (write permissions) becomes "Slice:alice=4q3" (write permissions, but rewrite to queue #3)
add to api to set/change this (root only)

Comments
Comment by Rob Sherwood [ 27/Jun/11 ]
updated description for clarity. Also, this ties into https://openflow.stanford.edu/bugs/browse/FLOWVISOR-97

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-81

Don't ship a default configuration

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Josh Smift Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
Rather than trying to ship a default configuration that works out of the box, FV should ship unconfigured, and the install docs should include a step for admins to generate a new configuration.
In particular, I think this means that the package should not include mySSLKeyStore or config.json, and that the docs should include a note to run 'sudo -u flowvisor fvconfig generate /etc/flowvisor/config.json' after the package is installed.
(It might also be nice if fvconfig didn't include the 'alice' and 'bob' slices by default, but I don't feel strongly about that. But in fact everyone who installs FV just has to delete them, and that seems sort of silly... If you want to have some example slices, maybe have some docs showing how to create those example slices?)

Original issue: https://openflow.stanford.edu/bugs/si/jira.issueviews:issue-html/FLOWVISOR-188/FLOWVISOR-188.html

jetty logging goes to stderr instead of FVLog

Status: In Progress
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: Long Term

Type: Bug Priority: Minor
Reporter: Rob Sherwood Assignee: Anne Struble
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified

Description
It would be nice if jetty could be made to use the existing FV logging service FVLog ( or vice versa...)
2011-07-05 16:56:06.183:INFO::Logging to StdErrLog::DEBUG=false via org.eclipse.jetty.util.log.StdErrLog
2011-07-05 16:56:06.221:INFO::jetty-7.0.2.v20100331
2011-07-05 16:56:06.484:INFO::Started [email protected]:8081

Comments
Comment by Anne Struble [ 06/Jul/11 ]
Pushed to origin anne/dev
Comment by William Snow [ 01/Oct/12 ]
Sumanth is working this one

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-101

make cross product of topology X flowspace easier

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
too hard to do
foreach dpi

foreach port

    foreach flowspace

        fvctl addFlowSpace $dpid ...

implement a list of dpid:port pairs

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
not just easier, but more efficient.
Indiana folks are reporting 20k FS entries
Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-71

OF error message: Untranslate an XID in the embedded message

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Masahiko Takahashi Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: Flowvisor
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
There is an openflow message embedded in most error messages, and when FV
sends an error message up to the controller, we should make sure to
untranslate the XID in the embedded message in addition to the outer XID.
(The attached patch was created by Masahiko Takahashi and Rob Sherwood)
**I did not find an attached patch when I moved this issue

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-135

Nightly build packages in unstable apt repo

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Improvement Priority: Major
Reporter: Nick Bastin Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: geni
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
It was proposed at the openflow bi-weekly sync that we have packages made for things that aren't releases, but so you didn't have to pull from git and build yourself. An easy manifestation of this would be to just make nightly builds in an unstable apt tree, and people could pull whatever they want, probably named something like:
flowvisor-nightly-20110530
There's probably some work that would go into making this version number work in all the right places.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-90

Missing instructions for package install

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Luisa Nevers Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
Ubuntu 10.04.2 LTS
Ubuntu package FlowVisor 0.8.1.2

Description
Using instructions from https://openflow.stanford.edu/display/flowvisor/fv_deploy.
If a user follow the "install ubuntu package and configure" path there are two issues:
the instructions jump into using a password, but no instructions are given to set/generate
a FlowVisor password.
Also missing are instructions to set the user/group for the FlowVisor.

Comments
Comment by Josh Smift [ 29/Aug/12 ]
The page that this ticket is about, it no longer exists. The new page has some issues, but I think this particular ticket can be closed.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-137

FlowVisor 0.6.x package improvements

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
A couple of suggestions for improving the FlowVisor? 0.6.x package:
The package currently sets /usr/etc/flowvisor (and .../envs.sh) to be owned by UID 1001. Could they instead be owned by "the 'openflow' user, whatever UID that happens to have"? (Or a 'flowvisor' user, if you like that better; we currently have all our OF stuff sharing a pseudo-user, but don't feel strongly about it.)
It'd be nice if /usr/etc/flowvisor (and .../envs.sh) were world-readable.
Other Ubuntu things don't seem to use /usr/etc, so it might be more Debian-liketo use /etc/flowvisor instead of /usr/etc/flowvisor.
Could the package run 'sudo -u openflow fvconfig generateCert' after installation, but only if the cert doesn't already exist?
It'd be nice if the package was signed, so it could be installed non-interactively (e.g. via Puppet or Cfengine).

Comments
Comment by Josh Smift [ 28/Aug/12 ]
Most of these things have been fixed in more recent versions. For the two that haven't, I've created new, separate tickets for them: FLOWVISOR-183 for the /usr/etc -> /etc move, and FLOWVISOR-184 for the package-singing thing. I think this one can be closed.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-43

LLDP packet made by FlowVisor doesn't have "the end of LLDPDU" nor a TLV header before padding(0xcafebabe)

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Masahiko Takahashi Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: Flowvisor, NEC
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Add-the-end-of-LLDPDU.patch

Description
When looking at packet dump with wireshark, LLDP packets made and sent by FlowVisor
were marked as "malformed packet." Because an LLDP packet made by FlowVisor doesn't
have "the end of LLDPDU" nor a TLV header, but followed by padding(0xcafebabe) that
is recognized as "type = 101, length = 254"(shown by wireshark). The attached patch
inserts "the end of LLDPDU" and proper TLV header for the padding. In addition, it
modifies some other things regarding LLDP packet, which are not big deals, though.

Comments
Comment by Ali Al-Shabibi [ 06/Feb/12 ]
missing patch....
Comment by Masahiko Takahashi [ 07/Feb/12 ]
Here is a patch...
From 79005596f4bc637dab77ddf518819cf37758f938 Mon Sep 17 00:00:00 2001
From: Masahiko Takahashi [email protected]
Date: Fri, 2 Sep 2011 15:48:24 -0700
Subject: [PATCH] LLDP: Adding "the end of LLDPDU" and proper TLV header before padding.

An LLDP packet made and sent by FlowVisor has no "the of of LLDPDU"
(0x00, 0x00) before padding (0xcafebabe), which results in improper
type and length as TLV header. This patch inserts "the end of LLDPDU"

and proper TLV header for the padding.

src/org/flowvisor/message/lldp/LLDPTrailer.java | 2 +-
src/org/flowvisor/ofswitch/TopologyConnection.java | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/org/flowvisor/message/lldp/LLDPTrailer.java b/src/org/flowvisor/message/lldp/LLDPTrailer.java
index c020ea7..3938183 100644
--- a/src/org/flowvisor/message/lldp/LLDPTrailer.java
+++ b/src/org/flowvisor/message/lldp/LLDPTrailer.java
@@ -87,7 +87,7 @@ public class LLDPTrailer {
ByteBuffer newPacket = ByteBuffer.allocate(embedded.length + len);
newPacket.put(embedded);

  int tlv = (len & 0x1ff) | ((LLDP_CHASSIS_ID & 0x007f) << 9);

```
  int tlv = ((len - TLV_LEN) & 0x1ff) | ((LLDP_CHASSIS_ID & 0x007f) << 9);
newPacket.putShort((short) tlv);

newPacket.put(LLDP_CHASSIS_ID_LOCAL);
```
diff --git a/src/org/flowvisor/ofswitch/TopologyConnection.java b/src/org/flowvisor/ofswitch/TopologyConnection.java
index 66ecc29..5e0ddff 100644
--- a/src/org/flowvisor/ofswitch/TopologyConnection.java
+++ b/src/org/flowvisor/ofswitch/TopologyConnection.java
@@ -482,13 +482,23 @@ public class TopologyConnection implements FVEventHandler, FVSendMsg {
bb.putShort(portNumber);
```
// TTL TLV
```

  byte ttl[] = { 0x06, 0x02, 0x00, 0x70 };

  byte ttl[] = { 0x06, 0x02, 0x00, 0x78 };
bb.put(ttl); // type 3, length 2, 120 seconds

// SysD TLV
bb.put(lldpSysD);
bb.putLong(this.featuresReply.getDatapathId());

```
  // End of LLDPDU
```
```
  byte endoflldp[] = { 0x00, 0x00 };
```

  bb.put(endoflldp); // type 0, length 0

```
  // padding
```
```
  if (bb.position() > (size - 4))
```
```
      return buf;
```

  int tlv = ((size - bb.position() - 2) & 0x1ff) | ((1 & 0x007f) << 9); // LLDP_CHAEEIS_ID << 9

```
  bb.putShort((short) tlv);
```

  bb.put((byte) 0x07); // subtype = LLDP_CHASSIS_ID_LOCAL
while (bb.position() <= (size - 4))
    bb.putInt(0xcafebabe); // fill with well known padding
return buf;

--
1.7.0.4

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-131

port regression tests to python unittest

Status: Open
Project: Flowvisor
Component/s: Tests
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
for increased sanity

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-20

packet_out is incorrectly blocked with partially overlapping flow space

In a packet out, the in_port is typically OFPP_NONE or OFPP_ALL, etc. The FV ignores that value when testing whether a given controller is allowed to send a packet_out's embedded packet, and assumes it's OFPP_ALL. This incorrectly matches all of the slices with the same port, so, for example:
if Alice and Bob has overlapping flowspace (e.g., both match all packets), but where partitioned by port, e.g., Alice has ports 1-4 and Bob has ports 5-8, and Bob had priority over Alice, then alice should be able to send any packet as long as it is output to ports 1-4. But, in the current code, she is prevented from doing so, because the way the match is constructed also matches Bob's rules, and Bob's is higher priority. The fix is, rather than rewrite the match logic (yuck!), to ignore match rules that don't fit Alice's slice.
So, the code is now:
[FVPacketOut.java line ~50]
{ match.loadFromPacket(this.getPacketData(), this.getInPort()); // TODO : for efficiency, do this lookup on the slice flowspace, // not the switch List flowEntries = fvClassifier.getSwitchFlowMap() .matches(fvClassifier.getSwitchInfo().getDatapathId(), match); if ((flowEntries == null) // got no response || (flowEntries.size() < 1) // nothing matched has write permissions || (!flowEntries.get(0).hasPermissions( fvSlicer.getSliceName(), SliceAction.WRITE)) }
So, the line flowEntries.get(0).hasPermissions() only looks at the highest priority entry. Instead, it should go through entries 0...n until it finds the first entry that contains a slice from alice's slice, i.e., fvSlicer.getPorts().contains(port);

Original issue information:
https://openflow.stanford.edu/bugs/browse/FLOWVISOR-130

Aggregate_flow_stats_req: FV doesn't extract the request

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: None

Description
When a controller issues aggregate_flow_stats_req with wildcard_all for matching field, FV sends the req to the switch as is, not extracting matching fields depending on what rules the slice has.

Original Jira Issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-172

"fvctl changePasswd" doesn't change password

Even though "fvctl changePasswd" shows "success!" it doesn't change password at all. This is due to a SQL syntax error in SliceImpl.java. Just changing "AND" to "," should be enough. The patch is attached.

Status: Open
Project: Flowvisor
Component/s: Config, Core
Affects Version/s: 0.8.3, 0.8.4, 0.8.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Masahiko Takahashi Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: bugreport-changepasswd.txt

Description
Even though "fvctl changePasswd" shows "success!" it doesn't change password at all. This is due to a SQL syntax error in SliceImpl.java. Just changing "AND" to "," should be enough. The patch is attached (shown below, not attached:)

diff -r e078241c2769 src/org/flowvisor/config/SliceImpl.java
--- a/src/org/flowvisor/config/SliceImpl.java Wed Aug 08 14:41:13 2012 -0700
+++ b/src/org/flowvisor/config/SliceImpl.java Fri Aug 10 10:56:39 2012 -0700
@@ -52,7 +52,7 @@
" passwd_salt, controller_hostname, controller_port, contact_email, drop_policy, lldp_spam, slice_queue) " +
"VALUES(?,?,?,?,?,?,?,?,?,?,?,?)";
private static String DELETESLICE = "DELETE FROM Slice WHERE " + SLICE + " = ?";

private static String SCRYPT = "UPDATE Slice SET " + CRYPT + " = ? AND " + SALT +
private static String SCRYPT = "UPDATE Slice SET " + CRYPT + " = ?, " + SALT +
" = ? WHERE " + SLICE + " = ?";

private static String FLOWVISOR = "SELECT id from " + Flowvisor.FLOWVISOR + " WHERE " + Flowvisor.CONFIG + " = ?";

Original issue: https://openflow.stanford.edu/bugs/si/jira.issueviews:issue-html/FLOWVISOR-181/FLOWVISOR-181.html

Flowspace entries and non-existent slices

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
If you delete a slice with fvctl, it also deletes all of the flowspace rules pointing to that slice. However, you can still add a flowspace rule with fvctl that points to a non-existent slice, which seems inconsistent.

Comments
Comment by Nick Bastin [ 27/Apr/11 ](from jbs in trac)
My two cents: I can see some advantage in allowing you to delete a slice and recreate it with the same name, and have the existing flowspace entries remain intact; and thus, also, to create flowspace entries that point to a slice that doesn't exist (yet).
Maybe an interface like
fvctl deleteSlice [ --preserve-flowspace ]
fvctl addFlowSpace [--force ]
so that by default, deleting a slice removes your flowspace entries, but you can override it if you want to preserve them; and by default, adding a flowspace entry to a slice that doesn't exist gives you an error (or a warning) but you can override that if you really want to do this? That seems like it'd do what most people want by default, but let people who want to do something slightly complicated still do so, without too much trouble.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-12

Create package installation user if it doesn't exist

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Josh Smift Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
FlowVisor currently requires a 'flowvisor' user, but doesn't create that user or check for its existence. It should create a 'flowvisr' user (or other 8-character-or-less user) if one doesn't exist, and use that.

Comments
Comment by Josh Smift [ 14/Dec/11 ]
On further reflection, it seems like you probably shouldn't change what user FlowVisor should run as; but you still can run into the problem described here if that user doesn't exist.
Please change the description of this bug to:
FlowVisor currently requires a 'flowvisor' user, but doesn't create that user or check for its existence. It should create a 'flowvisr' user (or other 8-character-or-less user) if one doesn't exist, and use that.
Comment by Josh Smift [ 21/Sep/12 ]
On further further reflection, it's been using the username 'flowvisor' for a while now, and modern Unix is generally ok with longer-than-8-character usernames. Let's just stick with that.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-149

configurable switch backoff connection

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Long Term

Description
make it so each slice can configure how often the switches connect to it

Comments
Comment by Rob Sherwood [ 04/Jul/11 ]
still a reasonable request in 0.7.x ; this amounts to having a slice-specific variable for FVSlicer.maxReconnectSeconds.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-61

Path and naming mismatches between FlowVisor package and documentation

Status: Open
Project: Flowvisor
Component/s: Packaging
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Luisa Nevers Assignee: Nick Bastin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
OS Ubuntu 10.04.2 LTS
Ubuntu package FlowVisor 0.8.1.2

Description
Followed the instructions for a FlowVisor Ubuntu package install and
configuration on a new system and have run into path and naming issues.
The page https://openflow.stanford.edu/display/flowvisor/fv_deploy points to a
file /usr/local/etc/flowvisor/flowvisor-config.xml, but file that is delivered
by the package has different name and exists in a different path
/usr/etc/flowvisor/config.xml.
Additionally, there are several mismatched paths in the fv_deploy page and the installed package:
doc=> /usr/local/sbin/ package installs=> /usr/sbin/
doc=> /usr/local/etc/flowvisor/ package installs=> /usr/etc/flowvisor/
Package-installation specific steps should use path and naming that is delivered.

Comments
Comment by Luisa Nevers [ 28/Sep/11 ]
A comment about the path mismatch and the configuration naming consistency, as delivered by the package the "/etc/init.d/flowvisor" will not work because it executes the following command:
sudo -u flowvisor /usr/sbin/flowvisor /usr/etc/flowvisor/config.xml
The user "flowvisor" does not exist, the configuration "config.xml is a sample configuration and the documentation instruct the user to generate their own with a different file name "flowvisor-config.xml" without instruction to modify the system start-up file.
Comment by Josh Smift [ 29/Aug/12 ]
The page that this ticket is about, it no longer exists. The new page has some issues, but I think this particular ticket can be closed.

original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-136

If config can't be written, error should be communicated back to RPC API

Status: Open
Project: Flowvisor
Component/s: RPC
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Improvement Priority: Major
Reporter: Nick Bastin Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: opnk11
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
If you make an RPC call that causes the config to be written, and the config write fails (EPERM, etc.), you are not informed.

Comments
Comment by Josh Smift [ 28/Aug/12 ]
I created a duplicate of this ticket in FLOWVISOR-150, which was labeled "wontfix", but not actually resolved. Is this problem resolved now?
Comment by Ali Al-Shabibi [ 28/Aug/12 ]
Yes, in the new way the config is handled it is no longer written for any change (it was too much of a performance hit). Now to write the config, you must explicitely run fvctl dumpConfig .

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-80

Add /etc/init.d/flowvisor status

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: 0.8.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Josh Smift Assignee: Ali Al-Shabibi
Resolution: Unresolved Votes: 0
Labels: willfix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
It'd be nice if '/etc/init.d/flowvisor status' told you whether it was running or not; this is especially useful for system configuration management type things, like Puppet.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-140

make flowspace update more efficient

Status: Open
Project: Flowvisor
Component/s: None
Affects Version/s: None
Fix Version/s: Long Term

Type: Improvement Priority: Major
Reporter: Rob Sherwood Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: gec12
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
High-level problem: Small flowspace updates are too costly when the total amount number of flowspace entries are large.
When you update the flowspace ($n$ rules, $s$ switches and $t$ slices) each of the FVSlicers (of which there are $s_t$) rebuilds its view of the flowspace, when nets in an O(n_s_t) operation. There is a relatively straight forward fix to this: instead of building t
he view up from scratch, just handle the diff (add, remove, etc.) which will reduce it to a O(d_s*t) operation, where $d$ is the size of the diff.
This should be fairly straight forward to code: embed the diff in the config update message for each FVSlicer to process and then apply the diff to their local copy of the flowspace rather than recreating the entire view from scratch.

Comments
Comment by Rob Sherwood [ 06/Jul/11 ]
[reposted from FLOWVISOR-98]
Rob, the only types of log events are above WARN are ALERT and CRIT in both NLR and I2, sample below:
ALERT
Jul 5 15:38:13 ofc-vm2 flowvisor: ALERT-slicer_internet2-nox-switch_ID__ofc-vm1_net_internet2_edu_29_dpid=00:00:0e:84:40:39:1b:93: STARVING: handling event took 25ms: org.flowvisor.events.FVIOEvent@4be7e13a
Jul 5 15:38:14 ofc-vm2 flowvisor: ALERT-topoDpid=00:00:0e:83:40:39:18:1b: STARVING: handling event took 110ms: org.flowvisor.events.FVIOEvent@2ac15229
Jul 5 15:38:26 ofc-vm2 flowvisor: ALERT-classifier-dpid=00:00:0e:83:40:39:18:1b: STARVING: handling event took 125ms: org.flowvisor.events.ConfigUpdateEvent@249c0dd6
Jul 5 15:38:26 ofc-vm2 flowvisor: ALERT-slicer_tupty10_ID__ofc-vm1_net_internet2_edu_21_dpid=00:00:0e:83:40:39:18:1b: STARVING: handling event took 55ms: org.flowvisor.events.FVIOEvent@5a625014
Jul 5 15:38:26 ofc-vm2 flowvisor: ALERT-slicer_tupty10_ID__ofc-vm1_net_internet2_edu_21_dpid=00:00:0e:83:40:39:1b:93: STARVING: handling event took 27ms: org.flowvisor.events.FVIOEvent@6c777f67
Jul 5 15:38:26 ofc-vm2 flowvisor: ALERT-slicer_tupty10_ID__ofc-vm1_net_internet2_edu_21_dpid=00:00:0e:83:40:39:18:58: STARVING: handling event took 26ms: org.flowvisor.events.FVIOEvent@194d7ad3
Jul 5 15:40:38 ofc-vm2 flowvisor: ALERT-slicer_fvadmin_dpid=00:00:0e:84:40:39:18:1b: STARVING: handling event took 17ms: org.flowvisor.events.FVIOEvent@4086d951
Jul 5 15:41:46 ofc-vm2 flowvisor: ALERT-classifier-dpid=00:00:0e:83:40:39:18:58: STARVING: handling event took 12ms: org.flowvisor.events.FVIOEvent@68b4f5b6
CRIT
Jul 5 15:37:18 ofc-vm2 flowvisor: CRIT-slicer_tupty10_ID__ofc-vm1_nlr_net_14_dpid=0e:83:00:23:47:ca:bc:40: FIXME: need to flush old flow entries
Jul 5 15:37:18 ofc-vm2 flowvisor: CRIT-slicer_jbs15-naxos-33015_ID__ofc-vm1_nlr_net_16_dpid=0e:83:00:23:47:ca:bc:40: FIXME: need to flush old flow entries
Jul 5 15:37:18 ofc-vm2 flowvisor: CRIT-slicer_nlr-nox-switch_ID__ofc-vm1_nlr_net_10_dpid=0e:83:00:23:47:ca:bc:40: FIXME: need to flush old flow entries

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-100

need to virtualize flow_mod priorities

Status: Open
Project: Flowvisor
Component/s: Core
Affects Version/s: 0.7.2
Fix Version/s: Next

Type: Improvement Priority: Critical
Reporter: Nick Bastin Assignee: Rob Sherwood
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Description
to properly fix overlapping flowspace
possible algorithm:
calculate k regions, and remap flow_mods into k regions
pick k as the number of contiguous chunks of non-overlapping flowspace
new_priority = remap(old_priority,i,k,n) :

region_size = n/k
new = i*region_size + old/n
return new

Comments
Comment by Rob Sherwood [ 27/Jun/11 ]
Problem:
Currently, the priorities in the flowspace do not translate down to priorities in the switches flow table. As a result, for example, a slice with a lower priority "match=all" rule can block/starve slices with higher priority flow entries.
For example, if the flowspace was (higher number == higher priority):
priority 5000: of_match=nw_src=192.168.0.0/16 --> alice
priority 1000: of_match=all --> bob
Currently, Bob could insert a rule to drop all packets, because it matched his flowspace, but it would affect alice, because should would stop getting packet_in's for packets matching 192.168.0.0/16.
Solution:
part 1: for each intersecting flowspace, insert an extra flow_mod that sends to controller IF alice does not already have a pre-existing rule.
Example: in the above case, bob sending a drop all rule should be translated into a lower priority drop all rule for bob, and a higher priority flow_mod with match=nw_src=192.168.0.0/16 with action output:OFPP_CONTROLLER
part 2: the priorites in flow_mods need to be rewritten, so that Bob can't write a higher priority rule than alice.
Example, using a function to rewrite flow_mod.priority fields, like the above formula.
BOTH OF THESE SOLUTIONS ASSUME THAT PRIORITIES ARE CORRECTLY IMPLEMENTED IN SWITCHES WHICH IS NOT THE CASE ON THE HPs!!

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-72

opennetworkinglab / flowvisor Goto Github PK

flowvisor's People

Contributors

Stargazers

Watchers

Forkers

flowvisor's Issues

In addition, snac is having trouble displaying bandwidth stats (again), and I'm seeing a bunch of

flowvisor: WARN: msg failed sanity check: ofmsg:v=1;t=STATS_REQUEST;l=56;x=0;st=FLOW

Note that 'git log' in the flowvisor source directory starts off with:

Release flowvisor-0.6.beta4

and proper TLV header for the padding.

Recommend Projects

Recommend Topics

Recommend Org