Gateyway Load Sharing - Statistische Verzögerung eingehender DHCP Pakete

[Tom Green]

Hallo,

also ich hab mich mal an der Idee versucht (teils zusammen "ge-goggle-d"):

  * Auf dem GW eingehende DHCP Broadcasts werden erkannte, wenn
      o keine IP Adresse (0.0.0.0)
      o an UDP port 67
      o von UDP port 68
  * davon wird jedes "n-te" Paket heraus gegnommen und markiert
  * und dann um 250 ms verzögert

Müsste man versuchen zu testen. Meinungen?

P.S.:

  * Bin mir nicht sicher, wie man die Verzögerung messen kann. Evtl. ein
    Testlauf auf nue1, wobei jedes eintreffende DHCP Paket verzögert wird
  * Noch cleverer wäre es, das DHCPOFFER zu verzögern. Das habe ich
    iptable-technisch aber nicht zu greifen gekriegt
  * Die Batman GW selection sollte nicht so schnell aus dem Rennen, weil
    (a) einfach, (b) vorhanden / out-of-the-box

Gruß...
Torben

=== statistic-dhcp-delay.sh ====
#!/bin/bash

IF=bat0
IFSPEED=10Mbps    # Get from sudo /sbin/ethtool $IF
DELAY=250ms
PORT_C=68         # DHCP Client
PORT_S=67         # DHCP Server
PROTO=UDP         # DHCP IP Protocol
Nth=3             # act on every nth package


#
# Create a tree of classful HTB objects
#
/sbin/tc qdisc add dev $IF handle 1: root htb

#
# Create a classful child bucket with classid 1:11
#
/sbin/tc class add dev $IF parent 1: classid 1:11 htb rate $IFSPEED

#
# Create a qdisc (classless) netem child to provide a delay for packets
in this 'bucket'
#
/sbin/tc qdisc add dev $IF parent 1:11 handle 11: netem delay $DELAY

#
# Filter mangled/marked traffic to the above class
#
/sbin/tc filter add dev $IF parent 1:0 prio 1 protocol ip handle 11 fw
flowid 1:11

#
# Use iptables to mangle TCP packets to port $PORT  and mark packet for
tc filtering
#
#/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source 0.0.0.0
--dport $PORT_S --sport $PORT_C -j MARK --set-mark 11
#/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source 0.0.0.0
--dport $PORT_S --sport $PORT_C -j LOG --log-prefix "Incoming DHCP
traffic: "

/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source 0.0.0.0
--dport $PORT_S --sport $PORT_C -m statistic --mode nth --every $Nth
--packet 0 -j MARK --set-mark 11
/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source 0.0.0.0
--dport $PORT_S --sport $PORT_C -m statistic --mode nth --every $Nth
--packet 0 -j LOG --log-prefix "Incoming DHCP traffic: "





On 11.09.2015 17:50, Michael Sessler wrote:
> Hallo delphiN, > > Ich hätte spontan an ein zufälliges Delay gedacht, so dass per
Zufallsprinzip irgendeiner der Schnellste ist. Statistisch sollte sich
die Last dann verteilen. > Aber wenn man das von der eigenen Systemlast
abhängig machen könnte, wäre es sogar noch cleverer. > Ich finde die
Idee gut. > > DerMichy > > Am 11.09.2015 um 17:06 schrieb delphiN:
> Am 11.09.2015 16:54, schrieb Tim Niemeyer:
> >>> Wer in der Netztopologie am schnellsten den DHCP Request
> >>> beantwortet,
> >>>> wird zum GW. Das ist in der Regel fff-nue. Wer am weitesten weg
> >>>> ist, bekommt fast keine Clients, das ist in der Regel meiner ;)
> Ich hab da auch schon öfters mal drüber nachgedacht.
>
> Ein Ansatz wäre es auf den Gateways einen speziellen DHCP-Server zu
> verwenden, der eine gewisse Zeit abwartet, bis er antwortet.
> Diese kleine Verzögerung könnte man z.B. von der Anzahl der
> VPN-Verbindungen, oder dem aktuellen Netzwerkdurchsatz abhängig
> machen. So könnte man die Last dynamischer verteilen ohne eine
> zentrale Steuerung zu schaffen.
> Wenn Ihr die Idee gut findet würde ich mir das man anschauen.
> Eingelesen hab ich mich schon und halte es für einen gangbaren Weg.
>
> delphiN
>
> -- freifunk at wunschik.net
> delphiN at jabber.ccc.de
> Mitglied: Freie Netze e.V., CCC, Piratenpartei
>
>
> > >


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20150914/995493a2/attachment-0002.html>