First IP OK, second IP times out

Discussion in 'Installation/Configuration' started by Craig, Aug 29, 2009.

  1. Craig

    Craig New Member

    I have two IPs for two ssl sites.

    Each IP has its own public IP, private IP and network adaptor.

    DNS is set up and has worked in the past before reinstalling everything and installing ISPConfig. I've used ISPConfig for years but this is my first use of it on a multi-IP box.

    I can ping the second domain and it connects to the second IP address without problem.

    I have the second IP selected for the second site in ISPConfig.

    But, both mail and http requests to the domain and even the IP time out.

    Any ideas on how to figure out what is wrong?

    Added info, I can telnet from inside the box to port 80 and 110 of the first IP but not the second.
    Last edited: Aug 29, 2009
  2. id10t

    id10t Member

    Which distro? Sounds like a network config issue... post your output of ifconfig -a and route -n
  3. Craig

    Craig New Member

    Thanks for replying,

    Distro is Centos 5.3

    ifconfig -a
    eth0      Link encap:Ethernet  HWaddr 00:15:C5:E6:BC:AD
              inet addr:  Bcast:  Mask:
              inet6 addr: fe80::215:c5ff:fee6:bcad/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:74109 errors:0 dropped:0 overruns:0 frame:0
              TX packets:72796 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:18727615 (17.8 MiB)  TX bytes:7155738 (6.8 MiB)
              Interrupt:169 Memory:f8000000-f8012100
    eth1      Link encap:Ethernet  HWaddr 00:15:C5:E6:BC:AF
              inet addr:  Bcast:  Mask:
              inet6 addr: fe80::215:c5ff:fee6:bcaf/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:2940 errors:0 dropped:0 overruns:0 frame:0
              TX packets:79 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:246290 (240.5 KiB)  TX bytes:10610 (10.3 KiB)
              Interrupt:169 Memory:f4000000-f4012100
    lo        Link encap:Local Loopback
              inet addr:  Mask:
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:2874 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2874 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:3944310 (3.7 MiB)  TX bytes:3944310 (3.7 MiB)
    sit0      Link encap:IPv6-in-IPv4
              NOARP  MTU:1480  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
    route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 eth0   U     0      0        0 eth1     U     0      0        0 eth1         UG    0      0        0 eth0
    The "route" looks strange but I don't know for sure and if it is, I don't know how to fix it. :(

    I checked and compared ifcfg-eth0 and ifcfg-eth1 and noticed that ifcfg-eth1 didn't have the gateway specified whereas ifcfg-eth0 did. I added the gateway to ifcfg-eth1 and issued an
    ifdown eth1
    and then
    ifup eth1
    but now the system is unresponsive. :-(
    Last edited: Aug 30, 2009
  4. Craig

    Craig New Member

    I went to the data center and rebooted the system and did a manual initialization and said "N" to starting the network during boot.

    I then deleted the eth1 configuration and recreated it, using NetworkManager but still, the second IP seems to be unusable. :(
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    And you are sure that the provider that assigned you the IP routed it to your server?
  6. Craig

    Craig New Member

    That's a good question Till, I don't know right now. I should find out tomorrow though.

    I was hoping I could find a way to identify whether or not the problem was internal, i.e. network configuration of the server box or external.

    Is there anything that can be learned by looking at the eth0 and eth1 configurations?

    If so,
    # Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
    # Please read /usr/share/doc/initscripts-*/sysconfig.txt
    # for the documentation of these parameters.
    I just checked eth1 again and now it doesn't have the gateway listing. I have been configuring the two adapters using the "NetworkManager" GUI in Centos and it seems like somehow the configurations are changing slightly depending on which interface is brought up, when and what order.

    I'm lost. :(
    Last edited: Aug 30, 2009
  7. Craig

    Craig New Member

    New info.

    I connected the line going to eth1 to a different box, actually a Windows laptop running wireshark and I could see connection attempts from a third box I was using to try to telnet to various ports.

    So, it seems like it isn't an external routing problem but instead, an internal configuration problem.

    Should configuring a box with two nic cards and two IPs be this difficult? In the past, I even just used the NetworkManager and everything worked without a problem.
  8. id10t

    id10t Member

    Well, you only need the one gateway so that explains why it locked when you added one for your .115.x network.

    Your ifconfig and route output looks OK to me, but then I've not used a rh based distro since '99...

    Got iptables doing anything? Perhaps its being blocked there...
  9. Craig

    Craig New Member

    Regarding Iptables, I am running Bastille, as part of ISPConfig and using that as I always have in the past.

    I found something interesting though, if I ifdown eth0 and allow eth1 to use its gateway, eth1 works as it should. If I ifdown eth1 and allow eth0 to use its gateway, it works too as expected. The problem comes when trying to force eth1 to use eth0's gateway.

    Another thing I found, although I don't know the exact topology of the external network, is that the external network routing changed recently and that even though the private addresses I have to work with, and appear to be on the same network, they are actually on different networks coming through different switches.

    Is it even possible for packets to come in on one network and go out through another??

    I think what I am going to do is ask the network admin to route both public IPs through the same internal network and then run both to one network adapter. That seems a LOT easier to work with than what I'm trying to deal with now.

    Of course it would help if I knew more than just enough to be dangerous. :D

    One other strange thing, I have another thread here, in the scripting forum, where I was having problems with PHP's "gethostbyname()" method. When I tried the test of only enabling one adapter at a time, that problem went away. When I tried to enable both adapters again, the problem came back!

    Some days it just doesn't pay to wake up in the morning! ;)
  10. Craig

    Craig New Member

    I found the answer!!!

    Not surprising, I found it right here at HowToForge.

    When I searched, I just didn't use the right terminology.

    Somehow I came across a thread on basically the exact same issue, two public IPs and two NICs,

    There are a couple of excellent resources listed in topdog's last post that although having more information than I would ever hope to need, probably is exactly what I need.
  11. Craig

    Craig New Member

    Multiple NICs, Multiple IPs, Multiple Networks on one box

    That was so easy!!!!

    To save someone else the headache, three days lost time and fear of losing my job, not to mention my mind, here's how I did it: (Anyone who has corrections to make, just post it and I'll update this)

    First, although it is unlikely your 'Nix box does not have the capability to do this, it is a good idea to check to make sure.

    At the command prompt execute:
    cd /etc/iproute2
    If you end up in the expected directory, this will likely work for you. If not, google "iproute2" and you should find what you need to enable it.

    The situation is that you've got two, or more network cards. How do you make sure that the networks connected to each don't clash while at the same time make sure that packets received on network "0" are replied to using network "0" and same for network "1", "2" and so on?

    The scripts/files we will be working with are:
    /etc/sysconfig/network-scripts/ifcfg-eth[ADAPTER ID]
    /etc/sysconfig/network-scripts/route-eth[ADAPTER ID]
    /etc/sysconfig/network-scripts/rule-eth[ADAPTER ID]

    The last three are create for each adapter with the "ADAPTER ID" being the number of the adapter.

    To begin, we set up configurations for each NIC/IP/eth[ADAPTER ID]
    They are found in
    They are named "ifcfg-eth0", "ifcfg-eth1" and so on and beginning at 0 and increasing up to the number of NICs you have, minus 1.

    First though, you will need to know the MAC addresses of your Network Interface Cards (NIC). Unfortunately, all the common methods for determining the MAC address of the adapters on your system assume the network is already set up.

    One cheap and dirty way is to install "NetworkManager" only long enough to to get the MAC address of each of the cards and then uninstall it and forever wipe it from your system.

    Note: In this walk-through I use brackets and capitalized names to indicate what the contents of the bracket should be replaced with. Throughout this walk-through, all the bracketed terms are consistent so if you see [GATEWAY] in the ifcfg-eth[ADAPTER ID] section, you can know that the same value is used in the "route" section for the same NIC/IP/eth[ADAPTER ID].

    Use whatever editor you prefer although I prefer "nano" and so will use that for this walk-through,
    nano /etc/sysconfig/network-scripts/ifcfg-eth0
    creates the first configuration script and its contents are :
    # Adapter id
    DEVICE=eth[ADAPTER ID, 0 -> ~, ex. eth0, eth1, eth2 ...]
    # Adapter type
    # Run at boot time
    # Could be DHCP, "static" or "none" but "static" or "none" if you are reading this.
    # MAC Address of the adapter.
    # Replace the value shown with 
    # your NIC's MAC address
    # and "BROADCAST" will be provided by your
    # ISP or network administrator
    Once you have saved that, by hitting [ctrl-x] -> [y] -> [enter] in the nano editor, connect the network cable to the card, if not already connected and type
    ifup eth0
    That initializes the network interface identified as eth0. You may want to wait a couple of minutes before testing it because it can take some time for it to actually come up and definitely wait for a command prompt while it tries to connect to whichever network it was told to.

    Then try making a connection to test it out either from within the box you are working on or preferably, from outside so you can test everything at one time.

    There are dozens of ways to test the connection including "ping", which I do NOT suggest but instead, prefer trying to telnet to a service I know should be running for a more realistic test. So:
    If you use "80" for "SERVICE PORT" it will try to connect to an http service on port 80 at the IP being tested.

    Depending on what the server is set up to reply with when an IP based request is made, you may get a page of html, a page of stuff that flies by leaving you with an empty terminal screen or just about anything. But, you will definitely know that it is working because it won't time out.

    To terminate the test cleanly, type
    and hit enter.

    If you want to take that interface down for some reason, just type
    ifdown eth[ADAPTER ID]
    and it will close. The "I" and "F" in "ifdown" and "ifup" for that matter, stands for "InterFace".

    This is useful for testing interfaces individually without having to worry about conflicts. Just make sure that you don't issue an ifdown on whatever IP you are connected to via SSH unless you are near the box you are working on, for obvious reasons. ;)

    Similarly, all interfaces can be restarted at the same time by issuing the command:
    service network restart
    but I don't suggest using that if you are remoting in in case there is an error and you lose the ability to connect at all. Hosting companies usually charge you money to re-setup your network if you take it down and can't get it back up so be careful.

    Now, before you start configuring other interfaces, we will configure the routing and rules for that routing for the first NIC. This is MUCH easier than it sounds once you have seen it done.

    There are two things we need to tell the system so that it knows what to do and when. The first is the route that traffic to and from a given interface should take and the second, when that route should be used.

    Although there are a LOT of routing and rules one can apply, all we care about at this point is to make sure that packets that come in on a given interface for a given IP go out the same interface for the same IP.

    To do this next part, we will do it in two steps. The first step, manually execute each instruction on the command line and then after making sure they do what they were supposed to do, we can commit them to initialization scripts so that the will be executed every time the server is restarted or a given interface is brought up after being down.

    In practice though, once the first set of scripts are tested for the first interface, the rest can usually be easily copied from the original and then edited to add the interface specific elements.

    So now at this point we have a working NIC/IP/Interface and it is time to set routing for it. We need to set two types of routing, to the interface and from the interface.

    Also, we need somewhere to tell the system to look for this information and we do that in /etc/iproute2/rt_tables. But, don't edit it directly. We will pipe what we want into it.

    What this routing table holds for each contained route is a unique number, [NUMBER] and a table name, [TABLE NAME]. The number indicates to the system which order the tables should be checked for routing a given packet.

    If you execute
    cat /etc/iproute2/rt_tables
    you will see that some default routing tables already exist and since their numbers are high, they are queried after anything we will be adding here.

    Also, in these examples, if you see quotation marks in the "code" section, they must be added on the command line also. Labels in brackets should be replaced, including the brackets, with whatever information the label says it should contain.

    To add a table pointer for the NIC we just set up, enter:
    echo "[NUMBER] [TABLE NAME]" >> /etc/iproute2/rt_tables
    "TABLE NAME" can be whatever you want, just so that it is unique and so that you make sure you use it for the rest of the commands/scripts that apply to a given NIC/IP/eth[ADAPTER ID].

    As mentioned, we will be issuing the commands to perform the configuration manually, to test them and then, committing them to a script after testing. (X) indicates the number of the interface we are working with and is the same as the number used above when configuring the NIC itself.

    So at the command line type:
    ip route add [NETWORK]/24 dev eth[ADAPTER ID] src [IP ADDRESS] table [TABLE NAME]
    That tells the system that packets that come from "src" [IP ADDRESS] go to the adapter [ADAPTER ID].

    Now, we tell it the reverse, where do packets from that adapter go:
    ip route add default via [GATEWAY] dev eth[ADAPTER ID] table [TABLE NAME]
    If you think it looks a lot like a default gateway statement, it is. But, only by using iproute2 can one define different gateways for different NICs and expect things to work.

    So we have the routing for the first adapter set up and so now we will set up rules for when that routing should be used and here again, two rules will be create, one for packets to the adapter and one for packets from it.

    At the command line type:
    ip rule add from [IP ADDRESS]/32 table [TABLE NAME]
    The "/32" restricts the rule to just that address. You could change that numer to increase the range of IPs affected but that is out of scope for this walk-through.

    What that says is that traffic from [IP ADDRESS] should have the routing defined in [TABLE NAME] applied to it.

    That may seem redundant but rules can be used to specify all sorts of cool things, such as types of service which would allow you to route differently depending on what service was being accessed. It is just that we only need a very simple rule but it is a rule we need none the less.

    To specify a rule for packets coming from the interface, we execute
    ip rule add to [IP ADDRESS] table [TABLE NAME]

    To make sure that the commands have taken affect and aren't sitting in a cache somewhere, execute:
    ip route flush cache
    While we have been entering these commands, they have been taking effect as soon as the command was entered, or the "flush" command executed so whatever method you used to test the interface before, do it again now to make sure it still works.

    But, don't issue an ifdown[NUMBER]/ifup[NUMBER] or restart the network because the commands entered as they have been only exist in memory/system and are gone on a restart.

    To make them executed automagically on a reboot, network restart or ifdown/ifup, we will create network scripts and include the information into them.

    The scripting "engine" is very simple. The routing script engine basically takes each line and adds "ip route add " to the beginning of it and then executes it so, to create the content for the scripts you can simply copy each command after the default part that is added by the scripting engine.

    First, the routing script:
    nano /etc/sysconfig/network-scripts/route-eth[ADAPTER ID]
    [NETWORK] dev eth[ADAPTER ID] src [IP ADDRESS] table [TABLE NAME]
    default via [GATEWAY] dev eth[ADAPTER ID] table [TABLE NAME]
    And for the "rule" script:
    nano /etc/sysconfig/network-scripts/rule-eth[ADAPTER ID]
    from [IP ADDRESS]/32 table [TABLE NAME]
    to [IP ADDRESS] table [TABLE NAME]
    There, the first NIC/IP is fully configured. You can now execute:
    ifdown eth0
    ifup eth0
    and test to make sure everything still works.

    From here on out, it is the same process over and over again to configure any other NICs/IPs you have. Whether you choose to do that step-by-step or use copy-n-paste is up to you although step-by-step is more likely to help you remember how to do it again in the future.

    Either way, good luck and have fun.
    Last edited: Sep 1, 2009
  12. mr_insane

    mr_insane New Member

    Thank you very much mannnnnnnn
    you saved me time
  13. gurukos

    gurukos New Member

    Dear people,
    I followed this guide but unfortunately doesn't work for me...
    I installed Centos 5.6 with 2 nics, set them up on 2 different networks, made the routes etc, but only one works (reaches out)...

    Does anyone have some time an d will to help me, pleaaaase...? I 've lost my mind with that.

    When i got time i 'll post a diagram of what i want to establish so if somebody can help.

    Thank you in advance

    Last edited: Jun 10, 2011

Share This Page