| 40 | |
| 41 | === when openflow.conf gets messed up (6/22) === |
| 42 | One method to rewrite the !OpenFlow configuration is to delete openflow.conf directly through the switch, then use the `setvsi` command to set the new virtual switches up. This should be unnecessary, but it happened to be effective when old configurations did not seem to go away despite editing the .conf file using a PC. |
| 43 | |
| 44 | {{{ |
| 45 | > cd /mnt/ |
| 46 | > rm openflow.conf |
| 47 | remove 'openflow.conf'? y |
| 48 | > setvsi 1 1,3,5,7,9,11,13,15,2.1 tcp 172.16.4.224 dpid 0x0123456789ab |
| 49 | > setvsi 2 17,19,21,23,25,27,29,31,2.2 tcp 172.16.4.180 dpid 0x012345678abc |
| 50 | > setvsi 3 33,35,37,39,41,43,45,47,2.3 tcp 172.16.4.64 dpid 0x01234567abcd |
| 51 | > showswitch |
| 52 | vlan ports secure channel |
| 53 | ---- ----- -------------- |
| 54 | 1 1, 3, 5, 7, 9, 11, 13, 15, 2.1 disconnected |
| 55 | 2 17, 19, 21, 23, 25, 27, 29, 31, 2.2 disconnected |
| 56 | 3 33, 35, 37, 39, 41, 43, 45, 47, 2.3 disconnected |
| 57 | }}} |
| 58 | |
| 59 | |
| 60 | However, it seems like it is not possible to set `double-wide-mode`, or `no-save` through the CLI. These have to be added by editing openflow.conf using the PC. |
| 61 | |
225 | | ==== some experimentation with Ruby sockets ==== |
226 | | |
227 | | The switch will keep trying to contact a controller, regardless of whether the controller is active. This happens once every 15 seconds or so, and can be seen with a very simple script that listens on TCP 6633 (the default !OpenFlow port) on the console's !OpenFlow VLAN interface, which has the IP address 172.16.100.1: |
228 | | |
229 | | {{{ |
230 | | #!/usr/bin/ruby -w |
231 | | require 'socket' |
232 | | |
233 | | # allow the switch to try to establish a connection |
234 | | ofpsock = TCPserver.new("172.16.100.1", 6633) |
235 | | |
236 | | #listen to see what port the switch is using |
237 | | while (session = ofpsock.accept) |
238 | | t = Time.now # to see interval of messages |
239 | | peer = session.peeraddr |
240 | | puts "#{peer[1]} #{peer[2]} #{t.to_s.split[3]}" |
241 | | session.close |
242 | | end |
243 | | |
244 | | |
245 | | }}} |
246 | | |
247 | | You get: |
248 | | {{{ |
249 | | 55354 172.16.100.10 20:53:22 |
250 | | 55353 172.16.100.10 20:53:37 |
251 | | 55352 172.16.100.10 20:53:52 |
252 | | 55351 172.16.100.10 20:54:07 |
253 | | ... |
254 | | |
255 | | from a later experiment |
256 | | |
257 | | 55080 172.16.100.10 22:12:53 |
258 | | 55079 172.16.100.10 22:13:08 |
259 | | |
260 | | actually consistent with bwm-ng logs |
261 | | |
262 | | }}} |
263 | | |
264 | | The first column shows the switch's port. 172.16.100.10 is the vlan interface IP address for the Openflow VLAN on the switch, so you know it is the !OpenFlow switch trying to establish a connection with the controller. To be honest it's not clear if the timestamps would reflect the speed of the code or the activity of the switch. |
265 | | |
266 | | |
267 | | |
268 | | |
269 | | |
270 | | |
271 | | |
272 | | |
273 | | |
274 | | |
275 | | |
276 | | |
277 | | |