70203
Sep 29, 2008, updated at Sep 30, 2008 (UTC)
3600
7
0
Einbahnstraße kein echo reply nach request
Folgendes Problem: Auf ein echo request (gesendet von Server1) an eine IP eines Server2, erfolgt keine echo reply, obwohl der request im System eintrifft.
Hallo Zusammen,
habe ein wirklich fieses Problem auf der Arbeit, welches ich euch gerne erläutern würde, da ich hoffe, das jemand von Euch dazu etwas vielleicht einfällt.
Folgendes Problem: Auf ein echo request (gesendet von Server1) an eine IP eines Server2, erfolgt keine echo reply, obwohl der request im System eintrifft.
Dies Verhalten besteht auch bei geleerten ip-table-chains (shorewall clean).
Ping lokal auf den virtuellen Interfaces auf Server2 funktioniert erwartungsgemäß.
Ein cat /proc/sys/net/ipv*/icmp_echo_ignore_all auf Server2 ergibt 0.
Danke im Voraus für eure Mühe und die besten Grüße
Benjamin Casa
Folgend ein paar Auszüge von Konfigurationsdateien und Logs:
interfaces server2
ifconfig von server2
route -n server2
ping von Server1
// tcpdump von Server2
habe ein wirklich fieses Problem auf der Arbeit, welches ich euch gerne erläutern würde, da ich hoffe, das jemand von Euch dazu etwas vielleicht einfällt.
Folgendes Problem: Auf ein echo request (gesendet von Server1) an eine IP eines Server2, erfolgt keine echo reply, obwohl der request im System eintrifft.
Dies Verhalten besteht auch bei geleerten ip-table-chains (shorewall clean).
Ping lokal auf den virtuellen Interfaces auf Server2 funktioniert erwartungsgemäß.
Ein cat /proc/sys/net/ipv*/icmp_echo_ignore_all auf Server2 ergibt 0.
Danke im Voraus für eure Mühe und die besten Grüße
Benjamin Casa
Folgend ein paar Auszüge von Konfigurationsdateien und Logs:
interfaces server2
root@server2:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address xx.xx.164.82
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
gateway xx.xx.164.81
dns-search domain.tld
auto eth0:0
iface eth0:0 inet static
address xx.xx.164.83
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
auto eth0:1
iface eth0:1 inet static
address xx.xx.164.84
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:2
iface eth0:2 inet static
address xx.xx.164.85
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:3
iface eth0:3 inet static
address xx.xx.164.86
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:4
iface eth0:4 inet static
address xx.xx.164.87
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:5
iface eth0:5 inet static
address xx.xx.164.88
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:6
iface eth0:6 inet static
address xx.xx.164.89
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
#auto eth0:7
iface eth0:7 inet static
address xx.xx.164.90
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
auto eth0:8
iface eth0:8 inet static
address xx.xx.164.91
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
auto eth0:9
iface eth0:9 inet static
address xx.xx.164.92
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
auto eth0:10
iface eth0:10 inet static
address xx.xx.164.93
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95
auto eth0:11
iface eth0:11 inet static
address xx.xx.164.94
netmask 255.255.255.240
network xx.xx.164.80
broadcast xx.xx.164.95ifconfig von server2
root@server2:~# ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.82 Bcast:xx.xx.164.95 Maske:255.255.255.240
inet6 Adresse: fe80::xxxx:xxxx:xxxx:c00/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:98353257 errors:0 dropped:0 overruns:0 frame:0
TX packets:6732426 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:2816903543 (2.6 GiB) TX bytes:1027636319 (980.0 MiB)
Interrupt:22 Basisadresse:0x4c00
eth0:0 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.83 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
eth0:1 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.84 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
eth0:8 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.91 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
eth0:9 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.92 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
eth0:10 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.93 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
eth0:11 Protokoll:Ethernet Hardware Adresse 00:xx:xx:xx:xx:00
inet Adresse:xx.xx.164.94 Bcast:xx.xx.164.95 Maske:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:22 Basisadresse:0x4c00
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16415596 errors:0 dropped:0 overruns:0 frame:0
TX packets:16415596 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:3954625213 (3.6 GiB) TX bytes:3954625213 (3.6 GiB)route -n server2
root@server2:/etc/network# route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
xx.xx.164.80 0.0.0.0 255.255.255.240 U 0 0 0 eth0
0.0.0.0 xx.xx.164.81 0.0.0.0 UG 0 0 0 eth0ping von Server1
[root@server1:~]$ for i in 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 ; do ping xx.xx.164.$i -w 1 ; done
PING xx.xx.164.81 (xx.xx.164.81) 56(84) bytes of data.
64 bytes from xx.xx.164.81: icmp_seq=1 ttl=252 time=10.0 ms
--- xx.xx.164.81 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.038/10.038/10.038/0.000 ms
PING xx.xx.164.82 (xx.xx.164.82) 56(84) bytes of data.
64 bytes from xx.xx.164.82: icmp_seq=1 ttl=60 time=9.77 ms
--- xx.xx.164.82 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.773/9.773/9.773/0.000 ms
PING xx.xx.164.83 (xx.xx.164.83) 56(84) bytes of data.
64 bytes from xx.xx.164.83: icmp_seq=1 ttl=60 time=9.72 ms
--- xx.xx.164.83 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.729/9.729/9.729/0.000 ms
PING xx.xx.164.84 (xx.xx.164.84) 56(84) bytes of data.
--- xx.xx.164.84 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING xx.xx.164.85 (xx.xx.164.85) 56(84) bytes of data.
--- xx.xx.164.85 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.86 (xx.xx.164.86) 56(84) bytes of data.
--- xx.xx.164.86 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.87 (xx.xx.164.87) 56(84) bytes of data.
--- xx.xx.164.87 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.88 (xx.xx.164.88) 56(84) bytes of data.
--- xx.xx.164.88 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.89 (xx.xx.164.89) 56(84) bytes of data.
--- xx.xx.164.89 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.90 (xx.xx.164.90) 56(84) bytes of data.
--- xx.xx.164.90 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.91 (xx.xx.164.91) 56(84) bytes of data.
--- xx.xx.164.91 ping statistics --- [11:54]
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.92 (xx.xx.164.92) 56(84) bytes of data.
--- xx.xx.164.92 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.93 (xx.xx.164.93) 56(84) bytes of data.
--- xx.xx.164.93 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.94 (xx.xx.164.94) 56(84) bytes of data.
--- xx.xx.164.94 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
PING xx.xx.164.95 (xx.xx.164.95) 56(84) bytes of data.
--- xx.xx.164.95 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms// tcpdump von Server2
root@server2:~# tcpdump -n -i eth0 | grep xx.xx.52.73
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:53:47.446792 IP xx.xx.52.73 > xx.xx.164.82: icmp 64: echo request seq 1
11:53:47.446826 IP xx.xx.164.82 > xx.xx.52.73: icmp 64: echo reply seq 1
11:53:48.450626 IP xx.xx.52.73 > xx.xx.164.83: icmp 64: echo request seq 1
11:53:48.450657 IP xx.xx.164.83 > xx.xx.52.73: icmp 64: echo reply seq 1
11:53:49.454626 IP xx.xx.52.73 > xx.xx.164.84: icmp 64: echo request seq 1
11:53:56.506412 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 1
11:53:57.507129 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 2
11:53:57.514440 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 1
11:53:58.515070 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 2
11:53:58.522185 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 1
11:53:59.523003 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 2
11:53:59.530211 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 1
11:54:00.530997 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 2
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 98055
Url: https://administrator.de/contentid/98055
Printed on: April 23, 2024 at 07:04 o'clock
7 Comments
Latest comment
Erstmal solltest du für uns alle klären was es mit den virtuellen Sub-Interfaces auf der Maschine auf sich hat ???
Wollen wir mal wieder ein bischen raten hier...
Vermutlich machst du 802.1q VLAN Tagging auf diesem physischen Rechner Interface wie z.B. hier beschrieben:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832/4
Damit wäre aber deine IP Adressierung komplett falsch und unsinning. Denn bei einer 28 Bit Subnetzmaske kannst du maximal 14 IP Hostadressen in einem Netzwerk unterbringen.
Bei dir sind aber alle Subinterfaces in einem einzigen IP Netzwerk, nämlich immer im .80er Netz was IP technisch gesehen vollkommen falsch ist.
(Unter der Annahme das das von dir gepostete xx.xx immer die gleichen Ziffern darstellt !??)
Alle Subinterfaces müssen aber in einem separaten IP Netz betrieben werden !!
Abgesehen davon benötigst du dann auch einen 802.1q tagged Link auf der Switchseite der den Rechneranschluss wieder in diese VLANs auflöst sonst wird das eh nichts !!!
Logischerweise wäre dann so wie es derzeit aussieht ein Pingversuch unsinnig und führt bei dieser vollkommen falschen Interface Konfiguration zum Chaos wie du ja selber sehen kannst !!!
Es kann aber auch sein das du ein Link Aggregation machst auf dem Rechner aber dafür ist dann diese gepostet Konfig vollkommen falsch, denn da hat man nur ein einziges Interface.
Irgendwas ist also an deiner Netzwerkkarte im Rechner komplett falsch konfiguriert oder du postest uns hier nur einen Bruchteil der Konfig und was der Rechner im Netzwerk macht (VLAN Tagging ??), so das wir hier im Dunkeln tappen
Wollen wir mal wieder ein bischen raten hier...
Vermutlich machst du 802.1q VLAN Tagging auf diesem physischen Rechner Interface wie z.B. hier beschrieben:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832/4
Damit wäre aber deine IP Adressierung komplett falsch und unsinning. Denn bei einer 28 Bit Subnetzmaske kannst du maximal 14 IP Hostadressen in einem Netzwerk unterbringen.
Bei dir sind aber alle Subinterfaces in einem einzigen IP Netzwerk, nämlich immer im .80er Netz was IP technisch gesehen vollkommen falsch ist.
(Unter der Annahme das das von dir gepostete xx.xx immer die gleichen Ziffern darstellt !??)
Alle Subinterfaces müssen aber in einem separaten IP Netz betrieben werden !!
Abgesehen davon benötigst du dann auch einen 802.1q tagged Link auf der Switchseite der den Rechneranschluss wieder in diese VLANs auflöst sonst wird das eh nichts !!!
Logischerweise wäre dann so wie es derzeit aussieht ein Pingversuch unsinnig und führt bei dieser vollkommen falschen Interface Konfiguration zum Chaos wie du ja selber sehen kannst !!!
Es kann aber auch sein das du ein Link Aggregation machst auf dem Rechner aber dafür ist dann diese gepostet Konfig vollkommen falsch, denn da hat man nur ein einziges Interface.
Irgendwas ist also an deiner Netzwerkkarte im Rechner komplett falsch konfiguriert oder du postest uns hier nur einen Bruchteil der Konfig und was der Rechner im Netzwerk macht (VLAN Tagging ??), so das wir hier im Dunkeln tappen
Zitat von @aqui:
Erstmal solltest du für uns alle klären was es mit den
virtuellen Sub-Interfaces auf der Maschine auf sich hat ???
Wollen wir mal wieder ein bischen raten hier...
[...]
Irgendwas ist also an deiner Netzwerkkarte im Rechner komplett falsch
konfiguriert oder du postest uns hier nur einen Bruchteil der Konfig
und was der Rechner im Netzwerk macht (VLAN Tagging ??), so das wir
hier im Dunkeln tappen
Erstmal solltest du für uns alle klären was es mit den
virtuellen Sub-Interfaces auf der Maschine auf sich hat ???
Wollen wir mal wieder ein bischen raten hier...
[...]
Irgendwas ist also an deiner Netzwerkkarte im Rechner komplett falsch
konfiguriert oder du postest uns hier nur einen Bruchteil der Konfig
und was der Rechner im Netzwerk macht (VLAN Tagging ??), so das wir
hier im Dunkeln tappen
Hallo aqui,
selbstverständlich soll keiner hier um Dunklem stehen und raten müssen. : )
Die Sache mit den Subinterfaces ist unterm Strick recht simple. Es handelt sich beim Server2 um einen dedizierten Server welchem der IP-Bereich xx.xx.164.80/28 zugewiesen ist.
Dadurch haben wir folgende Daten:
Netz-ID xx.xx.164.80
Addressen xx.xx.164.81-94
Broadcast xx.xx.164.95
Gateway xx.xx.164.81
Es werden keine VLANs eingesetzt oder ein Link auf dem Server aggregiert, evt. davor.
Warum diese Art der Konfiguration nach deinen Ansichten völlig falsch sein soll, ist für mich gerade nicht nachvollziehbar.
Beste Grüße
Benjamin
Moin,
MfG,
VW
Es werden keine VLANs eingesetzt oder ein Link auf dem Server aggregiert, evt. davor.
Das könnte auch erklären, warum scheinbar kein Echo-Reply ankommt. Denn, der Server kann dieses echo-Reply ja auch auf einem anderen Interface im gleichen Subnetz senden, der Request sendende Server wartet aber auf einen Reply von genau der angepingten IP-Adresse. Hast du mal geguckt, ob das Reply nicht gesendet wird, oder ob es auf dem anfragenden Server nur nicht angenommen wird, weil es von einer anderen Quell-IP ausgeht?- Grundsätzlich (außer bei von Aqui genannten Sonderfällen) gilt:
- 1 Interface = 1 Subnetz
MfG,
VW
Hallo VW,
in meinem ersten Post habe ich einen Auzug von einem tcpdump-Mitschnitt (tcpdump von Server2) angehängt, aus welchem man sehen kann, wie sich der Server verhält.
tcpdump von Server2
root@server2:~# tcpdump -n -i eth0 | grep xx.xx.52.73
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:53:56.506412 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 1
11:53:57.507129 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 2
11:53:57.514440 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 1
11:53:58.515070 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 2
11:53:58.522185 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 1
11:53:59.523003 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 2
11:53:59.530211 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 1
11:54:00.530997 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 2
Beste Grüße
Benjamin Casa
in meinem ersten Post habe ich einen Auzug von einem tcpdump-Mitschnitt (tcpdump von Server2) angehängt, aus welchem man sehen kann, wie sich der Server verhält.
tcpdump von Server2
root@server2:~# tcpdump -n -i eth0 | grep xx.xx.52.73
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
- Server1 senden request an Server2, Interface 164.82
- Server2 antwortet mit reply über angesprochenes Interface 164.82
- Hier das gleiche Spiel nur das wir nicht mehr eth0 sonder eth0:0 ansprechen
- Antwort von eth0:0
- Und hier hört es leider mit den Antworten auf : (
11:53:56.506412 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 1
11:53:57.507129 IP xx.xx.52.73 > xx.xx.164.91: icmp 64: echo request seq 2
11:53:57.514440 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 1
11:53:58.515070 IP xx.xx.52.73 > xx.xx.164.92: icmp 64: echo request seq 2
11:53:58.522185 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 1
11:53:59.523003 IP xx.xx.52.73 > xx.xx.164.93: icmp 64: echo request seq 2
11:53:59.530211 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 1
11:54:00.530997 IP xx.xx.52.73 > xx.xx.164.94: icmp 64: echo request seq 2
Beste Grüße
Benjamin Casa
OK, wir dürfen dann mal weiterraten das diese virtuellen Interfaces vermutlich von einer Virtualisierungs SW wie z.B. VmWare kommen.
In dem Falle stimmt dann auch wieder diese Zuordnung und ein Ping kann aber dann nur funktionieren wenn alle virtuellen Interfaces in der VM Software in den bridged Modus in den Netzwerk Settings geschaltet sind !! (Kein NAT oder Host Modus !!!)
So eine Konfig wie du sie gepostet hat ist KEINE Standardkonfig für ein Ethernet Interface unter Linux sondern hat eben was mit VLAN Tagging oder Virtualisierung zu tun. (Virtuelle Interfaces)
Um nicht alle in ein offenes Messer laufen zu lassen und ein ewiges Nachfragen zu provozieren wäre es etwas intelligenter gewesen ein klein wenig mehr über die Struktur des o.a. Rechners zu posten, die du vermutlich wohl selber nur rudimentär kennst...
Falls es der Bridge Modus nicht ist und Ping Client und die virtuellen Server auch wirklich in einem gleichen IP Segment nämlich dem .80er Netz sich befinden kann es nur noch ein Firewall Problem sein, das ICMP (Ping) Pakete filtert !!
In dem Falle stimmt dann auch wieder diese Zuordnung und ein Ping kann aber dann nur funktionieren wenn alle virtuellen Interfaces in der VM Software in den bridged Modus in den Netzwerk Settings geschaltet sind !! (Kein NAT oder Host Modus !!!)
So eine Konfig wie du sie gepostet hat ist KEINE Standardkonfig für ein Ethernet Interface unter Linux sondern hat eben was mit VLAN Tagging oder Virtualisierung zu tun. (Virtuelle Interfaces)
Um nicht alle in ein offenes Messer laufen zu lassen und ein ewiges Nachfragen zu provozieren wäre es etwas intelligenter gewesen ein klein wenig mehr über die Struktur des o.a. Rechners zu posten, die du vermutlich wohl selber nur rudimentär kennst...
Falls es der Bridge Modus nicht ist und Ping Client und die virtuellen Server auch wirklich in einem gleichen IP Segment nämlich dem .80er Netz sich befinden kann es nur noch ein Firewall Problem sein, das ICMP (Ping) Pakete filtert !!
Hallo aqui,
ich bin jeder Nachfrage dankbar, damit auch das letzten Problem der Nachvollziehbarkeit beseitigt werden kann. : )
Bei Server2 sind das nur sogenannte IP-Alias, welche konfiguriert sind. Keine virtuellen Interfaces, Virtualisierungs SW, oder ähnliches. Habe mal kurz in google gesucht und unter den Links [1,2] ist es beschrieben wurden.
Zur Struktur kann ich folgendes sagen: Server1 und Server2 sind dedizierte Server bei verschiedenen Provider und sind dadurch direkt übers Internet erreichbar.
Ein Firewall-Problem schließe ich aus folgenden Gründen aus:
1. tretet das Problem auch bei leeren iptable-chains auf (shorewall clean)
2. Werden die ersten zwei requests beantwortet. Alle folgenden kommen im System an (tcpdump) nur wird anscheinend kein reply generiert.
Beste Grüße
Benjamin
[1] http://www.oreilly.de/german/freebooks/linag2/netz0507.htm (ganz unten "IP-Alias")
[2] http://tldp.org/HOWTO/IP-Alias/commands.html
ich bin jeder Nachfrage dankbar, damit auch das letzten Problem der Nachvollziehbarkeit beseitigt werden kann. : )
Bei Server2 sind das nur sogenannte IP-Alias, welche konfiguriert sind. Keine virtuellen Interfaces, Virtualisierungs SW, oder ähnliches. Habe mal kurz in google gesucht und unter den Links [1,2] ist es beschrieben wurden.
Zur Struktur kann ich folgendes sagen: Server1 und Server2 sind dedizierte Server bei verschiedenen Provider und sind dadurch direkt übers Internet erreichbar.
Ein Firewall-Problem schließe ich aus folgenden Gründen aus:
1. tretet das Problem auch bei leeren iptable-chains auf (shorewall clean)
2. Werden die ersten zwei requests beantwortet. Alle folgenden kommen im System an (tcpdump) nur wird anscheinend kein reply generiert.
Beste Grüße
Benjamin
[1] http://www.oreilly.de/german/freebooks/linag2/netz0507.htm (ganz unten "IP-Alias")
[2] http://tldp.org/HOWTO/IP-Alias/commands.html
OK, dann sind alle Unklarheiten beseitigt.
Es ist möglich das bei Alias Adressen keine ICMP Pakete versendet werden sondern nur vom physischen Interface.
Das ist nicht unüblich, denn sollten auch ICMP Redirects oder sowas von allen Aliases versendet werden kann es Probleme in einem IP Netz geben. weshalb ICMP Support bei Alias IPs meist geblockt ist.
Das kann ggf. Ursache sein und solltest du mal prüfen wenn sonst alles richtig ist !
Es ist möglich das bei Alias Adressen keine ICMP Pakete versendet werden sondern nur vom physischen Interface.
Das ist nicht unüblich, denn sollten auch ICMP Redirects oder sowas von allen Aliases versendet werden kann es Probleme in einem IP Netz geben. weshalb ICMP Support bei Alias IPs meist geblockt ist.
Das kann ggf. Ursache sein und solltest du mal prüfen wenn sonst alles richtig ist !
