ExpressRoute 연결 문제 해결

8분

ExpressRoute는 프라이빗 광섬유 연결을 통해 작동하여 인터넷을 통해 직접 연결하는 것보다 빠른 Azure 연결을 제공합니다. 이 단원에서는 ExpressRoute 연결에서 발생할 수 있는 문제를 해결하는 방법을 알아봅니다.

다음 다이어그램은 네트워크(고객 네트워크)와 Azure(Microsoft Datacenter) 간의 연결을 보여 줍니다.

ExpressRoute를 사용하려면 활성 Microsoft Azure 계정이 있어야 합니다.

또한 Microsoft 365 서비스에 연결하려면 하나 이상의 Microsoft 365 계정이 필요합니다. 그러나 Microsoft 365는 인터넷을 통한 연결에 최적화되어 있으므로 특정 사례에만 권장됩니다.

또한 서비스 공급자와 협력하여 프라이빗 연결을 관리해야 합니다.

구독 필요	Microsoft Azure	Microsoft Azure 및 Microsoft 365
Microsoft Azure 계정	권장	권장
Microsoft 365	권장하지 않음	권장

게이트웨이 및 SKU

ExpressRoute는 가상 게이트웨이를 사용하여 Azure 가상 네트워크를 온-프레미스 네트워크에 연결합니다.

가상 네트워크 게이트웨이는 게이트웨이 서브넷에 배포되는 둘 이상의 VM으로 구성됩니다. 게이트웨이 VM은 라우팅 테이블을 포함하며 특정 게이트웨이 서비스를 실행합니다.

게이트웨이에는 VPN 및 ExpressRoute의 두 가지 유형이 있습니다. VPN 게이트웨이는 인터넷을 통해 암호화된 트래픽을 보냅니다. ExpressRoute 게이트웨이는 암호화되지 않은 연결을 통해 트래픽을 보냅니다. 게이트웨이를 구성할 때 유형을 ExpressRoute로 지정해야 합니다.

각 가상 네트워크에는 유형별로 하나의 게이트웨이가 있을 수 있으므로 다음과 같이 구성할 수 있습니다.

VPN 트래픽용 가상 네트워크 게이트웨이: Vpn을 입력합니다.
ExpressRoute 트래픽용 가상 네트워크 게이트웨이: ExpressRoute를 입력합니다.

또한 사용하려는 게이트웨이 SKU도 구성할 수 있습니다. SKU는 게이트웨이에 할당된 대역폭을 말합니다. 게이트웨이 SKU가 높을수록 CPU 및 네트워크 대역폭 처리량이 늘어납니다. ExpressRoute 게이트웨이는 다음 SKU를 지원합니다.

Standard
고성능
초고성능
ErGw1Az
ErGw2Az
ErGw3Az

게이트웨이 SKU를 업그레이드하려면 다음 PowerShell cmdlet을 사용할 수 있습니다.

Resize-AzVirtualNetworkGateway

또는 Azure Portal 가상 네트워크 게이트웨이 구성 창에서 구성을 변경합니다. 다음 업그레이드가 지원됩니다.

표준에서 고성능으로
표준에서 초고성능으로
고성능에서 초고성능으로
ErGw1Az에서 ErGw2Az로
ErGw1Az에서 ErGw3Az로
ErGw2Az에서 ErGw3Az로
기본에서 표준으로

다음 다운그레이드가 지원됩니다.

고성능에서 표준으로
ErGw2Az에서 ErGw1Az로

필요한 업그레이드 또는 다운그레이드가 지원되지 않는 경우 게이트웨이를 삭제하고 다시 만듭니다.

ExpressRoute 게이트웨이를 만들려면 먼저 서브넷의 IP 주소를 포함하는 게이트웨이 서브넷을 설정해야 합니다.

Azure Portal에서 가상 네트워크를 선택하고 서브넷을 선택한 다음 게이트웨이 서브넷 만들기를 선택합니다. 게이트웨이 서브넷의 IP 주소 범위를 구성하는 경우 ExpressRoute 게이트웨이와 VPN 게이트웨이가 공존하는 구성에는 큰 게이트웨이 서브넷이 필요합니다. 또한 게이트웨이 서브넷에 향후 추가 구성을 포함하기에 충분한 IP 주소가 포함되어 있어야 합니다. /27 이상(/27, /26 등)의 게이트웨이 서브넷을 권장합니다.

게이트웨이 서브넷은 ExpressRoute에만 사용됩니다. 게이트웨이 서브넷에 다른 항목을 할당하지 마세요.
이름이 GatewaySubnet이어야 합니다.
0.0.0.0/0 대상을 사용하는 사용자 정의 경로는 지원되지 않습니다.
GatewaySubnet의 NSG는 지원되지 않습니다.
BGP 경로 전파를 사용으로 설정합니다. 사용 안 함으로 설정된 경우에는 게이트웨이가 작동하지 않습니다.

가상 네트워크 게이트웨이 만들 때 게이트웨이 VM은 게이트웨이 서브넷에 배포되고 필수 ExpressRoute 게이트웨이 설정으로 구성됩니다.

참고

게이트웨이가 만들어지고 사용할 준비가 되는 데 최대 45분이 걸릴 수 있습니다.

ExpressRoute 회로가 작동하는지 확인

Azure Portal의 왼쪽 메뉴에서 모든 서비스>네트워킹>ExpressRoute 회로를 선택하여 기존 ExpressRoute 회로를 확인합니다.

구독에서 만든 모든 ExpressRoute 회로가 여기에 표시됩니다.

Screenshot of Expressroute circuits list.

회로를 작동하려면 서비스 공급자에게 서비스 키를 보내야 합니다. 각 서비스 키는 단일 회로에 고유합니다. 관련 회로를 선택하고 개요 페이지에서 해당 공급자의 서비스 키 필드를 찾습니다.

Screenshot of service key field.

공급자 상태에는 서비스 공급자 측의 프로비전 상태에 대한 정보가 표시됩니다.

회로 상태에는 Microsoft 측의 프로비전 상태에 대한 정보가 표시됩니다.

새 ExpressRoute 회로를 만들면 회로는 다음 상태가 됩니다.

공급자 상태: 프로비전되지 않음 회로 상태: 사용

회로는 서비스 공급자가 프로비전할 때 변경됩니다.

공급자 상태: 프로비전하는 중 회로 상태: 사용

ExpressRoute 회로는 다음 상태일 때 작동 중입니다.

공급자 상태: 프로비전됨 회로 상태: 사용

Azure PowerShell cmdlet을 사용하여 프로비전 상태를 확인할 수도 있습니다.

Get-AzExpressRouteCircuit -ResourceGroupName "Test-Resource" -Name "Test-Circuit"

출력에는 회로 프로비전 상태와 서비스 공급자 프로비전 상태가 모두 표시됩니다.

회로 상태가 사용 안 함 상태에서 멈춰 있으면 Microsoft 지원에 문의하세요.

공급자 상태가 프로비전되지 않음 상태에서 멈춰 있으면 서비스 공급자에게 문의하세요.

회로에 대한 피어링 구성의 유효성 검사

각 ExpressRoute 회로에는 Azure 개인 피어링과 Microsoft 피어링이 있을 수 있습니다. Azure 개인 피어링은 Azure의 개인 가상 네트워크에 대한 트래픽입니다. Microsoft 피어링은 PaaS 및 SaaS의 공용 엔드포인트에 대한 트래픽입니다.

피어링은 서비스 공급자에 의해 구성됩니다. 포털의 피어링이 여전히 비어 있는 경우 새로 고침을 사용하여 회로에서 현재 라우팅 구성을 끌어오세요.

ExpressRoute 회로 피어링의 상태는 Azure Portal의 ExpressRoute 회로 개요 페이지에서 확인할 수 있습니다. 모든 ExpressRoute 피어링은 피어링 섹션 아래에 표시됩니다.

위의 스크린샷에서 Azure 개인 피어링은 프로비전되었지만 Azure 공용 및 Microsoft 피어링은 프로비전되지 않았습니다. 또한 성공적으로 프로비전된 피어링에는 기본 및 보조 지점 간 서브넷도 나열됩니다.

피어링 사용에 실패하는 경우 할당된 기본 및 보조 서브넷이 연결된 CE/PE-MSEE의 구성과 일치하는지 확인합니다. 또한 올바른 VlanId, AzureASN 및 PeerASN이 MSEE에서 사용되는지와 이러한 값이 연결된 CE/PE-MSEE에서 사용된 값에 매핑되는지를 확인합니다. MD5 해싱을 선택하는 경우 공유 키가 MSEE 및 PE-MSEE/CE 쌍에서 동일해야 합니다. 보안을 위해 이전에 구성된 공유 키는 표시되지 않습니다.

참고

피어링 위치는 Microsoft와 피어링하는 물리적 위치를 나타냅니다. 위치 속성은 Azure 네트워크 리소스 공급자의 위치를 나타냅니다. 회로의 피어링 위치와 지리적으로 가까운 네트워크 리소스 공급자를 선택 하는 것이 좋습니다.

또한 MSEE(Microsoft Enterprise Edge) 디바이스에서 도착하고 출발하는 패킷을 계산하여 개인 피어링 연결을 테스트할 수도 있습니다. 이 도구를 사용하면 다음 질문에 대답하여 연결을 확인할 수 있습니다.

내 패킷이 Azure에 도착하나요?
내 온-프레미스 네트워크로 돌아가고 있나요?

Azure Portal에서 이 진단 도구에 액세스하려면 ExpressRoute 회로를 선택한 다음 진단 및 문제 해결을 선택합니다.

경로가 라이브 상태이고 올바로 구성되었는지 확인

피어링 연결을 테스트하여 경로가 라이브 상태이고 올바로 구성되었는지 확인할 수 있습니다. MSEE(Microsoft Enterprise Edge) 디바이스에서 ExpressRoute 회로의 에지에 도착하고 출발하는 패킷을 계산하여 개인 피어링 연결을 테스트합니다. 이 진단 도구는 ACL(액세스 제어 목록)을 MSEE에 적용하여 특정 ACL 규칙에 적중하는 패킷 수를 계산합니다. 이 도구를 사용하면 연결이 예상대로 작동하는지 확인할 수 있습니다.

이 진단 도구에 액세스하려면 Azure Portal의 ExpressRoute 회로에서 문제 진단 및 해결을 선택합니다.
일반적인 문제 아래에서 연결 문제를 선택합니다.
발생한 문제에 대해 자세히 알려주세요. 드롭다운에서 Azure Private, Azure Public 또는 Dynamics 365 서비스에 대한 연결을 선택합니다.
개인 피어링 연결 테스트 섹션까지 아래로 스크롤하여 펼칩니다.
PsPing 테스트를 온-프레미스 IP 주소에서 Azure IP 주소로 실행하고, 연결 테스트 동안 계속 실행합니다.
양식의 필드를 채웁니다. 앞서 사용한 것과 동일한 온-프레미스 및 Azure IP 주소를 입력해야 합니다. 제출을 선택하고 결과를 기다립니다. 결과가 준비되면 아래에서 해석하기 위한 정보를 검토합니다.

기본 및 보조 MSEE 디바이스에 대한 두 가지 결과 집합이 있습니다. 입력 및 출력 일치 항목 수를 검토하고, 다음 시나리오를 사용하여 결과를 해석합니다.
- 두 MSEE에서 보내고 받은 패킷 일치 항목이 표시됨 회로의 MSEE에서 정상적인 인바운드 및 아웃바운드 트래픽을 나타냅니다. 온-프레미스 또는 Azure에서 손실이 발생하는 경우 MSEE에서 다운스트림이 발생합니다.
- PsPing을 온-프레미스에서 Azure로 테스트하는 경우 받은 결과에는 일치 항목이 표시되지만 보낸 결과에는 일치 항목이 표시되지 않음: 트래픽이 Azure로 인바운드되지만 온-프레미스로 돌아오지 않음을 나타냅니다. 반환 경로 라우팅 문제가 있는지 확인합니다. Azure에 적절한 접두사를 보급하고 있는지 확인합니다. UDR 재정의 접두사가 있는지 확인합니다.
- PsPing을 Azure에서 온-프레미스로 테스트하는 경우 보낸 결과에는 일치 항목이 표시되지 않지만 받은 결과에는 일치 항목이 표시됨: 트래픽이 온-프레미스로 이동하지만 다시 돌아오지 않음을 나타냅니다. 공급자와 협력하여 ExpressRoute 회로를 통해 트래픽이 Azure로 라우팅되지 않는 이유를 확인해야 합니다.
- 한 MSEE에는 일치 항목이 없는 것으로 표시되고 다른 MSEE에는 양호한 일치 항목이 표시됨: 한 MSEE에서 트래픽을 받거나 전달하지 않음을 나타냅니다. 오프라인 상태인지 확인합니다(예: BGP/ARP 다운).

예제:

src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches

이 테스트 결과에는 다음과 같은 속성이 있습니다.

IP 포트: 3389
온-프레미스 IP 주소 CIDR: 10.0.0.0
Azure IP 주소 CIDR: 20.0.0.0

ExpressRoute 회로 다시 설정

ExpressRoute 회로의 작업이 성공적으로 완료되지 않으면 회로가 “실패” 상태가 될 수 있습니다. Azure PowerShell을 사용하여 실패한 ExpressRoute 회로를 다시 설정할 수 있습니다. 최신 버전의 Azure Resource Manager PowerShell cmdlet을 설치해야 합니다.

상승된 권한으로 PowerShell 콘솔을 열고 계정에 연결합니다. 연결에 도움이 되도록 다음 예제를 사용합니다.
```
Connect-AzAccount
```
Azure 구독이 여러 개인 경우 계정의 구독을 확인합니다.
```
Get-AzSubscription
```

사용할 구독을 지정합니다.

Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name"

다음 명령을 실행하여 실패한 상태의 회로를 다시 설정합니다.

$ckt = Get-AzExpressRouteCircuit -Name "ExpressRouteARMCircuit" -ResourceGroupName "ExpressRouteResourceGroup"

Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

이제 회로가 다시 설정되었습니다.

비대칭 라우팅 문제 해결

비대칭 라우팅은 반환 네트워크 트래픽이 외부로 나가는 원래 흐름과 다른 경로를 사용하는 경우입니다. 예를 들어 인터넷 경로와 프라이빗 경로가 동일한 대상으로 가는 경우입니다. 동일한 대상에 연결된 여러 프라이빗 경로가 있는 경우에도 발생합니다.

경로 추적은 네트워크 트래픽이 예상된 경로를 탐색하도록 하는 가장 좋은 방법입니다.

Azure ExpressRoute를 통해 연결하는 경우 여러 개의 Microsoft 링크를 사용할 수 있습니다. 기존 인터넷 연결과 ExpressRoute 연결이 있습니다. Microsoft로 향하는 트래픽은 인터넷 연결을 통과하지만 ExpressRoute 연결을 통해 반환될 수 있습니다. 또는 트래픽이 ExpressRoute를 통과하지만 인터넷 경로를 통해 반환될 수 있습니다.

ExpressRoute 회로에서 더 많은 특정 IP 주소가 수신됩니다. 따라서 ExpressRoute를 통해 제공되는 서비스를 위해 네트워크의 트래픽이 Microsoft로 이동하는 경우 트래픽은 ExpressRoute 연결로 라우팅됩니다.

비대칭 라우팅을 해결할 때 라우팅을 사용하거나 SNAT(원본 기반 NAT)를 사용하는 두 가지 옵션이 있습니다.

라우팅 옵션에서는 공용 IP 주소를 적절한 WAN(광역 네트워크) 링크에 보급합니다. 예를 들어 메일 트래픽에 대한 인증 트래픽 및 ExpressRoute에 인터넷을 사용하려면 ExpressRoute를 통해 AD FS(Active Directory Federation Services) 공용 IP 주소를 보급하지 않아야 합니다. 또한 라우터가 ExpressRoute로 수신하는 IP 주소에 온-프레미스 AD FS 서버를 노출하지 않아야 합니다. ExpressRoute를 통해 수신된 경로는 구체적이므로 ExpressRoute를 Microsoft에 대한 인증 트래픽의 기본 경로로 만듭니다.

인증을 위해 ExpressRoute를 사용하려는 경우 NAT 없이 ExpressRoute에 AD FS 공용 IP 주소를 보급합니다. 그러면 Microsoft에서 시작된 트래픽을 ExpressRoute를 통해 온-프레미스 AD FS 서버로 보냅니다. 네트워크에서 Microsoft로 가는 반환 트래픽은 인터넷을 통해 선호되는 경로인 ExpressRoute를 사용합니다.

또는 SNAT를 사용하여 비대칭 라우팅을 방지합니다. 예를 들어 인터넷을 통해 SMTP 트래픽을 보내려는 경우 ExpressRoute를 통해 온-프레미스 SMTP 서버의 공용 IP 주소를 보급하지 마세요.

Microsoft에서 시작되어 온-프레미스 SMTP 서버로 이동하는 요청은 인터넷을 통해 이동합니다. SNAT는 내부 IP 주소에 대한 들어오는 요청입니다. SMTP 서버의 반환 트래픽은 ExpressRoute 대신 경계면 방화벽(NAT에 사용함)으로 이동하여 반환 트래픽이 인터넷 경로를 취하도록 합니다.

경로 필터링 문제 해결

ExpressRoute 회로에서 피어링을 구성하는 경우 에지 라우터가 연결 공급자를 통해 에지 라우터와 쌍으로 연결된 BGP(Border Gateway Protocol) 세션을 설정합니다. 이 시점에서 경로는 네트워크에 보급되지 않습니다. 네트워크로 경로 보급을 사용하려면 경로 필터를 구성해야 합니다.

경로 필터를 사용하면 사용하려는 서비스를 식별할 수 있습니다. 허용되는 BGP 커뮤니티 값의 목록입니다. 경로 필터 리소스가 정의되고 ExpressRoute 회로에 연결되면 BGP 커뮤니티 값에 매핑되는 모든 접두사는 네트워크에 보급됩니다.

경로 필터를 Microsoft 365 서비스에 연결하려면 ExpressRoute를 통해 Microsoft 365 서비스를 사용할 수 있는 권한이 부여되어야 합니다. 이 권한 부여가 없으면 작업이 실패합니다.

Microsoft 피어링을 통해 액세스할 수 있는 서비스와 관련된 BGP 커뮤니티 값은 ExpressRoute 라우팅 요구 사항에서 확인할 수 있습니다.

경로 필터에는 하나의 규칙만이 있을 수 있고 이 규칙은 허용 유형이어야 합니다. 규칙과 연결된 BGP 커뮤니티 값의 목록을 연결할 수 있습니다.

필터 규칙을 만듭니다.

규칙을 추가하고 업데이트하려면 경로 필터에 대한 규칙 관리 탭을 선택합니다.
드롭다운 목록에서 연결하려는 허용된 서비스 커뮤니티를 선택합니다. 완료되면 규칙을 저장합니다.

중복 구성 문제 해결

각 ExpressRoute 회로에는 고가용성을 보장하기 위한 중복 쌍의 교차 연결이 있습니다. 교차 연결 중 하나가 실패하면 연결이 끊어지지 않습니다. 중복 연결은 연결 및 고가용성을 제공합니다.

각 Azure VPN 게이트웨이는 두 개의 인스턴스로 구성되며 둘 다 활성 대기 상태입니다. 활성 인스턴스에 유지 관리 또는 계획되지 않은 중단이 발생하면 대기 인스턴스가 자동으로 인수(장애 조치(failover))합니다.

경로 업데이트 문제 해결

네트워크 라우팅은 네트워크 트래픽이 대상에 도달하는 경로를 결정하는 방법입니다. 경로 테이블은 네트워크 토폴로지 정보를 나열하여 라우팅 경로를 확인하는 데 사용됩니다. 가상 네트워크에 NVA(네트워크 가상 어플라이언스)가 포함된 경우 경로 테이블을 수동으로 구성하고 업데이트해야 합니다.

Azure Route Server를 사용하면 가상 네트워크에서 NVA를 구성, 유지 관리, 배포할 수 있습니다. 또한 Route Server는 가상 네트워크 주소 정보를 최신 상태로 유지합니다. Route Server는 경로 테이블을 유지 관리하는 관리 오버헤드를 제거합니다.

또는 Azure의 기본 경로를 재정의하는 정적 경로를 정의할 수 있습니다. 또는 서브넷의 경로 테이블에 경로를 추가할 수 있습니다. 사용자 정의 경로를 생성하거나 온-프레미스 네트워크 게이트웨이와 Azure 가상 네트워크 게이트웨이 간에 BGP(경계 게이트웨이 프로토콜) 경로를 교환하여 사용자 지정 경로를 만듭니다.

경로 업데이트 문제를 해결하려면 다음을 시도해 보세요.

가상 어플라이언스는 트래픽이 라우팅되는 경로 테이블과 동일한 서브넷에 배포하지 마세요. 이로 인해 트래픽이 서브넷을 벗어나지 못하는 라우팅 루프가 발생할 수 있습니다.
다음 홉 개인 IP 주소는 ExpressRoute 게이트웨이 또는 Virtual WAN을 통한 라우팅 없이 직접 연결되어야 합니다. 다음 홉을 직접 연결되지 않은 IP 주소로 설정하면 잘못된 사용자 정의 라우팅 구성이 발생합니다.

ExpressRoute 대기 시간 문제의 근본 원인 식별

ExpressRoute의 대기 시간 문제를 해결하기 위해 Azure 연결 도구 키트에는 iPerf라는 도구가 포함되어 있습니다.

파일을 호스트의 디렉터리에 복사하여 iPerf를 기본 성능 테스트에 사용합니다. 성능을 테스트하려면 다음 단계를 수행합니다.

PowerShell 모듈을 설치합니다.
```
(new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
```
이 명령은 PowerShell 모듈을 다운로드하고 로컬로 설치합니다.
지원 애플리케이션을 설치합니다.
```
Install-LinkPerformance
```
이 AzureCT 명령은 "C:\ACTTools"라는 새 디렉터리에 iPerf 및 PSPing을 설치합니다. 또한 ICMP 및 5201(iPerf) 트래픽 포트를 허용하기 위해 Windows 방화벽 포트를 엽니다.
성능 테스트를 실행합니다.

첫째, 원격 호스트에서 iPerf를 서버 모드로 실행하고 설치해야 합니다. 원격 호스트가 3389(Windows용 RDP) 또는 22(linux용 SSH)에서 수신 대기하고 5201 포트에서 iPerf에 대한 트래픽을 허용해야 합니다. 원격 호스트가 Windows인 경우 AzureCT를 설치하고 Install-LinkPerformance 명령을 실행 합니다. 이 명령은 iPerf 및 필요한 방화벽 규칙을 설정합니다.

원격 컴퓨터가 준비되면 로컬 컴퓨터에서 PowerShell을 열고 테스트를 시작합니다.
```
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
```
이 명령은 네트워크 링크의 대역폭 용량과 대기 시간을 예측할 수 있도록 일련의 동시 부하 및 대기 시간 테스트를 실행합니다.
테스트의 출력을 검토합니다.

iPerf 테스트의 구체적인 결과는 "C:\ACTTools"의 AzureCT 도구 디렉터리에 있는 개별 텍스트 파일에 들어 있습니다.

PowerShell 출력 형식은 다음과 비슷합니다.

Screenshot of PowerShell output of test.

성능 테스트가 예상한 결과와 다른 경우 단계별 프로세스를 사용하여 문제를 해결합니다.

첫째, 가정이 올바른지 점검합니다. ExpressRoute 회로가 1Gbps이고 대기 시간이 100ms인 경우 대기 시간이 긴 링크에서 TCP가 갖는 특징을 고려할 때 1Gbps를 예상하는 것은 합리적이지 않습니다.

둘째, 라우팅 도메인 사이의 에지에서 시작하여 문제를 단일 주요 라우팅 도메인으로 격리하는 것이 좋습니다. 회사 네트워크, WAN 또는 Azure 네트워크에서 시작할 수 있습니다. 서비스 공급자 또는 ISP에 문의해야 하는 합리적인 이유가 있어야 합니다. 더 이상 문제 해결을 제어할 수 없기 때문입니다. 그러면 수정 작업이 지연될 수 있습니다.

문제가 있는 것으로 보이는 주요 라우팅 도메인을 식별한 후에는 다이어그램을 작성합니다. 다이어그램에서 영역을 확인하면 테스트할 지점을 계획하여 체계적으로 작업할 수 있습니다. 네트워크를 세그먼트로 분할하여 문제의 범위를 좁히고 결과를 얻으면 다이어그램을 업데이트합니다.

잊지 말고 OSI 모델의 다른 레이어도 확인해야 합니다. 네트워크 및 레이어 1~3(물리적, 데이터 및 네트워크)에 초점을 맞추기 쉽지만 애플리케이션 레이어의 레이어 7에 문제가 있을 가능성도 있습니다. 열린 마음으로 가정을 확인합니다.

참고

엔드포인트 간의 지리적 대기 시간은 대기 시간의 가장 큰 구성 요소입니다. 물리적 및 가상 구성 요소, 홉 수와 같은 장비 대기 시간이 포함됩니다. 그러나 지리는 WAN 연결을 처리할 때 전체 대기 시간에 더 큰 영향을 미치는 것으로 나타났습니다. 또한 광섬유 거리는 직선 또는 로드맵 거리가 아니라는 것을 이해하는 것이 중요합니다. 정확하지는 않지만 충분히 좋은 도시 거리 계산기를 사용하세요.

계속