ArcosCom Linux User
2008-May-28 08:54 UTC
[CentOS] Problem accessing to Windows Terminal Server in load balancing.
Hi guys, I have this configuration: LAN -- LINUX BRIDGE -- LINUX BRIDGE -- TS The linux's bridges are for wifi purposes (2 centos machines) and is working fine. The problem I have is that the TS are 3 windows TS in load balancing configuration. There is 1 IP for general purposes and every TS has its own IP. For example, the configuration is: 192.168.0.1/24 TS1 192.168.0.2/24 TS2 192.168.0.3/24 TS3 192.168.0.10/24 (TS server IP for load balancing) The problem I encountered is that every PC into the LAN has access from the LAN to every TS (tested with ping), but them have no access to the IP for load balancing. I observed that all TSn IP's has their ARP entry in the ARP table, but the IP for load balancing not. How can I solve this problem at the bridge level? I think that there is something that the bridges are filtering and perhaps is because the TS load balancing software uses various "virtual macs" for the load balancing IP. Perhaps I must change any /proc/sys/net/ipv4/conf/<dev>/ file to bypass this filter, I'm thinking in "arp_ignore", put a "1" into it, but is a production environment and I don't want to loss the access to the devices. Any help?
Lorenzo Quatrini
2008-May-28 16:12 UTC
[CentOS] Problem accessing to Windows Terminal Server in load balancing.
ArcosCom Linux User ha scritto:> > I observed that all TSn IP's has their ARP entry in the ARP table, but the > IP for load balancing not. > > How can I solve this problem at the bridge level? I think that there is > something that the bridges are filtering and perhaps is because the TS > load balancing software uses various "virtual macs" for the load balancing > IP. >I had a similar issue with a Cisco router; the solution was to add an entry on the arp table for the IP for load balancing and the "virtual" ethernet address of the cluster. (You can find them on the properties of the cluster) I guess you could use /etc/ether to make the mapping persistent. Regards Lorenzo Quatrini