Heming, Can I suggest you run through the OpenFlow tutorial? Getting familiar with the OpenFlow wireshark plugin, controller setup, etc should clear a lot of your doubts. There are a lot of materials out there (though they might not be very organized). The tutorial is usually a great start, thanks to Brandon and others' hard work.
Regards KK On 11 May 2012 11:10, Heming Wen <heming....@mail.mcgill.ca> wrote: > Hi KK, > > I am using a controller running on a VM in Virtualbox under bridged mode with > its own IP address (192.168.1.203). In order to capture the packet in a > cleaner fashion, I used two different setup, both with 6633 as OF port. In > each of the setup, there is only the controller and the other device present > in the subnet. Here are the four test cases I ran: > > 1) PC controller with pyswitch (192.168.1.203) <-----> Pronto switch > (192.168.1.1) > > This is working as intended. A connectivity test between the controller and > switch is run every 15 seconds. Here is a slice of tcpdump of eth0 on the > controller I included for you to compare with the AP one which doesn't work: > > 1a) When pyswitch is not activated, the switch cannot establish the > connection as expected. It retries every 15 seconds. > > 11:25:54.413729 IP 192.168.1.1.47678 > 192.168.1.203.6633: Flags [S], seq > 632326855, win 5840, options [sackOK,TS val 148549274 ecr 0,mss > 1460,nop,wscale 5], length 0 > 11:25:54.413754 IP 192.168.1.203.6633 > 192.168.1.1.47678: Flags [R.], seq 0, > ack 632326856, win 0, length 0 > 11:26:09.414071 IP 192.168.1.1.47679 > 192.168.1.203.6633: Flags [S], seq > 872002931, win 5840, options [sackOK,TS val 148553024 ecr 0,mss > 1460,nop,wscale 5], length 0 > 11:26:09.414108 IP 192.168.1.203.6633 > 192.168.1.1.47679: Flags [R.], seq 0, > ack 872002932, win 0, length 0 > 11:26:14.411074 ARP, Request who-has 192.168.1.1 tell 192.168.1.203, length 28 > 11:26:14.411374 ARP, Reply 192.168.1.1 is-at e8:9a:8f:fb:c3:7f, length 46 > 11:26:24.414151 IP 192.168.1.1.47680 > 192.168.1.203.6633: Flags [S], seq > 1113043895, win 5840, options [sackOK,TS val 148556774 ecr 0,mss > 1460,nop,wscale 5], length 0 > 11:26:24.414176 IP 192.168.1.203.6633 > 192.168.1.1.47680: Flags [R.], seq 0, > ack 1113043896, win 0, length 0 > 11:26:29.413669 ARP, Request who-has 192.168.1.203 tell 192.168.1.1, length 46 > 11:26:29.413691 ARP, Reply 192.168.1.203 is-at 08:00:27:60:e6:e7, length 28 > > 1b) When pyswitch is activated, connection is established as intended. No > random disconnect occurs. A message is sent between the controller and switch > every 15 second. > > 11:28:09.413993 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack 1, > win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 > 11:28:09.414043 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 1:9, ack 1, win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 8 > 11:28:09.414056 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [.], ack 9, > win 91, options [nop,nop,TS val 40338360 ecr 148583024], length 0 > 11:28:09.414472 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 1:9, ack 9, win 91, options [nop,nop,TS val 40338360 ecr 148583024], length 8 > 11:28:09.414607 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 9:17, ack 9, win 91, options [nop,nop,TS val 40338360 ecr 148583024], length 8 > 11:28:09.414690 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack 9, > win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 > 11:28:09.414819 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack 17, > win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 > 11:28:09.414927 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 17:29, ack 9, win 91, options [nop,nop,TS val 40338361 ecr 148583024], length > 12 > 11:28:09.415514 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack 29, > win 183, options [nop,nop,TS val 148583024 ecr 40338361], length 0 > 11:28:09.416910 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], seq > 9:1457, ack 29, win 183, options [nop,nop,TS val 148583024 ecr 40338361], > length 1448 > 11:28:09.416949 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 1457:2633, ack 29, win 183, options [nop,nop,TS val 148583024 ecr 40338361], > length 1176 > 11:28:09.416962 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [.], ack > 2633, win 181, options [nop,nop,TS val 40338361 ecr 148583024], length 0 > 11:28:09.417200 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 29:53, ack 2633, win 181, options [nop,nop,TS val 40338361 ecr 148583024], > length 24 > 11:28:09.418380 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 2633:2669, ack 53, win 183, options [nop,nop,TS val 148583025 ecr 40338361], > length 36 > 11:28:09.418596 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 53:125, ack 2669, win 181, options [nop,nop,TS val 40338361 ecr 148583025], > length 72 > 11:28:09.457692 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack > 125, win 183, options [nop,nop,TS val 148583035 ecr 40338361], length 0 > 11:28:24.413293 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 2669:2677, ack 125, win 183, options [nop,nop,TS val 148586774 ecr 40338361], > length 8 > 11:28:24.413536 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 125:133, ack 2677, win 181, options [nop,nop,TS val 40342110 ecr 148586774], > length 8 > 11:28:24.413725 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack > 133, win 183, options [nop,nop,TS val 148586774 ecr 40342110], length 0 > 11:28:39.413913 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 2677:2685, ack 133, win 183, options [nop,nop,TS val 148590524 ecr 40342110], > length 8 > 11:28:39.414183 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 133:141, ack 2685, win 181, options [nop,nop,TS val 40345860 ecr 148590524], > length 8 > 11:28:39.414403 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack > 141, win 183, options [nop,nop,TS val 148590524 ecr 40345860], length 0 > 11:28:54.413935 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq > 2685:2693, ack 141, win 183, options [nop,nop,TS val 148594274 ecr 40345860], > length 8 > 11:28:54.414204 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq > 141:149, ack 2693, win 181, options [nop,nop,TS val 40349610 ecr 148594274], > length 8 > 11:28:54.414484 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack > 149, win 183, options [nop,nop,TS val 148594274 ecr 40349610], length 0 > > 2) PC controller with pyswitch (192.168.1.203) <-----> Pc Engine AP > (192.168.1.189) > > Now for the case where it doesn't really work as intended. The AP connect and > disconnect from the controller due to " no response to inactivity probe after > 5 seconds, disconnecting". > > 2a) pyswitch not activated. The AP retries every 8 second or so. Just like > with the switch, the behaviour seems as expected. > > 11:03:35.149878 IP 192.168.1.189.60392 > 192.168.1.203.6633: Flags [S], seq > 3709438136, win 5840, options [mss 1460,sackOK,TS val 579519 ecr 0,nop,wscale > 4], length 0 > 11:03:35.149907 IP 192.168.1.203.6633 > 192.168.1.189.60392: Flags [R.], seq > 0, ack 3709438137, win 0, length 0 > 11:03:43.147437 IP 192.168.1.189.60393 > 192.168.1.203.6633: Flags [S], seq > 3834847840, win 5840, options [mss 1460,sackOK,TS val 581519 ecr 0,nop,wscale > 4], length 0 > 11:03:43.147466 IP 192.168.1.203.6633 > 192.168.1.189.60393: Flags [R.], seq > 0, ack 3834847841, win 0, length 0 > 11:03:48.146873 ARP, Request who-has 192.168.1.189 tell 192.168.1.203, length > 28 > 11:03:48.147436 ARP, Reply 192.168.1.189 is-at 00:23:20:d6:06:1f, length 46 > 11:03:51.140086 IP 192.168.1.189.60394 > 192.168.1.203.6633: Flags [S], seq > 3969455372, win 5840, options [mss 1460,sackOK,TS val 583518 ecr 0,nop,wscale > 4], length 0 > 11:03:51.140110 IP 192.168.1.203.6633 > 192.168.1.189.60394: Flags [R.], seq > 0, ack 3969455373, win 0, length 0 > 11:03:59.137615 IP 192.168.1.189.60395 > 192.168.1.203.6633: Flags [S], seq > 4090766827, win 5840, options [mss 1460,sackOK,TS val 585518 ecr 0,nop,wscale > 4], length 0 > 11:03:59.137640 IP 192.168.1.203.6633 > 192.168.1.189.60395: Flags [R.], seq > 0, ack 4090766828, win 0, length 0 > 11:04:07.130442 IP 192.168.1.189.60396 > 192.168.1.203.6633: Flags [S], seq > 4211263035, win 5840, options [mss 1460,sackOK,TS val 587517 ecr 0,nop,wscale > 4], length 0 > 11:04:07.130469 IP 192.168.1.203.6633 > 192.168.1.189.60396: Flags [R.], seq > 0, ack 4211263036, win 0, length 0 > 11:04:12.127764 ARP, Request who-has 192.168.1.203 tell 192.168.1.189, length > 46 > 11:04:12.127788 ARP, Reply 192.168.1.203 is-at 08:00:27:60:e6:e7, length 28 > > 2b) pyswitch activated. The AP connects to the controller, but then > disconnect shortly because it fails to receive keep-alive messages. Here is > two cycles of connect/disconnect: > > 11:36:18.979394 IP 192.168.1.189.56840 > 192.168.1.203.6633: Flags [S], seq > 156517514, win 5840, options [mss 1460,sackOK,TS val 1070398 ecr 0,nop,wscale > 4], length 0 > 11:36:18.979424 IP 192.168.1.203.6633 > 192.168.1.189.56840: Flags [R.], seq > 0, ack 156517515, win 0, length 0 > 11:36:26.976537 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [S], seq > 288016471, win 5840, options [mss 1460,sackOK,TS val 1072397 ecr 0,nop,wscale > 4], length 0 > 11:36:26.976577 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [S.], seq > 631201559, ack 288016472, win 5792, options [mss 1460,sackOK,TS val 40462751 > ecr 1072397,nop,wscale 6], length 0 > 11:36:26.977088 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack > 1, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 > 11:36:26.977144 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], seq > 1:9, ack 1, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 8 > 11:36:26.977160 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [.], ack > 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], length 0 > 11:36:26.977600 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 1:9, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], length 8 > 11:36:26.977692 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 9:17, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], length 8 > 11:36:26.977786 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 17:29, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], length 12 > 11:36:26.977863 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack > 9, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 > 11:36:26.977985 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack > 17, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 > 11:36:26.978079 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack > 29, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 > 11:36:26.978884 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], seq > 9:185, ack 29, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length > 176 > 11:36:26.979084 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 29:53, ack 185, win 108, options [nop,nop,TS val 40462752 ecr 1072397], > length 24 > 11:36:26.979634 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], seq > 185:221, ack 53, win 365, options [nop,nop,TS val 1072397 ecr 40462752], > length 36 > 11:36:26.979888 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40462752 ecr 1072397], > length 72 > 11:36:27.182869 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40462803 ecr 1072397], > length 72 > 11:36:27.590900 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40462905 ecr 1072397], > length 72 > 11:36:28.406907 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40463109 ecr 1072397], > length 72 > 11:36:30.038873 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40463517 ecr 1072397], > length 72 > 11:36:33.303980 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40464333 ecr 1072397], > length 72 > 11:36:39.830905 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40465965 ecr 1072397], > length 72 > 11:36:46.975768 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [S], seq > 604390870, win 5840, options [mss 1460,sackOK,TS val 1077396 ecr 0,nop,wscale > 4], length 0 > 11:36:46.975789 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [S.], seq > 2165900425, ack 604390871, win 5792, options [mss 1460,sackOK,TS val 40467751 > ecr 1077396,nop,wscale 6], length 0 > 11:36:46.976299 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack > 1, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 > 11:36:46.976456 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], seq > 1:9, ack 1, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 8 > 11:36:46.976466 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [.], ack > 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], length 0 > 11:36:46.976558 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 1:9, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], length 8 > 11:36:46.976618 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 9:17, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], length 8 > 11:36:46.976668 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 17:29, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], length 12 > 11:36:46.976852 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack > 9, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 > 11:36:46.976904 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack > 17, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 > 11:36:46.976956 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack > 29, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 > 11:36:46.977759 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], seq > 9:185, ack 29, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length > 176 > 11:36:46.977831 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 29:53, ack 185, win 108, options [nop,nop,TS val 40467751 ecr 1077396], > length 24 > 11:36:46.978361 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], seq > 185:221, ack 53, win 365, options [nop,nop,TS val 1077396 ecr 40467751], > length 36 > 11:36:46.978462 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [FP.], seq > 125:133, ack 221, win 108, options [nop,nop,TS val 40467751 ecr 1072397], > length 8 > 11:36:46.978515 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 53:125, ack 221, win 108, options [nop,nop,TS val 40467751 ecr 1077396], > length 72 > 11:36:46.979196 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], seq > 221:313, ack 125, win 365, options [nop,nop,TS val 1077397 ecr 40467751], > length 92 > 11:36:46.979300 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], seq > 313:385, ack 125, win 365, options [nop,nop,TS val 1077397 ecr 40467751], > length 72 > 11:36:46.979306 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [R], seq > 288016692, win 0, length 0 > 11:36:46.980084 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40467752 ecr 1077397], > length 24 > 11:36:46.980990 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 149:229, ack 385, win 108, options [nop,nop,TS val 40467752 ecr 1077397], > length 80 > 11:36:47.182857 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40467803 ecr 1077397], > length 24 > 11:36:47.590882 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40467905 ecr 1077397], > length 24 > 11:36:48.407692 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40468109 ecr 1077397], > length 24 > 11:36:50.038876 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40468517 ecr 1077397], > length 24 > 11:36:53.302861 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40469333 ecr 1077397], > length 24 > 11:36:59.831044 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], seq > 125:149, ack 385, win 108, options [nop,nop,TS val 40470965 ecr 1077397], > length 24 > > I noticed that the controller 192.168.1.203, shortly after establishing > connection, tries to send a packet to the AP continuously because it doesn't > receive any response from the AP. This happened at 11:36:26.979888 and > 11:36:46.980084. And then, the AP disconnects from the controller with > message " no response to inactivity probe after 5 seconds, disconnecting". I > wasn't able to obtain a good slice of the tcpdump on the AP side because the > traffic level was extremely high. I'll try to filter out some of it and see > if if the AP ever received the message from the controller. > > Do you have any suggestions for this issue? Should I use a different > controller (not pyswitch)? > > (I apologize for the long log files) > > Thank you, > Regards, > > Heming > ________________________________________ > From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap > [yap...@stanford.edu] > Sent: May 10, 2012 17:52 > To: Heming Wen > Cc: Dan Talayco; openflow-discuss@lists.stanford.edu > Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP > > Can you grab a tcpdump of the controller traffic and take a look > there? Why is the controller going silent? It should have some > keep-alive going. Which switch would this be on the AP? > > Regards > KK > > On 10 May 2012 13:56, Heming Wen <heming....@mail.mcgill.ca> wrote: >> Hi KK, >> >> Here is a "slice" of the log from the AP point of view (accessed through >> serial interface): >> >> Dec 31 16:00:51|00018|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connected >> Dec 31 16:00:51|00019|fail_open|WARN|No longer in fail-open mode >> [ 40.682489] ath5k phy0: unsupported jumbo >> Dec 31 16:01:01|00020|rconn|ERR|dp0<->tcp:192.168.1.203:6633: no response to >> inactivity probe after 5 seconds, disconnecting >> [ 44.599003] ath5k phy0: unsupported jumbo >> [ 44.663382] ath5k phy0: unsupported jumbo >> Dec 31 16:01:02|00021|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connecting... >> Dec 31 16:01:03|00022|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connection >> timed out >> Dec 31 16:01:03|00023|rconn|INFO|dp0<->tcp:192.168.1.203:6633: waiting 2 >> seconds before reconnect >> [ 46.695553] ath5k phy0: unsupported jumbo >> Dec 31 16:01:05|00024|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connecting... >> Dec 31 16:01:07|00025|fail_open|WARN|Could not connect to controller (or >> switch failed controller's post-connection admission control policy) for 15 >> seconds, failing open >> Dec 31 16:01:07|00026|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connection >> timed out >> Dec 31 16:01:07|00027|rconn|INFO|dp0<->tcp:192.168.1.203:6633: waiting 4 >> seconds before reconnect >> [ 50.176894] ath5k phy0: unsupported jumbo >> [ 53.487164] ath5k phy0: unsupported jumbo >> Dec 31 16:01:11|00028|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connecting... >> Dec 31 16:01:11|00029|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connected >> >> The problem is: " no response to inactivity probe after 5 seconds, >> disconnecting". This connect/disconnect cycle continues endlessly. >> >> On the controller side, here is a slice of the message: >> >> 00025|nox.coreapps.examples.pyswitch|INFO: Switch 1 has joined the network >> 00026|nox.coreapps.examples.pyswitch|INFO: Switch 1 has left the network >> 00027|nox.coreapps.examples.pyswitch|INFO: Switch 1 has joined the network >> 00028|nox.coreapps.examples.pyswitch|INFO: Switch 1 has left the network >> >> So it seems it's AP who's disconnecting on its own, not the controller. Do >> you know if this is a normal behavior? Did I miss something in the setup of >> the wireless AP? >> >> @Dan: >> >> Currently, the error I see above occur even if I have a direct ethernet >> connection between the AP and the controller PC. >> >> However, in the future setup, I plan to use a desktop switch to allow the >> same controller to control both the management port of the switch and the AP >> attached to the switching plane of the switch. In that setup, there will be >> a situation where the controller connection with the AP needs to be >> configured through OpenFlow. So I was wondering if the following still >> holds: >> >>> The main thing you want (need) to avoid is having the traffic for an >>> OpenFlow controller connection travel over a data plane that is itself >>> controlled by the same connection >> >> Because technically in my setup, the traffic of the OpenFlow controller >> connection with AP are travelling over the data plane controlled by a >> connection between the switch and the OpenFlow controller. So technically, >> it's two connections, one between switch and controller, the other between >> AP and controller. The controller connection with the switch does not go >> through the switching plane of itself (instead it goes through the switching >> plane of a third non-openflow switch). Would the concern you have still be >> valid in this case? Also, would the introduction of a third non-openflow >> switch be problematic? >> >> Here is a schematic of my planned setup: >> >> [controller PC] <----------> [D-link desktop switch (No Openflow)] >> [Pronto switch management port] <----------> [D-link desktop switch (No >> Openflow)] >> [Pronto switching plane port] <------------> [D-link desktop switch (No >> Openflow)] >> [Pc Engine AP] <---------------> [Pronto switching plane port] >> >> So the ports controlled by Openflow are the Pronto switch port. Since the >> only way the AP can be accessed by the controller is through the Pronto >> switch, the OF control messages with AP would be themselves flow entries in >> the OF-controlled switch. Would that be an issue? >> >> Thank you for your kind response, >> Regards, >> >> Heming >> ________________________________________ >> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >> [yap...@stanford.edu] >> Sent: May 10, 2012 15:51 >> To: Dan Talayco >> Cc: Heming Wen; openflow-discuss@lists.stanford.edu >> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >> >> Hi, >> >> If you are having the connection to AP come and go, you are probably >> having a connection. Question is why is the AP disconnecting. Look >> at the log of the controller. That should say something. >> >> Regards >> KK >> >> On 10 May 2012 12:30, Dan Talayco <dtala...@stanford.edu> wrote: >>> Sorry for the non-specific response. >>> >>> The main thing you want (need) to avoid is having the traffic for an >>> OpenFlow controller connection travel over a data plane that is itself >>> controlled by the same connection. In theory this can be made to work, but >>> probably not without firmware changes to one or more of the devices >>> involved. >>> >>> -Dan >>> >>> On Thursday, May 10, 2012 at 12:09 PM, Heming Wen wrote: >>> >>> Hi KK, >>> >>> Thanks for the heads up. I am currently trying approach #1 (using extra >>> switch to connect everything under 1 subnet). Before doing that though, I >>> was trying to test the connection between nox and the PC engine AP. When I >>> was using pyswitch to test the connection, it seems that the AP's connection >>> to the controller is constantly on and off (join and left the network >>> constantly). I am not sure if this is the normal behavior because pyswitch >>> probably was not designed for controlling the APs. Right now, the AP keeps >>> disconnecting from the controller. However, it did recognize the DPID I set >>> for the AP (which was "1"). >>> >>> I am not sure if this is because I am using pyswitch instead of the intended >>> OpenRoads controller. I will be using a different controller eventually but >>> I wanted to know if there was something wrong with the AP-controller >>> connection to start off with. >>> >>> Thank you again, >>> >>> Heming >>> ________________________________________ >>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>> [yap...@stanford.edu] >>> Sent: May 10, 2012 13:55 >>> To: Heming Wen >>> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >>> >>> Hi Heming, >>> >>> Some comments inline. >>> >>> Regards >>> KK >>> >>> On 10 May 2012 09:18, Heming Wen <heming....@mail.mcgill.ca> wrote: >>> >>> Hi KK, >>> >>> In terms of physical hardware, I believe we have the exact same set of >>> hardware mentioned in the Stanford OpenRoads testbed. We are using PC Engine >>> AP and Pronto 3290 switches with Indigo installed. Right now, a controller >>> VM is running on a PC workstation connected to the management port of the >>> Pronto switch. Using simple pyswitch.py controller to detect devices, a >>> successful connection has been established between the switch and the >>> controller. >>> >>> When you say "make sure the controller is also accessible to the AP on the >>> datapath", I am not extremely sure about the approach I should take. Do you >>> mean using a second switch (a smaller one, D-Link desktop switch for >>> instance) to connect the control port of the switch, the port of the Pc >>> workstation controller and the switching plane of the switch (on which the >>> AP is attached) together? >>> >>> >>> This should work in theory. I assume Indigo allows this. Dan should >>> be able to comment on this. It is setting up an out-of-band control >>> network. >>> >>> Or do you mean by having an extra network card installed on the controller >>> PC in order to be connected to both the control port of the switch and the >>> switching plane (using two subnets). >>> >>> >>> Yes, this is what Dan was describing and we have done this before. >>> With a NEC though. >>> >>> Or are you referring to something else entirely? Is it possible for us to >>> use the same approach you used in your setup so we can recreate it? >>> >>> >>> We had this setup in various forms over time, using different switches >>> and APs. There isn't a "particularly right" way to do this. It all >>> depends on the equipment you have at hand and what you are trying to >>> do. >>> >>> >>> Sorry for asking so many questions at once as I am still relatively new with >>> networking in general. >>> >>> Thank you for your swift response and support. >>> >>> Heming >>> ________________________________________ >>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>> [yap...@stanford.edu] >>> Sent: May 9, 2012 22:19 >>> To: Heming Wen >>> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >>> >>> Hi Heming, >>> >>> One way is to have only the AP in inband mode. Get your switch to the >>> controller, then make sure the controller is also accessible to the AP >>> on the datapath. We have had such a setup before. It should work. >>> >>> Regards >>> KK >>> >>> On 9 May 2012 18:42, Heming Wen <heming....@mail.mcgill.ca> wrote: >>> >>> Hi Dan, >>> >>> Actually, I was wondering about how the OpenRoads deployment was setup. I >>> thought the APs were attached to the OpenFlow switches? Or are they not >>> Pronto switches? In other words, how is the OpenRoads controller setup in >>> order to control both the switches and the AP at the same time? >>> >>> Thank you, >>> >>> Heming >>> ________________________________________ >>> From: Dan Talayco [dan.tala...@bigswitch.com] on behalf of Dan Talayco >>> [dtala...@stanford.edu] >>> Sent: May 9, 2012 18:00 >>> To: Heming Wen >>> Cc: openflow-discuss@lists.stanford.edu >>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >>> >>> I believe you're basically asking the switch to route (or at least switch) >>> between the management port and the dataplane. The short answer is that the >>> switch won't do this and it's not planned to be supported. >>> >>> You probably want "physical in-band management" where the Pronto switch is >>> managed by a connection accessed through a data plane port. This feature is >>> not yet fully supported on the Pronto platforms, although some people are >>> working with it now. Note that although physically on a dataplane port, the >>> connection may still be logically separated from the OpenFlow controlled >>> traffic. >>> >>> If you take this approach (of physical in-band) would you expect to be able >>> to dedicate a VLAN to management (including the controller traffic)? The >>> alternative is to have OpenFlow controlling the traffic to the controller, >>> something that has enough pitfalls that no one has really gotten it to work >>> reliably. >>> >>> -Dan >>> >>> >>> On Wednesday, May 9, 2012 at 1:17 PM, Heming Wen wrote: >>> >>> Greetings, >>> >>> We are currently setting up a basic Openflow Wireless testbed with three PC >>> Engine AP and a Pronto 3290 switch in our labs. We have a few questions >>> regarding the connection between the elements: >>> >>> 1) There are three controller path setups possible: L3 inband, tunneling and >>> L2 inband. If we want to setup a small demo (n-casting for instance), is >>> there a preference for a particular configuration? >>> >>> 2) How must the Openflow controller connected to the network in order to >>> control the AP? Right now, the openflow controller is connected to the >>> special ethernet port of the Pronto switch (in order to control the switch). >>> The default pyswitch controller can detect the Indigo/Pronto switch. >>> However, the AP is connected to the switching plane of the Pronto switch. Is >>> there a way to access the switching plane ports from the control port or >>> must the controller be connected in a different fashion? Right now, pinging >>> doesn't work between the switching plane and the control plane. >>> >>> Thank you for your help, >>> >>> Heming >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu<mailto:openflow-discuss@lists.stanford.edu> >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
