I observed a glaring oversight this morning after migrating a chain of 3 ME3400s from STP to REP...
We like consistency and cookie-cutter stuff, so we try to mirror configs as much as humanly possible across as many devices as possible. Along that same vain, we serve DHCP customers off of these ME3400s in addition to statically assigned customers. In order to do that, we create an SVI, call it VLAN4000, put a subnet on it and then create a corresponding DHCP pool. We'd prune VLAN4000 off of the core facing trunks because the intention was always for those DHCP SVIs to be 'locally significant'. Since the REP documentation makes it very clear that one should allow all VLANs on REP enabled trunks, what wound up happening is DHCPDISCOVERs would be broadcast across the chain and consequently, the wrong devices might respond to those DHCPDISCOVER messages causing all sorts of chaos. It was worked around by going against the REP documentation and pruning VLAN4000 off of the REP enabled trunks, but I can't help but wonder if this might wind up breaking something down the road (REP's admin VLAN hasn't been changed from VLAN 1) or if pruning VLANs for corner cases like this is a reasonable thing to do. Anyone have any thoughts? _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
