Re: Bridging with 2 unidirectional vlans and one phys if
Grant Taylor <[email protected]> Wed, 06 Feb 2008 10:35:15 -0600
| Newsgroups | gmane.linux.network.bridge.ebtables.user |
|---|---|
| Organization | Riverview Technologies Inc. |
| Message-ID | <[email protected]> |
On 02/06/08 10:18, Zoilo Gomez wrote: > It is 8139too (Realtek 8139). > > But I do not think that it has anything to do with the network card > drivers. From inspecting tcpdump (monitoring on all interfaces) it is > obvious that the ARP Request goes out via vlan223 (correct), but the > Reply of course comes back on vlan200 (also correct) ... and from that > moment on, all IP-traffic is now bridged to vlan200 (instead of > vlan223), because that is where the MAC address replied ... I too run 8139s and have no problems with them. However there are some cards (that offload some functions from the driver to a CPU on the NIC?) that have these problems. > So I tried to establish a static ARP entry: > => arp -s 192.168.22.254 00:11:22:33:44:55 -i vlan223 > > The ARP entry shows up correctly in the arp table, but it seems to be > ignored: an ARP-request is sent out anyway for 192.168.22.254, in spite > of the static ARP-entry, and I end up in the same situation. > > Anybody know why the static ARP-entry is ignored? It is my (mis)understanding that the ARP cache is only used when the local system is trying to find the MAC address of an IP, not when it is forwarding frames. Thus, if you are sending traffic from your host behind your Linux box the ARP cache on the Linux box will have no baring what so ever on where the traffic is sent. > Anybody know how to force that all IP-traffic be sent via vlan223, > without ARP-interference? I'm puzzled by the fact that the Linux bridge is behaving the way that it is. I'm surprised that the traffic is not going out vlan223 like it is suppose to be. This makes me believe there is something wrong with the bridging code to allow it to work in spite of EBTables. Unless there is something like IPTables where traffic only passes EBTables on the first pass through the kernel (like IPTables NAT table). On a whim, try adding the following EBTables rules and try again. ebtables -A FORWARD -o eth1 -i vlan223 -j DROP ebtables -A FORWARD -i eth1 -o vlan200 -j DROP See what the counters say with these rules in place. Also, make sure that you flush your EBTables in between tests to make sure that there is no stale rule that is effecting you. Can we see the output of ebtables-save (I think that is correct)? Grant. . . . ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/