Hi Guanyao,

Which version of NOX are you using?  We used to store both the datapathid
and port in a 64bit int because we made the assumption that the datapathid
would be no longer than 48 bits.  That no longer holds, but we've updated
the code in most actively used places to not assume that.  One of the
exceptions I see right now is the python translation of the flow in event,
but I'm not seeing the use you mentioned in sprouting.cc.

In the case you describe, both inports get recorded, and based on
information from link discovery, authenticator can tell which inport is most
"accurate" (takes the one most upstream).  But again, not sure which version
of nox you're using.

2.   That is not expected behavior and likely just depends on what
information that authenticator/routing modules have discovered so far.

Natasha

On Wed, Mar 3, 2010 at 2:51 PM, Guanyao Huang <[email protected]> wrote:

> Sorry to bother you again.
> I have two issues regarding both authenticator module and routing
> module. Please look at the code in sprouting.cc, set_route() function.
>
> 1, The inport is from fi.src_location.location->dpport. Can you
> explain the structure of the location variable? How it maintains both
> datapathid and port number?
>
> My actual concern is:
> Sometimes, packets will get broadcasted before a route is calculated.
> When a broadcasted packet hit another switch, the inport also changed.
> I understand route.id.src is the real ingress switch, so, the whole
> procedure is to find a route from the src datapath, not current
> datapath. But sometimes, because of this, it consistently show "Packet
> not on route" and freezes there. I guess this is because the
> controller is always processing at this "Packet not on route" but not
> continue.
>
> 2, Sometimes the egress datapath read from the authenticator module is
> not the closest one to the dst mac. This makes the flow sent to
> different datapath other than the correct one. Is this a known bug or
> is this not important?  Our experiment shows this sometimes matters.
>
> Thanks.
>
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Reply via email to