Csdrhrt

I bought a server with 4 ip addresses that need to be configured manually

• yy.zz.159.7/23 (gw yy.zz.156.1)


• yy.zz.159.8/23 (gw yy.zz.156.1)


• yy.zz.159.13/23 (gw yy.zz.156.1)


• 
  xxx.144.29.243 (gw xxx.144.28.1) main ip address

I added a subinterface ifcfg-eth0:1/2/3 for each one and this is my route table :

Kernel IP routing table Destination     Gateway         Genmask        Flags Metric Ref    Use Iface

xxx.144.28.0    0.0.0.0         255.255.254.0   U     0      0        0 eth0

yy.zz.156.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0

169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

0.0.0.0         yy.zz.156.1     0.0.0.0         UG    0      0        0 eth0

0.0.0.0         xxx.144.28.1    0.0.0.0         UG    0      0        0 eth0

When i ping on the added ip addresses i get TTL expired in transit message, from my researches i think there is an infinite loop in my route table, can anyone please point out the problem here?

I guessed your addresses, ran a traceroute (well, mtr) to all four of them, and while it shows a loop, it's ping-ponging between two addresses that look very much like a point-to-point link between two routers. The same loop also happens when trying to ping/traceroute various other addresses from the subnet, so it's probably "normal" for not-yet-assigned addresses at this provider.

From that I would guess that the problem is with your server provider – they don't have the correct routes pointing the extra addresses to your server.

Meanwhile, your own routing table seems normal, and isn't missing anything obvious. Although that's not the whole routing table – there are entries that the obsolete route command doesn't see. If you directly assign an IP address to an interface (such that it shows in ip addr), this creates a hidden /32 route that tells the OS to always consume the packets and this takes priority over regular subnet routes.

So if you have verified that the addresses are in ip addr, the loop generally won't be your fault.

What you should check now is whether you even receive the packets at all. Use a packet capture tool such as tcpdump:

tcpdump -n -i eth0 "icmp"

While it's running try to ping the server's addresses. If you had a loop, tcpdump would show a storm of "ICMP Echo" packets for every single ping attempt. On the other hand, if it doesn't show any echo packets at all, then the problem is with your ISP (i.e. the server hosting company) – they haven't actually routed the addresses to your server correctly.