Vlan deployment

[parthrawat979]

I know it's a very silly question to ask, but I want to know whenever we create a vlan with vlan vlan-num e.g. vlan 10

and then till we don't use exit and came back to configuration mode the vlan doesn't show up. Like why we have to explicitly 'exit' to create a vlan succesfully??

[Joseph W. Doherty]

I've never noticed that, but I'm not saying it doesn't behave as you describe.

Firstly, it's possible such behavior might vary between platforms and/or other configuration settings being used (such as VTP).

Secondly, such behavior might be because when you enter a VLAN number, you've entered VLAN configuration mode and perhaps changes are not "committed" until you explicitly (or implicitly) exit.  Such behavior might be due to supporting VTP, even in transparent or off modes.  I.e. to avoid sending a VTP revision until all VLAN configuration changes have been completed.

[Joseph W. Doherty]

Thinking some more about this, such behavior might also be due to that long ago you had CatOS, for L2 switches, and IOS for routers.  On early L3 (or MLS) switches, they had two separate configs, one for L2 and one for L3.  Possibly (so long ago, I don't recall), the L2 config didn't immediately commit creation of a new VLAN until it thought you were done with its configuration options.  Possibly, also, VLAN information was (is?) stored within a "VLAN database", might be a cause for such behavior.

BTW to confirm what you've noticed, you're saying. . .

Conf t

Vlan 5 !new vlan

! doesn't yet exist until . . .

Exit ! now

! But have you tried 

Vlan 6 ! another new VLAN, status V5?

Int something ! implicit mode change, status V5?

Unfortunately, I don't have any real equipment to test VLAN configuration behavior.

[Martin L]

what IOS? real switch?

[Joseph W. Doherty]

what IOS? real switch?

Great questions.

Which is why in my first reply I mentioned such behavior may vary by platform.

Yet, such behavior wouldn't be obvious and as VLANs configurations are somewhat special, I could see such behavior as a possibility.

Also why in my second reply I mentioned not having any "real" equipment to test such behavior.

If this is Packet Tracer behavior, well PT behavior is sometimes just its behavior.

Still, again, great questions.

[paul driver]

Hello 
the reason for this is - some older ios’s do not update there internal d/b unless the exit command is applied.

[Cristian Matei]

Hi,

   This has been the expected behaviour since the very early days of IOS, don't recall if it had anything to do with CatOS inheritance or how it behaved in CatOS. And this behaviour is still present today, and it has nothing to do with VTP version you're running or the VTP mode you're running, because regardless of these settings, VLAN database changes are always present in VLAN.dat file; even if you run VTP in transparent mode, in which case the VLAN configuration shows in running-config, the VLAN configuration is still also kept in VLAN.dat file, which make sense as if you change from transparent to  server / client mode, the switch VLAN configuration is not gonna which will for sure result in an outage / network down event.

   My humble expectation / understanding for the reason is that because the switch treats this configuration as a transaction from the perspective of making changes to VLAN.dat file, changes are committed only after you exit the VLAN configuration mode.

   Finally, I would say that the know the exact WHY from Cisco's perspective, one would have to look for very old documentation or training on CatOS, where it all started. I'd say that today, this is just inheritance and the way it t still works, also on latest IOS-XE code versions, which is normal, we don't change any behaviour for no valid reason. At the same time, for example NX-OS is different per what I recall, in NX-OS you don't have to exit the VLAN configuration mode for VLAN to show up / exist, so different NOS'es, different decisions being made by engineers that did the coding.

Thanks,

Cristian.

[Joseph W. Doherty]

This has been the expected behaviour since the very early days of IOS . . .

Laugh, might depend on your definition of "early" as IOS, early on was L3.  I.e., was there VLAN support in Cisco devices before it was supported in any IOS, like perhaps CatOS?

. . . don't recall if it had anything to do with CatOS inheritance or how it behaved in CatOS.

Finally, I would say that the know the exact WHY from Cisco's perspective, one would have to look for very old documentation or training on CatOS, where it all started. I'd say that today, this is just inheritance . . .

"Just" inheritance?  I believe not.

My humble expectation / understanding for the reason is that because the switch treats this configuration as a transaction from the perspective of making changes to VLAN.dat file, changes are committed only after you exit the VLAN configuration mode.

"Transaction", excellent word!  But why?  What's so special about vlan.dat?  Besides vlan.dat, anything else tied to VLAN configuration that might be special and might benefit from transactional updating?  I believe there is, VTP.

We often think of VTP just providing a nice set of VLANs, by VLAN ID number (and optionsl names too) across a VTP domain, but it does a tad more.  For instance, with its domain understanding of VLAN usage, it offers its auto pruning option.  It also, I recall (?) offers the capability to suspend or disable a VLAN across a VTP domain (a feature I recall only using once).

Besides VLAN configuration changes impacting all switches in a VTP domain, keep in mind early switches were often not all ports wirespeed capable and were easier to overwhelm their control plane with even trivial updates.

So, during VLAN updates like:

Name for Matei's testing 

Name (temporary) for Matei's testing

Name (temporary) for Matei's (x1234) testing

Do you really want every line configuration change to immediately update every switch in the VTP domain?  Maybe not?

Also, why even have a vlan.dat?  transparent or off modes store VLAN info as other config information, right?  So, what's special about vlan.dat?

Well, it might be "convenient" for some other running protocol (like VTP) have access to VLAN data, unique to the needs of such other protocols also avoid needing to be aware or interact with whatever keeps configuration data stored for internal usage.

I suspect, because of the above reasoning, the described VLAN configuration commitment behavior, at least initially implemented, is likely very much bound up with VTP.

And this behaviour is still present today, and it has nothing to do with VTP version you're running or the VTP mode you're running . . .

Maybe, maybe not.

Firstly, when we speak of VTP versions, there's the public facing versions (i.e. 1, 2, 3) and internal software versions, which may be totally invisible to us.

When Cisco added the "off" mode, hasn't VTP been changed?  But, it doesn't impact our backward compatibility.  If Cisco's new off mode doesn't maintain vlan.dat, generally, does it, or should it, matter to us?

BTW, for flexibility in software evolution, we want to keep many internal details hidden.  So, for example, with vlan.dat, Cisco makes its existence known and mentions it's something you may want to make an off device backup of, but its internal structure isn't described.

To sum up, truthfully, to OP's question of particular behavior, only Cisco could answer that, laugh, if they still remember (and are willing to).  Otherwise it's conjecture, based on what other information that's available to us, and on our experience and knowledge.

Personally, my education and decades of my career was in (avant-garde) software development so, perhaps, I'm a bit more attuned to some "whys" things are done as they are.  But again it's personal conjecture.  Laugh, some real head scratchers can be when you assume what you're examining is the best or optimal approach and it's not.

[Cristian Matei]

Hi,

     When I said the early days of IOS, it was obviously meant to be read as the early days of IOS when layer 2 features / VLAN's were added, this is how I recall it, I've had this exact experience / functionality like 20+ years ago when I was learning this.

    When I said today it's just inheritance, it was meant to be read literally as today, that today it's working this way, which is the same way since I've known IOS supporting layer 2 features, thus today it's just inheritance of a decision made very long time ago, nothing has changed. 

   When I said functionality is the same regardless of which VTP version you're running, and which VTP mode, including OFF, it was meant to say that the outcome is the same, regardless how you have VTP configured; obviously we don't know what we don't know, we do't know the code internal ramifications and reasoning / logical structure.

    Yes, why was the decision made so that VLAN configuration changes behave this way, transaction mode which require to exit (equivalent of commit & exit in other NOS'es or Linux :wq), we can debate and find enough reasons to write an e-book Only someone from Cisco with access to those 20+ years internal documents, if still existing, can bring light to this. 

Thanks,

Cristian.

[Joseph W. Doherty]

Perhaps to summarize your answer to "why" the observed behavior "is as it is", simply because that's the way it has been, for years and years, i.e. inheritance.

Further, as we cannot really know the original design reasoning, and it works as it does, possibly it's not even worthwhile to speculate beyond "it is as it is".

Apologies if I'm misreading your replies, i.e. what meaning you're trying to convey.

[Cristian Matei]

Hi,

    The way I operate is to completely understand the functionality, expected behaviour in all scenarios, as this is what matters in real life. Additionally, i absolutely always never give up to understand the WHY, as this is a key aspect in understanding / knowledge / logic / reasoning; however, I never like to speculate if I can't find the WHY as for me, speculation fits outside of technology area and there are countless paths / options in speculation. Yes, I speculate initially till I meet the logic (normal thinking and reasoning process), but this needs to ultimately be validated by RFC or by a god documentation explaining the logic and reasoning; if this process fails, I don't care what the possible options could be, for me it's useless data that might do me more harm than good.

   Obviously, everyone is free on bringing their own opinions, suggestions, ideas; however, I, as a person, like to know the truth / the reality of the WHY, if this is not possible, just stick with the outcome / aka it is what it is; in my mind and from my experience, the more speculations I have, the more (in other more complex technologies) I tend to build newer structure on top of these speculations and this is a path to failure.

   I really appreciate the convo and hope it makes sense where I'm coming from.

Thanks,

Cristian.

[Joseph W. Doherty]

I really appreciate the convo and hope it makes sense where I'm coming from.

Thank you, Cristian.

Yes, your position makes sense, especially for typical network engineering.

My position is different, but possibly that's because of my decades of software development and maintenance experience.

That's not intended to imply my approach is better for typical network engineering, but it's possible better for some issues.  Conversely, I believe, your approach is actually better for many more issues.

The difference might somewhat fall into the subtle distinction between training/experience vs. education/reasoning.  The former, see A, B is the answer.  The latter, learn and understand why B is the answer for A, and perhaps you can figure out, if you see C, what's an answer.

Possibly one early example, when I started to dabble in network engineering, I noticed Cisco devices' egress interface queues seemed (back then) always had a default queue limit of 40.  So, perhaps like OP, maybe a silly question, but why 40?

I recall (?) back then, and even to date, not coming across why 40.  Further, you often come across Cisco documentation saying something along the lines that many default values are chosen with great care and should only be changed with careful consideration.  Lastly, I didn't find much Cisco documentation explaining any "science" in figuring out an optimal queue limit, assuming such exists.

So, (and assuming) we're unable to acquire a why 40 answer from Cisco, do we just go with "well it is what it is"?  Should we avoid any and all speculation because we cannot find the definitive why answer.  (Of course, is we had such an answer, there no need to speculate.)

Unlike the OP question about why VLAN changes are committed when they are, the why 40 question is, I believe, more relevant because, possibly, even if it's an optimal value, knowing why it was chosen may help me to ascertain what my queue limit should be.

Assuming you can see the possible advantage in why the why 40 case might be speculated vs. the VLAN why case, I propose discussing speculation for the latter is valuable to learn the capability to speculate.

In science, creating a theory is speculation too, and you're correct, incorrect speculation can lead to some specular failures, but they can also lead to new wonderful things.

Anyway, I do have my own theory why 40 was chosen.  But it can be totally incorrect, along with some of my assumptions such as it was actually chosen for some reason, and the people choosing it were likely "smart".

For me, creating (what I believe to be) a logical theory why 40 was chosen led to a niche understanding of optimizing network performance that within the subject of QoS, I'm now a legend in my own mind.  ; )