Visit here for our full Cisco 350-601 exam dumps and practice test questions.
Question 181:
An engineer is configuring a Cisco Nexus switch to support jumbo frames. What is the default MTU size for Layer 3 interfaces on Nexus switches?
A) 1500 bytes
B) 9000 bytes
C) 9216 bytes
D) 1518 bytes
Answer: A
Explanation:
The default MTU size for Layer 3 interfaces on Cisco Nexus switches is 1500 bytes, which is the standard Ethernet MTU that accommodates traditional IP packets without fragmentation. This default value matches the historical Ethernet standard and ensures compatibility with networks that have not been specifically configured for jumbo frames. Administrators must explicitly configure larger MTU values when jumbo frame support is required.
MTU or Maximum Transmission Unit defines the largest packet size that can traverse an interface without fragmentation. The 1500-byte default represents the payload size and does not include the Ethernet header and trailer overhead. Including Layer 2 overhead, the complete frame can be 1518 bytes for untagged frames or 1522 bytes for VLAN-tagged frames.
Layer 3 MTU configuration on Nexus switches applies to routed interfaces created with the no switchport command. These interfaces function as router ports forwarding IP traffic between different subnets. The MTU setting determines the maximum IP packet size the interface accepts and forwards.
Jumbo frames with MTU values larger than 1500 bytes can improve network performance for applications transferring large amounts of data by reducing packet processing overhead and increasing throughput efficiency. Common jumbo frame sizes include 9000 bytes and 9216 bytes, though the specific value depends on network design requirements.
Configuring jumbo frames requires changing MTU on all devices in the traffic path including switches, routers, servers, and storage systems. Inconsistent MTU settings cause fragmentation or packet drops degrading performance. End-to-end consistency is critical for successful jumbo frame implementation.
The MTU configuration command on Nexus Layer 3 interfaces is mtu size where size specifies the desired MTU in bytes. For example, mtu 9000 configures the interface to support 9000-byte jumbo frames. This configuration should be applied consistently across all interfaces in the forwarding path.
While 9000 bytes is a common jumbo frame size, it is not the default MTU on Nexus switches. The 9000-byte MTU must be explicitly configured when required for specific applications like iSCSI storage, NFS file systems, or high-performance computing environments that benefit from reduced packet processing.
The value 9216 bytes represents the maximum jumbo frame size supported by many Nexus platforms and is sometimes used in storage networks. However, this is not the default MTU setting. Like 9000 bytes, the 9216-byte MTU requires explicit configuration.
The value 1518 bytes represents the maximum standard Ethernet frame size including headers and trailers but this is not how MTU is specified. MTU refers to the Layer 3 payload size of 1500 bytes, while 1518 bytes includes the 14-byte Ethernet header and 4-byte FCS trailer.
Question 182:
A data center administrator is implementing Cisco ACI and needs to understand policy enforcement. At which layer does the ACI fabric enforce policy?
A) Only at the leaf switches
B) Only at the spine switches
C) At both leaf and spine switches
D) Only at the APIC controller
Answer: A
Explanation:
The ACI fabric enforces policy only at the leaf switches, which serve as the policy enforcement points for all traffic entering or exiting the fabric. Leaf switches contain the hardware-based policy enforcement engines that evaluate traffic against configured contracts and apply appropriate permit, deny, redirect, or marking actions. This distributed enforcement architecture provides line-rate policy application without bottlenecks.
Leaf switches receive policy information from the APIC controller which translates high-level application policies into specific forwarding and filtering rules. The APIC renders these policies into concrete configurations and pushes them to appropriate leaf switches where hardware ASICs enforce them at wire speed. This separation between policy definition and enforcement enables centralized management with distributed execution.
Policy enforcement occurs when traffic crosses endpoint group boundaries. When a packet arrives at a leaf switch, the switch identifies the source and destination EPGs then consults configured contracts to determine allowed interactions. Only traffic permitted by contracts is forwarded while unauthorized traffic is dropped at the ingress leaf switch.
The leaf switch enforcement model ensures that policy is applied consistently regardless of traffic paths through the fabric. Since all traffic enters and exits through leaf switches, enforcing policy at these points guarantees complete coverage. Spine switches simply forward VXLAN-encapsulated traffic based on underlay routing without inspecting overlay policies.
Hardware-based policy enforcement in leaf switch ASICs enables multi-terabit throughput without performance degradation. The parallel processing architecture applies policy to all traffic simultaneously ensuring that security and segmentation do not compromise application performance. This hardware acceleration is essential for modern data center scale requirements.
ACI’s distributed enforcement contrasts with traditional firewall architectures where traffic must traverse centralized enforcement points. Distributed enforcement eliminates potential bottlenecks and provides optimal traffic paths while maintaining consistent security policies across the entire fabric.
Spine switches do not enforce policy in ACI fabric architecture. Spine switches operate exclusively in the underlay network forwarding VXLAN-encapsulated packets based on outer IP headers. They do not inspect inner headers or evaluate contracts making them simple high-speed forwarding devices that scale effectively.
Policy is not enforced at both leaf and spine switches. The clear division of responsibility where leaf switches handle policy enforcement and spine switches handle forwarding simplifies the architecture and enables independent scaling of each layer. This separation is fundamental to ACI’s design philosophy.
The APIC controller does not enforce policy on data plane traffic. APIC defines and distributes policies but does not sit in the traffic path. All data flows directly between leaf switches through spine switches bypassing the APIC entirely. This architecture ensures management plane issues do not affect data plane performance.
Question 183:
An engineer is troubleshooting VXLAN connectivity and needs to verify VTEP peer discovery. Which protocol does VXLAN with multicast underlay use for VTEP discovery?
A) PIM
B) IGMP
C) BGP
D) Flood-and-learn
Answer: D
Explanation:
VXLAN with multicast underlay uses flood-and-learn mechanisms for VTEP discovery where VTEPs learn about remote VTEPs by receiving flooded traffic from them. When a VTEP needs to send broadcast, unknown unicast, or multicast traffic for a VNI, it encapsulates the frames and sends them to the multicast group associated with that VNI. All VTEPs subscribed to that multicast group receive the traffic and learn the source VTEP’s IP address.
The flood-and-learn process works similarly to traditional MAC learning in switches. When a VTEP receives a VXLAN packet from the multicast group, it examines the outer IP header to identify the source VTEP IP address and the inner Ethernet frame to learn the source MAC address. The VTEP creates a mapping between the MAC address and the source VTEP enabling future unicast traffic to that MAC to be sent directly to the appropriate VTEP.
This dynamic learning eliminates the need for manual VTEP configuration or centralized control plane protocols. As VTEPs send and receive flooded traffic through multicast groups, they automatically discover peers and build forwarding tables. The approach is simple to implement and works well in smaller deployments with limited numbers of VTEPs.
Multicast underlay configuration requires PIM to build multicast distribution trees and IGMP for VTEPs to join multicast groups, but these protocols support the flood-and-learn process rather than being the discovery mechanism itself. The actual VTEP discovery happens through receiving flooded data plane traffic.
Flood-and-learn has limitations including inefficient use of network bandwidth due to flooding, slower convergence compared to control plane protocols, and scalability challenges in large deployments. Modern implementations often use EVPN control plane instead of flood-and-learn for better efficiency and scale.
In EVPN-based VXLAN, BGP replaces flood-and-learn for VTEP discovery and MAC learning. EVPN provides more efficient and scalable operations but requires more complex configuration. The choice between flood-and-learn and EVPN depends on deployment size and requirements.
PIM or Protocol Independent Multicast builds and maintains multicast distribution trees in the underlay network enabling efficient delivery of multicast traffic. While PIM is essential for multicast underlay operation, it does not directly perform VTEP discovery. PIM ensures flooded VXLAN traffic reaches all interested VTEPs but the VTEPs themselves learn peers through flood-and-learn.
IGMP enables VTEPs to join and leave multicast groups associated with VNIs. VTEPs use IGMP to subscribe to multicast groups ensuring they receive flooded traffic for relevant VNIs. While IGMP is necessary for multicast operation, the actual VTEP discovery occurs when VTEPs receive and process flooded traffic.
BGP is used in EVPN control plane architectures as an alternative to flood-and-learn. In EVPN VXLAN, BGP with EVPN address family advertises VTEP information and MAC addresses eliminating the need for data plane learning. However, multicast underlay VXLAN uses flood-and-learn not BGP for discovery.
Question 184:
A network administrator is configuring Spanning Tree Protocol on Nexus switches. Which STP enhancement prevents temporary loops during topology changes by keeping ports in blocking state until they are ready to forward?
A) PortFast
B) BPDU Guard
C) BPDU Filter
D) BackboneFast
Answer: A
Explanation:
PortFast is the STP enhancement that transitions edge ports directly to forwarding state bypassing listening and learning states, but the question asks about preventing loops during topology changes by keeping ports in blocking state until ready. Actually, this description best matches standard STP behavior, but among the options provided, none perfectly describes this. However, examining the intent, the question seems to be asking about STP port state transitions, and PortFast is the most relevant enhancement that affects port state transitions.
Let me reconsider the question. The description of keeping ports in blocking state until ready to forward actually describes the normal STP operation through listening and learning states. Among the provided options, none specifically does this, but PortFast actually does the opposite by skipping these states for edge ports.
Given the options, this appears to be a flawed question, but in the context of STP enhancements and based on the options provided, I’ll provide accurate information about PortFast:
PortFast enables rapid transition to forwarding state for access ports connected to end devices. When PortFast is enabled on a port, that port skips the normal listening and learning states and moves directly from blocking to forwarding. This reduces the time end devices wait for network connectivity from approximately 30 seconds to just a few seconds.
PortFast should only be enabled on ports connected to end devices that do not generate BPDUs or create loops. Enabling PortFast on ports connected to switches or bridges can create temporary loops during topology changes. Proper deployment limits PortFast to access ports serving workstations, servers, or other endpoint devices.
The feature improves user experience by eliminating the delay between connecting a device and establishing network connectivity. Without PortFast, users must wait while STP transitions through listening and learning states before the port forwards traffic. This delay affects DHCP client behavior and application startup.
PortFast edge configuration on Nexus switches uses the spanning-tree port type edge command. This configuration clearly indicates the port connects to an edge device and should use rapid transition. Modern best practices combine PortFast with BPDU Guard for additional security.
BPDU Guard protects PortFast-enabled ports by shutting them down if BPDUs are received indicating another switch has been connected. This security feature prevents accidental or malicious loop creation when PortFast ports are misused. BPDU Guard does not directly affect port state transitions but protects against configuration errors.
BPDU Filter prevents ports from sending or receiving BPDUs which can be useful in specific scenarios but generally should be avoided as it disables STP protection. BPDU Filter does not keep ports in blocking state but rather removes them from STP topology consideration entirely creating potential loop risks.
BackboneFast is a Cisco proprietary STP enhancement that speeds convergence when indirect link failures occur by reducing the maximum age timer. BackboneFast helps with faster convergence but does not specifically address keeping ports in blocking state until ready to forward.
Question 185:
An engineer is configuring storage networking and needs to understand Fibre Channel zones. What is the primary purpose of zoning in a Fibre Channel fabric?
A) Load balancing traffic across multiple paths
B) Controlling which devices can communicate with each other
C) Encrypting data in transit between devices
D) Compressing storage traffic to save bandwidth
Answer: B
Explanation:
The primary purpose of zoning in Fibre Channel fabrics is controlling which devices can communicate with each other by creating logical security boundaries within the SAN. Zoning restricts visibility and access between Fibre Channel devices ensuring that hosts can only see and access authorized storage resources. This access control is fundamental to SAN security and multi-tenant operation preventing unauthorized data access.
Zoning operates at the Fibre Channel switch level creating enforcement points that filter traffic based on zone membership. Devices can only establish sessions with other devices in the same zone. This restriction prevents hosts from discovering or accessing storage they should not see, protecting data confidentiality and integrity.
Two primary zoning types exist: WWN-based zoning that uses World Wide Names to identify devices, and port-based zoning that uses physical switch ports. WWN zoning provides flexibility allowing devices to move between ports without reconfiguration, while port zoning offers simplicity and performance. Most deployments use WWN zoning for its mobility advantages.
Zone configurations contain multiple zones each defining a set of members that can communicate. A device can be a member of multiple zones enabling controlled sharing of resources. The active zone set represents the currently enforced configuration distributed to all switches in the fabric ensuring consistent policy enforcement.
Proper zoning is critical for SAN security and stability. Without zoning, all devices see all other devices creating security vulnerabilities and potential configuration errors. Hosts might accidentally discover and modify LUNs belonging to other systems causing data corruption. Zoning provides essential isolation in shared SAN environments.
Zoning works with LUN masking to provide comprehensive access control. Zoning controls visibility at the fabric level while LUN masking at the storage array level determines which LUNs specific initiators can access. Together these mechanisms ensure that hosts access only their designated storage.
Load balancing traffic across multiple paths is accomplished through multipathing software and protocols like ALUA not through zoning. While proper zoning configuration can influence path selection by controlling fabric topology visibility, load balancing is not the primary purpose of zoning.
Encryption of Fibre Channel data in transit is provided by technologies like FC-SP or link-level encryption not zoning. Zoning controls access and visibility but does not encrypt data. Some SAN environments implement encryption for data at rest or in transit separately from zoning.
Compression of storage traffic to save bandwidth is handled by data reduction technologies at the storage array or host level not through Fibre Channel zoning. Zoning operates at the access control layer and does not modify or compress data payloads.
Question 186:
A data center uses Cisco Nexus switches with VDC feature. What is the primary benefit of Virtual Device Contexts?
A) Increasing switching capacity beyond hardware limits
B) Partitioning a physical switch into multiple logical switches
C) Enabling Layer 2 multipath forwarding
D) Providing hardware redundancy for control plane
Answer: B
Explanation:
The primary benefit of Virtual Device Contexts is partitioning a single physical Nexus switch into multiple logical switches each operating as an independent device with its own configuration, management, and resources. VDCs enable organizations to consolidate multiple physical switches onto one hardware platform while maintaining complete isolation between logical instances. This virtualization reduces hardware costs, power consumption, and data center space requirements.
Each VDC functions as a separate logical switch with dedicated interfaces, routing tables, spanning tree instances, and management plane. Administrators manage VDCs independently with separate login credentials, configurations, and administrative domains. This isolation enables different teams or tenants to share hardware while maintaining complete operational independence.
VDC assignment of physical interfaces ensures that each VDC controls specific ports preventing interference between contexts. An interface assigned to one VDC cannot be used by another VDC providing complete traffic isolation. This hard partitioning differs from VLANs which share interfaces and switch resources.
Resource allocation in VDCs includes CPU bandwidth, memory allocation, and forwarding table space ensuring fair resource sharing and preventing one VDC from monopolizing switch resources. Administrators can configure resource limits guaranteeing minimum performance levels for critical VDCs while allowing best-effort operation for less critical contexts.
VDCs are particularly valuable for service providers offering managed services to multiple customers, large enterprises with separate network teams for different business units, and data centers consolidating test and production environments. The logical separation provides security and independence while hardware sharing reduces costs.
Only certain Nexus switch families support VDCs including the Nexus 7000 series. Other Nexus platforms like the Nexus 9000 in standalone mode do not provide VDC capabilities. Understanding platform capabilities is important when designing networks with VDC requirements.
VDCs do not increase switching capacity beyond hardware limits. The physical switch’s backplane, ASICs, and port count remain constant regardless of VDC configuration. VDCs partition existing capacity among logical instances rather than expanding total capacity. For additional capacity, additional physical hardware is required.
Layer 2 multipath forwarding is provided by technologies like VPC, FabricPath, or VXLAN not by VDCs. While VDCs can run these technologies within logical contexts, VDC itself does not enable multipathing. VDCs focus on administrative and resource partitioning.
Hardware redundancy for the control plane is provided by features like dual supervisor modules and ISSU not by VDCs. VDCs create logical separation on existing hardware but do not provide additional physical redundancy. Control plane redundancy requires redundant hardware components.
Question 187:
An administrator is configuring AAA on a Nexus switch for user authentication. Which AAA method list should be configured to try RADIUS first and fall back to local authentication if RADIUS is unavailable?
A) aaa authentication login default group radius local
B) aaa authentication login default local group radius
C) aaa authentication login default group tacacs+ local
D) aaa authentication login radius local
Answer: A
Explanation:
The AAA method list configuration aaa authentication login default group radius local correctly configures the switch to attempt RADIUS authentication first and fall back to local authentication if RADIUS servers are unreachable or unresponsive. The method list processes authentication methods in the order specified, trying each subsequent method only if previous methods fail or are unavailable.
The default keyword indicates this method list applies to all login sessions unless a more specific method list is configured for particular lines or interfaces. Using default ensures consistent authentication policy across console, SSH, and Telnet access methods. This centralized policy simplifies administration and ensures security consistency.
The group radius keyword instructs the switch to contact configured RADIUS servers for authentication. The switch sends authentication requests to RADIUS servers in the configured server group attempting each server until receiving a response. If all RADIUS servers are unreachable or timeout, the switch proceeds to the next method in the list.
The local keyword indicates that if RADIUS authentication fails or is unavailable, the switch should authenticate against local username and password database configured on the switch itself. Local authentication provides fallback access when centralized authentication infrastructure is unavailable ensuring administrators can access the switch during network outages.
This configuration represents best practice for production environments where centralized authentication provides security and audit benefits while local authentication ensures access during AAA server failures. The fallback capability balances security with operational requirements for emergency access.
Method list ordering is critical and affects authentication behavior. Placing local before group radius would attempt local authentication first defeating the purpose of centralized authentication. The order should reflect primary and backup authentication sources in order of preference.
The configuration aaa authentication login default local group radius places local authentication first which contradicts the requirement to try RADIUS first. This ordering would authenticate most users against local database only falling back to RADIUS if local authentication fails which is the opposite of the intended behavior.
The configuration aaa authentication login default group tacacs+ local uses TACACS+ instead of RADIUS. While TACACS+ is a valid AAA protocol providing similar functionality to RADIUS, the question specifically asks for RADIUS authentication. Organizations should use the AAA protocol that matches their infrastructure.
The syntax aaa authentication login radius local is incomplete and invalid. The default keyword or named method list is required to specify where the method list applies. Additionally, group keyword is needed before the protocol name. This command would be rejected by the switch configuration parser.
Question 188:
A network engineer is implementing Cisco FabricPath and needs to understand switch roles. Which FabricPath device type connects to classical Ethernet networks?
A) Spine switch
B) Edge switch
C) Core switch
D) Leaf switch
Answer: B
Explanation:
Edge switches in FabricPath topology connect to classical Ethernet networks providing the boundary between FabricPath domain and traditional Ethernet environments. Edge switches perform the critical function of translating between FabricPath and classical Ethernet forwarding behaviors enabling seamless integration with existing network infrastructure. This translation capability allows gradual FabricPath adoption without requiring wholesale network replacement.
FabricPath edge switches operate in dual mode supporting both FabricPath on core-facing interfaces and classical Ethernet on interfaces connecting to legacy switches, routers, or end devices. The edge switch converts between the two forwarding paradigms encapsulating classical Ethernet frames into FabricPath format when sending into the fabric and decapsulating when forwarding to classical Ethernet domains.
Edge switches maintain both classical Ethernet MAC address tables for locally connected devices and FabricPath forwarding information for remote destinations within the fabric. This dual forwarding table approach enables correct forwarding decisions based on destination location and path type. The integration of both forwarding modes in edge switches provides transparency to connected devices.
VLANs extend across FabricPath and classical Ethernet boundaries through edge switches. Edge switches forward tagged frames appropriately whether destined for FabricPath or classical Ethernet domains ensuring VLAN consistency throughout the network. This VLAN transparency simplifies migration and coexistence scenarios.
Edge switch capabilities enable incremental FabricPath deployment where organizations can introduce FabricPath in core and aggregation layers while maintaining classical Ethernet at access layers. This migration flexibility reduces risk and allows phased infrastructure modernization aligned with business requirements and budget constraints.
Multiple edge switches can connect the same classical Ethernet segment to FabricPath fabric providing redundancy and load balancing. FabricPath protocols ensure loop-free topology while allowing all links to forward traffic simultaneously unlike classical Ethernet’s spanning tree which blocks redundant links.
Spine switches in FabricPath topology provide high-speed interconnection between edge switches forming the fabric core. Spine switches run FabricPath protocols exclusively and do not connect to classical Ethernet networks. Their role focuses on efficient traffic forwarding within the FabricPath domain using shortest path routing.
Core switch is a general term describing devices in network cores but is not a specific FabricPath device type. In FabricPath terminology, spine switches comprise the core while edge switches provide connectivity to end devices and classical Ethernet networks.
Leaf switch terminology is typically associated with leaf-spine architectures in VXLAN or ACI fabrics rather than FabricPath. While leaf switches in VXLAN environments serve similar edge connectivity roles, FabricPath specifically uses edge switch terminology for devices connecting to classical Ethernet.
Question 189:
An administrator is configuring NX-OS and needs to schedule configuration backups. Which feature allows scheduling commands to run at specific times?
A) EEM
B) Scheduler
C) Cron
D) Configuration Rollback
Answer: B
Explanation:
The Scheduler feature on Cisco NX-OS allows administrators to schedule commands or scripts to run at specific times or recurring intervals. Scheduler provides native support for automated task execution including configuration backups, operational command execution, and script running. This built-in capability enables routine maintenance tasks without external automation tools or manual intervention.
Scheduler configuration involves creating jobs that specify commands to execute and schedules defining when jobs run. Jobs can execute single commands, multiple commands, or scripts stored in switch bootflash. Schedules support one-time execution at specific dates and times or recurring execution on daily, weekly, or monthly intervals.
For configuration backups, administrators create scheduler jobs that execute copy running-config commands saving configurations to local storage or remote servers. Scheduling these backups during off-peak hours or at regular intervals ensures recent configuration copies are available for disaster recovery without requiring manual backup procedures.
Scheduler integrates with switch logging systems generating syslog messages when jobs start, complete, or encounter errors. These logs provide audit trails of scheduled task execution and enable monitoring of automation effectiveness. Administrators can verify backup jobs completed successfully by reviewing scheduler logs.
The feature supports complex scheduling scenarios including multiple jobs running at different intervals, jobs with dependencies, and jobs that execute only under specific conditions. This flexibility accommodates diverse operational requirements from simple daily backups to complex maintenance workflows.
Scheduler persistence ensures that jobs and schedules survive switch reboots. Configuration is saved in startup config and automatically restored during boot allowing scheduled tasks to continue operating reliably. This persistence is essential for production environments where automation must survive maintenance and failures.
EEM or Embedded Event Manager provides event-driven automation responding to system events like interface state changes or syslog messages. While powerful for reactive automation, EEM is event-driven rather than time-based. For scheduled time-based execution, Scheduler is the appropriate feature.
Cron is a time-based job scheduler found in Unix and Linux operating systems but is not a native feature of Cisco NX-OS. While administrators familiar with Unix might conceptually compare Scheduler to cron, NX-OS uses its own Scheduler implementation rather than incorporating Linux cron.
Configuration Rollback enables reverting to previous configuration checkpoints when changes cause problems. Rollback is a recovery feature rather than a scheduling mechanism. Rollback does not execute commands at scheduled times but restores configurations on demand when needed.
Question 190:
A data center network uses MP-BGP EVPN for VXLAN control plane. Which BGP address family is used for EVPN routes?
A) IPv4 unicast
B) L2VPN EVPN
C) VPNv4
D) IPv6 unicast
Answer: B
Explanation:
The L2VPN EVPN address family is specifically designed for carrying EVPN routes in MP-BGP. This address family extends BGP to support Layer 2 VPN services and VXLAN overlay networks by defining new NLRI types for MAC addresses, IP addresses, and multicast information. EVPN address family enables the rich control plane functionality required for modern data center fabrics.
L2VPN EVPN address family supports multiple route types each serving specific purposes in overlay network operation. Route Type 2 advertises MAC and IP addresses, Route Type 3 handles multicast distribution, Route Type 4 supports Ethernet segment discovery, and Route Type 5 distributes IP prefix information. These route types provide comprehensive control plane coverage for Layer 2 and Layer 3 overlay services.
BGP configuration for EVPN requires enabling the L2VPN EVPN address family under BGP neighbors exchanging overlay control plane information. Configuration syntax includes address-family l2vpn evpn under BGP neighbor configuration activating EVPN route exchange. This explicit activation ensures only intended peers participate in overlay control plane.
The address family encodes EVPN routes using BGP path attributes and extended communities for route targets, route distinguishers, and EVPN-specific information. These attributes enable flexible route filtering, traffic engineering, and multi-tenancy support essential for large-scale data center deployments.
EVPN address family scales effectively using BGP route reflectors to reduce full mesh peering requirements. Route reflectors enable hierarchical designs where leaf switches peer with route reflectors rather than all other leaf switches. This architecture scales to hundreds or thousands of leaf switches supporting massive fabrics.
The standardization of L2VPN EVPN address family in RFC 7432 and related RFCs ensures multi-vendor interoperability. Different vendors’ VXLAN implementations using EVPN control plane can interoperate when following standards enabling heterogeneous data center fabrics.
IPv4 unicast address family is the traditional BGP address family for IPv4 routing but does not carry EVPN overlay information. While underlay routing between VTEPs might use IPv4 unicast address family, overlay MAC and IP reachability requires the specialized L2VPN EVPN address family.
VPNv4 address family supports MPLS Layer 3 VPNs carrying IPv4 routing information with VPN labels. While VPNv4 serves similar multi-tenant purposes in MPLS networks, VXLAN EVPN specifically requires L2VPN EVPN address family designed for Layer 2 and Layer 3 overlay services.
IPv6 unicast address family carries IPv6 routing information but does not support EVPN functionality. While networks might use IPv6 in the underlay or as end-user addressing, EVPN control plane requires the dedicated L2VPN EVPN address family regardless of underlying IP version.
Question 191:
An engineer is troubleshooting a VPC configuration where orphan ports are not working correctly. What is the purpose of the VPC peer-gateway feature?
A) Load balancing traffic across VPC peers
B) Allowing VPC peer to act as gateway for traffic destined to peer’s MAC
C) Providing Layer 3 routing between VPC peers
D) Creating redundant gateway paths for orphan devices
Answer: B
Explanation:
The VPC peer-gateway feature allows a VPC peer switch to act as the active gateway for traffic destined to its peer’s MAC address, improving forwarding efficiency in certain scenarios. Without peer-gateway, traffic arriving at one VPC peer switch but destined to the other peer’s router MAC address must traverse the peer-link even when better forwarding paths exist. Peer-gateway optimizes this behavior enabling local forwarding.
Specific scenarios where peer-gateway provides benefits include hosts that cache ARP responses and continue sending to the MAC address of the router that originally responded even when traffic arrives at the other VPC peer. Without peer-gateway, the receiving peer must forward this traffic across the peer-link to the peer owning that MAC address causing suboptimal traffic flow.
Peer-gateway enables both VPC peers to forward traffic regardless of which peer’s MAC address appears in the destination field. Each peer accepts and forwards traffic destined to either its own router MAC or its peer’s router MAC. This acceptance eliminates unnecessary peer-link traversal improving efficiency and reducing peer-link bandwidth consumption.
The feature is particularly important for certain load balancing scenarios and application behaviors that create asymmetric traffic patterns. Some load balancers or application designs send traffic to specific router MAC addresses rather than virtual MAC addresses. Peer-gateway ensures efficient forwarding regardless of these application characteristics.
Configuration requires enabling peer-gateway under the VPC domain configuration. The command vpc peer-gateway activates the feature for all router interfaces. This global setting applies across all VLANs and interfaces improving forwarding for any traffic that might arrive with the peer’s MAC address.
Peer-gateway should be enabled in most VPC deployments as best practice unless specific reasons dictate otherwise. The feature provides operational benefits with minimal downsides. Most modern VPC configurations include peer-gateway to ensure optimal traffic forwarding across all scenarios.
Load balancing traffic across VPC peers is achieved through VPC member port configurations and LACP not through peer-gateway. VPC inherently provides active-active forwarding where both peers forward traffic simultaneously. Peer-gateway optimizes specific forwarding scenarios rather than providing general load balancing.
Providing Layer 3 routing between VPC peers is not the purpose of peer-gateway. VPC peers route traffic independently based on their routing tables. Peer-gateway allows peers to accept traffic destined to each other’s MAC addresses but does not establish routing protocols or exchange routes between peers.
Creating redundant gateway paths for orphan devices is accomplished through configuring multiple default gateways or gateway redundancy protocols not peer-gateway. Orphan devices are single-homed to one VPC peer and rely on standard Layer 3 redundancy mechanisms. Peer-gateway optimizes forwarding not gateway redundancy.
Question 192:
A network administrator is configuring port channels on Nexus switches. What is the maximum number of active physical interfaces typically supported in a single port-channel?
A) 4
B) 8
C) 16
D) 32
Answer: B
Explanation:
The maximum number of active physical interfaces typically supported in a single port-channel on Cisco Nexus switches is 8 interfaces, though this may vary by platform and software version. Having 8 active members provides substantial aggregate bandwidth while maintaining manageable link-level complexity. Additional interfaces beyond 8 can be configured as standby members ready to activate if active members fail.
Port-channels aggregate multiple physical links into a single logical interface providing increased bandwidth and redundancy. When configured with 8 member interfaces each operating at 10 Gbps, the port-channel provides up to 80 Gbps aggregate bandwidth. This aggregation scales bandwidth beyond single interface limits without requiring expensive high-speed optics.
The 8-member limit represents the number of simultaneously active and forwarding interfaces. Some configurations allow additional interfaces in standby or hot-standby mode bringing total configured members above 8. Standby members activate automatically when active members fail providing additional resilience beyond the active member count.
Load balancing algorithms distribute traffic across port-channel members based on source and destination information from various protocol layers. Hash-based algorithms ensure that traffic for specific flows consistently uses the same member link maintaining packet ordering. The algorithms can incorporate MAC addresses, IP addresses, and port numbers creating flow distribution.
Different Nexus platforms may support different maximum member counts and capabilities. Administrators should verify platform-specific limits in documentation. Some newer platforms or enhanced feature sets may support more than 8 active members providing greater scale for specific use cases.
Port-channel member interfaces must have compatible configurations including matching speed, duplex, and sometimes MTU settings. Mismatched configurations prevent interfaces from joining the port-channel or cause inconsistent behavior. Configuration compatibility checks ensure operational stability.
While 4 active interfaces is below the typical maximum, some organizations may choose to configure fewer members based on bandwidth requirements and cost considerations. However, the platform capability typically allows up to 8 active members providing flexibility for various deployment scenarios.
While 16 interfaces might seem reasonable for high-bandwidth requirements, this exceeds the typical active member limit on most Nexus platforms. Some platforms support 16 interfaces in total including standby members but generally limit active members to 8 for manageability and load balancing effectiveness.
32 interfaces significantly exceeds port-channel capabilities on Nexus switches. This large member count would create load balancing challenges and is not supported by standard port-channel implementations. Organizations requiring bandwidth beyond 8-member port-channels should consider higher-speed interfaces or alternative designs.
Question 193:
An engineer is implementing QoS and needs to classify traffic based on Layer 3 information. Which field in the IP header is used for QoS classification?
A) TTL
B) DSCP
C) Protocol
D) Identification
Answer: B
Explanation:
The DSCP or Differentiated Services Code Point field in the IP header is specifically designed for QoS classification enabling devices to identify and prioritize traffic based on service requirements. DSCP occupies 6 bits in the IP Type of Service field providing 64 possible values for traffic categorization. This standardized classification mechanism enables consistent QoS treatment across multi-vendor networks.
DSCP values indicate the desired per-hop behavior for packets as they traverse network devices. Routers and switches examine DSCP values to determine queuing priority, drop precedence, and bandwidth allocation. Standardized DSCP values like EF for voice traffic and AF classes for differentiated application traffic enable predictable QoS behavior.
Common DSCP values include EF or Expedited Forwarding with value 46 used for low-latency traffic like voice, AF or Assured Forwarding classes providing different service levels with drop precedence, and CS or Class Selector values maintaining backward compatibility with IP Precedence. These standard values ensure interoperability across equipment from different vendors.
Network devices classify traffic into service classes based on DSCP values then apply appropriate policies including priority queuing for delay-sensitive traffic, guaranteed bandwidth for business-critical applications, and rate limiting for best-effort traffic. DSCP-based classification enables differentiated treatment without requiring deep packet inspection.
DSCP marking typically occurs at network edges where traffic enters the network either at access switches or on routers interfacing with end users. Edge marking followed by DSCP-based treatment throughout the network creates trust boundaries and ensures consistent QoS policies. Core devices trust and honor DSCP markings applied at edges.
Organizations define DSCP marking policies based on application requirements and business priorities. Voice and video applications receive high-priority DSCP values ensuring low latency and jitter while bulk file transfers receive lower priority. These policies align network behavior with business objectives.
TTL or Time To Live prevents routing loops by decrementing at each hop and discarding packets when reaching zero. While important for routing operation, TTL does not provide QoS classification information. TTL serves a completely different purpose unrelated to traffic prioritization.
The Protocol field identifies the upper-layer protocol carried in the IP payload such as TCP, UDP, or ICMP. While protocol information can be used as part of classification rules, the Protocol field itself is not designed for QoS classification. DSCP provides dedicated QoS marking avoiding protocol field overloading.
The Identification field supports IP fragmentation and reassembly by uniquely identifying fragments of original packets. This field serves fragmentation functionality and does not carry QoS information. DSCP in the Type of Service field provides standardized QoS classification.
Question 194:
A data center uses FCoE for storage networking. Which statement correctly describes FCoE operation?
A) FCoE completely replaces Fibre Channel protocol with Ethernet
B) FCoE encapsulates Fibre Channel frames in Ethernet frames
C) FCoE converts Fibre Channel to iSCSI for Ethernet transport
D) FCoE uses TCP/IP for reliable Fibre Channel delivery
Answer: B
Explanation:
FCoE or Fibre Channel over Ethernet encapsulates native Fibre Channel frames within Ethernet frames enabling FC storage traffic to traverse Ethernet infrastructure. The encapsulation preserves complete FC frames including headers and payloads while adding Ethernet headers for network transport. This approach maintains FC protocol characteristics while leveraging Ethernet’s widespread adoption and cost-effectiveness.
The encapsulation process wraps FC frames in Ethernet frames using a dedicated EtherType value 0x8906 identifying the payload as FCoE traffic. Network devices recognize this EtherType and apply appropriate handling including priority flow control and lossless forwarding required for storage traffic. The FC frame remains intact within the Ethernet encapsulation enabling transparent operation of FC protocols.
FCoE enables network convergence where storage and data traffic share the same physical Ethernet infrastructure reducing cabling, switch ports, and management complexity. Converged Enhanced Ethernet extensions including PFC, ETS, and DCB create lossless Ethernet suitable for FCoE operation. These enhancements transform standard Ethernet into a reliable transport for storage traffic.
FCoE maintains the complete FC protocol stack including FC-2 frame format, FC zoning, and FC flow control mechanisms. Upper-layer storage protocols like SCSI operate unchanged over FCoE experiencing the same characteristics as native FC SANs. Applications and storage arrays require no modifications to work over FCoE.
Converged Network Adapters in servers support both FCoE and standard Ethernet traffic on the same physical adapter and cables. CNAs reduce server adapter slots and simplify cabling while enabling full FCoE participation. The CNA presents separate FCoE and Ethernet interfaces to the operating system.
FCoE deployment requires FCoE-capable switches functioning as Fibre Channel Forwarders that bridge between FCoE and native FC networks. FCFs handle encapsulation, de-encapsulation, and translation between FCoE and FC domains enabling integration with existing SAN infrastructure.
FCoE does not completely replace Fibre Channel protocol but rather provides an alternative transport mechanism. The FC protocol itself including frame format, flow control, and upper-layer services remains unchanged. FCoE enables FC operation over Ethernet rather than replacing FC with something fundamentally different.
FCoE does not convert Fibre Channel to iSCSI. These are distinct storage protocols with different characteristics. iSCSI encapsulates SCSI commands in TCP/IP using standard IP networking while FCoE maintains native FC frames over specialized Ethernet. The protocols serve similar purposes but use completely different approaches.
FCoE does not use TCP/IP for transport. FCoE operates at Layer 2 using Ethernet frames directly without IP or TCP headers. The lossless nature of FCoE relies on Ethernet flow control and Data Center Bridging extensions rather than TCP’s reliability mechanisms. This fundamental difference distinguishes FCoE from IP-based storage protocols.
Question 195:
An administrator is configuring interface descriptions on a Nexus switch for documentation purposes. What is the maximum length of an interface description?
A) 40 characters
B) 80 characters
C) 120 characters
D) 254 characters
Answer: B
Explanation:
The maximum length of an interface description on Cisco Nexus switches is 80 characters providing sufficient space for meaningful documentation while maintaining manageable configuration file sizes. Interface descriptions serve critical documentation purposes identifying interface purpose, connection destinations, circuit IDs, and other relevant information. The 80-character limit encourages concise yet informative descriptions.
Interface descriptions appear in show interface output and configuration displays helping administrators quickly understand interface purposes without consulting external documentation. Well-written descriptions significantly improve troubleshooting efficiency by providing context about interface connections and usage directly in the switch interface.
Best practices recommend including specific information in descriptions such as remote device name, remote interface identifier, circuit or ticket numbers, and contact information. For example, a description like “Connection to DC2-CORE-01 Eth1/5 Circuit ATT-12345” provides comprehensive connection details within the character limit.
Descriptions should follow organizational naming conventions ensuring consistency across the network infrastructure. Standardized description formats enable automated parsing and documentation generation. Consistent descriptions also help network operations teams quickly understand configurations when troubleshooting or performing maintenance.
The description command under interface configuration mode accepts text strings up to 80 characters. Configuration syntax is description text where text contains the descriptive information. Descriptions containing spaces must be enclosed in quotes or entered as contiguous words depending on syntax requirements.
Interface descriptions persist in switch configuration and appear in configuration backups providing valuable documentation even when network management systems are unavailable. This built-in documentation capability ensures critical information remains accessible during outages or when dedicated documentation systems are inaccessible.
While 40 characters might suffice for basic descriptions, this length restriction would limit documentation detail. The 80-character limit provides better balance between information richness and configuration file manageability. Longer descriptions enable more comprehensive documentation improving operational efficiency.
120 characters exceeds the interface description limit on Nexus switches. While some network devices support longer descriptions, Nexus platforms enforce the 80-character maximum. Attempting to configure descriptions exceeding this limit results in truncation or command rejection depending on input method.
254 characters significantly exceeds Nexus interface description capabilities and would create unwieldy configuration files. Such long descriptions would impair readability in configuration displays and show command output. The 80-character limit represents optimal balance between documentation detail and practical usability.