c3550 fails to forward broadcasts to ephemeral port helper address

steve.dutky · ‎04-04-2007

My attempts to download an IOS image to c1131 access point from an offnet tftp sever fail.

The access point connects to a routed port on c3550 switch:

interface FastEthernet0/6

no switchport

ip address 10.0.0.3 255.255.255.0

ip helper-address 10.3.1.26

!tftp server

end

The access point starts up at 10.0.0.1 and initiates tftp://255.255.255.255//c1130-k9w7-tar.default.

This originates from udp source port 1024 and gets forwarded to the tftp server at the helper-address 10.3.1.26 on destination port 69.

The tftp server responds with block 1 originating from 10.3.1.26:32851 sent to 10.0.0.1:1024. Subsequent replies from the access point directed to 255.255.255.255:udp32851 do not get forwarded to the helper-address of the tftp server. (destination mac address/ttl all 0xFF...).

Eventually the access point times out the tftp attempt and starts up bootp broadcasts to udp68. These do get forwarded to the helper address.

see below for output from debug udp on the c3550. This matches SPAN session on interface FastEthernet0/6 and tcpdump running on tftp server. No problem seen using tftp server bidirectionally for other IOS devices on/off net.

The c3550 runs IOS C3550-I5Q3L2-M, Version 12.1(22)EA8a which so far has not ortherwise misbehaved for me.

Any insight or advice appreciated.

UDP packet debugging is on

mySwitch#

Apr 4 16:08:51: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed state to up

Apr 4 16:08:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/6, changed state to up

04:38:03: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(69), length=39

04:38:03: UDP: forwarded broadcast 69 from 10.0.0.1 to 10.3.1.26 on Vlan103

04:38:03: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:13: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:18: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:23: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:28: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:33: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:38:38: UDP: rcvd src=10.0.0.1(1024), dst=255.255.255.255(32851), length=12

04:39:47: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=584

04:39:47: UDP: sent src=10.0.0.3(67), dst=10.3.1.26(67), length=604

04:39:51: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=584

04:39:51: UDP: sent src=10.0.0.3(67), dst=10.3.1.26(67), length=604

steve.dutky · ‎04-04-2007

Okay, I fixed my immediate problem by configuring a one-off "ip forward-protocol 32851".

I don't know how or why my xinetd keeps picking the same ephemeral port for spawning tftpd, but reconfiguring a layer3 switch/router seems a bad way of accomodating it.

I welcome suggestions for improvement.