cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2276
Views
0
Helpful
4
Replies

Router passing broadcast UDP 137 even with 'no ip forward-protocol ds'

jkeeffe
Level 2
Level 2

I have a 3640 router (IOS 12.2(26)), which is passing subnet broadcasts even though I have these statements:

no ip forward-protocol udp netbios-ns

no ip forward-protocol udp netbios-dgm

We're trying to track down why some PC's are getting the standard Windows 169.254.xxx.xxx address, and stumbled onto this problem of the router passing 169.254.255.255 subnet broadcasts.

I'm not concerned in this question about why some PCs are not finding a DHCP server and instead getting a 169.254.xxx.xxx address. I am concerned about why the router is passing the 169.254.255.255 packets. I know this is happening because I see packets on the network connected to F0/0 which are sourced from F0/0's mac address. Here is F0/0 config:

interface FastEthernet0/0

ip address 164.72.100.129 255.255.255.128

no ip unreachables

ip accounting output-packets

ip route-cache same-interface

ip route-cache flow

speed 100

full-duplex

...and...

ROC-INET-3640#sh int f0/0

FastEthernet0/0 is up, line protocol is up

Hardware is AmdFE, address is 0010.7b9c.47c1 (bia 0010.7b9c.47c1)

Internet address is 164.72.100.129/25

Here is the output of snoop showing the 169.254.255.255 destination address sources from the router F0/0:

12:59:26.129935 I 0:10:7b:9c:47:c1 1:50:5a:48:64:a6 0800 92: 169.254.148.30.137 > 169.254.255.255.137: udp 50

0000 fdaa0110 00010000 00000000 20454245 ............ EBE

0010 44454443 4e454d46 44444243 41434143 DEDCNEMFDDBCACAC

0020 41434143 41434143 41434141 41000020 ACACACACACAAA..

0030 0001 ..

(ttl 121, id 30291)

So the big question: Why is the router passing 169.254.255.255 port 137 when it is configured with the 'no ip forward-protocol ns' statement?

4 Replies 4

Richard Burts
Hall of Fame
Hall of Fame

Jim

I am not sure of what is happening here. If you ping to 169.254.148.30, the supposed source, do you get any response. On which interface is the PC which originated the packet? Can you post the configuration of that interface as well?

HTH

Rick

HTH

Rick

I can't ping or traceroute to the source - there is no route for 169.254.148.30. The source is somewhere out of the router's F0/1 interface and here is that int's config - very basic:

interface FastEthernet0/1

ip address 164.72.52.135 255.255.255.128

no ip unreachables

ip wccp 2 redirect in

ip wccp 3 redirect in

ip wccp 4 redirect in

ip wccp 5 redirect in

ip route-cache flow

speed 100

full-duplex

This is definitely strange - yet there must be an explanation somewhere.

dbellaze
Level 4
Level 4

I think the problem is Cisco routers only see broadcasts in two ways. All ones (255.255.255.255), or directed (in this case 169.254.255.255). Obviously in this case the 169.254.255.255 is actually a network broadcast and not directed, but since Cisco only see's in two ways it gets caught in being a directed broadcast.

By default all routers are supposed to allow directed broadcasts, but have the option to disable it. I think Cisco has it disabled by default starting with a certain IOS.

Try putting the following command on your Fa0/0 interface and see if this helps (I'm not sure on the placement so you might have to try it on the Fa0/1 too).

no ip directed-broadcast

Daniel

Also, it looks like your forward protocol deny statements are not blocking the message because the packet is using UDP port 50 as the destination.

Daniel

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: