Skip to content
Snippets Groups Projects
Select Git revision
  • gh-pages
  • hot-failover
  • master default protected
  • master-green
  • master-prejava8
  • perf-test
  • release.asplus
  • release.asplus.bvs
  • revert-555-master
  • revert-559-revert-555-master
  • revert-594-master
  • v0.8
  • v0.82
  • v0.85
  • v0.90
  • v0.91
  • v1.0
  • v1.1
  • v1.2
  • wallaby
  • v1.2
  • v0.91
  • v1.1
  • v1.0
  • v0.90
  • v0.85
  • v0.82
  • v0.8
  • asplus-rc5
  • asplus-rc2
30 results
You can move around the graph by using the arrow keys.
Created with Raphaël 2.2.04Dec3124Nov13126429Oct12876528Sep21114331Aug2120181513121128Jul222116830Jun292726242322191812109865432129May262313121110130Apr272019181716138327Mar262019171615141312109327Feb20165420Jan1230Dec2925232221191817161512121Nov2018141310753131Oct3027261024Sep1615141129Aug27211917161514131211108765431Jul302818Jun21Apr20625Mar754228Feb1Mar30Dec205Nov30Oct17Sep756Aug222Jul1728Jun26252423222120191817141312111076543231May3029282726252423222120191817OF-DPA init and learning switch functions created. Possible use is commented out in ForwardingBase.java for the time being.Merge pull request #608 from xuraylei/masterfix concurrency flaw in DHCPServer Modulefix concurrency flaws in LoadBalancer ModuleFirst round of OF-DPA additions for learning switch functionality.Merge pull request #603 from rizard/masterFixed SFP issue where the flow checker would allow a flow w/o a switch specified.Merge pull request #602 from mindi102680/masterMerge pull request #1 from mindi102680/mindi102680-patch-1Merge pull request #601 from chechoRP/patch-1Update MatchUtils.javaFix for Firewall issue #590 Merge pull request #599 from rizard/masterFinally, finally got to the bottom of the 'simple topology' Forwarding bug.Merge pull request #598 from rizard/masterTidy up topology and get rid of some many redundant functions in ITopologyService. Also, fix a bug that prevents outgoing broadcast ports from being queried on single-switch islands.Merge pull request #597 from rizard/masterPatch Forwarding's pushPacket and pushRoute. We do not want to push a packet if the command is delete or delete-strict.Merge pull request #595 from rizard/masterWow. Not sure how that passed. Should have run ant (outside eclipse) -- would have given the compile error.Revert "Finish new topology service integration by patching Forwarding + one new feature"revert-594-masterrevert-594-masterMerge pull request #594 from rizard/masterAdded ability to disable ARP flows in Forwarding. Many hardware switches cannot handle ARP flows. ARP flows on by default; turn off/on via 'flood-arp' in floodlightdefault.properties. Also, finished integrating new topology service/routing into Forwarding. This required a few more null checks to handle cases where packet-ins are received while the controller is starting/still discovering the topology/links.Merge pull request #593 from rizard/masterFixed (really this time) the last bug WRT link latencies. This actually wasn't even a latency bug, but it existed beforehand. We only dispatch an update when checking for link timeouts if the link's unicast time just expired and we still have a valid multicast time. Otherwise, we remove the link if both unicast and multicast times are expired. Originally, we were dispatching updates when multicast times were expiring and unicast times were still valid. Such a case results in the link being in the unicast state before and after the multicast expiration; thus, no link update should be dispatched.Topology manager now purges any existing link in its data structures before it tries to add a new link (no-op if one exists). This needs to be done in order to update latencies. Also changed some log levels.Hooray! Fixed (fingers crossed) the last couple bugs WRT LLDP vs BDDP timing. Link discovery reaches a steady state now and latency updates do not impact the type of link (unicast/multicast) being reported to the topology manager.Removing a bunch of unused annotations along with the source.Fix potential divide by zero. Increased latency parameters to threshold=0.50, history=10. Maybe it's just because my control plane is over a VPN and over the public internet, but the link latencies are fluctuating a bit. TODO evaluate whether or not we should completely clear the average/history each time we accept a new latency value. This would lessen the number of latency updates.Change logging. Update default history size to 10. Base update decision on previous link value, not current observed.Add latency to trace log in updatesImplemented a rolling link latency history for switch links. Each link will contain a single latency value. When a link update occurs, the latency computed from the LLDP packet is added to the exisiting link's LinkInfo. LinkInfo maintains a latency history for link L. The 1-to-1 mapping between Link and LinkInfo still exists. LinkInfo will provide a new latency based on the rolling window size and update threshold -- configurable through floodlightdefault.properties but default to 5 latency data points and 30%, respectively. As an example, the 0th latency value is used as the intial latency for a particular (new) link. Each LLDP update for this link will contain a latency. This latency is added to the LinkInfo from updates 0 - 3. Update 4 will make 5 historical latency data points. This will cause an average to be computed of these 5 data points. If the average is +/-30% of the latency recorded in the 0th latency, the link latency will be updated. For exach, successive latency recorded, the same average will be computed. If the new average is not +/-30% of the old recorded value, an update will not occcur. Every latency 'replacement/update' will cause a new topology to be computed in the topology manager. Keeping a rolling average takes into account current network conditions, but also helps to average out outliers and keeps topology updates to a minimum.Set link discovery logging to info.Integrated new topology code and updated unit tests to a passing state. I'd be more comfortable adding more unit tests to the topology. Also made some changes to the link discovery manager's latency subsystem. We start with a baseline latency based on the switch's features reply turnaround time. This should be relatively quick -- just like an echo. Next step for latency is to keep a rolling list of past latencies for more defined topology updates based on latency updates. We don't want to update latencies too frequently, since tiny changes (or outliers) shouldn't require a complete topology recomputation.src/mainMerge pull request #592 from rizard/masterMerge branch 'master' of http://github.com/floodlight/floodlightPatch load balancer to include source port in static flow pusher entry names. This will allow a single source host to have multiple connections load-balanced across multiple LB hosts.Merge pull request #589 from rizard/masterMerge branch 'master' of http://github.com/floodlight/floodlight