|
Replies:
2
-
Last Post:
May 11, 2006 7:15 PM
by: yun
|
|
|
Posts:
768
From:
US
Registered:
6/14/05
|
|
|
|
Clearview: PSARC fasttrack for VLAN
observability enhancements (due 5/19)
Posted:
May 10, 2006 10:04 PM
|
|
Hi,
We've drafted a PSARC fasttrack proposing a set of VLAN observability
enhancements needed for Clearview:
http://opensolaris.org/os/project/clearview/vlan_filtering/vlan_psarc.txt
Specifically, it clarifies DLPI semantics in a VLAN environment and how
those semantics will affect snoop behavior. In addition, it proposes a
set of pfmod changes to allow snoop to filter VLAN-tagged packets.
Comments are appreciated. We are setting a timer for comments at one
week (May 19th), at which point we plan to submit to PSARC.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview: PSARC fasttrack for VLAN
observability enhancements (due 5/19)
Posted:
May 11, 2006 11:26 AM
in response to: yun
|
|
> http://opensolaris.org/os/project/clearview/vlan_filtering/vlan_psarc.txt
This is excellent. I think the behavior described is the best way to
handle VLAN headers. I have just a few suggestions on the wording of the
document.
> Note that all VLAN packets have SAP value
> 0x8100. Therefore, we propose that all VLAN packets be sent upstream
> if the stream is in promiscuous mode.
Both of these statements are true only on the physical PPA, not on VLAN
PPAs; this should be made clear somehow. (A VLAN tagged packet actually
has *two* SAPs, one on the physical stream and another on the VLAN
stream.) Also, I'd add the word SAP or DL_PROMISC_SAP to the second
sentence above ("... is in SAP promiscuous mode") just to be perfectly
clear.
> As a result, if snooping on a
> physical link, VLAN tagged packets should be visible if they pass the
> physical-layer filter.
I'd call that "physical address" filter instead of "physical-layer".
> As already discussed, network observation applications (which make use
> of the DL_PROMISC_SAP promiscuity and the DLIOCRAW ioctl) will be
> able to see VLAN packets on physical links, and will not strip the VLAN
> tag in a VLAN packet, even on a VLAN link.
Wording nit: the subject seems to change between the two verb clauses of
this sentence (this case doesn't impact whether *applications* strip VLAN
tags). Maybe s/will not strip/will see/ .
> In theory, VLAN packets are just packets of SAP value 0x8100. They
> are nothing more special than other packets, for example, IP packets.
I'd replace "In theory" with "To the physical link".
One final question: VLANs are often used to implement security domains or
other forms of isolation. The model defined by this case does seem to
allow "leakage" between VLANs if a VLAN link consumer uses raw mode to
transmit a "forged" VLAN header or a packet with no VLAN tag. In the near
future we may be granting DLPI layer access to zones or virtual machines
that are not trusted with full privileges in the global zone/physical
domain. Does this create a problem? Should the VLAN software prevent it?
Should we specify that enforcement now as part of this case? Should we at
least allude to it with a statement like the following?
It is considered an error to request a VLAN link in raw mode to transmit a
packet with an incorrect header (one that specifies some other VLAN) but
the provider interface will not necessarily prevent the transmission or
report an error. Software that needs to transmit on multiple VLANs should
use the physical link or multiple VLAN links as needed.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/14/05
|
|
|
|
Re: Clearview: PSARC fasttrack for VLAN
observability enhancements (due 5/19)
Posted:
May 11, 2006 7:15 PM
in response to: mditto
|
|
Mike,
Thanks for your comments. See inline:
>> Note that all VLAN packets have SAP value
>> 0x8100. Therefore, we propose that all VLAN packets be sent upstream
>> if the stream is in promiscuous mode.
>
> Both of these statements are true only on the physical PPA, not on VLAN
> PPAs; this should be made clear somehow. (A VLAN tagged packet actually
> has *two* SAPs, one on the physical stream and another on the VLAN
> stream.) Also, I'd add the word SAP or DL_PROMISC_SAP to the second
> sentence above ("... is in SAP promiscuous mode") just to be perfectly
> clear.
>
Sure. I will make both clear.
>
>> As a result, if snooping on a
>> physical link, VLAN tagged packets should be visible if they pass the
>> physical-layer filter.
>
> I'd call that "physical address" filter instead of "physical-layer".
In the "Data Link Provider Interface Specification", it is:
"DL_PROMISC_PHYS indicates promiscuous mode at the physical level"
I will change it to physical-level filter to make it consistent with the
specification.
>
>
>> As already discussed, network observation applications (which make use
>> of the DL_PROMISC_SAP promiscuity and the DLIOCRAW ioctl) will be
>> able to see VLAN packets on physical links, and will not strip the VLAN
>> tag in a VLAN packet, even on a VLAN link.
>
> Wording nit: the subject seems to change between the two verb clauses of
> this sentence (this case doesn't impact whether *applications* strip VLAN
> tags). Maybe s/will not strip/will see/ .
>
Today. Some drivers do strip the VLAN tags on a VLAN link even when it
is in raw mode. This case also tries to make this clearly defined.
>> In theory, VLAN packets are just packets of SAP value 0x8100. They
>> are nothing more special than other packets, for example, IP
>> packets.
>
> I'd replace "In theory" with "To the physical link".
>
Okay.
>
> One final question: VLANs are often used to implement security domains or
> other forms of isolation. The model defined by this case does seem to
> allow "leakage" between VLANs if a VLAN link consumer uses raw mode to
> transmit a "forged" VLAN header or a packet with no VLAN tag. In the near
> future we may be granting DLPI layer access to zones or virtual machines
> that are not trusted with full privileges in the global zone/physical
> domain. Does this create a problem? Should the VLAN software prevent it?
> Should we specify that enforcement now as part of this case? Should we at
> least allude to it with a statement like the following?
>
> It is considered an error to request a VLAN link in raw mode to transmit a
> packet with an incorrect header (one that specifies some other VLAN) but
> the provider interface will not necessarily prevent the transmission or
> report an error. Software that needs to transmit on multiple VLANs should
> use the physical link or multiple VLAN links as needed.
>
Thanks. I will add this.
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
