Multiple SVI on 2960

[AK59]

Hi everybody,

I'm really doubtful about a situation I'm experiencing at work.

Here's the summary.

Few years ago, the company I work in deployed five 2960 switches access in order to connect APs.

Only one of these five switch was used as a 'node' and was connected to others networks. The 4 remaining are all linked to this switch.  All of their managing interfaces are in a 10.59.201.0/24 network. (1 SVI per switch) 

These switches are not used anymore but they're still up (and must be) and remotely controlable thank to this 'node'.

For a special purpose, I need to put the switch used as a node in another network (10.21.1.0/24).

The problem is that I can't disconnect the node on its initial network, otherwise I'll lose the 4 others switches. 

So, my idea was to put another SVI like that : 

interface Vlan XXX

ip address 10.59.201.X 255.255.255.0
ip address 10.21.1.X 255.255.255.0 secondary

But that secondary address is unreachable because the default-gateway set in the switch is in 10.59.201.X/24 network. 

I also thought about creating another interface Vlan but the problem would be the same as the gateway isn't on the same network. 

So my question was, if we have multiple SVIs on a switch, is it mandatory to have their IP address on the same network ? 

Thanks in advance, 

[chrisgray1]

Hi,

It seems that you need the right IOS image for limited L3 capabilities on the 2960  -12.2(55)SE

If you are running that or greater then it should be possible create another SVI on the node.

The 2960 is not L3 routing switch apart from some static routes, but it can have multiple SVIs.

The new SVI should have the separate network. 10.21.1.0/24

FYI - Each SVI is its own network.. L3 subnet and L2 vlan

The switch itself can route between them. 

[AK59]

Thanks CrisGray1.

But, how do you explain the fact that we have an ip address defined on a vlan, and also the ability to put secondary addresses etc... and,moreover, a default-gateway.

I can do the same in another vlan, with a totally different IP address on the same switch right ?

[chrisgray1]

So I think that you have the switch in L2 mode with a default gateway.. To have it in L3 mode you would have to enable Ip routing an give it a static default route.. to whatever is your current default gateway address.

Then you can create the SVI for the new subnet.

I don't think that the 2960 is able to run any secondary addressing in the deafult L2 mode, but I may be wrong. So if you want to run a second subnet off this switch then you should enable the basic routing feature..

Someone has written about using it on the 2960 here

https://ccie-or-null.net/2013/07/25/routing-on-a-cisco-2960-catalyst-switch/

[paul driver]

Hello

Does the "node" switch connect to any L3 switch if so by trunk or access port  or are these the only devices in the network?

How are the other switches connected to the node -  trunk or access port?

If this node does connect to a L3 switch (trunked) , then all you need to do it put the other switches interconnect to node in access-port mode and you would be okay to change the node MGT interface

If the above isnt applicable then you can still makes your change to the "node" and still gain remote access to the other switches via clustering it quite an elegant way to gain L2 access.

I have used this lots of time when for some reason or the other Ive lost L3 connection to a neighboring switch and needed to gain access to it, As long as you know the neighboring enable password you should be good to go.

Example:
"node switch"
config t
cluster enable stan
do sh cluster candidates  ( to obtain the base mac-addresss of the switch)
cluster member 1 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 2 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 3 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 4 mac-address xxxx.xxxx.xxxx password ^&^^%$
end

rcommand X  ( cluster member)
once you've gain access just change its  SVI interface

res
Paul

[AK59]

---

@paul driver wrote:

Hello

Does the "node" switch connect to any L3 switch if so by trunk or access port  or are these the only devices in the network?

How are the other switches connected to the node -  trunk or access port?

If this node does connect to a L3 switch (trunked) , then all you need to do it put the other switches interconnect to node in access-port mode and you would be okay to change the node MGT interface

If the above isnt applicable then you can still makes your change to the "node" and still gain remote access to the other switches via clustering it quite an elegant way to gain L2 access.

I have used this lots of time when for some reason or the other Ive lost L3 connection to a neighboring switch and needed to gain access to it, As long as you know the neighboring enable password you should be good to go.

Example:
"node switch"
config t
cluster enable stan
do sh cluster candidates  ( to obtain the base mac-addresss of the switch)
cluster member 1 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 2 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 3 mac-address xxxx.xxxx.xxxx password ^&^^%$
cluster member 4 mac-address xxxx.xxxx.xxxx password ^&^^%$
end

rcommand X  ( cluster member)
once you've gain access just change its  SVI interface

res
Paul

---

The node switch connect to another 2960s by trunk, and the others switches are connected to the node by trunk too.  Thanks for the cluster scheme, I have one more question :

If I change the IP management int of the node and change the remaining switch into a cluster scheme. 

Will the remaining switches will be reachable by their IP address or I would have to access them trhough the node via "rcommand" ?

Thanks in advance, 

[paul driver]

Hello

if trunks connect to every switch tand those Svi’s are associated to a part vlan that’s allowed  to cross those trunks you don’t need to use the cluster you should be able to reach the end switches anyway even if you change the mode switch IP address 

 the L3 switch will do the inter vllan routing

If the above isn’t applicable. Then if you go down the cluster setup once you’ve change the addressing  on the end switche then you should again be able to reach them via ip

rrs

paul