☰

반무작위 연결 손실

tag-icon • tag-icon networking router audio modem
반무작위 연결 손실

복잡한 네트워크 문제가 있습니다.

맥락상 저는 한 위치에 여러 방송국이 있는 라디오 방송국 클러스터에서 일하고 있으며 오디오 콘텐츠를 전달하는 데 인터넷을 많이 사용합니다. 우리는 3개의 라디오 피드를 온라인 피드로 스트리밍하고, 두 개의 서로 다른 피드를 두 개의 서로 다른 타워 사이트로 푸시하여 오디오가 공중파로 방송되고, 두 개의 오디오 피드(때로는 3개)를 수신하고, 하나의 피드를 소스로 다시 보냅니다. 이 모든 스트리밍은 연중무휴 24시간 진행되므로 우리는 평균적인 사람보다 인터넷을 조금 더 많이 사용합니다. 연결이 끊어지지 않는 한 우리는 방송을 멈추지 않습니다.

우리는 한동안 연결 끊김으로 인해 어려움을 겪어 왔으며 이는 전문 라디오 방송국에게는 매우 문제가 되는 일입니다. 우리는 답변을 얻기 위해 인터넷 서비스 제공업체에 전화를 걸었고 문제를 조사하도록 시도할 때마다 빈손으로 돌아왔습니다.

처음에는 문제가 단지 패킷 손실인 줄 알았습니다. 그러나 나는 연결 손실이 단지 반 무작위적일 뿐이며 어떤 종류의 패턴이 있다는 것을 발견했습니다. 각 스테이션은 무음 센서에 연결되어 있어 스테이션이 방송을 중단할 경우 경고를 보냅니다. 이러한 경고는 다른 의미를 가질 수 있습니다. 하지만 우리에게 있어 알림은 인터넷 연결 중단을 알리는 것일 뿐입니다. 이 문제를 해결하기 위해 다른 위치에서 오디오를 수신하는 두 스테이션에서 수집한 정보를 사용하고 있습니다. 소스로부터 오디오 수신이 중단되면 경고가 전송됩니다.

첫째, 대부분의 경우 연결 중단은 새로운 시간이 시작되기 2분 전(12:58, 4:58, 1:58)에만 발생하기 때문에 연결 문제가 완전히 무작위로 발생하는 것은 아닙니다. 연결 문제는 새로운 시간이 시작되기 약 2분 전에 발생하는 경우가 90% 이상이라고 말하고 싶습니다. 하지만 확실하게 확인해야 할 것 같아요. 한 시간 전 2분에 연결이 끊기는 것은 나에게는 충분히 이상하지만 그 이상의 일이 있다.

연결 중단은 매시간 또는 매일 같은 시간 동안 발생하지 않습니다. 연결이 중단되는 시간은 매일 다릅니다. 그리고 더욱 이상한 점은 한 스테이션은 한 시간이 끝나기 2분 전에 네트워크 중단이 발생하는 반면 다른 스테이션은 중단이 발생하지 않을 수 있다는 것입니다. 실제로 각 역은 새로운 시간이 시작되기 2분 전에 연결이 끊어지지만, 두 역이 동시에 다운되는 경우는 본 적이 없는 것 같습니다. 따라서 연결 문제는 하루 중 임의의 시간에 발생할 뿐만 아니라 각 스테이션마다 다른 시간에도 발생합니다. 유일한 공통점은 '한' 시간이 끝나기 약 2분 전에 연결 끊김이 발생한다는 것입니다.

지금은 역에 없어서 우리가 사용하고 있는 정확한 장비를 제공할 수는 없지만 설정은 상당히 간단합니다.

Netgear Prosafe 24 포트 스위처에 연결된 모뎀이 있습니다. 그런 다음 스위처는 건물의 개별 공간에 신호를 공급합니다. 일반적으로 각 방에는 작은 4~8포트 스위처(다양한 브랜드)가 있습니다. 그러면 오디오를 수신하는 오디오 처리 장치가 이러한 소형 스위처에 연결됩니다.

나는 여기서 완전히 헤매고 있습니다. 심지어 Comcast에게 그것이 우리 잘못이 아니라는 점을 설득하는 데에도 어려움을 겪고 있습니다. 지금은 주말 동안 24포트 스위처의 연결을 끊고 모뎀 뒷면의 4개 포트만 사용하여 중요/필수 장비에 전원을 공급할 생각입니다. (더 작은 스위처 중 하나 이상은 연결된 상태로 유지해야 할 것 같습니다.) , 그렇지만). 개입하는 기술이 없기 때문에 문제가 지속된다면 Comcast가 책임을 져야 할 것이라고 생각합니다.

어떤 도움이라도 큰 축복이 될 것입니다! 문제가 반 무작위인 이유는 무엇입니까? 문제의 원인을 찾으려면 어디서부터 시작해야 합니까? 저는 모뎀이 조금 의심스럽습니다. 모뎀을 교체할 무렵부터 문제가 발생하기 시작한 것 같습니다. 하지만 결국 나는 길을 잃었습니다... 길을 잃었습니다.. 길을 잃었습니다.

답변1

문제를 분리하는 것부터 시작하십시오. 네트워크를 외부에서 시작하여 문서/논리 흐름을 위해 작업하는 세그먼트로 논리적으로 나누겠습니다.

  • 인터넷(8.8.8.8은 Google DNS 서버이며 다운되지 않음)
  • ISP 연결 장치에서 ISP 네트워크로 한 번 홉
  • 모뎀
  • 라우터/NAT 장치
  • 내부 네트워크(192.168.xx, 172.20.xx, 10.xxx)

이러한 분석을 이해하면 우리는 내부에서 외부로 무엇을 가지고 있는지 알아내기 시작합니다. 그래서...

ipconfig 명령 사용

내부 장치(PC)에서 해당 장치/PC에 따라 네트워크의 모양을 확인합니다. 시작 | 실행 | cmd Enter ipconfigEnter

그러면 IP/서브넷/게이트웨이가 제공됩니다(첫 번째 계층 문제 해결을 위해 비활성화된 경우 무선 연결이 아니길 바랍니다).

다음과 같아야 합니다:

Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : removed
   IPv4 Address. . . . . . . . . . . : 192.168.0.100
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.1

다른 것이 아닌 이더넷/로컬 영역 연결 장치를 사용하고 있는지 확인하세요. 현재 있는 장치는 IPv4 주소: 192.168.0.100입니다. NAT 장치/라우터는 기본 게이트웨이입니다: 192.168.0.1

ping 명령 사용

이제 네트워크 장치와 NAT/라우터 장치 간의 연결 테스트를 시작합니다. 명령 프롬프트에서는 ping 명령 유형을 사용합니다.

ping 192.168.0.100 -t

또는

ping -t 192.168.0.100

기본적으로 당신이 하고 있는 일은 장치에 안녕하세요라고 말하는 것입니다. 그리고 그 장치는 응답해야 합니다(우리가 상황이 이상해질 수 있는 인터넷의 한가운데에 들어갈 때까지).

좋은 반응:

Reply from 192.168.0.100: bytes=32 time<1ms TTL=64

나쁜 반응:

Destination Host Unreachable

또는

Request timed out

아니면 다른 것

이 명령의 -t는 중지하라고 지시할 때까지( Ctrl+ c또는 X로 창을 닫음) 1초마다 정보 패킷을 계속 보내는 것을 의미합니다. -t를 사용하지 않으면 4개의 패킷만 수행하고 중지됩니다.

이제 링크를 테스트하는 방법을 알았으므로 네트워크의 모든 링크/연결에 대해 ping 명령을 사용하고 어디에서 문제가 발생하는지 살펴보겠습니다.

Tracert 명령 사용

마지막으로 해야 할 일은 사용자와 인터넷 사이의 링크(이중 NAT 또는 두 개의 NAT 장치라고 함)에 이상한 것이 없는지 확인하고 ISP 모뎀 외부에 있는 장치가 무엇인지 확인하는 것입니다.

명령 프롬프트에 다음을 입력하세요.

tracert google.com<kbd>Enter</kbd>

당신은 다음과 같은 것을 얻게 될 것입니다 :

tracert google.com

Tracing route to google.com [74.125.21.138]
over a maximum of 30 hops:

1    <1 ms    <1 ms    <1 ms  router [192.168.0.1]
2     2 ms     1 ms     1 ms  device [10.1.10.1]
3     1 ms     1 ms     1 ms  blah.somename.whatever [123.123.123.123]
4     1 ms     1 ms     1 ms  124.124.124.124
5     *        *        *     Request timed out.

....더 많은 내용이 있을 예정입니다. 중지하려면 Ctrl+를 사용하세요.C

중요한 것은 각 줄의 [] 사이에 있는 장치의 IP 주소입니다. 참고: 위의 ipconfig 테스트에서 기본 게이트웨이 IP 뒤의 행이 192.168.xx, 172.20.xx, 10.xxx 패턴(라우팅할 수 없는 개인 서브넷) 중 하나와 일치하는 경우 이중 NAT가 있는 것이므로 다른 이상한 문제가 발생할 수 있습니다. 여기서는 이에 대해 다루지 않겠습니다.

마지막으로 필요한 정보는 네트워크의 공개 IP입니다. www.ipchicken.com으로 이동하세요. 그 숫자가 귀하의 공개 IP입니다.

이제 이 모든 정보를 바탕으로 무엇을 테스트할까요?

  1. 본인(다음 항목에서 문제가 발생하지 않는 한 일반적으로 이 항목은 건너뜁니다.): 192.168.0.100

  2. NAT 라우터에 대한 연결: 192.168.0.1

  3. 아이치킨번호 : 123.123.123.125

  4. ISP 모뎀(공용 게이트웨이) 외부의 첫 번째 홉: 123.123.123.123

  5. Google의 DNS 서버: 8.8.8.8

따라서 위에서 설명한 핑 테스트를 사용하면 최대 5개의 명령 프롬프트 창이 열려 핑으로 각 홉을 테스트할 수 있습니다. 각 장치 사이에 문제가 될 수 있는 것이 무엇인지 다시 한번 살펴보겠습니다.

ping 192.168.0.100

- 100%가 아닌 경우 NIC 문제가 있거나 IP 스택이 손상되어 재구축이 필요한 것입니다.

ping 192.168.0.1

- 100%가 아닌 경우 PC와 스위치/라우터 사이의 내부 배선 문제가 있는 것입니다. 네트워크 케이블/스위치/라우터를 따르고 교체하기 시작하세요. - 여기에 이중 NAT가 있는 경우 후속 홉에서 문제가 발생하기 시작합니다.

ping 123.123.123.125

- ISP 모뎀에 문제가 있습니다. 테스트해 보세요. - 네트워크 분할 용어로 우리는 DMARC 또는 로컬 회사 네트워크(IT 담당자의 문제)와 ISP 네트워크 사이의 경계를 교차하고 있습니다.

ping 123.123.123.123

- 인터넷 연결에 문제가 있습니다. ISP에서 로그인하여 인터넷 연결을 확인해야 합니다. 모뎀이 다음 ISP 장비 세트에 제대로 연결되지 않아 문제를 해결해야 합니다. - 케이블 ISP는 전원(보통 +-10)과 SNR(신호 대 잡음비)을 확인해야 하며 허용 가능한 범위를 알려주어야 합니다. 범위 내에 있지 않으면 ISP 기술을 배포해야 합니다. - DSL에서는 소음 프로필을 확인하도록 해야 하며 사양 내에 있어야 합니다. 여기서는 전화선에 연결된 모든 장치에 필터를 설치하는 것이 문제가 될 수 있습니다.

ping 8.8.8.8

이것은 웹 어딘가에 있으며 ISP는 이것이 사실인지 아닌지에 대한 타당성을 거부할 것입니다. Tracert 체인을 더 자세히 살펴보면 문제가 발생하기 시작하는 위치를 파악하는 데 도움이 될 수 있습니다. 이름은 운 좋게 네트워크 경계가 변경될 때 이를 식별하는 데 도움이 됩니다.

IT직에 오신 것을 환영합니다 :)

관련 정보