cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1415
Views
30
Helpful
17
Replies

If an L2 switch cannot read VLAN, will the tag exist out of egress?

Hello.

If an L2 switch cannot read VLAN tags, will the VLAN tag still exist when the switch transmits the frame it out it's egress port?

Thank you.

2 Accepted Solutions

Accepted Solutions

balaji.bandi
Hall of Fame
Hall of Fame

The short answer is NO  and it all depends on the config.

You need to provide more information, what device model, IOS code, an example of config, or example of scenarios

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

View solution in original post

To your original question, NIC will consider what it receives either noise or a L2 frame.  If the latter, NIC will check if frame was corrupted or not. If not, L2 will determine if frame is one it supports. If supported, then data, like what's in a VLAN header can be used.

The forgoing means if a VLAN tag cannot be actually read, upon ingress, the whole is corrupt, i.e., nothing to forward.

To the question of when a switch copies/pastes vs building new, that depends upon switch's architecture, often considered proprietary.

Consider frame enters access port and needs to be flooded out other access ports.  Do you physically copy frame, somewhere, to egress queue for each other egress port, or do you pass a pointer to each other egress port?

So, to answer your follow up question, it depends on a particular switch's architecture.

View solution in original post

17 Replies 17

balaji.bandi
Hall of Fame
Hall of Fame

The short answer is NO  and it all depends on the config.

You need to provide more information, what device model, IOS code, an example of config, or example of scenarios

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

This is only a theoretical question. 

Ok, so you say "no"-- I guess that means the switch doesn't simply copy/paste the frame data, but rebuilds a fresh frame for egress, with much of the same data. 

To your original question, NIC will consider what it receives either noise or a L2 frame.  If the latter, NIC will check if frame was corrupted or not. If not, L2 will determine if frame is one it supports. If supported, then data, like what's in a VLAN header can be used.

The forgoing means if a VLAN tag cannot be actually read, upon ingress, the whole is corrupt, i.e., nothing to forward.

To the question of when a switch copies/pastes vs building new, that depends upon switch's architecture, often considered proprietary.

Consider frame enters access port and needs to be flooded out other access ports.  Do you physically copy frame, somewhere, to egress queue for each other egress port, or do you pass a pointer to each other egress port?

So, to answer your follow up question, it depends on a particular switch's architecture.

As an aside, it can be surprising how much information, about how hardware does what it does, can be considered proprietary, even for "things" that very much can impact how well the network device operates in its role.

For example, years ago, PPS rates were often quoted just for 1500 byte packets.  When you asked for PPS rate for 64 byte packets, or other packet sizes, sometimes that information was available.

With switches, if you asked is this switch a blocking or non-blocking architecture, that information, too, might be unavailable.

When the 3750 series came out, I couldn't obtain/find answers to exactly how StackWise operated.  When the 3750E came out, with its StackWise+, Cisco documented how the latter was superior, not only in doubling the bandwidth, but in how the ring traffic was managed (NB: re: managed - major difference; IMO, much, much improved in Plus).

Also little things can sometimes make big differences.  Assume we're passing a VLAN tagged frame from one trunk to another.  Physically we should be able to pass a frame copy, as is.  However, if the switch is enhanced/smart, and we change the CoS value within the VLAN header, i.e. as little as changing one bit, we now have to recalculate the CRCs.  Do we update the VLAN tag in the frame we've stored somewhere in the switch, or do we build a new frame including the revision?

If there are two egress trunk ports, and one should have the CoS change and the other no CoS change, how do we handle that?

Unfortunately, sometimes, not knowing all the capability capacities can come back to haunt you.  When I was at one company, they used best possible hardware options for 7609s.  Wire speed for up to ###.  The fine print didn't make clear, or note, the wire speed was only for unicast.  Company started to push lots and lots (and lots) of multicast through these 7609s, and found hardware could not support anywhere near the same unicast bandwidth capacities.  (To be fair, I suspect possibly even, or most of, Cisco didn't know of the lower bandwidth capacity for multicast.  Probably this was the first company to push such very, very high amounts of multicast.)

Laugh, and for another aside, a situation possibly like no one having ever pushed (or tried to) so much multicast through a 7609, decades ago I was programming on a IBM mainframe, for which, IBM had relatively recently (back then) came out with "XA" (extended addressing - address space increased from 16 MB [of which you might be able to use about 6 MB, for an app] to 2 GB).

Yea!  At the time I was writing an application for which I wanted to use in-memory reference tables, some rather large, like one being 20 MB.  Further, the way I was loading these data tables were as executable program binaries; one of which was 20 MB.

One day, some gossip got back to me, our mainframe was occasionally, all of a sudden, crashing (very unusual for IBM mainframes).  IBM came, found the problem, it was due to, or as quoted to me as "Who the f**k created a 20 MB program binary?"  (NB: back than, a program binary exceeding a single MB was large.)

IBM found they had a bug, and fixed it, which is why the foregoing got back to me only as gossip.  I.e. I wasn't doing anything "wrong" (but certainly seemed to be the first to do this).

@Joseph W. Doherty your reply made me to go back to 15years or more good days..!

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

My understanding is switch cannot read the dot1q tag it won't be able to process the frame and drops the frame. The only time I have seen switch re-write VLAN tags is with Private VLAN promiscuous trunk ports but it's part of the config. 

How sw can not read tag' 

I think you are neaning wrong tag in trunk can lead to forward frame via wrong egress port.

this is a purely theoretical question.

Ohh OK 
the SW cannot read tag if one side config as access and other side config as trunk 
here the access side SW will not read the tag and all frame is forward via VLAN assign to that port.

To be honest I will run lab to check second case. 

Update you when I finish.

Case1
IOU1 access port vlan1 
IOU2 trunk port with native vlan 1 

the frame is flow between the two SW and you see ping is success 
Screenshot (315).png

Case2
the IOU1 access port vlan 1
the IOU2 trunk port native vlan 10 

the ping is failed meaning the IOU2 drop the frame 

 

Screenshot (316).png

In the past, I recall I've setup PT to jump VLANs, like in your case 2, and it worked fine.

Which port on IOU2 is the trunk port (e0/0?)?

Where and how is 10.0.0.2 configured?

For port I talking about port interconnect SW

For 10.0.0.2 I config it with only add ip to interface' there must l2 between two SW.

Review Cisco Networking for a $25 gift card