Kleine Netzmasken statt local-proxy-arp im flachen DSL-Netz
Ich habe das Problem, dass DSLAMs das DSL-Netz segmentieren, während die Layer2 Wolke es als ein durchgehendes Netz ansehen. Ein Lösungsvorschlag ist, die Layer2 Wolke zu drastisch zu verkleinern. Dies probiere ich aus.
Ausgangslage
Die DSLAMs verhindern eine direkte Kommunikation von CPEs, die an diesem einem DSLAM angeschlossen sind. Eine Firma kann also nicht mit ihren Mitarbeitern im gleichen Dorf kommunizieren, wenn diese von zu Hause arbeiten wollen.
Die kanonische Lösung mit local-proxy-arp besteht darin, dass der Router die ARP-Antworten fälscht und damit die Kommunikation wieder ermöglicht. Leider macht das massiv Probleme, wenn man Redundanz oder mehrere zentrale Geräte in das Netz bringen will.
Netzmaske verkleinern
Wie ich gelernt habe, besteht die branchenübliche Lösung darin, dem Endgerät (CPE) eine extrem kleine Netzmaske (/32) zu geben. Damit glaubt das Endgerät es sei alleine am Netz.
Aber wie erreicht es sein Gateway? Das liegt doch außerhalb des zugewiesenen Netzes? Was man bräuchte wäre folgendes:
# ip address add a.b.c.d/32 dev eth # ip route a.b.c.e/32 dev eth # ip route 0.0.0.0/0 via a.b.c.e
Aber wie bekommt man so etwas Krankes der CPE beigebogen? Schließlich hat sich der Kunde den Router selbst gekauft und wir haben keinen Einfluss auf die Kiste.
Alles was, wir tun können, ist eine passende DHCP Antwort schicken. Also probiere ich das mal (ganz vorsichtig)
subclass "Dynamisch" 1:00:90:33:1f:19:1a {option subnet-mask 255.255.255.255;}
subclass "Dynamisch" 1:9c:c7:a6:ba:e0:1b {option subnet-mask 255.255.255.255;}Das sollte tun (Pools etc. sind anderweitig konfiguriert).
Und nun der Test vom Router aus:
cisco#ping 198.51.100.128 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.51.100.128, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms cisco#ping 198.51.100.201 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.51.100.201, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms cisco#sh arp | in 198.51.100.128|198.51.100.201 Internet 198.51.100.201 2 9cc7.a6ba.e01b ARPA Vlan140 Internet 198.51.100.128 2 0090.331f.191a ARPA Vlan140
Tada! Das tut doch schon mal. Und Tests an dem Gerät bestätigen auch die Funktionalität des Internets.
Andere Server
Nun der kompliziertere Teil. Wie kommen zentrale Geräte, die nicht das Gateway sind, mit dem Setup klar?
Probieren wir's aus:
linux# ip addr add 198.51.100.108/23 dev eth_slot linux# ping -c2 198.51.100.201 PING 198.51.100.201 (198.51.100.201) 56(84) bytes of data. 64 bytes from 198.51.100.201: icmp_seq=1 ttl=64 time=7.01 ms 64 bytes from 198.51.100.201: icmp_seq=2 ttl=64 time=6.83 ms --- 198.51.100.201 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 6.834/6.922/7.011/0.121 ms
Und der Tcpdump dazu sagt:
13:36:57.930798 00:1b:21:2d:3a:bb > 9c:c7:a6:ba:e0:1b, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.201: icmp 64: echo request seq 1 13:36:57.937778 9c:c7:a6:ba:e0:1b > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.201 > 198.51.100.108: icmp 64: echo reply seq 1 13:36:58.935366 00:1b:21:2d:3a:bb > 9c:c7:a6:ba:e0:1b, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.201: icmp 64: echo request seq 2 13:36:58.942188 9c:c7:a6:ba:e0:1b > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.201 > 198.51.100.108: icmp 64: echo reply seq 2
Geht hin und her. Die Pakete kommen direkt von der CPE (eine Fritzbox) und reden mit dem Server.
Stop mal! Warum kommen die Pakete direkt? Sollten die nicht über den Router gehen?
Offensichtlich hat die Fritzbox gelernt, dass sie dieses Gerät direkt am WAN-Bein erreichen kann und schickt auch die Pakete direkt.
Genauer gefragt: Ist das ein Problem?
Wenn zwei CPEs miteinander reden sollen, aber nicht können (DSLAM-Sperre), dann können sie gegenseitig ihre ARP-Anfragen nicht sehen und beantworten. Also werden sie nie versuchen, direkt miteinander zu kommunizieren. Also kein Problem.
Apropos ARP. Da waren keine ARP-Pakete im Tcpdump. Also nochmal mit gelöschtem ARP-Cache.
linux# arp -d 198.51.100.201 linux# ping -c2 198.51.100.201 PING 198.51.100.201 (198.51.100.201) 56(84) bytes of data. 64 bytes from 198.51.100.201: icmp_seq=2 ttl=63 time=6.97 ms --- 198.51.100.201 ping statistics --- 2 packets transmitted, 1 received, 50% packet loss, time 999ms rtt min/avg/max/mdev = 6.970/6.970/6.970/0.000 ms
Und der Dump dazu:
13:46:38.389346 00:1b:21:2d:3a:bb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 198.51.100.201 tell 198.51.100.108 13:46:38.390063 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 60: arp reply 198.51.100.201 is-at 00:07:b4:00:8c:02 13:46:38.390073 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.201: icmp 64: echo request seq 1 13:46:38.396544 9c:c7:a6:ba:e0:1b > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 60: arp reply 198.51.100.201 is-at 9c:c7:a6:ba:e0:1b 13:46:39.389251 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.201: icmp 64: echo request seq 2 13:46:39.396208 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.201 > 198.51.100.108: icmp 64: echo reply seq 2
Das erste Paket ging über local-proxy-arp und wurde nicht beantwortet.
Das könnte daran liegen, dass die Fritzbox bereits einen ARP EIntrag hat, so dass sie das ankommende Paket als gespooft verwirft. Aber das bedarf noch der Klärung.
Innovaphone
Die andere Test-CPE ist eine Innovaphone.
linux# arp -d 198.51.100.128 linux# ping -c2 198.51.100.128 PING 198.51.100.128 (198.51.100.128) 56(84) bytes of data. 64 bytes from 198.51.100.128: icmp_seq=2 ttl=127 time=5.86 ms --- 198.51.100.128 ping statistics --- 2 packets transmitted, 1 received, 50% packet loss, time 1000ms rtt min/avg/max/mdev = 5.860/5.860/5.860/0.000 ms
Auch das geht! Aber auch hier fehlt das erste Paket. Liegt es am proxy ARP?
13:56:05.356955 00:1b:21:2d:3a:bb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 198.51.100.128 tell 198.51.100.108 13:56:05.359382 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 60: arp reply 198.51.100.128 is-at 00:07:b4:00:8c:02 13:56:05.359392 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 1 13:56:05.362879 00:90:33:1f:19:1a > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 64: arp reply 198.51.100.128 is-at 00:90:33:1f:19:1a 13:56:06.356946 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 2 13:56:06.362793 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 2
Diesmal erfolgt der Ping komplett über den zentrale local-proxy-arp Router.
Und noch ein Pingtest bei vorhandenem ARP-Eintrag:
linux# ping -c2 198.51.100.128 PING 198.51.100.128 (198.51.100.128) 56(84) bytes of data. 64 bytes from 198.51.100.128: icmp_seq=1 ttl=127 time=6.02 ms 64 bytes from 198.51.100.128: icmp_seq=2 ttl=127 time=5.84 ms --- 198.51.100.128 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 5.841/5.930/6.020/0.118 ms
Und der Dump dazu:
14:09:37.939110 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 1 14:09:37.945105 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 1 14:09:38.943687 00:1b:21:2d:3a:bb > 00:07:b4:00:8c:02, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 2 14:09:38.949516 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 2
Die Kommunikation erfolgt komplett über den Router.
Stop mal! Warum antwortet die Innovaphone nicht auf ARP? Für einen zentralen Server heißt das, dass er auf local-proxy-arp angewiesen ist.
Aber genau diese Funktion soll doch abgeschaltet werden! Das ist genau der Zweck der Übung.
Bei einem Versuch einige Minuten später zeigt sich erstaunlicherweise ein anderes Bild
14:23:44.753899 00:1b:21:2d:3a:bb > 00:90:33:1f:19:1a, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 1 14:23:44.759817 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 1 14:23:45.757222 00:1b:21:2d:3a:bb > 00:90:33:1f:19:1a, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 2 14:23:45.762979 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 2
Die Pakete werden direkt an die Innovaphone gesendet, aber über den Router beantwortet. Das ist komplett in Ordnung!
Aber was ist da passiert? Ich lösche nochmal den ARP-Cache auf dem Linux und schnüffle mit:
14:38:22.492139 00:1b:21:2d:3a:bb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 198.51.100.128 tell 198.51.100.108 14:38:22.498015 00:90:33:1f:19:1a > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 64: arp reply 198.51.100.128 is-at 00:90:33:1f:19:1a 14:38:22.498027 00:1b:21:2d:3a:bb > 00:90:33:1f:19:1a, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 1 14:38:22.503751 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype IPv4 (0x0800), length 98: IP 198.51.100.128 > 198.51.100.108: icmp 64: echo reply seq 1 14:38:22.509747 ac:f2:c5:df:30:3f > 00:1b:21:2d:3a:bb, ethertype ARP (0x0806), length 60: arp reply 198.51.100.128 is-at 00:07:b4:00:8c:02 14:38:23.497404 00:1b:21:2d:3a:bb > 00:90:33:1f:19:1a, ethertype IPv4 (0x0800), length 98: IP 198.51.100.108 > 198.51.100.128: icmp 64: echo request seq 2
Die Innovaphone scheint sich diesmal kooperativer zu verhalten. Damit hat sie den Test auch bestanden.
Fazit
Der Ansatz scheint zu tun.
- Ein Fritzbox als CPE tut wie erwartet. Die bedient andere Geräte im gleichen Layer2 Netzwerk direkt, sobald sie ARP-Kontakt hatte.
- Eine Innovaphone als CPE tut völlig korrekt. Der Rückweg geht immer den konfigurierten Weg über den Router. Im Test hatte sie sich ab und zu mal zickig, aber kein prinzipelles Problem.
Beide benutzen den Router, der außerhalb ihres logischen Netzsegementes liegt, korrekt. Andere zentrale Komponenten werden ebenso behandelt.
Damit steht einer schrittweisen Einführung nichts prinzipelles im Wege.