up vote 0 down vote favorite
share [g+] share [fb]

I recently inherited a pair of servers that were originally set up in a datacenter. I know Linux reasonably well, but almost nothing about how to set up networking. These servers each have three ethernet ports, so I'm triply-lost. My goal is to restore these to the simplest possible configuration. I do not need the complexity (or benefits) of datacenter-grade networking.

Here's what I have:

  • server1: web server, needs to connect to server 2. Server 1 is working fine, when it can connect to the database. IP is 192.168.10. Our bug tracker tries to connect to the database on 192.168.1.20
  • server2: database server (running mysql). For some reason, server1 can sometimes access server2 using the IP 192.168.1.20. Other times, however, it cannot.

My goal: make it so that server1 can consistently connect to server2. These servers are waaaaay overkill for what we're using them for. I want the simplest possible configuration. I do not need to use all three network cards. I would be fine if these servers just connected to our office router and obtained IPs just like everything else.

Please let me know what information you need from me. Here is the output of ifconfig on server1:

eth0      Link encap:Ethernet  HWaddr 00:30:48:f3:55:d2
          inet addr:64.34.44.74  Bcast:64.34.44.79  Mask:255.255.255.248
          inet6 addr: fe80::230:48ff:fef3:55d2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          <snip>    
eth1      Link encap:Ethernet  HWaddr 00:30:48:f3:55:d3
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fef3:55d3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          <snip>    
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          <snip>

Here is the ifconfig output on server2:

br1       Link encap:Ethernet  HWaddr 00:30:48:f3:56:03
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fef3:5603/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          <snip>
eth0      Link encap:Ethernet  HWaddr 00:30:48:f3:56:02
          inet addr:64.34.44.75  Bcast:64.34.44.79  Mask:255.255.255.248
          inet6 addr: fe80::230:48ff:fef3:5602/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          <snip>
eth1      Link encap:Ethernet  HWaddr 00:30:48:f3:56:03
          inet6 addr: fe80::230:48ff:fef3:5603/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          <snip>
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          <snip>

Here is the output of brctl show br1 on server 2:

bridge name     bridge id               STP enabled     interfaces
br1             8000.003048f35603       no              eth1

On server 2, 

$ ip route show

64.34.44.72/29 dev eth0  proto kernel  scope link  src 64.34.44.75
192.168.1.0/24 dev br1  proto kernel  scope link  src 192.168.1.20
default via 64.34.44.73 dev eth0  metric 100

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:30:48:f3:56:02 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:30:48:f3:56:03 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1b:21:5d:58:d8 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1b:21:5d:58:d9 brd ff:ff:ff:ff:ff:ff
6: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:30:48:f3:56:03 brd ff:ff:ff:ff:ff:ff

On server 1:

$ ip route show
64.34.44.72/29 dev eth0  proto kernel  scope link  src 64.34.44.74
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.10
default via 64.34.44.73 dev eth0  metric 100

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:30:48:f3:55:d2 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:30:48:f3:55:d3 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1b:21:5d:5d:e8 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1b:21:5d:5d:e9 brd ff:ff:ff:ff:ff:ff
link|improve this question
notjim, also, please edit in ip route show & ip link show from server1 and server2. – Mike Pennington May 11 '11 at 18:48
@mike pennington: done. – notJim May 11 '11 at 18:54
feedback

2 Answers

up vote 0 down vote

Server 1 looks fine, assuming the cabling is right, but server 2 looks extremely ropey. Could you add the output of brctl show br1?

link|improve this answer
I've added that. – notJim May 11 '11 at 18:13
Could you expand on what the cabling should be? I have never set foot in a data center :/. I think right now all of the network cards are plugged into a router we inherited along with these servers. The router then plugs into our office switch... – notJim May 11 '11 at 20:34
feedback
up vote 0 down vote

notJim,

Run a dedicated link between server1:eth1 and server2:eth1. This will be for your DB connection between the boxes.

I assume your office network is not in the 64.34.44.72/29 block. If I am correct, re-address eth0 on each machine with a static address that your office network admin assigns; connect eth0 of each machine to your office network. The reason I say static is because these machines provide business services to your network; they need to be mapped in DNS, and also need a constant address you can manage them from.

If your bug-tracker is not on server1, reconfigure the bug tracker to connect to whatever address you assign to server2:eth0, and be sure that your DB server is listening on server2:eth0.

It is possible to eliminate the dedicated eth1 link between them, but since you have a DB connection (presumably between server1 and server2), there shouldn't be a need for that traffic to cross your corporate LAN... besides you'll get a tiny bit more reliability with a crossover cable and no intermediate device to fail.

Some offices get complicated by assigning all addrs via DHCP, and resolve names w/ dynamic dns... if that works in your office, then great... no need for statics on eth0.

link|improve this answer
Hmm, okay... now to figure out which port is which... – notJim May 11 '11 at 20:26
Does the fact that the bridge is bridged to eth1 mean that eth1 is reachable using 192.168.1.20? (assuming eth1 is wired correctly?) – notJim May 11 '11 at 20:33
@notjim, (responding to an old edit you did) you can plug them into a switch one port at a time, and look at the output of ip link show... the interface that is up will have state UP in the flags... yes eth1 on server2 should be pingable on 192.168.1.20. – Mike Pennington May 11 '11 at 20:35
Oh, thanks, that will be handy. – notJim May 11 '11 at 21:25
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.