[c-nsp] Auto deployment of switches w/ "service config"

[Peter Rathlev]

Short version: Is there any way to use a management VLAN different from
1 for auto deploment of network devices with "service config"?

Longer version: I'm experimenting with "service config" based auto
deployment for switches, to ease the manual task of configuring new
switches throughout the network. (I'm aware of the security risks with
this, that's not the question here.)

I've come across an irritating problem: We generally don't use VLAN 1 at
all, and therefore neither for management. We generally use 3560G with
the odd 3750-12S or 2960G appearing too. Most of our inter switch links
on access switches look somewhat like this (excluding irrelevant
configuration):

interface GigabitEthernet0/28
 description GE-trunk 932-xf4-asw-02 Gi0/28
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 501
 switchport mode trunk
 switchport nonegotiate
!

To leverage "service config" I need a brand new switch to get an IP
address and further instructions from DHCP. My problem is that a brand
new switch has all ports in "switchport mode dynamic auto" per default.

When I connect "dynamic auto" to an unconditional trunk with "switchport
nonegotiate", the dynamic-auto port falls back to "static access". But
the switchport (cf. above) sends out BPDUs (here in VLAN 501) so the new
switch blocks (%SPANTREE-7-RECV_1Q_NON_TRUNK). :-(

If I instead remove "switchport nonegotiate" (which I would very much
not like to) it can negotiate a trunk, but I get a native VLAN mismatch
(%SPANTREE-2-RECV_PVID_ERR). :-(

If I configure "switchport mode dynamic auto" on the already running
switch, I can make the new switch fall back to "static access", and have
DHCP et cetera work, but this wouldn't work as a general configuration
since auto<->auto will not establish a trunk. Manually controlling which
are auto and which are trunk doesn't scale. :-(

So what's the trick? How can I make this work without having some kind
of configuration in VLAN 1? :-)

(I'm aware of Cisco's "Smart Install" initiative and am investigating
that on the side.)

-- 
Peter