Comments inline: On Fri, Mar 12, 2010 at 1:56 PM, Guanyao Huang <[email protected]> wrote:
> I think some document of authenticator module is very necessary. > The newest version of authenticator module seems changed a lot, but > the code for routing module remains the same. > For example, why there are many events defined in host_event.hh, host_event.hh has comments describing the meanings of the different events. > why > there are many entries, bindings defined in authenticator.hh. > For networks wanting to identify hosts with certain addresses, or coming up on certain locations, with specific identifiers. e.g. Someone wants to say "mac address ab:cd:ef:12:34:56 will always be host A so when that mac address shows up, the host event should include host A's identifier." If such an identifier doesn't exist then the entity is tagged with a default identifier, which is probably what you see as it doesn't seem that you are using this feature - it's optional. > Normally, given a mac address, or, IP address, what is the API used to > get its datapath? > get_<dl/nw>addr_entry() and look at and authenticated locations. an AuthedLocation can be traversed to find the port and datapathid. if those switches/ports have been tagged with identifiers, those can be seen as well, though again, it doesn't seem like you're using that, so you can ignore it. > Without such things, I feel easily get lost in the code. > I guess many people are developing their own module based on flow_in > event. It would be nice if they know how this flow_in event was > generated. > > all the flow-in is trying to do is annotate a packet-in event with identifiers. e.g. this packet was sent by host A which is on switch B and has user C logged in. if you don't need this functionality, you are free to ignore the flow-in and just use the packet-in. to address KK's comments, the flow-in event is not generated for the sole purpose of routing. 1. the tagging can prove very useful in other scenarios (as we use internally) and 2. pulling in the the routing component using the flow_in_event is completely optional, and can be replaced by a component using packet-in's instead. sprouting.hh/.cc uses the flow-in event to set up routes from the original source instead of the one the packet came in on (as you may have seen, these datapaths are not always the same) to support mobility. In general, it's actions reflect what's need to get to end-to-end routing working in somewhat of a dynamic network. Finally, in regard to the presence of multiple locations for a given mac address. We found the need for this in certain topologies where a host was effectively connected to two distinct openflow ports in the network, sending/receiving packets on both using the same mac address. If this doesn't happen in your topologies, and the AUTH_WITH_ROUTING ifdef is enabled in authenticator.hh (which depends on the routing_module library, NOT the sprouting.hh/sprouting.cc component) then you should not be seeing multiple locations, or they should be timing out. Feel free to resend any questions I missed. Natasha On Fri, Mar 12, 2010 at 1:40 PM, Srini Seetharaman > <[email protected]> wrote: > > Just to add to Guanyao's observations: I wanted to mention that the > > host having two bindings is something we run across often in our > > Stanford setup. However, we notice it only when the topology is > > changed during runtime. > > > > Srini. > > >
_______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
