Cisco 1721 forwarding LAN broadcasts!?

[david.baker]

Hello :)

I've got an odd problem with a Cisco that's forwarding broadcast packets from the LAN to its default route, out of its SHDSL WAN interface.

The LAN interface is configured with 172.18.205.1/23, but the broadcasts are coming from source IP's in the ranges 172.25.0.0/16, 172.50.0.0/16 and 172.75.0.0/16 to 172.25.255.255, 172.50.255.255 and 172.75.255.255 respectively. These 3 networks were part of an IP addressing scheme that's longer in use, it having been changed to 172.18.204.0/23 (this is from the LAN administrator, and something I wasn't involved in).

Now, there are obviously some hosts on the LAN that haven't been reconfigured to use the new address scheme that are originating the broadcasts, but my question is, why are these packets being forwarded at all?

I think it's something to do with the fact that the source/destination IP's are in a different subnet to the LAN interface, which means it isn't recognising them as broadcasts, but I'm not totally sure.

Any help on this would be appreciated.

Thanks

Dave

[mheusinger]

Hi,

yes you are rigth, it does not know they are broadcasts. This is an IP routing question. With any IP packet arriving at a router it performs a lookup in the routing table for the destination IP. What is the longest match? I assume it is the default route in your case. Your router does not know this is a broadcast as this would require the information on the specific network mask. Assume you would have installed 172.0.0.0/8 somewhere in your network. Then 172.50.255.255 is a valid host address and the packet has to be forwarded.

If you want to suppress this traffic you should install an access-list that denies it (don´t forget to allow the other traffic).

Hope this helps

Martin

[david.baker]

Hi Martin - thanks for your help.

This particular router is part of a hub-and-spoke MPLS VPN. Each spoke site simply has a static default route to a firewall at the main hub site, which is where the broadcast traffic was first noticed.

So, it's not *really* a routing issue. My understanding is that a router simply wont forward a broadcast packet from one network to another - as soon as the packet is recognised as a broadcast by the LAN interface it's dropped, and no route lookup will take place.

I'm not totally sure how an interface determines if a packet is a broadcast - what boolean operation it uses. Knowing this would help greatly.

An interesting point is that I've set up an access list to filter the traffic, and applied it outbound to the WAN interface, rather than inbound on the LAN interface. Comparing the counters on the access list to the broadcast counter on the LAN interface shows that roughly twice as many broadcasts are being received on the LAN as are being blocked by the access list. This sort of suggests that the LAN interface is recognising both the valid broadcasts from from hosts in its subnet, *and* the erroneous ones, but is forwarding the latter.The plot thickens!

FYI, there's no secondary or helper IP configured on the LAN interface, and ip directed-broadcast is implicitly off in the IOS version that the router is running (12.2).

Cheers

Dave

[mheusinger]

Hi Dave,

the question might be what is a "broadcast packet".

First there are Layer2 broadcasts with a destination MAC of ff.ff.ff.ff.ff.ff on ethernet interfaces. A good example would be an ARP request. In this case the IP portion is not broadcast at all, it contains the sender IP and the requested IP. Those packets are local to the LAN unless you tell the router to forward this to some other box. This proxy behaviour is achieved f.e. for DHCP requests by configuring a "ip helper-address" command. Thats not your case I assume.

Then there is the IP broadcast address, i.e. on a subnet all host bits set to 1. This might or might not be forwarded as Layer2 broadcast. As I tried to point out, in a VLSM (classless) environment the only way to determine whether it is an IP broadcast is by knowing the network mask (forget class A, B, C, ...!). You need the mask to see which are the "host bits" and which are not. The information source for that is the routing table.

In your example 172.50.255.255 is an IP broadcast IF the network is 172.50.0.0/16. It is a valid HOST address if your network is f.e. 172.0.0.0/8. (by the way 172.50.1.0 is also a valid host address in a network 172.50.0.0/23 so the same applies to network addresses).

Now on your spoke sites you have a router as well, which forwards those 172.50.255.255 packets to your firewall. According to the IP routing table on your spoke site 172.50.255.255 is NOT an IP broadcast, so it forwards it along the default route to your firewall. For your firewall I assume 172.50.255.255 is also NOT an IP broadcast address - this depends on the FW routing table. But according to the security rules it is not allowed to forward to this network and drops as well as logs the packets.

After all no mystery here, just normal default behaviour in a classless world.

Regarding your access-list: I cannot comment as I do not know the config.

HTH

Martin

[david.baker]

I get it now :) Thanks for your help Martin.

Regards

Dave

[Richard Burts]

Dave

If these were subnet broadcasts then I would say that the behavior is correct. Since they are network broadcasts I am surprised that they are being forwarded. Is there any kind of ip helper-address configured on the router? That could cause forwarding of broadcasts.

It also occurs to me to wonder what these end stations have configured as their default gateway.

If you would post the config of the router we might be able to find some other explanation for this.

edit: having seen Martin's post it makes me think that my distinction of network broadcast vs subnet broadcast is a pretty classful distinction. In a classless environment Martin is quite correct that forwarding these broadcasts toward the default route is the right thing to do. I believe that if you want to get rid of these broadcasts there is an alternative to access lists. If you configure a static route for these broadcast addresses and forward them to null 0 then they will be discarded without the overhead of running through an access list.

HTH

Rick

[david.baker]

Hi Rick.

The configuration of the endstations is currently a mystery, unfortunately.

The key to understanding this is knowing what steps a router's interface goes through when it receives a packet to classify the destination IP, and make a decision about what to do with it - route it, drop it, or whatever. It obviously checks to see if it's in the same network as itself, and if it's a unicast or broadcast address, but the order in which it does this could be important.

If you look at my reply to Martin's post, it seems that the router is both recognising the packets as being broadcasts and incrementing the LAN broadcast counters accordingly, and at the same time recognising that the packet is destined for a network other than its own and forwarding it to the default route...

Is this normal behaviour, or could it perhaps be an IOS bug?

Cheers

Dave

[thomuff]

Can you attach the router configuration?

[david.baker]

I'm unable to forward the entire config' I'm afraid.