3V0-25.25 Practice Questions

The scenario describes a stable BGP session between the NSX Tier-0 gateway and the Top-of-Rack (ToR) router, which confirms that network connectivity and basic BGP parameters are correct. However, the Tier-0 is not receiving a default route (0.0.0.0/0), which is essential for routing traffic to external networks like the internet.

For the Tier-0 gateway to learn the default route via BGP, the peer router (the ToR) must be explicitly configured to advertise it. If the ToR router does not have a default route in its own routing table or is not configured with a policy to originate and advertise one to the NSX Tier-0 BGP neighbor, the route will not be sent, directly causing the issue described.

A. Missing BGP communities on the ToR would affect route filtering or policy application but would not inherently prevent the advertisement of a default route.

B. This describes the reverse traffic flow. The ToR receiving a default route from the Tier-0 is for inbound traffic, not for workload outbound internet access.

C. A route limit issue is improbable because the BGP session is described as "up and stable." Hitting a route limit typically causes the session to flap or reset.

1. VMware NSX-T Data Center Design Guide: In the section "Tier-0 Gateway Design

" the guide details the BGP peering relationship with physical routers. It establishes that for north-south connectivity

the physical network infrastructure is responsible for advertising external network reachability (such as a default route) to the NSX Tier-0 gateways. The absence of this advertisement from the physical router is a common configuration error. (Reference: VMware NSX-T Data Center Product Documentation

NSX-T Data Center Design Guide

Chapter 5: Tier-0 Gateway Design).

2. VMware Cloud Foundation Architecture and Design Guide: This guide specifies the physical network requirements for a VCF deployment. In the "NSX Network Design" section

it mandates that upstream physical routers (ToRs) must be configured for BGP peering with the NSX Edge nodes to exchange routing information. This explicitly includes the advertisement of a default route from the physical network to the NSX Tier-0 for external access. (Reference: VMware Cloud Foundation Documentation

Architecture and Design Guide

Section: NSX-T Data Center Design for VMware Cloud Foundation).

3. VMware NSX Administration Guide: The guide's section on "Configure BGP on a Tier-0 Gateway" explains the process of setting up BGP neighbors and route filters. It implicitly relies on the BGP peer (the ToR) being correctly configured to send the desired routes. Verifying received routes is a standard troubleshooting step

and an empty or incomplete list of received routes points to a configuration issue on the advertising peer. (Reference: VMware NSX Product Documentation

NSX Administration Guide

Chapter: Tier-0 Gateways

Section: Configure BGP).

To influence BGP route path selection, administrators manipulate BGP attributes. AS-Path Prepend is used on outbound route advertisements to artificially lengthen the ASPATH attribute. Since BGP prefers shorter paths, this makes the advertised route less preferable to external peers, influencing inbound traffic flow away from that path. The Multi-Exit Discriminator (MED) attribute is also advertised to an external peer to influence how that peer sends traffic into the local AS when multiple entry points exist. A lower MED value is preferred, making it the chosen path for inbound traffic. Both are standard BGP traffic engineering mechanisms available on an NSX Tier-0 Gateway.

A. BFD: Bidirectional Forwarding Detection (BFD) is a protocol used for rapid failure detection of the forwarding path, not a BGP attribute for path selection.

B. Cost: Cost is a metric used by Interior Gateway Protocols (IGPs) like OSPF to determine the best path within an autonomous system, not a standard BGP attribute.

1. VMware NSX Documentation

"Route Maps on Tier-0 Gateways": This official document details the configuration of route maps on Tier-0 gateways to manipulate BGP updates. It explicitly lists set as-path-prepend and set med as available actions to influence routing decisions. (Search for "Route Maps on Tier-0 Gateways" in the VMware NSX product documentation for the relevant version).

2. VMware NSX Documentation

"Add a Tier-0 Gateway": In the section describing BGP configuration for a Tier-0 gateway

the documentation outlines the use of route maps for filtering and modifying BGP advertisements

which includes setting attributes like AS-Path and MED for traffic engineering. (Search for "Configure BGP on a Tier-0 Gateway" in the VMware NSX product documentation).

3. VMware NSX Reference Design Guide: This guide discusses north-south connectivity patterns and often details best practices for traffic engineering using BGP. It describes using AS-Path prepending and MED to influence inbound traffic routing from upstream physical routers to the NSX environment. (Refer to the BGP routing design sections in the latest NSX Reference Design Guide).

The scenario describes a common issue after replacing a failed NSX Manager node where the old node's configuration entry persists, causing a "Degraded" cluster status. According to official VMware NSX documentation, the correct procedure to forcibly remove a failed or unrecoverable node from the cluster's configuration is to use the detach node command. This command must be run from the command-line interface (CLI) of a healthy, surviving manager node in the cluster, specifying the UUID of the old, failed node. This action purges the stale record, resolves the inconsistency, and allows the cluster to return to a stable, healthy state.

B. delete node : This is not the correct or documented NSX CLI command for removing a manager node from the cluster. The proper command verb is detach.

C. detach node then delete node : This option is incorrect because it includes the non-standard delete node command. The entire procedure requires only a single detach node command.

D. detach node: This is an incomplete command. The detach node command requires the specific UUID of the node to be removed as a mandatory argument to function correctly.

1. VMware NSX-T Data Center 3.2 Administration Guide

Page 101

Section: "Remove a Failed NSX Manager Node from a Cluster".

The guide explicitly states: "If an NSX Manager node fails and cannot be recovered

remove it from the cluster. From the CLI of a healthy NSX Manager node in the cluster

run the detach node command." This confirms the exact syntax and procedure.

2. VMware NSX 4.1 Administration Guide

Section: "NSX Manager Life Cycle" -> "Remove a Failed NSX Manager Node from a Cluster".

This more recent documentation reiterates the same procedure: "From the CLI of a healthy NSX Manager node in the cluster

run the detach node command to remove the failed node." This shows the command has remained consistent across versions.

The scenario requires providing outbound internet access to multiple isolated labs that use the same internal IP addresses. This is a classic use case for Source Network Address Translation (SNAT). SNAT translates the private, non-routable source IP addresses of the lab machines into a public, routable IP address. This translation must occur at the edge of the logical network before traffic is sent to the public internet. In an NSX architecture, the Tier-0 gateway serves as this edge, connecting the logical overlay network to the physical underlay and the external world. Therefore, configuring SNAT rules on the Tier-0 gateway is the correct solution.

A. Configure DNAT rules on the Tier-1 gateway.

DNAT (Destination NAT) is used for inbound traffic, translating a public destination IP to a private internal IP. The requirement is for outbound access.

B. Configure isolation on the NSX segment.

Segment isolation restricts traffic between VMs on the same segment. It does not provide a mechanism for external network connectivity or address translation.

C. Configure firewall rules to isolate the traffic going to the public internet.

Firewall rules permit or deny traffic based on policy. They do not perform the IP address translation necessary to solve the overlapping IP address problem for internet access.

1. VMware Docs

NSX-T Data Center Administration Guide

"NAT" section: "SNAT (Source NAT) is used to translate a private IP address to a public IP address. SNAT is for traffic that originates in the NSX-T Data Center domain and has a destination outside the NSX-T Data Center domain. A common use case for SNAT is to provide Internet access to VMs on a private network." This document confirms SNAT is the correct technology for the use case.

2. VMware Docs

NSX-T Data Center Administration Guide

"Add a Tier-0 Gateway" section: "A Tier-0 gateway provides a gateway service between the logical and physical network. It is required if you want to connect your VMs to the physical network." This establishes the Tier-0 as the correct location for North-South traffic services like public internet access.

3. VMware Press

NSX-T Reference Design Guide

Section 5.2.1 "Tier-0 Gateway": "The T0-GW is responsible for connecting the NSX logical space with the physical network... It is where stateful services such as NAT

Gateway Firewall

and VPN can be enabled." This reference explicitly places the NAT function on the Tier-0 gateway for connecting to external networks.

NAT64 in VMware NSX is a stateful translation service that enables communication between IPv6-only and IPv4-only networks. It is supported on both Tier-0 and Tier-1 gateways. A key requirement for its implementation is that the gateway (either Tier-0 or Tier-1) where NAT64 is configured must be in an active-standby High Availability (HA) mode. This is because NAT64 is a centralized service hosted on the Services Router (SR) component of the gateway, which operates in an active-standby configuration to maintain translation state consistently.

A. NAT64 is a stateful translation mechanism, not stateless. It must maintain a session table to map IPv6 addresses and ports to their IPv4 counterparts for the duration of a connection.

C. NAT64 is supported on both Tier-0 and Tier-1 gateways, providing flexibility for different network topology designs, not just on Tier-1 gateways.

E. NAT64 requires the gateway to be in active-standby mode to ensure state consistency. Active-active mode is not supported for this specific service.

1. VMware NSX 4.1 Documentation

NSX Administration Guide

"NAT64" section.

Reference for B & E: "NAT64 is a centralized service. For a Tier-0 gateway

the service is hosted on a SR (Services Router) in active-standby HA mode. For a Tier-1 gateway

the service is hosted on a SR in active-standby HA mode." This confirms the active-standby requirement for both gateway types.

Reference for C & D: "You can configure NAT64 rules on Tier-0 and Tier-1 gateways." This confirms support on both gateway tiers.

Reference for A: The document describes NAT64 as a translation mechanism that "allows IPv6-only clients to contact IPv4-only servers

" which inherently requires stateful connection tracking

a core principle of NAT. The active-standby requirement also points to the need to synchronize state

which is a characteristic of stateful services.

To successfully implement OSPF on a VMware NSX Tier-0 Gateway, an administrator must configure two primary components after enabling the main protocol toggle. First, an OSPF Area must be explicitly defined (such as a backbone Area 0 or a normal area) by selecting the "Set" option next to "Area Definition". Second, the administrator must attach specific Tier-0 external or service interfaces to this defined area by selecting the "Set" option next to "OSPF Configured Interfaces". Without defining the routing area and actively assigning local interfaces to participate within it, the Tier-0 gateway cannot form OSPF neighbor adjacencies or exchange link-state advertisements.

VMware. VMware NSX-T Data Center Administration Guide. Chapter: Routing, Section: "Configure OSPF on a Tier-0 Gateway". (Specifically, the configuration steps mandating the creation of an OSPF area and the subsequent mapping of Tier-0 uplink/loopback interfaces to the specified OSPF area).

In VMware NSX-T, when an Active/Standby Tier-1 Gateway (necessitated by stateful services like a Gateway Firewall) is connected to an Active/Active Tier-0 Gateway within the same Edge Cluster, traffic aligns to the Edge Node hosting the active Tier-1 Service Router (SR). To prevent suboptimal routing and unnecessary inter-node tunneling (hairpinning), the active Tier-1 SR on EN2 routes northbound traffic directly to the local Tier-0 SR instance residing on that same Edge Node. The local Tier-0 SR then utilizes its own direct uplinks (P1 and P2 on EN2) to establish ECMP paths to the physical Top-of-Rack (ToR) switches.

VMware. (2022). VMware NSX-T Data Center Reference Design Guide, Chapter 4: Logical Routing, Section: Edge Cluster Design (Tier-0 A/A and Tier-1 A/S routing mechanics). Official VMware Documentation.

VMware. (2023). NSX Administration Guide, "Routing and Service Run States," Routing architectures for stateful services. Official VMware Documentation.

In a network virtualization architecture using NSX-T, virtual machines (like VM-1) generate standard, unencapsulated traffic. When this traffic needs to traverse an Overlay-Segment to reach a VM on another host (VM-2), the source host's hypervisor encapsulates the original frame at the Tunnel Endpoint (TEP). This process adds an outer IP, UDP, and GENEVE header. To observe this fully encapsulated GENEVE packet using a protocol analyzer like Wireshark, the capture must be performed on the physical uplink interface (vmnic0) as the packet exits the host toward the physical datacenter fabric. Capturing at the VM's vNIC would only yield the unencapsulated inner payload.

VMware Docs: VMware NSX-T Data Center Administration Guide, "Packet Capture and Network Troubleshooting". Sections detailing pktcap-uw usage specify that capturing on the physical uplink (vmnic) is required to view the outer encapsulation headers (GENEVE/UDP/IP) before traffic enters the physical fabric.

IETF RFC 8926: "Geneve: Generic Network Virtualization Encapsulation", Section 3.1 (Encapsulation over IPv4/IPv6) and Section 4.1 (Transit Devices). DOI: 10.17487/RFC8926. This defines how the inner payload is encapsulated by the tunnel endpoint and transmitted over the physical transit infrastructure.

In VMware NSX-T, North-to-South (incoming) traffic arriving at the Edge Node's Tier-0 Service Router (SR) is first routed locally to the Tier-0 Distributed Router (DR). The Tier-0 DR then forwards the packet to the locally instantiated Tier-1 Distributed Router (DR) on the same Edge Node. Routing happens closest to the ingress point; therefore, the Edge Node's Tier-1 DR performs the final routing lookup for the destination logical segment. Once routed, the Edge Node encapsulates the packet and sends it via the Geneve overlay directly to the Compute Hypervisor's Transport Endpoint (TEP), entirely bypassing the Compute Node's Tier-1 DR. Since the Tier-0 DR is not highlighted, the Tier-1 DR on the Edge Node is the correct next highlighted hop.

VMware NSX-T Data Center Reference Design Guide, Chapter 4: Routing (Section: Packet Walks - Physical to Logical / North-to-South).

VMware NSX Documentation: "Logical Routing and Forwarding", detailing the separation and packet flow between Distributed Routers (DR) and Service Routers (SR).

In a VMware NSX multi-tier routing architecture, route leaking is utilized to facilitate efficient East-West communication between isolated routing domains (such as VRFs) without requiring traffic to hairpin through oversubscribed physical L3 devices. To govern this exchange and prevent routing loops, route-maps are configured and applied directly at the Tier-0 Gateway level. These route-maps act as explicit filtering mechanisms, defining the exact prefixes that are permitted to be exported or imported between the distinct Tier-0 routing tables. Therefore, the hotspot configuration target must be the Tier-0 Gateway.

VMware. (2023). VMware NSX 4.1 Administration Guide. "Routing and Forwarding - VRF Route Leaking." Document ID: VMware-NSX-4.1-Admin. (Specifies that route maps for inter-VRF leaking are applied at the Tier-0 configuration).

VMware. (2023). NSX Multi-Tenancy Architecture and Design Guide. "Tier-0 Gateway and Route Map Configurations." (Details the logical placement of routing policies to optimize East-West traffic bypassing physical fabric).