Free 3V0-25.25 Practice Test

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 Transit Gateway (TGW) is the component that provides connectivity between a Virtual Private Cloud (VPC) and external networks, such as a physical datacenter. It establishes BGP peering with the datacenter routers to exchange routing information. To control which routes are advertised from the VPC, a routing policy (typically a route map with a prefix list) must be applied to the BGP session on the TGW. This policy can be configured to filter outgoing (export) advertisements to prevent the VPC's prefixes from being sent to the datacenter, while still allowing the TGW to learn incoming routes, such as the required default route.

A. On the VPC default route advertiser: This is incorrect because the policy needs to be applied at the point where VPC routes are exported, which is the VPC's TGW, not necessarily the external device advertising the default route to the VPC.
C. On the providers' BGP peer template: Applying a policy to a template would likely affect all BGP peers configured from that template, not just the specific new VPC as required by the scenario. The TGW provides the necessary granular control.
D. On the VPC Gateway Firewall: The Gateway Firewall is responsible for enforcing stateful security policies on traffic flow (L4-L7). It does not control the advertisement of network prefixes via the BGP routing protocol.

1. VMware NSX-T Data Center Administration Guide (NSX 3.2): In the "BGP" chapter, section "Configure BGP Route Filtering," it states, "You can apply a route map to a BGP neighbor to filter the routes that are received from and advertised to the neighbor." The BGP neighbor configuration for a VPC is on its Transit Gateway (which is a dedicated Tier-0 Gateway). Applying an "out" filter here achieves the desired outcome. (Reference: VMware NSX-T Data Center 3.2 Administration Guide, Chapter: BGP, Section: Configure BGP Route Filtering).

2. VMware NSX Design Guide (NSX 4.1): The guide explains the architecture of NSX VPC, stating, "Each VPC is connected to a transit gateway for north-south connectivity... The transit gateway is a dedicated Tier-0 gateway that is instantiated when the first VPC is created." This establishes the TGW as the routing boundary where policies for external connectivity are applied. (Reference: VMware NSX 4.1 Design Guide, Chapter 10: NSX for vSphere with Tanzu, Section: NSX VPC).

3. VMware NSX-T Data Center Product Documentation (NSX 4.x): The documentation on "Add a Route Map" for BGP configuration on a Tier-0 Gateway explicitly shows the option to set the direction to "Out". This directly supports applying a policy on the TGW to control exported prefixes. (Reference: VMware NSX 4.1 Administration Guide, Section: Add a Route Map).

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.

In VMware NSX-T (the networking underpinning VMware Cloud Foundation), IPSec VPNs are classified as stateful services. All stateful services—such as NAT, load balancing, and VPNs—require a centralized Service Router (SR) component hosted on the NSX Edge nodes. To maintain the connection state and ensure traffic is not routed asymmetrically and dropped, these services strictly require the gateway to be deployed in an Active-Standby high availability (HA) configuration. Active-Active gateways only provide distributed routing (stateless) and do not support IPSec VPNs. Therefore, both Tier-0 and Tier-1 gateways are supported for IPSec VPNs, provided they are in Active-Standby mode.

VMware NSX-T Data Center Administration Guide – Virtual Private Network (VPN) > IPsec VPN: This documentation section explicitly dictates that to configure an IPsec VPN service, the Tier-0 or Tier-1 gateway must be configured in Active-Standby high availability mode.

VMware Cloud Foundation Design Guide – NSX Edge Node Design: Highlights the architectural requirement that stateful services (Edge Firewall, NAT, VPN) mandate an Active-Standby gateway configuration on the Edge cluster, contrasting with Active-Active which is strictly for ECMP routing without 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).