agradmin
asked on
Unable to ping management interface from the CLI on new 2960x stack
I am building a new stack of Cisco 2960X switches to replace an aging 2960 set. I have updated the software and tftp'd the image of the existing stack to the new switches. After recreating (required) VLANs I have compared/cross-checked the running config and it looks OK. The 2960X stack is curremntly in a lab environment and caonnected only to a support laptop (console + Ethermet access to swicthes)
However, when I try to ping the management IP (assigned to VLAN254) via the console connection (ie from the switch itself) it times out (tests good on original switches). I get the same result trying to ping the support laptop (configured on same subnet).
Also, I see in the VLAN brief that my trunk port on each switch is indicating as being assigned to VLAN1, this is not the case when compared to the original. All active interfaces are otherwise assigned to other VLANs'
I am reluctant to schedule replacement on the existing switch stack until I have and understanding of why I am unable to ping, and why the trunk ports are showing in VLAN1. I am not Cisco certified so would really appreciate some insight here.
Thanks!
However, when I try to ping the management IP (assigned to VLAN254) via the console connection (ie from the switch itself) it times out (tests good on original switches). I get the same result trying to ping the support laptop (configured on same subnet).
Also, I see in the VLAN brief that my trunk port on each switch is indicating as being assigned to VLAN1, this is not the case when compared to the original. All active interfaces are otherwise assigned to other VLANs'
I am reluctant to schedule replacement on the existing switch stack until I have and understanding of why I am unable to ping, and why the trunk ports are showing in VLAN1. I am not Cisco certified so would really appreciate some insight here.
Thanks!
SVI is in up down state in the case that there is no at least 1 active port for that VLAN (trunk port with management VLAN typically).
All trunk ports typically look as assigned to VLAN 1 while port is down.
Check state of your management interface:
show up int brief | exc unass
Need to be in up up state to be functional.
All trunk ports typically look as assigned to VLAN 1 while port is down.
Check state of your management interface:
show up int brief | exc unass
Need to be in up up state to be functional.
ASKER
Sorry, that command is not recognized (sh up not available). If I do a sh int vlan 254 it shows the interface as being up, line protocol down. (Vlan 1 shows down/down)
Do you feel that what I am seeing is simply the result of being a test environment with trunk ports etc not connected to the corresponding network? Is there any further testing I can perform to prove?
Do you feel that what I am seeing is simply the result of being a test environment with trunk ports etc not connected to the corresponding network? Is there any further testing I can perform to prove?
No what you are seeing is due to the fact that the vlans/SVIs are not up/up and therefore won't pass traffic/allow for connectivity.
I am sorry - typo.
show ip int brief | exc unass (but depending on virtualization "| exc unass" may not be accepted (e.g. Packet tracer))
up down - means SVI is actually not capable of forwarding any traffic.
if you issue:
show spanning tree - vlan 254 will not have spanning tree instance or VLAN is missing. The reason is because there is no active port in that VLAN or VLAN is not created on switch. VLAN is automatically added to switch when port is assigned to that VLAN, but not when SVI is created for that VLAN.
In test environment it can vary since it is not real device, but "show vlan brief" and "show spanning-tree vlan 254" show give you some clue.
show ip int brief | exc unass (but depending on virtualization "| exc unass" may not be accepted (e.g. Packet tracer))
up down - means SVI is actually not capable of forwarding any traffic.
if you issue:
show spanning tree - vlan 254 will not have spanning tree instance or VLAN is missing. The reason is because there is no active port in that VLAN or VLAN is not created on switch. VLAN is automatically added to switch when port is assigned to that VLAN, but not when SVI is created for that VLAN.
In test environment it can vary since it is not real device, but "show vlan brief" and "show spanning-tree vlan 254" show give you some clue.
ASKER
Thanks Justin,
sh ip int brief | exclude unassigned shows a status for VLAN 254 as 'UP' but a protocol of 'DOWN' (sh ip int brief shows it as administratively down). I've tried a 'no shut' to no avail - what do you suggest next?
I have yet to try sh spanning-tree but will get to it if you feel needed.
Regarding " VLAN is automatically added to switch when port is assigned to that VLAN, but not when SVI is created for that VLAN."
The 1st switch was originally configured with a basic config to allow it to be used as a backup in case of failure. I then tftp's a saved image from the master of the switch stack currently in production. Noticing that several VLANs were not created (but had port assignments) I created them manually - sh VLAN brief shows the correct port assignments
sh ip int brief | exclude unassigned shows a status for VLAN 254 as 'UP' but a protocol of 'DOWN' (sh ip int brief shows it as administratively down). I've tried a 'no shut' to no avail - what do you suggest next?
I have yet to try sh spanning-tree but will get to it if you feel needed.
Regarding " VLAN is automatically added to switch when port is assigned to that VLAN, but not when SVI is created for that VLAN."
The 1st switch was originally configured with a basic config to allow it to be used as a backup in case of failure. I then tftp's a saved image from the master of the switch stack currently in production. Noticing that several VLANs were not created (but had port assignments) I created them manually - sh VLAN brief shows the correct port assignments
agra -
If you do not have an active physical interface in vlan 254 then it is not going to come up. I noted this farther up in the thread.
If you do not have an active physical interface in vlan 254 then it is not going to come up. I noted this farther up in the thread.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Justin, that information is helpful as indeed this is purely a management port with no hosts attached. I will plan to created trunk as indicated in order to test.
As for VLAN deletion - I checked the run config immediately after tftping the saved image of a production stack so VLANS should not have been deleted. The new switches do have updated software if you are saying that is s possible cause.
Thanks again for the help.
As for VLAN deletion - I checked the run config immediately after tftping the saved image of a production stack so VLANS should not have been deleted. The new switches do have updated software if you are saying that is s possible cause.
Thanks again for the help.
It is not about software version, but VTP implementation and VTP version.
You can check details about VTP with:
show vtp status
show vtp password
You can check details about VTP with:
show vtp status
show vtp password
ASKER
Thanks all for the help. I ended up assigning a port to VLAN254. As suggested the port came up and I was able to ping both the management IP and from the switch to an attached laptop.
At this point I feel relatively confident that the switch stack will work when placed in the production environment, so repeat my thanks.
At this point I feel relatively confident that the switch stack will work when placed in the production environment, so repeat my thanks.
ASKER
Thanks to both for supplying the information that helped me work through this
You're welcome.
Regarding trunks and vlan 1 - if you are seeing this under the show commands, then the annotation of vlan 1 is most likely regarding the native vlan on the trunks. Check your actual trunk configs to determine what vlans are enabled to traverse them.