從我們在佩塔提夸和內坦亞的以色列節點（AS206446，CLOUD LEASE）的 Ping，發送 ICMP 回聲請求並記錄來回時間。這些位置的典型 RTT：特拉維夫至法蘭克福約 52–60 ms、至阿姆斯特丹約 58–66 ms、至倫敦約 62–70 ms、至巴黎約 55–63 ms、至紐約約 128–138 ms、至杜拜約 25–35 ms、至新加坡約 145–165 ms。這些基準假設在以色列國際閘道無擁塞情況下，透過 FLAG 或 SEA-ME-WE 容量的乾淨電纜路由。

同時從兩個以色列節點執行 Ping 對確認一致性很有用。兩個節點在同一 AS 和都會區，因此對同一目標的兩者之間有意義的不同 RTT，將表明本地路由差異——例如一個節點使用不同的上游過境路徑——而非地理差異。實際上，佩塔提夸和內坦亞的結果對大多數目標相差在 2–4 ms 以內。

ICMP 速率限制在從以色列朝歐洲的過境路由器上很常見，特別是在多個電信業者匯聚流量的海底電纜著陸站。若從以色列的 Ping 顯示比預期高的 RTT，但同一主機的 TCP 檢測以預期速度完成，差異是 ICMP 處理而非真實路徑擁塞。MTR 追蹤中在特定跳的 ICMP RTT 升高但下游無丟包，可確認這一點。

以色列的網際網路基礎設施集中在特拉維夫都會區，全國主要的 IX 設施、資料中心和電信業者機房均位於此。IIX（以色列網際網路交換中心）運營主要對等互連架構，供國內 ISP、內容供應商和 CDN PoP 使用。ISUOG 作為次要 IX。兩者均位於特拉維夫都會走廊，以色列電信業者和主機代管基礎設施的大部分均實體設於此。我們的探測節點所在的佩塔提夸和內坦亞，兩城市相距約 15 公里，均在此都會集中區內。

以色列的國際連線幾乎完全透過海底電纜出境。FLAG 和 SEA-ME-WE 電纜系統在海法和特拉維夫上岸，透過地中海提供前往歐洲的主要容量。次要路徑透過西奈半島的埃及陸上路由。特拉維夫至法蘭克福的路徑在路由良好的電纜容量上約 50–60 ms。特拉維夫至倫敦約 60–68 ms。特拉維夫至紐約透過跨大西洋電纜約 125–135 ms。這些 RTT 與南歐位置相當，使以色列在歐洲 CDN 基礎設施的有用範圍內。

主要以色列電信業者包括運營主要國內固定線路骨幹的 Bezeq International（AS8551）、Partner Communications（AS12400）、HOT Telecom（AS5486）和 Cellcom。商業 ISP 和主機代管市場由包括 CLOUD LEASE（AS206446）在內的其他業者服務，CLOUD LEASE 託管我們兩個探測節點。AS206446 是在佩塔提夸和內坦亞有存在的雲端主機代管和主機代管業者，兩者都透過以色列國內骨幹連接，並向 IIX 和國際閘道進一步過境。

以色列的固定線路平均寬頻速度在該地區最高，由廣泛的光纖部署和競爭性的 ISP 定價驅動。以色列市場的對等互連狀況對其地理位置而言異常良好——透過海底電纜靠近歐洲，以及積極參與 IIX，意味著許多歐洲 CDN 邊緣以與南歐使用者相當的延遲服務以色列。Akamai、Cloudflare 和 AWS 均在特拉維夫地區維護邊緣 PoP。

我們在以色列運營兩個探測節點——一個在佩塔提夸，一個在內坦亞——均透過 CLOUD LEASE（AS206446）。在同一 AS 和都會區有兩個節點，意味著結果通常一致，但同時執行兩者可確認沒有任何節點有本地路由異常。對於有 Anycast 或 GeoDNS 的目標，鑑於兩個節點的地理接近性和共享上游，兩者應返回相同或幾乎相同的結果。