유니캐스트 플러드: 두 판 사이의 차이

띄어쓰기 수정
(→‎해결: 주석 편집)
태그: 2017 원본 편집
(띄어쓰기 수정)
[[컴퓨터 네트워크|컴퓨터 네트워킹]] 에서 '''유니캐스트 플러드'''는 스위치가 유니 캐스트유니캐스트 프레임을 수신하고 이를 브로드 캐스트브로드캐스트 프레임으로 취급하여 스위치의 다른 모든 포트로 프레임을 플러딩하는 경우이다.
 
== 배경 ==
''[[유니캐스트]]'' 라는 용어는 네트워크의 한 지점에서 다른 지점으로의 일대일 전송을 의미한다. 일반적으로 유니캐스트는 프레임이 여러 호스트가 아닌 의도된 수신자에게만 전달되기 때문에 더 안전한 것으로 간주된다. 이 다이어그램은 한 네트워크 호스트에서 다른 호스트로의 프레임 유니 캐스트유니캐스트 전송을 보여준다.
[[파일:Unicast.svg|가운데|200x200픽셀]]
스위치가 스위치의 포워딩 테이블에 없는 대상 주소가 있는 유니 캐스트유니캐스트 프레임을 수신하면 프레임은 브로드캐스트 프레임처럼 취급되어 네트워크의 모든 호스트로 전송된다.
[[파일:Broadcast.svg|가운데|200x200픽셀]]
 
== 원인 ==
[[네트워크 브리지|트랜스패어런트 브리징]]의 러닝 프로세스에서는 유니캐스트 프레임이 장치로 전달되기 전에 스위치가 장치에서 프레임을 수신해야 한다. 이러한 전송이 수신되기 전에 유니캐스트 플러딩은 전송이 의도한 대상에 도달하도록 보장하는 데보장하는데 사용된다. 일반적으로 수신 측은 러닝 과정을 완료하는 응답을 생성하므로 일반적으로 짧은 라이프 타임을 갖는다. 이 프로세스는 장치가 처음에 네트워크에 연결되거나 한 포트에서 다른 포트로 이동 될 때 또는 장치가 일반적으로 전달 테이블에서 제거 될 때 5 분5분 동안 활동이 없을 때 발생한다.
 
주소 캐시에 공간이 없는 스위치는 프레임을 모든 포트로 흘려보낸다. 이것은 호스트가 많은 네트워크에서 흔히 발생하는 문제이고, 주소 테이블의 인위적인 플러딩은 덜 일반적이며 MAC 플러딩 이라고 한다.
 
또 다른 일반적인 원인은 호스트의 [[주소 결정 프로토콜|ARP]] 타이머가 스위치의 주소 캐시 보관 시간 보다 긴 경우로, 스위치는 호스트에 연결된 포트의 MAC 주소를 알 수 없게 된다.<ref>{{
.<ref>{{
cite web
| url = http://mailman.nanog.org/pipermail/nanog/2009-June/011311.html
}}</ref>
 
스위치 이외의 장치도 유니캐스트 플러드를 생성할 수 있다. 브리지 인터페이스가 있지만 브리지 캐시에 대상 프레임의 주소가 없는 라우터는 프레임을 모든 브리지 구성원으로 흘려보낸다. <ref>{{
<ref>{{
cite web
| url = http://forums.freebsd.org/showpost.php?p=163796&postcount=17
}}</ref>
 
네트워크의 기능이 잘못 구성되면 유니캐스트 플러딩이 발생할 수도 있다. 호스트 A에서 B 로의 2 개의 레이어 2 경로가 있고 호스트 A가 경로 1을 사용하여 호스트 B와 통신하지만 호스트 B가 경로 2를 사용하여 호스트 A에 응답하는 경우 경로 1의 중간 스위치는 대상 [[MAC 주소]] 를 인식하지 못한다. 경로 2의 호스트 B와 중간 스위치는 호스트 A의 대상 MAC 주소를 인식하지 못한다. <ref>{{
<ref>{{
cite web
| url = http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch3.html#wp1079669
}}</ref>
 
마지막으로,마지막 유니캐스트 플러드의 원인으로 토폴로지 변경을변경이 있을 수 있이다. [[신장 트리 프로토콜|신속한 스패닝 트리에]] 참여하는 네트워크 포트에서 링크 상태가 변경되면 해당 스위치의 주소 캐시가 플러시되어 스위치가 주소를 학습할 때까지 모든 후속 프레임이 모든 포트로 흐른다. <ref>{{
<ref>{{
cite web
| url = http://www.ciscopress.com/articles/article.asp?p=336872
 
== 해결 ==
위의 링크에서 논의 된논의된 몇 가지 해결 방법이 있다. [http://forums.freebsd.org/showpost.php?p=163796&postcount=17] [http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch3.html#wp1079669] [http://www.ciscopress.com/articles/article.asp?p=336872] 그러나 많은 상황에서 로우 엔드 스위치는, 더 큰 주소 테이블을 가지고 있고 유니 캐스트 플러드를 차단할 수 있는 하이 엔드 스위치로 교체해야 한다. Cisco 스위치에서 유니 캐스트 플러드를 차단하는 것은 쉽지만 기본적으로 활성화되어 있지 않다. 일반적인 호스트 ARP 캐시 시간 초과보다 오래 클라이언트 액세스 포트에서 테이블 항목을 유지하도록 시간 초과 및 / 또는 보안 기능이 구성되었는지 확인한 후 이 명령을 사용하여 해당 포트에서 유니 캐스트유니캐스트 플러드를 차단한다. <ref>{{
cite web
| url = http://packetlife.net/blog/2010/jun/4/blocking-unknown-unicast-flooding/
}}</ref>
'''Switch (config-if) # switchport block unicast'''
다른 방법으로는 계층 2에서 호스트를 격리하는 것이 포함하며, 이는 라우터로 향하지 않는 내부 LAN 통신을 차단한다. 편리한 도구 (로우 엔드 스위치 <ref>{{
cite web
| url = http://blog.ine.com/2008/07/14/private-vlans-revisited/
== 네트워크에 미치는 영향 ==
네트워크에 유니 캐스트 플러딩이 발생하면 네트워크 성능이 저하된다. 다음은 브리지 주소 캐시의 크기를 조정하기 전후의 브리지 그래프이다.
[[image:StoppingTheUnicastFlood.png|center|580px|링크=Special:FilePath/StoppingTheUnicastFlood.png]]
20%의 프레임만 유효하게 전달 되고 프레임의 80 %가 플러드 아웃되어 목적지 주소로 수신되지 않는다 (첫 번째 참조 이미지). 대용량 네트워크에서는 플러드 된플러드된 트래픽으로 인해 포트가 포화 상태가되어 패킷 손실과 높은 대기 시간이 발생할 수 있다.
 
소진된 주소 테이블의 또 다른 부작용은 데이터 손실이다. 보안 고려 사항은 유니캐스트 플러드의 여러 원인 중 하나인 MAC 플러딩플러딩에서 에서 설명합니다설명한다. 최종 사용자가 [[패킷 분석기|패킷 스니퍼를]] 실행하는 경우 플러드 된 프레임을 캡처하고 볼 수 있다.
 
== 참고 문헌 ==
익명 사용자