Hi All, Trying to find an answer to a single technical point concerning a migration of a fleet of Catalyst 6500's to VSS-1440. I've had a scan through the documentation on CCO (whitepapers, config guides, migration guides, etc.) but cannot find anything dealing with this one specific point. Background: Assume that on both stand-alone chassis, you have a specific vlan interface with L3 configuration, such as: switch1: vlan 10 name testing ! interface vlan10 ip address 10.100.100.1 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! switch2: vlan 10 name testing ! interface vlan10 ip address 10.100.100.2 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! Once switch 1 is converted to VSS mode and is brought up as ACTIVE/MASTER, it will keep it's layer3 configuration on the VLAN interface. The question is what happens to the L3 configuration on switch2 when it comes up in STANDBY/SLAVE? I can foresee one of two possibilities, but not sure which to expect before trying to do this in a live enviroment: either: 1. switch2 will boot up straight into NSF/SSO, inheriting its [new L3] configuration from the active master, overwriting the pre-VSS L3 configuration. (would be preferable). or 2. switch2 will boot up and enter RPR mode with incompatible configuration for the interface, forcing me to have to manually remove the L3 configuration from the interface before I can proceed with the migration. (not really ideal with hundreds of vlans on these things...) Any idea which one of these would be the case ? (the glbp will be retained, as it will be running between two VSS pairs with 10G trunks between them). Thanks in advance Leland
From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands.
Switch 1 is intact with the new naming convention as well as SVI's. I cannot comment on glbp as I do not run it. /Jason -----Original Message----- From: Leland Vandervort [mailto:leland@taranta.discpro.org] Sent: Monday, October 19, 2009 11:07 AM To: nanog@nanog.org Subject: Cisco VSS-1440 migration query Hi All, Trying to find an answer to a single technical point concerning a migration of a fleet of Catalyst 6500's to VSS-1440. I've had a scan through the documentation on CCO (whitepapers, config guides, migration guides, etc.) but cannot find anything dealing with this one specific point. Background: Assume that on both stand-alone chassis, you have a specific vlan interface with L3 configuration, such as: switch1: vlan 10 name testing ! interface vlan10 ip address 10.100.100.1 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! switch2: vlan 10 name testing ! interface vlan10 ip address 10.100.100.2 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! Once switch 1 is converted to VSS mode and is brought up as ACTIVE/MASTER, it will keep it's layer3 configuration on the VLAN interface. The question is what happens to the L3 configuration on switch2 when it comes up in STANDBY/SLAVE? I can foresee one of two possibilities, but not sure which to expect before trying to do this in a live enviroment: either: 1. switch2 will boot up straight into NSF/SSO, inheriting its [new L3] configuration from the active master, overwriting the pre-VSS L3 configuration. (would be preferable). or 2. switch2 will boot up and enter RPR mode with incompatible configuration for the interface, forcing me to have to manually remove the L3 configuration from the interface before I can proceed with the migration. (not really ideal with hundreds of vlans on these things...) Any idea which one of these would be the case ? (the glbp will be retained, as it will be running between two VSS pairs with 10G trunks between them). Thanks in advance Leland
On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote:
From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands.
This one is alarming, especially given that there may well be some physical interfaces that are only present/used on one of the two chassis in the group. Would be interesting to see if they are defaulted to factory or not. (I would expect unused ports to be defaulted, but not ones actually configured and actively in use). Don't suppose you're able to test that one? However, this sounds like good news for the VLAN/virtual interfaces though.
Switch 1 is intact with the new naming convention as well as SVI's.
I cannot comment on glbp as I do not run it.
The glbp isn't really that much of a worry since those are being converted from HSRP anyway so will have to manually do those.
/Jason
Thanks dude... sounds like it partially answers my question, but raises another ;) L.
On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote:
From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands.
When you convert to vss mode the interfaces are renamed. The interface in switch 2 that was g1/1 becomes 2/1/1. Any configuration applied to g1/1 will be rejected because that interface no longer exists. If you intended to keep interface configuration, you will need to reapply that to the new interface name. Jason
Thanks to all on this. I've pretty much mitigated this by creating a VSS-ized version of the interface configs (chassis/slot/port) which I can then re-inject back into the system config after conversion. Shame that switch1 keeps its config and simply renumbers the interfaces, but switch2 just says "I here am new" .. but oh well. Leland On Mon, 2009-10-19 at 17:04 -0400, Mishka, Jason wrote:
On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote:
From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands.
When you convert to vss mode the interfaces are renamed. The interface in switch 2 that was g1/1 becomes 2/1/1. Any configuration applied to g1/1 will be rejected because that interface no longer exists. If you intended to keep interface configuration, you will need to reapply that to the new interface name.
Jason
participants (3)
-
Jason Giles -
Leland Vandervort -
Mishka, Jason