Lost VLAN info

Both Clients and Servers advertise the VLAN information. The only difference is that you can not create or modify VLANs on the client. So, if a server receives a summary advertisement from a client with a higher revision number it will synchronize its data base to that client.

networker050184 wrote: »

Both Clients and Servers advertise the VLAN information. The only difference is that you can not create or modify VLANs on the client. So, if a server receives a summary advertisement from a client with a higher revision number it will synchronize its data base to that client.

argh!! thanks...

Some quick questions...

1) When I create a vlan on SWITCH#1, I thought that vlan info was going to be advertised to SWITCH#2 and SWITCH#2 would also have the new vlan info? It doesn't seem to be working...

2) Is there a reset command for lowering the revision number?

Deathgomper

notgoing2fail wrote: »

Is there a reset command for lowering the revision number?

You can reset the revision number by changing the vtp mode to transparent and then back to client or server, or you can change the domain name and then change it back.

ConstantlyLearning

notgoing2fail wrote: »

argh!! thanks...

Some quick questions...

1) When I create a vlan on SWITCH#1, I thought that vlan info was going to be advertised to SWITCH#2 and SWITCH#2 would also have the new vlan info? It doesn't seem to be working...

2) Is there a reset command for lowering the revision number?

1) What exactly are you doing and what's not working?

2) You could put a switch into VTP transparent mode, change the VTP domain name and the revision number should go back to 0.

ConstantlyLearning wrote: »

1) What exactly are you doing and what's not working?

Just playing around with my switches. I have two 3550 switches connected to each other via crossover on both ports 24.

SWITCH#1 = server
SWITCH#2 = client

Now I learned my lesson above regarding the revision numbers so I won't forget that. And thanks guys for showing me how to reset by going to transparent and back to client. I didn't know that.

Now....

Both switches have revision 7 now. Ok....

So on SWITCH#1 I tried creating a new vlan called: vlan 150.

I thought that SWITCH#2 would also get the VTP update and also have vlan 150?

When I tried creating vlan 150 on SWITCH#1, I got this error..

VLAN 1003 parent VLAN missing
APPLY VLAN changes failed.

This is vlan 1003:
1003 trcrf-default

So what the heck does vlan 1003 have anything to do with me wanting to create a vlan called: vlan 150?

It won't update the other switch unless the revision number is higher. To reset it change the VTP domain name then change it back and it will return to 0.

EDIT: Man you guys are quick. I stepped away for a minute and you guys are way ahead of me.

To the OP, check this out.

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_configuration_example09186a008009478e.shtml#vlan1003

ConstantlyLearning

notgoing2fail wrote: »

So on SWITCH#1 I tried creating a new vlan called: vlan 150.

I thought that SWITCH#2 would also get the VTP update and also have vlan 150?

When I tried creating vlan 150 on SWITCH#1, I got this error..

VLAN 1003 parent VLAN missing
APPLY VLAN changes failed.

This is vlan 1003:
1003 trcrf-default

So what the heck does vlan 1003 have anything to do with me wanting to create a vlan called: vlan 150?

Try setting the revision number on both switches back to 0 and deleting vlan.dat on both switches.

Then start the playing again.

Agreed, everyone is pretty fast here, that's why I like coming to this site...

Well I'm not having any luck with what is suppose to be the most trivial of all things switch related...

I jumped on both switches, deleted the vlans. Set SWITCH#2 to transparent and back to client. The revision reset to 0.

I jumped on SWITCH#1, and for the heck of it, set it to transparent as well and then back to server. The revision reset to 0.

There is no vlan.dat currently. Both switches are using VTP version 2.

I'm going to go ahead and reboot the switches, it's the only thing left I can think of....

I disconnected my trunk just to see if I can create a new vlan standalone.

I am still getting the same error. What's strange is, I only seem to be running into this issue after I trunked it with SWITCH#2, because obviously I had a vlan 150 running before already with no issues creating a vlan.

However, upon reboot, I did catch this error...I need to google it to see what it means...

%SW_VLAN-4-VTP_INTERNAL_ERROR: VLAN manager received an internal error 14 from vtp function vtp_download_info: Bad parent VLAN ID

Did you delete the vlan.dat file?

networker050184 wrote: »

Did you delete the vlan.dat file?

Absolutely!

I'm seeing something really strange. When I run this command:

show vlan

It only shows the default vlans.

But when I run this command:

show running-config

It still shows my original vlan 150 with the ip address I assigned it...

So what gives? I must be fundamentally missing something.....

On a side note, I created a new vlan called: vlan 25

Then I issued show vlan, and again, nothing showed up. But when I run this command: show running-config

It also shows vlan 25 with no ip address.... crazy!!??

An SVI (VLAN interface) is not the same as a VLAN in the database. Just because you have one doesn't mean you have the other.

ConstantlyLearning

networker050184 wrote: »

An SVI (VLAN interface) is not the same as a VLAN in the database. Just because you have one doesn't mean you have the other.

Yep, remove anything else you configured in relation to the VLAN's you removed. Interface assignments, SVI's etc.

Erase the startup config as well as vlan.dat and see what the story is then.

I went ahead and nuked the config...LOL...

That, along with deleting the vlan.dat did the trick.

My concern though is, what if this was a production environment? I mean, I would have been screwed!!!???

mikej412

notgoing2fail wrote: »

My concern though is, what if this was a production environment? I mean, I would have been screwed!!!???

It depends -- do you consider being unemployed as being screwed?

The funny thing is that some people do wait until they are in a production environment to figure this stuff out.

Anyway -- this is one of the reasons why you want 3 switches in your CCNA Lab. One Server, one client, and one transparent (usually in the middle of the other two.

mikej412 wrote: »

It depends -- do you consider being unemployed as being screwed?

The funny thing is that some people do wait until they are in a production environment to figure this stuff out.

Anyway -- this is one of the reasons why you want 3 switches in your CCNA Lab. One Server, one client, and one transparent (usually in the middle of the other two.

I don't have much experience with simulators so I don't know if one would run into issues that I just ran into with a simulator, but this is why I love real equipment.

So now I'm going to have a little OCD, because "something" happened, something got corrupted etc etc....

I might be able to recreate the issue by having the client have a higher revision number, then things might blow up again, but there has to be a better answer than to nuke the config....

Everything is working now. Created vlan 150 on SWITCH#1 and it got propogated to SWITCH#2....

Now I'm going to turn off STP and watch a light show....

notgoing2fail wrote: »

So I consoled in and checked the vlan status. As it turns out, SWITCH#1 lost it's custom vlan 150 and it's own revision went from 2 to 7, exactly matching SWITCH#2.

But how is this possible when SWITCH#1 was set to server mode and SWITCH#2 was set to client mode???

You've just learned why most admins will not deploy VTP in a production network. The risk of it doing something you didn't expect and blowing up your VLAN database is simply not worth the risk.

And yet the CCNA wants you to learn it anyway, virtually assuring that some wet behind the ears network admin is going to have a resume generating event because of something he read in a book

APA

mikej412 wrote: »

Anyway -- this is one of the reasons why you want 3 switches in your CCNA Lab. One Server, one client, and one transparent (usually in the middle of the other two.

If you want to have some real fun.... turn on VTP pruning with the topology Mike gave you above.

You can see some nasty effects of running a transparent switch between a server\client topology

Also... if your VTP database isn't synchronizing... also check that VTP passwords are the same on all devices in the VTP domain.

However in your scenario you managed to wipe the server config with the client DB so one would assume that your VTP passwords are matching.

Use 'show vtp password' to verfiy (Note some older IOS images don't support this command)

thenjduke

Wouldn't it be better just to put all the routers in transparent mode instead of doing client server mode and have all the vlan information at your core switches and just put the vlan information that is local to the access access switches? Like this
Core Switch

Vlan 10 Marketing
Vlan 20 Sales
Vlan 30 Engineering

Access Switch Marketing

Vlan 10 Port #

Access Switch Sales

Vlans 20 Port #

?

yup, that's how we deploy it, a switch only has the vlans it needs on it, except in a few select cases where we've had to add a few vlans on a switch without actually having any ports on that switch because we needed it to transit a pair of trunks

Forsaken_GA wrote: »

You've just learned why most admins will not deploy VTP in a production network. The risk of it doing something you didn't expect and blowing up your VLAN database is simply not worth the risk.

And yet the CCNA wants you to learn it anyway, virtually assuring that some wet behind the ears network admin is going to have a resume generating event because of something he read in a book

wet behind the ears!! I love it!!!

I was going to do a poll and ask who around here actually does VTP in production..... the CCNA book makes it sounds like the golden ticket to easy switch admin, yet for something so trivial, I was having a hard time!!!

chmorin

Ah revision numbers. Let the VTP packet spoofing begin. (Another security issue with VLAN's. IMO the perks outweigh the cons though.)

APA wrote: »

If you want to have some real fun.... turn on VTP pruning with the topology Mike gave you above.

You can see some nasty effects of running a transparent switch between a server\client topology

Also... if your VTP database isn't synchronizing... also check that VTP passwords are the same on all devices in the VTP domain.

However in your scenario you managed to wipe the server config with the client DB so one would assume that your VTP passwords are matching.

Use 'show vtp password' to verfiy (Note some older IOS images don't support this command)

Why the heck not? I have another switch laying around, better to find out the side effects in lab than production....

BTW, I had no VTP passwords set on any of the switches, I didn't want to complicate matters.....

chmorin wrote: »

Ah revision numbers. Let the VTP packet spoofing begin. (Another security issue with VLAN's. IMO the perks outweigh the cons though.)

Ohhh, so you'd rather have VTP than to manage each switch individually?

thenjduke

Actually here at my job we do it the way I describe above. I see too many problems with VTP and the way it works especially if you put a access switch into vtp server mode to change a vlan and then that revision updates across to core switches that hold vtp server. There goes entire vlan info.

notgoing2fail wrote: »

Ohhh, so you'd rather have VTP than to manage each switch individually?

Once you have your network in place, you won't often be messing with the vlan setup, most of the administrative overhead is in initial deployment. It takes me about 5 minutes to provision a new vlan, and most of that is the VRRP setup, which has to be done regardless. I usually only have to touch 3 devices (the access switch, the aggregation switch, and the distribution switch). And if I screw up, I only have to touch the same amount of devices to revert my changes.

I'll take that any day over the chance that VTP might screw up and blank my vlan setup, guaranteeing that I'll have to touch virtually every device in the network, and have a not so pleasant conversation with my boss to boot.

Forsaken_GA wrote: »

Once you have your network in place, you won't often be messing with the vlan setup, most of the administrative overhead is in initial deployment. It takes me about 5 minutes to provision a new vlan, and most of that is the VRRP setup, which has to be done regardless. I usually only have to touch 3 devices (the access switch, the aggregation switch, and the distribution switch). And if I screw up, I only have to touch the same amount of devices to revert my changes.

I'll take that any day over the chance that VTP might screw up and blank my vlan setup, guaranteeing that I'll have to touch virtually every device in the network, and have a not so pleasant conversation with my boss to boot.

It really makes me wonder how many features are really implemented in production.

So for the CCNA Security, I'm reading about NAC, Cisco CSA blah blah, how it's great and how PCs that aren't compliant don't get on the network....

But at the end of the day, is this actually implemented as sold? I'm sure every company has different policies...

How many companies though allow their bosses PCs full internet access while the rest of the workers go through a filter? I know at the companies I've worked for, that's how it works.

Do as I say, but not as I do.....

notgoing2fail wrote: »

It really makes me wonder how many features are really implemented in production.

So for the CCNA Security, I'm reading about NAC, Cisco CSA blah blah, how it's great and how PCs that aren't compliant don't get on the network....

But at the end of the day, is this actually implemented as sold? I'm sure every company has different policies...

I'm sure folks that purchase and implement a whole Cisco solution probably deploy some of this stuff. There are a few different free implementations of NAC, so the cisco solution is less appealing, and don't even get me started on CSA.... the operating systems it supports is limited (last time I checked, there was no MacOS desktop agent, which means about half the executives at our company would be out), and I find that Cisco client software tends to absolutely suck. Actually, I take that one step further and just in general say that Cisco software sucks, outside of the IOS images driving their hardware anyway. CiscoWorks drives me up the wall.

Everyone's got to remember that yes, when it comes to network certification, Cisco may be the de facto standard, but they are not vendor neutral. They're going to cheer for their solutions, even though it's not necessarily the best solution

Forsaken_GA wrote: »

I'm sure folks that purchase and implement a whole Cisco solution probably deploy some of this stuff. There are a few different free implementations of NAC, so the cisco solution is less appealing, and don't even get me started on CSA.... the operating systems it supports is limited (last time I checked, there was no MacOS desktop agent, which means about half the executives at our company would be out), and I find that Cisco client software tends to absolutely suck. Actually, I take that one step further and just in general say that Cisco software sucks, outside of the IOS images driving their hardware anyway. CiscoWorks drives me up the wall.

Everyone's got to remember that yes, when it comes to network certification, Cisco may be the de facto standard, but they are not vendor neutral. They're going to cheer for their solutions, even though it's not necessarily the best solution

You're so right.

As I'm reading up on all these Cisco acronyms, I had no idea they had quite a bit of software. Anyone reading the CCNA Security would think that Cisco is a software company with CSA, NAC (framework/appliance), MARS, SDM, ASDM etc etc... And how confusing is it that they have ACS and CSA! LOL...

Anyways, I'm not yet fully aware of other NAC products. But what you just said about Mac OS hits the spot and what OS's it supports.

When reading about CSA and how it intercepts API calls to the kernel, well, that kinda scares me....so it's basically a traffic cop...

Also, I'm starting to get confused with all their appliances and features. So if I decide to get the NAC appliance which seems to do a lot of things, what about my ASA that also has IPS, anti-spyware stuff? Do I turn them off?
Because you did pay more to license those features!!!!

I just hope that Cisco isn't reaching out too far, spreading themselves too thin....studying up on CCNA Security has really opened my eyes as far as the software side of things for Cisco.....

BTW, if you're running CSA, are you suppose to stop using Norton Anti-virus, anti-spyware, anti-malware...and what about windows defender?

And let's face it, how many OS's are really patched up to the absolute latest patch? You can't do that in production, you have no idea if the patches will screw up any of the applications you're running...

It just all doesn't seem very practical....

Sorry for the rant....