Huawei Certified ICT Professional - Datacom Advanced Routing & Switching Technology — Free Practice Questions
10 free sample questions from a bank of 241, with the correct answers and explanations. No signup required — start practising right now.
- TRUE
- FALSE
The short version
B — The ABR does not translate every Type 7 LSA. Only NSSA external routes whose P-bit is set are converted into Type 5 LSAs, so the word “all” makes the statement false.
Key concepts in this question
- NSSA: an OSPF area that allows local external routes as Type 7 LSAs instead of Type 5.
- Type 7 LSA: carries NSSA external prefixes and stays inside the NSSA unless translated.
- P-bit: the propagate flag in the Type 7 LSA header that requests translation by the ABR.
- NSSA ABR translation: converts P-bit-set Type 7 LSAs into Type 5 LSAs for the rest of the OSPF domain.
Why B is correct
An NSSA ABR translates a Type 7 LSA into a Type 5 LSA only when the P-bit is set. Routes originated with P-bit 0 are deliberately kept inside the NSSA, for example to filter which redistributed prefixes leak out. Because at least one class of Type 7 LSA is never converted, the claim that the ABR converts “all” Type 7 LSAs is false, and FALSE is the correct verdict.
Why the others are wrong
- A. TRUE ignores the P-bit rule and the filtering use case, so it overstates ABR behavior and contradicts the NSSA translation mechanism.
H12-831 exam tip
Memory hook: P stands for Propagate — no P-bit, no Type 5. Any option saying “all Type 7 become Type 5” is a trap.
- IPSG can prevent IP address spoofing attacks
- IPSG is a source IP address filtering technology based on the three-layer interface
- IPSG can turn on the IP packet inspection and alarm function, and cooperate with the network management to perform alarms
- IPSG can prevent the host from changing the IP address privately
The short version
B — IPSG is not a Layer 3 interface technology. It is a Layer 2 access-interface filter built on the DHCP snooping binding table, so statement B is the incorrect one.
Key concepts in this question
- IPSG (IP Source Guard): filters received packets against source IP or IP-plus-MAC bindings.
- Binding table: built mainly from DHCP snooping entries, plus static bindings.
- Layer 2 interface: IPSG is applied on access interfaces to check hosts, not on routed Layer 3 interfaces.
- Spoofing defense: drops packets whose source address does not match the port binding.
Why B is correct
The question asks for the incorrect statement. IPSG works on Layer 2 interfaces: it inspects the source IP (and optionally MAC) of incoming frames against the binding table for that port. Calling it a source-IP filter “based on the three-layer interface” misplaces the technology, so B is factually wrong and is therefore the intended answer.
Why the others are wrong
- A. Correct behavior: mismatched source IPs are dropped, which does prevent IP spoofing attacks.
- C. Correct behavior: IPSG supports packet check statistics with alarm reporting to the NMS.
- D. Correct behavior: a host that statically changes its IP fails the binding check, so private changes are blocked.
H12-831 exam tip
Memory hook: IPSG guards the switchport, not the routed interface — see “Layer 3” in an IPSG option and suspect it immediately.
- Route B
- Route C
- Route A
The short version
C — Route A wins on the shortest AS_PATH. BGP compares AS_PATH length before MED and IGP cost, and only Route A traverses a single AS.
Key concepts in this question
- AS_PATH length: the first decisive tiebreaker here; shorter is always preferred.
- MED comparison: only matters between paths from the same neighboring AS.
- IGP cost tiebreaker: considered only after AS_PATH, origin, and MED fail to decide.
- Arrival order: irrelevant; best-path is recomputed from attributes, not sequence.
Why C is correct
All three routes cover 10.1.1.0/24 with reachable next hops. Route A lists AS_PATH “3” (one AS hop) while Routes B and C list “1 2” (two AS hops), so Route A is strictly shorter and wins at the AS_PATH step. The lower MED of Route A (0) is consistent but never needs to be consulted, and the higher IGP cost of Route A (12) is evaluated far too late to matter. Option C names Route A, so it is correct.
Why the others are wrong
- A. Route B loses on the longer AS_PATH, and its MED of 150 is the worst anyway.
- B. Route C also loses on the longer AS_PATH; its better IGP cost (13 vs 11 is actually worse) cannot override AS_PATH length.
H12-831 exam tip
Memory hook: AS_PATH beats MED beats IGP cost — decide at the earliest step and stop reading the table.
- 10
- 20
- 0
- 15
The short version
B — Client2 ends up with 20 paths. Each of the two RRs reflects all 10 routes to Client2, so the client sees every prefix twice.
Key concepts in this question
- Route reflector: re-advertises IBGP routes to clients without a full mesh.
- Dual-client design: Client1 and Client2 peer with both RR1 and RR2.
- Same Cluster-ID: makes each RR discard the sibling reflection, avoiding an RR-level loop.
- BGP table counting: each received path is an entry, so duplicates from two RRs add up.
Why B is correct
R1 injects 10 EBGP routes into Client1, which advertises them to both RR1 and RR2 over IBGP. Each RR reflects the 10 routes to its clients, including Client2. The shared Cluster-ID stops RR1 and RR2 from re-reflecting each other’s copies, but it does not stop either RR from serving Client2. Client2 therefore receives 10 paths via RR1 plus 10 via RR2, giving 20 BGP table entries.
Why the others are wrong
- A. Counts only one copy per prefix and misses the second RR’s reflection.
- C. Would require Client2 to receive nothing, which contradicts correct IBGP reflection to clients.
- D. 15 has no basis: reflections arrive in complete sets of 10, so the total must be a multiple of 10.
H12-831 exam tip
Memory hook: same cluster stops RR-to-RR echo, not RR-to-client delivery — count one full set of routes per RR.
- hop-count must be greater than 2
- hop-count must be greater than 15
- hop-count must be greater than 1
- hop-count must be greater than 255
The short version
C — The hop count must exceed 1. EBGP defaults to TTL 1, and sourcing from a Loopback adds a hop even on a direct link, so at least 2 is required.
Key concepts in this question
- EBGP TTL: directly connected EBGP peers use TTL 1 by default.
- Loopback peering: the packet travels Loopback-to-interface, consuming an extra TTL hop.
- ebgp-max-hop: the VRP knob raising permitted EBGP TTL for non-direct peering.
- Direct link fallacy: a physical direct connection does not keep TTL at 1 once Loopbacks are used.
Why C is correct
With directly connected physical interfaces, TTL 1 suffices. Moving the session to Loopbacks inserts an additional hop (Loopback to outgoing interface) on each side, so TTL 1 packets expire and the session never establishes. Configuring peer ebgp-max-hop with any value greater than 1 (practically 2 or more) fixes this, which is exactly what option C states.
Why the others are wrong
- A. Greater than 2 works but is stricter than necessary; the minimum threshold is simply above 1.
- B. Greater than 15 is excessive for a direct link and confuses this case with long multihop paths.
- D. Greater than 255 is impossible, since TTL is an 8-bit field capped at 255.
H12-831 exam tip
Memory hook: Loopback EBGP means TTL 2 minimum — “directly connected” stops mattering once Loopbacks enter.
- The system ID of R1 is ee8c.a0c2.bafl
- R1 has both leve1-1 and level-1-2 link state information
- R1 only has link state information for leve1-2
- In the leve1-2 network, there are a total of 8 routers
The short version
A — R1 system ID is ee8c.a0c2.bafl. The reconstructed display reads that NET value.
Key concepts in this question
- System ID: 6-byte NET portion identifying the IS-IS router.
- Display output: system ID plus level database entries.
- Reconstructed value: ee8c.a0c2.bafl on R1.
Why A is correct
The reconstructed IS-IS exhibit lists R1 with system ID ee8c.a0c2.bafl, so A quotes the output exactly.
Why the others are wrong
- B. The reconstruction shows only Level-1-2 entries, not both separate Level-1 and Level-1-2 databases.
- C. R1 holds the combined Level-1-2 database phrasing, not a Level-1-2-only restriction as worded.
- D. The Level-1-2 router count in the reconstruction is not 8.
H12-831 exam tip
Copy the system ID dotted hex verbatim; counts need the figure.
- 2
- 1
- 4
- 3
The short version
B — A single ACL rule is enough. One wildcard mask selects exactly the odd third octets 1, 3, 5, and 7 while skipping the even ones.
Key concepts in this question
- Wildcard mask: a 0 bit must match, a 1 bit is “don’t care.”
- Odd-octet pattern: 1, 3, 5, 7 share binary 00000x0x with the low bit set.
- Aggregation: one rule with mask 0.0.6.0 covers all four prefixes.
- Exclusion check: the same mask must not accidentally match 2, 4, or 6.
Why B is correct
The targets are 10.0.1.0/24, 10.0.3.0/24, 10.0.5.0/24, and 10.0.7.0/24. The rule 10.0.1.0 0.0.6.0 fixes the base 00000001 and wildcards bits 1 and 2 (value 6 = 00000110), matching 01, 11, 101, 111 — exactly 1, 3, 5, 7. Prefixes 2, 4, 6 have the low bit clear and are excluded. Hence one rule suffices, and option B is correct.
Why the others are wrong
- A. Two rules can work but are not minimal, since the single 0.0.6.0 mask already covers everything.
- C. Four rules (one per route) waste configuration and ignore wildcard aggregation.
- D. Three rules likewise miss that the odd-octet set collapses into one mask.
H12-831 exam tip
Memory hook: odd third octets 1/3/5/7 collapse to base 1 with wildcard 6 — write it in binary to verify.
- 6661
- 3
- 6662
- 8888
The short version
D — approved (flipped from A). On the P–PE1 link the LDP transport label is popped by PHP, leaving VPN label 8888 as the outermost label; 6661 does not exist in the exhibit.
Key concepts in this question
- Label stack: BGP VPN label 8888 for 192.168.1.0/24, outer LDP label for FEC 1.1.1.1/32.
- PHP at P: P's LSP is In 6662 / Out 3 (implicit null) toward PE1.
- Capture between P and PE1: taken after P pops the transport label.
Why D is correct
The exhibit shows P's LDP LSP 6662→3 for PE1's loopback; out-label 3 means P removes the transport label, so the packet arriving on PE1 from P has only VPN label 8888 on top.
Why the others are wrong
- A. 6661 is not used anywhere in the figure's label tables (banked A is wrong).
- B. Label 3 is implicit-null and never forwarded on the wire.
- C. 6662 is the PE2→P transport label, already popped before the P→PE1 hop.
H12-831 exam tip
Same topology as H12-891 #72: P→PE1 after PHP → top label = VPN 8888.
- The device type of R1 is Level-2
- The device type of R1 cannot be determined
- The device type of R1 is Leve1-1
- The device type of R1 is Level-1-2
The short version
D — R1 defaults to Level-1-2. The IS-IS process has no is-level override, so VRP keeps the default dual-level device type.
Key concepts in this question
- IS-IS levels: Level-1 is intra-area, Level-2 is backbone, Level-1-2 does both.
- VRP default: an IS-IS process without is-level configuration is Level-1-2.
- Figure reading: the shown config enables IS-IS with a NET but sets no level.
- Stem wording: the question text says OSPF but the figure and options concern the IS-IS device type.
Why D is correct
The figure shows “isis 1” with cost-style wide and a network-entity, and no is-level command at process or interface level. Under VRP defaults, that means the router operates as Level-1-2, forming both Level-1 and Level-2 adjacencies as appropriate. Option D states Level-1-2, matching the effective configuration.
Why the others are wrong
- A. Level-2 only would require an explicit is-level level-2 setting, which is absent.
- B. The type is fully determinable from the default, so “cannot be determined” is wrong.
- C. Level-1 only would likewise require an explicit is-level level-1 setting, which is absent.
H12-831 exam tip
Memory hook: no is-level means dual level — default Level-1-2 unless the config says otherwise.
- If the DHCP request message received by the GigabitEthemnet0/0/1 interface does not contain the SutOption information of Option82, the device will generate Option82 and insert it into the message
- Enabling the DHCP Snooping configuration can be used to prevent DHCP Server counterfeiters from attacking
- Configure GigabitEthernet0/0/1 as a trusted interface
- Enabling the DHCP Snooping configuration can be used to prevent ARP spoofing attacks
The short version
D — DHCP snooping alone does not stop ARP spoofing. That claim overstates the feature, making D the wrong description the question asks for.
Key concepts in this question
- DHCP snooping: builds a binding table and filters DHCP messages by trust state.
- Trusted interface: forwards DHCP server messages; untrusted ones are checked or dropped.
- Option 82 insertion: the relay adds circuit information when the client sent none.
- ARP spoofing defense: needs DAI or IPSG on top of the snooping table, not snooping alone.
Why D is correct
The question asks which description is wrong. Enabling DHCP snooping blocks rogue DHCP servers via trusted and untrusted port roles, but by itself it does not inspect or block forged ARP packets — that requires Dynamic ARP Inspection or IPSG bound to the snooping table. Option D credits snooping alone with ARP-spoofing prevention, so it is the incorrect statement and the correct choice.
Why the others are wrong
- A. Matches the “dhcp option82 insert enable” line: Option 82 is added when missing.
- B. States the core snooping benefit: untrusted ports cannot pose as a DHCP server.
- C. Matches the config line setting GigabitEthernet0/0/1 as trusted.
H12-831 exam tip
Memory hook: snooping stops fake servers; DAI stops fake ARPs — never let one feature claim the other’s job.
Want the full bank of 241 questions for Huawei Certified ICT Professional - Datacom Advanced Routing & Switching Technology? See all practice exams.