On 27 Jun 2002, Danny Lepage wrote:
> On Thu, 2002-06-27 at 17:26, Amit Kucheria wrote:
>
> > BTW, for this experiment, I only have unidirectional UDP traffic. So I
> > dont expect any packets back on the reverse path. Not that it should
> > really matter, should it?
>
> Oh yes. That is why your seeing such behavior.
>
> Here is roughly how the switching engine works in pseudo code:
>
> OnReceiveFrame( frameReceived, receivingPort ) {
> UpdateForwardingTable( frameReceived->srcMacAddr, receivingPort );
>
> dstPort = LookUpForwardingTable( frameReveiced->dstMacAddr );
>
> if ( null(dstPort) )
> BroadcastFrameOnAllPorts( frameReceived );
> else
> SendFrameOnPort( frameReceived, dstPort );
> }
>
> The switch can only populate his forwarding table from ethernet frame on
> a port, with the frame source MAC addr.
>
> If the traffic is unidirectional, the switch will only see frame with
> src MAC V1 but will never see frame with src MAC V2.
This does seem to make a *lot* of sense only if that algorithm works
that way you described. And maybe it does, because I cannot seem to come
up with any examples in every-day networks where the traffic flows
strictly in one direction. In that case this algorithm is all that you
need to get real *switched* communication with autolearning.
Now I am going to try and come up with a way to force the switch to
learn all interface-port mappings before starting my experiment. Maybe a
simple ping between the two machines originating from both sides should
solve the problem.
Thanks for that elaborate explanation.
ciao,
Amit
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
