Just to warn ppl that testking.com is a ‘nice to have’ as a lot of the questions are very, if not entirely, alike. the answers aren’t always up to scratch. So use the questions but be very careful with the answers. Though I must say I have my doubts about some of the answers of the written too…

Here are some things I stumbled upon so far and mailed to feedback@testking.com:

Error #1

• Test : 350-001 Q & A with Explanations
• version : 75 (still in 76)
• Page : 330
• Question # : 7
• Suggested answer : D

Motivation:
ATM PVCs can support PPP though a number of ways, most common through AAL5SNAP as per config below. The CPE config can use a Dialer, Virtual-template or a Multilink interface to facilitate QoS for VoIP. The issue is that a service policy is required for a LLQ service-policy.

Stated support for VoIP when using F/R and/or ATM:
http://www.cisco.com/warp/public/788/voice-qos/designing-mlp-over-fr-atm.html

Specific documentation about VoIP when interworking F/R and ATM:
http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080101210.shtml

interface ATM2/0.1 point-to-point
_pvc /
# for example an SDSL circuit:
__vbr-rt 2304 2304
# for VoIP it's best to reduce the tx-ring to something like 3 (12.4 supports a tx-ring-limit as low as 1)
# (default = 40 particles, though a value of 8 seems to give best balance between VoIP and data)
__tx-ring-limit 3
# Use a Virtual-Template for cloning basic config
__encapsulation aal5mux ppp Virtual-Template 10
!
interface Virtual-Template 10
_ppp authentication [chap|pap]
_ppp multilink
_service-policy input trusted-MPlus

Wrong answers:
A. FRF.12 is not enough as the ATM interface can’t do LFI when doing IPoATM (RFC1483 or newer revisions). F/R only interworking would work with FRF.12
B. Adding that MLP is the only way to accomplish fragmentation over an ATM link would be better.
C. It is possible using PPP not FRF.12, ATM doesn’t support FRF.12 now does it.
E. PPP doesn’t support LFI, MLP (an extension to PPP) does, D is the better answer.

Error #2

• Test: 350-001 Q & A with Explanations
• version : 75 (previous versions & 76 too
• Page : 255
• Question # : 2
• Suggested answer : all are wrong

Motivation:
Depending on what type routing/class the following prefix-lists should be used. Generally only one line should be used to match a class. Multiple lines is only usefull for non contiguous address space like 10.2.0.0 – 10.5.0.0, as is common for normal ACLs.

Class A = 0xxx xxxx (B) = 0-127 (D) => need to match on 1st bit only (MSB)
Class B = 10xx xxxx (B) = 128-191 (D) => need to match on 1st 2 bits (MSB)
Class C = 110x xxxx (B) = 192-223 (D) => need to match on 1st 3 bits (MSB)
Class D = 1110 xxxx (B) = 224-239 (D) => need to match on 1st 4 bits (MSB)
Class E = 1111 xxxx (B) = 240-255 (D) => need to match on 1st 4 bits (MSB)

See my Filtering & PBR quick ref page for the resulting prefix-lists

Wrong answers:
A: 191 = 1011 1111 (B) with a /3 means the range 160.0.0.0-191.255.255.255 is matched (this is not any class)
B: 0.0.0.0/0 means any address (meaning any class)
C: 128.0.0.0/2 matches 128.0.0.0-191.255.255.255 which is the class B range, however ‘ge 17’ means only subnets are matched. ‘ge 16’ would be class B including VLSM subnets.
D: see answer B
E: 128.0.0.1/1 matches 128.0.0.0-255.255.255.255, this is too much. This list would not work as prefix-lists work by first match. The second line will therefore only ever get hit by any address with a mask of /0-23. This prefix-lixt is a mess!

The answer given by testking.com (E) implies a match-all for prefix-lists, this is not true!

Error #3

• Test 350-001 Q & A with Explanations
• Version : 75 (and 76)
• Page : 326
• Question # : 2
• Suggested answer : given answer is correct

Motivation:
The Incorrect answers are described wrong. Answers B and D are wrong indeed but the following text change is required:

“should be female, not male” >> “should be male, not female“