A dependency of some component you're running hasn't been met. To rectify this, you should probably run the missing component by including it on the commandline. If you run with logging at DEBUG level, you'll get a more detailed message, such as "
core:startup() in pox.forwarding.l2_multi still waiting for: openflow_discovery". In this case, it indicates that
Why doesn't POX's discovery use the normal LLDP MAC address?
POX's discovery uses the MAC address that Nicira defined for use with OpenFlow-based discovery and which was used by the NOX controller. The significant difference between the normal one and the Nicira one is that the original one is in the bridge-filtered range, which means that Ethernet switches should never forward it. If your network is entirely made of OpenFlow switches, this doesn't make any difference. But if your network is a combination of OpenFlow switches and traditional Ethernet switches, it does.
Imagine you had the following topology, where A and B are OpenFlow switches, and S is a standard Ethernet switch.
A -- S -- B
Imagine that the controller tells A to send a discovery packet with the normal LLDP MAC address. It gets to S. S will drop it, since the address is bridge-filtered. Thus, the controller concludes that packets sent from A will not reach B. This is obviously false except in the very special (that is, unusual) case where you're using bridge-filtered MAC addresses!
By using a non-bridge-filtered address for discovery, POX (and NOX before it) can "see through" traditional Ethernet switches.
What's a good strategy for debugging a problem with my POX-based controller?