I have a sup720 for which I have developed a configuration. I need to apply the config to the sup. Circumstances being what they are, however, I only have a 6506 chassis available and the configuration will be used on a 6509 that is in production right now. In production, there will be blades in 7 and 8. On the 6506, I won't be able to apply those parts of the configuration.
On a 3750, it's possible to specify a member number and a switch type with a provision command, then set up the ports even though the hardware doesn't yet exist in the stack.
Is there such a facility on the 6500 series (be able to specify a config for a blade that doesn't exist)? I've found a "module provision" command, but it's not clear to me how it's used and it doesn't look anywhere near as comprehensive as the command on the 3750 (it doesn't appear I can specify the blade that will be going into the slot).
Solved! Go to Solution.
Indeed you can provision modules on a Cat6500. It's been recently introduced with the VSS feature.
Search for 'module provision (virtual switch)' in the command lookup tool.
Just now I had the challenge to remove a provisioned config from a VSS member switch, since I moved a module within that member and its config remained sticky (= provisioned) in the running config.
To remove leftovers of modules you don't want to see in the running config anymore, you need to issue this command:
default module provision switch 2
To see the status of provisioned and on-line modules, issue the following command:
sh module provision switch 2
Hmmm . . . the way I'm reading this though is that you have to be using VSS.
My event has come and gone, and all is well. However, it would still be useful to know if a person can, without using or intending to use VSS, program up a supervisor on a chassis with a different slot count. (In my case, I would have been using a 6506 to program a sup720 for a 6509, so I needed to be able to tell the sup about port configurations on slots 7 and 8.)
There was one response here that said "no" and my fellow colleagues are also saying they don't think it's possible. So I'm going to presume that it is not possible unless I hear otherwise.
We have a policy of staging configurations onto the equipment that will be deployed so the configurations can be peer reviewed. We follow this even when expanding the access layer in a closet, but especially for core switches.
The reason we don't just write the config into Notepad and send it to another engineer is to avoid running the risk of something being missed in the handwritten configuration that would appear through a "show run".
I happened to scrounge up an unused 6509, but I had an unused 6506 racked up and powered that I could've used straight up if I could configure on a different-sized chassis through some kind of provisioning command set.
I'm not the enterprise switching guru, yet this is what I'm guessing:
1.) What you might want to do to check if provisioning in general works for a single chassis w/out VSS is, you want to try an IOS with at least 12.2(33)SXHx and check the behaviour of the 'module provisioning' command. This release was the first one that supported VSS so there's a chance that some features have also been ported to non-VSS code.
2.) I don't think you'll be able to provision a linecard e.g. for slot 8, if you only have a 6-slot chassis. Compared to the 3750ies, you just won't be able to physically extend that 6-slot chassis at any time, so why should Cisco support this possibility.
Anyway, if you have time and a lab, I'd suggest you to try it out ;)
Thanks for the reply.
We're working on level-setting a new IOS on our 6500's and haven't made a decision yet. I'm guessing it's going to be one of the 12.2(33) flavors, so I may get a chance to experiment soon.
My feeling on why it should be supported is simply the concept of being modular. That sup can move from a 6503 to a 6513 in a moment's notice. Why not have the ability to let it anticipate being moved to a new chassis? The only reason I could think of is if it would take too much code to anticipate all the variations of cards out there, but since it needs to know how to work with them anyway when they're physically installed, it doesn't seem like too big a leap to be able to provision for a slot that doesn't actually exist.
I may be able to lab it after we decide on a new IOS. If I get the opportunity, I'll report back.