DHCP Probleme - Störende Clients

Technik Infrastruktur / Backbone
1

Wie vielleicht der Ein oder Andere schon mitbekommen hat, habe ich mir heute ein bisschen DHCP angeschaut.
Dabei ist mir aufgefallen, dass ein Client besonders oft einen DHCP-Request absendet (Auswertung der dhcpd.leases).

Bei näherer Betrachtung viel mir auf, dass entsprechender Client (ein Device der Firma HTC (MAC: bc:cf:cc:xx:xx:xx) in 20 Minuten etwa 4500 DHCP Requests gestellt hat (Damit verursachte dieser Client ~ 45% des gesamten BOOTP/DHCP Traffics auf diesem GW). Auch unter der Annahme, dass Clients häufiger Nachfragen, da unser Netz überlastet ist, ist das eine viel zu hohe Anzahl.

Leider konnten wir den Knotenbetreiber (noch) nicht erreichen. Daher haben wir uns entschieden den Client im DHCPD zu blocken, respektive ihm nicht mehr zu antworten. Nun sendet der Client etwa 40 bis 60 DHCP Discover Anfragen pro SEKUNDE (die zum Glück vom Batman gewrappt werden und nur einem Gateway-Server aufgetischt werden).

Dennoch konnten wir durch diese Blockade den Gateway-Server (Paradox) stark entlasten (siehe: https://freifunk-muensterland.de/grafana/dashboard/db/gateway-details, Blockade um 22:20 aktiviert). Außerdem hat sich umgehend die Anzahl der Clients ohne gültiges DHCP Lease von ~190 auf etwa 85 mehr als halbiert ( https://freifunk-muensterland.de/grafana/dashboard/db/gateway-ubersicht ).

Wir hoffen, dass wir in den nächsten Tagen Kontakt zum Knotenbetreiber aufnehmen können und das Problem endgültig beheben können.

Stay tuned…

PS: Wenn ich hier von DHCP rede, meine ich DHCPv4.
PPS: Mir sind heute noch 1-2 weitere Clients mit einem änhnlichen Verhalten aufgefallen.
PPPS: Ich will nicht unbedingt dem Client das Problem in die Schuhe schieben, auffällig war, das bei betroffenen Clients die Anzahl der Hops bis zum DHCP Server recht hoch war. Auf der anderen Seite waren an den entsprechenden Knoten weitere Clients angemeldet, die offensichtlich nicht solche Probleme verursacht haben.

3 „Gefällt mir“
2

Gute Arbeit.

3

Es gibt ne Option um alle leases eines Client freizugeben, wenn der eine neue bestellt. Kann man bestimmt nur für dessen MAC anstellen. Gute Arbeit!

4

Great!

Können wir direkt in der Knotenfirmware iptables-Regeln definieren?

Dann könnten wir dort schon eine maximale Rate von DHCP-Anfragen wegfiltern. Ich kann mir gut vorstellen, dass das eine App ist, die schnelles Netz verspricht oder so. Alternativ ginge das auch pro VPN-Anschluss auf den Gateways.

40-60 Anfragen / Sekunde sind, obwohl ich den Standard gerade nicht im Kopf habe, sicher nicht zugelassen. 1-2 / 10 Sekunden wäre normal.

So könnte man BTW sowieso das Netz flach legen: Massenhaft DHCP-Requests schicken, von wechselnden MAC-Adressen.

Bevor hier wieder “Netzneutralität” angeprangert wird: Niemand braucht mehr als eine Anfrage pro Sekunde, das entspräche schon 30 neu angemeldete Clients pro Minute (bei 1 Request und einer Retransmission pro Client).

5

Kannst du das als iptables Regel forumlieren?

RFC

The client SHOULD wait a minimum of ten
seconds before restarting the configuration process to avoid
excessive network traffic in case of looping.
6

Moin,

weiß gerade nicht, ob auf Server oder Client. Passende Regeln sowohl für
einen speziefischen Client, als auch zum generellen Limiten gibt es hier:

http://dhcp-users.isc.narkive.com/0p6gbnmi/limit-dhcp-requests-with-iptables-problem-router

Alternativ könnte man auch überlegen, den Uplink-Nodes über ein Skript
Lease-Bereiche zu verteilen und die dann DHCP machen zu lassen. Dann
gäbe es auch kein Problem bei wackeligen Uplinks…

7

Ok Rate Limit für DHCP habe ich da gesehen allerdings scheint das global zu sein und nicht pro Client (was ja besser wäre da sonst auch “vernüftige Clients” an dem Router runtergezogen werden).

Any iptables wizards in the house?

8

Ich bin aus Gründen die ich am Wochenende beschreiben will, wieder dazu über gegangen eine Bridge vor das Bateman zu setzten. Dann kann man mit ebtables eine MAC zentral aussperren.

2 „Gefällt mir“
9

Mir ist gerade aufgefallen, dass teilweise gleiche bootp.id / Transaction ID häufiger vorkommen. Das sieht schon fast so aus, als wäre irgendwo ein loop. Ich schaue gerade, wie ich daraus eine Statistik bauen kann.

1 „Gefällt mir“
10

Nunja, auf den Nodes deployed wäre es egal. Wie schon geschrieben: Beim Durchlassen von 1 Paket /Sekunde könnten sich immer 10 Clients parallel mit DHCP-Adressen versorgen. Das ist schon die Hälfte einer 841-Kapazität.

11

Über Nacht habe ich auf parad0x einen tcpdump laufen lassen, dabei ist mir wie oben schon geschrieben aufgefallen, dass teilweise die Transaktions-ID häufiger vorkommt.

Hier mal eine Auswahl (anonymisiert, sende ich auf Wunsch via verschlüsseltem Kanal zu):

     27 0x1880b96a    a4:e4:b8:xx:xx:xx
     28 0x1f9b905f    a4:e4:b8:xx:xx:xx
     28 0x1fb08603    00:cd:fe:xx:xx:xx
     28 0x1fb08615    00:cd:fe:xx:xx:xx
     32 0x1b9ebd6c    a4:e4:b8:xx:xx:xx
     34 0x26318813    a4:e4:b8:xx:xx:xx
     39 0x8c3e783b    78:ca:04:xx:xx:xx
     40 0xcfb40468    60:36:dd:xx:xx:xx
     52 0x3776891b    40:6f:2a:xx:xx:xx
     54 0x8c365b5f    40:6f:2a:xx:xx:xx
     74 0x43327829    48:9d:24:xx:xx:xx
     81 0x7085493c    a4:e4:b8:xx:xx:xx
     86 0xf504c308    40:6f:2a:xx:xx:xx
     87 0x9a153016    a4:e4:b8:xx:xx:xx
    104 0x15437e78    a4:e4:b8:xx:xx:xx
    114 0xe2a42124    a4:e4:b8:xx:xx:xx
    120 0xe3d1c511    a4:e4:b8:xx:xx:xx
    123 0xf0eb4b39    a4:e4:b8:xx:xx:xx
    184 0xef4f4778    48:9d:24:xx:xx:xx
    213 0x6d2d6b62    a4:e4:b8:xx:xx:xx
    223 0x18198478    30:b5:c2:xx:xx:xx
    226 0x4e87c975    ec:1a:59:xx:xx:xx
    281 0xb888ce5f    a4:e4:b8:xx:xx:xx
    316 0x72917d25    00:d8:13:xx:xx:xx
    330 0xdda12f15    a4:e4:b8:xx:xx:xx
    445 0x93499a6e    40:6f:2a:xx:xx:xx
    535 0x53694376    94:eb:cd:xx:xx:xx
    539 0xa6065810    a4:e4:b8:xx:xx:xx
    561 0x6250a555    94:eb:cd:xx:xx:xx
    696 0xa9c0406e    52:54:00:xx:xx:xx
    743 0xdc3c23c9    00:1b:21:xx:xx:xx

Die Auswertung wurde mit folgendem (zusammengeschusterten) Befehl erstellt (ich denke das kann man auch direkt mit tshark machen, aber da bin ich noch zu blöd zu):

tshark -r dhcp_fail_dump -R bootp.id -T fields -e bootp.id -e bootp.hw.mac_addr | sed -e "s/,.*$//" | sort | uniq -c | sort -n

Hängt man noch ein 

| wc -l
dahinter, bekommt man die Anzahl der unique Transaktions-ID, MAC Tupel: 44735

Den TCP Dump habe ich ca. 10 Stunden auf parad0x laufen gehabt mit folgendem Befehl:

tcpdump -i bat0 port 67 or port 68 -w dhcp_fail_dump

Dabei wurden 166726 Pakete aufgezeichnet.

Bei einigen wenigen Clients im Netz scheint gehörig was schief zu laufen. Ob es letztendlich an diesen Clients oder an einer gehörigen Macke im Netz liegt, gilt es noch zu ermitteln.