Added Dedicated IP - Domain Times Out

[monkey64]

I wanted to put a domain it on its own dedicated IP as I have an SSL Certificate I need to use.

I contacted my host who sold me a new IP and I changed my zone records to reflect the IP change. Shortly after that, I got the blue-ish WHM splash screen which said "You are seeing this because ..." Some hours later, I just get the "The connection has timed out" Firefox message and the site does not load.

I should point out that I have done this before without any issues and this is the second static IP I have added to WHM. The IP is shown in WHM and the changeover from old to new goes without a hitch. Apparently...

I checked my DNS and Zone settings and they are similar my other site on a dedicated IP (obviously with a different IP). The IP is: 37.128.131.7

Any ideas?

 

[cPanelTristan]

Does the new IP ping from your local system when trying it?

It does not ping for me:

# ping 37.128.131.7
PING 37.128.131.7 (37.128.131.7): 56 data bytes
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 d463 0 0000 2e 01 fe0a 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 0
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 050f 0 0000 2e 01 cd5f 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 1
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5700 0 0000 2e 01 7b6e 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 2
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 8e11 0 0000 2e 01 445d 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 3
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 1842 0 0000 2e 01 ba2c 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 4
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 ca39 0 0000 2e 01 0835 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 5
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 0d64 0 0000 2e 01 c50a 10.1.7.179 37.128.131.7

Request timeout for icmp_seq 6
92 bytes from fw-tv2-b2.memset.net (89.151.85.231): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 0a29 0 0000 2e 01 c845 10.1.7.179 37.128.131.7

^C
--- 37.128.131.7 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss

When an IP isn't pinging, it's typically an issue with the network or ipaliases. Check if the IP shows in ifconfig:

ifconfig | grep 37.128.131.7

If it does there, try restarting ipaliases:

/etc/init.d/ipaliases restart

Otherwise, try restarting both the network and ipaliases:

/etc/init.d/network restart
/etc/init.d/ipaliases restart

If you still cannot ping it, contact your IP provider. Something isn't setup right with the IP. You might have the wrong netmask listed or they might not have properly routed it to your machine.

Of note, please do not try to ping the IP on the server itself. The IP almost always pings on the server it's been added to, even when it doesn't ping from another system trying to reach it.

Thanks!

 

[monkey64]

Came to it this morning and it sprang into life on that IP!
Perhaps it took longer to propogate than usual. Still, 10 hours is excessive...

Problem solved, thanks Tristan

 

[NetMantis]

Monkey64, just so you know and for your information, the problem you described with your new IP address actually had nothing to do with either the IP address itself or changing the information in your DNS zone for your domain either. In fact, I would wager fairly safely that your IP address as well as the domain you pointed to it were both actually working 100% perfectly the whole entire time without you even realizing it!

What you experienced is very common and normal and is actually caused by the route caching in your own computer at home or your ISP (they can do this too) service at home. Basically what happens is your computer remembers where it has been and how to get there and when you attempt to go back to someplace on the net that you have been before, your computer uses the IP information it remembered previously instead of doing an actual real lookup of the correct IP address on the internet. That works fine most of the time but doesn't work so much when the IP address for a site you recently visited has also recently changed. In that case, your computer tries to go to the wrong IP address and as a result, the web site is of course not there!

Meanwhile, the rest of the world who much of whom have never visited your site previously find that they can reach the same site no problems whatsoever ---- really leaving mainly you alone not able to see the site!

Eventually, the cache in your computer or ISP expires (usually no more than 24 hours), and at that point your computer is forced to make a new inquiry from the internet for IP information for the sites you are trying to reach and at that point, you catch up to the rest of the world and begin to see what everyone else was already seeing!

Welcome to the wonderful world of DNS resolution!

But anyway, yes this is all perfectly normal ..... and no, your site probably wasn't down at all!

 

[cPanelTristan]

No, the domain and IP weren't working 100% of the time and it wasn't caching. The IP itself was timing out entirely with 100% packet loss if you look at my results above. You don't get that when it's caching. Additionally, I couldn't have possibly been cached, because I'd never viewed the site or IP before.

 

[NetMantis]

Actually I ran my own pings and network tests prior to you posting your reply and before I finally replied and I was able to connect to the IP with no trouble whatsoever so it was indeed actually working at the time.

One major difference however between you checking and myself checking the same IP is that neither my computer nor my ISP has any route caching and always reads resolutions live from the internet (setup that way deliberately) so any changes anywhere on the internet on any network is immediately available to me to view instantly without any kind of delay.

It's not just simply previous visit caching alone that is the issue, there is a flip side to that coin and that being that the routing information for new IPs also has to be recognized by your ISP before you can reach it and if it isn't pulling that information in live real time (most don't and are on a delay), it might take a little while for you to be able to see newly activated IPs on the internet --- that's really the same as what I spoke of before with previous visit caching but instead has to do more with your ISP than your own computer but very similar.

Your ISP would however eventually get the information on the new IP and then you would be able to connect again. Other ISPs might get the information immediately, others might actually take longer than yours to know how to connect to the new IP.