Infrastructure And Design practice questions

Force fragmentation by enabling ICMP unreachable messages.

Why it fails: Fragmentation significantly increases latency and packet loss probability.

Reduce the video resolution to 360p to keep packet sizes small.

Why it fails: This reduces quality unnecessarily rather than fixing the network transport.

Disable QoS to allow larger packets to traverse the path.

Why it fails: Disabling QoS will likely cause drops due to buffer starvation.

Cisco Tomcat Service

Why it fails: Tomcat handles web traffic, not cluster failover mechanisms.

Cisco Database Layer Monitor

Why it fails: While involved in replication, it is not the primary high availability management service.

Cisco Unity Connection Message Transfer Agent

Why it fails: This handles email/voicemail message delivery, not cluster state.

Disable SIP OPTIONS keepalives on all trunk configurations.

Why it fails: Disabling keepalives makes it impossible to track the status of the remote end.

Set the DSCP value to EF for all SIP signaling traffic.

Why it fails: DSCP marks the traffic, but does not prevent transmission of unnecessary signaling packets.

Enable SIP REFER method support on all inter-cluster trunks.

Why it fails: REFER is used for call transfers, not for optimizing signaling traffic across high-latency links.

5061

Why it fails: 5061 is for SIP TLS signaling.

8080

Why it fails: 8080 is often used for web management.

443

Why it fails: 443 is for HTTPS traffic.

Keepalive Interval

Why it fails: This is for SCCP/SIP keepalives, not TFTP loading.

Max Phone Registrations

Why it fails: This is not a configurable parameter for TFTP performance.

Registration Timeout

Why it fails: This affects registration behavior, not TFTP file distribution.

Cisco Unity Connection

Why it fails: Unity Connection manages voicemail, not Jabber config.

IM and Presence Service

Why it fails: IM&P manages status and messaging, not phone configuration.

TFTP Server

Why it fails: MRA does not use standard TFTP for configuration delivery; it uses HTTP/HTTPS.

Use an ACL to match PC MAC addresses.

Why it fails: ACLs are for security, not for traffic separation/VLAN tagging.

Enable Auto-QoS on the switch port.

Why it fails: Auto-QoS is a helper tool, but defining the voice VLAN is the foundational requirement.

Assign a static IP to the PC.

Why it fails: This has no impact on voice traffic prioritization.

_cisco-uds._tcp

Why it fails: _cisco-uds._tcp is queried internally by endpoints to find Cisco Unified Communications Manager service, not the external Expressway-E used for MRA. It tempts because it is a genuine UDS discovery record, but it applies to on-premises registration rather than mobile and remote access edge traversal.

_sip._tls

Why it fails: _sip._tls locates a SIP registrar or proxy for standard SIP registration, whereas MRA discovery requires the _collab-edge._tls SRV record pointing at Expressway-E. It tempts because SIP over TLS is the actual signalling protocol used, but the discovery step precedes and differs from the signalling lookup.

_tftp._udp

Why it fails: _tftp._udp is the SRV record used for phone configuration file retrieval, not for locating an MRA traversal server. The client queries _collab-edge._tls to discover Expressway-E. It tempts because TFTP provisioning is genuinely part of phone boot-up, but that lookup happens after registration discovery, not for it.

Media Proxy

Why it fails: Media proxy handles RTP, not SIP header privacy.

Call Admission Control (CAC)

Why it fails: CAC manages bandwidth, not SIP privacy.

Registration Proxy

Why it fails: This is for handling device registrations, not hiding topology.

Quality of Service (QoS)

Why it fails: QoS classifies, marks and queues traffic to protect voice quality, but it admits every call regardless of remaining bandwidth, so over-subscription still occurs. It is tempting because QoS is deployed on constrained WAN links, and would be correct when prioritising voice packets rather than limiting concurrent call counts.

Resource Reservation Protocol (RSVP)

Why it fails: RSVP reserves bandwidth per flow at each router, but Unified Communications Manager's CAC uses locations and regions rather than RSVP signalling. It is tempting because RSVP is a genuine reservation protocol, and would be correct in an MPLS or IP network where routers themselves honour RSVP reservations.

Gatekeeper-based CAC

Why it fails: Gatekeeper-based CAC is a legacy H.323 construct; Cisco Unified Communications Manager uses locations-based CAC to limit calls across WAN links. It is tempting because gatekeepers performed admission control in H.323 environments, and would be correct when the deployment still relies on H.323 gatekeepers rather than Unified CM.

SIP INFO

Why it fails: SIP INFO is for signaling, not media streaming.

HTTPS

Why it fails: HTTPS is not used for streaming real-time audio.

Unicast RTSP

Why it fails: Unicast consumes a unique stream for every single user, scaling poorly.

_https._udp

Why it fails: HTTPS does not use UDP.

_ftp._tcp

Why it fails: FTP is not used for MRA.

Incorrect IP address in host file

Why it fails: Host file changes are not a cause; DNS mismatches might be, but host files are usually static.

High CPU utilization on the publisher

Why it fails: High CPU slows down performance, but doesn't cause replication states to fail.

Missing TFTP files

Why it fails: TFTP issues are independent of database replication.

Random Early Detection (RED)

Why it fails: Congestion avoidance, not priority management.

Weighted Fair Queuing (WFQ)

Why it fails: Not sufficient for strict voice priority.

Traffic Shaping

Why it fails: Used for bandwidth limiting, not latency reduction.

802.1X Authentication

Why it fails: Used for network access control, not DHCP forwarding.

Port Security

Why it fails: Limits MAC addresses, doesn't handle DHCP forwarding.

DHCP Snooping

Why it fails: Snooping is a security feature to prevent rogue servers, not for forwarding.

16

Why it fails: 16 exceeds the supported cluster limit for a single publisher.

4

Why it fails: This is a low number; the limit is higher.

32

Why it fails: Exceeds the limit.

Route all calls to a central office.

Why it fails: This risks sending the wrong address to the PSAP.

Use the caller's IP address.

Why it fails: IP addresses do not provide actionable location info to PSAPs.

Disable emergency routing.

Why it fails: This is illegal and dangerous.

Configure the phones to use the publisher as the primary TFTP server and a subscriber as the secondary.

Why it fails: TFTP server configuration affects how phones download configuration files, not which CUCM server they register to for call processing. While TFTP redundancy is important, it does not provide call-processing failover. The phones would still attempt to register to the same CUCM server based on their Device Pool and CUCM Group settings.

Create a new Region and assign it to the Device Pool.

Why it fails: Regions are used to define codec selection between groups of devices, not for call-processing redundancy. Assigning a Region to a Device Pool affects the codecs used for calls between devices in different regions, but it does not provide a mechanism for phones to register to an alternate CUCM server if their primary fails.

Enable Cisco Unified Communications Manager Assistant (CUMA) on the subscribers.

Why it fails: CUMA is a feature that provides manager-assistant call handling, not call-processing redundancy. It allows assistants to manage calls for managers, but it does not influence which CUCM server a phone registers to. Enabling CUMA would not help phones re-register to another subscriber if their primary fails.

Deploy a single CUCM server with Cisco Unified Survivable Remote Site Telephony (SRST) at each building to provide redundancy.

Why it fails: SRST provides call processing redundancy only for remote branch offices when they lose WAN connectivity to the central CUCM. It does not protect against a CUCM server failure for on-campus users. A single CUCM server remains a single point of failure, and SRST does not provide administrative access or full feature support during an outage.

Deploy two CUCM publishers in the same cluster for database redundancy and load balancing.

Why it fails: A CUCM cluster supports only one publisher. Multiple publishers in the same cluster are not supported and would cause database replication conflicts. High availability is achieved through multiple subscribers, not multiple publishers. This option is technically invalid and would not meet the customer's requirement for a resilient design.

Deploy a single CUCM subscriber and use the publisher only for database replication.

Why it fails: A single subscriber creates a single point of failure for call processing. If that subscriber fails, all users lose telephony service. The publisher is not designed to handle call processing in a production environment and using it only for database replication does not provide the required redundancy or administrative capability during an outage.

Deploy a Cisco Unified Communications Manager Express (Unified CME) router at each branch for SRST fallback.

Why it fails: Unified CME is a full call-control platform, not a survivability service. Deploying it at each branch would create a second call-processing domain, require separate dial plans and licensing, and contradict the centralized design goal. SRST is the correct CUCM survivability mechanism for branch offices; Unified CME is intended for small standalone sites, not as a fallback for a centralized cluster.

Configure each branch phone with a secondary TFTP server located at the branch office.

Why it fails: A secondary TFTP server only helps with configuration file downloads; it does not provide call processing or dial tone. If the WAN fails, the phones still cannot register to CUCM, and no internal calls can be made. TFTP redundancy addresses file retrieval, not call-control survivability, so it does not satisfy the requirement.

Deploy a CUCM subscriber node at each branch office and add it to the same cluster.

Why it fails: Placing CUCM subscriber nodes at branches increases hardware footprint, licensing, and management overhead, and it changes the deployment from centralized to distributed. The scenario explicitly requires keeping call control in the data center. A local CUCM node would also require database replication over the WAN, which is not recommended for latency-sensitive clusters.