A customer based in a serviced office has an installation with the eth0 port connected to his internal network and the eth1 port plugged into a communal switch which eventually leads the connection out into the internet. LFS allows manual IP configuration of eth0 (lets call it 192.168.0.1) but insisted on doing its own "search and configure" for the internet connection. When we first set it up it found the right address (lets call it 111.111.111.111) and everything was fine and dandy.
Then the serviced office provider decided to install a new firewall and his customers had to endure some connection downtime while that happened. When all of the systems were reconnected my customer was perplexed to find that his rebooted LFS server was now showing the firewall's external IP (lets call it 222.222.222.222) as its own eth1 IP address.
We did toy with the idea of adding new DNS entries to LFS to try to work around the problem but I dislike those type of bandaid solutions - they tend to come back and bite you further down the track when you're solving some other unrelated configuration problem.
After much wailing and gnashing of teeth and consumption of coffee we found an answer by connecting the LFS eth1 to a reprogrammed router which that been isolated from the rest of the network. The router range was limited to a single address (111.111.111.111) and when we ran the LFS netscan command the LFS eth1 picked up the magic number and permanently stored it into its configuration file. We then pulled the eth1 cable out of the router and plugged it into the regular network switch and everyone was happy. We still haven't figured out why LFS was picking up the Firewall external IP and that question might stay in the too-hard basket for some years to come. I think a review of the Firewall configuration might reveal some interesting anomolies, but we aren't allowed to examine that hardware.
Every day is a new adventure.
.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment