Unitymedia CMTS sendet ARP Anfragen an Anschluss

[rv112]

Hallo!

Seit Wochen beobachte ich dass mein für mich zuständiges CMTS ARP Requests via Broadcast an meinen Anschluss schickt. Dabei laufen ca. 100 kbit/s Traffic auf, bzw. rund 40-50 Anfragen pro Sekunde. Eine Anfrage sieht dabei so aus:

11	0.026159	Cadant_6b:xx:xx	Broadcast	ARP	60	Who has 37.209.65.171? Tell 37.209.64.1

Leider bin ich dagegen Machtlos. Kann das ebenfalls jemand beobachten?

 

[0rko]

Ist bei einem CMTS völlig normal. Deal with it.

 

[robert_s]

Broadcast an meinen Anschluss

Siehst Du den Fehler selbst, oder mit dem Zusatztipp "shared medium"...?

 

[rv112]

Mir war das zuvor nie aufgefallen.

 

[Wechseler]

ARP-Traffic ist zwar völlig normal, aber 50 Requests pro Sekunde? An meinem inaktiven HFC-Anschluß liefen zuletzt 8-9 MB Traffic pro Tag auf. Also unter 1 kbps im Durchschnitt.

 

[rv112]

Ne, hier laufen massig an Requests auf. Im Schnitt 100 kbit/s Traffic.

 

[0rko]

Je nachdem, wie viele Modems von einem CMTS bedient werden, gibt es mehr oder weniger ARP Traffic. Wenn ein normales Modem (TC4400) ohne integriertes Gateway (ConnectBox) verwendet wird, bekommt man das mit.

Wenn jetzt jemand ganz erstaunt ist, wenn es auch mal 100 kbit/s an ARP Traffic sind oder vielleicht sogar mehr. Iss so. Kann man auf Providerseite mit verschiedenen Ansätzen vorgehen aber das interessiert so gut wie keinen. Ausser den Leuten, die von ihrer verwöhnten Switched Ethernet Welt kommen

 

[robert_s]

Prinzipiell könnte natürlich auch ein Fehler vorliegen oder vielleicht auch eine DoS-Attacke auf das CMTS. Um das als Kunde zu ermitteln, müsste man den DOCSIS Management-Traffic analysieren, um herauszufinden, wie viele Kabelmodems es in dem Segment gibt, und dann analysieren, ob die ARP-Requests damit korrelieren, oder ob da z.B. erheblich mehr IPv4-Adressen gesucht werden als es Kabelmodems gibt, was ein Hinweis darauf wäre, dass da falsche ARP-Requests ins Segment gesendet werden.

 

[0rko]

Prinzipiell könnte natürlich auch ein Fehler vorliegen oder vielleicht auch eine DoS-Attacke auf das CMTS. Um das als Kunde zu ermitteln, müsste man den DOCSIS Management-Traffic analysieren, um herauszufinden, wie viele Kabelmodems es in dem Segment gibt, und dann analysieren, ob die ARP-Requests damit korrelieren, oder ob da z.B. erheblich mehr IPv4-Adressen gesucht werden als es Kabelmodems gibt, was ein Hinweis darauf wäre, dass da falsche ARP-Requests ins Segment gesendet werden.

Keine so gute Idee. Das IP Interface, welches die IP Adressen hält, versorgt weit mehr Segmente bzw. Mac Domains. Also nicht nur das eigene Segment. Aus diesem Grund sieht man z.B. auch die ARP Requests aus anderen Segmenten bzw. Mac Domains, welche vom CMTS über das selbe IP Interface versorgt werden.
Wenn so ein CMTS dann 10.000, 20.000, 30.000 Modems versorgt, gibt es eine Menge ARP Requests.

 

[Wechseler]

Ich würde 30 GB ARP-Traffic pro Monat trotzdem erstmal als ungewöhnlich einstufen. Das ist ja mehr, als ich teilweise als Nutztraffic habe.

 

[Ool3eiV3aetooChu]

Ich hatte immer schon viel arp traffic auf der Leitung…

<i>
</i>¯\(°_o)/¯ root@colossus:~ $ timeout 1m tcpdump -nn -i eth0 -w /dev/null arp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16914 packets captured
16927 packets received by filter
0 packets dropped by kernel

Bei 46 bytes (ohne padding) pro arp wären das dann ~760KiB pro Minute, also auch ca. 30GiB pro Monat.

 

[robert_s]

Keine so gute Idee. Das IP Interface, welches die IP Adressen hält, versorgt weit mehr Segmente bzw. Mac Domains. Also nicht nur das eigene Segment. Aus diesem Grund sieht man z.B. auch die ARP Requests aus anderen Segmenten bzw. Mac Domains, welche vom CMTS über das selbe IP Interface versorgt werden.
Wenn so ein CMTS dann 10.000, 20.000, 30.000 Modems versorgt, gibt es eine Menge ARP Requests.

Also mein CMTS in Berlin dürfte sicherlich ein "größeres" sein, aber ich habe nicht den Eindruck, dass derartige Massen von ARP-Requests hier hereinkommen.

Ich verstehe auch nicht, warum das CMTS nicht filtern können sollte, und einen ARP-Request nur in das Segment schickt, in welchem die MAC-Adresse, welcher diese IP-Adresse zuletzt zugewiesen wurde, zu finden ist. Diese Information muss ja stets durch das CMTS durch.

So verstehe ich auch den Punkt im DOCSIS-Standard, dass das CMTS als "ARP Proxy" fungieren soll, genau um eben die ARP-Requests zu filtern.

 

[Maurice]

Völlig normal. Kurze Momentaufnahme an meinem Anschluss (gemittelt über 5 Minuten):
ARP-Requests: 363/s
~ 134 kbit/s (368 Bit (46 Byte) pro ARP-Request)
~ 40,3 GiB/Monat
Sind bei einem 150Mbps-Anschluss ca. 0,1% der gebuchten Bandbreite. Also entspannt bleiben. :schnarch:

Dabei laufen ca. 100 kbit/s Traffic auf, bzw. rund 40-50 Anfragen pro Sekunde.

Das passt irgendwie nicht zusammen. Das wären 250 - 300 Byte pro ARP-Request.

An meinem inaktiven HFC-Anschluß liefen zuletzt 8-9 MB Traffic pro Tag auf. Also unter 1 kbps im Durchschnitt.

Dann wohnst Du entweder in einer sehr ruhigen Gegend ... oder Du erfasst die eingehenden Broadcasts auf dem WAN-Interface nicht.

 

[Ool3eiV3aetooChu]

Die Gateways fragen regelmäßig die IP-Adressen ihres Netzes ab – was sie auch sollen[1] –, aber mangels Netztrennung bekommt man die arps von jedem Gateway des Segments mit.

<i>
</i>¯\(°_o)/¯ root@colossus:~ $ tcpdump -nn -r arp.pcap | awk '/who-has/{print $7}' | sort | uniq -c
reading from file arp.pcap, link-type EN10MB (Ethernet) 76 10.131.128.1, 6 10.195.208.1, 98 10.2.16.1, 18 10.248.64.1, 16 10.248.88.1, 6 10.251.152.1, 6 10.251.184.1, 20 10.4.112.1, 12 10.42.48.1, 46 109.90.236.1, 788 178.202.152.1, 5756 88.152.120.1, 2 88.152.120.25, 6896 95.222.136.1, 1300 95.223.232.1, 1866 95.223.236.1,

Aber: Innerhalb einer Minute wurden teilweise bis zu 24 arp requests pro IP-Adresse gesendet:

<i>
</i>¯\(°_o)/¯ root@colossus:~ $ tcpdump -nn -r arp.pcap | cut -c17- | sort | uniq -c | sort -nr | head
reading from file arp.pcap, link-type EN10MB (Ethernet) 24 ARP, Request who-has 95.222.142.222 tell 95.222.136.1, length 46 24 ARP, Request who-has 88.152.127.104 tell 88.152.120.1, length 46 22 ARP, Request who-has 95.223.239.191 tell 95.223.236.1, length 46 22 ARP, Request who-has 95.223.238.38 tell 95.223.236.1, length 46 22 ARP, Request who-has 95.223.232.196 tell 95.223.232.1, length 46 22 ARP, Request who-has 88.152.127.82 tell 88.152.120.1, length 46 22 ARP, Request who-has 88.152.126.9 tell 88.152.120.1, length 46 22 ARP, Request who-has 88.152.126.223 tell 88.152.120.1, length 46 22 ARP, Request who-has 88.152.125.224 tell 88.152.120.1, length 46 22 ARP, Request who-has 88.152.125.210 tell 88.152.120.1, length 46

was imho ziemlich ungesund ist. Das ist entweder eine Fehlkonfiguration oder auf den Gateways läuft irgendwas, was am arp cache vorbeiläuft (oder ihn aus irgendwelchen Gründen nicht nutzen will).
Man könnte ja mal einen arpsponge ins Netz stellen und gucken, was passiert :naughty:

[1] ich könnte mir vorstellen, daß man die arptable auch aus den Informationen des DHCP-Servers füllen könnte

 

[addicted]

BTW, `sort -V` eignet sich hervorragend für IP-Adressen

 

[robert_s]

Sind bei einem 150Mbps-Anschluss ca. 0,1% der gebuchten Bandbreite. Also entspannt bleiben. :schnarch:

Warum sollten Broadcasts im Kabelsegment von der gebuchten Bitrate eines Anschlusses abgezogen werden...? Der Management-Traffic wird das ja auch nicht...

 

[Ool3eiV3aetooChu]

BTW, `sort -V` eignet sich hervorragend für IP-Adressen

Danke für den Tip
Wenn ich IP-Adressen sortieren wollte, hatte ich bisher meist

perl -ne 'print for sort {pack("C4"=>$a=~/\b(\d+)\.(\d+)\.(\d+)\.(\d+)\b/) cmp pack("C4"=>$b=~/\b(\d+)\.(\d+)\.(\d+)\.(\d+)\b/)}<>'

verwendet. Deine Lösung ist doch um einiges handlicher