Re: Switches and ARP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 27, 2002 at 05:14:05PM -0500, Amit Kucheria wrote:
[switches learn by seeing _SOURCE_ MAC on ports]
>
> This does seem to make a *lot* of sense only if that algorithm works
> that way you described.

It does.

> 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.

Speaking of every-day networks and the real world, I encounted that,
along with flooding problems, in two situations: First, there's the
UDP based Cisco netflow collector protocol, where usually there's
only traffic flowing TO the collector box. Second, in a multiple-interface
box, you can easily get the incoming traffic on one link, and the outgoing
traffic on the other link.

In both cases, if you think about the incoming data stream only,
two things may alternately happen. There will be a router sending
the incoming packets through the switch to the box. That router _does_
operate ARP.  Now, if the ARP timeout is larger than the switch MAC
table timeout, then there will be a period of flooding. This happens
easily with the default (long) ARP timeouts on Cisco routers. The solution
is then to make the ARP timeout smaller than the MAC table timeout,
forcing an ARP request now and then, and the ARP reply will then refresh
the timer on the switch MAC table.

> 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.

Given the algorithm you now know, you have to use something (anything)
which has the correct source MAC on the desired output port. ping will
do fine, an ARP request/reply pair will do fine, an a totally synthesized
"MAC takeover" packet will do, too. Source MAC on desired port -> mapping.

best regards
  Patrick

-
: 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

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux