최근 Cisco 2520에서 업그레이드를 수행했습니다. 업그레이드의 일부로 SVI가 스위치에 추가되어 이전에 다른 스위치(트렁크를 통해)에서 수행되었던 VLAN을 로컬로 라우팅할 수 있게 되었습니다. SVI에는 다음과 같은 매개변수가 있습니다.
네트워크 주소: 192.168.65.96 서브넷 마스크: 255.255.255.248 SVI 주소: 192.168.65.102
이 서브넷에는 두 개의 장치가 있었고, 변경이 이루어졌을 때 기본 게이트웨이와 서브넷 마스크가 각각 192.168.65.1 / 255.255.255.0임에도 불구하고 두 장치 모두 여전히 원격 네트워크와 통신할 수 있었습니다.
그 후 모니터링하는 동안 장치 중 하나와의 통신이 끊겼지만 다른 장치는 온라인 상태로 유지되었습니다. 두 장치 모두에서 서브넷 마스크와 기본 게이트웨이를 올바르게 구성하여 문제를 해결했지만 두 장치가 모두 sunet 마스크/기본 게이트웨이를 잘못 구성했음에도 불구하고 한 장치와 통신할 수 있고 다른 장치는 통신할 수 없는 이유를 누군가 설명할 수 있는지 궁금합니다.
감사해요!
답변1
넷마스크(서브넷 마스크)는 IP 주소의 일부가 아니며 IP 헤더의 어느 곳으로도 가지 않습니다. "192.168.65.96"으로 주소가 지정된 패킷은 사용된 넷마스크에 관계없이 여전히 "192.168.65.96"으로 주소가 지정됩니다.
대신 넷마스크는 다음과 같은 형태로 작동합니다.노선, 그리고 패킷을 보낼 때만 사용되지만 수신할 때는 사용되지 않습니다. 즉, 잘못된 넷마스크가 구성된 호스트는 여전히 패킷을 받을 수 있지만 올바르게 보낼 수는 없습니다.
패킷을 보낼 때 넷마스크를 검사하여 결정합니다.대상 IP 주소가 동일한 서브넷에 있는지 여부송신 호스트로서:
소스와 대상이 모두 동일한 서브넷에 있으면 MAC 수준("레이어 2")에서 직접 패킷을 보낼 수 있음을 의미합니다.게이트웨이를 사용하지 않고, 발신자는 ARP를 사용하여 IP 주소를 수신자의 MAC 주소로 직접 확인합니다.
따라서 두 호스트가 서로의 넷마스크에 따라 동일한 서브넷 내에 있는 경우 해당 상황에서는 게이트웨이가 필요하지 않으므로 게이트웨이 주소가 잘못 구성되어도 문제가 되지 않습니다.
만일 그들이~ 아니다동일한 서브넷에 있는 경우 게이트웨이가 필요하며 발신자는 대신 ARP를 사용하여 게이트웨이의 MAC 주소를 찾습니다.
따라서 잘못 구성된 넷마스크는 "동일한 서브넷?"에 잘못된 결과를 제공하는 주소와의 통신에만 영향을 미칩니다. 시험.
넷마스크가 다음과 같은 경우너무 넓은(접두사 길이가 너무 짧음) 필요한 것보다 더 많은 주소를 포함하면 넷마스크에 실수로 포함된 주소(실제로 서브넷에 "로컬"이 아닌 주소)로 더 이상 패킷을 보낼 수 없습니다.
그러한 주소로 패킷을 보내려고 할 때 호스트는 마치 로컬이 아닌 것처럼 ARP를 통해 패킷을 확인하려고 시도합니다. 즉, ARP 요청이 도달하지 않습니다.
예를 들어, 192.168.1.0/24 서브넷에 있지만 실수로 넷마스크를 /16(255.255.0.0)으로 구성한 경우 192.168.xx의 나머지 부분과의 통신이 끊어집니다(계속 연결할 수는 있음). 이전과 마찬가지로 192.168.1.x).
(통신을 통해서도5월게이트웨이가 '프록시 ARP'를 구현하고 "상대방"을 대신하여 해당 ARP 요청에 응답하는 경우에도 여전히 가능합니다. 이는 실제로 ISP가 '클라이언트 격리'로 수행하거나 대규모 서브넷을 분할하는 중간 단계로 수행되는 경우도 있습니다. 실제로 Proxy-ARP는 서브넷이 발명되기 전에 대규모 클래스형 네트워크를 분할하는 데 사용되었습니다.)
어느 쪽이든 실제로 서브넷에 있는 로컬 호스트는 물론이고 잘못된 넷마스크가 적용되지 않는 원격 호스트와 계속 통신할 수 있으므로 한동안 이 사실이 눈에 띄지 않을 수 있습니다.
넷마스크가 다음과 같은 경우너무 좁다(접두사 길이가 너무 큼) 필요한 주소를 포함하지 않으면 반대 결과가 나타납니다. 호스트가 필요하다고 생각하기 때문에 넷마스크가 실수로 제외한 서브넷 부분과 통신하지 못할 수도 있습니다. 해당 주소에 대한 게이트웨이를 통과하세요.
만약 거기에~이다게이트웨이를 사용하면 패킷을 동일한 서브넷으로 다시 라우팅할 수 있으며 작업은 여전히 매우 비효율적으로 작동합니다. 게이트웨이는 ICMP "리디렉션" 패킷을 보내 더 직접적인 경로가 있음을 알릴 수도 있으며 OS는 자동으로 라우팅 테이블을 업데이트하여 직접 통신을 다시 허용할 수도 있습니다. 따라서 잘못된 구성은 오랫동안 눈에 띄지 않을 수 있습니다.
하지만 넷마스크가 너무 좁은 경우그리고게이트웨이가 잘못되면 해당 주소로 패킷을 전혀 보낼 수 없습니다. 호스트는 존재하지 않는 게이트웨이를 통해 패킷을 보내려고 시도합니다.
두 상황 모두에서 영향을 받는 대상은 '올바른' 넷마스크와 '잘못된' 넷마스크가 다른 결과를 제공하는 대상뿐입니다.