Warum more specifics für die DHCP-Pools?

Moin,

wir nutzen ein /20 pro Mesh, heruntergebrochen auf /23 pro Gateway. Durch die unten verlinkte Funktion entstehen aus dem /23 5 putzige Mini-Netze, und das dann je Gateway je Mesh (Domäne):

root@l2tp-ham02 ~ # ipcalc 10.255.130.16 - 10.255.131.255 | grep -v "deaggregate" | sed -e 's/\(^.*$\)/route \1 via \"bat99\";/g'
route 10.255.130.16/28 via "bat99";
route 10.255.130.32/27 via "bat99";
route 10.255.130.64/26 via "bat99";
route 10.255.130.128/25 via "bat99";
route 10.255.131.0/24 via "bat99";

Sinn der Übung war vermutlich, fehlgeleiteten Traffic »außen« am Mesh vorbei zum richtigen Gateway zu schicken? Allein: ob der nun bei gw01 statt gw04 ins Mesh geht, auf welches die /20-Route ja zeigt, ist doch egal, durch muß es da sowieso? Zudem, welcher Traffic soll das sein?

Die Frage ist also »ist das Kunst oder kann das weg?« :wink:

Moin,

die Idee ist, das auf den DHCP-Bereich des jeweiligen Gateways runterzubrechen, weil meiner Erfahrung nach Verbindungen innerhalb vom Fledermausmann pro Sprung signifikant langsamer werden.

Wenn man runde Bereiche für die DHCP-Server hat, sollte das eigentlich nicht zu kleinzellig werden.

Wir könnten das aber optional machen. Bin nicht mehr so sicher, ob das viel bringt.

Viele Grüße
Matthias