Exam 300-410 All QuestionsBrowse all questions from this exam
Question 262

An administrator attempts to download the .pack NBAR2 file using TFTP from the CPE router to another device over the Gi0/0 interface. The CPE is configured as below: hostname CPE

!

ip access-list extended WAN

<`¦>

remark => All UDP rules below for WAN ID: S421T18E58F90

permit udp any eq domain any

permit udp any any eq tftp

deny udp any any

!

interface GigabitEthernet0/0

<`¦>

ip access-group WAN in

<`¦>

!

tftp-server flash:pp-adv-csr1000v-1612.1a-37-53.0.0.pack

The transfer fails. Which action resolves this issue?

    Correct Answer: D

    The issue lies in the way TFTP operates. TFTP initiates a transfer using UDP port 69, but for the actual data transfer, it uses randomly chosen ephemeral ports. Since the WAN ACL denies all other UDP traffic except for DNS and TFTP on port 69, the data transfer fails. By permitting UDP traffic on port 69, specifically for TFTP, the transfer can start but then fails as it tries to use random ports for data transfer, which are blocked by the ACL. Changing the WAN ACL to permit traffic for UDP port 69 will allow the initial connection to succeed, but you also need to consider allowing ephemeral ports for data transfer. However, the specific action to resolve the issue as per the options provided is to change the WAN ACL to permit UDP port 69 to allow the TFTP initiation.

Discussion
HuntkeyOption: C

This is actually to my surprise... The TFTP apparently is using the random port for the transfer: TFTP uses UDP as its transport protocol. A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack, typically from the range of ephemeral ports.[4] https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

[Removed]Option: D

This is interesting. Huntkey provided a nice resource of information, the RFC for TFTP provides explanation as to why this rule actually affects the connection between client and server. Based on the RFC, TFTP utilizes an ephemeral port named (TID, Transfer Identifier) that is used for the duration of the session. This TID is a random port between 0 to 65535. When a client sends a Write or Read request (WRQ and RRQ respectively), the Client chooses a TID at random, and sends the request to the server with destination port 69, this is allowed by the ACE #2 in the ACL. When the server receives the Request, it also chooses a TID at random, and uses that to send the ACK for a WRQ or a the first data packet for RRQ, but this communication is now continued between TIDs as the source/destination UDP ports. this is where the ACE#3 in the ACL is breaking the connection. 1.- CLIENT (src.port.TID) ---(WRQ/RRQ)----> (dst.port.69) TFTP 2.- CLIENT (dst.port.TID) <---(ACK/DATA)--- (src.port.TID) TFTP

SeMo0o0o0Option: C

C is corerct

inteldarvidOption: D

D correct: https://thwack.solarwinds.com/free-tools-trials/f/tftp-server/4613/tftp-communicating-on-high-ports

mrnipsnipsOption: D

This doesn't make sense the ACL is applied 'in' what does it have to do with outbound traffic ?