I covered importance of testing the impact of delayed response earlier.
It is also important to test for lost responses to see how queuing up impacts the application/device under test.
Semantically confusing fields in networking data (like http://192.168.1.255 over a 255.225.255.0 LAN) should be tested to avoid gaffes and towards more secure code. Protocol fuzz testing should ideally cover such tests.
At last, there is also a possibility of events related to other protocols happening at unfortunate events. How does your system behave when route summary is happening from OSPF to BGP AND an OSPF update arrives? Testing such scenario is extremely difficult for the want of right set of tools and skills. It also unleashes combinatorial nightmare for testing. However, with careful “code baking” policy, it is possible to find strange, bad and nasty bugs before customers find them in the field.