cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2613
Views
7
Helpful
11
Replies

2 core switches with same SVIs

kish02
Level 1
Level 1

Hi, is it possible to have 2 core switches running with the very same SVIs configured? Im not referring to stacking. I want to take down the old core later on but will gradually transfer the connected devices from old to the new core one at a time.

2 Accepted Solutions

Accepted Solutions

Hi

  This is not possible but is not necessary either. Just put the Core you want do disable in layer2 only and keep the core you will keep on the network as the gateway for enveryone. You change the default gateway on the devices under de core you want to shutdown, shutdown the SVI and keep it as layer2. Of course, if you have HRSP it will not work during this time but if the idea is to have one core only i will not have HSRP anyway.

View solution in original post

friend the new Core will use same subnet BUT different SVI IP, 
the host use OLD Core SVI IP and we want to make it use new SVI so as I mention before only change defualt-router under DHCP to point to New Core SVI IP 
you dont need to change the subnet.

View solution in original post

11 Replies 11

I try before the traffic will drop, 
Instead you can
first assign new SVI for new Core SW 
make DHCP server push new SVI ip to all host 
then host when reassign IP from DHCP it will get new SVI ip and use it as GW 
after you make sure that all host use new SVI you can remove OLD core SW

Hi

  This is not possible but is not necessary either. Just put the Core you want do disable in layer2 only and keep the core you will keep on the network as the gateway for enveryone. You change the default gateway on the devices under de core you want to shutdown, shutdown the SVI and keep it as layer2. Of course, if you have HRSP it will not work during this time but if the idea is to have one core only i will not have HSRP anyway.

Thank you  @MHM Cisco World @Flavio Miranda for your feedback.

 

I'm trying to find a way to have the least downtime as much as possible.

So I have to configure the new core switch with a new SVI from a new subnet, meaning configuring fresh DHCP and reconfiguring all VMs underlying right? There's no way to reuse the same subnet but use different IP on the new core.

friend the new Core will use same subnet BUT different SVI IP, 
the host use OLD Core SVI IP and we want to make it use new SVI so as I mention before only change defualt-router under DHCP to point to New Core SVI IP 
you dont need to change the subnet.

Thank you, that cleared up everything.

You are so so welcome 

Hello MHH
I believe Its not necessary, you just need to use the same addressing on the new core but just piecemeal the L3 migration onto the new core?


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello Flavio
I would say it is possible , Infact is a desired way of migration from old to new cores, in that you re-create the old cores SVIs on the new core but have them in a admin down state then you migrate all l2 interconnects first over to the new core and lastly disable the L3 SVIs on OLD core and enable them on new core.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

davidjohnson
Level 1
Level 1

Yes, it is possible to have two core switches with the same SVIs (Switched Virtual Interfaces) configured. This setup is commonly known as an HSRP (Hot Standby Router Protocol) or VRRP (Virtual Router Redundancy Protocol) configuration.

In this configuration, both core switches will have the same SVIs configured with identical IP addresses. One switch will be designated as the active or primary switch, while the other switch will be in standby mode. The active switch will handle the traffic, while the standby switch will be ready to take over if the active switch fails.

To achieve this setup, you can follow these general steps:

1. Configure the SVIs with the same IP address on both core switches. For example:
```
Core1:
interface VLAN10
ip address 192.168.1.1 255.255.255.0

Core2:
interface VLAN10
ip address 192.168.1.1 255.255.255.0
```

2. Configure the HSRP or VRRP settings on both switches. This includes specifying a virtual IP address and a priority for each switch. For example:
```
Core1:
interface VLAN10
standby 1 ip 192.168.1.100
standby 1 priority 110

Core2:
interface VLAN10
standby 1 ip 192.168.1.100
standby 1 priority 100
```

3. Ensure that both switches are connected and can communicate with each other through a dedicated link or a shared VLAN.

4. Configure the connected devices to use the virtual IP address (e.g., 192.168.1.100) as their default gateway.

With this configuration, the active switch will respond to ARP requests for the virtual IP address, and the standby switch will take over if the active switch becomes unavailable. As you gradually transfer the connected devices from the old core to the new core, you can update their default gateway settings to point to the virtual IP address.

Once all the devices have been migrated, you can proceed with decommissioning the old core switch.

It's important to consult the documentation and configuration guides specific to your network equipment, as the commands and configuration details may vary depending on the vendor and switch model you are using.

Regards; 

David Johnson.

Thank you @davidjohnson , I will also put this into consideration.

@davidjohnson this looks like an AI bot copy/paste answer and not really appropriate to the question which has already been answered. The whole idea of these communities is to share your knowledge and experience with others - not show you can query a search engine or chatbot!  We all use searches when appropriate but that's to expand our knowledge not to parrot something we don't understand ourselves.