No, the title doesn't imply a great new translation technology for that indispensable file transfer protocol TFTP. Instead, this is to highlight an "oversight" - I won't go so far as to call it a "bug" - in Cisco IOS.
I'm testing with version Advanced IP Services 12.4 (24)T on a 7200 series router - just in case that matters.
For many services on Cisco routers and switches, I've been using the "source interface" command to explicitly tell the device what address to source the updates from. Normally, I point it to a loopback interface. This makes looking at logs pretty easy when DNS resolves the loopback address to the device name.
So for example:
ip flow-export source Loopback0 logging source-interface Loopback0 snmp-server trap-source Loopback0 snmp-server source-interface informs Loopback0
In most cases, we'll even use "update-source LoopbackX" for iBGP neighbors.
This makes looking at a Syslog and SNMP Trap aggregator easy. As long as they resolve addresses to names, I see content like:
Router1 Informational Local7 Interface FastEthernet0/0 up SwitchA Emergency Local6 Power supply 1 down
Instead of:
10.254.254.1 Informational Local7 Interface FastEthernet0/0 up 10.254.254.2 Emergency Local6 Power supply 1 down
Now that we've shown why this is good practice, I'll also add that we track nightly TFTP backups of configurations in TFTP logs and the same principle applies. So we use the 'ip tftp source-interface Loopback0' command. Notice however that all previous commands don't start with 'ip', the TFTP 'source-interface' command does. Big deal? With IPv6 it turns out ... YES, it is.
Granted the backup routine tested connected to the devices via IPv4 and requested a TFTP backup via SNMP to the IPv4 address of the TFTP server - so we didn't lose a night's worth of backups and wake up to an error log. The benefits of testing first! However, with IPv6 enabled and an IPv6 address on the Loopback0 interface, IPv6 TFTP should work. And in the test, it didn't.
Here's the relevant configuration:
ip tftp source-interface Loopback0 interface Loopback0 ip address 10.254.254.1 255.255.255.255 ipv6 address 2001:DB8:AFE:FE00::1/128 ipv6 enable interface FastEthernet2/0 description To TFTP Server ip address 192.168.100.1 255.255.255.0 ipv6 address 2001:DB8:192:168::1/64 ipv6 enable
The TFTP server in the test lives at:
192.168.100.254
2001:db8:192:168::254
Again, IPv4 TFTP worked as expected. The Loopback0 address (10.254.254.1) shows in the TFTP logs. But with IPv6, something strange happened:
R1#copy run tftp Address or name of remote host []? 2001:db8:192:168::254 Destination filename [r1-confg]? ..... %Error opening tftp://2001:db8:192:168::254/r1-confg (Timed out) R1#
And the resultant TFTP server log shows:
TFTP# crapps.pl -S tftpd -6 Starting MODE -> TFTP Server Listening on -> [::]:69 (udp) TFTP Root directory -> . afe:fe01:: 62506 WRQ OCTET r1-confg STARTED afe:fe01:: 62506 WRQ OCTET r1-confg STARTED afe:fe01:: 62506 WRQ OCTET r1-confg File './r1-confg' already exists afe:fe01:: 62506 WRQ OCTET r1-confg Timeout occurred on DATA packet 1 ...
Who the heck is "afe:fe01::"? My Loopback0 IPv6 address is "2001:db8:afe:fe00::1". True, but my Loopback0 IPv4 address is "10.254.254.1", or in hex used directly as an IPv6 address is "afe:fe01::". I remember a saying about computers doing exactly what you tell them to. The Cisco router is sourcing the TFTP from the 'ip tftp source-interface Loopback0' - 'ip' as in "IPv4".
So is IPv6 TFTP broken? No, you just need to remove the 'source-interface' command:
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#no ip tftp source-interface Loopback0 R1(config)#end R1#copy run tftp Address or name of remote host []? 2001:db8:192:168::254 Destination filename [r1-confg]? !! 8774 bytes copied in 5.540 secs (1584 bytes/sec) R1#
And confirmed on the TFTP server:
TFTP# crapps.pl -S tftpd -6 Starting MODE -> TFTP Server Listening on -> [::]:69 (udp) TFTP Root directory -> . 2001:db8:192:168::1 52000 WRQ OCTET r1-confg STARTED 2001:db8:192:168::1 52000 WRQ OCTET r1-confg SUCCESS [8774 bytes]
Much better. Of course now the source is the interface of the router that the TFTP traverses, in this case, FastEthernet2/0. This will also be the same for IPv4 TFTP now.
Nightly TFTP backups are one of those automated tasks we set and forget. Sure there are monitors in place to catch changes and email alerts, but how often does something go wrong? Imagine waking up to an error log an no backups. Not then end of the world, but certainly not something you want to see before your first cup of coffee. Test and test again, especially when incorporating IPv6.
No comments :
Post a Comment