최근에 사무실에 광섬유 라인을 설치했는데, 현재 겪고 있는 약간의 문제를 제외하고는 모든 것이 잘 작동하고 있으며 네트워크 응답도 정말 놀랍습니다.
우리가 겪고 있는 문제는 때때로 라우터가 조각나서 패킷을 삭제한다는 것입니다. 라인도 아니고 스위치도 아닙니다. 라우터 자체이고 하드웨어를 교체했는데 두 부분 모두 그렇게 합니다. 제가 사용하고 있는 장비는 Juniper Netscreen SSG5입니다. 증상은 다음과 같습니다.
나는 "내부" 인터페이스에 대해 pingflood를 수행합니다.
ping -f -c 10000 <internal-ip>
10,000개의 응답을 받았습니다. 매번. 그런 다음 외부 인터페이스의 IP 주소를 제외하고 동일한 작업을 수행합니다(그러나 여전히 동일한 장치에 있음). 10,000개 중 10~15개 패킷이 삭제됩니다. 회사의 다른 모든 게이트웨이에 대해 동일한 테스트를 수행했지만 다른 어떤 것도 이 동작을 보여주지 않았습니다. 나는 당황했다.
광섬유 회사의 지원팀과 이야기를 나눴는데 두 인터페이스 모두 전이중으로 100Mb로 하드 코딩되어 있어 문제가 발생할 수도 있습니다. 그런데 라우터 내부에서 외부 인터페이스에 ping을 하면 패킷이 손실되는 일이 전혀 없어 인터페이스 자체가 아닌가 하는 생각이 듭니다. 그리고 로컬 인터페이스는 패킷을 잃지 않으므로 스위치가 아닙니다.
하드웨어 자체의 디자인을 제외하고는 문제가 어디에 있는지 솔직히 잘 모르겠습니다. 그래프를 보았는데, 심지어 pingflood 중에도 라우터의 CPU나 메모리를 최대화하는 데는 거의 도달하지 못했습니다.
어떤 제안이 있으십니까?
편집하다
Tom의 경우: 광섬유는 13Mb/s이지만 인터페이스를 ping할 때 광섬유로 넘어가지 않습니다. 로컬 LAN은 100Mb/s로 실행되고 있으며 내부 인터페이스는 모든 패킷에 응답합니다. 다른 하드웨어를 빌릴 수 있는지 알아봐야겠지만, 다른 사이트에 같은 증상을 보이지 않는 구형 모델인 Junipers(5GT)가 있습니다.
답변1
다음 두 가지 사항을 염두에 두십시오.
- 라우터는 SSG5에 대해 구체적으로 잘 알지 못하지만 라우터로 전달되는 ICMP 트래픽을 제한할 가능성이 높습니다.
- 140MBit/sec의 전달 속도는 트래픽이 진행되고 있다고 가정합니다.~을 통해라우터; 해결된 트래픽에게모든 패킷이 라우터의 자체 IP 스택으로 전달되고 응답 패킷을 생성해야 하므로 라우터는 추가 성능 저하를 유발합니다.
시도해 볼 몇 가지 테스트:
- LAN에서 핑플러딩을 시도해보세요~을 통해라우터; 아마도 WAN 링크의 원격 끝일까요? (귀하의 서비스 제공업체가 소유한 경우 처리 능력이 더 뛰어난 것일 것이라고 가정합니다.)
- 달리다아이퍼프사무실에 있는 노드와 인터넷 외부의 노드 사이에서 귀하가 어떤 모습으로 형성되고 있는지에 대한 좋은 아이디어를 얻을 수 있습니다.
답변2
그냥 아이디어인데.. 그런데 섬유의 속도는 얼마나 되나요? 라우터의 백플레인이 실제로 해당 속도로 패킷을 이동할 수 있습니까? 스위치 포트의 연결을 최대화하여 Cisco 857의 이더넷 버퍼를 채우는 것과 비슷한 문제가 있었습니다.
SSG5는 최신 버전의 ScreenOS를 실행하고 있습니까? 최신 펌웨어 업데이트?
사양에서는 초당 140Mbit 또는 30,000개의 패킷을 이동할 수 있다고 주장합니다. 그렇지 않을 수도 있지만 더 강력한 라우터가 트래픽을 처리할 수 있을까요?
다른 사람에게서 더 큰 장치를 빌릴 수 있나요? 아마도 Cisco 2811이나 Juniper J2320이 아닐까요?
답변3
AT&T(파이버/메트로 이더넷)로 전환했을 때도 비슷한 문제가 있었습니다.
라우터의 인터페이스에 오류가 표시됩니까? Cisco를 사용하면 인터페이스에 따라 CRC 또는 입력 오류가 표시됩니다.
우리는 마침내 자동 또는 100/전체가 "고착"될 때까지 각 위치에 대해 자동, 10/반 및 전체, 100/반 및 전체 사이의 다양한 협상 방법을 교환하여 문제를 해결했습니다. 또한 대역폭 제한에 문제가 있는지 확인하기 위해 공급자에게 13Mbps 제한을 일시적으로 제거하도록 요청할 수도 있습니다.
AT&T는 자신들이 사용한 스위치(또한 Cisco)에 문제가 있다고 비난했지만 대체 모델로 교체하지는 않았습니다. 오류가 발생하지 않고 100/전체 작업(하드 코딩 또는 자동 협상을 통해)이 발생하지 않는 한 우리는 관심을 멈췄습니다.
오늘날까지도 우리는 여전히 일부 사무실을 자동으로 사용하고 일부는 100/완전히 사용하고 있습니다. 단지 그것이 효과가 있었고 우리는 그것을 깨뜨리고 싶지 않기 때문입니다.