Changing Masks

So a customer reckons a quick subnet mask change on their router will increase their available host range on their management network.. just like that... :(

Problem: Why increasing a subnet mask (even when you can keep the same gateway) breaks things if you don't update all the associated nodes masks (and additional assets that reference that new increased subnet)... can you help with, add to, or validate the list of issues below?

Example / Details :

• Router is a Cisco 5548 running NX-OS 5.0(3)N1(1c) 
• Original network: 10.4.66/24 Router gateway: 10.4.66.1 Router mask updated: to /23 i.e. 255.255.254.0 (The 10.4.67/24 is free for use).
• Updated network: 10.4.66/23 Router gateway remains: 10.4.66.1 
• Existing endpoints not updated and remain with original /24 mask. 
• Only new endpoints in the higher portion of the habitable range and the router now have /23 mask. 
• VLAN ID stays the same. 
• Network consists mainly of management servers and infrastructure devices management interfaces. 

  a) If a host A with its old /24 mask tries to talk to a new host B in the higher portion of the router updated /23 (i.e. 10.0.67.x ) it can not do so directly via ARP. It assumes the other host is on a remote subnet after checking its own host A mask. The A host (thinking it's still on a /24) then sends all traffic to the default gateway rather than via local means to host B. The router has to then process the frame/packet, do a lookup, and forward to host B essentially doubly handling a frame and packet rather than a conversation which could have remained fully on the local switched fabric.

b) Any hosts with static routes configured for the initial /24 will follow their default gateways to reach the new /23 higher portion without having their static routes updated. This may affect multihomed hosts with multiple egress interfaces that require the non-default gateway to communicate to remote management networks for example.

c) The new network will have to be confirmed as being advertised in all required infrastructure routers routing tables, VRFs, and associated statics. (Equally this may affect VPN concentrators, layer 3 switches, or any devices that perform either dynamic or static routing).

d) Any NAT rules will have to be updated to allow for the new /23 and associated pool sizes and mappings.

e) Any firewall objects/network objects will have to be updated to reflect the new network size.

f) For any hosts that use the IP broadcast address to communicate (as opposed to the layer 2 all hosts broadcast address of ff:ff:ff:ff:ff:ff ), the /24 broadcast address is 10.4.66.255 whereas the /23 broadcast address is 10.4.67.255… (albeit 255.255.255.255 will always reach either) thus all endpoints/hosts should be updated.

g) Methods that use proxy ARP or (potentially gratuitous ARP) from the /24 range may fail to update the router and/or hosts if the IP is not deemed to be from the correct subnet.

h) any infrastructure/router ACL(Access Control Lists) that reference a /24 mask will now have to be updated to reflect the /23 mask or connectivity/reachability may suffer.

i) any infrastructure/router prefix lists, policy maps, or traffic engineering that references these subnets or utilises the ACL's above may fail without being correctly updated.

j) if one was to update required endpoints/servers with the updated /23 mask many devices may cache the old mask and/or require a networking restart or route flush before performing.