Hi
Back to the second issue. I think it is a common problem that "one mac
might get authenticated to more than one datapath". This will cause
problem for a topology with loops. I heard someone else also
complaining about it.
Here is a simple verbose output. I am running routing and
spanning_tree module. It is a simple output of ping command (from
70.14 to 70.15), where arp entry is static. Nox version is 0.6. I
didnt modify anything, but only added command for line 157, 165, etc,
below. I only send one ICMP request.
You donot need to bother the details. But:
1, clearly "00:15:17:d1:fa:92 192.168.70.14" get authenticated many
times. Actually each time it is broadcasted and received by one
datapath, that datapath will add it, showing this mac address can be
reached by myself.
2, line 176 is the returned path for arp reply. Because more than one
datapath announce itself to the dst mac, the returned path is actually
faraway from the real dst datapath. The authenticator module chooses
the last announced datapath as dst datapath, which is improper.
For a loopless topology, authenticating many times have no problem
(remember in_port and out_port can not be the same). But for a loop
topology, I think this really matters.
A simple modification might be to let each mac address be
authenticated only once. Basically, why one mac address should be
authenticated more than once? Is there a reason for this? Since I only
send one ICMP request, I think the multiple authenticating messages
suggest that mac is authenticated more than once.
The code to call authenticator module is in
SPRouting::set_route(Flow_in_event& fi,
Routing_module::RoutePtr& route,
uint16_t& inport, uint16_t& outport,
const Buffer& actions, bool check_nat)
Thanks.
================================
00147|authenticator|DBG:Automatically authing 00:15:17:d1:fa:92 192.168.70.14.
00148|authenticator|DBG:Binding for host doesnt exist, using default.
00149|authenticator|DBG:Host auth event received.
00150|authenticator|DBG:authenticated added location authenticated to
00:15:17:d1:fa:92.
00151|authenticator|DBG:Added 00:15:17:d1:fa:92 192.168.70.14 to host
authenticated.
00152|sp_routing|DBG:handle_flow_in 00269e3ed906: 165863676166
00153|sp_routing|DBG:Broadcasting 269e3ed906 port0012:vlanffff
mac00:15:17:d1:fa:92->00:15:17:d1:fa:86 proto0800
ip192.168.70.14->192.168.70.15 port8->0
00154|authenticator|DBG:Automatically authing 00:15:17:d1:fa:92 192.168.70.14.
00155|authenticator|DBG:Host auth event received.
00156|authenticator|DBG:authenticated added location authenticated to
00:15:17:d1:fa:92.
00157|sp_routing|DBG:handle_flow_in 00269e3dd906: 165863610630
00158|sp_routing|DBG:Broadcasting 269e3dd906 port0011:vlanffff
mac00:15:17:d1:fa:92->00:15:17:d1:fa:86 proto0800
ip192.168.70.14->192.168.70.15 port8->0
00159|authenticator|DBG:Automatically authing 00:15:17:d1:fa:92 192.168.70.14.
00160|authenticator|DBG:Automatically authing 00:15:17:d1:fa:92 192.168.70.14.
00161|authenticator|DBG:Host auth event received.
00162|authenticator|DBG:authenticated added location authenticated to
00:15:17:d1:fa:92.
00163|authenticator|DBG:Host auth event received.
00164|authenticator|DBG:authenticated added location authenticated to
00:15:17:d1:fa:92.
00165|sp_routing|DBG:handle_flow_in 00269e3fd906: 165863741702
00166|sp_routing|DBG:Broadcasting 269e3fd906 port0017:vlanffff
mac00:15:17:d1:fa:92->00:15:17:d1:fa:86 proto0800
ip192.168.70.14->192.168.70.15 port8->0
00167|sp_routing|DBG:handle_flow_in 00269e40d906: 165863807238
00168|sp_routing|DBG:Broadcasting 269e40d906 port001c:vlanffff
mac00:15:17:d1:fa:92->00:15:17:d1:fa:86 proto0800
ip192.168.70.14->192.168.70.15 port8->0
00169|authenticator|DBG:Automatically authing 00:15:17:d1:fa:86 192.168.70.15.
00170|authenticator|DBG:Binding for host doesnt exist, using default.
00171|authenticator|DBG:Host auth event received.
00172|authenticator|DBG:authenticated added location authenticated to
00:15:17:d1:fa:86.
00173|authenticator|DBG:Added 00:15:17:d1:fa:86 192.168.70.15 to host
authenticated.
00174|sp_routing|DBG:handle_flow_in 00269e3fd906: 165863741702
00175|routing|DBG:Route: port0016:vlanffff
mac00:15:17:d1:fa:86->00:15:17:d1:fa:92 proto0800
ip192.168.70.15->192.168.70.14 port0->0
00176|routing|DBG:16:269e3fd906:19 --> 1b:269e40d906:1c
On Thu, Mar 4, 2010 at 9:56 AM, Natasha Gude <[email protected]> wrote:
> 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
