Auswirkung eines falsches Subnetzes ^ ^

[legrx]

Salut,

ich sitze über die Abschlussprüfung FISI Winter 13/14, 1. Handlungsschritt, a)

Dort ist ein Netzplan abgebildet, der hat so ein paar Fehler und man soll diese beschreiben, deren Auswirkungen darstellen und und die Fehlerbeseitigung beschreiben. Gut. Nun hat ein Client in einem originären /24er Subnetz mit 192.168.1.X IPs eine 16er Subnetzmaske, also 255.255.0.0 anstatt 255.255.255.0. IP und Gateway aber alles gut.

Mir ist völlig klar, dass das ein Fehler ist. Aber was ist denn in diesem Zusammenhang die konkrete Auswirkung?

Ich habe das mal hier lokal versucht nachzuvollziehen (allerdings mit Linux only) und hab erstmal kein Problem gehabt. Alle konnten sich anpingen und anderweitig erreichen.

Kann mir da jemand helfen, wo mein Denkfehler liegt? Ich kann halt Beschreibung und Fehlerbeseitigung ausfüllen, aber weiß nicht recht was in die Auswirkung nun rein muss ^ ^

Danke euch.

Baba!

[legrx]

Achso, und der Gateway ist natürlich 192.168.1.254/24. Aber warum sollte der den Client nicht mehr "beliefern" können? Wenn die Subnetzsituation umgekehrt wäre, ok, aber so? Ich steh aufm Schlauch

[Gast Blub666]

Hm, wenn ich mich nicht irre, dann hat es prinzipiell keine Auswirkung auf die Kommunikation mit anderen /24 SN-Rechnern. Der besagte PC kann dann einfach nur mit noch mehr Rechnern (außerhalb des /8er Clientanteils) kommunizieren.

Aber nimm es für die Prüfung als Fehler hin. ;-)

[Gast UnknownX]

Vereinfacht: Die Sicht des Client A vergroessert sich, somit kommuniziert er alle ziele in dem 16er bereich ohne GW an. Das GW selbst verwaltet aber ein 24er subnet in dem sich auch Client A befindet. Wenn Client A nun ein rechner ausserhalb des eigentlichen 24er bereichs anpingt klappt das nicht. Denn der Zielrechner ist eigentlich in einem anderen subnet. Client A muesste also das GW nutzen. Tut er aber nicht, denn aus seiner sicht ist der Zielrechner mit im selben Subnetz.

[legrx]

Boom! :upps Natürlich. Ausgezeichnet. Danke euch!

Bearbeitet 4. Mai 2014 von legrx

[legrx]

Einen hätt ich noch: Winter 13/14:

Ping-Test von Workstation 2001:db8:45:c00:2e0:81ff:fe55:32a7 zum Server 2001:db8.45:C0F:2AE:3dff:fe45:cd07 - funktioniert nicht. Andere IPv6 Hosts können den Server aber erreichen. Nennen sie einen möglichen Grund für den fehlgeschlagenen Ping u. beschreiben sie eine Lösungsmöglichkeit.

ICMP Unterdrückung in der Firewall wohl nicht, andere können das ja. Es sei denn die Regeln werde pro Client erstellt, mh.

Kabel locker? Zumindest wurde ja nicht gesagt, dass die Workstation irgendwas anderes erreichen kann.

Typo in der Befehlseingabe?

anstatt ping6 -I Interface ipv6-Adresse ping ipv6-adresse genutzt?

Und ernsthaft?

Bearbeitet 4. Mai 2014 von legrx

[&&&]

hab den Netzwerkplan jetzt nicht vor mir aber denkbar wäre doch, dass ein, falls vorhanden, Router zwischen den beiden Netzwerkknoten nichts mit IPv6-Paketen anfangen kann.

[legrx]

Sicherlich möglich, ich hatte bei der Formulieren nur gedacht, man solle "rauslesen", dass das Problem wohl eher lokal gelagert sein muss.

[Gast Blub666]

Bei dieser Aufgabenstellung wird fast alles bewertet. Hatte mit einem Prüfer genau über diese Aufgabe gesprochen.

Er meinte, die ist so schwammig gestellt, dass dort fast alles genommen wird, was nur etwas sinn macht.

z. B.

Fehlkonfiguration bei der IPv6 Konfiguration

Ein Hop dazwischen, welcher mit dem Paket nichts anfangen kann. (z. B. ein nicht konfigurierter Router)

Rechner hängt im falschen VLAN

und so weiter. Also mach dir da kein Kopf drum. Auf doof gestellte Fragen, kann man auch doof antworten. ;-)

Werde ich am Mittwoch zu mindestens auch machen...