JN0-683: Data Center Professional

Understanding EVPN-VXLAN Architectures:

EVPN-VXLAN overlays allow for scalable Layer 2 and Layer 3 services in modern data centers.

CRB (Centralized Routing and Bridging): In this architecture, the Layer 3 routing is centralized on spine devices, while the leaf devices focus on Layer 2 switching and VXLAN tunneling. This setup is optimal when the goal is to centralize routing for ease of management and to avoid complex routing at the leaf level.

ERB (Edge Routing and Bridging): This architecture places routing functions on the leaf devices, making it a distributed model where each leaf handles routing for its connected hosts.

Architecture Choice for Spine Routing:

Given the requirement to ensure Layer 3 routing happens on the spine devices, the CRB (Centralized Routing and Bridging) architecture is the correct choice. This configuration offloads routing tasks to the spine, centralizing control and potentially simplifying the overall design.

With CRB, the spine devices perform all routing between VXLAN segments. Leaf switches handle local switching and VXLAN encapsulation, but routing decisions are centralized at the spine level.

This model is particularly advantageous in scenarios where centralized management and routing control are desired, reducing the complexity and configuration burden on the leaf switches.

Data Center

Reference:

The CRB architecture is commonly used in data centers where centralized control and simplified management are key design considerations. It allows the spines to act as the primary routing engines, ensuring that routing is handled in a consistent and scalable manner across the fabric.

Understanding the Exhibit Setup:

The network diagram shows an EVPN-VXLAN setup, a common design for modern data centers enabling Layer 2 and Layer 3 services over an IP fabric.

Leaf1 and Leaf2 are the leaf switches connected to Server1 and Server2, respectively, with each server in a different subnet (172.16.1.0/24 and 172.16.2.0/24).

Spine1 and Spine2 are part of the IP fabric, interconnecting the leaf switches.

EVPN-VXLAN Basics:

EVPN (Ethernet VPN) provides Layer 2 and Layer 3 VPN services using MP-BGP.

VXLAN (Virtual Extensible LAN) encapsulates Layer 2 frames into Layer 3 packets for transmission across an IP network.

VTEP (VXLAN Tunnel Endpoint) interfaces on leaf devices handle VXLAN encapsulation and decapsulation.

Integrated Routing and Bridging (IRB):

IRB interfaces are required on leaf1 and leaf2 (where the endpoints are directly connected) to route between different subnets (in this case, between 172.16.1.0/24 and 172.16.2.0/24).

The IRB interfaces provide the necessary L3 gateway functions for inter-subnet communication.

Traffic Flow Analysis:

Traffic from Server1 (172.16.1.1) destined for Server2 (172.16.2.1) must traverse from leaf1 to leaf2.

The traffic will be VXLAN encapsulated on leaf1, sent over the IP fabric, and decapsulated on leaf2.

Since the communication is between different subnets, the IRB interfaces on leaf1 and leaf2 are crucial for routing the traffic correctly.

Correct Statements:

C . An IRB Interface must be configured on leaf1 and leaf2: This is necessary to perform the inter-subnet routing for traffic between Server1 and Server2.

D . Traffic from server1 to server2 will transit the VXLAN tunnel between leaf1 and leaf2: This describes the correct VXLAN operation where the traffic is encapsulated by leaf1 and decapsulated by leaf2.

Data Center

Reference:

In EVPN-VXLAN architectures, the leaf switches often handle both Layer 2 switching and Layer 3 routing via IRB interfaces. This allows for efficient routing within the data center fabric without the need to involve the spine switches for every routing decision.

The described traffic flow aligns with standard EVPN-VXLAN designs, where direct VXLAN tunnels between leaf switches enable seamless and scalable communication across a data center network.

Understanding the Configuration:The configuration shown in the exhibit involves an EVPN (Ethernet VPN) setup using BGP as the routing protocol. The export policy named CHANGE_NH is applied to the BGP group evpn-peer, which includes a rule to change the next hop for routes that match the policy.Issue with Next Hop Not Changing:The policy CHANGE_NH is correctly configured to change the next hop to 203.0.113.10 for the matching routes. However, the next hop remains unchanged when advertising EVPN routes to the peer 203.0.113.2.Reason for the Issue:In Junos OS, when exporting routes for VPNs (including EVPN), the next-hop change defined in a policy will not take effect unless the vpn-apply-export parameter is used in the BGP configuration. This parameter ensures that the export policy is applied specifically to VPN routes.The vpn-apply-export parameter must be included to apply the next-hop change to EVPN routes.Answer: Explanation:D . The vpn-apply-export parameter must be applied to this peer: This is the correct solution because the next hop in EVPN routes won't be altered without this parameter in the BGP configuration. It instructs the BGP process to apply the export policy to the EVPN routes.Data Center

Reference:This behavior is standard in EVPN deployments with Juniper Networks devices, where the export policies applied to VPN routes require explicit invocation using vpn-apply-export to take effect.