IP alias nem megy bizonyos IP-kkel

Hálózatok általános

Sziasztok!

Egy kis segítséget szeretnék kérni, már kínomban nem tudok mit kitalálni.
Adott egy ISP-nél egy LAN, amin van pár PC és egy címtartományt ide route-ol az ISP. Az egyik pc ki fog dőlni, .163-as IP-vel és ezt az IP-t szeretném egy másik PC-re a sajátja mellé felhúzni. Az a problémám, hogy ahogy átteszem az IP-t az új PC-re, onnantól kezdve nem válaszol se pingre, se semmire. Ha egy olyan IP-t vetetek fel az új PC-re, amin eddig nem volt semmilyen eszköz, akkor semmi baj, minden megy szépen. Ezt csinálom:

régi pc-n:
ifdown eth1

új pc-n:
ip addr add x.x.x.163/28 dev eth1 label eth1:163

Ezeket néztem meg:
- ARP-re válaszol az új pc, mac address stimmel
- ARP-re nem válaszol a régi pc
- ifconfig-gal eljátszva a fentieket ugyanaz az eredmény
- új PC-n tcpdump mutatja a bejövő icmp csomagot, de választ már nem mutat rá
- iptables minden tábla flush, majd raw tábla prerouting láncába és a filter tábla input láncába tettem egy mindent beengengedő, icmp-re szűkített szabályt, hogy megnézzem, hány csomagot kap el: semmi se megy át rajtuk
- ip route flush cache nem hatásos

Nem tudom megcsinálni, hogy huzamosabb ideig rajta hagyjam az új pc-n a szóban forgó IP-t, mert szolgáltatások futnak rajta és megbillent a megrendelő, ha nem mennek. Debian wheezy, 3.2.51, ha számít valamit. Kérek szépen ötleteket, hogy mitől lehet ez és hogyan lehet megszüntetni.

Köszi előre is: lukit

  • 6038 megtekintés

( wildy | 2014. 08. 19., k – 16:17 )

Mindket IP cimnel (mukodo/uj, ill. nem mukodo/atvett esetben) ugyanaz a subnet/netmask van beallitva? Ha van bejovo forgalom (azaz nem a router / switch ARP cache-eben ragadt be a korabbi MAC), akkor ugy hangzik, mintha rp_filter=1 lenne, de annak illene bekavarnia mindket esetben. 'ip ro get IP_cime_a_gepnek_ahonnan_pingelsz' milyen iface-t mutat?

( athila v | 2014. 08. 19., k – 16:23 )

Szerintem szólj a szolgáltatónál, hogy amikor átrakod az IP-t másik gépre, akkor töröljék a routerükben az ARP cache-ből a bejegyzésedet, illetve, ha van port-security konfigolva a switchportodon, akkor azt is.


1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:15:17:b5:e1:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.195.13/24 brd 192.168.195.255 scope global eth0
inet6 fe80::215:17ff:feb5:e138/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:15:17:b5:e1:39 brd ff:ff:ff:ff:ff:ff
inet x.x.x.165/28 brd x.x.x.175 scope global eth1
inet x.x.x.174/28 scope global secondary eth1:174
inet6 fe80::215:17ff:feb5:e139/64 scope link
valid_lft forever preferred_lft forever

default via x.x.x.161 dev eth1
x.x.x.160/28 dev eth1 proto kernel scope link src x.x.x.165
192.168.195.0/24 dev eth0 proto kernel scope link src 192.168.195.13

Lehet,hogy hülyeség,amit írok,de ez a sor,mintha hiányozna a routing table-ből:
x.x.x.160/28 dev eth1 proto kernel scope link src x.x.x.174

Tudom és látom,hogy ott van a /28 az elején de az src résznél nincs ott a .174
és ugyanez a .163-ra.

Másik oldalról a gépek saját switch-re vaqgy szolgáltatói switch-re csatlakoznak?
Ha szolgáltatóira,akkor kérdezz rá légyszi,hogy egy porton hány IP-t engednek át.

Ha nem megy, akkor írj privátba és segítek megnézni szívesen.

SZVSZ inkabb az a problema, hogy azonos subneten van minden cime igy a kimeno valaszcsomagok a .165 forrascimmel mennek ki. Egy uj route szabaly onmagaban nem oldana meg a problemat (csak tovabbi kavarodast okozhatna az, hogy melyik kimeno csomag melyik IP cimrol menne). Ahhoz, hogy a bejovo es kimeno cimek stimmeljenek conntrack es NAT is kell. CONNMARK kornyeken erdemes nezelodni.