Huawei H35-211_V2.5 HCIP-Access V2.5 Exam Practice Test

In Huawei IPTV troubleshooting, mosaic/flash/jerky or intermittent picture typically results from packet loss or bit errors. Common causes include: optical power near the receiver sensitivity threshold causing FEC/BER spikes (A); loss of I-frames (key frames) either in the encoder/compression stage (B) or due to line transmission loss/jitter (D); and device rate-limit (CAR/policing) misconfiguration that drops packets under burst traffic (C). Any of these can yield unstable display.

Drag & Drop Answer (NGN layers → devices):

Network control layer → Softswitch

Service management layer → OSS system

Edge access layer → MA5800

Core switching layer → Core router

Why:

Softswitch handles call/session control ⇒ control layer.

OSS provides O&M/service management ⇒ service management layer.

MA5800 is an OLT/access device ⇒ edge access layer.

Core router provides backbone forwarding ⇒ core switching layer.

A persistently high CPU on the OLT main control board is typically driven by excessive control-plane load or abnormal traffic patterns. Common causes include:

Illegal login attempts generating authentication and logging overhead (A)

Layer-2 loops leading to storms and protocol churn (B)

DoS/scan/attack traffic stressing control/management processing (C)

Rogue/misbehaving ONUs causing frequent state changes, registration flaps, or abnormal report traffic (D)

All listed factors are recognized contributors to elevated CPU on access OLTs.

In eSight’s ONT Zero-Touch workflow, multi-service profiles define service parameters delivered to ONTs—primarily service VLANs such as Internet/Data VLAN, Voice VLAN, and IPTV/Multicast VLAN with related QoS. Hardware attributes like ONU type or Ethernet port count are part of the device/ONT profile, not the multi-service profile. A generic “Default VLAN” parameter is not used here; instead, explicit service VLANs are specified (for example, data VLAN and voice VLAN).

In 10G-EPON (IEEE 802.3av), the wavelength plan uses 1577 nm downstream and 1270 nm upstream. The 1270 nm upstream is used in both asymmetric and symmetric 10G-EPON profiles.

A is consistent with Huawei L2 multicast practice: global L2 multicast/IGMP snooping parameters can be set and then take effect for multicast VLANs involved in service provisioning.

B reflects the forwarding/CPU-punt behavior on access line cards: IGMP Reports/Leaves from users are recognized by board logic and processed by the control plane to update multicast state.

C matches default service control on BTV/IPTV access where a default program limit (commonly 8) per user applies unless adjusted by policy/profile.

D is incorrect: when IGMP match mode is disabled, multicast programs are not required to be pre-provisioned as channels; groups can be learned dynamically by IGMP. Preconfiguring channels is needed when match mode is enabled (channel matching enforced).

IGMP Snooping is a Layer-2 function that listens to IGMP control packets between hosts and the multicast querier. Upon receiving a host’s Membership Report (Join) for group G, the switch learns that the ingress port is a member port for G and adds that port to the group’s forwarding entry, so multicast traffic for G is forwarded only to those learned member ports (saving bandwidth and avoiding flooding). Huawei’s official documentation describes IGMP Snooping exactly in this way.

In Huawei’s 10G GPON (Gigabit-capable Passive Optical Network) system, different optical wavelengths are used for upstream and downstream transmission to ensure bidirectional communication over a single fiber.

According to the ITU-T G.987.x series and Huawei’s Access Network Technical Documentation, the wavelength plan for 10G GPON (XG-PON) is as follows:

Downstream (OLT → ONU): 1577 nm

Upstream (ONU → OLT): 1270 nm

This separation of wavelengths allows both transmission directions to occur simultaneously using WDM (Wavelength Division Multiplexing) on the same optical fiber, minimizing interference.

Huawei OLTs such as the MA5800 and EA5800 series follow this standard exactly — supporting 10G GPON (XG-PON) with downstream at 1577 nm and upstream at 1270 nm.

Hence, the correct answer is 1577 nm.

Answer: B

References (Aligned with HCIP-Access V2.5 and Huawei Technical Sources):

HCIP-Access V2.5 Study Guide – “Huawei Campus Network Overview” Chapter, Section: PON Technology Overview

Huawei 10G GPON (XG-PON) Technical White Paper

ITU-T G.987.2: 10-Gigabit-capable Passive Optical Networks (XG-PON): Physical Media Dependent (PMD) Layer Specification

Huawei MA5800 Product Description – 10G GPON Port Wavelength Specifications

The MG reports availability and restarts to the MGC using H.248 ServiceChange with Method=Restart. The Reason code distinguishes the type of restart. In Huawei implementations aligned with H.248 semantics, Reason=[901] corresponds to a warm/warmboard restart scenario rather than a full cold start.

Board restart triggers a warm restart of the voice board/MG, producing ServiceChange { Method=Restart, Reason=901 }.

Reset coldstart performs a cold start, which would use a different reason code (cold start), not 901.

Reboot system generally implies a broader device reboot similar to cold start semantics, not 901.

ONT re-register affects ONU registration and does not cause the MG to announce a ServiceChange restart to the MGC.

Huawei anti-DoS on access boards performs periodic detection. Ports with consecutive detections of abnormal traffic are placed into a blacklist/quarantine state. The system then applies a random back-off interval before re-detecting; if no further anomalies are found, the port can be automatically removed from the blacklist.

XG-PON encapsulates user data into XGEM frames. The XGEM Port-ID field is 12 bits, allowing identification of logical connections (GEM ports) per ONU. This mirrors the 12-bit Port-ID used in GPON GEM.

When the number of access users approaches or exceeds the single-layer VLAN space and services must be distinguished per user, Huawei recommends hierarchical VLAN (QinQ) on the uplink: map a customer VLAN (C-VLAN) at the access side and add a service/provider VLAN (S-VLAN) toward the aggregation/core, i.e., C → S+C. This expands scalability beyond the ~4K single-VLAN limit while enabling precise user/service binding for large FTTH deployments (e.g., ~5K users under one OLT).

For IPv4 multicast, the MAC mapping uses 01-00-5E followed by the low-order 23 bits of the multicast IP address. Because an IPv4 multicast address has 28 variable bits (224/4), 5 bits are not mapped to the MAC. Therefore, 2⁵ = 32 distinct multicast IP addresses can map to the same multicast MAC address.

This is wrong. A PON port LED not green may indicate several states—not only a hardware fault. It can mean the port is administratively shutdown, no ONUs are registered, or the port is in an alarm or idle state depending on the LED color and blinking pattern. Fault requires correlation with alarms and performance counters in U2000, not LED color alone.

For ONT zero-touch on eSight/iMaster NCE-Campus, the prerequisite is that the OLT is onboarded and provisioned (communication parameters, northbound credentials, templates) so that discovered ONTs can inherit policies and be auto-activated. During incremental OLT configuration, eSight does push/update the OLT’s configuration (templates, profiles, authentication rules). Saying “do not provision OLT” is therefore false.

Type C dual-homing provides device-level protection with two OLTs; when one OLT/uplink fails, services switch to the peer OLT. In single-homing, ONUs are associated with only one OLT; therefore an OLT failure interrupts services (C). Single-homing has simpler networking and management than dual-homing (D). It does not offer switchover to another OLT (so B is incorrect), and the “important-service” positioning in A is typically applied to dual-homing scenarios that require the highest availability.

OLT-level (device-level) protection is achieved by dual-homing ONUs to two independent OLT interfaces so that services can switch to another OLT when one fails. In Huawei protection taxonomy, the dual-homing scheme (as contrasted with single-homing) provides device-side redundancy for the OLT. By comparison, Ethernet port protection groups and LACP protect uplink links and bandwidth at Layer 2, not the OLT device itself; single-homing does not protect against OLT failure.

PITP (Port Identification Transparent Transmission) is used on access networks to carry a user’s physical access-location to the upper AAA/BRAS. It has two working forms: P-mode (PPPoE+)—injecting location identifiers into PPPoE discovery—and V-mode (Vendor-tag)—carrying vendor/location tags transparently upstream. The purpose is to let the upper server associate user credentials with access location and, by policy, restrict roaming. Options A, B, D, and E correctly describe these behaviors/terms. Option C is inaccurate as written: PITP itself does not “bind the authentication” or inherently “avoid theft/roaming”; it only delivers location info. Preventing credential theft/roaming is achieved by AAA/BRAS policy that uses the PITP-carried location, not by PITP alone.

Huawei Anti-MAC-Spoofing binds the source MAC to the service flow/port to prevent address forgery. It is functionally exclusive with certain per-VLAN MAC check features (e.g., WMAC, SC, PPPoe-SMAC) to avoid conflicting validation logic. For IPoE users with fixed IP, operators typically configure static bindings/entries so that address and access policies remain consistent.

Option D is wrong: disabling Anti-MAC-Spoofing and removing fixed entries can affect service behavior; if forwarding is interrupted, that does impact user service—so the statement is self-contradictory and incorrect.

This statement is wrong. In U2000, network elements (NEs) can be added by multiple methods, including batch addition/import and automatic discovery, not just one-by-one during a live access session. U2000 supports template-based onboarding and batch operations to improve efficiency for large-scale deployments.

Huawei’s E2E pre-connection ODN (pre-connectorized ODN) adopts factory-pre-terminated cables, closures and splitter modules. Features highlighted in HCIP-Access V2.5 include: splicing-free quick installation (raising build efficiency and reducing skill/tool dependence), compact pre-connected splitter boxes, distributed splitting that shortens drop lengths and reduces ducts/cables, and easy O&M because modules are plug-and-play with no field splicing.

In Huawei’s 10G GPON (XG-PON) system, the split ratio defines how many Optical Network Units (ONUs) can be connected to a single Optical Line Terminal (OLT) port through passive optical splitters.

According to ITU-T G.987.x standards and Huawei’s 10G GPON technical specifications, the maximum theoretical optical split ratio for 10G GPON is 1:128.

This means that a single OLT PON port can serve up to 128 ONUs through the passive optical distribution network (ODN).

While the physical capability supports 1:128, practical deployments often use lower ratios (e.g., 1:64) to maintain optical power budgets and ensure stable service quality, especially over longer fiber distances or when optical losses are high.

Huawei’s MA5800/EA5800 series OLTs, which support 10G GPON, comply fully with this standard, enabling 1:128 maximum splitting with appropriate ODN design.

Therefore, the correct answer is C. 1:128.

References (Aligned with HCIP-Access V2.5 and Huawei Technical Documentation):

HCIP-Access V2.5 Study Guide – “Huawei Campus Network Overview” Chapter, Section: GPON and 10G GPON Overview

Huawei 10G GPON (XG-PON) Technical White Paper

ITU-T G.987.1: 10-Gigabit-capable Passive Optical Networks (XG-PON) – General Characteristics

Huawei MA5800/EA5800 Product Description – Optical Port Split Ratio Specifications

IEEE 802.3av (10G-EPON) explicitly enables coexistence of 1G-EPON and 10G-EPON on the same outside plant (ODN) by separating downstream wavelengths (1G ~1480–1500 nm vs 10G ~1575–1580 nm) and using dual-rate TDMA in the upstream (10G uses 1260–1280 nm within the broader 1G band). This wavelength plan and OLT capabilities allow operators to reuse existing ODN and achieve a smooth upgrade via WDM overlays at the OLT. Industry and standards materials emphasize this approach for incremental migration.

With PITP enabled and Vendor-tag switching allowed, Huawei OLTs support transparent transmission and augmentation: the OLT keeps the user-carried Vendor tag and appends the local Vendor tag (e.g., slot/port/location), ensuring the upstream AAA/BRAS receives both the access-side identity and the OLT’s own location identity. Simply adding only the local tag (A) loses user-side info; forwarding unchanged (B) omits OLT location; discarding (D) contradicts the feature intent.

XG-PON (10G GPON) adopts XGEM framing. Compared with GPON’s 12-bit GEM Port-ID, XGEM expands the Port-ID field to 16 bits, increasing the number of logical data flows that can be identified per ONU/OLT and improving service granularity. Hence the correct length is 16 bits.

Huawei QoS describes PQ (Priority Queuing) as the strict-priority scheduler ensuring that high-priority queues are served first before lower-priority queues. WRR/DRR/RR are weighted or round-robin modes intended for fair sharing and do not guarantee strict preemption for latency-sensitive traffic. Therefore, PQ is selected for higher-priority services (e.g., voice, control).

A mismatch between the service-profile’s user-port configuration and the ONT’s actual port capacity does not disable all services. Ports beyond the ONT’s capability remain inactive/unused, while valid ports with correct service bindings continue to work. Service availability depends on the consistency of applied profiles and actual hardware resources, not on a complete shutdown.

SNMPv2c uses a community-string model (clear-text “read”/“write” strings) and provides no authentication integrity or encryption. Only SNMPv3 adds auth/privacy (AuthNoPriv/AuthPriv) with hashing and encryption. Therefore, stating that SNMPv2c can encrypt user passwords is false.

Huawei multicast guidance stresses IGMP version compatibility: devices running an earlier version must interoperate only with hosts using the same or earlier version, otherwise v3 messages may not be processed. In Huawei’s multicast feature guidance for access devices (OLT side vs. user side), the behavior documented is that when the device is operating in IGMPv2, IGMPv3 Report messages from terminals are not processed—interoperation is restored only after the terminal/device side is downgraded to v2 (often driven by periodic queries that induce hosts to respond in v2). This maps operationally to dropping unsolicited IGMPv3 Reports when the OLT is fixed to v2. Huawei also recommends ensuring the device runs an IGMP version the same as or later than member hosts to avoid such loss. Therefore, with OLT fixed at v2, an incoming v3 Join is discarded.

In Huawei access network devices (such as MA5800, EA5800, and SmartAX series), the DHCP Option 82 (Relay Agent Information Option) feature is used to identify the source location of DHCP requests coming from users connected to access ports.

This helps the DHCP server assign IP addresses based on access topology information, such as slot, port, and VLAN IDs.

When Option 82 is enabled globally and within the VLAN service profile, and the port/service-port is configured to allow user-side packets to carry Option 82, the device processes incoming DHCP requests as follows:

If a user-side DHCP packet does not contain Option 82:→ The device automatically adds local Option 82 information (e.g., circuit ID, remote ID) before forwarding it to the DHCP server.

If a user-side DHCP packet already contains Option 82:→ The device removes (strips) the existing Option 82 field to prevent spoofing or inconsistent location data.→ Then it adds its own local Option 82 information (accurate relay agent data based on the device’s configuration).→ The modified packet is then forwarded to the DHCP server.

This ensures that only trusted network-side Option 82 data is passed along, maintaining accurate user-location binding for IP address management and security.

Therefore, the correct behavior is:

The access device strips the Option 82 field from the user packet and adds its own local Option 82 information.

References (Aligned with HCIP-Access V2.5 and Huawei Technical Documents):

HCIP-Access V2.5 Study Guide – “Huawei Campus Network Overview” Chapter, Section: DHCP Relay and Option 82 Mechanism

Huawei MA5800/EA5800 Configuration Guide – IP Service → DHCP Relay and Option 82 Configuration

Huawei Enterprise Networking Product Documentation: “Understanding DHCP Option 82 Processing”

Huawei Access Network Feature Guide, Section: Processing Policies of DHCP Packets with Option 82

With IGMP Snooping/Proxy on access devices (such as Huawei OLTs), multiple receiver joins for the same (VLAN, Group) are aggregated. The OLT maintains a per-group member table and typically forwards a single upstream IGMP Join toward the multicast router (or querier) for that group, regardless of how many downstream users in that VLAN have joined. Additional local joins add downstream interfaces to the OLT’s table but do not trigger extra upstream joins per user. Hence, stating that two same-program viewers cause “two join messages” upstream is wrong.

Huawei GPON design recommends at most two splitting stages and a total split ratio within the optical power budget (commonly up to 1:64 for standard budgets).

A: 1:2 × 1:16 = 1:32 (valid).

C: 1:8 × 1:8 = 1:64 (valid under standard budgets).

D: 1:2 × 1:8 = 1:16 (valid).

B: 1:16 × 1:16 = 1:256, which exceeds typical GPON budgets and recommended engineering practice. Hence B is the incorrect networking.

Huawei OLTs support trust/remark mechanisms that can inherit (copy) user packet priorities (for example, trusting incoming 802.1p or DSCP to drive forwarding queues) and also support locally configured priorities (policy-based remarking/mapping on the OLT) to enforce service differentiation. Thus, both priority inheritance and local priority configuration are supported, making the statement Right.

In IP address discovery mode, eSight does not require L2 same-subnet adjacency; it only requires IP reachability/routing, proper SNMP credentials/alignment, and the operator’s Resource Access permission to poll and add devices. The “same network segment” prerequisite applies to ARP broadcast discovery mode, not to IP address discovery.