route field

No, there is no necessity for that.

For example, it is possible to build a layer 2 switch in which every port has a dedicated "send" path to each other port (e.g., the wiring to send from port B to port D is completely different than the wiring used to send from port C to port D); and when a packet came in to a port, the port could send the packet literally simultaneously to every other port, and then each output port could discard the packets that are not destined for that output port. No routing information of any kind would have to be kept on such a layer 2 switch, as each output port would independantly decide whether the output packet was to be transmitted or not.

I am not saying that this would be a *good* way to build a layer 2 switch, but your question was about whether there is a *necessity* of having some kind of "route fiele", and my example above demonstrates that it is not *necessary*.

Now, it could potentially be much more *efficient* to have some kind of "route field" in real layer 2 switches -- but it is not *necessary>

Note, by the way, that in networking, the word "route" usually refers to layer 3 information. Unmanaged layer 2 switches do not need to hold any layer 3 information for basic layer 2 operations, so if you are referring to "route" in the layer 3 sense, then the answer is a flat NO. My answer about the hypothetical layer 2 switch was for the case where you might have meant "route field" more generally, such as some kind of internal table that listed MAC addresses and their associated port: my example shows that even that kind of internal table is not *necessary* in a layer 2 switch.

You have been asking a lot of questions about VLANs lately, and one of your questions that I answered recently but which you did not understand (or believe?) my answer gave a scenario in which you were attempting to show that layer 2 switch must have an intra-vlan router in order to provide VLAN connectivity in single- instance STP cases. I suspect that your current question is just a rephrasing of that earlier question, and I will reinforce my answer of that time: if you use a layer 2 switch with VLANs that are restricted to particular ports, and you use a single-instance STP protocol, then your VLAN connectivity *will* break, and the breaking would be the fault of the person that configured the situation, not the fault of the layer 2 switch. Furthermore, there is no requirement that layer 2 switches support VLANs *at all*.

Several times, I have noticed you get confused about the functionality that *must* be supported in -all- layer 2 switches, mixing it up with functionality that needs only to be supported in layer 2 switches that claim to have standard conformance to particular -optional- features.

Can you be more specific in describing what you are asking?

For example, to me it souds like you are asking whether layer 2 connectivity MUST be provided within a mesh of layer 2 switches (bridges).

If that's what you're asking, then it all depends what you want to do. For example, you can simply not connect these switches together at all. Just use them as the hub of a star-topology network, for multiple independent star networks. If you want to allow connectivity among the many star topologies, you simply install layer 3 routers between them, as necessary.

VLANs are supposed to emulate physcially separate LANs, or physically separate catenets (to be more precise). If you build a network of layer 2 switches in which each Ethernet segment belongs to a different VLAN, you are emulating a case of multiple independent, physically disconnected LANs. Your previous example did not permit any communications between the Ethernet LANs at all, at layer 2.

Bert

----------------------------------------------------------------------------=

Thanks a lot sir, for ur wonderful reply, again i m thank ful to u that u noticing my queries ,

Sir according to ur reply i've something to ask .... may i....plz

As u mentioned here about inter-vlan route and one of my query is related to that ..... so the functionality of inter-valn route is provided in l2 switch is only if the switch controller provide some inter-vlan supporting register support or is done without that.

and route field info ia necessary in case of IGMP Snooping ,,, sir wat u say about this.... please ....

Thanks

Vikrant

---------------------------------------------------------------------------=

-----------------------------------

Hi,

Can U plz tell me about Leaky VLAN concept....

plz also provide u'r email-id for further discussion as some of my queries are .... in form of graphics here it is not possible to put that type of queries....

Thanks

Vikrant

Maybe he is asking about CFI + E-RIF support which is not necessary to support. If I remember correctly the standard suggests that packets with CFI should not be supported in modern equipment.

--Kim

--------------------------------------------------------

what is the replacement of CFI to new one can u tell me....

one more thing is the SVL concept is relied as a logical one or it depends on switch controller if it given that one ATU table is supported then is it means that of SVL or what.....

----------------------------------------

what is the mac_service_data_unit what part of frame is it contain

as in IEEE standard of stp and 1q here mentioned this term

The frame_type, mac_action, destination_address, source_address, mac_service_data_unit, user_ priority, and frame_check_sequence

please also tell me

is the sequence of a mac frame is seems to be changed as normally tell the frame as DA, SA, Type, Data, FCS

but here in IEEE stp and 1q the sequence seems from frame type ...

------------------------- plz tell me the description of the

frame_type, mac_action, destination_address, source_address, mac_service_data_unit, user_ priority, and frame_check_sequence

and also tell how a end station make user priority or a host is not vlan aware then also is it able to send priority tagged frames (null VLAN ID).

Thanks

Vikrant

------------------------------

Hello

can u plz clear the meaning of the statemnent of CFI in fddi snap

In a SNAP-encoded tag header transmitted using FDDI MAC methods, CFI has the following meanings:

1) When the frame takes the source-routed form (i.e., the RII bit is set in the frame=92s source MAC Address field and a RIF follows the source MAC Address), the interpretation of the CFI bit is as defined in a) for SNAP-encoded tag headers transmitted using 8802-5 MAC methods. The ERIF field is not present in this form; 2) When the frame takes the transparent form (i.e., the RII bit is reset in the frame=92s source MAC Address field and there is no RIF following the source MAC Address), the interpretation of the CFI bit and the presence or absence of the E-RIF is as defined in b) for Ethernet-encoded tag headers transmitted using 802.3/Ethernet MAC methods.

it is defined in ieee standerd 1q

It's the "data content" part of a MAC frame that is used for the special service frames of the Internal Sublayer Service. So it's not the same frame as used in the normal peer-to-peer MAC service. Clause

6.4 of 802.1Q covers this. For example, this service frame can be used to set the VLAN IDs in a switch, or to check parameters such as MAC_operational or other status parameters of a switch.

Bert

Scratch that first example. I'm not sure the ISS can do that.

Bert

Au contraire, mon frere. The MAC SDU is simply a fancy architectural term for the MAC payload, whether it be for a bridge function client, or a Network layer protocol client.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

---------------------------------------

can u plz tell me about the transparent frame

also of E-RIF ...

sir if 've a file of

ISO/IEC 15802.3

then plz give me a link to down load it for free or send me in my mail id --- snipped-for-privacy@gmail.com

Thanks

Vikrant

--------------------------------------------------------------------

Sir ,

can u give a difference in

transparent frame & source-routed frame

plz give an exp.. regarding of the ethernet / 802.3 frame.

Thanks

Vikrant

---------------------------------------------------------------------------=

Sorry, I would prefer to to conduct these discussions in public. My experience with switches and routers is more practical than theoretical, and is based largely upon older generations of equipment before IGMP and the like was important. As you are asking questions about newer more advanced features, it is better that my answers be in public where the people who know better can correct my mistakes.

Hello Sir,

I 've query but first i write a statement of IEEE 802.1q (1998) of about CFI (canonical format indicator) ...

In an Ethernet-encoded tag header, transmitted using 802.3/Ethernet MAC methods, CFI has the following meanings:

1) When set, indicates that the E-RIF field is present in the tag header, and that the NCFI bit in the RIF determines whether MAC Address information that may be present in the MAC data carried by the frame is in Canonical (C) or Non-canonical (N) format; 2) When reset, indicates that the E-RIF field is not present in the tag header, and that all MAC Address information that may be present in the MAC data carried by the frame is in Canonical format (C).

-------------- Now my query is when the CFI bit is set in case of this ethernet frame. please tell me

Thanks

VIkrant

But then, what happened to the Protocol ID field?

Bert

The CFI bit is not set in the case of Ethernet bridging Ethernet LANs. Ethernet uses canonical address format, therefore:

1. The CFI bit must not be set (i.e. set to 0), and

1. You cannot use so-called "source routing."

On the other hand, if the bridge is "tunneling," or bridging, an FDDI frame from one FDDI LAN to another FDDI LAN, for example, and there are some Ethernet segments between the two FDDI LANs, then the VLAN tag can carry that FDDI "source routing" information. It's a way of allowing frames from different MACs to be bridged, without losing extra header information available in the non-Ethernet LANs.

Here's the note in 802.1Q Clause 9 that explains this:

"NOTE 2=97A decision to use native source-routing on FDDI or to use an embedded routing information field in the VLAN tag depends on local knowledge in a Bridge or end station of the capabilities of the other stations attached to the FDDI LAN. The VLAN tag E-RIF allows source- routing information to be transparently 'tunneled' across LANs that do not support source routing and through MAC Bridges and VLAN-aware Bridges that discard native source-routed frames."

Bert

If by "Protocol ID" field you mean the Ethernet "Type/Length" field, that is NOT part of the payload, and not part of the SDU. It is part of the MAC PDU (Protocol Data Unit, as opposed to Service Data Unit). In general, PDU = SDU + Headers/Trailers at any given layer.

(Note: This equation is somewhat of a simplification, particularly for protocols that perform fragmentation and reassembly of a single SDU into/from multiple PDUs.)

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com