Cisco 300-101 Free Practice Questions

Answer: A 

Explanation: 

Answer: A 

Explanation: 

Network administrators can use Unicast Reverse Path Forwarding (Unicast RPF) to help limit

the malicious traffic on an enterprise network. This security feature works by enabling a router to verify the

reachability of the source address in packets being forwarded. This capability can limit the appearance of

spoofed addresses on a network. If the source IP address is not valid, the packet is discarded. Unicast

RPF works in one of three different modes: strict mode, loose mode, or VRF mode. Note that not all

network devices support all three modes of operation. Unicast RPF in VRF mode will not be covered in this

document. When administrators use Unicast RPF in strict mode, the packet must be received on the

interface that the router would use to forward the return packet. Unicast RPF configured in strict mode may

drop legitimate traffic that is received on an interface that was not the router's choice for sending return

traffic. Dropping this legitimate traffic could occur when asymmetric routing paths are present in the

network. When administrators use Unicast RPF in loose mode, the source address must appear in the

routing table. Administrators can change this behavior using the allow-default option, which allows the use

of the default route in the source verification process. Additionally, a packet that contains a source address

for which the return route points to the Null 0 interface will be dropped. An access list may also be

specified that permits or denies certain source addresses in Unicast RPF loose mode. Care must be taken

to ensure that the appropriate Unicast RPF mode (loose or strict) is configured during the deployment of

this feature because it can drop legitimate traffic. Although asymmetric traffic flows may be of concern

when deploying this feature, Unicast RPF loose mode is a scalable option for networks that contain

asymmetric routing paths. Reference: http://www.cisco.com/web/about/security/intelligence/unicastrpf.

html

Answer: B 

Explanation: 

Answer: A,B 

Explanation: 

While stateful and stateless NAT64 perform the task of translating IPv4 packets into IPv6 packets and vice

versa, there are important differences. The following

table provides a high-level overview of the most relevant differences.

Table 2. Differences Between Stateless NAT64 and Stateful NAT64

Stateless NAT64 Stateful NAT64

1:1 translation 1:N translation

No conservation of IPv4 address Conserves IPv4 address

Assures end-to-end address Uses address overloading, hence transparency and scalability lacks in endto-

end address transparency

No state or bindings created on the State or bindings are created on every translation unique translation

Requires IPv4-translatable IPv6 No requirement on the nature of IPv6 addresses assignment (mandatory

address assignment requirement)

Requires either manual or DHCPv6 Free to choose any mode of IPv6 based address assignment for IPv6

address assignment viz. Manual, hosts DHCPv6, SLAAC Reference: http://www.cisco.com/c/en/us/

products/collateral/ios-nx-os-software/enterprise-ipv6- solution/white_paper_c11-676277.html

Answer: A 

Explanation: 

Answer: A 

Explanation: 

DMVPN Tunnel Flaps Intermittently Problem DMVPN tunnel flaps intermittently. Solution

When DMVPN tunnels flap, check the neighborship between the routers as issues with neighborship

formation between routers may cause the DMVPN tunnel to flap. In order to resolve this problem, make

sure the neighborship between the routers is always up. Reference: http://www.cisco.com/c/en/us/support/

docs/security-vpn/ipsec-negotiation-ike- protocols/29240-dcmvpn.html#Prblm1

Answer: A,B 

Explanation: 

Answer: D 

Explanation: 

PAP authentication involves a two-way handshake where the username and password are

sent across the link in clear text; hence, PAP authentication does not provide any protection against

playback and line sniffing. CHAP authentication, on the other hand, periodically verifies the identity of the

remote node using a three-way handshake. After the PPP link is established, the host sends a "challenge"

message to the remote node. The remote node responds with a value calculated using a one-way hash

function. The host checks the response against its own calculation of the expected hash value. If the

values match, the authentication is acknowledged; otherwise, the connection is terminated. Reference:

http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/10241- ppp-callinhostname.

html

Answer: A,C,E 

Explanation: 

It is a general best practice not to mix TCP-based traffic with UDP-based traffic (especially

streaming video) within a single service provider class due to the behaviors of these protocols during

periods of congestion. Specifically, TCP transmitters will throttle-back flows when drops have been

detected. Although some UDP applications have application-level windowing, flow control, and

retransmission capabilities, most UDP transmitters are completely oblivious to drops and thus never lower

transmission rates due to dropping. When TCP flows are combined with UDP flows in a single service

provider class and the class experiences congestion, then TCP flows will continually lower their rates,

potentially giving up their bandwidth to drop-oblivious UDP flows. This effect is called TCP-starvation/

UDP-dominance. This can increase latency and lower the overall throughput. TCP-starvation/UDPdominance

likely occurs if (TCP-based) mission-critical data is assigned to the same service provider class

as (UDP-based) streaming video and the class experiences sustained congestion. Even if WRED is

enabled on the service provider class, the same behavior would be observed, as WRED (for the most part)

only affects TCP-based flows. Granted, it is not always possible to separate TCP-based flows from UDPbased

flows, but it is beneficial to be aware of this behavior when making such application-mixing

decisions. Reference: http://www.cisco.com/warp/public/cc/so/neso/vpn/vpnsp/spqsd_wp.htm

Answer: A 

Explanation: 

The Unicast RPF feature helps to mitigate problems that are caused by the introduction of

malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a

verifiable IP source address. For example, a number of common types of denial-of-service (DoS) attacks,

including Smurf and Tribal Flood Network (TFN), can take advantage of forged or rapidly changing source

IP addresses to allow attackers to thwart efforts to locate or filter the attacks. For Internet service providers

(ISPs) that provide public access, Unicast RPF deflects such attacks by forwarding only packets that have

source addresses that are valid and consistent with the IP routing table. This action protects the network of

the ISP, its customer, and the rest of the Internet. Reference: http://www.cisco.com/en/US/docs/ios/12_2/

security/configuration/guide/scfrpf.html

Answer: Here is the solution below: 

Explanation: 

To troubleshoot the problem, first issue the show running-config on all of 4 routers. Pay more attention to the outputs of routers R2 and R3 The output of the "show running-config" command of R2: 

The output of the "show running-config" command of R3: 

We knew that all areas in an Open Shortest Path First (OSPF) autonomous system must be physically connected to the backbone area (Area 0). In some cases, where this is not possible, we can use a virtual link to connect to the backbone through a non-backbone area. The area through which you configure the virtual link is known as a transit area. In this case, the area 11 will become the transit area. Therefore, routers R2 and R3 must be configured with the area <area id> virtual-link <neighbor router-id>command. + Configure virtual link on R2 (from the first output above, we learned that the OSPF process ID of R2 is 1): 

R2>enable 

R2#configure terminal 

R2(config)#ipv6 router ospf 1 

R2(config-rtr)#area 11 virtual-link 3.3.3.3 

Save the configuration: 

R2(config-rtr)#end 

R2#copy running-config startup-config 

(Notice that we have to use neighbor router-id 3.3.3.3, not R2's router-id 2.2.2.2) + Configure virtual link on R3 (from the second output above, we learned that the OSPF process ID of R3 is 1 and we have to disable the wrong configuration of "area 54 virtual-link 4.4.4.4"): 

R3>enable 

R3#configure terminal 

R3(config)#ipv6 router ospf 1 

R3(config-rtr)#no area 54 virtual-link 4.4.4.4 

R3(config-rtr)#area 11 virtual-link 2.2.2.2 

Save the configuration: 

R3(config-rtr)#end 

R3#copy running-config startup-config 

You should check the configuration of R4, too. Make sure to remove the incorrect configuration statements to get the full points. 

R4(config)#ipv6 router ospf 1 

R4(config-router)#no area 54 virtual-link 3.3.3.3 

R4(config-router)#end 

After finishing the configuration doesn’t forget to ping between R1 and R4 to make sure they work. 

Note. If you want to check the routing information, use the show ipv6 route command, not "show ip route". 

Answer: A 

Explanation: 

Answer: B 

Explanation: 

Answer: A 

Explanation: 

To display information about the Cisco Express Forwarding adjacency table or the hardware Layer 3-

switching adjacency table, use the show adjacency command.

Reasons for Incomplete Adjacencies

There are two known reasons for an incomplete adjacency:

The router cannot use ARP successfully for the next-hop interface.

After a clear ip arp or a clear adjacency command, the router marks the adjacency as incomplete. Then it

fails to clear the entry.

In an MPLS environment, IP CEF should be enabeled for Label Switching. Interface level command ip

route-cache cef No ARP Entry When CEF cannot locate a valid adjacency for a destination prefix, it punts

the packets to the CPU for ARP resolution and, in turn, for completion of the adjacency.

Reference: http://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/17812-cefincomp.

html#t4

Answer: A 

Explanation: 

Answer: C 

Explanation: