좋아요, 제 상황은 이렇습니다.
이것은 인터넷에 있습니다. 6224는 이 그림의 라우터이며 물리적으로 Kanata에 상주합니다.
VLAN 1697과 3994는 모두 인터넷 서비스 제공업체에서 제공합니다. 이러한 VLAN은 단일 1Gb 이더넷 회선을 통해 제공됩니다.
Kanata 호스트는 6224에 직접 연결됩니다. 다른 두 사이트는 원격입니다.
VLAN 3994는 단일 IP 주소 공간이므로 이론적으로 해당 서브넷의 호스트가 어디에 있는지는 물리적으로 중요하지 않습니다.
여기에 문제가 있습니다.
인터넷에 추가로 연결된 모니터링 시스템이 있으므로 모니터의 프로브가 1697 VLAN의 이 다이어그램으로 들어옵니다.
인터넷에서 Albert 또는 Bells Corners의 호스트에게 ping을 보내면 손실이 0입니다. 연결이 완벽해 보입니다.
Kanata에서 호스트에 핑을 보낼 때 핑의 10~40%가 손실됩니다. 손실은 예측할 수 없지만, 손실이 발생하면 항상 최소 3개, 일반적으로 4개, 드물게 그 이상 핑을 한 묶음으로 잃습니다.
3994년 카나타에 있는 6224에 모니터를 직접 부착해봤습니다..
모니터가 6224 라우팅 인터페이스에 ping을 보내면 정확히 동일한 손실 패턴이 보이지만 원격 시스템의 손실과 동시에 나타나는 것은 아닙니다. 핑 시간은 약 1ms입니다.
모니터가 6224에 직접 연결된 다른 시스템에 ping을 보내면 손실이 0이 됩니다. 핑 시간은 약 0.1ms로, 라우터를 핑하는 시간의 1/10입니다.
여기서 무슨 일이 일어나고 있는지 아는 사람 있나요?
상황을 덜 명확하게 하기 위해 업데이트하세요.
무슨 일이 일어나고 있는지는 ISP의 연결에 들어오고 나가는 트래픽이 괜찮다는 것입니다. 라우터 브레인에서 스위칭 브레인(또는 그 반대로)으로 이동하는 트래픽이 문제를 일으키는 것입니다.
두 원격 사이트 간의 인터넷 액세스가 안정적이기 때문에 ISP를 비난할 수는 없습니다. 문제가 있는 것은 6224에 직접 연결된 호스트뿐입니다.
업데이트 2
좋아요, 흔적을 오랜 시간 관찰한 후에 좀 더 구체적인 증상이 나타났습니다.
나는 ISP 업링크의 vlan 3994에서 tcpdump를 수행하여 내가 봐야 할 것은 원격 사이트로 이동하는 브로드캐스트 트래픽뿐이라는 이론에 따라 내 주소를 찾았습니다. 대신, 이 VLAN의 TLS를 따라 내려가는 내 시스템 인터페이스에서 볼 것으로 예상했던 패킷을 보았습니다.
그래서:
어떤 이유에서인지 6224는 내 시스템이 TLS의 맨 끝에 있다고 생각하는 경우가 많습니다.
작동 중일 때 스위칭 테이블을 검사하면 내 항목은 다음과 같습니다.
3994 0007.E924.F714 2/g16 Dynamic
...포트 16에 연결되어 있으므로 이는 의미가 있습니다. 그러나 연결이 끊어지면 다음과 같이 보입니다.
3994 0007.E924.F714 2/g22 Dynamic
잘못된 방향의 패킷 스트림이 내 시스템의 브로드캐스트에 의해 유도되는 것 같습니다. 그러나 하나의 브로드캐스트가 내 시스템에서 나가고 두 개는 3994 VLAN에서 TLS로 전송되는 것을 볼 수 있습니다. 일반적으로 이는 IGMP V2 멤버십 보고서/그룹 가입 224.0.0.251이지만 때로는 내 시스템의 관리 칩이 자체적으로 침입하는 경우도 있습니다(어리석은 이유로 2초마다 이 작업을 수행함).
이는 Bells Corners 또는 Albert에 내 방송을 듣고 어떤 이유로든 이를 다시 에코하는 시스템이 있음을 의미합니다. 그래서 6224는 아, 이 맥은 정말로 TLS 링크 아래에 있어야 하고 이에 따라 스위칭 테이블을 조정해야 합니다.
문제에 대한 이 설명이 어떤 종소리를 울리나요?
답변1
좋아, 나는 이것을 알아냈고 여기에 쓰겠습니다. 이 특정 솔루션은 극단적인 경우이기 때문에 누구에게도 도움이 되지 않을 것입니다.
이 공급자와의 링크에 대한 고대 역사로 돌아가서 우리는 기본 VLAN에 두 번째 VLAN을 추가했습니다. 당시 공급자는 이 VLAN을 태그된 두 가지로 모두 연결했습니다.그리고연결 측에 태그가 지정되지 않았습니다. 해당 스위치는 태그가 지정된 연결과 태그가 지정되지 않은 연결을 별도의 연결로 처리합니다.
그러면 Dell에 연결된 내 시스템이 arp 브로드캐스트(이 컴퓨터의 관리 인터페이스는 어리석은 이유로 0.5초마다 arp 패킷을 방출함)를 내보내고, 스위치는 링크를 통해 원격 사이트로 전달됩니다. 공급자의 스위치는 태그가 지정되지 않은 인터페이스에서 브로드캐스트를 듣습니다.태그가 지정된 인터페이스를 통해 나에게 다시 보냅니다.. 스위치는 이를 듣고 브로드캐스트를 시작하는 MAC 주소가 실제로 공급자의 링크를 통해 도달할 수 있다고 결론을 내립니다. 따라서 후속 패킷이 잘못된 방향으로 전달됩니다.
해결책은 공급자가 Dell의 구성에 동의하도록 구성을 변경하도록 하는 것이었습니다. 모든 일반적인 연결 문제가 중단되었습니다.