Ip – 0.0.0.0/32 Special-Use address

The use of secondary IP interface addresses on Cisco routers at least do not seem to have major pitfalls necessarily but moreover some limitations I've found it is useful to be aware of.

• A flat network using secondary addresses/multiple subnets will avoid the need employ dot1q trunking but will generate more broadcast traffic (if the purpose is to be able to increase the number of hosts). Depending on design this can impact upon network performance, specifically the hosts/clients.
• Routing protocols:
  • In EIGRP neighbour adjacencies will not form on secondary ip addresses full stop.
  • In OSPF then secondary addressed networks are considered as stubs so no hello packets are sent on them and will not form adjacencies either.
  • In BGP then since it acts as an application on top of TCP then its doesn't seem to care if they are primary or secondary due to the TCP process just attempting to match a source address received with an available BGP peer to form neighborship... So this can work but be careful not to mismatch primary and secondary.
• Packets sourced from the router will be from the primary interface address (Routers on a segment should normally agree on what the primary subnet is).
• Multicast PIM interface configuration needs routers that connect to each other to use the same subnet as the primary address as opposed to secondary.

To avoid issues then I'll use primary addressing wherever possible and secondary in corner case scenarios.

I was thinking if there's a way to use libpcap or another tool in turn to forge an ARP-request frame and make all the nodes within the LAN answer to the broadcast address ( so you could sniff it) or to the port where my NIC is connected to.

It doesn't have to be that complicated.

As long as your switch isn't using a feature similar to Dynamic ARP Inspection, the simple way to detect addresses is to use arping... you can find this in most linux distributions (although CLI options sometimes vary depending on what arping build you have).

[mpenning@home ~]$ sudo arping -c 2 -S 0.0.0.0 -D -i eth0 172.16.100.40
ARPING 172.16.100.40
60 bytes from 00:ae:de:ad:be:ef (172.16.100.40): index=0 time=3.513 msec
60 bytes from 00:ae:de:ad:be:ef (172.16.100.40): index=1 time=2.778 msec

You can write a script to cycle through as many addresses as you like; usually it's a good idea to sniff with wireshark and see what subnets could be used in that vlan (i.e. by looking at the source address in ARP requests).

Dynamic ARP Inspection

If you are running Dynamic ARP Inspection (DAI), you can't detect addresses like this as long as DAI checks IP address validity... I tested this on a Cisco 2960 running this configuration:

ip arp inspection vlan 100
ip arp inspection validate src-mac dst-mac ip

When I used arping as shown above, the switch noticed the invalid 0.0.0.0 source IP address in the ARP frame, and dropped it:

Jun  1 04:05:29.561 CDT: %SW_DAI-4-INVALID_ARP: 1 Invalid ARPs (Req) on Gi0/1, 
vlan 100.([0024.1bde.add7/0.0.0.0/0000.0000.0000/172.16.100.40/04:05:28 CDT 
Mon Jun 1 2015])