솔루션 아키텍처
제안된 프로덕션 등급 아키텍처를 언급하기 전에, 완료를 위해 보안이 문제가 되지 않고 더 빠른 결과를 선호하는 경우에 사용할 수 있는 접근 방식을 공유하겠습니다.
개념 증명 비프로덕션급 DHCP 서버 통합 접근 방식
이 접근 방식에서 DHCP 서버는 패브릭의 서비스 블록 기능에 로컬로 연결됩니다. 중복을 위해 ESI-LAG는 패브릭 측에 구성되고 일반 LAG는 서버 측에 구성됩니다. 가능한 모든 4,000+ VLAN이 구성되어 DHCP 서버에 대한 이 링크에 노출됩니다. 그러면 모든 액세스 VLAN의 레이어 2 브로드캐스트 도메인이 DHCP 서버로 확장되므로 패브릭 자체에 DHCP 릴레이의 추가 구성이 필요하지 않습니다. 수신할 일치하는 하위 인터페이스를 구성함으로써, DHCP 서버는 클라이언트가 보내는 MAC 브로드캐스트 패킷을 수신하여 리스를 할당할 수 있습니다. 이는 기존 방식으로 작동하며, 많은 DHCP 서버(Junos OS 포함)가 이 트래픽에 응답할 수 있습니다.
이는 프로덕션 등급 설계 및 롤아웃에는 권장되지 않습니다. 네트워크를 더 빨리 가동하는 데 도움이 될 수 있지만 이러한 설계에는 심각한 보안 위험이 따릅니다!
프로덕션 등급 설계에서 이를 권장하지 않는 이유는 패브릭 설계의 기본 보안 기능을 우회하기 때문입니다. 일반적으로 모든 패브릭 VRF는 서로 격리됩니다. 이렇게 하면 서로 다른 VRF의 VLAN 간의 모든 트래픽이 방화벽과 같은 보안 기능을 구현할 수 있는 WAN 라우터를 통과하게 됩니다. 서비스 블록의 DHCP 서버에 대한 링크에 모든 VLAN을 배치함으로써 WAN 라우터를 우회하여 보안 기능을 우회합니다. 공격자가 개방형 관리자 로그인과 같은 보안 허점을 발견하거나 무언가가 잘못 구성된 경우 공격자는 모든 VLAN 사이를 이동하며 VRF 간의 WAN 라우터 기반 스크리닝을 우회할 수도 있습니다. 이러한 장단점에 유의하십시오.
가 있는 EVPN 멀티호밍
권장되는 프로덕션급 DHCP 서버 통합 접근 방식
권장되는 프로덕션 등급 솔루션은 패브릭 내부의 DHCP 릴레이를 활용하여 고객 관리 DHCP 서버로 전달하는 IETF RFC 2131 및 RFC 3046 표준 기반 접근 방식입니다.
캠퍼스 패브릭에서 DHCP 릴레이는 일반적으로 레이어 3 게이트웨이 VRF가 연결된 액세스 스위치에서 노스바운드 기능으로 트래픽을 전송하는 위치에 있습니다. 이는 레이어 2 브로드캐스트 도메인과 네트워크의 나머지 레이어 3 포워딩 사이의 경계이기 때문입니다. 임대를 요청하는 DHCP 클라이언트는 항상 이 레이어 2 도메인의 브로드캐스트 MAC 주소(FF:FF:FF:FF:FF)를 처리합니다. 이러한 메시지가 VRF에 도달하면 VRF의 DHCP 릴레이 기능(RFC 2131에서는 이를 BOOTP 릴레이 에이전트라고 함)에 의해 IP UDP 패킷으로 패브릭 또는 패브릭 외부에 연결된 DHCP 서버로 전달됩니다. 이와 함께 추가 정보를 전달하는 기능은 항상 DHCP 서버로 향하는 UDP 패킷에 포함됩니다.
- 게이트웨이 IP(RFC 2131에서는 이를 "giaddr"라고 함)는 DHCP 패킷의 소스 IP 주소입니다. DHCP 서버는 모든 응답 패킷을 이 임베디드 IP 주소로 다시 보냅니다. 따라서, 응답하는 패킷이 이 IP 주소에 도달할 수 있어야 합니다. 보고된 소스 IP는 패브릭 유형 및 WAN 라우터 통합 방법에 따라 다를 수 있습니다. 이 JVD에 설명된 가장 널리 사용되는 두 가지 방법은 다음과 같습니다.
- 가상 게이트웨이 주소 지정을 사용하는 소형 패브릭의 경우, 각 패브릭 VRF에 로컬로 구성된 각 오버레이 VLAN의 정적 IP 주소가 게이트웨이 IP로 사용됩니다.
- 애니캐스트 주소 지정이 사용되는 대규모 패브릭의 경우, 패브릭 전체에 분산된 VRF가 추가적인 오버레이 루프백 IP를 사용합니다. 이 패브릭에서 VRF가 구성된 모든 노드의 각 VRF는 게이트웨이 IP로 사용되는 고유한 IP 주소를 가져옵니다. 따라서 추가 오버레이 네트워크가 있지만 VRF 간에 공유됩니다. 이 경우 루프백 IP 주소 사용에는 두 가지 유형이 있습니다.
- 각 EVPN 패브릭 스위치의 lo0.0 인터페이스에 바인딩된 기존 언더레이 루프백 IP 주소가 항상 존재합니다. 이는 VXLAN VTEP 및 EVPN BGP 신호 전송에 사용됩니다. 일반적으로 오버레이 전송에는 보이지 않습니다.
- DHCP 릴레이에 사용되는 새로운 루프백 IP 주소는 오버레이 VLAN에서 볼 수 있습니다. 이 오버레이 루프백 풀을 정의할 때 이 범위가 오버레이 VLAN에 의해 다른 곳에서 사용되지 않도록 주의하십시오. 또한 이 오버레이 루프백 풀의 IP 주소는 VRF가 위치한 EVPN 패브릭의 노드에만 바인딩되어야 합니다.
- DHCP 릴레이 기능은 RFC 3046에 따라 DHCP 옵션 82에 의해 추가된 것과 같은 추가 정보를 포함할 것으로 예상됩니다. 이렇게 하면 DHCP 서버가 클라이언트 요청의 소스를 식별하고 임대 유인물 결정을 보다 효과적으로 관리할 수 있습니다. DHCP 서버는 UDP 패킷을 수신하는 IP 주소 소켓 인터페이스에서 수신하도록 구성되었기 때문에 로컬 VLAN에서 DHCP 리스 요청을 더 이상 수신할 수 없기 때문에 필요합니다. DHCP 서버 벤더가 옵션 82에 포함할 수 있는 가능한 속성은 다양할 수 있으며 항상 패브릭과의 통합에 따라 달라집니다.
이미 언급했듯이 패브릭은 VRF가 패브릭에 있는 DHCP 릴레이 기능을 구성합니다. 스위치에서 수동으로 변경하지 마십시오. 패브릭 구성 필드 내에서 네트워크 및 VRF를 구성하는 창에서 DHCP 릴레이 구성 옵션을 찾을 수 있습니다. 나머지는 아래 그림과 같이 필요한 노드의 주니퍼 Mist™ 클라우드에 의해 자동으로 배포됩니다.
| 패브릭 유형 | DHCP 릴레이는 다음에 구성됩니다. | 지원되는 노드 수 |
|---|---|---|
| EVPN 멀티호밍 | 컬랩스드 코어 스위치 | 최대 4개 |
| CRB | 코어 스위치 | 최대 4개 |
| ERB | 분산 스위치 | 다수 |
| 에지에서 라우팅된 IP Clos | 액세스 스위치 | 다수 |
가상 게이트웨이 패브릭과 애니캐스트 패브릭 비교
패브릭 유형에 따라 오버레이 VLAN(클라이언트 트래픽이 있는 위치)에는 내부 목적으로 추가 IP 주소가 필요할 수 있으며, 가상 게이트웨이 패브릭의 경우와 같습니다. 주니퍼 Mist 캠퍼스 패브릭은 다음과 같은 패브릭 유형을 구성합니다.
| 패브릭 유형 | 가상 게이트웨이 패브릭 | 애니캐스트 패브릭 | |
|---|---|---|---|
| EVPN 멀티호밍 | 예 | --- | |
| CRB | 예 | --- | |
| ERB | --- | 예 | |
| IP Clos 패브릭 | --- | 예 | |
가상 게이트웨이 패브릭에는 일반적으로 매우 제한된 양의 VRF가 있습니다. 이러한 스위치는 코어 또는 축소된 코어 스위치에 있습니다. 주니퍼 Mist 캠퍼스 패브릭에서 지원되는 코어 또는 축소된 코어 스위치의 최대 수는 4개입니다. 즉, 특정 VRF는 패브릭에서 각 중복 코어 또는 축소된 코어 스위치에 최대 4번까지 복제될 수 있습니다. 가상 게이트웨이 패브릭이 아닌 애니캐스트 패브릭은 보다 확장된 설계에 적합합니다. 따라서 VRF의 위치는 분산 스위치(ERB) 또는 액세스 스위치(IP Clos 패브릭)에 있습니다. 가상 게이트웨이 패브릭의 특성상 시스템은 패브릭에 위치한 모든 VLAN에 대해 VRF마다 고유한 추가 정적 IP 주소를 필요로 합니다. 따라서 각 VLAN에 대한 공유 게이트웨이 IP 주소 외에도 해당 서브넷에 최대 4개의 추가 고유 IP 주소가 필요합니다.
왜 그런 디자인일까요? DHCP 릴레이와 같은 패브릭의 특정 트래픽에는 이점이 있습니다. DHCP 릴레이의 경우, 시스템은 DHCP 클라이언트 요청을 전달할 때 게이트웨이 IP 주소 대신 정적 IP 주소를 사용합니다. 고정 IP 주소가 VLAN/코어 스위치에 고유하므로 이 동작을 통해 DHCP 응답 패킷이 올바른 VRF로 다시 전송됩니다.
가상 게이트웨이 패브릭에 대해 생각하는 또 다른 방법은 VRRP와 같은 기존 레이어 2 게이트웨이 페일오버 설계와 비교하는 것입니다. 거기에는 항상 게이트웨이(VRF) 사이에 떠 있는 VIP가 있으며 각 게이트웨이에는 각 VLAN에 대한 고유한 추가 IP 가 필요합니다. 주니퍼 Mist 캠퍼스 패브릭에서는 EVPN 컨트롤 플레인이 이를 대신하므로 VRRP 프로토콜이 필요하지 않습니다.
각 서브넷에서 이러한 추가 정적 IP 주소를 분할하는 데 필요한 작은 희생은 애니캐스트 패브릭에서 제거됩니다. 이는 VRF가 설치된 분산/액세스 스위치가 더 확장되기 때문에 VLAN을 생성할 때 향후 성장을 잘 계획해야 하기 때문입니다. DHCP 릴레이와 같은 시스템 서비스는 애니캐스트 패브릭에서 약간 다르게 작동하며 내부적으로 더 복잡합니다.
보고된 게이트웨이 IP 주소로 어떤 IP 주소를 선택해야 합니까?
패브릭의 DHCP 릴레이 기능에 의해 전달되는 패킷에 어떤 게이트웨이 IP 주소가 내장되는지 결정하려면 일반적으로 다음 접근 방식 중 하나를 선택해야 합니다.
- EVPN 멀티호밍 패브릭의 경우, UI는 선택 항목을 제공하지 않으므로 항상 게이트웨이 IP에 가상 게이트웨이 IP 주소를 사용하게 됩니다. 이를 통해 DHCP 서버는 전달된 패킷에 포함된 게이트웨이 IP 주소만을 분석하여 요청이 시작된 VLAN을 식별할 수 있습니다.
- CRB 패브릭의 경우, 캠퍼스 패브릭 대화의 "VRF당 루프백 서브넷"에 IP 접두사를 채울 때 패브릭의 각 VRF에 할당된 오버레이 루프백 IP 주소를 사용하여 가상 게이트웨이 고정 IP 주소 설계 중에서 선택할 수 있습니다.
- ERB 및 IP Clos와 같은 대규모 패브릭의 경우 캠퍼스 패브릭 구성의 일부로 "VRF당 루프백 서브넷"에 IP 접두사를 입력하는 것이 좋습니다. 이렇게 하면 패브릭은 이 풀 범위를 벗어난 고유한 오버레이 루프백 IP를 패브릭의 각 VRF에 자동으로 할당합니다. 이 경우 이러한 오버레이 루프백 IP를 사용하면 WAN 라우터에서 각 게이트웨이 IP에 도달하는 방법을 예측하기 어려울 수 있으므로 패브릭으로 WAN 라우터 통합하기 위해 OSPF 또는 BGP와 같은 라우팅 프로토콜을 활용하는 것이 좋습니다.
기술적으로는 이러한 패브릭에서 "Loopback per-VRF subnet" 필드를 비워 둘 수 있지만 권장되지 않습니다. 비워 두면 애니캐스트 게이트웨이 IP는 전달된 패킷에 포함된 보고된 게이트웨이 IP가 됩니다. 이로 인해 DHCP 서버로 이동하는 과정에서 문제가 발생하지 않습니다. 그러나 DHCP 서버의 응답이 반환될 때 애니캐스트 IP가 패브릭 내의 여러 스위치에 의해 공유되기 때문에 응답 패킷은 요청을 시작하지 않은 스위치로 라우팅될 수 있으며 다른 PoD 또는 건물에 있을 수 있습니다. 이 경우 패킷이 요청을 시작하지 않은 스위치에 도착하면 DHCP 릴레이 기능이 응답의 캡슐화를 해제하고 클라이언트의 MAC 주소에 따라 패킷을 원격 스위치로 전달해야 하는지 결정합니다. 이를 위해 VXLAN 터널을 사용하여 클라이언트가 실제로 연결된 스위치에 패킷을 동서로 다시 보냅니다. 이로 인해 비효율적인 설계가 발생합니다.
DHCP 서버의 위치
권장하는 접근 방식은 패브릭 자체의 일부로 로컬 통합입니다.
캠퍼스 패브릭의 경우, 서비스 리프는 서비스 블록 기능이라고 하며, 다음 예에서는 DHCP 서버가 연결된 북쪽에 있는 한 쌍의 물리적 스위치를 패브릭의 필수 요소로 합니다.
DHCP 서버는 자신과 동일한 VRF에 있지 않은 클라이언트에 대한 리스도 관리할 수 있습니다. 그러나 패브릭 내부에는 항상 VRF 간 격리가 있으므로 패킷은 WAN 라우터를 통해 교환되어야 합니다.
이러한 로컬 통합이 불가능한 경우 DHCP 서버를 패브릭에 대한 외부 요소로 통합할 수도 있습니다. 다음은 다음 그림의 왼쪽 상단 모서리에 보이는 것입니다.
고려해야 할 사항 외부 DHCP 서버를 사용하고 있습니까?
외부 DHCP 서버를 패브릭에 통합할 때 이 접근 방식이 성공하기 위해 염두에 두어야 할 두 가지 중요한 사항이 있습니다.
- 패브릭 서버와 DHCP 서버 간의 지연 시간을 가능한 한 낮게 유지합니다. 지연 영향을 모르는 경우 퍼블릭 클라우드 환경에서 DHCP 서버를 운영하는 것을 고려하지 마십시오. 일부 DHCP 클라이언트는 임대를 요청할 때 매우 공격적일 수 있으며, 이로 인해 응답되지 않은 DHCP 임대 요청이 대기 시간이 긴 환경에서 누적되어 DHCP 서버에 과부하가 걸릴 수 있습니다. DHCP 클라이언트 동작은 패브릭 수준에서 거의 영향을 받지 않으므로 패브릭을 프로덕션에 배치하기 전에 전체 왕복 대기 시간에 초점을 맞춰 설계를 테스트하는 것이 좋습니다.
- 패브릭과 DHCP 서버 사이에는 어떤 형태의 네트워크 주소 변환(NAT)도 지원되지 않습니다. 그 이유는 DHCP 서버가 클라이언트 요청에 어떻게 응답해야 하는지 설명하는 IETF RFC 2131 의 다음 발췌문에 설명되어 있습니다. "giaddr"은 포함된 게이트웨이 IP 주소입니다.
4.1 Constructing and sending DHCP messages . If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. .
이 RFC 설명의 의미를 모를 수도 있으므로 RFC에 따라 SNATed DHCP 요청에 응답하지 않는 Microsoft DHCP 서버를 사용하는 트래픽의 예를 제공했습니다.
다음은 릴레이 패킷에 대해 생성된 액세스 스위치의 원래 소스 IP와 포트입니다.
tcpdump -nnvvi fabric3 'port 4789 and udp[8:2] = 0x0800 and udp[11:4] = 11099'
tcpdump: listening on fabric3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:48:50.799126 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 419)
172.16.254.6.42357 > 172.16.254.1.4789: [no cksum] VXLAN, flags [I] (0x08), vni 11099
IP (tos 0x0, ttl 64, id 27564, offset 0, flags [none], proto UDP (17), length 369)
10.99.99.1.67 > 192.168.10.11.67: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:d8:d1:04, length 341, xid 0x892af3d, Flags [none] (0x0000)
Gateway-IP 10.99.99.1
Client-Ethernet-Address 52:54:00:d8:d1:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 8: "desktop1"
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP
Agent-Information Option 82, length 39:
Circuit-ID SubOption 1, length 4: 1099
Unknown SubOption 9, length 31:
0x0000: 0000 0a4c 1a04 1849 5242 2d69 7262 2e31
0x0010: 3039 393a 6d67 652d 302f 302f 332e 30
WAN 라우터가 전달된 검색 메시지에 SNAT를 적용할 때 소스 IP와 포트를 다음과 같이 변경합니다.
tcpdump -nnvvi br0 'host 192.168.10.11'
12:40:46.545512 IP (tos 0x0, ttl 63, id 5475, offset 0, flags [none], proto UDP (17), length 369)
192.168.10.169.28594 > 192.168.10.11.67: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:d8:d1:04, length 341, xid 0x78caf527, secs 7, Flags [none] (0x0000)
Gateway-IP 10.99.99.1
Client-Ethernet-Address 52:54:00:d8:d1:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 8: "desktop1"
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP
Agent-Information Option 82, length 39:
Circuit-ID SubOption 1, length 4: 1099
Unknown SubOption 9, length 31:
0x0000: 0000 0a4c 1a04 1849 5242 2d69 7262 2e31
0x0010: 3039 393a 6d67 652d 302f 302f 332e 30
그러나 DHCP 서버의 응답은 SNAT가 적용되기 전에 패브릭 내부의 원래 소스 IP였던 포트 67의 원래 포함된 게이트웨이 IP에 응답합니다.
12:40:46.545962 IP (tos 0x0, ttl 128, id 30987, offset 0, flags [none], proto UDP (17), length 359)
192.168.10.11.67 > 10.99.99.1.67: [bad udp cksum 0x397c -> 0x81a7!] BOOTP/DHCP, Reply, length 331, xid 0x78caf527, Flags [none] (0x0000)
Your-IP 10.99.99.10
Server-IP 192.168.10.11
Gateway-IP 10.99.99.1
Client-Ethernet-Address 52:54:00:d8:d1:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Subnet-Mask Option 1, length 4: 255.255.255.0
RN Option 58, length 4: 345600
RB Option 59, length 4: 604800
Lease-Time Option 51, length 4: 691200
Server-ID Option 54, length 4: 192.168.10.11
Default-Gateway Option 3, length 4: 10.99.99.1
Domain-Name-Server Option 6, length 8: 8.8.8.8,9.9.9.9
Agent-Information Option 82, length 39:
Circuit-ID SubOption 1, length 4: 1099
Unknown SubOption 9, length 31:
0x0000: 0000 0a4c 1a04 1849 5242 2d69 7262 2e31
0x0010: 3039 393a 6d67 652d 302f 302f 332e 30
이 패킷은 SNAT 방화벽에 다시 도착하지 않습니다.
root@wanrouter> show security flow session destination-prefix 192.168.10.11
Session ID: 22116, Policy name: default-permit/5, Timeout: 50, Valid
In: 10.99.99.1/67 --> 192.168.10.11/67;udp, Conn Tag: 0x0, If: ae0.1099, Pkts: 72, Bytes: 26568,
Out: 192.168.10.11/67 --> 192.168.10.169/6673;udp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 0, Bytes: 0,
DHCP 릴레이 설계에 도움이 되는 Junos OS의 최적화
Junos OS 구성을 통해 설계를 최적화하는 데 도움이 되는 몇 가지 문이 있습니다. 패브릭이 자동으로 구성하는 이유를 알고 싶은 경우를 위해 여기 중요한 사항을 제시합니다.
Junos OS 구성에서는 디바이스가 제어되지 않는 DHCP 트래픽을 모니터링하지 못하도록 'forward-only' 문이 필요합니다.
set groups top routing-instances <vrf-name> forwarding-options dhcp-relay forward-only
Junos OS 구성에서 "relay-option-82 circuit-id vlan-id-only" 문은 옵션 82 DHCP 트래픽을 전달할 때 QFX 및 EX 스위치의 동작을 동기화합니다(기본적으로 서로 다른 속성을 사용함). 또한 이 속성은 더 이상 "IRB-irb.1099:ae10.0" 또는 "IRB-irb.1099:vtep.32769"와 같은 원치 않는 인터페이스 정보를 추가하지 않습니다. 이 구성을 추가하면 VLAN ID만 보고되므로 Linux KEA DHCP 서버가 올바른 임대를 할당하는 데 활용하는 이 필드의 문자열 구문 분석이 용이합니다.
set groups top routing-instances <vrf-name> forwarding-options dhcp-relay group <vlan-name> relay-option-82 circuit-id vlan-id-only
Junos OS 구성 문 "relay-option-82 server-id override"는 여기에 설명되어 있으며 사용자 환경에서 필요합니다. 이는 Microsoft DHCP 서버가 하위 옵션 5를 사용하여 패킷의 소스를 결정하고 할당할 올바른 풀을 선택하는 데 도움이 됩니다.
set groups top routing-instances <vrf-name> forwarding-options dhcp-relay group <vlan-name> relay-option-82 server-id override
루프백 IP를 게이트웨이 IP로 사용할 때 Junos OS 구성 문 "route-suppression destination"이 필요합니다. 게이트웨이 IP로 가상 게이트웨이 주소 정적 IP에는 사용되지 않습니다.
set groups top routing-instances <vrf-name> forwarding-options dhcp-relay group <vlan-name> route-suppression destination
Junos OS 구성에서 패브릭은 이제 "no-dhcp-flood" 옵션으로 모든 IRB 인터페이스를 구성합니다. 이렇게 하면 모든 DHCP 릴레이 디바이스가 클라이언트로부터 동일한 요청을 중복되지 않도록 클라이언트의 MAC 브로드캐스트를 제한하는 데 도움이 됩니다. 이 옵션이 없으면 모든 클라이언트 요청이 VLAN의 브로드캐스트 패킷이므로 원래 요청은 VXLAN을 통해 복제되어 해당 VRF가 구성된 모든 패브릭 노드로 전송된 다음 WAN 라우터로 DHCP 릴레이를 수행합니다.
set interfaces irb unit <vlan-id> no-dhcp-flood
랩에서 vJunos-switch 를 가상 스위치 인스턴스로 사용하는 경우, "no-dhcp-flood" 옵션을 가상 스위치에서 구성할 수 있지만 현재로서는 구현되지 않은 것으로 알려져 있습니다. 따라서 플러딩 및 잘못된 게이트웨이 IP 주소가 사용되는 것을 관찰할 수 있습니다. 그러나 이것이 이를 테스트하는 능력에 영향을 미치지 않아야 합니다. 이는 vJunos 스위치의 알려진 제한일 뿐입니다.