Lost VLAN info

Interesting scenario I just had. I have two switches, one set to server mode and another set to client. Same domain name.

The switch we'll call SWITCH#1 had a vlan called vlan 150 revision was 2 I believe.

The switch we'll call SWITCH#2 had the normal default vlan 1 but had a higher revision number of 7.

What I expected was that SWITCH#2 would not take on any of the info from SWITCH#1 because it's own revision was higher.

But what happened was that all my port lights on SWITCH#1 turned amber and I lost connectivity.

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???

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

notgoing2fail

Forsaken_GA wrote: »

I like Cisco products, as long as they're routers and switches. Kind of like how I like HP products, as long as they're printers.

For everything else (load balancers and firewalls mainly), I've had nothing but headaches with Cisco gear, and found other solutions to be much more friendly, and integrate nicely.

I'm a fan of HP products. I really like their printers, all of my printers are HP. And I like their servers. Mainly the DL series.

I've had minor issues with their laptops and monitors in the past but I've always gotten them fixed quickly and "free" under warranty by HP, even though their customer service is in India. Nothing against India, but the VOIP that they use is horrible.

For load balancers at my last company we ended up going with a Barracuda believe it or not for $2500. It served us EXTREMELY well for what we needed it to do. Load balancing HTTPS traffic.

Other solutions were either $10,000 and above or Cisco's SSL solution which was around $30,000....

I mean come on, you get what you pay for but the $2,500 we paid brand new for Barracuda's Load Master was perfect....

mikej412

Remember that a CCNA is trained to deal with small to medium sized enterprise branch networks -- and what works well in a single office environment doesn't necessarily transfer well to a super mongo data center or enterprise campus. That's why CCNAs usually have adult supervision in any large environment.

Forsaken_GA wrote: »

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

I remember learning all the gotchas mentioned so far in this thread while I was studying for my CCNA -- but someone who is just learning enough to pass the exam probably skips over this stuff and doesn't bother to lab any of this since the odds of seeing a SIM like this is small....

APA wrote: »

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

The people who skipped this during their CCNA study hopefully pick it up while studying for their CCNP.

DPG

mikej412 wrote: »

That's why CCNAs usually have adult supervision in any large environment.

Ouch!!!

notgoing2fail

DPG wrote: »

Ouch!!!

yeah I laughed too, but it's true. CCNA's I believe are still wet behind the ears.

You can have CCNP's wet behind the ears too, but I think the higher you go up, the harder it is for you to be a paper "Cert"....

Of course I'm sure you can find CCNA's or people without any certification that can own someone with a bunch of certs....

notgoing2fail

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

I went ahead and labbed this up. So far everything seems to work just fine, what side effects should I be looking out for? Here's my setup...

SWITCH#1 - server mode
SWITCH#2 - transparent mode
SWITCH#3 - client mode

All the vlans from SWITCH#1 propagated through SWITCH#2 to make it to SWITCH#3......while SWITCH#2 being in transparent mode is able to do its own thing as far as VLAN's are concerned...

I tried to do VTP pruning on the transparent switch#2, but it said that it cannot modify pruning unless in VTP server mode.

So I went ahead and did pruning on SWITCH#1. I then created a new vlan called VLAN 88.

I jumped on SWITCH#3 and there it is! VLAN 88 shows up!!

notgoing2fail

Also, I know this is off topic, but for anyone that uses access servers, do you know of any way to get back to the AS and stay there for good until you want to reconnect to another session?

I have a habit of pressing enter numerous times, just to give myself space on the console.

But when I do that, it automatically puts me back in the last session and it gets really annoying....

mikej412

notgoing2fail wrote: »

I jumped on SWITCH#3 and there it is! VLAN 88 shows up!!

What's the purpose of pruning? Did you do any commands to check your trunks?

If there was a broadcast in VLAN 88 on switch 1, would it get passed over the trunks through the transparent switch to switch 3?

notgoing2fail

mikej412 wrote: »

What's the purpose of pruning? Did you do any commands to check your trunks?

If there was a broadcast in VLAN 88 on switch 1, would it get passed over the trunks through the transparent switch to switch 3?

ohhhh....

Well the purpose of pruning is to save bandwidth right? If a vlan doesn't exist in another switch, then information meant for that vlan aren't suppose to get passed down right? This is what I recollect I didn't look it up...

Tell me if I'm hot or cold...

I did a show interfaces trunk before, I'll do it again it though unless there are some extra commands to check...

Here's a DUH question, how can I perform a broadcast on SWITCH#1 to test its effectiveness to reaching over to SWITCH#3? I assume I need a host connected to SWITCH#1 to do the broadcasting? I don't really have any useful networking tools in my arsenal yet....

I just got finished setting up my first etherchannel. LOL.... feels good!!!

DPG

notgoing2fail wrote: »

Also, I know this is off topic, but for anyone that uses access servers, do you know of any way to get back to the AS and stay there for good until you want to reconnect to another session?

I have a habit of pressing enter numerous times, just to give myself space on the console.

But when I do that, it automatically puts me back in the last session and it gets really annoying....

I had the same problem. I would just make sure to hit a key other than Enter when I switched back to the AS.

notgoing2fail

DPG wrote: »

I had the same problem. I would just make sure to hit a key other than Enter when I switched back to the AS.

I'm not sure what the point is for them to think that we would want to automatically resume the last connection by hitting enter on a blank command? It's more of a nuisance....

If I am hitting CTL+SHIFT+6 and X, it's for a reason, I want to get out of my session and do something else!!!

notgoing2fail

mikej412 wrote: »

What's the purpose of pruning? Did you do any commands to check your trunks?

If there was a broadcast in VLAN 88 on switch 1, would it get passed over the trunks through the transparent switch to switch 3?

Ok based on what you said, I decided to do some ping tests. Here's what I did.

On SWITCH#1, I added ports 14 and 16 to VLAN 88.

Each one contained a host on the same subnet. I was able to ping each other.

I then went to SWITCH#3 and moved the host that was on port 16 over
port 14 which was also added to VLAN 88.

Tried to ping it and it didn't work.

So is this what you meant?

chmorin

notgoing2fail wrote: »

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

On a Multi-Building, Multi-Campus, Cross-State institution, yes. We are also OCD on port security and ACL's.

notgoing2fail

notgoing2fail wrote: »

Ok based on what you said, I decided to do some ping tests. Here's what I did.

On SWITCH#1, I added ports 14 and 16 to VLAN 88.

Each one contained a host on the same subnet. I was able to ping each other.

I then went to SWITCH#3 and moved the host that was on port 16 over
port 14 which was also added to VLAN 88.

Tried to ping it and it didn't work.

So is this what you meant?

Ok I think I answered my own question.

I decided to take the current structure which did not allow me to ping a host on SWITCH#3.

Connect SWITCH#3 to SWITCH#1 and bypassed SWITCH#2 (the transparent switch) and VOILA! I was able to ping the host!

So now I really do believe that this is what you were getting at correct?

If so, how does one resolve this issue or can it not be resolved?

mikej412

notgoing2fail wrote: »

Tried to ping it and it didn't work.

And why didn't it work? Anything in any of the show commands relating to trunks that might indicate traffic for that VLAN wasn't going to be sent through/over the trunk?

notgoing2fail wrote: »

If so, how does one resolve this issue or can it not be resolved?

Either you don't prune, or you don't mix transparent switches in with non-transparent mode switches.

notgoing2fail

mikej412 wrote: »

And why didn't it work? Anything in any of the show commands relating to trunks that might indicate traffic for that VLAN wasn't going to be sent through/over the trunk?

Either you don't prune, or you don't mix transparent switches in with non-transparent mode switches.

hmmm...well the only SHOW command I'm aware of are:

show vlan
show vtp status
show interface trunk

Here's what it shows for SHOW INT TRUNK

SW-2960G-24>sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi0/20      auto             802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/20      1-4094

Port        Vlans allowed and active in management domain
Gi0/20      1-2,10,22,50,52,88,99

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/20      1,88

The last part is baffling. I'm not entirely sure what it means and why it doesn't include the other VLAN's like 10, 22, 50 etc etc....

Why just 1 and 88?

APA

mikej412 wrote: »

Either you don't prune, or you don't mix transparent switches in with non-transparent mode switches.

That is precisely what I was getting at notgoing2fail.....

1,88 are in the not pruned list perhaps beacuse that switch you are on has hosts posts active in those VLANs....

Otherwise if you are still running the Server--->Transparent ---->Client topology then perhaps you are experiencing what I was trying to point out in a subtle way...

With pruning a hierarchical topology is always expected where clients are always directly connected to server and vice versa so that the pruning mechanism does not get itself confused and prune vlans from trunk links incorrectly.

notgoing2fail

APA wrote: »

That is precisely what I was getting at notgoing2fail.....

1,88 are in the not pruned list perhaps beacuse that switch you are on has hosts posts active in those VLANs....

Otherwise if you are still running the Server--->Transparent ---->Client topology then perhaps you are experiencing what I was trying to point out in a subtle way...

With pruning a hierarchical topology is always expected where clients are always directly connected to server and vice versa so that the pruning mechanism does not get itself confused and prune vlans from trunk links incorrectly.

That's what's strange. The transparent switch doesn't have vlan 88, it only has vlan 1 and vlan 76. I suppose there's more than meets the eye with VTP and I'm just going to have to dig into it a little bit more.

But generally, I can see that broadcasts can be an issue...I would assume that multi-cast would be an issue too?

It's funny because in the CCNA, it completely blows over this pretty big "gotchya", their way of presenting it is, "Oh no problem, if you set your switch to transparent, it can control it's own vlans, but still forward VTP updates, no problem..."

Although true, it would be kinda nice if they talked about the side effects...unless they did and I completely missed it...

APA

the issue isn't with running VTP between server-transparent-client........ that works fine.... the issues start to occur when you turn on features such as pruning that rely on the hierarchica. topology I mentioned in my last post

APA

oh and pruning is only covered in CCNP I believe...... therefore CCNA hasn't a need for it although extra curricular labbing\reading never hurt anyone

notgoing2fail

APA wrote: »

the issue isn't with running VTP between server-transparent-client........ that works fine.... the issues start to occur when you turn on features such as pruning that rely on the hierarchica. topology I mentioned in my last post

You know what, I didn't try turning pruning off to see if I can ping across the transparent switch.

I'll lab it up later this morning....