Dump the control traffic using openflow.debug and then take a look at it, e.g., with the OpenFlow dissector for Wireshark. That may shed some light.
You also might try enabling fragment reassembly by sending an OFPT_SET_CONFIG. -- Murphy On Oct 23, 2014, at 9:41 PM, tim huang <pds...@gmail.com> wrote: > Sorry, please ignore last email. I made some mistakes for my statement. > > Hi, > > I find the situation is more interesting. At beginning, I thought it was > caused by the fragmentation, then I can't ping with any fragmentation. > However, when I tried several times.Actually, I can ping successfully with > large size packet, if that's the first flow between 2 switches.After the > flows timeouts on the switch, I can't ping any more through controller. > > Here is the output I get with same topology I described in my 2nd email. > > The 1st ping is successful. After the flows timeout on all the switches, I > can't ping any more with large size packets, but I can still issue ping with > small size packets. > > The outputs are the attempts with different sizes. > > And there are still some situations that I can't ping with large packets at > the beginning when I use mininet. I'm thinking maybe there are some > packets,like ARP or something else, had been forwarded between these 2 > switches before I ping. Usually, the first ping can be successful on my esxi > platform where I deploy the openvswitches and linux machines. > > ------------------------------------------------- > mininet> h1 ping h3 -s 5000 > PING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > 5008 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=94.5 ms > 5008 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.161 ms > 5008 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.092 ms > 5008 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.155 ms > 5008 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.130 ms > ^C > --- 10.0.0.3 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4001ms > rtt min/avg/max/mdev = 0.092/19.012/94.526/37.757 ms > mininet> h1 ping h3 -s 5000 > ^CPING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > > --- 10.0.0.3 ping statistics --- > 212 packets transmitted, 0 received, 100% packet loss, time 211623ms > > mininet> h1 ping h3 > PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. > 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.330 ms > 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=1166 ms > 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.093 ms > 64 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.095 ms > 64 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.081 ms > 64 bytes from 10.0.0.3: icmp_req=6 ttl=64 time=0.083 ms > ^C > --- 10.0.0.3 ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 5002ms > rtt min/avg/max/mdev = 0.081/194.523/1166.459/434.663 ms, pipe 2 > mininet> h1 ping h3 > PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. > 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=76.2 ms > 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.083 ms > 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.095 ms > 64 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.061 ms > 64 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.079 ms > ^C > --- 10.0.0.3 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4001ms > rtt min/avg/max/mdev = 0.061/15.313/76.250/30.468 ms > > mininet> h1 ping h3 -s 5000 > ^CPING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > > --- 10.0.0.3 ping statistics --- > 42 packets transmitted, 0 received, 100% packet loss, time 41045ms > -------------------------------------------------- > > I really want to fix this problem for pox to do some contribution, because it > really helps me a lot. I do love the concept of pox than other similar > controller,like Ryu. Can anybody give me some clue about this problem? > > On Fri, Oct 24, 2014 at 12:25 AM, tim huang <pds...@gmail.com> wrote: > Hi, > > I find the situation is more interesting than I thought. At beginning, it's > just caused by the fragmentation,I can't ping with any fragmentation. > however, when I tried several times. I found something new. I can ping > successfully with large size packet, it that's the first flow between 2 > switches,after the flows timeouts on the switch, I can't ping any more. > > Here is the output I get with same topology I described above. > > The 1st ping is successful. After the flows timeout on all the switches, I > can't ping any more with large size packets, but I can still issue ping with > small size packets. > Here are the attempts with different sizes. > > And there are still some situations that I can't ping with large packets at > the beginning. I'm thinking that maybe there are some packets had been > forwarded between these 2 switches before I ping. > > I want to fix this problem for pox to contribute some code for this project, > because it really helps me a lot. I do love the concept of pox than other > similar controller,like Ryu. Can anybody give me some clue about this problem? > ------------------------------------------------- > mininet> h1 ping h3 -s 5000 > PING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > 5008 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=94.5 ms > 5008 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.161 ms > 5008 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.092 ms > 5008 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.155 ms > 5008 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.130 ms > ^C > --- 10.0.0.3 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4001ms > rtt min/avg/max/mdev = 0.092/19.012/94.526/37.757 ms > mininet> h1 ping h3 -s 5000 > ^CPING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > > --- 10.0.0.3 ping statistics --- > 212 packets transmitted, 0 received, 100% packet loss, time 211623ms > > mininet> h1 ping h3 > PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. > 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.330 ms > 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=1166 ms > 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.093 ms > 64 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.095 ms > 64 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.081 ms > 64 bytes from 10.0.0.3: icmp_req=6 ttl=64 time=0.083 ms > ^C > --- 10.0.0.3 ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 5002ms > rtt min/avg/max/mdev = 0.081/194.523/1166.459/434.663 ms, pipe 2 > mininet> h1 ping h3 > PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. > 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=76.2 ms > 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.083 ms > 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.095 ms > 64 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.061 ms > 64 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.079 ms > ^C > --- 10.0.0.3 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4001ms > rtt min/avg/max/mdev = 0.061/15.313/76.250/30.468 ms > > mininet> h1 ping h3 -s 5000 > ^CPING 10.0.0.3 (10.0.0.3) 5000(5028) bytes of data. > > --- 10.0.0.3 ping statistics --- > 42 packets transmitted, 0 received, 100% packet loss, time 41045ms > -------------------------------------------------- > > > On Tue, Oct 21, 2014 at 7:08 AM, Lucas Brasilino <lr...@cin.ufpe.br> wrote: > > Yup, dart. It's actually more than due to get rolled over to eel, but it's > > waiting on me to have some time to dedicate to POX, which hasn't happened > > for a while. :) > > eel ? I was about to suggest 'eager' name :-D > > > -- > Att > Lucas Brasilino > MSc Student @ Federal University of Pernambuco (UFPE) / Brazil > twitter: @lucas_brasilino > > > > -- > Thanks > Tim > > > > -- > Thanks > Tim
