VLAN Filtering

Hello

I've a web link for u

formatting link
here in this page this line is mentioned

Each port is assigned obviously only 1 VLAN ID as it PVID as otherwise it would be impossible to decide to which VLAN to associate the data received.

please explain what it means as more than one per port supported ....

as mentioned in many documents

and in case of primary and secondary vlan case i think for each port which r of secondary vlan than this ports also assigned to primary vlan so that that vlan can be access layer 3 devices (web) as mentioned in rfc 3069 vlan aggregation.

please clerify the point.

Thanks in advance.....

regards

Vikrant

Reply to
vicky
Loading thread data ...

Does RFC 3069 talk about port-based VLANs or IP address-based VLANs? If you set up port-based VLANs, the only way to differentiate between VLANs is the port of the switch.

Think about it. In a port-based situation, is there anything at all in the frames arriving or leaving that port that can be used to differentiate between VLANs? How is this different from 802.1Q or IP address-based VLANs?

Bert

Reply to
Albert Manfredi

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

Should u plz tell me that

m i configure more than one vlan (pvid) in a single port in port based vlan case.

Vik

Reply to
vicky

I've answered that for you before. Multiple port-based VLANs for one port are not part of any standard. Any ability to configure them is switch-dependant and non-standard, and probably indicates a breach of the security model of VLANs (and so should be considered a bug.) If you want a single port to be part of multiple VLANs, then use an 802.1Q trunk port.

You keep trying to find a way to connect VLANs together with only the facilities of a layer 2 switch. A properly designed layer 2 switch will not allow you to connect VLANs together. Indeed, famous conference papers get written when people find implementations that -do- allow VLANs to talk to each other, because it is considered an important security breach.

If you are trying for that old configuration of having a server able to talk to any of the other ports but not have the ports able to talk directly to each other, then you need to use a trunk port for that server, or you need to use some switch-specific facility (outside of any standard) for this purpose.

Reply to
Walter Roberson

Ask yourself this simple question:

Assume port 1 of a switch is made to belong to VLANs A and B, and that these are purely port-based VLANs.

Now the switch receives frames from the end system connected to port

  1. How does the switch know whether those frames belong to VLAN A or VLAN B?

Is there anything in the frames that give the switch a hint?

Bert

Reply to
Albert Manfredi

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

Now Sir can u look at my file which in my shared web folder

formatting link
VLAN Aggregation.txt

here can u please mentioned how the concept of promiscous port and sub vlan concept

as the end users are in different - 2 vlan how they r able to share net by router which is for exp set in default vlan

and please look also in file names as

private-vlan-09.txt

at - 2.1 VLAN Pairings and Their Port-related Characteristics

in the same web file share link given above

how this statement be actually implemented in real.........

Thanks a lot for ur previous replies

Vikrant

Reply to
vicky

Is there anything in the VLAN aggregation or the private VLAN techniques that makes you believe the technique depends on purely port- based VLANs?

Ask yourself again the question I posed last time: In a port-based VLAN, how will the switch know which VLAN a frame belongs to, when it arrives from a host on a given port?

If you can't answer that question, then perhaps these Cisco techniques cannot depend on purely port-based VLANs. There must be SOMETHING in the arriving packet that is used to differentiate between VLANs, more than just the switch port on which the packet arrives. If not the

802.1Q tag, then something else.

Bert

Reply to
Albert Manfredi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.