Dan Wendlandt wrote: > David Erickson wrote: >> Hmm, I'm not sure that bindings_storage will work here since this is a >> time sensitive lookup, holding back packets from a flow waiting for a >> callback could be very detrimental, what do you think? >> >> -David >> > Hi David and Glen, > > We had a quick chat here about how to best meet your needs and decided > that the best approach is actually the simplest: you can just have your > own component listen to all packet in events to fill a python dictionary > of IP-to-location mappings based on the packet-in event's data. > Granted, this won't be super scalable in a large network, but if you > need real scalability, you will probably want to port the app to C++, in > which case you can easily access the same info via Authenticator. Does > that sound reasonable?
Dan, Thanks for the reply. We currently do have code that creates and tracks ip:mac:dpid mappings, the problem was getting this information back in to authenticator for when it creates the flow_in events. However I think what we can do is listen for flow_in's ourself, and if we determine the destination chosen by authenticator is not optimal (ie it selected the gateway when we can actually go directly to an ip), then we will issue a STOP to the event, and post our own flow_in event with the fixed up destination connector object. That will handle getting routing to set the correct route, then as a quick hack we can add a member variable to the Flow_in_event object to contain a dest mac for rewriting, which can be examined by the handle_flow_in within Routing at the last hop in the Full Route, and add the action to rewrite. Does that sound reasonable? Thanks, -David _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
