Design q2-11

A futuristic office environment showcasing network switches, cables, and a virtual interface displaying network performance metrics

Network Performance Optimization Quiz

Test your knowledge on network optimization techniques and protocols with our interactive quiz! This quiz covers essential topics including RSTP deployment, EIGRP adjacency issues, and EtherChannel configurations.

Enhance your understanding of network design
Challenge your skills with real-world scenarios
Perfect for engineers preparing for certification

15 Questions4 MinutesCreated by OptimizingNetwork321

Refer to the new resource(s) available.

RSTP Deployment

From: Network Manager;
To: CCIE Candidate;
Subject: RSTP Deployment

Hi,
We’re very excited that you are with us on this journey we’re about to embark on. I know we haven’t even got to the official meet and greet yet, but I figured I might just take advantages of your expertise already.

Our junior engineer has been busy rolling out new switches around the HQ lately. However, it seems that STP settings have been left at their defaults on all switches. This has resulted in poor performance related to wherever a device was plugged in or removed from the network. Mangement is convinced that simply by enabling Rapid PVST+ everywhere the performance of the network will dramatically improve, but

I’m wondering if there are any additional settings that absolutely must be implemented so that, after enabling RPVST+, the user experience is truly improved.

Best regards.
Network Manager

Which action must be taken in addition to enabling Rapid PVST+ on all switches in the HQ to guarantee
that the user experience is improved?

Disable EtherChannel Misconfiguration Guard

Protect ports toward end hosts with BPDU Guard

Configure ports toward end hosts as edge ports

Protect port toward end hosts with BPDU Filter

Refer to the new resource(s) available.

RE: RSTP Deployment

From: Network Manager;
To: CCIE Candidate;
Subject: RE:RSTP Deployment

Hi,

Thanks for the response. We have revised our choices, had Rapid PVST+ enabled on HQ switches, configured ports toward end hosts with PortFast, enabled BDPU Guard on the same ports and even shortened the forward_delay_timer to 10 seconds.

Then our junior decided to test the improvement and so he configured a trunk port on sw110, connected a Linux based host there, configured it with subinterfaces for each VLAN and had a set of continuous pings running from the Linux toward both sw101 and sw102 in each VLAN while flapping the uplinks from sw110 to both distri switches. He still saw outages of around 20 seconds. What’s going on there? We are considering rolling back the changes unless we can explain and fix this
quickly.

Best regards
Network Manager

Based on the description of the issue, what is the most likely reason?

Rapid PVST+ requires the use of LACP fast rate to support rapid convergence on EtherChannels.

Trunk ports are not considered as edge ports unless explicitly configured to.

The MAC aging time needs to be set to a value shorter than max_age+forward_delay.

PortFast is not enabled globally on the switches.

Refer to the new resource(s) available.

EIGRP Adjacency Issues - Conversation

Anna	Network Manager
Network Manager, sorry to interrupt you while you’re on those improvement at HQ but I need your help with a trouble ticket that just came in from Branch #4. They say EIGRP adjacency between r70 and r24 over the DMVPN tunnel keeps going up and down. Syslog on r70 is just filled with all kinds of logs so not sure what to focus on first. One of the things I noticed is just an ongoing churn of %DUAL-5-MERCHANGE EIGRP IPv4 65006 logs saying logs saying the EIGRP neighbor with r24 is up and then seconds later it is back down again
	Do you know if anything changed at that branch or in those configs? isn’t that branch the location where they were looking at maybe doing BGP over the DMVPN tunnel instead of EIGRP? Are any other branches having issues with EIGRP neighboring to r24 over DMVPN?
No other branches are having issues at all I just went into r24 and this is the only EIGRP neighbor that is flapping And yes, you are right. Branch #4 is the branch where they were going to try to do BGP instead of EIGRP over the DMVPN but remember, we haven’t enabled r24 to do BGP over the DMVPN session with r70 anyway-I just checked it.
	Okay… let’s look at their configs and draw this all out. I am sure it is something in r70 I think remember us hitting something like this in our original deployment of the DMVPN. And let’s involve our CCIE-in-making to help us with this too!

Based on the diagram, what design change can be made to address the flapping EIGRP neighbor between r24 and r70 without impacting the network connectivity to any other DMVPN location?

On r70, enable EIGRP stub

On r21 and r70, put the WAN interfaces toward the SP into a front door VRF

On r70, only enable EIGRP on the r70 LAN interfaces and the DMVPN tunnel

On r70, do not advertise the 10.200.0.0/24 subnet in BGP

On r70, put the WAN interfaces toward the SP into a front door VRF

	LACP EtherChannel	Static EtherChannel
Provides the shortest link bundling time possible
Adds data plane overhead
Adds control plane overhead
Provides protection against miscabling
Allows automatic fallback to individual link operation
Provides the widest vendor and implementation interoperability
Supports Layer3 EtherChannels
Supports Layer2 EtherChannels
Provides protection against misconfiguration
Supports various load balancing modes

Design q2-11

Network Performance Optimization Quiz

More Quizzes