So it probably has to do with fragmentation and the fact that l2_multi does exact matches. The other controllers you're testing are probably doing forwarding based on just IP or Ethernet destinations, which simplifies things. Modify l2_multi to do that too and see if it makes a difference.
Around line 384 of l2_multi.py, there's the line: match = of.ofp_match.from_packet(packet) Comment it out and do a simpler match. Like... match = of.ofp_match(dl_dst = packet.dst) -- Murphy On Oct 19, 2014, at 5:45 PM, Tim Huang <pds...@gmail.com> wrote: > Sorry for my unclear statement. > > I’m using the discovery, STP, l2_multi modules on the controller with the > diamond topology, like > > h1—s0—— s1—— s2—h3 > | | > | ——s3—— | > > > When I issue a ping on h1 (10.0.0.1) like this > ------------------- > root@ubuntu:~# ping 10.0.0.3 -s 1600 > PING 10.0.0.3 (10.0.0.3) 1600(1628) bytes of data. > ^C > --- 10.0.0.3 ping statistics --- > 14 packets transmitted, 0 received, 100% packet loss, time 13102ms > —————————— > The ping can never be successful. By default, I can’t see any warning or > error log information on pox. > > If you ping with smaller size packet like 1000 bytes, there isn't any > problem. After I tested, the threshold is around 1500, I’m thinking it’s > because of fragmentation. > > ————————————————————— > root@ubuntu:~# ping 10.0.0.3 -s 1000 > PING 10.0.0.3 (10.0.0.3) 1000(1028) bytes of data. > 1008 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=268 ms > 1008 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.061 ms > 1008 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.052 ms > 1008 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.057 ms > ———————————————— > Here is the all log information on the pox side. > ———————————— > pox git:(dart) ./pox.py openflow.discovery openflow.spanning_tree > forwarding.l2_multi > POX 0.3.0 (dart) / Copyright 2011-2014 James McCauley, et al. > INFO:core:POX 0.3.0 (dart) is up. > INFO:openflow.of_01:[00-00-00-00-00-0c 1] connected > INFO:openflow.of_01:[00-00-00-00-00-0d 4] connected > INFO:openflow.of_01:[00-00-00-00-00-0b 2] connected > INFO:openflow.of_01:[00-00-00-00-00-0a 3] connected > INFO:openflow.discovery:link detected: 00-00-00-00-00-0c.3 -> > 00-00-00-00-00-0d.2 > INFO:openflow.discovery:link detected: 00-00-00-00-00-0c.2 -> > 00-00-00-00-00-0b.3 > INFO:openflow.discovery:link detected: 00-00-00-00-00-0d.3 -> > 00-00-00-00-00-0a.3 > INFO:openflow.discovery:link detected: 00-00-00-00-00-0d.2 -> > 00-00-00-00-00-0c.3 > INFO:openflow.spanning_tree:6 ports changed > INFO:openflow.discovery:link detected: 00-00-00-00-00-0b.3 -> > 00-00-00-00-00-0c.2 > INFO:openflow.spanning_tree:4 ports changed > INFO:openflow.discovery:link detected: 00-00-00-00-00-0b.2 -> > 00-00-00-00-00-0a.2 > INFO:openflow.spanning_tree:1 ports changed > INFO:openflow.discovery:link detected: 00-00-00-00-00-0a.3 -> > 00-00-00-00-00-0d.3 > INFO:openflow.spanning_tree:4 ports changed > INFO:openflow.discovery:link detected: 00-00-00-00-00-0a.2 -> > 00-00-00-00-00-0b.2 > ————————————————————— > > Using Ryu as the controller for the same topology > ——— ———— ————— > root@ubuntu:~# ping 10.0.0.3 -s 9999 > PING 10.0.0.3 (10.0.0.3) 9999(10027) bytes of data. > 10007 bytes from 10.0.0.3: icmp_req=21 ttl=64 time=1.36 ms > 10007 bytes from 10.0.0.3: icmp_req=22 ttl=64 time=0.183 ms > 10007 bytes from 10.0.0.3: icmp_req=23 ttl=64 time=0.118 ms > 10007 bytes from 10.0.0.3: icmp_req=24 ttl=64 time=0.142 ms > 10007 bytes from 10.0.0.3: icmp_req=25 ttl=64 time=0.259 ms > 10007 bytes from 10.0.0.3: icmp_req=26 ttl=64 time=0.150 ms > 10007 bytes from 10.0.0.3: icmp_req=27 ttl=64 time=0.122 ms > 10007 bytes from 10.0.0.3: icmp_req=28 ttl=64 time=0.109 ms > 10007 bytes from 10.0.0.3: icmp_req=29 ttl=64 time=0.265 ms > ————— ————————— > > >> On Oct 19, 2014, at 19:42, Murphy McCauley <murphy.mccau...@gmail.com> wrote: >> >> I don't know what limit you're running into. >> >> Can you be (much) more specific about what you're trying to do, what you >> think should be happening, what is happening instead, any relevant errors or >> log messages, etc.? >> >> -- Murphy >> >> On Oct 19, 2014, at 4:35 PM, Tim Huang <pds...@gmail.com> wrote: >> >>> Hi, >>> >>> I am modifying the pox code to perform some kind of load balancing on the >>> controller. However, I found that the maximum ping packet size that pox can >>> handle is around 1500 bytes which is too small for my test case, then I >>> tried other controllers like Ryu, Opendaylight, and they don’t have this >>> kind of limitation. Is it because of fragmentation or something else? any >>> clue for this? >> >
