netmask problem

[MrRed]

hallo zusammen,

könnte mir bitte jemand diese zwei zeilen aus der linux-welt
in die bsd-welt übersetzen. die zweite heisst bestimmt:
"route add default 217.20.117.1"
aber ich bekomm das mit der netmask net richtig hin und aus
der manpage werde ich auch net schlau.

# route add -net 217.20.117.0 netmask 255.255.255.240 dev eth0
# route add default gw 217.20.117.1

thx, mrred.

 

[MrFixit]

Da steht alles drin, ist im Prinzip die gleiche Syntax, nur kannst du kein Device angeben

http://www.openbsd.org/cgi-bin/man.cgi?query=route&sektion=8

 

[MrRed]

# ifconfig
fxp0:
[...]
inet 217.20.127.50 netmask 0xffffff00 broadcast 217.20.127.255


statt
# route add -net 217.20.117.0 netmask 255.255.255.240 dev eth0
hab ich versucht
# route -n add -net 217.20.117.0 217.20.127.50 255.255.255.240
add net 217.20.117.0: gateway 217.20.127.50

dann
# route -n add default 217.20.117.1
add net default: gateway 217.20.117.1: Network is unreachable

was hab ich jetzt falsch gemacht?

so sollte die routing-tabelle danach aussehen:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
217.20.117.0    0.0.0.0         255.255.255.240 U        40 0          0 eth0
217.20.127.0    0.0.0.0         255.255.255.0   U        40 0          0 eth0
0.0.0.0         217.20.117.1    0.0.0.0         UG       40 0          0 eth0

das problem ist, dass ich nicht vor der kiste sitze, sondern dass
sie im RZ steht - daher nur remote zugriff.
ich mach daheim ein image und kopier es mit "dd" über die platte.
kann also keine 10 versuche machen.

das war schon mein dritter :-P

mrred.

 

[MrFixit]

Vielleicht sagst du einfach mal, was du erreichen willst.

 

[MrRed]

sorry, ich bin das ganze irgendwie total falsch angegangen.
neuer versuch...

meine ip: 217.20.127.50 (netmask 255.255.255.0)
mein gateway: 217.20.117.1 (netmask 255.255.255.240)

mein problem:
ich hatte bisher noch nie den fall, dass meine ip nicht im selben subnet wie
mein gateway ist. daher muss ich erst eine route in das subnetz des gateways
setzen. das funktioniert unter linux so:

route add -net 217.20.117.0 netmask 255.255.255.240 dev eth0

unter openbsd bekomme ichs einfach net hin, hab schon alles mögliche ausprobiert.
ich hoffe, dass es jetzt etwas klarer wurde wo es hängt.

thx, mrred.

 

[MrFixit]

Und wie soll das gehen? Du brauchst einen Router in ein anderes Subnetz. Das mag in einem geswitchen Netz vielleicht noch hinhauen, aber garantieren kann dir das niemand.

Wer macht denn so einen Kaese? Frag mal den Netzbetreuer nach dem Router fuer _dein_ Subnetz.

 

[MrRed]

Wer macht denn so einen Kaese?.

danke, wenigstens bin ich nicht der einzige der so denkt

 

[bofh]

ich habe vor einiger zeit das selbe problem gehabt

ich konnte kein router angeben der in einem anderen netz steht obwohl die route
dorthin bekannt war

mich würde aber trotzdem mal interesieren ob das zu relaisieren ist und wo es
dabei hängt

von der logik her dürfte es doch eigentlich kein problem sein ein gateway
anzugeben was in einem anderen netz ist und die route dorthin schon bekannt ist

nur so interessenhalber

 

[MrRed]

gerade antwort bekommen:
>allo,
>
> sie könne auch 217.20.127.1 als Gateway benutzen. Die .117.1 wird
> standardmässig aus dem Install. System gesetzt.
>
> mfg
> S.Räßl

*waaaaah*
und das sagen die mir jetzt.
bzw. da hätte ich auch selber drauf kommen können

danke für den anstoss MrFixit!

mrred.

 

[MrRed]

von der logik her dürfte es doch eigentlich kein problem sein ein gateway
anzugeben was in einem anderen netz ist und die route dorthin schon bekannt ist

nur so interessenhalber

unter linux kein problem, aber openbsd sagt *magichnet* (nach meinen erkenntnissen)
und ist auch besser so!! sowas macht man einfach net!!

 

[roefe]

macht wirklich keinen sinn...

verlange vom rz betrieber den standard gateway für den netz.... dann ganz einfach:

route add default x.x.x.x

 

[MrRed]

hab jetzt den gateway aus meinem netz benutzt und siehe da:
es geht

der anbieter heisst übrigens netdirekt (www.netdirekt.de).
bin sonst echt zufrieden, hardware is ok und die preise sind prima.
ich verwende die kiste haupsächlich als "sandkasten"

 

[bofh]

@ MrRed

Ja ich weiss das man es nicht macht im allgemeinen, aber mich wprde es echt interesieren
wie man das aushebelt

 

[MrRed]

denke mal dass es mit den "normalen" bsd-werkzeugen nicht geht
(route --force *hehe*)
aber vll mit bisl gebastel und fragroute dazu.

mrred.

 

[SierraX]

Hab in einem Artikel ((Net)BSD auf SSH-Rootservern; freeX 4|5 )dazu was gefunden:

Unter Linux wird gelegentlich ein Gateway angegeben, der nicht direkt erreichbar ist (eine statische Route ist vorgeschaltet). Das funktioniert unter BSD nicht, da ein Gateway direkt erreichbar sein muß. Die Kobination aus Netzmaske 0xffffff00 und statischer Route wurde daher hier durch eine größere Netzmaske 0xffff00 umgangen. Die Konfiguration des Netzwerkes ist mit einem Eintrag des Provider-Nameservers in der /etc/resolv.conf abgeschlossen.

 

[bofh]

merci

 

[kili]

Hab in einem Artikel ((Net)BSD auf SSH-Rootservern; freeX 4|5 )dazu was gefunden:

Das Netz zu vergroessern ist aber Muell, weil man dadurch (im typischen Hoster-Environment) andere Rechner aussperrt.

Ich habe diesen Thread nur grob quergelesen, aber ich glaube, ich hatte bei Strato ein aehnliches Problem. Die Loesung: eine explizite Link-level Route werfen. Das sieht bei mir dann so aus:

$ netstat -rnfinet
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            81.169.132.1       UGS        11  2295198      -   fxp0
81.169.132.1       0:0:c:7:ac:7       UHLS        1        0      -   fxp0
81.169.133.206     0:30:48:53:3f:8e   UHLc        0      614      -   lo0 =>
81.169.133.206     link#1             UC          1        0      -   fxp0
127/8              127.0.0.1          UGRS        0        0  33224   lo0
127.0.0.1          127.0.0.1          UH          2    58363  33224   lo0
224/4              127.0.0.1          URS         0        0  33224   lo0
$ cat /etc/hostname.fxp0                                
inet 81.169.133.206 0xffffffff
!route add 81.169.132.1 -link \$if: -interface

Adressen, Netmasks etc. muessen natuerlich angepasst werden. Und: ja, die Netmask, die man bei Strato verwenden muss ist etwas exotisch :-)

 

[SierraX]

Wieso sollte man andere Aussperren? Man vergrößert doch die Anzahl der Hosts innerhalb deiner Subnet. Ob die nun wirklich da sind ist doch scheiß egal.
Wenn du jetzt eine netmask von 0xfffffe00 genommen hättest. Welche Hosts hättest du dann deiner meinung nach ausgeschlossen?

 

[kili]

Wenn du jetzt eine netmask von 0xfffffe00 genommen hättest. Welche Hosts hättest du dann deiner meinung nach ausgeschlossen?

Alle, die in diesem Subnet liegen, und weder mein Server noch der dahinter liegende Router sind. Warum? Weil Pakete an diese Rechner gerade nicht uebers Defaultgateway geschoben werden, wenn sie lt. Netmask im gleichen Subnetz sind.

 

[SierraX]

Das wären dann also nach deiner Rechnung 255 Server die du nicht erreichen könntest. Wenn du Pech hast.
Ich glaube bei x Millionen Rechnenern lässt sich das verschmerzen. Wenn es dann wirklich ein unerträglicher zustand wird. Kann man es ja immernoch ändern. Ich bin aber immernoch nicht hinter das System deines Vorschlages gestiegen, funkt das überhaupt bei allen Betriebsystemen?

 

[kili]

Das wären dann also nach deiner Rechnung 255 Server die du nicht erreichen könntest. Wenn du Pech hast.
Ich glaube bei x Millionen Rechnenern lässt sich das verschmerzen.

In meinem Beispiel sind es noch ein paar Rechner mehr, da ich die Netmask auf 0xfffffe00 setzen muesste.

Klar liesse sich das verschmerzen, aber man hat schon Pferde kotzen sehen :-)

Irgendwann findet sich jemand, mit dem man zusammen irgendwelche verteilten Services anbieten will, und der hat dann nach Murphy rein zufaellig auch einen Server bei Strato gemietet, der im gleichen Subnetz liegt.

Ich bin aber immernoch nicht hinter das System deines Vorschlages gestiegen, funkt das überhaupt bei allen Betriebsystemen?

History: Zur Installation von OpenBSD auf dem Blech hatte ich damals die (vorzuegliche) Anleitung von Dettus verwendet, die damals auch noch die Anpassung der Netmask vorgeschlagen hatte. Einziger Unterschied: ich musste besagte Netmask 0xfffffe00 verwenden, weil mein Gateway sonst nicht erreichbar gewesen waere.

Das hat mich dann irgendwie so gewurmt (schliesslich koennten andere noch groessere "kuenstliche" Subnets benoetigen), dass ich ein paar Stunden gegoogelt habe. Dabei kamen u.a. jede Menge Hinweise zu gepatchten Linux-Tools heraus, sowie ein laenglicher Thread zu link-level Routes unter Net- oder FreeBSD (bei Bedarf kann ich letzteres auch noch mal aus den Tiefen meiner Bookmarks herauskramen).

Ich wuerde sagen: ja, zumindest auf den BSDs sollte es so oder so aehnlich funktionieren, auch wenn die Syntax von route(8) z.T. unterschiedlich ist. Und unter Linux funktioniert es offenbar auch, zumal Strato ja Linux vorinstalliert.

Anschaulich bewirkt der Link-level Eintrag in der Routingtabelle, dass alles, was an das Gateway gehen soll, blind und ohne Ruecksicht auf Verluste auf fxp0 gekuebelt wird, auch, wenn mein Gateway gar nicht in meinem Netz (mit Netmask 0xffffffff) ist.

 

[SierraX]

In meinem Beispiel sind es noch ein paar Rechner mehr, da ich die Netmask auf 0xfffffe00 setzen muesste.

9 Bit zur Adressierung? Da komm ich auf einen Adressraum von 510 Hosts. Die Normale hat 253 im Adressraum. Da komm ich auf 257 die GGF. nicht erreichbar sind.

Klar liesse sich das verschmerzen, aber man hat schon Pferde kotzen sehen :-)

Nur im Kino oder auf DVD! Schuh des Manitu

Irgendwann findet sich jemand, mit dem man zusammen irgendwelche verteilten Services anbieten will, und der hat dann nach Murphy rein zufaellig auch einen Server bei Strato gemietet, der im gleichen Subnetz liegt.

Kann sein. Ist so ne situation die man sich nicht wuenscht, und sich darum kuemmern wuerde weil es einen irgendwie wurmt

History: Zur Installation von OpenBSD auf dem Blech hatte ich damals die (vorzuegliche) Anleitung von Dettus verwendet, die damals auch noch die Anpassung der Netmask vorgeschlagen hatte. Einziger Unterschied: ich musste besagte Netmask 0xfffffe00 verwenden, weil mein Gateway sonst nicht erreichbar gewesen waere.

Das hat mich dann irgendwie so gewurmt (schliesslich koennten andere noch groessere "kuenstliche" Subnets benoetigen), dass ich ein paar Stunden gegoogelt habe. Dabei kamen u.a. jede Menge Hinweise zu gepatchten Linux-Tools heraus, sowie ein laenglicher Thread zu link-level Routes unter Net- oder FreeBSD (bei Bedarf kann ich letzteres auch noch mal aus den Tiefen meiner Bookmarks herauskramen).

Waere sehr nett.

Ich wuerde sagen: ja, zumindest auf den BSDs sollte es so oder so aehnlich funktionieren, auch wenn die Syntax von route(8) z.T. unterschiedlich ist. Und unter Linux funktioniert es offenbar auch, zumal Strato ja Linux vorinstalliert.

Dachte Strato verwendet eine Statisch Route was unter BSD nicht funkt.

Anschaulich bewirkt der Link-level Eintrag in der Routingtabelle, dass alles, was an das Gateway gehen soll, blind und ohne Ruecksicht auf Verluste auf fxp0 gekuebelt wird, auch, wenn mein Gateway gar nicht in meinem Netz (mit Netmask 0xffffffff) ist.

Erhoeht das nicht den Traffic (da sich ja die Broadcasts erhoehen) im Netz ins unermaessliche und heizt die Kollision an?

 

[kili]

Waere sehr nett.

http://www.atm.tut.fi/list-archive/freebsd-stable/msg05393.html

Witzigerweise sehe ich gerade, dass der OP es ebenfalls mit Linklevel routing versucht hatte, dabei aber ARP-Errors bekommen hat. Egal, bei mir funktioniert es :-)

Dachte Strato verwendet eine Statisch Route was unter BSD nicht funkt.

Man kann keine INET-Routen ausserhalb des lokalen Netzes werfen. Tue ich ja auch nicht. Siehe route(8), zum Thema Einstellung der Address family.

Erhoeht das nicht den Traffic (da sich ja die Broadcasts erhoehen) im Netz ins unermaessliche und heizt die Kollision an?

In meinem Fall nicht Broadcasts finden ja nur im lokalen Netzt statt, und das besteht in diesem Fall aus exakt einem Rechner (81.1698.133.206). Der Router (81.169.132.1) duerfte die entsprechenden Pakete eigentlich noch nicht mal sehen.

Zum Vergleich, hier noch mal beide Loesungen. Zunaechst die mit der grosszuegigen Netmask, dann die mir Linklevel Routing:

81.169.133.206/23 ----------> 81.169.132.1/mirdochegal

81.169.133.206/32 -- fxp0 --> 81.169.132.1/mirdochegal

Der einzige Nachteil, der mir dabei aufgefallen ist: ich bekomme direkt nach dem Booten eine(!) ARP-Fehlermeldung.

Einen Versuch ist also in jedem Fall Wert, wenn man sich in seltsamen Netzwerkumgebungen befindet. Die im oben genannten Thread erwaehnten Loesungsvorschlaege mit Aliases sollten auch in Erwaegung gezogen werden, haetten mir hier aber nicht viel gebracht.