Hi Yannatos,
Welcome to the forums
You have raised a number of questions and issues. Let's see...
1- When I finished the settings, the SVI at Core_48 were not UP in L2 (protocol-down / link-down / admin-up).
Which VLAN/SVI are we talking about? Interface Vlan110?
Either way, these are the two main reasons why an SVI does not come up:
- The VLAN does not exist
- The VLAN exists but there is no switchport in the STP Forwarding state for that VLAN (access or trunk)
There may be other platform-dependent reasons but these two are the most frequent ones. Is it possible that one of these reasons could apply? In addition, was your vPC domain already fully up without any Type-1 and Type-2 inconsistencies at the time when the SVI at Core_48 was still down?
3- In order to raise layer 2 at 48, I had to configure a interface as TRUNK, but I don't want to make it permanent.
Which interface exactly did you configure as a trunk on Core_48?
4- We are migrating the network on VLAN1 to other SVI, but everything is on VLAN1
I do not understand this statement. Is it a comment, or a question, or something else? Please try to explain in different words.
5- How do I make changes to the VPC? If try to change will lose connection? Secondary shutdown the SVI, VPC ports and ORFHAN ports?
It depends on the changes whether you will lose connection or not. Until you have configured both vPC peers with identical settings, there will be a configuration mismatch between them. In vPC, some of these mismatches are called Type-1 inconsistencies, and if they occur, the entire vPC will be brought down on both vPC peers. Other mismatches are called Type-2 inconsistencies, and if they occur, the vPC peers will warn you but they will not bring down the vPC - however, note that because the inconsistency is still there, you may encounter inconsistent traffic handling until the configuration consistency is restored. Please check the following document:
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/interfaces/7_x/b_Cisco_Nexus_3000_Series_NX-OS_Interfaces_Configuration_Guide_7x/b_Cisco_Nexus_3000_Series_NX-OS_Interfaces_Configuration_Guide_7x_chapter_0110.html#concept_B627252416F64FBBBC4E4378E9F99B70
The "must be identical" parameters are those whose mismatch will generate a Type-1 inconsistency. The "should be identical" parameters are those whose mismatch will generate a Type-2 inconsistency.
6- Relly need Default Gateway on the managment port? at the moment it is configured with DG, I believe to be wrong.
You really need it. The reason is that the management interface is placed in a standalone VRF (Virtual Routing and Forwarding) instance - essentially it has its own routing table independent of the global one (called 'default' in NX-OS). If you access the switch remotely on its management port's IP address, the switch needs to respond to you back - but it will look for a route back to you in the VRF of the management port - and that one is the "management" VRF. So you need to have a default route independent of any other routing tables for the management VRF.
Reviewing your configuration, I have noted that you have the peer-switch configured but your STP priorities are not correctly aligned. This prevents the peer switch functionality from working properly. Two rules to observe here:
- Enable peer-switch only if the vPC pair is intended to become the root switch for all vPC VLANs. If the root switch for vPC VLANs is a different switch that the vPC pair, do not have the peer-switch enabled
- For the peer-switch to work correctly, both vPC peers must have identical STP priorities in all vPC VLANs. Currently, it is not the case - your priorities are different on Core_47 and Core_48. You need to make them identical for all VLANs for the peer-switch to become active.
Feel free to ask further!
Best regards,
Peter
