UDP-Checks von unseren israelischen Knoten senden ein Paket an den angegebenen Port und warten auf eine Antwort. Dies ist relevant für das Testen von DNS-Resolvern, WireGuard- oder OpenVPN-Endpoints, SIP-Infrastruktur und Game-Servern, die für israelische Nutzer erreichbar sein müssen. Die israelische ISP-Infrastruktur blockiert ausgehendes UDP auf kommerziellen Verbindungen nicht, sodass ein Keine-Antwort-Ergebnis von unseren Knoten darauf hinweist, dass die Blockierung auf der Zielseite oder im Transit liegt und nicht innerhalb Israels.

Für VPN- oder Tunneling-Dienste mit israelischen Nutzern bestätigt ein UDP-Check von AS206446, ob der Endpoint von einem der israelischen Haupt-Hosting-ASNs aus erreichbar ist. WireGuard-Endpoints antworten auf einen UDP-Probe nicht, es sei denn, der Peer ist konfiguriert – ein Keine-Antwort-Ergebnis ist für korrekt deploytes WireGuard normal. OpenVPN UDP und Game-Server-Protokolle, die auf einen Probe tatsächlich eine nicht-authentifizierte Antwort senden, bestätigen die Erreichbarkeit durch das Zurücksenden eines beliebigen Pakets.

Das gleichzeitige Ausführen von UDP-Checks auf beiden israelischen Knoten ist ein schneller Konsistenztest. Da beide Knoten denselben Upstream (AS206446) und internationalen Transit-Pfad teilen, würden unterschiedliche Ergebnisse zwischen den beiden zum selben Ziel auf eine knotenspezifische Routing-Anomalie hindeuten. Konsistente Keine-Antwort von beiden bestätigt, dass das Problem nicht knotenspezifisch ist, sondern ein allgemeines Problem mit dem Pfad von israelischen Netzen zum Ziel darstellt.

Israels Internetinfrastruktur konzentriert sich auf den Großraum Tel Aviv, wo sich die wichtigsten IX-Einrichtungen, Rechenzentren und Carrier Hotels des Landes befinden. IIX (Israel Internet Exchange) betreibt den primären Peering-Fabric, der von inländischen ISPs, Content-Providern und CDN-PoPs genutzt wird. ISUOG fungiert als sekundärer IX. Beide befinden sich im Metro-Korridor Tel Aviv, wo der Großteil der israelischen Carrier- und Hosting-Infrastruktur physisch untergebracht ist. Petah Tikva und Netanya – die beiden Städte, in denen unsere Probe-Knoten betrieben werden – liegen etwa 15 km voneinander entfernt und fallen beide in diese metro-konzentrierte Zone.

Internationale Konnektivität aus Israel verläuft fast ausschließlich über Seekabel. Die FLAG- und SEA-ME-WE-Kabelsysteme landen in Haifa und Tel Aviv und bieten primäre Kapazität in Richtung Europa durch das Mittelmeer. Ein sekundärer Pfad verläuft über Land via Ägypten durch den Sinai. Der Pfad Tel Aviv – Frankfurt beträgt auf gut gerouteter Kabelkapazität ungefähr 50–60 ms. Tel Aviv nach London liegt bei etwa 60–68 ms. Tel Aviv nach New York beträgt über transatlantisches Kabel ungefähr 125–135 ms. Diese RTTs sind mit südeuropäischen Standorten vergleichbar und platzieren Israel in einem nützlichen Latenzbereich zur europäischen CDN-Infrastruktur.

Zu den großen israelischen Carriern gehören Bezeq International (AS8551), der das inländische Festnetz-Backbone betreibt, Partner Communications (AS12400), HOT Telecom (AS5486) und Cellcom. Der kommerzielle ISP- und Hosting-Markt wird von weiteren Anbietern bedient, darunter CLOUD LEASE (AS206446), der beide unserer Probe-Knoten hostet. AS206446 ist ein Cloud-Hosting- und Colocation-Anbieter mit Präsenz in Petah Tikva und Netanya, beide angebunden über das israelische inländische Backbone mit anschließendem Transit zu IIX und internationalen Gateways.

Israel hat eine der höchsten durchschnittlichen Festnetz-Breitbandgeschwindigkeiten in der Region, angetrieben durch weitreichende Glasfaser-Deployments und wettbewerbsfähige ISP-Preise. Der israelische Markt ist für seinen geografischen Standort ungewöhnlich gut gepeert – die Nähe zu Europa über Seekabel und aktive Teilnahme am IIX bedeutet, dass viele europäische CDN-Edges Israel mit Latenz bedienen, die mit dem vergleichbar ist, was südeuropäische Nutzer sehen. Akamai, Cloudflare und AWS unterhalten alle Edge-PoPs in der Region Tel Aviv.

Wir betreiben zwei Probe-Knoten in Israel – einen in Petah Tikva und einen in Netanya – beide über CLOUD LEASE (AS206446). Da beide Knoten im selben AS und Großraum liegen, sind die Ergebnisse typischerweise konsistent, aber das gleichzeitige Ausführen beider bestätigt, dass keiner der Knoten eine lokale Routing-Anomalie aufweist. Für Ziele mit Anycast oder GeoDNS sollten beide Knoten identische oder nahezu identische Ergebnisse liefern, angesichts ihrer geografischen Nähe und des gemeinsamen Upstreams.