1

i'm using openstack, but i think this is a more general problem. Actually i've a dedicated which comes with 1 ip address, i bought another one, and added using openstack's nova-manage cli.

So now this is what i get

$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:48:fc:4c:92 brd ff:ff:ff:ff:ff:ff
    inet 188.165.x.x/24 brd 188.165.225.255 scope global eth0
    inet 94.23.x.x/32 scope global eth0
    inet6 fe80::230:48ff:fefc:4c92/64 scope link
    valid_lft forever preferred_lft forever

so it seems that both ip are binded to eth0, the problems is that i don't receive packets with destination set to 94.23.x.x, when i run tcpdump -i eth0 i see packets to both ip, when i run tcpdump -p -i eth0, so not in promiscous mode, i see packets to only the first ip, so dnat and what i need won't work.

If i try to ping 94.23.x.x on the host works fine, from outside gives timeout.

Any idea?

Best Regards

EDIT:

$ ip route
default via 188.165.x.254 dev eth0  metric 100 
188.165.x.0/24 dev eth0  proto kernel  scope link  src 188.165.x.x 
192.168.3.0/24 dev br100  proto kernel  scope link  src 192.168.3.1 
192.168.4.32/27 dev br100  proto kernel  scope link  src 192.168.4.33 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1
phemmer
  • 5,909
  • 2
  • 27
  • 36
alex88
  • 148
  • 9

2 Answers2

3

You have your second IP set up with a /32 netmask. which will pretty much prevent it from doing anything unless you're trying to host it as a loopback (..and your upstream is routing it to you).

Your provider should have given you a subnet mask with the second address you purchased. When you get it set up then your system should be able to ping other hosts in that 94.23.x.x subnet.

rnxrx
  • 8,143
  • 3
  • 22
  • 31
  • Nope, I have to use it as /32 because it's routed to my server, this is my hosting provider guide about alias ip http://help.ovh.com/IpAlias – alex88 May 21 '12 at 22:26
  • 1
    @alex88 no, rnxrx really is correct. A `/32` netmask will drop traffic because of reverse path filtering. Also you cannot route the traffic back out as with a `/32` netmask you cant reach external machines. Also that guide you linked is general purpose, and seems to be written to cover adding IPs in general, not your exact case, and so should be taken as such. – phemmer May 21 '12 at 23:17
  • 1
    @patrick time ago i've set with different netmask and they've closed server for not needed arp packets.. The additional ip is just to make machine respond to request coming to thAt ip, not reach external machines using that ip as source.. – alex88 May 21 '12 at 23:22
  • 1
    @Patrick I don't think that reverse path filtering is involved here, because the default route goes out eth0. In any case, the filtering is on the source IP, not the destination IP. – mgorven May 21 '12 at 23:59
  • @alex88 In this case the second IP address is not alias because the primary address is from diferrent subnet. – 0xFF May 22 '12 at 05:15
  • @0xFF so i should setup using ifconfig eth0:0 instead of just an ip addr add? btw, i have other servers with the same ip configuration and they works, i just wanted to debug why this isn't working – alex88 May 22 '12 at 06:56
  • @alex88 You should add the second address like this (example): ip a dev eth0 22.33.44.55/24 You can use "ifconfig" instead of "ip". Remember to use correct netmask! /32 in your case is incorrect. Could you show IP configuration from Your other servers? We could compare it. – 0xFF May 22 '12 at 09:51
  • @0xFF this http://pastebin.com/YGr9YDi6 the only different is that it uses a bridge, but trust that this one works as it respond to ping – alex88 May 22 '12 at 11:40
0

Can you check, what is destination MAC address on packets you receiving in tcpdump in promiscuous mode?

If it's destination MAC is not correct: 00:30:48:fc:4c:92 - you have an IP conflict and should contact your provider.

If it's correct - you have problems on your side, e.g. wrong NIC, ip, kernel settings, maybe incorrect netmask or routing problems.

DukeLion
  • 3,259
  • 1
  • 18
  • 19
  • You're right, check this paste http://pastebin.com/10R7xngE the mac is different, that's why it drops the packets? can be that? – alex88 May 22 '12 at 07:06
  • Ok, it's an IP conflict - ip address is used somewhere else. You provider need to resolve it, or give you another IP address. – DukeLion May 22 '12 at 07:12
  • i'm not sure about that, i have another server with eth0 with mac 90:e6:x:x:x:x which is on a bridge (vmbr0), the bridge uses the same mac as eth0 and i've added a vmbr0:0 ip, i can see it correctly receive packets to that ip, but the packets has a different mac as destination 02:00:x:x:x:x and they're not dropped. – alex88 May 22 '12 at 07:15
  • Hmm, sounds a bit strange to me. But regardless, default behaviour of ethernet NIC is to drop all packets not destined to it's mac address. Promiscuous mode allows it to accept all packets. Also it will work on bridge interface, since bridge interfaces should be in promiscuous mode to work. – DukeLion May 22 '12 at 07:19
  • i've tried to use http://pastebin.com/TCQa1FCu and set ifconfig eth0 promisc, still no logs, packets seems to be dropped – alex88 May 22 '12 at 07:25
  • You were right, i've contacted ovh, changed mac and now it works! – alex88 May 23 '12 at 17:02