☰

다중 건물 전략을 위한 서브넷 및 VLAN

tag-icon • tag-icon networking vlan subnet
다중 건물 전략을 위한 서브넷 및 VLAN

다른 사람들이 어떻게 하는지에 대한 약간의 피드백이 궁금합니다.

내가 보고 있는 사이트에는 광섬유로 연결된 여러 건물이 있고 각 건물은 자체 서브넷에 있습니다.

192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30

등

(기록을 위해 나는 192.168 서브넷에 있는 것이 바람직하지 않은 의미를 이해합니다)

각 건물은 DHCP 서버와 도메인 컨트롤러를 갖춘 자체 소규모 데이터 센터를 운영하고 있습니다.

내 가장 큰 문제는 서버를 두는 것이 매우 혼란스럽다는 것입니다.

192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.

분명히 모든 네트워킹 장비를 192.168.0.0 서브넷에, 모든 서버를 192.168.1.0에, DHCP를 192.168.3.0에 배치한다고 말할 수 있지만 이렇게 하면 크로스오버 VLAN이 생성됩니다.

예를 들어, 해당 건물에 있는 모든 컴퓨터가 있는 VLAN20에 DHCP 서버가 있고, 해당 건물에 있는 컴퓨터가 있는 VLAN10에 DHCP 서버가 있을 것입니다.

전통적으로 VLAN은 서브넷과 1:1로 유지됩니다.

다른 사람들은 이것을 어떻게 관리합니까? 192.168.0.1-.50이 서버 장비용으로 예약되어 있다는 것을 알고 계십니까?

저는 10.1.0.0/21 네트워크에서 왔기 때문에 모든 것을 분리할 수 있는 충분한 주소가 있었고 전혀 VLAN을 사용하지 않았습니다.

답변1

제공된 정보가 거의 없이 고려해야 할 요소가 많기 때문에 시나리오 기반으로 답변하기가 매우 어려운 질문입니다. 그러나 일반적인 의미에서 내 통찰력은 다음과 같습니다.

첫째, 개인 주소 그룹은 가정 사용자와 유사하다는 민감성을 기준으로 다른 개인 주소 그룹보다 더 바람직하거나 덜 바람직하지 않다는 질문에 대한 의견에 동의합니다. 내 경험에 따르면, VPN 사용자와의 충돌을 아무리 피하려고 노력하더라도 사용자 'A'에게 충돌이 발생하지 않으면 결국 충돌이 발생하는 일부 사용자 'B'가 있게 됩니다.

질문에서 언급하지 않은 한 가지 중요한 점은 장치의 양과 인프라 수명 동안 예상되는 성장입니다. 범위가 개방적이고 모호하므로 일반적인 요점을 유지하겠습니다.

네트워크를 건물당 서브넷으로 분할하기로 결정한 경우 먼저 필요한 건물 수를 식별한 다음 이것이 장기적(5~10년) 동안 충분할 확률을 고려하십시오. 과도하지 않고 현실적인 양의 네트워크에 도달하도록 노력하십시오. 나는 일반적으로 자유주의적이며 약간의 오버헤드를 허용합니다. 이를 사용하여 상위 수준 서브넷에 대해 실용적인 가장 좁은 범위를 정의합니다.

예를 들어, 3개의 건물이 있지만 10년에 걸쳐 5개로 증가할 것으로 예상되는 경우 이에 적합한 기본 2배수를 선택하고 이 접두사로 사용 가능한 첫 번째 옥텟을 분할합니다. 예. 최대 8개의 네트워크를 갖춘 172.16.xx:

000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19

이렇게 하면 주소 범위가 최대화되고 추가 서브넷이 가능해집니다. 또한 .19 범위 내의 모든 서브넷이 나머지 네트워크의 대부분에 대해 동일한 노드를 경유하는 경우 경로 정의를 단순화합니다. 이 균형은 두 가지 방식으로 작동해야 합니다. 예를 들어 원격 사무실과 같이 기본 건물 외에 주소가 많이 필요하지 않지만 연결만 필요한 소수의 건물이 있다고 가정해 보겠습니다. 이러한 단일 건물 '상위' 서브넷을 할당할 수 있습니다. 그리고 그것을 나누어 서비스를 제공합니다. 귀하의 목표는 궁극적으로 가장 필요할 수 있는 가장 큰 주소 공간을 유지하는 것입니다.

여기에서 네트워크를 애플리케이션별 할당으로 더 분할할 수 있습니다. 다음과 같은 작업을 수행할 수 있습니다.

건물 1(위에서).

001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21

우리는 이것을 더 발전시켜 다음을 얻을 수 있습니다:

001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24

제가 생각하기에 가장 중요한 것은 귀하의 시나리오에 적합한 솔루션을 찾는 것입니다. 당신은 아마도 다음을 원할 것입니다:

  • 성장 가능성이 가장 높은 곳에서 성장 여지를 최대화하십시오. 추측컨데, 나는 그것이 최종 사용자 네트워크일 것이라고 가정합니다.
  • 가능한 경우 일관된 패턴을 유지하여 ACL 및 방화벽 규칙을 단순화할 수 있습니다. 예를 들어, 세 번째 옥텟에서 패턴이 '01'인 4번째와 5번째 비트가 항상 '기타 네트워크'를 나타낸다는 것을 알고 있는 경우 단일 규칙으로 모든 건물을 캡처하는 하나의 비트마스크를 가질 수 있습니다.
  • 주소 공간이 사용자 홈 네트워크와 충돌할 수 있는지 여부에 초점을 맞추기보다는 사용자가 이를 어떻게 사용할 것인지에 초점을 맞춰 설계하십시오. 예를 들어; 변환이나 과부하가 없고 추가로 라우팅된 트래픽이 통과하는 지점 간 VPN인 경우 호환 가능한 주소 범위를 유지하는 것이 중요할 수 있습니다. 대부분의 가정 사용자에게는 충돌이 문제가 되지 않습니다. 왜냐하면 최종 장치에서 연결하고 해당 장치가 연결을 모든 트래픽의 게이트웨이로 처리하기 때문입니다. 이를 벗어나는 것은 귀하의 사용 정책에 위배될 수 있으며 귀하의 지원 범위를 벗어날 수 있습니다.
  • 동일한 서브넷의 네트워크는 동일한 VLAN에 있을 필요는 없지만 아마도 그래야 합니다. VLAN ID가 바로 그것입니다. 단지 숫자일 뿐이다. 교환하지 않는 경우 연결된 장치 전체에서 동일할 필요는 없지만 일관되지 않은 VLAN ID 구조를 갖는 것이 도움이 되는 시나리오는 생각할 수 없습니다. 동일한 네트워크의 두 개의 서로 다른 VLAN을 함께 연결하려면 브리지(스위치)를 사용합니다. 기본적으로 스위치를 여러 개의 하위 스위치로 분할하고 유지 관리가 어려운 방식으로 비효율적으로 결합하게 됩니다.
  • 불필요한 라우팅을 최소화합니다. 이러한 모든 네트워크를 갖는 것이 훌륭하고 논리적일 수 있지만, 많은 양의 트래픽이 라우터를 통해 네트워크 A에서 네트워크 B로 전달되는 경우 포트 속도를 전제로 라우터가 이를 지원할 수 있다고 가정하는 것만으로는 충분하지 않습니다. 충분합니다. 예를 들어, Cisco 1941 듀얼 기가비트 이더넷 라우터에는 듀얼 기가비트 포트만 있지만 네트워크 간 예상 처리량은 153Mbps입니다. (처리량 사양)
  • 네트워크가 충분하지 않습니다(...모순적인 의미에서). 네트워크를 분할하기 위해 서브넷을 사용하지 않은 경우 브로드캐스트는 모든 장치에 도달합니다. 특정 장치 그룹이 자주 직접 통신할 필요가 없다면 이는 해당 장치를 분리해야 한다는 의미입니다.
  • 네트워크 내부 및 네트워크 전반에서 수평적 확장성을 수용합니다. 모든 사용자에게 서비스를 제공하는 하나의 큰 서버를 보유하는 대신; 클라이언트에게만 서비스를 제공하기 위해 각 네트워크마다 더 작은 서버를 보유합니다. 그들은 공통 데이터 소스를 공유할 수 있으며 이는 또한 라우터의 부담을 덜어줄 것입니다. 하지만 수평적 확장을 달성하는 방법에는 여러 가지가 있습니다.

이것이 도움이 되거나 아이디어를 제공해주기를 바랍니다. :)

관련 정보