tftp
4 TopicsExternal Monitor + cURL + TFTP + Route Domains
Hi, I'm trying to do a external monitor to check if a tftp server is alive. During the development of the external monitor in a LAB, without route domains all works fine. After applying in production with route domains it no longer works as expected. The basic of the external monitor is: curl --globoff --silent --max-time 5 -o /dev/null tftp://[10.xx.xx.180]:69/probef5 After a packet capture we see it is the LTM reply with a ICMP Port Unreachable Even using tftp command in bash, the firt time run as expected, second in a row, it fail with timeout [adm@LTM:/S1-green-P::Active:Changes Pending] run # rdexec 14 tftp -v 10.xx.xx.180 -c get probef5 Connected to 10.xx.xx.180 (10.xx.xx.180), port 69 getting from 10.xx.xx.180:probef5 to probef5 [netascii] Received 7 bytes in 0.0 seconds [1640 bit/s] [adm@LTM:/S1-green-P::Active:Changes Pending] run # rdexec 14 tftp -v 10.xx.xx.180 -c get probef5 Connected to 10.xx.xx.180 (10.xx.xx.180), port 69 getting from 10.xx.xx.180:probef5 to probef5 [netascii] Transfer timed out. Any help would be appreciated.406Views0likes0CommentsTFTP virtual server - why not just a VIP listening on all ports with port translation disabled?
I'm looking to establish a virtual server for TFTP (for boot file retrievai via DHCP option 66/67). The examples given all depict an iRule that sets up a separate listening port for the "meet me" port that is returned after the initial exchange on port 69. My question is - why is that necessary? Why can't you just create a virtual server that listens on any port, without doing port translation (and with persistence based on e.g. source IP)? Wouldn't the following exchange be handled cleanly by that? Client UDP -> VIP:69 -> ServerA:69 (returns "meet me on port 50000") Client UDP -> VIP:50000 -> ServerA:50000 Is the concern that two servers might pick the same meet-me port? If so, would it work with priority group activation set such that only 1 server was accessed? (that wouldn't provide for load balancing, but would handle redundancy requirements).648Views0likes1CommentAdvanced TFTP Load Balancing
Problem this snippet solves: TFTP works in similar fashion to active FTP, using a callback from a random high port for the data stream: 1. The initiating host A sends a request packet to host B at Well Known Port 69. 2. B replies with a packet sent from an ephemeral port, which should be used for the remainder of the request for all data packets between Host A and host B. How to use this snippet: To support the callback connection, you would: 1. Configure the UDP virtual server on port 69 to accept the control connection and apply the clientSideTftp 2. Configure & apply a SNAT enabled at least on the server-side VLAN 3. Configure the UDP virtual server on :any 4. Apply the serverSideTftp to reestablish the auto last hop context 5. Build a data-group for all possible vlans the clients can connect to similar to vlanMapping Code : rule clientSideTftp { when CLIENT_ACCEPTED { set LAST_HOP_MAC [LINK::lasthop] set CLIENT_VLAN [LINK::vlan_id] set CLIENT_IP [IP::client_addr] set VIRTUAL_IP [IP::local_addr] } when SERVER_CONNECTED { table set "[LINK::vlan_id][IP::remote_addr][IP::local_addr][UDP::local_port]" "$LAST_HOP_MAC $VIRTUAL_IP $CLIENT_IP $CLIENT_VLAN" indefinite 3600 } } rule serverSideTftp { when CLIENT_ACCEPTED { set entry [table lookup "[LINK::vlan_id][IP::remote_addr][IP::local_addr][UDP::local_port]"] if { $entry ne "" } { nexthop [class search -value vlanMapping equal [lindex $entry 3]] [lindex $entry 0] snat [lindex $entry 1] node [lindex $entry 2] } } } data-group vlanMapping { external-file-name /config/vlanMapping.dat records { 1100 { data peering } 1101 { data external } } type string } Tested this on version: 10.2849Views0likes4Comments