Thanks for the response, I'll answer the questions below: El Mie, 10 de Septiembre de 2008, 16:15, Grant Taylor escribió: > On 09/10/08 02:51, ArcosCom Linux User wrote: >> Thanks for the response, I explain a bit more. > > *nod* > >> The 3 uplinks have 3 public IP addressess (one per uplink), and are >> "ADSL" links, one public ip per interface. > > Ok. > >> eth1 and eth2 have, each one, their direct connect to their ADSL >> gateway. > > Ok. > >> eth3 (public IP) and eth0 (private IP) share the same ethernet >> network. > > This confirms what I was thinking. However I ask why they are sharing > the same ethernet network? Why is the uplink 3 connection on the same > ethernet network as your LANs? Is there as reason that this is the case > rather than just putting uplink 3 directly on eth3 with out putting it > across the LANs network segment? > Because I cant have another uplink in the router place and I need to put that in another building that can have another uplink. >> Physically, this shared ethernet have many wireless bridges (using >> STP) to link all the buildings we need to link. > > Ok. This should not matter. > >> The test I done to see the latences are send 2 pings to the same >> physical place to diferent defices from the linux box. > > Ok... > >> One ping from router to adsl gateway (eth3->uplink3 gateway) and, at >> the same time, one ping from router to a workstation (eth0->LAN). >> >> Physically the two pings go trought the same physicall path and end >> in the same switch where the uplink3 gateway and the test workstation >> are. > > So the uplink 3 gateway is on the LAN and on the local side of a WAN link? > Yes. >> In router: >> >> a) I MASQUERADE the IP by interface (-j MASQUERADE), because I need >> to have all ougoing frames control. > > Is this the only reason that you have both eth0 and eth3 connected to > the same ethernet network? > Ah, no, this is not the reason. It's a "logistic" reason only. >> b) I balance the routers (as described in lartc and use magle to >> allow the responses from the incomming interface where they arrives. > > I believe this should be able to be done independent of the physical > interface that packets are leaving. > Yes, I think so too, only put here to put more information. >> c) I use tc (using HTB qdiscs) for the QoS (the problem became with >> QoS disabled too, don't think this were the problem). > > Ok. > >> Yesterday, I found a local kernel text file called >> /usr/share/doc/kernel-doc-2.6.18/Documentation/networking/ip-sysctl.txt >> (internet is not all) where I see a very usefull information about ip >> parameters and appears that tweaking some of them will solve some >> problems with ARP, but really I don't know many of these parameters >> and only appears to be usefull for me some of them: arp_filter, >> arp_accept, arp_ignore, rp_filter. > > With out knowing for sure what the problem is or what is causing it I > can't say what to adjust. However I suspect your problem has something > to do with the fact that (if I recall correctly) Linux will by default > respond to ARP queries on any interface for an IP that may be bound to a > different interface. In short IPs are more or less bound to the box not > the interface, thus any interface can get you to the box. There are a > couple of /proc entries that will adjust the kernel's ARP behavior to > make it only respond to ARP queries if they are bound to an IP that is > bound to the interface that it is coming in on, rather if the > interface's IP is in the subnet pertinent to the ARP query. > > I'm just guessing (with out seeing some TCPDumps of traffic) that > systems on either eth0 or eth3 are needing to ARP for either of the IPs > of eth0 or eth3 and the wrong interface is replying, or both are > replying. If both interfaces are replying at the same time or if they > are flip flopping back and forth I can see how your layer 2 ethernet > network / switch would be getting confused as well as devices wanting to > talk to said IPs. > Yes, that appears to be the problem (seeing tcpdumps in each interface). Do you have any suggestion about that parameters on that interfaces? > > > Grant. . . . > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
