Tracert to a Subnet Broadcast: Answer (3)
Today I’ll wrap up this long explanation of what happens to packets sent to a subnet broadcast address. You’ll probably need to read the other two answer posts to make sense of what’s in todays post. Enjoy!
- Original Question
- Answer Part 1 (R2’s Logic)
- Answer Part 2 (R3’s Logic)
- Answer Part 3 (This post)
To review, host A sends IP packets destined to 192.168.1.31, the broadcast address in subnet 192.168.1.0/27, located off R3. The TTL=1 packets are discarded by R2; the TTL=2 packets are discarded by R3. Next, let’s discuss the TTL=3 packets , which R3 will not throw away.
Pick up the story when R3 has this IP packet in memory, and R3 will not discard the packet due to TTL. R3 also has a connected route for 192.168.1.0/27. If the packet was sent to a unicast IP address in that subnet, R3 would need an ARP cache entry, or it would need to send an ARP request. However, because R3 knows that 192.168.1.31 Is a broadcast address, R3 knows that sending an ARP request is pointless, because no host could possibly have that IP address anyway. So, R3 instead would encapsulate the IP packet inside a broadcast Ethernet frame (destination FFFF.FFFF.FFFF), so that all hosts receive the packtet. Well, at least that would happen if Cisco IOS did not default to an interface setting of “no ip directed-broadcast”.
With that default setting, when IOS realizes that the destination is a broadcast address, in a connected subnet, IOS discards the packet. To enable the option to have the router forward the packet as a LAN broadcast, configure the “ip directed-broadcast” interface command.
Even if you configure R3 to forward these packets, most hosts would not respond.
As for the question, and whether answer D or E is correct, D is correct, for the reasons stated above. E is not correct, even in the case where you configuration “ip directed-brodcast” on R3’s LAN interface, because R3 will never ARP for an IP address it believes to be a subnet brodcast address on a connected subnet.
That’s it for this 4-post tirade. Ask questions if you have them!
Wendell
){kind=link}
What kind hosts would respond ? and why would other hosts not respond ?
How come R2 made no distinction between subnet broadcast ip’s but R3 made that distinction ?
Thanks & Regards
Hi Nigel,
Taking your questions one at a time:
As for which hosts reply, that’s a long answer, one that I avoided here because the focus was on the router behavior. if you google around for “broadcast ping OSX”, or for linux, windows, etc, you can in some cases find mechanisms to enable or disable on an OS. The answer is a big “it depends”.
As for R2 vs R3, I think these points are made between the two posts, but summarizing: Both R2 and R3 match a router. However, R2’s route lists a next-hop router, so R2 can encapsulate the packet so that it reaches the next hop router, without even thinking about whether the address is a subnet broadcast. R3, by matching a connected subnet route, sees the destination as a subnet broadcast, and uses the logic listed in this post.
Wendell