[Linux 2.4] kernel: host $TARGET ignores redirects
Marc Haber
ich habe hier einen Router mit Linux 2.4.3, der sich fleißig darüber
beschwert, wenn ein Windows ein ausgestelltes ICMP redirect ignoriert.
|Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
Kann ich diese Logeinträge irgendwie abschalten?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Andreas Ferber
>
>|Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
> Kann ich diese Logeinträge irgendwie abschalten?
In der Kernelkonfiguration "IP: verbose route monitoring"
(CONFIG_IP_ROUTE_VERBOSE) ausschalten oder
"echo 0 >/proc/sys/net/ipv4/conf/*/log_martians".
Andreas
--
A formal parsing algorithm should not always be used.
-- D. Gries
Marc Haber
>* Marc Haber <mh+use...@zugschlus.de> schrieb:
>>|Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
>> Kann ich diese Logeinträge irgendwie abschalten?
>
>In der Kernelkonfiguration "IP: verbose route monitoring"
>(CONFIG_IP_ROUTE_VERBOSE) ausschalten oder
>"echo 0 >/proc/sys/net/ipv4/conf/*/log_martians".
Danke.
Andre Beck
>
> ich habe hier einen Router mit Linux 2.4.3, der sich fleißig darüber
> beschwert, wenn ein Windows ein ausgestelltes ICMP redirect ignoriert.
>
> |Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
Hast Du auf dem Netz einen Prefix kürzer /24? Konsistent auf allen
Rechnern? Man kann die Meldung sicher ignorieren, aber besser wär
es wohl, die Ursache loszuwerden. Wobei es mich natürlich nicht
wundern täte, wenn Windows mit "supernet masks" buggy reagiert.
--
"the big bang: the ultimate hero of low frequency;
the divine intergalactical bassdrum" -- Yello, "solar driftwood"
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) ABP-RIPE Xlink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> writes:
>> ich habe hier einen Router mit Linux 2.4.3, der sich fleißig darüber
>> beschwert, wenn ein Windows ein ausgestelltes ICMP redirect ignoriert.
>>
>> |Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
>
>Hast Du auf dem Netz einen Prefix kürzer /24?
Nein, das sind zwei /24, zwischen denen geroutet wird, aus
historischen Gründen. .43/24 war früher ein 10-Mbit-Netz an einem
eigenen Ethernet des Routers, und .42/24 war das 100-Mbit-Gegenstück.
Vor kurzer Zeit wurde dann ein Switch installiert, und seitdem hat der
Router 42.1/24 und 43.1/24 auf demselben Interface. Das heißt aber
auch, dass der Router Redirects ausstellt.
>Man kann die Meldung sicher ignorieren, aber besser wär
>es wohl, die Ursache loszuwerden.
Mir ist es eigentlich völlig egal, ob das Windows sich an die
Redirects hält oder nicht, solange die Pakete irgendwie am Ziel
ankommen. Jedes Mal einen Logeintrag auf dem Router zu haben, ist aber
nicht schön.
Juergen P. Meier
>Andre Beck <be...@ibh.de> wrote:
>>Marc Haber <mh+use...@zugschlus.de> writes:
>>> ich habe hier einen Router mit Linux 2.4.3, der sich fleißig darüber
>>> beschwert, wenn ein Windows ein ausgestelltes ICMP redirect ignoriert.
>>>
>>> |Apr 17 14:33:25 louise kernel: host 192.168.42.249/if3 ignores redirects for 192.168.43.224 to 192.168.43.224
>>
>>Hast Du auf dem Netz einen Prefix kürzer /24?
>
>Nein, das sind zwei /24, zwischen denen geroutet wird, aus
>historischen Gründen. .43/24 war früher ein 10-Mbit-Netz an einem
>eigenen Ethernet des Routers, und .42/24 war das 100-Mbit-Gegenstück.
>Vor kurzer Zeit wurde dann ein Switch installiert, und seitdem hat der
>Router 42.1/24 und 43.1/24 auf demselben Interface. Das heißt aber
>auch, dass der Router Redirects ausstellt.
An wen will den der router redirecten ? an sich selber?
Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
Er braucht einen router, der ihm keine redirects zurueckschickt.
Wenn du schon beide netze mit einem switch koppelst, dann stell doch
auf _allen_ beteiligten rechnern die netzmaske auf /23 (255.255.254.0)
Dann sollte es auch ohne router gehen.
>>Man kann die Meldung sicher ignorieren, aber besser wär
>>es wohl, die Ursache loszuwerden.
>
>Mir ist es eigentlich völlig egal, ob das Windows sich an die
>Redirects hält oder nicht, solange die Pakete irgendwie am Ziel
>ankommen. Jedes Mal einen Logeintrag auf dem Router zu haben, ist aber
>nicht schön.
Dein windows _kann_ sich nicht an die redirects halten (ich nehme
mal an, der router redirected ins jeweils andere netz), da es diese
ip's nicht direkt erreichen kann.
Korrigiere die Netzmasken und es geht wieder.
Oder lass den router wieder routen.
Oder mach alles mit ARP-Hacks noch viel schlimmer ;)
>
>Grüße
>Marc
>
juergen
--
J...@lrz.fh-muenchen.de
"This World is about to be Destroyed!"
Andreas Ferber
>
> Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
> Er braucht einen router, der ihm keine redirects zurueckschickt.
Natürlich kann er, wenn beide Netze in derselben Broadcast Domain
liegen. Bzw. ich weiss nicht, ob Windows das kann, Linux kann es auf
jeden Fall. Du musst dazu nur eine zusätzliche Route ohne Gateway
eintragen, und diese Route kann natürlich auch aus einem Redirect
stammen. BTDT.
Andreas
--
Bei richtiger Serversoftware gibt es ein Handbuch. Das für Netbus befindet
sich bei dem, der Deinen Rechner fernbedient.
(Lutz Donnerhacke in de.org.ccc)
Juergen P. Meier
>* Juergen P. Meier <J...@lrz.fh-muenchen.de> schrieb:
>>
>> Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
>> Er braucht einen router, der ihm keine redirects zurueckschickt.
>
>Natürlich kann er, wenn beide Netze in derselben Broadcast Domain
>liegen. Bzw. ich weiss nicht, ob Windows das kann, Linux kann es auf
Das tun sie ja genau dann, wenn auf dem interface eben genau die /23
netzmaske ligt.
Du kannst (auch unter linux) das 192.168.43.0 netz erreichen,
wenn eth0 so aussieht:
eth0 IP=192.168.42.1 MASK=255.255.255.0 BCAST=192.168.42.255
Kann sein das es unter linux mal br0ken routing/netzwerk code
gab, der so etwas erlaubte, aber bei korrekter implementation
darf es nicht gehen. Du muesstest dann schon ein 'alias'
interface erzeugen, mit einer IP im anderen netz.
Da ist es aber einfacher gleich die netzmaske zu aendern
(das geht dann auch unter Windows)
>jeden Fall. Du musst dazu nur eine zusätzliche Route ohne Gateway
Solange du nicht die /23 netzmaske auch auf dem Interface definierst,
bekommst du immer die fehler meldung SIOCADDRT: Invalid argument
Netze, die nicht auf einem Interface liegen, koennen nur ueber ein
gateway erreicht werden.
>eintragen, und diese Route kann natürlich auch aus einem Redirect
>stammen. BTDT.
Routing anhand von ICMP redirects zu modifizieren ist generell
keine gute idee, insb. wenn man nicht jeder physikalischer
komponente im netz, die einem ICMP pakete schicken kann, absolut
vertrauen kann. (d.h. Nie wenn es ne route ins ineternet gibt.)
>Andreas
Andreas Ferber
>>> Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
>>> Er braucht einen router, der ihm keine redirects zurueckschickt.
>>Natürlich kann er, wenn beide Netze in derselben Broadcast Domain
>>liegen. Bzw. ich weiss nicht, ob Windows das kann, Linux kann es auf
> Das tun sie ja genau dann, wenn auf dem interface eben genau die /23
> netzmaske ligt.
Nein. Dann liegen sie in einem IP-Netzwerk. Eine Broadcast-Domain ist
einen Layer tiefer definiert, da ist noch kein IP bekannt.
> Du kannst (auch unter linux) das 192.168.43.0 netz erreichen,
> wenn eth0 so aussieht:
> eth0 IP=192.168.42.1 MASK=255.255.255.0 BCAST=192.168.42.255
> Kann sein das es unter linux mal br0ken routing/netzwerk code
> gab, der so etwas erlaubte, aber bei korrekter implementation
> darf es nicht gehen.
Für Hostimplementierungen: Ack. Bei Routern ist die Sache nicht so klar.
In RfC 1812 steht in Abschnitt 2.2.7 nur etwas von "[...] IP address of
the next hop router. A router expects that this IP address will be on
an IP (sub)net to which the router is connected." Nirgendwo steht etwas
davon, daß ein Router das erzwingen _muss_ (falls ich was übersehen
haben sollte, bitte ich um Korrektur). Da Linux sowohl als Host als auch
als Router eingesetzt werden kann, ist nicht ganz klar, wonach der
Kernel sich richten sollte, und da hat man sich wohl dafür entschieden,
das beschriebene Verhalten zuzulassen (mir fällt auf Anhieb auch keine
Situation ein, wo daraus ein Problem entstehen könnte, es kann höchstens
zu asymmetrischem Routing kommen).
>>jeden Fall. Du musst dazu nur eine zusätzliche Route ohne Gateway
> Solange du nicht die /23 netzmaske auch auf dem Interface definierst,
> bekommst du immer die fehler meldung SIOCADDRT: Invalid argument
> Netze, die nicht auf einem Interface liegen, koennen nur ueber ein
> gateway erreicht werden.
Erzähle das bitte nicht meinem IP-Stack hier.
lem: ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:4B:B3:70:34
inet addr:192.168.42.10 Bcast:192.168.42.255 Mask:255.255.255.0
[...]
eth0:1 Link encap:Ethernet HWaddr 00:10:4B:B3:70:34
inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
[...]
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
[...]
cooper: ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:01:02:04:A7:FE
inet addr:192.168.42.6 Bcast:192.168.42.255 Mask:255.255.255.0
[...]
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
[...]
cooper: ~ # route add -net 192.168.5.0/24 dev eth0
cooper: ~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.42.254 0.0.0.0 UG 0 0 0 eth0
cooper: ~ # ping -c 1 192.168.5.1
PING 192.168.5.1 (192.168.5.1) from 192.168.42.6 : 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=0 ttl=255 time=490 usec
--- 192.168.5.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.490/0.490/0.490/0.000 ms
cooper: ~ # arp -n | grep 192.168.5
192.168.5.1 ether 00:10:4B:B3:70:34 C eth0
Mit Cisco IOS funktioniert das ganze auch wunderbar (überflüssiges
gekürzt):
curie#sh run in fasteth 0/1
interface FastEthernet0/1
ip address 192.168.42.254 255.255.255.0
end
curie(config)#ip route 192.168.5.0 255.255.255.0 fasteth 0/1.100
curie#ping 192.168.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Vielleicht probierst du die Sachen einfach mal aus, bevor du behauptest,
sie würden nicht funktionieren...
>>eintragen, und diese Route kann natürlich auch aus einem Redirect
>>stammen. BTDT.
> Routing anhand von ICMP redirects zu modifizieren ist generell
> keine gute idee, insb. wenn man nicht jeder physikalischer
> komponente im netz, die einem ICMP pakete schicken kann, absolut
> vertrauen kann. (d.h. Nie wenn es ne route ins ineternet gibt.)
Wenn du oben so auf RfC-Einhaltung pochst, solltest du dich hier
vielleich auch dran halten: Ein IP-Host _muss_ ICMP Redirects
berücksichtigen. Natürlich schreibt dir niemand vor, daß du auf deinen
gen Internet gerichteten Routerinterfaces Redirects nicht blocken
darfst, nur macht man das eben auf dem Borderrouter, nicht auf dem
einzelnen Host (von Ausnahmen wie Untrusted Hosts im selben Netz mal
abgesehen).
Andreas
--
> 1. is qmail as secure as they say?
Depends on what they were saying, but most likely yes.
-- Seen on debian-devel
Juergen P. Meier
>Nein. Dann liegen sie in einem IP-Netzwerk. Eine Broadcast-Domain ist
>einen Layer tiefer definiert, da ist noch kein IP bekannt.
Broadcast domains nutzen dir nichts, wenn der routingcode schon
das routen des pakets verhindert, weil er nicht weis wo (an welches
interface) er es denn hinschicken soll.
Arp kommt erst nach dem routing (auch bei linux, nur da ist es
eben moeglich 'unmoegliche' routing eintraege zu generieren)
>> Du kannst (auch unter linux) das 192.168.43.0 netz erreichen,
>> wenn eth0 so aussieht:
>> eth0 IP=192.168.42.1 MASK=255.255.255.0 BCAST=192.168.42.255
>> Kann sein das es unter linux mal br0ken routing/netzwerk code
>> gab, der so etwas erlaubte, aber bei korrekter implementation
>> darf es nicht gehen.
>
>Für Hostimplementierungen: Ack. Bei Routern ist die Sache nicht so klar.
Wir (d.h. der OP) reden hier nicht ueber Router, mit denen sich alle
moeglichen schweinereien anstellen koennen, ich kenne cisco's...
>In RfC 1812 steht in Abschnitt 2.2.7 nur etwas von "[...] IP address of
>the next hop router. A router expects that this IP address will be on
>an IP (sub)net to which the router is connected." Nirgendwo steht etwas
>davon, daß ein Router das erzwingen _muss_ (falls ich was übersehen
>haben sollte, bitte ich um Korrektur). Da Linux sowohl als Host als auch
>als Router eingesetzt werden kann, ist nicht ganz klar, wonach der
Er setzt Windows rechner ein, und diese sind idR keine Router.
>Kernel sich richten sollte, und da hat man sich wohl dafür entschieden,
>das beschriebene Verhalten zuzulassen (mir fällt auf Anhieb auch keine
>Situation ein, wo daraus ein Problem entstehen könnte, es kann höchstens
>zu asymmetrischem Routing kommen).
>
>>>jeden Fall. Du musst dazu nur eine zusätzliche Route ohne Gateway
>> Solange du nicht die /23 netzmaske auch auf dem Interface definierst,
>> bekommst du immer die fehler meldung SIOCADDRT: Invalid argument
>> Netze, die nicht auf einem Interface liegen, koennen nur ueber ein
>> gateway erreicht werden.
>
>Erzähle das bitte nicht meinem IP-Stack hier.
Was kann ich fuer deinen br0ken IP stack? Mein IP stack verhaelt sich
nicht so und erlaubt keine derartigen konstruktionen.
>lem: ~ # ifconfig
>eth0 Link encap:Ethernet HWaddr 00:10:4B:B3:70:34
> inet addr:192.168.42.10 Bcast:192.168.42.255 Mask:255.255.255.0
>[...]
>eth0:1 Link encap:Ethernet HWaddr 00:10:4B:B3:70:34
> inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
>[...]
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
>[...]
>
>cooper: ~ # ifconfig
>eth0 Link encap:Ethernet HWaddr 00:01:02:04:A7:FE
> inet addr:192.168.42.6 Bcast:192.168.42.255 Mask:255.255.255.0
>[...]
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
>[...]
>cooper: ~ # route add -net 192.168.5.0/24 dev eth0
ich uebersetze das mal in den syntax des route commandos hier:
root@sol# route add -net 192.168.5.0/24 -interface hme0
hme0: bad value
die fehlermeldung EINVAL ruehrt daher, weil hme0 wie folgt aussieht:
root@sol# ifconfig hme0
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.1.2.173 netmask ffff0000 broadcast 10.1.255.255
ether 8:0:20:b3:1b:b
Das es mit linux (2.2.x ueberprueft, 2.4 nicht, weil rechner zuhause)
geht, heist lediglich das linux hier layer 2 routing umgehen kann.
(wie sinnvoll das ist, darueber laesst sich vortrefflich streiten,
ich selbst fand dieses feature von linux selbst schon sehr hilfreich..)
Das ist jedoch keineswegs die Regel. Unter strenger trennung von
Layer-1 und Layer-2 muss, um eine Subnet-fremde IP direkt ansprechen
zu koennen eine "alias" [oder wei immer es genannt wird] IP auf dieses
interface mit dem korrekten netz-add und -mask gesetzt werden.
Das diese strenge trennung in keinem mir bekannten RFC geforder wird
heist lediglich, das wir beide recht haben... ;)
Dem OP hilft das aber nicht viel, da der IP stack von Windows sich
eben nicht wie bei linux verhaelt.
>Mit Cisco IOS funktioniert das ganze auch wunderbar (überflüssiges
>gekürzt):
Cisco router (die IOS haben) sind keine Hosts.
Versuch das doch bitte mal mit ner PIX ;)
>> Routing anhand von ICMP redirects zu modifizieren ist generell
>> keine gute idee, insb. wenn man nicht jeder physikalischer
>> komponente im netz, die einem ICMP pakete schicken kann, absolut
>> vertrauen kann. (d.h. Nie wenn es ne route ins ineternet gibt.)
>
>Wenn du oben so auf RfC-Einhaltung pochst, solltest du dich hier
>vielleich auch dran halten: Ein IP-Host _muss_ ICMP Redirects
>berücksichtigen. Natürlich schreibt dir niemand vor, daß du auf deinen
aus rfc-0792: (ich hab den teil, der eindeutig besagt, das der
router _gar kein icmp-redirect_ schiecken duerfte, unterstrichen)
Man kann jetzt noch streiten, ob "network" sich hier auf layer-1 oder
layer-2 bezieht. Da jedoch der gesamtkontext (ICMP) jedoch auf layer-2
bezogen ist, halte ich es fuer abwaegig hier von layer-1 auszugehen.
[also (L2) subnets, und keine (L1) broadcast domains]
(ICMP Redirect)
Description
The gateway sends a redirect message to a host in the following
situation. A gateway, G1, receives an internet datagram from a
host on a network to which the gateway is attached. The gateway,
G1, checks its routing table and obtains the address of the next
gateway, G2, on the route to the datagram's internet destination
network, X. If G2 and the host identified by the internet source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
address of the datagram are on the same network, a redirect
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
message is sent to the host. The redirect message advises the
host to send its traffic for network X directly to gateway G2 as
this is a shorter path to the destination. The gateway forwards
the original datagram's data to its internet destination.
Ein advice (Ratschlag, Rat) ist keine verbindliche Anweisung.
Der host ist nicht verpflichtet (as in MUST) diesem ICMP
paket ueberhaupt beachtung zu schenken.
Deine aussage ist daher falsch.
>gen Internet gerichteten Routerinterfaces Redirects nicht blocken
>darfst, nur macht man das eben auf dem Borderrouter, nicht auf dem
>einzelnen Host (von Ausnahmen wie Untrusted Hosts im selben Netz mal
Natuerlich blocke ich ICMP redirects auf dem border-GW.
Aber die meisten meiner Hosts ignorieren ICMP-redirects aus einem
der folgenden gruende:
1) (haeufig) es findet kein dynamisches anpassen der routingtable statt.
2) der G2 im ICMP redirect ist vom host aus nicht direkt erreichbar,
daher verwirft er (der host) dieses paket als ungueltig.
>abgesehen).
>
>Andreas
juergen.
Marc Haber
>On Sun, 29 Apr 2001 15:35:05 +0200, <mh+use...@zugschlus.de> typed:
>>historischen Gründen. .43/24 war früher ein 10-Mbit-Netz an einem
>>eigenen Ethernet des Routers, und .42/24 war das 100-Mbit-Gegenstück.
>>Vor kurzer Zeit wurde dann ein Switch installiert, und seitdem hat der
>>Router 42.1/24 und 43.1/24 auf demselben Interface. Das heißt aber
>>auch, dass der Router Redirects ausstellt.
>
>An wen will den der router redirecten ? an sich selber?
An das eigentliche Ziel.
>Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
Natürlich kann er. Der Router leitet das erste Paket weiter, und teilt
dem absendenen Host dann mit, dass er den gewünschten Host aber auch
direkt erreichen kann.
>Wenn du schon beide netze mit einem switch koppelst, dann stell doch
>auf _allen_ beteiligten rechnern die netzmaske auf /23 (255.255.254.0)
Genau das wollen wir vermeiden.
>Dann sollte es auch ohne router gehen.
Es geht auch mit Router ausgezeichnet, und den Router kann man eh
nicht einsparen, da dieser Router die Internetanbindung herstellt.
>>Mir ist es eigentlich völlig egal, ob das Windows sich an die
>>Redirects hält oder nicht, solange die Pakete irgendwie am Ziel
>>ankommen. Jedes Mal einen Logeintrag auf dem Router zu haben, ist aber
>>nicht schön.
>
>Dein windows _kann_ sich nicht an die redirects halten
Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
andere Netz direkt erreichen.
>(ich nehme
>mal an, der router redirected ins jeweils andere netz), da es diese
>ip's nicht direkt erreichen kann.
Kann er.
>Korrigiere die Netzmasken und es geht wieder.
Es funktioniert ausgezeichnet.
>Oder lass den router wieder routen.
Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
Ordnung ist. Was ich lästig finde ist, dass er sich beschwert, wenn
man seine Redirects ignoriert.
Juergen P. Meier
>J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
>>An wen will den der router redirecten ? an sich selber?
>
>An das eigentliche Ziel.
Stimmt.
>>Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
>
>Natürlich kann er. Der Router leitet das erste Paket weiter, und teilt
>dem absendenen Host dann mit, dass er den gewünschten Host aber auch
>direkt erreichen kann.
Was der host evtl wegen striktem routing nicht kann.
>>Wenn du schon beide netze mit einem switch koppelst, dann stell doch
>>auf _allen_ beteiligten rechnern die netzmaske auf /23 (255.255.254.0)
>
>Genau das wollen wir vermeiden.
>
>>Dann sollte es auch ohne router gehen.
>
>Es geht auch mit Router ausgezeichnet, und den Router kann man eh
>nicht einsparen, da dieser Router die Internetanbindung herstellt.
Schalt doch auf dem router einfach das redirect-senden aus...
(sollte im manual des router's stehen.)
>>>Mir ist es eigentlich völlig egal, ob das Windows sich an die
>>>Redirects hält oder nicht, solange die Pakete irgendwie am Ziel
>>>ankommen. Jedes Mal einen Logeintrag auf dem Router zu haben, ist aber
>>>nicht schön.
>>
>>Dein windows _kann_ sich nicht an die redirects halten
>
>Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
>andere Netz direkt erreichen.
Ja, weil es kein striktes routing macht. (siehe anderes posting von mir)
Das ist nicht standard und kann sich schnell aendern.
Andere unixe machen das auch nicht (SunOS z.b.)
>>(ich nehme
>>mal an, der router redirected ins jeweils andere netz), da es diese
>>ip's nicht direkt erreichen kann.
>
>Kann er.
Ja, der router hat ja auch beide netze auf dem interface.
>>Korrigiere die Netzmasken und es geht wieder.
>
>Es funktioniert ausgezeichnet.
>
>>Oder lass den router wieder routen.
>
>Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
>Ordnung ist. Was ich lästig finde ist, dass er sich beschwert, wenn
>man seine Redirects ignoriert.
Das problem ist, das die hosts mit der /24 netzmaske (sofern sie
stricktes routing erzwingen) mit den redirects nichts anfangen
koennen, weil sie davon ueberzeugt sind das andere netz nur ueber
den default gateway erreichen zu koennen.
Deine konfiguration ist halt einfach Broken - da hilft auch nicht
das du das gerne so haben willst.
>Grüße
>Marc
juergen.
Marc Haber
>On Mon, 30 Apr 2001 20:32:37 +0200, <mh+use...@zugschlus.de> typed:
>>J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
>>>An wen will den der router redirecten ? an sich selber?
>>dem absendenen Host dann mit, dass er den gewünschten Host aber auch
>>direkt erreichen kann.
>
>Was der host evtl wegen striktem routing nicht kann.
Was verstehst Du unter "striktem Routing"?
>>>Dann sollte es auch ohne router gehen.
>>
>>Es geht auch mit Router ausgezeichnet, und den Router kann man eh
>>nicht einsparen, da dieser Router die Internetanbindung herstellt.
>
>Schalt doch auf dem router einfach das redirect-senden aus...
>(sollte im manual des router's stehen.)
Das erzeugt unnötige Last.
>>Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
>>andere Netz direkt erreichen.
>
>Ja, weil es kein striktes routing macht. (siehe anderes posting von mir)
Welches andere Posting? "strikt" kommt in Artikeln in diesem Thread
nur in dem Artikel vor, auf den ich gerade antworte.
>Das ist nicht standard und kann sich schnell aendern.
>Andere unixe machen das auch nicht (SunOS z.b.)
SunOS ignoriert also auch redirects?
>>>(ich nehme
>>>mal an, der router redirected ins jeweils andere netz), da es diese
>>>ip's nicht direkt erreichen kann.
>>
>>Kann er.
>
>Ja, der router hat ja auch beide netze auf dem interface.
Ein Linux hätte nicht beide Netze auf dem Interface und könnte
trotzdem.
>>Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
>>Ordnung ist. Was ich lästig finde ist, dass er sich beschwert, wenn
>>man seine Redirects ignoriert.
>
>Das problem ist, das die hosts mit der /24 netzmaske (sofern sie
>stricktes routing erzwingen) mit den redirects nichts anfangen
>koennen,
Und das kann man bei Windows nicht abschalten?
>weil sie davon ueberzeugt sind das andere netz nur ueber
>den default gateway erreichen zu koennen.
Ein redirect soll sie aber doch gerade darüber informieren, dass sie
doch können!
>Deine konfiguration ist halt einfach Broken - da hilft auch nicht
>das du das gerne so haben willst.
Was würde ich machen, wenn die beiden /24 nicht zufällig direkt
nebeneinander liegen würden? Wenn ich nicht Windows, sondern Mac OS
hätte, wo ich keine statischen Routen eintragen kann?
Juergen P. Meier
>J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
>>On Mon, 30 Apr 2001 20:32:37 +0200, <mh+use...@zugschlus.de> typed:
>>>J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
>>>>An wen will den der router redirecten ? an sich selber?
>>>Natürlich kann er. Der Router leitet das erste Paket weiter, und teilt
>>>dem absendenen Host dann mit, dass er den gewünschten Host aber auch
>>>direkt erreichen kann.
>>
>>Was der host evtl wegen striktem routing nicht kann.
>
>Was verstehst Du unter "striktem Routing"?
Das du eben keine route zu einem netz auf ein Interface legen kannst,
wo dieses Netz garnicht anliegt (gemaess ifconfig).
>>>>Dann sollte es auch ohne router gehen.
>>>
>>>Es geht auch mit Router ausgezeichnet, und den Router kann man eh
>>>nicht einsparen, da dieser Router die Internetanbindung herstellt.
>>
>>Schalt doch auf dem router einfach das redirect-senden aus...
>>(sollte im manual des router's stehen.)
>
>Das erzeugt unnötige Last.
Dann ist die netzmaske anzupassen (in dem fall ja kein problem)
>>>Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
>>>andere Netz direkt erreichen.
>>
>>Ja, weil es kein striktes routing macht. (siehe anderes posting von mir)
>
>Welches andere Posting? "strikt" kommt in Artikeln in diesem Thread
>nur in dem Artikel vor, auf den ich gerade antworte.
Das ist eine Bezeichnung, die Ich gewaehlt habe, um den Unterschied
zw. Linux|Cisco und anderen OS'en (z.b. SunOS 5, Windows) zu verdeutlichen.
Ich weis nicht, ob diese bezeichnung irgendwo sonst noch verwendet wird.
>>Das ist nicht standard und kann sich schnell aendern.
>>Andere unixe machen das auch nicht (SunOS z.b.)
>
>SunOS ignoriert also auch redirects?
Ja, sofern sie fuer den Kernel sinnlos erscheinen (sprich, der
im redirect angegebene GW gemaess routing (welches die durch die
interfaces gegebenen network-routen einschliesst) nicht direkt
erreichbar ist. Das ist eine vollkommen korrekte Implementation.
Das andere es anders machen (und das auch funktioniert)
ist hier allerdings ein anderes thema ;>
>>>>(ich nehme
>>>>mal an, der router redirected ins jeweils andere netz), da es diese
>>>>ip's nicht direkt erreichen kann.
>>>
>>>Kann er.
>>
>>Ja, der router hat ja auch beide netze auf dem interface.
>
>Ein Linux hätte nicht beide Netze auf dem Interface und könnte
>trotzdem.
Ja (linux kann und tut auch). Windows allerdings nicht. (ich konnte das
jetzt hier mit meinem win98 testen, und nach aussagen des OP betrifft
das auch W2k. Ich vermute daher das dies auch auf NT4 zutrifft...)
Bei SunOS bin ich schon selber ueber genau diese sacht (ignoriertes
redirect) gestolpert, darum weis ich das dort auch so genau.
(sunos 5.7 und 5.8)
>>>Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
>>>Ordnung ist. Was ich lästig finde ist, dass er sich beschwert, wenn
>>>man seine Redirects ignoriert.
>>
>>Das problem ist, das die hosts mit der /24 netzmaske (sofern sie
>>stricktes routing erzwingen) mit den redirects nichts anfangen
>>koennen,
>
>Und das kann man bei Windows nicht abschalten?
*lol* (war die frage jetzt ernst gemeint? ;)
>>weil sie davon ueberzeugt sind das andere netz nur ueber
>>den default gateway erreichen zu koennen.
>
>Ein redirect soll sie aber doch gerade darüber informieren, dass sie
>doch können!
Was der router denkt das die hosts es koennen muessten, muss nicht
mit der ansicht des hosts uebereinstimmen.
Klar das der host kann, wenn er die interface-netzaddresse/maske
nicht als aller weisheit letzter schluss betrachtet, aber das ist
nunmal kein MUST, sonder lediglich ein MIGHT...
>>Deine konfiguration ist halt einfach Broken - da hilft auch nicht
>>das du das gerne so haben willst.
>
>Was würde ich machen, wenn die beiden /24 nicht zufällig direkt
>nebeneinander liegen würden? Wenn ich nicht Windows, sondern Mac OS
>hätte, wo ich keine statischen Routen eintragen kann?
Dann laeuft aller traffic zwischen diesen beiden subnetzen ueber
den router. Und daran kann man dann auch nicht viel aendern. :-/
>Grüße
>Marc
PS: ich moechte hier dem eindruck, das ich das verhalten von
cisco und linux als "falsch" ansehe, nochmals entschieden
entgegenwirken (ich habe in einem frueheren posting wohl durch
ungeeignete wortwahl dies impliziert...).
Da es hier wohl keine Standards gibt, die das eine oder
das andere verhalten vorschreiben, ist weder das eine noch
das andere besser.
Es gab genug netzwerk umgebungen, wo ich selbst schon auf mehreren
linux systemen andere layer-2 subnetze, die auf dem gleichen
layer-1 netz hingen (so wie beim OP), statisch aufs interface
geroutet, allein um den router zu entlasten...
Marc Haber
>On Tue, 01 May 2001 10:07:47 +0200, <mh+use...@zugschlus.de> typed:
>
>Das du eben keine route zu einem netz auf ein Interface legen kannst,
>wo dieses Netz garnicht anliegt (gemaess ifconfig).
Verstehe.
>>Das erzeugt unnötige Last.
>
>Dann ist die netzmaske anzupassen (in dem fall ja kein problem)
Auf schlimmstenfalls 506 Rechnern?
>Das andere es anders machen (und das auch funktioniert)
>ist hier allerdings ein anderes thema ;>
Da finde ich den Weg der "anderen" aber deutlich sinnvoller. Ich habe
auf "meinem" Backbone normalerweise nur mit Cisco und Linux zu tun,
die Umgebung, über die wir hier diskutieren, ist das Office-Netz und
die einzige Stelle in meiner Umgebung, an der Windows-Mühlen mit
Redirects konfrontiert werden können. Slowlaris gibt es bei uns nicht.
>>>Das problem ist, das die hosts mit der /24 netzmaske (sofern sie
>>>stricktes routing erzwingen) mit den redirects nichts anfangen
>>>koennen,
>>
>>Und das kann man bei Windows nicht abschalten?
>
>*lol* (war die frage jetzt ernst gemeint? ;)
Es gibt bei Windows erstaunlich viele undokumentiere Registry-Switche.
Das ist fast so ergiebig wie ein obskures File unter /proc, in das man
seltsame Zaubersprüche hineinpipen muss, damit der Rechner einem
endlich den bestellten Kaffee kocht.
>>Was würde ich machen, wenn die beiden /24 nicht zufällig direkt
>>nebeneinander liegen würden? Wenn ich nicht Windows, sondern Mac OS
>>hätte, wo ich keine statischen Routen eintragen kann?
>
>Dann laeuft aller traffic zwischen diesen beiden subnetzen ueber
>den router. Und daran kann man dann auch nicht viel aendern. :-/
Der Router würde auch in diesem Fall fleißig Redirects ausstellen und
sich darüber beschweren, dass der Host die Redirects ignoriert.
>Es gab genug netzwerk umgebungen, wo ich selbst schon auf mehreren
>linux systemen andere layer-2 subnetze, die auf dem gleichen
>layer-1 netz hingen (so wie beim OP), statisch aufs interface
>geroutet, allein um den router zu entlasten...
Siehste...
Juergen P. Meier
>>Dann ist die netzmaske anzupassen (in dem fall ja kein problem)
>
>Auf schlimmstenfalls 506 Rechnern?
Bei verwendung von DHCP kein problem ;)
Bei sovielen rechnern bietet sich DHCP sowieso an. (am besten dann
einfuehren, wenn sowieso netzwerkumstellung anliegt, dann laesst
es sich in einem aufwasch ohne groessere zusatzarbeit erledigen ;)
Andernfalls ist es wirklich extrem umstaendlich, da hast du schon recht.
>>Das andere es anders machen (und das auch funktioniert)
>>ist hier allerdings ein anderes thema ;>
>
>Da finde ich den Weg der "anderen" aber deutlich sinnvoller. Ich habe
>auf "meinem" Backbone normalerweise nur mit Cisco und Linux zu tun,
>die Umgebung, über die wir hier diskutieren, ist das Office-Netz und
>die einzige Stelle in meiner Umgebung, an der Windows-Mühlen mit
>Redirects konfrontiert werden können. Slowlaris gibt es bei uns nicht.
Bei linux kannst du das ja per interface konfigurieren (siehe
/proc/sys/net/ipv4/conf/*/*redirects )
bei Solaris gibts das auch (ndd /dev/ip ip_ignore_redirects und
ip_send_redirects), nur da ist der default halt genau anders als
bei linux.
Obs das bei windows auch gibt, musst du Microsoft fragen...
>>>Und das kann man bei Windows nicht abschalten?
>>
>>*lol* (war die frage jetzt ernst gemeint? ;)
>
>Es gibt bei Windows erstaunlich viele undokumentiere Registry-Switche.
>Das ist fast so ergiebig wie ein obskures File unter /proc, in das man
>seltsame Zaubersprüche hineinpipen muss, damit der Rechner einem
>endlich den bestellten Kaffee kocht.
Leider sind die registry-zaubereien im gegensatz zum linux procfs
nicht dokumentiert (bzw. diese doku fuer normalsterbliche nicht
zugaenglich).
>>Dann laeuft aller traffic zwischen diesen beiden subnetzen ueber
>>den router. Und daran kann man dann auch nicht viel aendern. :-/
>
>Der Router würde auch in diesem Fall fleißig Redirects ausstellen und
>sich darüber beschweren, dass der Host die Redirects ignoriert.
Ja. Denn da hier wohl noch andere rechner ausser windoof im netz
stehen, die sauber auf die redirects reagieren, macht es wohl nicht
allzuviel sinn, das redirect-senden dem router abzugewoehnen.
ich glaub jetzt wirds langsam zeit fuer ein fup2p ;)
juergen
Andre Beck
> J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
> >On Sun, 29 Apr 2001 15:35:05 +0200, <mh+use...@zugschlus.de> typed:
> >>Nein, das sind zwei /24, zwischen denen geroutet wird, aus
> >>historischen Gründen. .43/24 war früher ein 10-Mbit-Netz an einem
> >>eigenen Ethernet des Routers, und .42/24 war das 100-Mbit-Gegenstück.
> >>Vor kurzer Zeit wurde dann ein Switch installiert, und seitdem hat der
> >>Router 42.1/24 und 43.1/24 auf demselben Interface. Das heißt aber
> >>auch, dass der Router Redirects ausstellt.
> >
> >An wen will den der router redirecten ? an sich selber?
>
> An das eigentliche Ziel.
Das aber aus Sicht des Client nicht direct connected ist.
> >Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
>
> Natürlich kann er. Der Router leitet das erste Paket weiter, und teilt
> dem absendenen Host dann mit, dass er den gewünschten Host aber auch
> direkt erreichen kann.
Das ist eine Erweiterung von ICMP Redirect von dem eigentlichen
Gedanken "erklär dem Rechner, dass es ein besseres Gateway zum
Ziel gibt" hin zu "erklär dem Rechner, dass das Ziel direct
connected ist". Interessante Idee, aber wo ist das standardi-
siert? Solange das nicht in einem "Requirements for Hosts"-RFC
steht, halte ich das eher für leicht abenteuerlich. Nicht zu-
letzt, weil es auch interessante Angriffe zulässt.
> >Wenn du schon beide netze mit einem switch koppelst, dann stell doch
> >auf _allen_ beteiligten rechnern die netzmaske auf /23 (255.255.254.0)
>
> Genau das wollen wir vermeiden.
Kann ich nachvollziehen, renumber sucks.
> >Dein windows _kann_ sich nicht an die redirects halten
>
> Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
> andere Netz direkt erreichen.
Wie gesagt, diese Interpretation von Redirect kann man nicht voraus-
setzen. Schön, wenn Linux das kann. IMO gehört es zumindest abschalt-
bar, wenn nicht per default aus. Man müsste mal nachsehen, was in dem
Zusammenhang /proc/sys/net/ipv4/conf/default/secure_redirects hergibt.
> >(ich nehme
> >mal an, der router redirected ins jeweils andere netz), da es diese
> >ip's nicht direkt erreichen kann.
>
> Kann er.
Ob er das kann oder nicht ist eine philosophische Frage. Er *könnte*,
wenn er eine connected route in dieses Netz hätte. Das Erzeugen einer
solchen ist für mich aber ein administrativer Vorgang, sowas einem
Automatismus (ICMP redirect ist ja letztlich nur eine Fehlerbehandlung)
zu überlassen ist mir nicht ganz geheuer.
> >Oder lass den router wieder routen.
>
> Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
> Ordnung ist.
Bei dieser Sorte Redirects streitbar, aber Ok ;)
> Was ich lästig finde ist, dass er sich beschwert, wenn
> man seine Redirects ignoriert.
Fehlermeldung auskommentieren, neu kompilieren, fertig. UTSL.
Alternativ auf den Windosen einmalig
route -p add <theothernet> mask 255.255.255.0 <myownip>
reinhämmern. Oder, falls das wirklich kein NT ist, in ein Batch ver-
bringen. Dann ist die connected route administrativ da und der Router
wird gar nicht mehr bemüht, was der Performance entgegenkommt.
Juergen P. Meier
>Marc Haber <mh+use...@zugschlus.de> writes:
>> J...@lrz.fh-muenchen.de (Juergen P. Meier) wrote:
>> >On Sun, 29 Apr 2001 15:35:05 +0200, <mh+use...@zugschlus.de> typed:
>> >>Nein, das sind zwei /24, zwischen denen geroutet wird, aus
>> >>historischen Gründen. .43/24 war früher ein 10-Mbit-Netz an einem
>> >>eigenen Ethernet des Routers, und .42/24 war das 100-Mbit-Gegenstück.
>> >>Vor kurzer Zeit wurde dann ein Switch installiert, und seitdem hat der
>> >>Router 42.1/24 und 43.1/24 auf demselben Interface. Das heißt aber
>> >>auch, dass der Router Redirects ausstellt.
>> >
>> >An wen will den der router redirecten ? an sich selber?
>>
>> An das eigentliche Ziel.
>
>Das aber aus Sicht des Client nicht direct connected ist.
Genau. layer-2 vor layer-1.
>> >Ein rechner mit .42/24 kann das .43/24er netz nicht direkt erreichen.
>>
>> Natürlich kann er. Der Router leitet das erste Paket weiter, und teilt
>> dem absendenen Host dann mit, dass er den gewünschten Host aber auch
>> direkt erreichen kann.
>
>Das ist eine Erweiterung von ICMP Redirect von dem eigentlichen
>Gedanken "erklär dem Rechner, dass es ein besseres Gateway zum
>Ziel gibt" hin zu "erklär dem Rechner, dass das Ziel direct
>connected ist". Interessante Idee, aber wo ist das standardi-
>siert? Solange das nicht in einem "Requirements for Hosts"-RFC
>steht, halte ich das eher für leicht abenteuerlich. Nicht zu-
>letzt, weil es auch interessante Angriffe zulässt.
Stellt doch ein RFC ;)
>> >Wenn du schon beide netze mit einem switch koppelst, dann stell doch
>> >auf _allen_ beteiligten rechnern die netzmaske auf /23 (255.255.254.0)
>>
>> Genau das wollen wir vermeiden.
>
>Kann ich nachvollziehen, renumber sucks.
Manchmal ist es notwendig und/oder sinnvoll. Und dabei kann man dann
oft gleich auf DHCP umsteigen, was die sache massiv erleichtert ;)
>> >Dein windows _kann_ sich nicht an die redirects halten
>> Ein Linux an derselben Stelle hält sich an die Redirects. Und kann das
>> andere Netz direkt erreichen.
>
>Wie gesagt, diese Interpretation von Redirect kann man nicht voraus-
>setzen. Schön, wenn Linux das kann. IMO gehört es zumindest abschalt-
>bar, wenn nicht per default aus. Man müsste mal nachsehen, was in dem
>Zusammenhang /proc/sys/net/ipv4/conf/default/secure_redirects hergibt.
Ist voll konfigurierbar.
>> >(ich nehme
>> >mal an, der router redirected ins jeweils andere netz), da es diese
>> >ip's nicht direkt erreichen kann.
>>
>> Kann er.
>
>Ob er das kann oder nicht ist eine philosophische Frage. Er *könnte*,
>wenn er eine connected route in dieses Netz hätte. Das Erzeugen einer
>solchen ist für mich aber ein administrativer Vorgang, sowas einem
>Automatismus (ICMP redirect ist ja letztlich nur eine Fehlerbehandlung)
>zu überlassen ist mir nicht ganz geheuer.
Woher bekommt er denn die IP dieses Netzbereichs, welche er auf das
interface binden soll ?
Automatismen sind hier in der Tat fehl am platz.
>> >Oder lass den router wieder routen.
>>
>> Der will routen, stellt aber zusätzlich Redirects aus, was völlig in
>> Ordnung ist.
>
>Bei dieser Sorte Redirects streitbar, aber Ok ;)
Der router weis ja nicht, das der host das target gemaess layer-2
(routing) nicht direkt erreichen kann. Er selbst kann das [1], also
geht schickt er fleissig redirects.
[1] am gleichen interface, also auf layer-1
>> Was ich lästig finde ist, dass er sich beschwert, wenn
>> man seine Redirects ignoriert.
>
>Fehlermeldung auskommentieren, neu kompilieren, fertig. UTSL.
>Alternativ auf den Windosen einmalig
>route -p add <theothernet> mask 255.255.255.0 <myownip>
>reinhämmern. Oder, falls das wirklich kein NT ist, in ein Batch ver-
>bringen. Dann ist die connected route administrativ da und der Router
>wird gar nicht mehr bemüht, was der Performance entgegenkommt.
eine batch im Autostart sollte hier helfen.
ist und bleibt aber ein workaround um das eigentlichen problem.
(renumbering)
juergen.
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
end
<URL:http://support.microsoft.com/support/kb/articles/q265/2/30.asp>
<URL:http://support.microsoft.com/support/kb/articles/Q260/8/22.ASP>