We have Cat-6506 with MSFC on the core and have created 9 VLANs using the following address schema 172.21.8.0/21. My partner decided to change the subnet mask on one of the VLAN Interfaces and changed the following: from 172.21.24.133/21, he changed to 172.21.24.133/24. Once he made the change, we could no longer access the MSFC on any of the VLANs. We're kind of stumped as to why - can anybody please shed the light? Thanks
How are you accessing the MSFC? Are you using telnet from a PC on the VLAN that your partner changed? If so, your PC may no longer be on the IP subnet now that it changed from /21 to /24.
Just to get a bit more info.,, Did you split the 172.21/16 range into subnets like the following:
and so on...
Does each VLAN have a unique /21 out of the above range ?
When you say "you cannot acces the MSFC" do you mean that you cannot route to any other VLANs from hosts on the VLAN whose mask you changed ?
Like the other posters I believe that we could give you better advice if we understood your situation better. Could you be clear about what addressing was used for each of the 9 VLANs?
Differences in subnet mask tend to be compensated for if proxy-arp is enabled and to be more problematic if proxy-arp is disabled. Could you tell us whether proxy-arp is enabled or disabled?
Would the VLAN interface where the mask was changed happen to be the VLAN where the sc0 interface belongs?
It would help us to give you better advice if you would post the relevant parts of the config.
the subnets are :
172.21.32.0/21 and so on and everything was OK.
then, the 172.21.24.0/21 was changed to /24 and after that change was made, we were unable to even ping any of the VLAN interfaces on the msfc from any of the vlans..So, I changed it back to /21 and it worked again....very odd...
I am not sure that I am correctly understanding your situation. I do not know if a few more details might help or not (or how far you want to persue this).
I can think of scenarios where changing the subnet mask of the VLAN interface from /21 to /24 would impact the ability to ping to or from devices connected in the 172.21.24.0 subnet. But your explanation of the situation seems to say that when you changed the mask of 172.21.24.0 it impacted the ability to ping from 172.21.16.0 to 172.21.32.0. If I am understanding you correctly this is indeed very wierd.
If you want to go further with this issue can you provide some clarification of the topology and the environment.
u're understanding me correctly - thanks. it's a very straight forward environment with a couple of etherchannelled cat-6506's at the core and cat-2980's on the access. I was sitting on the 172.21.16.0 subnet and could not ping any of the interfaces on the msfc until I changed the 172.21.24.133/24 interface back to /21.
Really an intriguing little problem. I think the issue is a bit more complicated than suggested.
In general, 6500-based systems are not there for testing purposes and therefore it is likely that the issue you reported played in a matter of seconds. You got it back up and the next thing you did was post this message, am I right?
You say there are two 6500's?
Are these perhaps running HSRP? Changing a subnet on one machine might render the HSRP config invalid. I can imagine that this could (temporarily) hang the MSFC. What would happen when you shut the interface before altering the subnet-mask?
Another option is that you may have caused a spanning-tree topology change while executing the change in which case you might see connectivity returning after about 30s.
Did you give it that long?
Thanks for your response. Yes, we do have HSRP running between all the interfaces and we only got to change the subnet mask on the 172.21.24.133 int on one cat-6500, but not on the other. Even though each HSRP group is totally autonomous from the others, your point is very well taken in that I wonder if it could wreck the havock on the whole config....
It is just a guess but what else could have caused the issue that you experienced?
There is little doubt that the hsrp config that remained after the change was invalid.
Under this kind of circumstances it is advisable to shut the interface before making any changes.
The HSRP was invalid just for the subnet (interface). that had the mask changed from /21 to /24.. why has it impacted every other subnet (interface)... Thanks