前段时间，领导要求重新优化我单位的网络IP资源。本人第一次承担这种项目，只得硬着头皮，摸石过河。虽然最后完成的并不十分完美，也总算获得一些经验，希望能够与各位同为类似工作而烦恼的同行们一些帮助。
俗话说，磨刀不误砍柴时。既然要实施该项目，那就先进行前期调研，做好需求分析。经过翻阅资料和与下级单位同事的谈话了解，得知当前网络存在着一些问题：一是管理复杂。由于各种原因，各单位的技术人员较少接触网络设备，因此当需要调整网络设备时，都只能通过以前的资料对号入座，而不能直接调整交换机配置，这间接增加了技术人员的管理难度；二是地址混乱。由于网络应用的增长速度大大超出了之前的规划，导致早前划分的IP子网和Vlan不够合理。某些单位占用了较多的IP地址，但使用率不到10%，而有些单位甚至需要额外的子网作为本单位IP资源。
找出了问题所在，就要制定项目目标了。首先，减少技术人员管理复杂度。这可以通过把单位内的Vlan去掉而达成；其次，根据各单位需要，重新划分IP子网，并保持每个单位最多使用一个C段地址（内部地址），其余额外加的地址都去掉。
既然制定了目标，是否可以立即做呢？答案是否定的，还必须考虑项目实施与当前状况之间的冲突，也就是可行性。由于之前的网络规划着重考虑了安全性方面的问题，各单位内设置了较多的子网。这是第一个问题的现状。而由于我单位在近期部署了正版企业版杀毒软件，以及较为完善的桌面管理系统，加上不断严格的网络使用管理制度，安全问题已经退居次席了；而且我单位没有OA（囧），通过网络传播的机密信息也较少，Vlan的存在也就相对不那么重要了。这使得第一个目标顺理成章。
但第二个目标就有难度了。由于我单位所有工作站使用静态IP地址，因此若改变IP地址，必须要求技术人员到每台工作站上进行修改。而由于跨段更换IP地址肯定会造成一段时间内的部分工作站无法上网（哪部分与网关端有关，若是在工作站修改前配置新网关，则没有修改的工作站暂时无法上网；若在之后配置新网关，则修改好的工作站暂时无法上网）。而且若跨单位调整IP资源，则需要制定严格的先后顺序，否则会出现两单位同时使用同一个网段的可能。最后，经过多次例会，确定所有单位的IP调整仅限于本单位内，在满足一段时间内应用所需前提下，仅保留一个Vlan和一个子网。
经过调整，最终目标如下：1、删除各单位多余Vlan，仅保留一个；2、采取多除少补的方式，使个单位只保留一个子网。实施时尽可能减少网络中断的时间。
终于到了具体技术实施的环节。由于改工作站信息的工作就由各单位技术人员配合完成了，本人主要负责交换机这一块。这里主要是解决如何尽可能减少网络中断时间的问题。首先考虑当前网络状况：
p_w_picpath_thumb8
每个单位都有不同的Vlan，每个Vlan对应一个IP子网。Vlan内的工作站全部使用子网内的IP地址，子网长度和指向SVI的网关。由于计划尽可能使得各单位使用原来的IP地址段，实际上除了其它网段的IP地址外，需要改IP地址的工作站只占少部分。绝大部分的IP地址都可以归为一个24位子网掩码的子网。对此，有两种方法可以使得更改子网掩码、网关不影响网络连通性：
一、网管员先记录当前核心交换机上各SVI的IP地址。然后在交换机上做配置，删除多余的vlan，shutdown掉各SVI，把所有端口都归入最终一个vlan内。在该剩下的vlan SVI上配上定好的网关IP，并把之前记录的SVI以secondary的形式配上。这时工作站若发出对原网关的ARP请求，新网关将以自己的MAC地址作为ARP应答。因此工作站将以SVI（网关B）的MAC作为外网数据包的二层目的地址。待所有工作站改完IP后，再删除这些secondary地址。这里要注意的是，必须要删除或者shutdown掉原SVI，才能在最终的SVI内配置secondaryIP地址，否则会报错：地址已存在。
二、在满足如下条件时，使用proxy-arp：
1、当前的IP与最终的SVI同在一个子网内；
2、原SVI（网关A）三层可达最终的SVI（网关B）。
其流程是：各工作站先配好最终的子网掩码和网关，最后由网管删除。有人可能会问，子网掩码、网关地址与Vlan相对应的SVI不同，能上外网吗？只要满足上述两个条件，答案就是可以的。当满足条件1时，为工作站配上新的掩码、网关后，工作站访问外网时，通过比较子网掩码，发现数据包目的地在“子网外”，因此它将把数据包发到“同一子网内的”网关B（条件1）。由于是同一子网内的，因此工作站发送一个ARP请求广播。这时，配置了proxy-arp的原SVI（网关A）收到该广播请求后，检查网关B是否三层可达。若可达（条件2），则把自己的MAC以arp应答的形式回复工作站。最后，工作站还是以SVI（网关A）的mac作为外网数据包的二层目的地址。待所有工作站改完IP后，再删除vlan、SVI，配上新的vlan和SVI。
两种方法有利有弊。第一种方式，某些路由协议不支持接口下的secondary地址作为接口发布；第二种方式有一定的条件限制。实际操作时，根据不同的情况选择不同的方式。
最终效果图示：
p_w_picpath_thumb[1]
总结：整个项目耗时一个月（不包括前期调研。当然其中还有其它项目打断过，我也还有其它工作忙乎），共涉及到26个地点共几乎500个工作站。当然相对配工作站的同志们老说，我算是轻松活了，但也搞得焦头烂额的。以下是小弟总结出来的一些经验：
一、拜托各位网络设计的大哥，前期规划再做细一点，以发展的眼光看问题。尽可能不要留给后来的小弟干这活，混口饭吃吃而已
二、强烈建议各位网管员使用DHCP，可以节省大量的经历研究其它网络优化的问题