From sacadmin Tue May 30 07:57:22 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UEvM5S017623 for ; Tue, 30 May 2006 07:57:22 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4UEvLtx010136 for ; Tue, 30 May 2006 07:57:21 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4UEvLTR012972 for ; Tue, 30 May 2006 08:57:21 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0300J012RGXJ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 30 May 2006 08:57:21 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J03002752VKFR40@mail-amer.sun.com>; Tue, 30 May 2006 08:57:21 -0600 (MDT) Date: Tue, 30 May 2006 10:56:46 -0400 From: Sebastien Roy Subject: 2006/358 VLAN Observability Enhancement Sender: Sebastien.Roy@Sun.COM To: psarc Cc: clearview-iteam Message-id: <1149001006.1998.7.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT Status: RO Content-Length: 24198 I'm sponsoring the following fast-track for Cathy Zhou and Dan Groves. The timer expires on June 06, 2006. VLAN Observability Enhancement ============================== Release binding: patch Commitment level: Stable Problem area ============ PSARC 2000/147 introduced VLAN support for Ethernet devices. However, it did not clearly state how or when VLAN packets could be sent or received by DLPI consumers, or how VLAN packets would be accounted by the system. Thus, different network drivers have implemented different semantics, leading to inconsistent or even incorrect behavior. As a result, DLPI-based applications are unable to: a. Monitor all traffic on a given link. Today, snooping on a physical link only reports untagged packets. Customers would like to observe all traffic, including VLAN traffic when snooping over a physical link. b. Observe the VLAN tag inside a tagged packet. Currently, most Solaris network drivers (if not all) strip off the VLAN tag prior to sending the VLAN packets upstream, despite that the stream is in the raw mode. In addition, currently, snoop(1M) does not have the ability to filter on VLAN-tagged packets, which will become a problem if the above issues are addressed. Proposal overview ================= To address the mentioned problem, this case: * clearly defines the semantics of DL_PROMISC_SAP and the DLIOCRAW ioctl, and how they affect network observation behavior in a VLAN environment. * discusses some common network kstats and their semantics in a VLAN environment. * discusses changes made to pfmod(7M) which are necessary for snoop to be able to capture and filter VLAN packets. DL_PROMISC_SAP ============== If a stream enables promiscuous mode at the DL_PROMISC_SAP level, based on its physical-level promiscuous setting, the stream is able to receive packets of all SAP (Ethernet type) values, no matter what SAP it is bound to. Note that to a stream attached to a physical link, all VLAN packets have SAP value 0x8100. Therefore, we propose that all VLAN packets be sent upstream if the physical stream is in DL_PROMISC_SAP promiscuous mode. As a result, if snooping on a physical link, VLAN tagged packets will be visible if they pass the physical-level filter. DLIOCRAW ======== PSARC/2005/626 discussed the DLIOCRAW ioctl semantics in detail: "The DLIOCRAW ioctl function is used by some DLPI applica- tions, most notably the snoop(1M) command. The DLIOCRAW com- mand puts the stream into a raw mode, which, upon receive, causes the the full MAC-level packet to be sent upstream in an M_DATA message instead of it being transformed into the DL_UNITDATA_IND form normally used for reporting incoming packets. Packet SAP filtering is still performed on streams that are in raw mode; if a stream user wants to receive all incoming packets it must also select the appropriate promis- cuous modes. After successfully selecting raw mode, the application is also allowed to send fully formatted packets to the driver as M_DATA messages for transmission. DLIOCRAW takes no arguments. Once enabled, the stream remains in this mode until closed." Specifically in a VLAN environment, we propose: * On the receive-side, streams in the raw mode must send the VLAN tagged packets upstream as they are, without stripping off the VLAN tag from the packets. * On the transmit-side, streams in the raw mode must keep the VLAN tags in the VLAN packets intact before it sends them out on the wire. As a result, if snooping over an network link (either a physical link or a VLAN link), users will see full MAC header of packets, including VLAN tags if they are VLAN packets. Network kstats ============== PSARC/1997/198 discussed some common network kstats and their semantics: kstat name SNMP variable type commitment lvl. multircv ifInMulticastPktsi ui32 evolving brdcstrcv ifInBroadcastPkts ui32 evolving multixmt ifOutMulticastPkts ui32 evolving brdcstxmt ifOutBroadcastPkts ui32 evolving rbytes ifInOctets ui32 evolving norcvbuf ifInDiscards ui32 evolving unknowns ifInUnknownProtos ui32 evolving obytes ifOutOctets ui32 evolving ipackets rsIfInPackets ui32 stable opackets rsIfOutPackets ui32 stable rbytes64 ifHCInOctets ui64 evolving ipackets64 rsIfInPackets ui64 evolving obytes64 ifHCOutOctets ui64 evolving opackets64 rsIfOutPackets ui64 evolving noxmtbuf ifOutDiscards ui32 evolving collisions rsIfCollisions ui32 stable ierrors ifInErrors ui32 stable oerrors ifOutErrors ui32 stable In order to match the observation behavior over a physical network link, for kstats listed above, we propose that VLAN traffic statistics be counted as statistics of a physical network link. pfmod ===== Because of the proposed changes to DLIOCRAW and DL_PROMISC_SAP, snoop will now correctly receive packets with VLAN headers intact. However, snoop is not currently able to capture, filter, or display VLAN packets. Enhancing snoop to capture and display VLAN packets is straightforward, but filtering support requires adding new operations to the pfmod kernel packet filter. Specifically, when possible, snoop filters packets in kernel-space using pfmod, which is an implementation of CMU/Stanford Packet Filter (CSPF). CSPF, as originally designed, is a language for a simple stack machine whose only storage is a stack. Indirection and branching are not supported. Offsets are fixed and must be determined at the time the packet filtering program is generated. There is no provision for indirect addressing in pfmod, or to have variable offsets. Therefore, there is no way to parse variable length headers, headers that may appear after the variable length header, or any other instance of dynamic packet structure. VLAN tagged packets are an instance of a dynamic packet structure because the VLAN header is inserted between the link layer header and the network layer header, thus changing packet structure from the packet structure where there are no VLANs. There is no way to determine, when snoop generates a packet filtering program, if snoop will be filtering on a network that involves VLANs. In order to solve this problem, we will add indirection, forward branching, and extra stack operations to pfmod. * Indirection - pfmod will have extra storage, in the form of an offset register. The offset register will be initialized to zero. The ENF_PUSHWORD instruction will change such that the offset register will be used in determining where to get the data. See the document impact section for details. ENF_PUSHWORD is the only existing instruction whose semantics change. Since the offset register is zero by default, then no user of pfmod will be affected by these changes unless that user makes use of the new instructions. * Forward branching - Two forward branching instructions, ENF_BRFL and ENF_BRTR, will be added. It will not be possible for these branches to go backwards in order to protect against a malicious user causing an infinite loop in the kernel. See document impact section for more details on the instructions. * Extra stack operations - A pop operation is added to pfmod. The pop operation exists to remove an element from the stack without performing any operations on it. These three things combined give us the ability to generate programs that can detect if a packet has a VLAN header, and then to change the offsets it uses. More details, along with background information can be found in the documents on the OpenSolaris Clearview project page for VLAN filtering at: http://www.opensolaris.org/os/project/clearview/vlan_filtering/ Application impact =================== * Network observation applications 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. Note that an application may use DLIOCRAW to transmit packets with incorrect or absent VLAN headers, which can be used to cause packets to "leak" between VLAN's. Therefore, it is considered an error to attempt to transmit packets with link headers with incorrect VLAN IDs through VLAN streams, and DLPI providers will prevent such transmission and drop the packets. Applications that need to transmit on multiple VLANs should either use the physical link or multiple VLAN links. Third party network observation tools that depend on libpcap (such as tcpdump and ethereal) will not be affected by the changes to pfmod. Libpcap is a wrapper around whatever packet capture or packet filtering facilities are provided by the native operating system. The current version of libpcap does not make use of pfmod on Solaris. Libpcap on Solaris uses bufmod to pull packets into user space and then relies on a user space implementation of Berkeley Packet Filter (BPF) to perform filtering operations. Users that use libpcap-based packet capture tools such as tcpdump and ethereal will need to include a vlan expression in their packet filtering expression if they are filtering on a VLAN configured interface. Otherwise, their packet filtering expressions will not correctly capture VLAN tagged packets. Third party tools that make use of pfmod will find that their current programs will continue to work, and if used in an environment without VLAN tagged packets, will continue to behave the same way. If there are VLAN tagged packets on the network, depending on what the third party tool is using pfmod to detect (i.e. IP packets on the network) the tool might have to change to generate pfmod programs that take advantage of the changes to pfmod to behave correctly. * MIB-II consumers PSARC/1997/198 declared that the listed set of network kstats were suitable for use for MIB-II purposes. As a result, MIB-II consumer (applications like netstat and the SNMP daemon) are gathering information by reading these network statistics. But that PSARC case didn't clearly define the semantics of these kstats in a VLAN environment. There are concerns that those MIB-II consumers might assume the kstats of a physical link only represent the non-VLAN view of the statistics, and if it represents a composite view of both VLAN tagged statistics and untagged statistics, it may cause problem. An option is to introduce another set of "physical kstats" to count both VLAN and non-VLAN traffic and and keep the current set of kstats to only count non-VLAN traffic. But we decide to make the above network kstats represent both VLAN and non-VLAN statistics for several reasons: - The characteristic of VLAN packets To the physical link, VLAN packets are just packets with SAP value 0x8100. They are no more special than other packets, for example, IP packets. - Consistency among network drivers Note that legacy network drivers -- even those that support VLANs -- use the same network kstats for both VLAN and non-VLAN traffic. Thus, if we changed the kstat semantics to only count non-VLAN traffic, the result would be inconsistent semantics unless the legacy drivers were also updated. However, it is not feasible to track down and modify all legacy drivers since many are owned by third parties. Indeed, a design goal of Nemo Unification (http://www.opensolaris.org/os/project/clearview/uv-design.pdf) is to provide the VLAN support without changing legacy drivers. In addition, we believe that the above also proves that the MIB-II consumers will not be affected by our proposed kstats semantics. - Consistency between "dladm" and "netstat" The "dladm show-link -s" command is used to display network statistics of each link. The statistics it reports include both VLAN and non-VLAN statistics. Presenting different view by "dladm show-link -s" and "netstat -i" will only cause confusion. * pfmod consumers The only pfmod consumers in the OS/Net consolidation are dhcpagent, in.dhcpd, and snoop. Dhcpagent and in.dhcpd are bound to ETHERTYPE_IP and ETHERTYPE_ARP, and so should require no changes. Snoop will change to generate pfmod programs using the new features so that it will continue to work correctly in a VLAN environment. The semantics of snoop's ethertype expression will change so that any existing customer scripts will continue to capture the same packets. The man page changes for the ethertype expression are listed in the document impact section. Network driver impact ===================== We will coordinate to update all Sun supported drivers to adhere to this proposal. Note that the behavior changes we propose only affect network drivers that support VLANs: - The clearview team will change both GLDv2 and GLDv3 to make sure drivers written to the GLD framework work correctly. - SSG/NSN is already aware of this proposal and they will change the ce driver accordingly (bug 4722784). - We are not aware of any third-party monolithic drivers that have VLAN support. Document impact =============== * dlpi(7P) - Evolving As VLAN is DL_ETHER specific, a media type specific subsection will be added into the dlpi(7P) manpage. Below are proposed context diffs. Note that in order to make the manpage clear, the proposed manpage changes include both the behavior specified (but never documented) by PSARC 2000/147 and the new behavior proposed by this new case. The parts are new with this case are marked with the changebars on the right: *** dlpi.origin.text Fri Apr 21 17:12:24 2006 --- dlpi.new.text Mon May 8 14:48:41 2006 *************** *** 317,323 **** --- 317,383 ---- this mode until closed. + DL_ETHER SPECIFIC DLPI SEMANTICS + VLAN Support + + VLAN PPA Access + + Some DL_ETHER DLPI providers support IEEE 802.1Q Virtual + LANs (VLANs). For these providers, traffic for a particu- + lar VLAN can be accessed by attaching to (or opening) a + special VLAN PPA that is calculated from the VLAN ID and + the actual hardware PPA of the device. This VLAN PPA is + calculated by multiplying the VLAN ID by 1000 and adding + the hardware PPA. For instance, VLAN PPA 2001 provides + access to VLAN ID 2 on hardware PPA 1. As with hardware + PPA's, a DLPI provider may provide either or both + DL_STYLE1 or DL_STYLE2 access to a given VLAN PPA, and + portable DLPI consumers must try both DLPI styles before + concluding that a DL_ETHER DLPI provider does not offer + VLAN support. + + Unless raw mode is enabled, a DLPI stream bound to a VLAN + PPA behaves no differently than a traditional DLPI stream. + In particular, as with hardware PPAs, data must be sent + to a DLPI provider without any link-layer headers (which + will then be added by the provider), and received data + will be passed to interested DLPI consumers without any + link-layer headers. Thus, DLPI consumers do not require + special-case logic to make use of VLAN PPAs. + + However, if raw mode is enabled, then the complete, unmo- | + dified MAC-level packet -- including Ethernet and VLAN | + headers -- will be passed to interested DLPI consumers. | + Similarly, the entire MAC-level packet -- including Ether- | + net and VLAN headers -- must be sent to the DLPI provider | + for transmission. Note that if a DLPI consumer attempts to | + transmit a packet through a VLAN but the packet does not | + have the correct VLAN ID, the DLPI provider must prevent | + such transmission and drop the packet. | + + Hardware PPA Access + + As per IEEE 802.1Q, all VLAN traffic is sent using Ether- + Type 0x8100. As such, in addition to attaching to the VLAN + PPA, all VLAN traffic for a given hardware PPA can also be + accessed by attaching to the hardware PPA and binding to + SAP 0x8100. In this case, all VLAN traffic, regardless of + VLAN ID, can be sent and received by the DLPI consumer. + However, even when raw mode is disabled, packets will be + received starting with their VLAN headers, and must be sent + to the DLPI provider with their VLAN headers already pre- + pended (but without Ethernet headers). Because adhering to + these semantics requires each DLPI consumer to have specia- + lized knowledge of VLANs, VLANs should only be accessed in + this manner when the VLAN PPA access method is insufficient + (e.g., because access to all VLAN traffic, regardless of + VLAN ID, is needed). + + Further, since all VLAN traffic is sent with SAP 0x8100, if | + a DLPI consumer enables promiscuous mode of a stream at the | + DL_PROMISC_SAP level, all VLAN traffic that was not fil- | + tered at the physical (DL_PROMISC_PHYS) level will also be | + visible. As before, these packets will also be received | + starting with their VLAN headers if raw mode is not enabled. | + FILES Files in or under /dev. * pfmod(7M) Below are proposed context diffs of pfmod(7M) manpage: *** pfmod.original.text Thu Apr 6 12:42:01 2006 --- pfmod.new.text Tue May 9 08:52:32 2006 *************** *** 104,122 **** (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords"). Each shortword of the command list ! specifies one of the actions ENF_PUSHLIT, ENF_PUSHZERO, ! ENF_PUSHONE, ENF_PUSHFFFF, ENF_PUSHFF00, ENF_PUSH00FF, or ! ENF_PUSHWORD+n, which respectively push the next shortword ! of the command list, zero, one, 0xFFFF, 0xFF00, 0x00FF, or ! shortword n of the subject message on the stack, and a ! binary operator from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which then ! operates on the top two elements of the stack and replaces ! them with its result. When both an action and operator are ! specified in the same shortword, the action is performed ! followed by the operation. The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the --- 104,139 ---- (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords") or an offset register. The offset ! register is initially zero. Each shortword of the command ! list specifies an action and a binary operator. Using _n_ as ! shorthand for the next shortword of the instruction stream and ! _%oreg_ for the offset register, the list of actions is: ! COMMAND SHORTWORDS ACTION ! ENF_PUSHLIT 2 Push _n_ on the stack. ! ENF_PUSHZERO 1 Push zero on the stack. ! ENF_PUSHONE 1 Push one on the stack. ! ENF_PUSHFFFF 1 Push 0xFFFF on the stack. ! ENF_PUSHFF00 1 Push 0xFF00 on the stack. ! ENF_PUSH00FF 1 Push 0x00FF on the stack. ! ENF_LOAD_OFFSET 2 Load _n_ into _%oreg_. ! ENF_BRTR 2 Branch forward _n_ shortwords if ! the top element of the stack is ! non-zero. ! ENF_BRFL 2 Branch forward _n_ shortwords if ! the top element of the stack is zero. ! ENF_POP 1 Pop the top element from the stack. ! ENF_PUSHWORD+m 1 Push the value of shortword (_m_ + ! _%oreg_) of the packet onto the stack. ! ! The binary operators can be from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which ! operate on the top two elements of the stack and replace ! them with its result. + When both an action and operator are specified in the same + shortword, the action is performed followed by the operation. + The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the *************** *** 186,192 **** The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. struct ether_header eh; /* used only for offset values */ --- 203,210 ---- The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. The filter ! will work whether or not a VLAN is configured. struct ether_header eh; /* used only for offset values */ *************** *** 222,227 **** --- 240,254 ---- sizeof (us_short); *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_EQ; + *fwp++ = ENF_BRFL; + *fwp++ = 3; /* If this isn't ethertype VLAN, don't change oreg */ + *fwp++ = ENF_LOAD_OFFSET; + *fwp++ = 2; /* size of the VLAN tag in words */ + *fwp++ = ENF_POP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT; *fwp++ = htons(ETHERTYPE_REVARP); *fwp++ = ENF_EQ; pf.Pf_FilterLen = fwp - &pf.Pf_Filter[0]; *************** *** 232,237 **** --- 259,272 ---- *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT | ENF_EQ; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_BRFL | ENF_NOP; + *fwp++ = 3; + *fwp++ = ENF_LOAD_OFFSET | ENF_NOP; + *fwp++ = 2; + *fwp++ = ENF_POP | ENF_NOP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT | ENF_EQ; *fwp++ = htons(ETHERTYPE_REVARP); * snoop(1M) Below are the proposed man page diffs for snoop. *** snoop.old.txt Tue May 23 13:39:13 2006 --- snoop.new.txt Tue May 23 16:30:09 2006 *************** *** 450,457 **** ethertype number ! True if the ethernet type field has value number. ! Equivalent to "ether[12:2] = number". --- 450,459 ---- ethertype number ! True if the Ethernet type field has value number. ! If number is not 0x8100 (VLAN) and the packet is ! VLAN tagged, then the expression will match the ! encapsulated Ethernet type. From sacadmin Tue May 30 10:17:15 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UHHFjV024599 for ; Tue, 30 May 2006 10:17:15 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4UHHmF9020230; Tue, 30 May 2006 13:17:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4UHHltA020227; Tue, 30 May 2006 13:17:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17532.32313.514080.184415@gargle.gargle.HOWL> Date: Tue, 30 May 2006 13:17:45 -0400 From: James Carlson To: Sebastien Roy Cc: psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Sebastien Roy's message of 30 May 2006 10:56:46 References: <1149001006.1998.7.camel@localhost> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3957 Sebastien Roy writes: > DLIOCRAW > ======== [...] > * On the transmit-side, streams in the raw mode must keep the VLAN tags > in the VLAN packets intact before it sends them out on the wire. How does a DLIOCRAW user find out what VLAN ID is in use on the stream so that he can construct the proper transmit-side bits? Is he required to parse the PPA-hack in the interface name? > Network kstats > ============== [...] > In order to match the observation behavior over a physical network > link, for kstats listed above, we propose that VLAN traffic statistics > be counted as statistics of a physical network link. I couldn't quite figure out what that meant. I *think* it means something like this: The kstats will be for the physical network link. Thus, the counters represent a sum of tagged (VLAN) and untagged packets on the wire. No separate VLAN-specific statistics are gathered. Is that correct? > Application impact > =================== [...] > 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. Just as a check: what exactly do libpcap users see here? Is there a chance that libpcap users get hurt? (I'm specifically worred about applications like ISC's DHCP.) > Users that use libpcap-based packet capture tools such as tcpdump and > ethereal will need to include a vlan expression in their packet filtering > expression if they are filtering on a VLAN configured interface. They don't "need" to do this, right? Things should just "work right" for ethereal users attaching to the VLAN (PPA-hack) nodes on the system, with no special configuration required. For those using the raw physical link, they _might_ need to set up VLAN filters, depending on what it is they're expecting (and wanting) to see. Do I have that right? Or is changing filter expressions a new _requirement_ for users? > Otherwise, their packet filtering expressions will not correctly capture > VLAN tagged packets. "Not correctly?" I hope this just means that existing filtering expressions will end up matching traffic on all VLANs, and not that it'll just start malfunctioning arbitrarily. > * MIB-II consumers I'm somewhat surprised that this section doesn't reference the RFCs (particularly 1573), which make it fairly clear that the interface statistics for MIB-II refer to the physical interface itself, and not virtual abstractions like 'circuits' or 'vlans.' To get VLAN usage information, you need either interface stacking (RFC 2233) or RMON (RFC 2613) extensions, and I don't think Solaris supports either. > - Consistency between "dladm" and "netstat" > > The "dladm show-link -s" command is used to display network > statistics of each link. The statistics it reports include both > VLAN and non-VLAN statistics. "include both?" Does this mean that just the sum is shown (meaning that separate statistics are _not_ kept for VLAN traffic), or that the output includes separate information for each? > * pfmod consumers [...] > Dhcpagent and in.dhcpd are bound to ETHERTYPE_IP and ETHERTYPE_ARP, > and so should require no changes. The important part is that they're not using DLIOCRAW, and not just how they're bound, correct? Missing from this list: mipagent. It seems to use DLIOCRAW. > Network driver impact > ===================== [...] > - We are not aware of any third-party monolithic drivers that have > VLAN support. Syskonnect Ethernet cards seem to support VLANs on Solaris. Aren't these monolithic? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue May 30 11:37:12 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UIbBLw029215 for ; Tue, 30 May 2006 11:37:12 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4UIbAao002213; Tue, 30 May 2006 14:37:10 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UIbAgK009562; Tue, 30 May 2006 14:37:10 -0400 (EDT) Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: Sebastien Roy Cc: psarc , clearview-iteam In-Reply-To: <1149001006.1998.7.camel@localhost> References: <1149001006.1998.7.camel@localhost> Content-Type: text/plain Message-Id: <1149014229.7961.153.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Tue, 30 May 2006 14:37:10 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1817 On Tue, 2006-05-30 at 10:56, Sebastien Roy wrote: > Specifically in a VLAN environment, we propose: > > * On the receive-side, streams in the raw mode must send the VLAN > tagged packets upstream as they are, without stripping off the > VLAN tag from the packets. > > * On the transmit-side, streams in the raw mode must keep the VLAN tags > in the VLAN packets intact before it sends them out on the wire. > > As a result, if snooping over an network link (either a physical > link or a VLAN link), users will see full MAC header of packets, > including VLAN tags if they are VLAN packets. I find this part of the proposal at least somewhat surprising -- not necessarily *wrong* but not what I would have expected. Here's the behavior I would have expected: DLIOCRAW access on an untagged link (e.g., bge0) sees everything from all vlans. DLIOCRAW access on a stream open on a VLAN link (e.g., bge2000 -- bge0 tag 2) behaves as if a virtual vlan bridge/switch were interposed on the link which: - on inbound, filters out all but tag 2, and removes the tag (but not the preceding ethernet header) - tags outbound frames with tag 2 Consider a situation where you have a switch with an uplink with N tagged vlans on it, and a bunch of downstream ports, one per vlan. If several of those ports were connected to different physical ports on a solaris server, i'd expect to be able to take the switch out of the picture and consolidate them into a single physical connection, with each vlan on that link broken out into a device which behaves almost exactly like the physical port version, replacing bge1, bge2, bge3, ... with bge1000, bge2000, bge3000, ... With your proposal, the application opening bge1000 in raw mode must be made vlan-aware.. - Bill From sacadmin Tue May 30 12:31:33 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UJVXMN001741 for ; Tue, 30 May 2006 12:31:33 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4UJW6JW029285; Tue, 30 May 2006 15:32:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4UJW5GU029282; Tue, 30 May 2006 15:32:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17532.40371.309440.557610@gargle.gargle.HOWL> Date: Tue, 30 May 2006 15:32:03 -0400 From: James Carlson To: Bill Sommerfeld Cc: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Bill Sommerfeld's message of 30 May 2006 14:37:10 References: <1149001006.1998.7.camel@localhost> <1149014229.7961.153.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 903 Bill Sommerfeld writes: > DLIOCRAW access on a stream open on a VLAN link (e.g., bge2000 -- bge0 > tag 2) behaves as if a virtual vlan bridge/switch were interposed on the > link which: > > - on inbound, filters out all but tag 2, and removes the tag > (but not the preceding ethernet header) > - tags outbound frames with tag 2 Agreed. One trivial refinement: if the priority bits are non-zero, then the reserved (dummy) tag 0 is used to encode priority alone. > With your proposal, the application opening bge1000 in raw mode must be > made vlan-aware.. Right ... it seems a bit strange, and counter-intuitive, but I can't point to a specific reason why it's _wrong_. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue May 30 15:00:55 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UM0tWR008137 for ; Tue, 30 May 2006 15:00:55 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4UM0nsf359317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 May 2006 15:00:53 -0700 (PDT) Message-ID: <447CC090.4030702@sun.com> Date: Tue, 30 May 2006 15:00:48 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Sebastien Roy CC: psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> In-Reply-To: <1149001006.1998.7.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1532 Sebastien Roy wrote: > Problem area > ============ > > PSARC 2000/147 introduced VLAN support for Ethernet devices. However, > it did not clearly state how or when VLAN packets could be sent or > received by DLPI consumers, or how VLAN packets would be accounted by > the system. Thus, different network drivers have implemented different > semantics, leading to inconsistent or even incorrect behavior. As a > result, DLPI-based applications are unable to: > > a. Monitor all traffic on a given link. > > Today, snooping on a physical link only reports untagged packets. > Customers would like to observe all traffic, including VLAN traffic > when snooping over a physical link. > > b. Observe the VLAN tag inside a tagged packet. > > Currently, most Solaris network drivers (if not all) strip off > the VLAN tag prior to sending the VLAN packets upstream, despite > that the stream is in the raw mode. > > In addition, currently, snoop(1M) does not have the ability to filter > on VLAN-tagged packets, which will become a problem if the above > issues are addressed. I don't have a problem with making those additional capabilities available, but I also want there to be a uniform way (independent of the device driver) to observe a particular VLAN. For instance what I get with bge today, where a snoop on bge1000 shows packets just for that VLAN. I can't tell from the description whether and how that will be provided. Erik From sacadmin Tue May 30 21:39:15 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4V4dEc5018709 for ; Tue, 30 May 2006 21:39:15 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4V4d87h019360 for ; Wed, 31 May 2006 12:39:08 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400A014VZMB00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 12:39:08 +0800 (SGT) Received: from [129.158.219.168] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04003MA4X75CFF@mail-apac.sun.com>; Wed, 31 May 2006 12:39:08 +0800 (SGT) Date: Wed, 31 May 2006 10:35:17 +0800 From: Darren Reed Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17532.40371.309440.557610@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: James Carlson Cc: Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <447D00E5.9020004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1149001006.1998.7.camel@localhost> <1149014229.7961.153.camel@thunk> <17532.40371.309440.557610@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1598 James Carlson wrote: >Bill Sommerfeld writes: > >>DLIOCRAW access on a stream open on a VLAN link (e.g., bge2000 -- bge0 >>tag 2) behaves as if a virtual vlan bridge/switch were interposed on the >>link which: >> >> - on inbound, filters out all but tag 2, and removes the tag >> (but not the preceding ethernet header) >> - tags outbound frames with tag 2 >> > >Agreed. One trivial refinement: if the priority bits are non-zero, >then the reserved (dummy) tag 0 is used to encode priority alone. > > >>With your proposal, the application opening bge1000 in raw mode must be >>made vlan-aware.. >> > >Right ... it seems a bit strange, and counter-intuitive, but I can't >point to a specific reason why it's _wrong_. > The framing of the ethernet VLAN packet doesn't really help here. If the tag were at the start of the ethernet frame, it'd be more intuitive to drop it off, but as it is, it is further in. And if the above is done then the "Application Impact" for third party tools is significantly lessened, specifically, this should be eliminated: " Users that use libpcap-based packet capture tools such as tcpdump and ethereal will need to include a vlan expression in their packet filtering expression if they are filtering on a VLAN configured interface. Otherwise, their packet filtering expressions will not correctly capture VLAN tagged packets." Otherwise, use would be: tcpdump -i bge2000 vlan and ip ...needing to say "vlan and" seems somehow redundant. And as far as I can tell, there is no way to tell a device is actually a VLAN, apart from its name? Darren From sacadmin Tue May 30 22:56:51 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4V5uoYf021121 for ; Tue, 30 May 2006 22:56:50 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4V5uibw029693 for ; Wed, 31 May 2006 13:56:44 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400C018HUK800@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 13:56:44 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04003GO8II5DF4@mail-apac.sun.com>; Wed, 31 May 2006 13:56:44 +0800 (SGT) Date: Wed, 31 May 2006 13:56:42 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17532.32313.514080.184415@gargle.gargle.HOWL> Sender: Cathy.Zhou@Sun.COM To: James Carlson Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447D301A.6000201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 4092 James Carlson wrote: > Sebastien Roy writes: >> DLIOCRAW >> ======== > [...] >> * On the transmit-side, streams in the raw mode must keep the VLAN tags >> in the VLAN packets intact before it sends them out on the wire. > > How does a DLIOCRAW user find out what VLAN ID is in use on the stream > so that he can construct the proper transmit-side bits? Is he > required to parse the PPA-hack in the interface name? > That's a possible way. But I just read Bill's mail and unless there are other problems I am not aware of, I tends to agree with him - that packets sent on a raw VLAN stream will not have the VLAN tag, instead the driver will insert the VLAN tag into the packets. Symmetrically, on the receive side, only packets with the correct VID will be passed up to a raw VLAN stream, and the VLAN tag will be removed. The receive side behavior was actually our initial reason that we proposed to make the VLAN tag intact - we think that it provides more observability so that applications like snoop can see exactly what the packets look like on the wire. >> Network kstats >> ============== > [...] >> In order to match the observation behavior over a physical network >> link, for kstats listed above, we propose that VLAN traffic statistics >> be counted as statistics of a physical network link. > > I couldn't quite figure out what that meant. I *think* it means > something like this: > > The kstats will be for the physical network link. Thus, the > counters represent a sum of tagged (VLAN) and untagged packets > on the wire. No separate VLAN-specific statistics are > gathered. > > Is that correct? > Not exactly. These kstats are also for VLANs. Even today, user can run "kstat -n bge3002" to see the statistics of VLAN3 on bge2. If I understand you correctly, we do not support corresponding SNMP variables for VLANs. (which I don't know whether in reality it is understood well, as I was just looking at a VLAN snmpwalk bug - see 6313901). But what we are proposing is not really relevant to VLAN SNMP variables: we are proposing to change the semantics of kstats for physical network link to include VLAN traffic. VLAN SNMP variables will not change by this case. >> * MIB-II consumers > > I'm somewhat surprised that this section doesn't reference the RFCs > (particularly 1573), which make it fairly clear that the interface > statistics for MIB-II refer to the physical interface itself, and not > virtual abstractions like 'circuits' or 'vlans.' > > To get VLAN usage information, you need either interface stacking (RFC > 2233) or RMON (RFC 2613) extensions, and I don't think Solaris > supports either. > See above. >> - Consistency between "dladm" and "netstat" >> >> The "dladm show-link -s" command is used to display network >> statistics of each link. The statistics it reports include both >> VLAN and non-VLAN statistics. > > "include both?" > > Does this mean that just the sum is shown (meaning that separate > statistics are _not_ kept for VLAN traffic), or that the output > includes separate information for each? > Sorry that I didn't make it clear. show-link -s will give statistics information for both physical link and VLAN link. An example output will look below: ipackets rbytes ierrors opackets obytes oerrors e1000g0 15095 4880777 0 10255 1158985 e1000g1000 22 1970 0 60 4098 0 Note that the statistics information of VLAN e1000g1000 is kept and displayed separately. But the first line (for e1000g0) includes both untagged traffic and VLAN traffic of e1000g1000. >> Network driver impact >> ===================== > [...] >> - We are not aware of any third-party monolithic drivers that have >> VLAN support. > > Syskonnect Ethernet cards seem to support VLANs on Solaris. Aren't > these monolithic? > Thanks for pointing it out. Is it possible that we can access its code and see whether it is monolithic and how this proposal will affect it? Thanks again - Cathy From sacadmin Tue May 30 23:03:51 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4V63oJK021161 for ; Tue, 30 May 2006 23:03:51 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4V63ibw000274 for ; Wed, 31 May 2006 14:03:44 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400G018RZCL00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 14:03:44 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04003B98U75DG4@mail-apac.sun.com>; Wed, 31 May 2006 14:03:44 +0800 (SGT) Date: Wed, 31 May 2006 14:03:43 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <1149014229.7961.153.camel@thunk> Sender: Cathy.Zhou@Sun.COM To: Bill Sommerfeld Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447D31BF.2020206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <1149014229.7961.153.camel@thunk> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 1206 > Here's the behavior I would have expected: > > DLIOCRAW access on an untagged link (e.g., bge0) sees everything from > all vlans. > > DLIOCRAW access on a stream open on a VLAN link (e.g., bge2000 -- bge0 > tag 2) behaves as if a virtual vlan bridge/switch were interposed on the > link which: > > - on inbound, filters out all but tag 2, and removes the tag > (but not the preceding ethernet header) > - tags outbound frames with tag 2 > > Consider a situation where you have a switch with an uplink with N > tagged vlans on it, and a bunch of downstream ports, one per vlan. > > If several of those ports were connected to different physical ports on > a solaris server, i'd expect to be able to take the switch out of the > picture and consolidate them into a single physical connection, with > each vlan on that link broken out into a device which behaves almost > exactly like the physical port version, replacing bge1, bge2, bge3, ... > with bge1000, bge2000, bge3000, ... > > With your proposal, the application opening bge1000 in raw mode must be > made vlan-aware.. > Like I mentioned in the reply to James, I agree with you on this. I will make changes accordingly. Thanks - Cathy From sacadmin Wed May 31 00:22:11 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4V7MANP012930 for ; Wed, 31 May 2006 00:22:11 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4V7M5bw006543 for ; Wed, 31 May 2006 15:22:05 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400M01CC9DC00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 15:22:05 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04003T1CGR5C0G@mail-apac.sun.com>; Wed, 31 May 2006 15:22:05 +0800 (SGT) Date: Wed, 31 May 2006 15:22:03 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <447D301A.6000201@sun.com> Sender: Cathy.Zhou@Sun.COM To: James Carlson Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447D441B.6090500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447D301A.6000201@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 413 >> Syskonnect Ethernet cards seem to support VLANs on Solaris. Aren't >> these monolithic? >> > Thanks for pointing it out. Is it possible that we can access its code > and see whether it is monolithic and how this proposal will affect it? Sorry that I wasn't intentionally ignoring your other questions, I thought Dan has replied them and I will let Dan answer your pfmod related questions. Thanks - Cathy From sacadmin Wed May 31 06:39:42 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VDdf4p003027 for ; Wed, 31 May 2006 06:39:41 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4VDeF6Z001835; Wed, 31 May 2006 09:40:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4VDeEGY001832; Wed, 31 May 2006 09:40:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.40125.494038.418097@gargle.gargle.HOWL> Date: Wed, 31 May 2006 09:40:13 -0400 From: James Carlson To: Darren Reed Cc: Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Darren Reed's message of 31 May 2006 10:35:17 References: <1149001006.1998.7.camel@localhost> <1149014229.7961.153.camel@thunk> <17532.40371.309440.557610@gargle.gargle.HOWL> <447D00E5.9020004@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1116 Darren Reed writes: > >Agreed. One trivial refinement: if the priority bits are non-zero, > >then the reserved (dummy) tag 0 is used to encode priority alone. [...] > The framing of the ethernet VLAN packet doesn't really help here. See the above. It helps in the narrow case where you want to grab the priority bits, which are in the same header as the VLAN tag. > Otherwise, use would be: > > tcpdump -i bge2000 vlan and ip > > ...needing to say "vlan and" seems somehow redundant. Yes. It's also not clear from the proposal whether this is actually _necessary_ for it to continue working, or if it's merely one of the things the user _could_ do. > And as far as I can tell, there is no way to tell a device > is actually a VLAN, apart from its name? Also one of my comments ... I asked about how the application gets the VLAN ID that it must use when doing writes with DLIOCRAW. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 31 06:55:12 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VDtB9G003792 for ; Wed, 31 May 2006 06:55:11 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4VDtjod001854; Wed, 31 May 2006 09:55:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4VDtigu001851; Wed, 31 May 2006 09:55:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.41056.12914.940235@gargle.gargle.HOWL> Date: Wed, 31 May 2006 09:55:44 -0400 From: James Carlson To: Cathy Zhou Cc: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Cathy Zhou's message of 31 May 2006 13:56:42 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447D301A.6000201@sun.com> <447D441B.6090500@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 4830 Cathy Zhou writes: > > How does a DLIOCRAW user find out what VLAN ID is in use on the stream > > so that he can construct the proper transmit-side bits? Is he > > required to parse the PPA-hack in the interface name? > > > > That's a possible way. But I just read Bill's mail and unless there are > other problems I am not aware of, I tends to agree with him - that > packets sent on a raw VLAN stream will not have the VLAN tag, instead > the driver will insert the VLAN tag into the packets. Symmetrically, on > the receive side, only packets with the correct VID will be passed up to > a raw VLAN stream, and the VLAN tag will be removed. This makes more sense to me; thanks. > The receive side behavior was actually our initial reason that we > proposed to make the VLAN tag intact - we think that it provides more > observability so that applications like snoop can see exactly what the > packets look like on the wire. Indeed it does, but it also raises other questions. > >> Network kstats > >> ============== [...] > > The kstats will be for the physical network link. Thus, the > > counters represent a sum of tagged (VLAN) and untagged packets > > on the wire. No separate VLAN-specific statistics are > > gathered. > > > > Is that correct? > > > > Not exactly. These kstats are also for VLANs. Even today, user can run > "kstat -n bge3002" to see the statistics of VLAN3 on bge2. What precisely does the user see if he asks for "kstat -n bge2"? Do these counters include VLAN-tagged packets or not? I believe the answer is that they do, but I can't tell from the original proposal. Now it sounds like you're saying that there are also per-VLAN statistics, using the ppa-hack for a naming scheme, but just not untagged statistics. If someone needs a count of untagged packets, he'll need to get "kstat -n bge2" and then subtract off each of "kstat -n bge1002" through "kstat -n bge4094002." Is that right? > If I > understand you correctly, we do not support corresponding SNMP variables > for VLANs. (which I don't know whether in reality it is understood well, > as I was just looking at a VLAN snmpwalk bug - see 6313901). I don't see any stacking information here, so it looks like users are just on their own to figure out what the numbers mean. > But what we are proposing is not really relevant to VLAN SNMP variables: > we are proposing to change the semantics of kstats for physical network > link to include VLAN traffic. VLAN SNMP variables will not change by > this case. Now I'm completely confused. The kstats here are _designed_ for SNMP support. See PSARC 1997/198. How could it be that the kstats change, but the SNMP variables don't change? > > Does this mean that just the sum is shown (meaning that separate > > statistics are _not_ kept for VLAN traffic), or that the output > > includes separate information for each? > > > Sorry that I didn't make it clear. show-link -s will give statistics > information for both physical link and VLAN link. An example output will > look below: > > ipackets rbytes ierrors opackets obytes oerrors > e1000g0 15095 4880777 0 10255 1158985 > e1000g1000 22 1970 0 60 4098 0 > > Note that the statistics information of VLAN e1000g1000 is kept and > displayed separately. But the first line (for e1000g0) includes both > untagged traffic and VLAN traffic of e1000g1000. OK. That's what I was trying to get at. e1000g0 there gives an accurate count of the packets on the wire, and has nothing to do with VLANs. That sounds like the right answer. > >> Network driver impact > >> ===================== > > [...] > >> - We are not aware of any third-party monolithic drivers that have > >> VLAN support. > > > > Syskonnect Ethernet cards seem to support VLANs on Solaris. Aren't > > these monolithic? > > > Thanks for pointing it out. Is it possible that we can access its code > and see whether it is monolithic and how this proposal will affect it? I don't have one of these things. You'll need to find someone who does. I'm sure it's possible to determine some general things (such as whether it's GLD or monolithic) from the binary alone, and it looks like their web site has drivers. (Ignoring for the moment any legal concerns about software download, and inspecting binaries.) I doubt that we can get source access, but it might be worth asking the vendor. Oddly, hardware vendors seem to treat these drivers as though they contain the ultimate answer to live, the universe, and everything. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 31 06:56:34 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VDuYUx003836 for ; Wed, 31 May 2006 06:56:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VDuXtx020255 for ; Wed, 31 May 2006 06:56:34 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4VDuXTR006810 for ; Wed, 31 May 2006 07:56:33 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400C01UJXSC00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 07:56:33 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04004XNUQ8KR92@mail-amer.sun.com>; Wed, 31 May 2006 07:56:33 -0600 (MDT) Date: Wed, 31 May 2006 09:56:45 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17532.32313.514080.184415@gargle.gargle.HOWL> Sender: Daniel.Groves@Sun.COM To: James Carlson Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447DA09D.1030908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 3295 James Carlson wrote: > Sebastien Roy writes: > >> Application impact >> =================== > [...] >> 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. > > Just as a check: what exactly do libpcap users see here? Is there a > chance that libpcap users get hurt? (I'm specifically worred about > applications like ISC's DHCP.) > If I understood the other comments and my private conversations with Cathy correctly (Cathy, please correct me if I'm wrong) the VLAN tag will be stripped out if you are listening on the VLAN link. If you are not capturing on the VLAN link, then the VLAN tag will not be stripped. For example, let's say I have bge0 and bge2000 (bge0 tag 2). If I do "snoop -d bge2000", I will see traffic over link bge2000 and the traffic will not have a VLAN tag because the driver stripped it out. If I do "snoop -d bge0" I will see traffic from both bge0 and bge2000. Traffic on bge2000 will have a VLAN tag. I expect libpcap users to have the same behavior. >> Users that use libpcap-based packet capture tools such as tcpdump and >> ethereal will need to include a vlan expression in their packet filtering >> expression if they are filtering on a VLAN configured interface. > > They don't "need" to do this, right? Things should just "work right" > for ethereal users attaching to the VLAN (PPA-hack) nodes on the > system, with no special configuration required. For those using the > raw physical link, they _might_ need to set up VLAN filters, depending > on what it is they're expecting (and wanting) to see. > > Do I have that right? Or is changing filter expressions a new > _requirement_ for users? > See above. If they're listening on the VLAN link, then they don't need to do anything. If they're listening on the interface (i.e. bge0 in the previous example) and they want to capture the VLAN tagged traffic, they'll need to change their filtering expression. >> Otherwise, their packet filtering expressions will not correctly capture >> VLAN tagged packets. > > "Not correctly?" > > I hope this just means that existing filtering expressions will end up > matching traffic on all VLANs, and not that it'll just start > malfunctioning arbitrarily. > If the VLAN tag is present, and they don't have the vlan expression as part of their filtering expression, the expression won't capture the VLAN tagged traffic, which might not be what the user expected. This is the way libpcap works. I can update the document to make that clearer. > >> * pfmod consumers > [...] >> Dhcpagent and in.dhcpd are bound to ETHERTYPE_IP and ETHERTYPE_ARP, >> and so should require no changes. > > The important part is that they're not using DLIOCRAW, and not just > how they're bound, correct? > Yes, that's correct. > Missing from this list: mipagent. It seems to use DLIOCRAW. > I'm not sure why you bring up mipagent. It doesn't use pfmod and in this section we're just looking at pfmod consumers. I think I've answered everything Cathy didn't respond to. Is there anything I missed? Dan From sacadmin Wed May 31 07:00:34 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VE0Y8P003863 for ; Wed, 31 May 2006 07:00:34 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VE0XtC007902 for ; Wed, 31 May 2006 07:00:33 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4VE0XfG019895 for ; Wed, 31 May 2006 08:00:33 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400C01UTNQI00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 08:00:33 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J040017XUWRDKB3@mail-amer.sun.com>; Wed, 31 May 2006 08:00:27 -0600 (MDT) Date: Wed, 31 May 2006 10:00:39 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <447CC090.4030702@sun.com> Sender: Daniel.Groves@Sun.COM To: Erik Nordmark Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447DA187.3050005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1809 Erik Nordmark wrote: > Sebastien Roy wrote: > >> Problem area >> ============ >> >> PSARC 2000/147 introduced VLAN support for Ethernet devices. However, >> it did not clearly state how or when VLAN packets could be sent or >> received by DLPI consumers, or how VLAN packets would be accounted by >> the system. Thus, different network drivers have implemented >> different >> semantics, leading to inconsistent or even incorrect behavior. As a >> result, DLPI-based applications are unable to: >> >> a. Monitor all traffic on a given link. >> >> Today, snooping on a physical link only reports untagged packets. >> Customers would like to observe all traffic, including VLAN >> traffic >> when snooping over a physical link. >> >> b. Observe the VLAN tag inside a tagged packet. >> >> Currently, most Solaris network drivers (if not all) strip off >> the VLAN tag prior to sending the VLAN packets upstream, despite >> that the stream is in the raw mode. >> >> In addition, currently, snoop(1M) does not have the ability to filter >> on VLAN-tagged packets, which will become a problem if the above >> issues are addressed. > > I don't have a problem with making those additional capabilities > available, but I also want there to be a uniform way (independent of the > device driver) to observe a particular VLAN. For instance what I get > with bge today, where a snoop on bge1000 shows packets just for that VLAN. > > I can't tell from the description whether and how that will be provided. > > Erik With the changes, if I do "snoop -d bge1000", I will still only see packets for that VLAN. That functionality won't change. Is that sufficient or is there something else you're looking for here? Dan From sacadmin Wed May 31 07:16:17 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VEGGoY004294 for ; Wed, 31 May 2006 07:16:16 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4VEG97h020787 for ; Wed, 31 May 2006 22:16:10 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400201VILM900@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 22:16:09 +0800 (SGT) Received: from [129.150.144.50] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J04003C1VMW5CIG@mail-apac.sun.com>; Wed, 31 May 2006 22:16:09 +0800 (SGT) Date: Wed, 31 May 2006 22:15:57 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17533.41056.12914.940235@gargle.gargle.HOWL> Sender: Cathy.Zhou@Sun.COM To: James Carlson Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <447DA51D.4000706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447D301A.6000201@sun.com> <447D441B.6090500@sun.com> <17533.41056.12914.940235@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Status: RO Content-Length: 2350 >What precisely does the user see if he asks for "kstat -n bge2"? Do >these counters include VLAN-tagged packets or not? > > Yes, they do. >I believe the answer is that they do, but I can't tell from the >original proposal. > >Now it sounds like you're saying that there are also per-VLAN >statistics, using the ppa-hack for a naming scheme, but just not >untagged statistics. If someone needs a count of untagged packets, >he'll need to get "kstat -n bge2" and then subtract off each of "kstat >-n bge1002" through "kstat -n bge4094002." Is that right? > > Right. >>If I >>understand you correctly, we do not support corresponding SNMP variables >>for VLANs. (which I don't know whether in reality it is understood well, >>as I was just looking at a VLAN snmpwalk bug - see 6313901). >> >> > >I don't see any stacking information here, so it looks like users are >just on their own to figure out what the numbers mean. > > Right, it seems it directly derives the VLAN SNMP variables using the VLAN PPA hack name kstats. >>But what we are proposing is not really relevant to VLAN SNMP variables: >>we are proposing to change the semantics of kstats for physical network >>link to include VLAN traffic. VLAN SNMP variables will not change by >>this case. >> >> > >Now I'm completely confused. > >The kstats here are _designed_ for SNMP support. See PSARC 1997/198. >How could it be that the kstats change, but the SNMP variables don't >change? > > SNMP variable of physical interfaces will be affected by our proposal, but not of VLAN interfaces. >>Thanks for pointing it out. Is it possible that we can access its code >>and see whether it is monolithic and how this proposal will affect it? >> >> > >I don't have one of these things. You'll need to find someone who >does. > >I'm sure it's possible to determine some general things (such as >whether it's GLD or monolithic) from the binary alone, and it looks >like their web site has drivers. (Ignoring for the moment any legal >concerns about software download, and inspecting binaries.) > >I doubt that we can get source access, but it might be worth asking >the vendor. Oddly, hardware vendors seem to treat these drivers as >though they contain the ultimate answer to live, the universe, and >everything. > > I will see what I can do. Thanks - Cathy From sacadmin Wed May 31 07:20:44 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VEKhFd004335 for ; Wed, 31 May 2006 07:20:43 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4VELHFN001917; Wed, 31 May 2006 10:21:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4VELHQm001914; Wed, 31 May 2006 10:21:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.42588.801209.426653@gargle.gargle.HOWL> Date: Wed, 31 May 2006 10:21:16 -0400 From: James Carlson To: Dan Groves Cc: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Dan Groves's message of 31 May 2006 09:56:45 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1552 Dan Groves writes: > > Just as a check: what exactly do libpcap users see here? Is there a > > chance that libpcap users get hurt? (I'm specifically worred about > > applications like ISC's DHCP.) > > > > If I understood the other comments and my private conversations with > Cathy correctly (Cathy, please correct me if I'm wrong) the VLAN tag > will be stripped out if you are listening on the VLAN link. If you are > not capturing on the VLAN link, then the VLAN tag will not be stripped. OK. That's a change in the spec. I think we should get a new spec at this point. I agree that the potential problem is gone if the tag is stripped on ppa-hack interfaces. > > Missing from this list: mipagent. It seems to use DLIOCRAW. > > > > I'm not sure why you bring up mipagent. It doesn't use pfmod and in > this section we're just looking at pfmod consumers. It does use DLIOCRAW, and the original specification _changed_ the behavior of DLIOCRAW when used on ppa-hack interfaces. Thus, when citing other potential applications involved, it seemed to me that this one should be included. With that change removed, this issue goes away (as does the need to reference in.dhcp and the others). > I think I've answered everything Cathy didn't respond to. Is there > anything I missed? Not that I see; thanks. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 31 07:33:15 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VEXFjN004545 for ; Wed, 31 May 2006 07:33:15 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VEXEtx003658 for ; Wed, 31 May 2006 07:33:15 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4VEXEfG010889 for ; Wed, 31 May 2006 08:33:14 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400601W84RZ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 08:33:14 -0600 (MDT) Received: from strat.East.Sun.COM ([129.148.174.103]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J040029QWFDFSE0@mail-amer.sun.com>; Wed, 31 May 2006 08:33:14 -0600 (MDT) Date: Wed, 31 May 2006 10:33:13 -0400 From: Sebastien Roy Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17533.42588.801209.426653@gargle.gargle.HOWL> Sender: Sebastien.Roy@Sun.COM To: James Carlson Cc: Dan Groves , psarc , clearview-iteam Message-id: <1149085993.18601.8.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> Status: RO Content-Length: 592 On Wed, 2006-05-31 at 10:21 -0400, James Carlson wrote: > Dan Groves writes: > > If I understood the other comments and my private conversations with > > Cathy correctly (Cathy, please correct me if I'm wrong) the VLAN tag > > will be stripped out if you are listening on the VLAN link. If you are > > not capturing on the VLAN link, then the VLAN tag will not be stripped. > > OK. That's a change in the spec. I think we should get a new spec at > this point. I've marked the case as "waiting need spec". The fast-track timer will be reset when the new spec is posted here. -Seb From sacadmin Wed May 31 08:39:00 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VFd0jH006843 for ; Wed, 31 May 2006 08:39:00 -0700 (PDT) Received: from [192.168.100.80] (vpn-129-150-25-2.SFBay.Sun.COM [129.150.25.2]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VFcx7S408702; Wed, 31 May 2006 08:39:00 -0700 (PDT) In-Reply-To: <447DA09D.1030908@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> Cc: James Carlson , Sebastien Roy , psarc , clearview-iteam Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/358 VLAN Observability Enhancement Date: Wed, 31 May 2006 08:38:58 -0700 To: Dan Groves X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 1010 On May 31, 2006, at 6:56 AM, Dan Groves wrote: > For example, let's say I have bge0 and bge2000 (bge0 tag 2). If I > do "snoop -d bge2000", I will see traffic over link bge2000 and the > traffic will not have a VLAN tag because the driver stripped it > out. If I do "snoop -d bge0" I will see traffic from both bge0 and > bge2000. Traffic on bge2000 will have a VLAN tag. I expect libpcap > users to have the same behavior. I'll be honest: I'm not sure how I feel about this. If I was trying to troubleshoot something, when I snooped bge0 and started seeing traffic from bge2000, I would likely think I have a network problem. I suspect I wouldn't be the only one massively confused by this. I would only hope that the VLAN tagging would be clearly marked. I also dread to see what happens on some of our machines that have interfaces with over 100+ VLANs configured on them. :( How do I just get the traffic on the (real) bge0 interface? What happens if I snoop bge0:0? From sacadmin Wed May 31 09:13:26 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VGDQhl008387 for ; Wed, 31 May 2006 09:13:26 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VGDQtx018638 for ; Wed, 31 May 2006 09:13:26 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4VGDLR5017311 for ; Wed, 31 May 2006 09:13:21 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J05006010YTMC00@d1-sfbay-10.sun.com> (original mail from Jochen.Behrens@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 09:13:21 -0700 (PDT) Received: from [129.150.22.235] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J05008XF122NU30@d1-sfbay-10.sun.com>; Wed, 31 May 2006 09:13:21 -0700 (PDT) Date: Wed, 31 May 2006 09:13:14 -0700 From: Jochen Behrens Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17533.40125.494038.418097@gargle.gargle.HOWL> Sender: Jochen.Behrens@Sun.COM To: James Carlson Cc: Darren Reed , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <447DC09A.5050605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1149001006.1998.7.camel@localhost> <1149014229.7961.153.camel@thunk> <17532.40371.309440.557610@gargle.gargle.HOWL> <447D00E5.9020004@sun.com> <17533.40125.494038.418097@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Status: RO Content-Length: 545 James Carlson wrote: > Darren Reed writes: > >>And as far as I can tell, there is no way to tell a device >>is actually a VLAN, apart from its name? > > > Also one of my comments ... I asked about how the application gets the > VLAN ID that it must use when doing writes with DLIOCRAW. > We've run into that problem before. Since there is no standard DLPI interface to get the tag, PSARC 2004/644 solved the problem for ethernet by making sure that the fastpath header contains the tag. It may be a little ugly, but it works... Jochen From sacadmin Wed May 31 09:27:29 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VGRTAr008780 for ; Wed, 31 May 2006 09:27:29 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VGRTtx025426 for ; Wed, 31 May 2006 09:27:29 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4VGRSH1027945 for ; Wed, 31 May 2006 10:27:28 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500G011CPUD00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 10:27:28 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J05004CJ1PSKQW1@mail-amer.sun.com>; Wed, 31 May 2006 10:27:28 -0600 (MDT) Date: Wed, 31 May 2006 12:27:40 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> Sender: Daniel.Groves@Sun.COM To: Allen Wittenauer Cc: James Carlson , Sebastien Roy , psarc , clearview-iteam Message-id: <447DC3FC.4070805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1367 Allen Wittenauer wrote: > > On May 31, 2006, at 6:56 AM, Dan Groves wrote: >> For example, let's say I have bge0 and bge2000 (bge0 tag 2). If I do >> "snoop -d bge2000", I will see traffic over link bge2000 and the >> traffic will not have a VLAN tag because the driver stripped it out. >> If I do "snoop -d bge0" I will see traffic from both bge0 and >> bge2000. Traffic on bge2000 will have a VLAN tag. I expect libpcap >> users to have the same behavior. > > I'll be honest: I'm not sure how I feel about this. > > If I was trying to troubleshoot something, when I snooped bge0 and > started seeing traffic from bge2000, I would likely think I have a > network problem. I suspect I wouldn't be the only one massively > confused by this. I would only hope that the VLAN tagging would be > clearly marked. > The -v option will show the VLAN tag. By default, the VLAN tag is not displayed. > I also dread to see what happens on some of our machines that have > interfaces with over 100+ VLANs configured on them. :( How do I just > get the traffic on the (real) bge0 interface? What happens if I snoop > bge0:0? > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... is whatever I'm looking for (if I just want to see all the traffic that is not VLAN tagged, then just use not ethertype 0x8100). Dan From sacadmin Wed May 31 10:54:41 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VHsfcn013582 for ; Wed, 31 May 2006 10:54:41 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4VHtFpr000936; Wed, 31 May 2006 13:55:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4VHtEop000933; Wed, 31 May 2006 13:55:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.55425.492313.72177@gargle.gargle.HOWL> Date: Wed, 31 May 2006 13:55:13 -0400 From: James Carlson To: Dan Groves Cc: Allen Wittenauer , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Dan Groves's message of 31 May 2006 12:27:40 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 767 Dan Groves writes: > > I also dread to see what happens on some of our machines that have > > interfaces with over 100+ VLANs configured on them. :( How do I just > > get the traffic on the (real) bge0 interface? What happens if I snoop > > bge0:0? > > > > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... > is whatever I'm looking for (if I just want to see all the traffic that > is not VLAN tagged, then just use not ethertype 0x8100). It would be nice to have proper keywords for these various cases. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 31 10:58:34 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VHwYq4013914 for ; Wed, 31 May 2006 10:58:34 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k4VHwY8c025025; Wed, 31 May 2006 13:58:34 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k4VHwXNC025022; Wed, 31 May 2006 13:58:33 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.55625.813821.444120@triplex.East.Sun.COM> Date: Wed, 31 May 2006 13:58:33 -0400 To: James Carlson Cc: Dan Groves , Allen Wittenauer , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: <17533.55425.492313.72177@gargle.gargle.HOWL> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> <17533.55425.492313.72177@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 686 > > > I also dread to see what happens on some of our machines that have > > > interfaces with over 100+ VLANs configured on them. :( How do I just > > > get the traffic on the (real) bge0 interface? What happens if I snoop > > > bge0:0? > > > > > > > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... > > is whatever I'm looking for (if I just want to see all the traffic that > > is not VLAN tagged, then just use not ethertype 0x8100). > > It would be nice to have proper keywords for these various cases. So would a "vlan" keyword suffice as an alias for "ethertype 0x8100", so that one could do "snoop -d bge0 not vlan"? -- meem From sacadmin Wed May 31 11:23:05 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VIN5M3014685 for ; Wed, 31 May 2006 11:23:05 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VIN4ph016345 for ; Wed, 31 May 2006 11:23:04 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4VIN4fG015775 for ; Wed, 31 May 2006 12:23:04 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500F0172DQL00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 31 May 2006 12:23:04 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J05004YX72FKRF2@mail-amer.sun.com>; Wed, 31 May 2006 12:23:04 -0600 (MDT) Date: Wed, 31 May 2006 14:23:16 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17533.55625.813821.444120@triplex.East.Sun.COM> Sender: Daniel.Groves@Sun.COM To: Peter Memishian Cc: James Carlson , Allen Wittenauer , Sebastien Roy , psarc , clearview-iteam Message-id: <447DDF14.4020908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> <17533.55425.492313.72177@gargle.gargle.HOWL> <17533.55625.813821.444120@triplex.East.Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 750 Peter Memishian wrote: > > > > I also dread to see what happens on some of our machines that have > > > > interfaces with over 100+ VLANs configured on them. :( How do I just > > > > get the traffic on the (real) bge0 interface? What happens if I snoop > > > > bge0:0? > > > > > > > > > > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... > > > is whatever I'm looking for (if I just want to see all the traffic that > > > is not VLAN tagged, then just use not ethertype 0x8100). > > > > It would be nice to have proper keywords for these various cases. > > So would a "vlan" keyword suffice as an alias for "ethertype 0x8100", so > that one could do "snoop -d bge0 not vlan"? > We could add one. From sacadmin Wed May 31 12:25:38 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VJPbc2018245 for ; Wed, 31 May 2006 12:25:38 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4VJQBFd001504; Wed, 31 May 2006 15:26:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4VJQBsH001501; Wed, 31 May 2006 15:26:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.60883.173068.158835@gargle.gargle.HOWL> Date: Wed, 31 May 2006 15:26:11 -0400 From: James Carlson To: Peter Memishian Cc: Dan Groves , Allen Wittenauer , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Peter Memishian's message of 31 May 2006 13:58:33 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> <17533.55425.492313.72177@gargle.gargle.HOWL> <17533.55625.813821.444120@triplex.East.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 938 Peter Memishian writes: > > It would be nice to have proper keywords for these various cases. > > So would a "vlan" keyword suffice as an alias for "ethertype 0x8100", so > that one could do "snoop -d bge0 not vlan"? That'd be a good start. I don't think that specific VLAN filters (ranges or the like) are needed right now, but they could be. Note that by accepting the underlying change, we're implicitly allowing a somewhat incompatible change in a patch: the snoop command will start outputting things that it didn't before. But given that what it did before was misleading enough to be wrong, and the low likelihood that anyone _relied_ on these things being missing from the output, I'm happy with it. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed May 31 15:04:50 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VM4oOu026292 for ; Wed, 31 May 2006 15:04:50 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VM4kr1807534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 May 2006 15:04:48 -0700 (PDT) Message-ID: <447E12F9.4090001@sun.com> Date: Wed, 31 May 2006 15:04:41 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Dan Groves CC: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> In-Reply-To: <447DA187.3050005@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 804 Dan Groves wrote: > With the changes, if I do "snoop -d bge1000", I will still only see > packets for that VLAN. That functionality won't change. > > Is that sufficient or is there something else you're looking for here? The suggested changes handle the main concern. But VLAN tag = 0 is also a perfectly valid tag, and in some cases it involves a 802.1q header (mostly when the priority field is non-zero). Today a snoop on bge0 gives the admin the packets for VLAN tag zero. Question is whether we want to preserve this behavior (and make it standard across all the NICs) while also adding the ability to snoop on all VLANs and have the VLAN headers be passed up. That is harder to do, because the name bge0 refers to the link in some places and refers to tag = 0 in other places. Erik From sacadmin Wed May 31 15:08:27 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VM8RsM026337 for ; Wed, 31 May 2006 15:08:27 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VM8LYk822509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 May 2006 15:08:23 -0700 (PDT) Message-ID: <447E13D4.5080709@sun.com> Date: Wed, 31 May 2006 15:08:20 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Dan Groves CC: Allen Wittenauer , James Carlson , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> In-Reply-To: <447DC3FC.4070805@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 408 Dan Groves wrote: > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... > is whatever I'm looking for (if I just want to see all the traffic that > is not VLAN tagged, then just use not ethertype 0x8100). But that doesn't capture the packets that contain a VLAN header (because they have non-zero priority) with tag = 0. Those also belong to the bge0 that IP and ARP sees. Erik From sacadmin Wed May 31 20:06:16 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5136Ejc003975 for ; Wed, 31 May 2006 20:06:15 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k51369VE018764 for ; Thu, 1 Jun 2006 11:06:09 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500901V64RA00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 01 Jun 2006 11:06:09 +0800 (SGT) Received: from [129.158.219.168] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J050032QVA85D79@mail-apac.sun.com>; Thu, 01 Jun 2006 11:06:09 +0800 (SGT) Date: Thu, 01 Jun 2006 11:06:05 +0800 From: Darren Reed Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17533.55625.813821.444120@triplex.East.Sun.COM> Sender: Darren.Reed@Sun.COM To: psarc Cc: Allen Wittenauer , clearview-iteam Message-id: <447E599D.6000304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> <17533.55425.492313.72177@gargle.gargle.HOWL> <17533.55625.813821.444120@triplex.East.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1430 Peter Memishian wrote: > > > > I also dread to see what happens on some of our machines that have > > > > interfaces with over 100+ VLANs configured on them. :( How do I just > > > > get the traffic on the (real) bge0 interface? What happens if I snoop > > > > bge0:0? > > > > > > > > > > I would use "snoop -d bge0 not ethertype 0x8100 and ( ... )" where ... > > > is whatever I'm looking for (if I just want to see all the traffic that > > > is not VLAN tagged, then just use not ethertype 0x8100). > > > > It would be nice to have proper keywords for these various cases. > >So would a "vlan" keyword suffice as an alias for "ethertype 0x8100", so >that one could do "snoop -d bge0 not vlan"? > > Hmmm, and maybe: snoop -d bge0 vlanid 2 or vlanid 1? Jochen Behrens wrote: > James Carlson wrote: > >> Darren Reed writes: >> >> >>> And as far as I can tell, there is no way to tell a device >>> is actually a VLAN, apart from its name? >> >> >> >> Also one of my comments ... I asked about how the application gets the >> VLAN ID that it must use when doing writes with DLIOCRAW. >> > > We've run into that problem before. Since there is no standard DLPI > interface to get the tag, PSARC 2004/644 solved the problem for > ethernet by making sure that the fastpath header contains the tag. > > It may be a little ugly, but it works... What's involved in properly extending DLPI to cover this? Darren From sacadmin Wed May 31 20:18:16 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k513IGm6004350 for ; Wed, 31 May 2006 20:18:16 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k513IFAG026365; Wed, 31 May 2006 23:18:15 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k513IFCW026362; Wed, 31 May 2006 23:18:15 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17534.23671.569229.48396@triplex.East.Sun.COM> Date: Wed, 31 May 2006 23:18:15 -0400 To: Darren Reed Cc: psarc , Allen Wittenauer , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: <447E599D.6000304@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <65CF56AD-D8AF-440A-8C61-464CB459633D@sun.com> <447DC3FC.4070805@sun.com> <17533.55425.492313.72177@gargle.gargle.HOWL> <17533.55625.813821.444120@triplex.East.Sun.COM> <447E599D.6000304@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 459 > > We've run into that problem before. Since there is no standard DLPI > > interface to get the tag, PSARC 2004/644 solved the problem for > > ethernet by making sure that the fastpath header contains the tag. > > > > It may be a little ugly, but it works... > > What's involved in properly extending DLPI to cover this? I beg folks: let's stay focused on the proposal for this case and not devolve into a general DLPI design discussion. -- meem From sacadmin Wed May 31 22:14:59 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k515EwSf006787 for ; Wed, 31 May 2006 22:14:59 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k515Erss027398 for ; Thu, 1 Jun 2006 13:14:53 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0600J0117K8Z00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 01 Jun 2006 13:14:53 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J06003RE18Q5DS9@mail-apac.sun.com>; Thu, 01 Jun 2006 13:14:52 +0800 (SGT) Date: Thu, 01 Jun 2006 13:14:50 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <447E12F9.4090001@sun.com> Sender: Cathy.Zhou@Sun.COM To: Erik Nordmark Cc: Dan Groves , Sebastien Roy , psarc , clearview-iteam Message-id: <447E77CA.2090500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 1562 > But VLAN tag = 0 is also a perfectly valid tag, and in some cases it > involves a 802.1q header (mostly when the priority field is non-zero). > Today a snoop on bge0 gives the admin the packets for VLAN tag zero. > > Question is whether we want to preserve this behavior (and make it > standard across all the NICs) while also adding the ability to snoop on > all VLANs and have the VLAN headers be passed up. One possibility could be: - For streams attached to a VLAN link (e.g., bge1000) * On the receive-side, the streams in the raw mode must only accept the VLAN tagged packets with the correct VLAN IDs. If the priority bits are zero, the streams must strip off the VLAN tags (but not the preceding Ethernet headers) before passing the packets upstream; otherwise, the streams will use the reserved tag 0 to encode the VLAN TCI and send up the packets. Again, symmetrically, some changes to the transmit side: * On the transmit-side, the packets sent down to the streams in the raw mode will either have Ethernet header without VLAN tags, or with VLAN headers but the VLAN IDs are 0 (priority bits are not 0). It is the streams's work to insert(encoding) the VLAN tags into the packets before sending them out on the wire. The TCI stuff introduces a lot of complexities. Before I make this change, I want to understand more about how this (VLAN tag = 0) is used in the real world. Thanks - Cathy From sacadmin Fri Jun 2 17:52:13 2006 Received: from sentry.SFBay.Sun.COM (sentry.SFBay.Sun.COM [129.146.157.28]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k530qD6Q000160 for ; Fri, 2 Jun 2006 17:52:13 -0700 (PDT) Received: from [129.146.11.202] (sr1-umpk-18.SFBay.Sun.COM [129.146.11.202]) by sentry.SFBay.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k530nqr5026052; Fri, 2 Jun 2006 17:49:52 -0700 (PDT) Message-ID: <4480DD3C.3060302@Sun.COM> Date: Fri, 02 Jun 2006 17:52:12 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cathy Zhou CC: Erik Nordmark , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> In-Reply-To: <447E77CA.2090500@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2991 Just one more opinion among many here, but... I don't like the idea of the VLAN streams inserting/stripping VLAN headers to accomodate a VLAN-unaware raw mode user. The VLAN data link mechanism should act as a fan-out mechanism, distributing packets to the right users without modifying them. In raw mode, it seems wrong to me for the DLPI provider to modify received packets in any way before presenting them to the user. This is for performance reasons as well as for transparency of the interface. Raw mode is for low level tools and protocols that are well aware of the nuances of the media format and/or need to observe "physical" I/O behavior. Modification would also be a performance problem in the loopback case. If the DLS layer has to insert a VLAN tag before handing the packet to the driver, and then remove the tag right back out again before handing a copy the packet to other users (e.g. snoop) we are doing a lot of unnecessary copying, when a dup reference would suffice. I think it makes sense to consider VLAN-tagged traffic as being of a slightly different media type, one with 18-byte link headers instead of 14-byte ones. Perhaps this should even be presented as a different DLPI media type (DL_ETHERVLAN?) although I'm not so certain about that. Using an alternate media type could also help snoop provide intuitive default behavior. If I do "snoop -d bge1000 ip" I want to see the VID 1 tagged IP packets described as plain IP packets. But "snoop -d bge0 ip" by default should not show me VID 1 tagged IP packets because those packets are not in fact considered IP packets by the bge0 link provider - it is not going to deliver them to IP because they are not of SAP ETHERTYPE_IP on that link. The difference, from snoop's point of view, is that VID 1 tagged packets are ethertype 0x8100 when seen on device bge0, but ethertype 0x0800 on device bge1000 - the ethertype is stored at a different header offset on DL_ETHERVLAN than it is on DL_ETHER media. As for the problem of how the DLS user can know what VID to use for transmitting, one solution is to require the user to fill in VID 0, or just have the provider ignore user-specified VID and always fill it in with the correct value for the link. Although this does involve the DLPI provider modifying the header, it is done before the multiple dups may happen, so it doesn't necessitate additional copying. If we find there is a need for a mechanism for explicitly stripping and inserting VLAN tags (say, for layer-2 forwarding of packets to a virtual machine that doesn't speak 802.1Q at all) we can build it into the bridge project or the "virtual switch" mechanism that we are considering for Crossbow. This would also achieve the goal of matching the physical model when virtualizing a physical bunch of machines attached to a VLAN-tagging switch... the virtual switch would be managable very much like the physical switch it emulates, including native VIDs per port, etc. -=] Mike [=- From sacadmin Sun Jun 4 12:13:01 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k54JD1m8010863 for ; Sun, 4 Jun 2006 12:13:01 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k54JDdcs012799; Sun, 4 Jun 2006 15:13:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k54JDd76012796; Sun, 4 Jun 2006 15:13:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17539.12514.966647.736649@gargle.gargle.HOWL> Date: Sun, 4 Jun 2006 15:13:38 -0400 From: James Carlson To: Mike Ditto Cc: Cathy Zhou , Erik Nordmark , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Mike Ditto's message of 2 June 2006 17:52:12 References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 4424 Mike Ditto writes: > Just one more opinion among many here, but... > > I don't like the idea of the VLAN streams inserting/stripping VLAN > headers to accomodate a VLAN-unaware raw mode user. The VLAN data > link mechanism should act as a fan-out mechanism, distributing > packets to the right users without modifying them. What is the architectural model for VLAN-specific nodes in Solaris? If the model is to behave as though you were attached to an untagged Ethernet interface on a VLAN-capable bridge ("switch"), then you would not have seen those tags, because the switch would strip them. Solaris should do the same. If the model is to allow access to all of the bits -- even those that you would not normally be able to access if you were connected via a switch -- then we need a much bigger redesign. This means that raw users also need to know which VLAN ID is in use, and will need to know when to generate headers. There are _no_ interfaces to do this today, and the project would be incomplete as it stands if it tried to do that. (As you note, adding new interfaces -- such as a new MAC type -- could solve that newly-created problem.) Note that doing as you suggest _will_ also break existing raw users. Those users expect to see normal Ethernet headers and will all need to be modified to handle VLANs. Since they're _already_ selecting a particular VLAN of interest implicitly by opening a VLAN-hack DLPI node, why should they be forced to deal with the VLAN headers on each packet as well? Furthermore, since there's no extra information here (it's already filtered), whom are we helping? > In raw mode, it seems wrong to me for the DLPI provider to modify > received packets in any way before presenting them to the user. It all depends on the model chosen. > Modification would also be a performance problem in the loopback case. > If the DLS layer has to insert a VLAN tag before handing the packet to > the driver, and then remove the tag right back out again before handing > a copy the packet to other users (e.g. snoop) we are doing a lot of > unnecessary copying, when a dup reference would suffice. Dups will still work. You don't need to copy the data to do this right; just strip the header by advancing b_rptr and allocating a new mblk. It's fairly cheap, other than a 14 byte copy (or, if you wish, double-dup and no copy). I think that if we're worried about header manipulation logic in the loopback snooping case, we're off the mark. That's not where the expense of snoop lay. > As for the problem of how the DLS user can know what VID to use for > transmitting, one solution is to require the user to fill in VID > 0, or just have the provider ignore user-specified VID and always fill > it in with the correct value for the link. And modify it on the fly?! That doesn't sound right to me. > Although this does > involve the DLPI provider modifying the header, it is done before the > multiple dups may happen, so it doesn't necessitate additional > copying. It will when db_ref > 1. It also just seems icky, particularly so when both the VLAN ID and the traffic class are both zero. Such a header is alien (you wouldn't encounter it on the wire), and forcing users to generate it seems strange. Plus, as noted above, it still breaks existing applications for no apparent benefit. > If we find there is a need for a mechanism for explicitly stripping > and inserting VLAN tags (say, for layer-2 forwarding of packets to a > virtual machine that doesn't speak 802.1Q at all) we can build it into > the bridge project or the "virtual switch" mechanism that we are > considering for Crossbow. This would also achieve the goal of > matching the physical model when virtualizing a physical bunch of > machines attached to a VLAN-tagging switch... the virtual switch > would be managable very much like the physical switch it emulates, > including native VIDs per port, etc. So, how exactly is the "virtual switch" design really administratively or behaviorally different from the existing VLAN hack design? In both cases, you have separate 'physical' DLPI nodes that represent VLANs. Why would the visible headers differ in the two cases? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Jun 6 03:18:56 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56AIuKI014605 for ; Tue, 6 Jun 2006 03:18:56 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56AIoS2850578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 Jun 2006 03:18:52 -0700 (PDT) Message-ID: <44854E9D.2040600@sun.com> Date: Tue, 06 Jun 2006 02:45:01 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Cathy Zhou CC: Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> In-Reply-To: <447E77CA.2090500@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3408 Cathy Zhou wrote: > One possibility could be: > > - For streams attached to a VLAN link (e.g., bge1000) > > * On the receive-side, the streams in the raw mode must only > accept the VLAN tagged packets with the correct VLAN IDs. > If the priority bits are zero, the streams must strip off > the VLAN tags (but not the preceding Ethernet headers) before > passing the packets upstream; otherwise, the streams will > use the reserved tag 0 to encode the VLAN TCI and send up the > packets. > > Again, symmetrically, some changes to the transmit side: > > * On the transmit-side, the packets sent down to the streams in > the raw mode will either have Ethernet header without VLAN > tags, or with VLAN headers but the VLAN IDs are 0 (priority > bits are not 0). It is the streams's work to insert(encoding) > the VLAN tags into the packets before sending them out on the > wire. > > The TCI stuff introduces a lot of complexities. Before I make this > change, I want to understand more about how this (VLAN tag = 0) is used > in the real world. Ethernet priority has been pushed e.g. by Microsoft as part of their larger QoS effort (which also included diffserv and intserv/RSVP). But I don't think that has been deployed much. There is however the possibility that some hosts might send packets with priority i.e. with a VLAN tag with CID=0. For interoperability we should be able to receive such packets, strip the VLAN header, and pass them to the datalink user that is bound to the ppa. Thus IP on bge0 should receive them. I don't know if that is already the case. But that doesn't help answer what we want to do for observability. Have you already decided that RAW datalink users using bge1000 will not see the VLAN headers when priority=0? If that's the case I think it is fine to do the same for non-zero priority. If somebody needs to see what is really (*) on the wire, they can snoop on bge0. (*) Still doesn't allow them to see the Ethernet CRC - we do clearly have many different flavors of "raw". But I'm still concerned about treating bge0 differently than bge1000. If we have the model that a datalink user bound to a specific SAP only receive packets that match that SAP and CID, and that RAW implies that Ethernet headers are passed up, and that DL_PROMISC_SAP means "all Ethernet types", we still don't have much guidance on how to treat snoop on bge0. If somebody approaches the problem from the IP/ARP layer and wants to see all IP and ARP packets for their ppa/cid, then they would potentially be confused if a snoop on bge0 shows packets for other VLANs. But if somebody really wants to look at the wire, then it makes sense that a snoop on bge0 shows all VLANs and with the VLAN headers. I think we need to address both cases of usage. This means that we need to make a distinction between "snoop the wire bge0" and "snoop the logical attachment point bge0 which has CID=0". [In the above, CID=0 can be encoded as a VLAN header with CID=0, or the absence of a VLAN header.] It seems like much of this is focused on the second use case (snooping the wire), which is missing from Solaris today. But we shouldn't throw the baby out with the bathwater by removing the first use case for snoop on bge0. Erik From sacadmin Tue Jun 6 03:19:02 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56AJ2qN014616 for ; Tue, 6 Jun 2006 03:19:02 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56AIuI2850640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 Jun 2006 03:18:58 -0700 (PDT) Message-ID: <44854FB0.3010303@sun.com> Date: Tue, 06 Jun 2006 02:49:36 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Mike Ditto , Cathy Zhou , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> In-Reply-To: <17539.12514.966647.736649@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 821 James Carlson wrote: > What is the architectural model for VLAN-specific nodes in Solaris? > > If the model is to behave as though you were attached to an untagged > Ethernet interface on a VLAN-capable bridge ("switch"), then you would > not have seen those tags, because the switch would strip them. > Solaris should do the same. FWIW I think the above is the simplest model. It matches what we have for IP/ARP usage of datalinks, yet still allows Xen/LDOMs to be attached to a particular VLAN. There are few cases where we need something different - one is "snoop the wire" and another is is if we in the future want to build an full-fledged Ethernet switch complete with dynamic VLAN membership e.g. (a cases where we can benefit from a single datalink user receiving packets for all VLAN tags.) Erik From sacadmin Tue Jun 6 07:44:11 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56EiBuP020992 for ; Tue, 6 Jun 2006 07:44:11 -0700 (PDT) Received: from [192.168.100.80] (vpn-129-150-25-2.SFBay.Sun.COM [129.150.25.2]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56EiAvs193611; Tue, 6 Jun 2006 07:44:10 -0700 (PDT) In-Reply-To: <1149001006.1998.7.camel@localhost> References: <1149001006.1998.7.camel@localhost> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81BD4DA9-B5E0-43F1-90CE-ECBE341D6DF2@sun.com> Cc: psarc , clearview-iteam Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/358 VLAN Observability Enhancement Date: Tue, 6 Jun 2006 07:44:09 -0700 To: Sebastien Roy X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 196 Given the issues around snoop, will ethereal and tcpdump be similarly impacted when looking at packets from bge0? What do these applications do on other OSes? Shouldn't it be consistent? From sacadmin Tue Jun 6 07:58:39 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56EwdWC021841 for ; Tue, 6 Jun 2006 07:58:39 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k56ExJxE018800; Tue, 6 Jun 2006 10:59:19 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k56ExJTh018797; Tue, 6 Jun 2006 10:59:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17541.38979.863141.691316@gargle.gargle.HOWL> Date: Tue, 6 Jun 2006 10:59:15 -0400 From: James Carlson To: Allen Wittenauer Cc: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Allen Wittenauer's message of 6 June 2006 07:44:09 References: <1149001006.1998.7.camel@localhost> <81BD4DA9-B5E0-43F1-90CE-ECBE341D6DF2@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 639 Allen Wittenauer writes: > Given the issues around snoop, will ethereal and tcpdump be > similarly impacted when looking at packets from bge0? What do these > applications do on other OSes? Shouldn't it be consistent? Those applications have dealt with VLAN headers for a long time, so it's nothing new. See, for example, the capture_vlan() and dissect_vlan() functions in ethereal's packet-vlan.c module. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Jun 6 08:23:14 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56FNDh4024349 for ; Tue, 6 Jun 2006 08:23:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56FNC53026610; Tue, 6 Jun 2006 11:23:12 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56FNCWP023750; Tue, 6 Jun 2006 11:23:12 -0400 (EDT) Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: Allen Wittenauer Cc: Sebastien Roy , psarc , clearview-iteam In-Reply-To: <81BD4DA9-B5E0-43F1-90CE-ECBE341D6DF2@sun.com> References: <1149001006.1998.7.camel@localhost> <81BD4DA9-B5E0-43F1-90CE-ECBE341D6DF2@sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1149607391.19860.15.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Tue, 06 Jun 2006 11:23:12 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2311 On Tue, 2006-06-06 at 10:44, Allen Wittenauer wrote: > Given the issues around snoop, will ethereal and tcpdump be > similarly impacted when looking at packets from bge0? What do these > applications do on other OSes? netbsd's vlans are named and administered somewhat differently, but despite that, the observability behavior is essentially identical to what is proposed as part of this case - the untagged physical interface sees tagged traffic with explicit tags, and the tagged vlan interface does not see tags. For example, with the following config (anonymized from a real system): fxp0: flags=8843 mtu 1500 address: aa:aa:aa:aa:aa:aa media: Ethernet autoselect (100baseTX full-duplex) status: active inet w.x.y.z netmask 0xffffff00 broadcast w.x.y.255 vlan0: flags=8843 mtu 1500 vlan: 2 parent: fxp0 address: aa:aa:aa:aa:aa:aa inet 10.12.0.2 netmask 0xffff0000 broadcast 10.12.255.255 vlan1: flags=8843 mtu 1500 vlan: 42 parent: fxp0 address: aa:aa:aa:aa:aa:aa inet 10.42.0.1 netmask 0xffff0000 broadcast 10.42.255.255 tcpdump on fxp0 will see all traffic, and by default will dump the tag and priority before parsing the rest of the frame: # tcpdump -ni fxp0 tcpdump: listening on fxp0 ... 11:11:32.219530 802.1Q vlan#2 P0 10.12.0.2.3483 > 10.12.0.53.3483: udp 194 11:11:32.221888 802.1Q vlan#2 P0 10.12.0.2.3483 > 10.12.1.1.41175: P 2950447393:2950448683(1290) ack 1264442025 win 33580 (DF) 11:11:32.224213 802.1Q vlan#2 P0 10.12.0.2.3483 > 10.12.0.52.36878: P 1:1291(1290) ack 0 win 33580 (DF) 11:11:32.226802 802.1Q vlan#2 P0 10.12.0.2.3483 > 10.12.0.50.3483: udp 194 ... 11:19:59.139243 802.1Q vlan#42 P0 10.42.0.1 > 10.42.0.2: icmp: echo request seq 2 11:19:59.139563 802.1Q vlan#42 P0 10.42.0.2 > 10.42.0.1: icmp: echo reply seq 2 ... while tcpdump on vlan1 will not see tags: # tcpdump -ni vlan1 ... 11:21:57.146461 10.42.0.1 > 10.42.0.2: icmp: echo request seq 0 11:21:57.146839 10.42.0.2 > 10.42.0.1: icmp: echo reply seq 0 11:21:58.150570 10.42.0.1 > 10.42.0.2: icmp: echo request seq 1 11:21:58.150893 10.42.0.2 > 10.42.0.1: icmp: echo reply seq 1 ... - Bill From sacadmin Tue Jun 6 08:56:33 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56FuXYF026664 for ; Tue, 6 Jun 2006 08:56:33 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k56FuWEq004644 for ; Tue, 6 Jun 2006 08:56:32 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56FuWoG028075 for ; Tue, 6 Jun 2006 09:56:32 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0G0070141BU800@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 06 Jun 2006 09:56:32 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0G004YF4A7KQC3@mail-amer.sun.com>; Tue, 06 Jun 2006 09:56:32 -0600 (MDT) Date: Tue, 06 Jun 2006 11:56:40 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <44854E9D.2040600@sun.com> Sender: Daniel.Groves@Sun.COM To: Erik Nordmark Cc: Cathy Zhou , Sebastien Roy , psarc , clearview-iteam Message-id: <4485A5B8.4030702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <44854E9D.2040600@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2979 Erik Nordmark wrote: > Cathy Zhou wrote: > >> >> The TCI stuff introduces a lot of complexities. Before I make this >> change, I want to understand more about how this (VLAN tag = 0) is >> used in the real world. > > Ethernet priority has been pushed e.g. by Microsoft as part of their > larger QoS effort (which also included diffserv and intserv/RSVP). But I > don't think that has been deployed much. > > There is however the possibility that some hosts might send packets with > priority i.e. with a VLAN tag with CID=0. For interoperability we should > be able to receive such packets, strip the VLAN header, and pass them > to the datalink user that is bound to the ppa. Thus IP on bge0 should > receive them. I don't know if that is already the case. > > But that doesn't help answer what we want to do for observability. > > Have you already decided that RAW datalink users using bge1000 will not > see the VLAN headers when priority=0? If that's the case I think it is > fine to do the same for non-zero priority. > We're re-working the case to state that we'll strip out the VLAN header when priority is zero for RAW users of the VLAN tagged link. However, if the priority bits are non-zero, the header will stay put. > If somebody needs to see what is really (*) on the wire, they can snoop > on bge0. > (*) Still doesn't allow them to see the Ethernet CRC - we do clearly > have many different flavors of "raw". > > > But I'm still concerned about treating bge0 differently than bge1000. > > If we have the model that a datalink user bound to a specific SAP only > receive packets that match that SAP and CID, and that RAW implies that > Ethernet headers are passed up, and that DL_PROMISC_SAP means "all > Ethernet types", we still don't have much guidance on how to treat snoop > on bge0. > > If somebody approaches the problem from the IP/ARP layer and wants to > see all IP and ARP packets for their ppa/cid, then they would > potentially be confused if a snoop on bge0 shows packets for other VLANs. > > But if somebody really wants to look at the wire, then it makes sense > that a snoop on bge0 shows all VLANs and with the VLAN headers. > > I think we need to address both cases of usage. This means that we need > to make a distinction between "snoop the wire bge0" and "snoop the > logical attachment point bge0 which has CID=0". [In the above, CID=0 can > be encoded as a VLAN header with CID=0, or the absence of a VLAN header.] > I've added a vlan expression to snoop, and it's defined as matching any packet whose ethertype is VLAN and whose VLAN ID is not zero. So I think you could take care of the second case by doing "snoop -d bge0 not vlan". > It seems like much of this is focused on the second use case (snooping > the wire), which is missing from Solaris today. But we shouldn't throw > the baby out with the bathwater by removing the first use case for snoop > on bge0. > > Erik > > > From sacadmin Tue Jun 6 11:34:46 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56IYkJB003998 for ; Tue, 6 Jun 2006 11:34:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56IYj6f011511 for ; Tue, 6 Jun 2006 11:34:45 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56IYjGN006713 for ; Tue, 6 Jun 2006 12:34:45 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0G00801BJGQ900@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 06 Jun 2006 12:34:45 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0G002OBBLVFTR0@mail-amer.sun.com>; Tue, 06 Jun 2006 12:34:45 -0600 (MDT) Date: Tue, 06 Jun 2006 14:33:49 -0400 From: Sebastien Roy Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <1149085993.18601.8.camel@strat.East.Sun.COM> Sender: Sebastien.Roy@Sun.COM To: psarc Cc: clearview-iteam Message-id: <1149618829.1915.83.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> Status: RO Content-Length: 33214 On Wed, 2006-05-31 at 10:33 -0400, Sebastien Roy wrote: > I've marked the case as "waiting need spec". The fast-track timer will > be reset when the new spec is posted here. The project team has updated the spec. It's pasted in-line here with modified lines marked with '*', but the unmarked spec will be in the materials directory shortly (sac.sfbay appears to be having nfs problems keeping me from logging in). The timer has been restarted and will expire on June 13, 2006. VLAN observability enhancement ============================== Release binding: patch Commitment level: Stable Problem area ============ PSARC 2000/147 introduced VLAN support for Ethernet devices. However, it did not clearly state how or when VLAN packets could be sent or received by DLPI consumers, or how VLAN packets would be accounted by the system. Thus, different network drivers have implemented different semantics, leading to inconsistent or even incorrect behavior. * Specifically, today, snooping on a physical link only reports untagged * packets. Customers would like to observe all traffic, including VLAN * traffic when snooping over a physical link. * In addition, currently, snoop(1M) does not have the ability to filter on VLAN-tagged packets, which will become a problem if the above issue * is addressed. * Proposal overview ================= To address the mentioned problem, this case: * clearly defines the semantics of DL_PROMISC_SAP and the DLIOCRAW ioctl, and how they affect network observation behavior in a VLAN environment. * discusses some common network kstats and their semantics in a VLAN environment. * discusses changes made to pfmod(7M) and snoop(1M) which are * necessary for snoop to be able to capture and filter VLAN packets. * DL_PROMISC_SAP ============== If a stream enables promiscuous mode at the DL_PROMISC_SAP level, based on its physical-level promiscuous setting, the stream is able to receive packets of all SAP (Ethernet type) values, no matter what SAP it is bound to. Note that to a stream attached to a physical link, all VLAN packets have SAP value 0x8100. Therefore, we propose that all VLAN packets be sent upstream if the physical stream is in DL_PROMISC_SAP promiscuous mode. As a result, if snooping on a physical link, VLAN tagged packets will be visible if they pass the physical-level filter. DLIOCRAW ======== PSARC/2005/626 discussed the DLIOCRAW ioctl semantics in detail: "The DLIOCRAW ioctl function is used by some DLPI applica- tions, most notably the snoop(1M) command. The DLIOCRAW com- mand puts the stream into a raw mode, which, upon receive, causes the the full MAC-level packet to be sent upstream in an M_DATA message instead of it being transformed into the DL_UNITDATA_IND form normally used for reporting incoming packets. Packet SAP filtering is still performed on streams that are in raw mode; if a stream user wants to receive all incoming packets it must also select the appropriate promis- cuous modes. After successfully selecting raw mode, the application is also allowed to send fully formatted packets to the driver as M_DATA messages for transmission. DLIOCRAW takes no arguments. Once enabled, the stream remains in this mode until closed." But it does not specifically discuss the semantics of DLIOCRAW in * a VLAN environment. To address this ambiguity, we propose: * - For streams attached to a physical link (e.g., bge0) * * On the receive-side, the streams in the raw mode must send * the VLAN tagged packets upstream as they are, without * stripping off the VLAN headers from the packets. * * On the transmit-side, the streams in the raw mode must keep * the VLAN headers in the VLAN packets intact before it sends * them out on the wire. * Note that above semantics also applies to the special priority * tagged packets, which have VLAN header but with zero VLAN ID * and non-zero priority bits (see the IEEE 802.1D standard). * - For streams attached to a VLAN link (e.g., bge1000) * * On the receive-side, the streams in the raw mode must only * accept the VLAN tagged packets with the correct VLAN IDs. * If the priority bits are zero, the streams must strip off * the VLAN headers (but not the preceding Ethernet headers) * before passing the packets upstream; otherwise, the streams * will use the reserved tag 0 to encode the VLAN TCI and send * up the packets. * * On the transmit-side, the packets sent down to the streams in * the raw mode will have either Ethernet headers (but no VLAN * headers), or VLAN headers with the special priority tags * (VLAN IDs are zero). The streams must insert(encode) the * VLAN tags into the packets before sending them out on the wire. * Note that the above proposal implies an (never documented) interface * to request certain QoS control of a packet on a raw stream: the packet * will have a VLAN header with its priority bits set but VLAN ID is 0. * PSARC 2000/147 defines another two QoS driver interfaces to set * the priority value when sending a packet. The priority value can be * specified: * - on the per-stream basis using the DL_UDQOS_REQ request, it will * remain unchanged until the next DL_UDQOS_REQ is sent. * - on the per-packet basis either using the b_band field of a * M_DATA message or the dl_priority field of a DL_UNITDATA_REQ. * To avoid confusion, the per-packet mechanisms defined above will only * be used when the stream is not in raw mode. If DLIOCRAW is used, * the stream will respect the priority value set in the VLAN header, * or use the per-stream priority value set by DL_UDQOS_REQ if priority * is not set in the VLAN header. * As a result of the proposed DLIOCRAW semantics, if snooping over an * physial network link, users will see full MAC header of packets, * including VLAN tags if they are VLAN packets; and if snooping over * a VLAN link, users will only see packets targetted on this VLAN, * with the VLAN tags already be stripped off, with the exeption of * the special priority tagged packets. * Network kstats ============== PSARC/1997/198 discussed some common network kstats and their semantics: kstat name SNMP variable type commitment lvl. multircv ifInMulticastPktsi ui32 evolving brdcstrcv ifInBroadcastPkts ui32 evolving multixmt ifOutMulticastPkts ui32 evolving brdcstxmt ifOutBroadcastPkts ui32 evolving rbytes ifInOctets ui32 evolving norcvbuf ifInDiscards ui32 evolving unknowns ifInUnknownProtos ui32 evolving obytes ifOutOctets ui32 evolving ipackets rsIfInPackets ui32 stable opackets rsIfOutPackets ui32 stable rbytes64 ifHCInOctets ui64 evolving ipackets64 rsIfInPackets ui64 evolving obytes64 ifHCOutOctets ui64 evolving opackets64 rsIfOutPackets ui64 evolving noxmtbuf ifOutDiscards ui32 evolving collisions rsIfCollisions ui32 stable ierrors ifInErrors ui32 stable oerrors ifOutErrors ui32 stable In order to match the observation behavior over a physical network link, for kstats listed above, we propose that VLAN traffic statistics be counted as statistics of a physical network link. As the result, * the kstats of a physical link (e.g., bge0) will represent a sum of * both tagged (VLAN) and untagged packets on the wire. * pfmod ===== Because of the proposed changes to DLIOCRAW and DL_PROMISC_SAP, snoop will be able to receive packets with VLAN headers. However, * snoop is not currently able to capture, filter, or display VLAN * packets. Enhancing snoop to capture and display VLAN packets is * straightforward, but filtering support requires adding new * operations to the pfmod kernel packet filter. * Specifically, when possible, snoop filters packets in kernel-space using pfmod, which is an implementation of CMU/Stanford Packet Filter (CSPF). CSPF, as originally designed, is a language for a simple stack machine whose only storage is a stack. Indirection and branching are not supported. Offsets are fixed and must be determined at the time the packet filtering program is generated. There is no provision for indirect addressing in pfmod, or to have variable offsets. Therefore, there is no way to parse variable length headers, headers that may appear after the variable length header, or any other instance of dynamic packet structure. VLAN tagged packets are an instance of a dynamic packet structure because the VLAN header is inserted between the link layer header and the network layer header, thus changing packet structure from the packet structure where there are no VLANs. There is no way to determine, when snoop generates a packet filtering program, if snoop will be filtering on a network that involves VLANs. In order to solve this problem, we will add indirection, forward branching, and extra stack operations to pfmod. * Indirection - pfmod will have extra storage, in the form of an offset register. The offset register will be initialized to zero. The ENF_PUSHWORD instruction will change such that the offset register will be used in determining where to get the data. See the document impact section for details. ENF_PUSHWORD is the only existing instruction whose semantics change. Since the offset register is zero by default, then no user of pfmod will be affected by these changes unless that user makes use of the new instructions. * Forward branching - Two forward branching instructions, ENF_BRFL and ENF_BRTR, will be added. It will not be possible for these branches to go backwards in order to protect against a malicious user causing an infinite loop in the kernel. See document impact section for more details on the instructions. * Extra stack operations - A pop operation is added to pfmod. The pop operation exists to remove an element from the stack without performing any operations on it. These three things combined give us the ability to generate programs that can detect if a packet has a VLAN header, and then to change the offsets it uses. More details, along with background information can be found in the documents on the OpenSolaris Clearview project page for VLAN filtering at: http://www.opensolaris.org/os/project/clearview/vlan_filtering/ snoop * ===== * Snoop will be modified to accept two new filtering expressions to * make packet capture on a VLAN enabled interface easier. One existing * expression will have its semantics change. * The new expressions are: * * vlan - This expression will match any packet with ethertype VLAN * whose VLAN ID is not zero. Packets with VLAN ID of zero are * handled differently because those are used to encode priority * information. * * vlan-id - This expression will match any packet whose ethertype * is VLAN and whose VLAN ID is the same as the ID given in the * expression. Unlike with the vlan expression, packets with * ethertype VLAN whose ID is zero will not be treated differently. * These packets, on a physical link, introduce a VLAN header * that DLIOCRAW applications might not be expecting. Treating * these packets allows administrators to easily troubleshoot * any problems that might occur. * The semantics of snoop's ethertype expression will change so that * any existing customer scripts will continue to capture the same * packets. * See the document impact section for more details on these changes. * Application impact =================== * Network observation applications 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 (with VLAN headers) on physical links, and will * perhaps see packets with VLAN headers on a VLAN link (in the case of * special priority tagged packets). * Third party network observation tools that depend on libpcap (such as tcpdump and ethereal) will not be affected by the changes to pfmod. Libpcap is a wrapper around whatever packet capture or packet filtering facilities are provided by the native operating system. The * current version of libpcap does not make use of pfmod on Solaris. Libpcap on Solaris uses bufmod to pull packets into user space and then relies on a user space implementation of Berkeley Packet Filter (BPF) to perform filtering operations. Users that use libpcap-based packet capture tools such as tcpdump and ethereal will need to include a vlan expression in their packet * filtering expression if they want to capture VLAN tagged traffic on an * interface configured with VLANS while attached to the physical link. * Third party tools that make use of pfmod will find that their current programs will continue to work, and if used in an environment without VLAN tagged packets, will continue to behave the same way. If the * tool is attached to the physical interface and the tool user wants * to filter on VLAN tagged packets, then the tool will have to generate * a different program. * * MIB-II consumers PSARC/1997/198 declared that the listed set of network kstats were suitable for use for MIB-II purposes. As a result, MIB-II consumer (applications like netstat and the SNMP daemon) are gathering information by reading these network statistics. But that PSARC case didn't clearly define the semantics of these kstats in a VLAN environment. There are concerns that those MIB-II consumers might assume the kstats of a physical link only represent the non-VLAN view of the statistics, and if it represents a composite view of both VLAN tagged statistics and untagged statistics, it may cause problem. An option is to introduce another set of "physical kstats" to count both VLAN and non-VLAN traffic and and keep the current set of kstats to only count non-VLAN traffic. But we decide to make the above network kstats represent both VLAN and non-VLAN statistics for several reasons: - The characteristic of VLAN packets To the physical link, VLAN packets are just packets with SAP value 0x8100. They are no more special than other packets, for example, IP packets. - Consistency among network drivers Note that legacy network drivers -- even those that support VLANs -- use the same network kstats for both VLAN and non-VLAN traffic. Thus, if we changed the kstat semantics to only count non-VLAN traffic, the result would be inconsistent semantics unless the legacy drivers were also updated. However, it is not feasible to track down and modify all legacy drivers since many are owned by third parties. Indeed, a design goal of Nemo Unification (http://www.opensolaris.org/os/project/clearview/uv-design.pdf) is to provide the VLAN support without changing legacy drivers. In addition, we believe that the above also proves that the MIB-II consumers will not be affected by our proposed kstats semantics. - Consistency between "dladm" and "netstat" The "dladm show-link -s" command is used to display network statistics of each link. The statistics it reports include both VLAN and non-VLAN statistics. Presenting different view by "dladm show-link -s" and "netstat -i" will only cause confusion. * pfmod consumers The only pfmod consumers in the OS/Net consolidation are dhcpagent, in.dhcpd, and snoop. Dhcpagent and in.dhcpd do not use DLIOCRAW and so should require no * changes. * Snoop will change to generate pfmod programs using the new features so that it will continue to work correctly in a VLAN environment. Network driver impact ===================== We will coordinate to update all Sun supported drivers to adhere to this proposal. Note that the behavior changes we propose only affect network drivers that support VLANs: - The clearview team will change both GLDv2 and GLDv3 to make sure drivers written to the GLD framework work correctly. - SSG/NSN is already aware of this proposal and they will change the ce driver accordingly (bug 4722784). - There are very few third-party monolithic drivers that have VLAN * support. Syskonnect might be one of them, and we are contacting the * relevant people to see the options to update their drivers to be * consistent with our proposal. * Document impact =============== * dlpi(7P) - Evolving As VLAN is DL_ETHER specific, a media type specific subsection will be added into the dlpi(7P) manpage. Below are proposed context diffs. Note that in order to make the manpage clear, the proposed manpage changes include both the behavior specified (but never documented) by PSARC 2000/147 and the new behavior proposed by this new case. The parts are new with this case are marked with the changebars on the right: *** dlpi.origin.text Fri Apr 21 17:12:24 2006 --- dlpi.new.text Mon May 8 14:48:41 2006 *************** *** 317,323 **** --- 317,383 ---- this mode until closed. + DL_ETHER SPECIFIC DLPI SEMANTICS + VLAN Support + + VLAN PPA Access + + Some DL_ETHER DLPI providers support IEEE 802.1Q Virtual + LANs (VLANs). For these providers, traffic for a particu- + lar VLAN can be accessed by attaching to (or opening) a + special VLAN PPA that is calculated from the VLAN ID and + the actual hardware PPA of the device. This VLAN PPA is + calculated by multiplying the VLAN ID by 1000 and adding + the hardware PPA. For instance, VLAN PPA 2001 provides + access to VLAN ID 2 on hardware PPA 1. As with hardware + PPA's, a DLPI provider may provide either or both + DL_STYLE1 or DL_STYLE2 access to a given VLAN PPA, and + portable DLPI consumers must try both DLPI styles before + concluding that a DL_ETHER DLPI provider does not offer + VLAN support. + + Unless raw mode is enabled, a DLPI stream bound to a VLAN + PPA behaves no differently than a traditional DLPI stream. + In particular, as with hardware PPAs, data must be sent + to a DLPI provider without any link-layer headers (which + will then be added by the provider), and received data + will be passed to interested DLPI consumers without any + link-layer headers. Thus, DLPI consumers do not require + special-case logic to make use of VLAN PPAs. + + Hardware PPA Access + + As per IEEE 802.1Q, all VLAN traffic is sent using Ether- + Type 0x8100. As such, in addition to attaching to the VLAN + PPA, all VLAN traffic for a given hardware PPA can also be + accessed by attaching to the hardware PPA and binding to + SAP 0x8100. In this case, all VLAN traffic, regardless of + VLAN ID, can be sent and received by the DLPI consumer. + However, even when raw mode is disabled, packets will be + received starting with their VLAN headers, and must be sent + to the DLPI provider with their VLAN headers already pre- + pended (but without Ethernet headers). Because adhering to + these semantics requires each DLPI consumer to have specia- + lized knowledge of VLANs, VLANs should only be accessed in + this manner when the VLAN PPA access method is insufficient + (e.g., because access to all VLAN traffic, regardless of + VLAN ID, is needed). + + Further, since all VLAN traffic is sent with SAP 0x8100, if | + a DLPI consumer enables promiscuous mode of a stream at the | + DL_PROMISC_SAP level, all VLAN traffic that was not fil- | + tered at the physical (DL_PROMISC_PHYS) level will also be | + visible. As before, these packets will also be received | + starting with their VLAN headers if raw mode is not enabled. | + + QoS Support * + + The IEEE 802.1D standard defines eight classes of priority * + values used by QoS traffic control of Ethernet packet. The * + priority values, although are encoded in the 802.1Q tags, * + can be used independently from VLANs. In particular, a * + special priority tagged packet (with VLAN ID zero but * + priority bits non-zero) does not belong to any VLANs. * + + The priority value can be set on either per-stream or per- * + packet basis. Specifically, DLPI consumers can: * + + - specify the per-stream priority using the DL_UDQOS_REQ * + request. The priority value will remain unchanged until * + the next DL_UDQOS_REQ. * + + - specify the per-packet priority value using the b_band * + field of a M_DATA message or the dl_priority field of a * + DL_UNITDATA_REQ. * + + raw mode | * + + Hardware PPA Access | * + + If raw mode is enabled, then the complete, unmodified MAC- | * + level packet -- including Ethernet and VLAN headers -- | * + will be passed to interested DLPI consumers. Similarly, | * + the entire MAC-level packet -- including Ethernet and VLAN | * + headers -- must be sent to the DLPI provider for transmi- | * + ssion. Note that the priority value (if any) can also be | * + encoded into the VLAN header, and the priority value spe- | * + cified in the b_band field will be ingnored. | * + + VLAN PPA Access | * + + If raw mode is enabled, only packets with the correct VLAN | * + ID will be passed up to the interested DLPI consumers. | * + DLPI providers must strip off the VLAN headers (but not the | * + preceding Ethernet headers) before sending up the packets, | * + with the exeptions of priority tagged packets. In that | * + case, DLPI providers must use the reserved tag 0 to encode | * + the VLAN TCI and send up the packets. | * + + Similarly, on the transmit-side, DLPI consumers must send | * + the packets down to the DLPI providers without the VLAN | * + headers (but with the Ethernet headers), unless certain | * + QoS support is required. In that case, the packet can | * + have the VLAN header to indicate the priority value but | * + its VLAN ID must be zero. The DLPI providers will then | * + insert the VLAN tags or encode the VLAN tags using the | * + priority value specified in the VLAN headers, and send the | * + packets out on the wire. | * FILES Files in or under /dev. * pfmod(7M) Below are proposed context diffs of pfmod(7M) manpage: *** pfmod.original.text Thu Apr 6 12:42:01 2006 --- pfmod.new.text Tue May 9 08:52:32 2006 *************** *** 104,122 **** (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords"). Each shortword of the command list ! specifies one of the actions ENF_PUSHLIT, ENF_PUSHZERO, ! ENF_PUSHONE, ENF_PUSHFFFF, ENF_PUSHFF00, ENF_PUSH00FF, or ! ENF_PUSHWORD+n, which respectively push the next shortword ! of the command list, zero, one, 0xFFFF, 0xFF00, 0x00FF, or ! shortword n of the subject message on the stack, and a ! binary operator from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which then ! operates on the top two elements of the stack and replaces ! them with its result. When both an action and operator are ! specified in the same shortword, the action is performed ! followed by the operation. The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the --- 104,139 ---- (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords") or an offset register. The offset ! register is initially zero. Each shortword of the command ! list specifies an action and a binary operator. Using _n_ as ! shorthand for the next shortword of the instruction stream and ! _%oreg_ for the offset register, the list of actions is: ! COMMAND SHORTWORDS ACTION ! ENF_PUSHLIT 2 Push _n_ on the stack. ! ENF_PUSHZERO 1 Push zero on the stack. ! ENF_PUSHONE 1 Push one on the stack. ! ENF_PUSHFFFF 1 Push 0xFFFF on the stack. ! ENF_PUSHFF00 1 Push 0xFF00 on the stack. ! ENF_PUSH00FF 1 Push 0x00FF on the stack. ! ENF_LOAD_OFFSET 2 Load _n_ into _%oreg_. ! ENF_BRTR 2 Branch forward _n_ shortwords if ! the top element of the stack is ! non-zero. ! ENF_BRFL 2 Branch forward _n_ shortwords if ! the top element of the stack is zero. ! ENF_POP 1 Pop the top element from the stack. ! ENF_PUSHWORD+m 1 Push the value of shortword (_m_ + ! _%oreg_) of the packet onto the stack. ! ! The binary operators can be from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which ! operate on the top two elements of the stack and replace ! them with its result. + When both an action and operator are specified in the same + shortword, the action is performed followed by the operation. + The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the *************** *** 186,192 **** The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. struct ether_header eh; /* used only for offset values */ --- 203,210 ---- The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. The filter ! will work whether or not a VLAN is configured. struct ether_header eh; /* used only for offset values */ *************** *** 222,227 **** --- 240,254 ---- sizeof (us_short); *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_EQ; + *fwp++ = ENF_BRFL; + *fwp++ = 3; /* If this isn't ethertype VLAN, don't change oreg */ + *fwp++ = ENF_LOAD_OFFSET; + *fwp++ = 2; /* size of the VLAN tag in words */ + *fwp++ = ENF_POP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT; *fwp++ = htons(ETHERTYPE_REVARP); *fwp++ = ENF_EQ; pf.Pf_FilterLen = fwp - &pf.Pf_Filter[0]; *************** *** 232,237 **** --- 259,272 ---- *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT | ENF_EQ; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_BRFL | ENF_NOP; + *fwp++ = 3; + *fwp++ = ENF_LOAD_OFFSET | ENF_NOP; + *fwp++ = 2; + *fwp++ = ENF_POP | ENF_NOP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT | ENF_EQ; *fwp++ = htons(ETHERTYPE_REVARP); * snoop(1M) Below are the proposed man page diffs for snoop. *** snoop.old.txt Tue May 23 13:39:13 2006 --- snoop.new.txt Fri Jun 2 10:46:26 2006 * *************** *** 450,457 **** ethertype number ! True if the ethernet type field has value number. ! Equivalent to "ether[12:2] = number". --- 450,459 ---- ethertype number ! True if the Ethernet type field has value number. ! If number is not 0x8100 (VLAN) and the packet is ! VLAN tagged, then the expression will match the ! encapsulated Ethernet type. *************** * *** 471,478 **** * --- 473,488 ---- * * True if the packet is of the appropriate ethertype. * * + vlan * + * + True if the packet has ethertype VLAN and the VLAN ID * + is not zero. * * + vlan-id id * * + True for packets of ethertype VLAN with the id id. * + * + * pppoe * * True if the ethertype of the packet is either pppoed * From sacadmin Tue Jun 6 12:07:27 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56J7QZx005576 for ; Tue, 6 Jun 2006 12:07:27 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56J7PQJ018740; Tue, 6 Jun 2006 15:07:25 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56J7PK7024648; Tue, 6 Jun 2006 15:07:25 -0400 (EDT) Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: Sebastien Roy Cc: psarc , clearview-iteam In-Reply-To: <1149618829.1915.83.camel@localhost> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> Content-Type: text/plain Message-Id: <1149620844.19860.78.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Tue, 06 Jun 2006 15:07:25 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1162 On Tue, 2006-06-06 at 14:33, Sebastien Roy wrote: > Note that above semantics also applies to the special priority * > tagged packets, which have VLAN header but with zero VLAN ID * > and non-zero priority bits (see the IEEE 802.1D standard). * ... > before passing the packets upstream; otherwise, the streams * > will use the reserved tag 0 to encode the VLAN TCI and send * > up the packets. Is "TCI" another way of saying "priority bits" and/or "priority tags" ? (that's the only way to read this which makes sense to me but I'd rather get a clarification). > snoop * > ===== * > > Snoop will be modified to accept two new filtering expressions to * > make packet capture on a VLAN enabled interface easier. One existing * > expression will have its semantics change. Can you provide examples of how snoop will display a packet with a vlan tag in it? (in default, -v, and -V modes)? From sacadmin Tue Jun 6 12:13:53 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56JDqxi005740 for ; Tue, 6 Jun 2006 12:13:52 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k56JDqFw019539; Tue, 6 Jun 2006 15:13:52 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k56JDpa0019536; Tue, 6 Jun 2006 15:13:51 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17541.54255.945190.979572@triplex.East.Sun.COM> Date: Tue, 6 Jun 2006 15:13:51 -0400 To: Bill Sommerfeld Cc: Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: <1149620844.19860.78.camel@thunk> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 161 > Is "TCI" another way of saying "priority bits" and/or "priority tags" ? Yes -- both fields -- and the CFI field, but that's always 0 on Ethernet. -- meem From sacadmin Tue Jun 6 12:20:01 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56JJjvN006052 for ; Tue, 6 Jun 2006 12:20:01 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56JJji7004903 for ; Tue, 6 Jun 2006 12:19:45 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56JJiH0003944 for ; Tue, 6 Jun 2006 13:19:45 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0G00G01DN6X800@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 06 Jun 2006 13:19:44 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0G002H6DOVFTS0@mail-amer.sun.com>; Tue, 06 Jun 2006 13:19:44 -0600 (MDT) Date: Tue, 06 Jun 2006 15:19:52 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <1149620844.19860.78.camel@thunk> Sender: Daniel.Groves@Sun.COM To: Bill Sommerfeld Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <4485D558.2020008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 3709 Bill Sommerfeld wrote: >> snoop * >> ===== * >> >> Snoop will be modified to accept two new filtering expressions to * >> make packet capture on a VLAN enabled interface easier. One existing * >> expression will have its semantics change. > > Can you provide examples of how snoop will display a packet with a vlan > tag in it? (in default, -v, and -V modes)? > default: 192.168.2.42 -> 192.168.2.66 ICMP Echo request (ID: 35096 Sequence number: 0) 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence number: 0) -v: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 1 arrived at 15:18:11.54517 ETHER: Packet size = 106 bytes ETHER: Destination = 0:7:e9:24:45:93, ETHER: Source = 0:3:ba:45:a6:d4, ETHER: VLAN ID = 123 ETHER: VLAN Priority = 0 ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 84 bytes IP: Identification = 48846 IP: Flags = 0x0 IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 1 (ICMP) IP: Header checksum = 771d IP: Source address = 192.168.2.42, 192.168.2.42 IP: Destination address = 192.168.2.66, 192.168.2.66 IP: No options IP: ICMP: ----- ICMP Header ----- ICMP: ICMP: Type = 8 (Echo request) ICMP: Code = 0 (ID: 35097 Sequence number: 0) ICMP: Checksum = adad ICMP: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 2 arrived at 15:18:11.54523 ETHER: Packet size = 102 bytes ETHER: Destination = 0:3:ba:45:a6:d4, ETHER: Source = 0:7:e9:24:45:93, ETHER: VLAN ID = 123 ETHER: VLAN Priority = 0 ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 84 bytes IP: Identification = 21240 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 1 (ICMP) IP: Header checksum = a2f3 IP: Source address = 192.168.2.66, 192.168.2.66 IP: Destination address = 192.168.2.42, 192.168.2.42 IP: No options IP: ICMP: ----- ICMP Header ----- ICMP: ICMP: Type = 0 (Echo reply) ICMP: Code = 0 (ID: 35097 Sequence number: 0) ICMP: Checksum = b5ad ICMP: -V: ________________________________ 192.168.2.42 -> 192.168.2.66 ETHER Type=0800 (IP), VLAN ID=123, size=106 bytes 192.168.2.42 -> 192.168.2.66 IP D=192.168.2.66 S=192.168.2.42 LEN=84, ID=48847, TOS=0x0, TTL=255 192.168.2.42 -> 192.168.2.66 ICMP Echo request (ID: 35098 Sequence number: 0) ________________________________ 192.168.2.66 -> 192.168.2.42 ETHER Type=0800 (IP), VLAN ID=123, size=102 bytes 192.168.2.66 -> 192.168.2.42 IP D=192.168.2.42 S=192.168.2.66 LEN=84, ID=21241, TOS=0x0, TTL=255 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35098 Sequence number: 0) From sacadmin Tue Jun 6 12:40:26 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56JePGs006747 for ; Tue, 6 Jun 2006 12:40:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56JeO5R025579; Tue, 6 Jun 2006 15:40:24 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56JeOsl024733; Tue, 6 Jun 2006 15:40:24 -0400 (EDT) Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: Dan Groves Cc: Sebastien Roy , psarc , clearview-iteam In-Reply-To: <4485D558.2020008@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1149622823.19860.141.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Tue, 06 Jun 2006 15:40:24 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 998 On Tue, 2006-06-06 at 15:19, Dan Groves wrote: > default: > > 192.168.2.42 -> 192.168.2.66 ICMP Echo request (ID: 35096 Sequence number: 0) > 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence number: 0) so there's no indication of a vlan tag in the default mode? that seems very wrong. For instance, if I noticed that bits weren't moving, I might run a snoop, see expected traffic arriving, and assume it wasn't the switch config and spend a bunch of time looking for a host-side misconfiguration before I'd think of cranking up the verbosity level to see the vlan tags that were present because my port on the switch was misconfigured to send everything tagged. By comparison, tcpdump inserts "802.1Q vlan#2 P0" before the IP addresses. I don't think you need anything that verbose, though; how about: VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence number: 0) I don't think it's necessary to dump the priority in the default mode. - Bill From sacadmin Tue Jun 6 12:51:58 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56JpvTO007000 for ; Tue, 6 Jun 2006 12:51:57 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k56Jpvok019876; Tue, 6 Jun 2006 15:51:57 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k56Jpucu019873; Tue, 6 Jun 2006 15:51:57 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17541.56540.927450.330298@triplex.East.Sun.COM> Date: Tue, 6 Jun 2006 15:51:56 -0400 To: Bill Sommerfeld Cc: Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: <1149622823.19860.141.camel@thunk> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 308 > I don't think you need anything that verbose, though; how about: > > VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence > number: 0) That seems high-risk to me -- e.g., many test consolidation scripts have knowledge of the basic structure of the snoop output format. -- meem From sacadmin Tue Jun 6 13:08:18 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56K8HLp007997 for ; Tue, 6 Jun 2006 13:08:17 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k56K8vxx020136; Tue, 6 Jun 2006 16:08:57 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k56K8uG3020133; Tue, 6 Jun 2006 16:08:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17541.57559.106076.337304@gargle.gargle.HOWL> Date: Tue, 6 Jun 2006 16:08:55 -0400 From: James Carlson To: Peter Memishian Cc: Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Peter Memishian's message of 6 June 2006 15:51:56 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 868 Peter Memishian writes: > > > I don't think you need anything that verbose, though; how about: > > > > VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence > > number: 0) > > That seems high-risk to me -- e.g., many test consolidation scripts have > knowledge of the basic structure of the snoop output format. Although today they just don't see those packets at all, because we don't support snooping VLANs on the base instance. I'd agree that we don't normally allow changes to the default snoop output in a patch (as it's too likely parsed by someone), but this one seems less harmful to me than the usual case. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Jun 6 13:19:57 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56KJvbx008818 for ; Tue, 6 Jun 2006 13:19:57 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k56KJuKl021450 for ; Tue, 6 Jun 2006 13:19:56 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56KJuAB005698 for ; Tue, 6 Jun 2006 14:19:56 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0G00801GC7NN00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 06 Jun 2006 14:19:56 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0G00EE4GH7SUNY@mail-amer.sun.com>; Tue, 06 Jun 2006 14:19:56 -0600 (MDT) Date: Tue, 06 Jun 2006 16:20:04 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17541.57559.106076.337304@gargle.gargle.HOWL> Sender: Daniel.Groves@Sun.COM To: James Carlson Cc: Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <4485E374.9030104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2057 James Carlson wrote: > Peter Memishian writes: >> > I don't think you need anything that verbose, though; how about: >> > >> > VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence >> > number: 0) >> >> That seems high-risk to me -- e.g., many test consolidation scripts have >> knowledge of the basic structure of the snoop output format. > > Although today they just don't see those packets at all, because we > don't support snooping VLANs on the base instance. > > I'd agree that we don't normally allow changes to the default snoop > output in a patch (as it's too likely parsed by someone), but this one > seems less harmful to me than the usual case. > Though I do see this in the snoop man page which indicates we're telling customers they will never see information such as VLAN tag information (summary form is the default display for snoop): snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, only the data pertaining to the highest level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and ethernet frame information is suppressed but can be displayed if either of the verbose options are chosen. If no objects, I could change it to: snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, only the data pertaining to the highest level protocol is displayed; however if the packet has a VLAN header that information will be displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and ethernet frame information (with the exception of VLAN information if the packet is VLAN tagged) is suppressed but can be displayed if either of the verbose options are chosen. And then modify snoop to display data similar to what Bill suggests. Dan From sacadmin Tue Jun 6 13:20:05 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56KK5qb008829 for ; Tue, 6 Jun 2006 13:20:05 -0700 (PDT) Received: from [192.9.61.110] (punchin-client-192-9-61-110.SFBay.Sun.COM [192.9.61.110]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56KK3hG263205; Tue, 6 Jun 2006 13:20:04 -0700 (PDT) Message-ID: <4485E314.90206@sun.com> Date: Tue, 06 Jun 2006 13:18:28 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Memishian CC: Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> In-Reply-To: <17541.56540.927450.330298@triplex.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 627 Peter Memishian wrote: > > I don't think you need anything that verbose, though; how about: > > > > VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence > > number: 0) > > That seems high-risk to me -- e.g., many test consolidation scripts have > knowledge of the basic structure of the snoop output format. But on the physical link, that's OK, because we probably would prefer these lines to appear anomalous to someone/something that is expecting plain IP packets. Making them look like normal IP packets when they aren't actually being delivered to IP is the problem to avoid. -=] Mike [=- From sacadmin Tue Jun 6 13:44:17 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56KiHQT009761 for ; Tue, 6 Jun 2006 13:44:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56KiGLx004590; Tue, 6 Jun 2006 16:44:16 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56KiFT1024949; Tue, 6 Jun 2006 16:44:15 -0400 (EDT) Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: James Carlson Cc: Peter Memishian , Dan Groves , Sebastien Roy , psarc , clearview-iteam In-Reply-To: <17541.57559.106076.337304@gargle.gargle.HOWL> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> Content-Type: text/plain Message-Id: <1149626655.19860.238.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Tue, 06 Jun 2006 16:44:15 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 656 On Tue, 2006-06-06 at 16:08, James Carlson wrote: > I'd agree that we don't normally allow changes to the default snoop > output in a patch (as it's too likely parsed by someone), but this one > seems less harmful to me than the usual case. Indeed. The packets it would choke on are the ones it wouldn't see at all before. A modestly robust snoop-output-parser should reset its parser for each line/packet and expect to not cope with certain packets, and these are precisely the packets they wouldn't have been exposed to earlier. A non-robust parser can be protected from seeing the new stuff via adding "not vlan" to the expression. - Bill From sacadmin Tue Jun 6 16:05:01 2006 Received: from sentry.SFBay.Sun.COM (sentry.SFBay.Sun.COM [129.146.157.28]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56N51sZ015174 for ; Tue, 6 Jun 2006 16:05:01 -0700 (PDT) Received: from [129.146.11.160] (sr1-umpk-04.SFBay.Sun.COM [129.146.11.160]) by sentry.SFBay.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k56N2fFZ000148; Tue, 6 Jun 2006 16:02:41 -0700 (PDT) Message-ID: <44860A17.7060105@Sun.COM> Date: Tue, 06 Jun 2006 16:04:55 -0700 From: Mike Ditto Reply-To: Michael.Ditto@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Groves CC: James Carlson , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> In-Reply-To: <4485E374.9030104@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1590 Dan Groves wrote On 06/06/06 13:20,: > If no objects, I could change it to: > > snoop can display packets in a single-line summary form or > in verbose multi-line forms. In summary form, only the data > pertaining to the highest level protocol is displayed; > however if the packet has a VLAN header that information > will be displayed. The problem with that is that the VLAN header is entirely uninteresting in summary form, *except* in the case of the physical link and a non-zero VLAN ID. I think there has to be some distinction between an incidental VLAN header that doesn't significantly change the meaning (recipient) of the packet and one that indicates that the packet is not actually part of the virtual link being observed. This problem arises because, as Erik notes, we don't have two different link devices for "physical LAN" and "VLAN 0", and the effective behavior is inconsistent: a user bound to a SAP effectively gets "VLAN 0" but snoop effectively gets "physical LAN". It's not just a display problem, it's also a filter problem: I should be able to use the interface name that shows up in ifconfig -a and get packets only for that link, but "snoop -d bge0 port 80" will also pick up packets from bge1000, which I don't want to see because IP doesn't see them either. One way to handle this is to have snoop apply a "not vlan or vlan 0" filter by default, but I don't know how to make that fit in with other user-supplied filter parameters. Is a new option, to be "VLAN promiscuous", in order here? -=] Mike [=- From sacadmin Tue Jun 6 16:12:23 2006 Received: from sentry.SFBay.Sun.COM (sentry.SFBay.Sun.COM [129.146.157.28]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56NCNSM015628 for ; Tue, 6 Jun 2006 16:12:23 -0700 (PDT) Received: from [129.146.11.160] (sr1-umpk-04.SFBay.Sun.COM [129.146.11.160]) by sentry.SFBay.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k56NA2gR000161; Tue, 6 Jun 2006 16:10:03 -0700 (PDT) Message-ID: <44860BD6.8080204@Sun.COM> Date: Tue, 06 Jun 2006 16:12:22 -0700 From: Mike Ditto Reply-To: Michael.Ditto@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: James Carlson , Cathy Zhou , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> <44854FB0.3010303@sun.com> In-Reply-To: <44854FB0.3010303@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1419 Erik Nordmark wrote On 06/06/06 02:49,: > James Carlson wrote: >> If the model is to behave as though you were attached to an untagged >> Ethernet interface on a VLAN-capable bridge ("switch"), then you would >> not have seen those tags, because the switch would strip them. >> Solaris should do the same. > > FWIW I think the above is the simplest model. It matches what we have > for IP/ARP usage of datalinks, yet still allows Xen/LDOMs to be attached > to a particular VLAN. In the long term, I think we want to attach Xen/LDOMs to MAC devices - either physical or virtual NICs, so the VLAN links don't come into play. But we will also be able to use a software bridge to connect a link device to a Xen/LDOM domain and in that case, yes, having the VLAN link device modify the headers on the fly allows simple connecting of domains to VLANs. > There are few cases where we need something different - one is "snoop > the wire" and another is is if we in the future want to build an > full-fledged Ethernet switch complete with dynamic VLAN membership e.g. > (a cases where we can benefit from a single datalink user receiving > packets for all VLAN tags.) The other major case is where the domain OS is VLAN-aware and wants to attach to multiple VLANs, just as if it were physically on the link. In that case, we want to direct an arbitrary set of VLAN IDs to a domain with tags intact. -=] Mike [=- From sacadmin Tue Jun 6 16:45:56 2006 Received: from sentry.SFBay.Sun.COM (sentry.SFBay.Sun.COM [129.146.157.28]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k56Nju5j015904 for ; Tue, 6 Jun 2006 16:45:56 -0700 (PDT) Received: from [129.146.11.160] (sr1-umpk-04.SFBay.Sun.COM [129.146.11.160]) by sentry.SFBay.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k56NhZZ9000255; Tue, 6 Jun 2006 16:43:35 -0700 (PDT) Message-ID: <448613B3.3020909@Sun.COM> Date: Tue, 06 Jun 2006 16:45:55 -0700 From: Mike Ditto Reply-To: Michael.Ditto@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Cathy Zhou , Erik Nordmark , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> In-Reply-To: <17539.12514.966647.736649@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4426 James Carlson wrote On 06/04/06 12:13,: > If the model is to allow access to all of the bits -- even those that > you would not normally be able to access if you were connected via a > switch -- then we need a much bigger redesign. This means that raw > users also need to know which VLAN ID is in use, and will need to know > when to generate headers. There are _no_ interfaces to do this today, > and the project would be incomplete as it stands if it tried to do > that. (As you note, adding new interfaces -- such as a new MAC type > -- could solve that newly-created problem.) I think a VLAN ID inquiry at the DLPI would be appropriate in any case. Unfortunately, the new MAC type isn't a perfect model, because it's not really true that all DL_ETHER headers are 14 bytes and all DL_ETHERVLAN headers are 18 bytes. RAW users still have to understand the VLAN headers. > Note that doing as you suggest _will_ also break existing raw users. > Those users expect to see normal Ethernet headers and will all need to > be modified to handle VLANs. Since they're _already_ selecting a > particular VLAN of interest implicitly by opening a VLAN-hack DLPI > node, why should they be forced to deal with the VLAN headers on each > packet as well? I think it's fair to expect raw users to deal with the raw link headers by default, and deal with special cases specially (when applying a traditional Ethernet application to traffic from a VLAN environment you might need a translator in between). > Furthermore, since there's no extra information here (it's already > filtered), whom are we helping? We help the network-layer software by stripping out the link-layer headers entirely. We help the link-layer-aware software by leaving the link-layer headers intact entirely. > Dups will still work. You don't need to copy the data to do this > right; just strip the header by advancing b_rptr and allocating a new > mblk. It's fairly cheap, other than a 14 byte copy (or, if you wish, > double-dup and no copy). I think that if we're worried about header > manipulation logic in the loopback snooping case, we're off the mark. > That's not where the expense of snoop lay. It means yet another way that observation changes the operation of the system: By snooping on the physical link, you cause a raw VLAN link user to start getting multi-block messages, because we couldn't modify the link header in place. >>As for the problem of how the DLS user can know what VID to use for >>transmitting, one solution is to require the user to fill in VID >>0, or just have the provider ignore user-specified VID and always fill >>it in with the correct value for the link. > > And modify it on the fly?! That doesn't sound right to me. It's less modification-on-the-fly than the alternative proposal. >> Although this does >>involve the DLPI provider modifying the header, it is done before the >>multiple dups may happen, so it doesn't necessitate additional >>copying. > > It will when db_ref > 1. It also just seems icky, particularly so > when both the VLAN ID and the traffic class are both zero. Such a > header is alien (you wouldn't encounter it on the wire), and forcing > users to generate it seems strange. But you'd have to copy in that case anyway in the alternative proposal. Thus no *additional* copying. > Plus, as noted above, it still breaks existing applications for no > apparent benefit. I'm skeptical that such applications (which use raw mode and parse Ethernet headers) have a reasonable expectation of running when the format of Ethernet headers changes, as it did with 802.1Q. Yes, it's useful for us to provide tools to translate/bridge between plain Ethernet networks and VLAN networks, I'm just not sure that the link device is the best place to do it. > So, how exactly is the "virtual switch" design really administratively > or behaviorally different from the existing VLAN hack design? One should be able to configure which applications ("ports") see which VLANs, with and without tags. > In both cases, you have separate 'physical' DLPI nodes that represent > VLANs. Why would the visible headers differ in the two cases? Because some users need to see the headers, and others must not see the headers. However, I'm sure we can make do either way, I am just putting my concerns out there and I don't have a major objection to the current proposal. -=] Mike [=- From sacadmin Tue Jun 6 19:25:48 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k572PmYM020416 for ; Tue, 6 Jun 2006 19:25:48 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k572Plma020578; Tue, 6 Jun 2006 22:25:47 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k572PlT7020575; Tue, 6 Jun 2006 22:25:47 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17542.14635.557945.483032@triplex.East.Sun.COM> Date: Tue, 6 Jun 2006 22:25:47 -0400 To: Mike Ditto Cc: Peter Memishian , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: <4485E314.90206@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 981 > > > VLAN#2: 192.168.2.66 -> 192.168.2.42 ICMP Echo reply (ID: 35096 Sequence > > > number: 0) > > > > That seems high-risk to me -- e.g., many test consolidation scripts have > > knowledge of the basic structure of the snoop output format. > > But on the physical link, that's OK, because we probably would prefer > these lines to appear anomalous to someone/something that is expecting > plain IP packets. Making them look like normal IP packets when they aren't > actually being delivered to IP is the problem to avoid. I am fine with calling packets out that are on a separate VLAN, but I do not see any relationship here with "delivery to IP". If there happens to be a "bge2000" IP interface, then the packets above will be delivered to IP; if not, they won't be. The same applies to someone snooping the bge2000 VLAN link: any IP packets viewed on that link may or may not be delivered to IP, depending on whether a bge2000 IP interface exists. -- meem From sacadmin Wed Jun 7 01:16:06 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k578G6go020437 for ; Wed, 7 Jun 2006 01:16:06 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k578G1MY164748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Jun 2006 01:16:03 -0700 (PDT) Message-ID: <44868B40.3090703@sun.com> Date: Wed, 07 Jun 2006 01:16:00 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Peter Memishian CC: Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> In-Reply-To: <17542.14635.557945.483032@triplex.East.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 974 Peter Memishian wrote: > I am fine with calling packets out that are on a separate VLAN, but I do > not see any relationship here with "delivery to IP". If there happens to > be a "bge2000" IP interface, then the packets above will be delivered to > IP; if not, they won't be. The same applies to someone snooping the > bge2000 VLAN link: any IP packets viewed on that link may or may not be > delivered to IP, depending on whether a bge2000 IP interface exists. The inconsistency is actually in the name space. Compare the following 4 uses of link names snoop -d bge2000 ifconfig bge2000 plumb snoop -d bge0 ifconfig bge0 plumb In the above bge2000 means VLAN tag #2 on bge0. But bge0 means different things with ifconfig and snoop. For ifconfig it is "no vlan" (no VLAN header or a VLAN header with tag=0). For snoop it means "everything on the wire". Will this inconsistency cause confusion for customers? Seems like BSD has the same inconsistency. Erik From sacadmin Wed Jun 7 01:18:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k578IKbO020485 for ; Wed, 7 Jun 2006 01:18:20 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k578IF0R165065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Jun 2006 01:18:17 -0700 (PDT) Message-ID: <44868BC6.2020600@sun.com> Date: Wed, 07 Jun 2006 01:18:14 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Michael.Ditto@sun.com CC: James Carlson , Cathy Zhou , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> <44854FB0.3010303@sun.com> <44860BD6.8080204@Sun.COM> In-Reply-To: <44860BD6.8080204@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 770 Mike Ditto wrote: > In the long term, I think we want to attach Xen/LDOMs to MAC devices - > either physical or virtual NICs, so the VLAN links don't come into play. > But we will also be able to use a software bridge to connect a link > device to a Xen/LDOM domain and in that case, yes, having the VLAN link > device modify the headers on the fly allows simple connecting of domains > to VLANs. This proposal doesn't prevent either AFAICT. > The other major case is where the domain OS is VLAN-aware and wants to > attach to multiple VLANs, just as if it were physically on the link. > In that case, we want to direct an arbitrary set of VLAN IDs to a > domain with tags intact. I don't see anything in this proposal that would prevent that in the future. Erik From sacadmin Wed Jun 7 03:18:13 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57AICgd022936 for ; Wed, 7 Jun 2006 03:18:13 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k57AI6es001033 for ; Wed, 7 Jun 2006 18:18:06 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0H00G01J9OI100@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 07 Jun 2006 18:18:06 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0H003NMJA15DB9@mail-apac.sun.com>; Wed, 07 Jun 2006 18:18:06 +0800 (SGT) Date: Wed, 07 Jun 2006 18:18:01 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <44868B40.3090703@sun.com> Sender: Cathy.Zhou@Sun.COM To: Erik Nordmark Cc: Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Message-id: <4486A7D9.6050307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 784 > The inconsistency is actually in the name space. > > Compare the following 4 uses of link names > snoop -d bge2000 > ifconfig bge2000 plumb > snoop -d bge0 > ifconfig bge0 plumb > > In the above bge2000 means VLAN tag #2 on bge0. > But bge0 means different things with ifconfig and snoop. For ifconfig it > is "no vlan" (no VLAN header or a VLAN header with tag=0). > For snoop it means "everything on the wire". > But we can look at this from another angle: even we leave VLAN packets aside, snoop means everything on the wire and ifconfig only sees IP packets. In my opinion, they are just different applications which are interested in packets of different SAP(s). Uses can use snoop filter to observe exactly packets they are interested. Thanks - Cathy From sacadmin Wed Jun 7 08:29:03 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57FT2r1001598 for ; Wed, 7 Jun 2006 08:29:03 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k57FThjt022807; Wed, 7 Jun 2006 11:29:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k57FTgQB022804; Wed, 7 Jun 2006 11:29:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17542.61669.961739.78806@gargle.gargle.HOWL> Date: Wed, 7 Jun 2006 11:29:41 -0400 From: James Carlson To: Erik Nordmark Cc: Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Erik Nordmark's message of 7 June 2006 01:16:00 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 968 Erik Nordmark writes: > But bge0 means different things with ifconfig and snoop. For ifconfig it > is "no vlan" (no VLAN header or a VLAN header with tag=0). > For snoop it means "everything on the wire". I don't agree. bge0 means the same thing in both cases -- it means the same thing as an "untagged port" on a switch. You see VLAN tags (with their proper VLAN SAP values) if there are VLAN packets. If there's IP with plain old Ethernet DIX headers, you see that too. The fact that IP is particularly interested in one SAP value and doesn't listen to them all shouldn't come as much of a surprise. > Will this inconsistency cause confusion for customers? > Seems like BSD has the same inconsistency. I see it as a consistency. ;-} -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jun 7 08:45:21 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57FjKO9002024 for ; Wed, 7 Jun 2006 08:45:20 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k57Fk0aF022901; Wed, 7 Jun 2006 11:46:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k57Fk0pb022898; Wed, 7 Jun 2006 11:46:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17542.62648.132716.668195@gargle.gargle.HOWL> Date: Wed, 7 Jun 2006 11:46:00 -0400 From: James Carlson To: Michael.Ditto@sun.com Cc: Cathy Zhou , Erik Nordmark , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Mike Ditto's message of 6 June 2006 16:45:55 References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> <448613B3.3020909@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 6590 Mike Ditto writes: > James Carlson wrote On 06/04/06 12:13,: > > If the model is to allow access to all of the bits -- even those that > > you would not normally be able to access if you were connected via a > > switch -- then we need a much bigger redesign. This means that raw > > users also need to know which VLAN ID is in use, and will need to know > > when to generate headers. There are _no_ interfaces to do this today, > > and the project would be incomplete as it stands if it tried to do > > that. (As you note, adding new interfaces -- such as a new MAC type > > -- could solve that newly-created problem.) > > I think a VLAN ID inquiry at the DLPI would be appropriate in any case. I don't. I think it significantly muddies the waters. > Unfortunately, the new MAC type isn't a perfect model, because it's not > really true that all DL_ETHER headers are 14 bytes and all DL_ETHERVLAN > headers are 18 bytes. RAW users still have to understand the VLAN > headers. Indeed. I think it's a mess, which is why I'm hoping we're not headed that direction. > > Note that doing as you suggest _will_ also break existing raw users. > > Those users expect to see normal Ethernet headers and will all need to > > be modified to handle VLANs. Since they're _already_ selecting a > > particular VLAN of interest implicitly by opening a VLAN-hack DLPI > > node, why should they be forced to deal with the VLAN headers on each > > packet as well? > > I think it's fair to expect raw users to deal with the raw link headers > by default, and deal with special cases specially (when applying a > traditional Ethernet application to traffic from a VLAN environment > you might need a translator in between). But if those same raw users were connected via an untagged port on a switch, the switch would be doing _exactly_ this modification on the fly. It's not an unexpected behavior. Why should it be "unexpected" behavior when the system emulates this functionality, but "expected" otherwise? Note that the non-raw DLPI user will not even know that tagging is going on. This is also very much like an untagged switch port, so the proposed model is self-consistent. > > Furthermore, since there's no extra information here (it's already > > filtered), whom are we helping? > > We help the network-layer software by stripping out the link-layer > headers entirely. We help the link-layer-aware software by leaving > the link-layer headers intact entirely. I disagree. We're hurting the latter case by making it appear different from the instance where the user is connected via an external switch that strips the tags. I see no administrative or client difference between the VLAN-hack PPAs and switch ports. > > Dups will still work. You don't need to copy the data to do this > > right; just strip the header by advancing b_rptr and allocating a new > > mblk. It's fairly cheap, other than a 14 byte copy (or, if you wish, > > double-dup and no copy). I think that if we're worried about header > > manipulation logic in the loopback snooping case, we're off the mark. > > That's not where the expense of snoop lay. > > It means yet another way that observation changes the operation of the > system: By snooping on the physical link, you cause a raw VLAN link > user to start getting multi-block messages, because we couldn't > modify the link header in place. That doesn't sound like an architectural issue to me. > >>As for the problem of how the DLS user can know what VID to use for > >>transmitting, one solution is to require the user to fill in VID > >>0, or just have the provider ignore user-specified VID and always fill > >>it in with the correct value for the link. > > > > And modify it on the fly?! That doesn't sound right to me. > > It's less modification-on-the-fly than the alternative proposal. I don't see how that makes it better or more coherent. > > It will when db_ref > 1. It also just seems icky, particularly so > > when both the VLAN ID and the traffic class are both zero. Such a > > header is alien (you wouldn't encounter it on the wire), and forcing > > users to generate it seems strange. > > But you'd have to copy in that case anyway in the alternative proposal. > Thus no *additional* copying. So, it's merely a matter of having the first 18 bytes in the "right" order that we can logically place them on the wire? I don't see how that's really an architectural argument. It sounds like the argument revolves around some notion of performance or efficiency, but I fail to see how that's really an important consideration here. We're talking about raw DLPI users opening up VLAN-hack PPAs. That shouldn't be a bulk interface. > > Plus, as noted above, it still breaks existing applications for no > > apparent benefit. > > I'm skeptical that such applications (which use raw mode and parse > Ethernet headers) have a reasonable expectation of running when the > format of Ethernet headers changes, as it did with 802.1Q. They most certainly do have that expectation when connecting to a switch port that does exactly this same kind of header manipulation for exactly the same purpose. > Yes, it's useful for us to provide tools to translate/bridge between > plain Ethernet networks and VLAN networks, I'm just not sure that the > link device is the best place to do it. Why? If we don't do it there, then what exactly do those nodes represent? What's the conceptual model? > > So, how exactly is the "virtual switch" design really administratively > > or behaviorally different from the existing VLAN hack design? > > One should be able to configure which applications ("ports") see which > VLANs, with and without tags. That's a different issue, and one that I think can't be solved with the existing VLAN hack design. I think you're talking about having alternate PPAs that represent filtered tagged ports -- where some subset of the VLANs are present, but not all of them. That sounds interesting, and perhaps useful, but unrelated to the current design. I'm somewhat reluctant to do a fundamental redesign of this project team's proposal on this mailing list. > However, I'm sure we can make do either way, I am just putting my > concerns out there and I don't have a major objection to the current > proposal. Would it be possible to discuss with the team and come back? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jun 7 08:45:56 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57FjuQu002153 for ; Wed, 7 Jun 2006 08:45:56 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k57FkaoS022909; Wed, 7 Jun 2006 11:46:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k57Fka0L022906; Wed, 7 Jun 2006 11:46:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17542.62683.596631.884265@gargle.gargle.HOWL> Date: Wed, 7 Jun 2006 11:46:35 -0400 From: James Carlson To: Erik Nordmark , Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: James Carlson's message of 7 June 2006 11:29:41 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 442 James Carlson writes: > bge0 means the same thing in both cases -- it means the same thing as > an "untagged port" on a switch. You see VLAN tags (with their proper ^^^^^^^^^^^^^ "tagged port" -- aka, a trunk. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jun 7 10:05:54 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57H5sVN007100 for ; Wed, 7 Jun 2006 10:05:54 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k57H5sRY021739 for ; Wed, 7 Jun 2006 10:05:54 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k57H5sm0025104 for ; Wed, 7 Jun 2006 11:05:54 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0I00F011NZJC00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.SFBay.Sun.COM; Wed, 07 Jun 2006 11:05:54 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0I009TB25SLT10@mail-amer.sun.com>; Wed, 07 Jun 2006 11:05:53 -0600 (MDT) Date: Wed, 07 Jun 2006 13:06:01 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <44860A17.7060105@Sun.COM> Sender: Daniel.Groves@Sun.COM To: Michael.Ditto@Sun.COM Cc: James Carlson , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <44870779.1070108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 3226 Mike Ditto wrote: > Dan Groves wrote On 06/06/06 13:20,: >> If no objects, I could change it to: >> >> snoop can display packets in a single-line summary form or >> in verbose multi-line forms. In summary form, only the data >> pertaining to the highest level protocol is displayed; >> however if the packet has a VLAN header that information >> will be displayed. > > The problem with that is that the VLAN header is entirely uninteresting > in summary form, *except* in the case of the physical link and a > non-zero VLAN ID. I think there has to be some distinction between > an incidental VLAN header that doesn't significantly change the meaning > (recipient) of the packet and one that indicates that the packet is not > actually part of the virtual link being observed. This problem arises > because, as Erik notes, we don't have two different link devices for > "physical LAN" and "VLAN 0", and the effective behavior is inconsistent: > a user bound to a SAP effectively gets "VLAN 0" but snoop effectively > gets "physical LAN". > On a physical link, the proposal is to always leave the VLAN header alone. So if a user was executing snoop on the physical link, they'll see the VLAN information in summary mode. On the VLAN link, we will strip out the VLAN header unless the priority bits are non-zero. If the priority bits are zero, the user will not see any extra text. I could modify the proposed behavior change to handle the non-zero priority bits case. Since here the stream sets the VLAN ID to zero, we could easily take care of this. My new proposal: snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, only the data pertaining to the highest level protocol is displayed. Except that if the packet has a VLAN header and its VLAN ID is non-zero then snoop will show that the packet is VLAN tagged. > It's not just a display problem, it's also a filter problem: I should be > able to use the interface name that shows up in ifconfig -a and get packets > only for that link, but "snoop -d bge0 port 80" will also pick up packets > from bge1000, which I don't want to see because IP doesn't see them either. > Cathy mentioned in another response that snoop and ifconfig should see different things because they are interested in different things. > One way to handle this is to have snoop apply a "not vlan or vlan 0" > filter by default, but I don't know how to make that fit in with other > user-supplied filter parameters. Is a new option, to be "VLAN > promiscuous", > in order here? > I see. Let me see if I understand. Your proposal is that, by default, if snoop is attached to the physical interface that snoop would behave as if the user applied a "not vlan" expression ("not vlan" means packets whose ethertype is not VLAN or packets whose ethertype is VLAN and whose VLAN ID is zero, which is what I think you mean by "not vlan or vlan 0"). If the user wanted to see all the VLAN tagged packets, then they would use a separate command line option. Am I correct? Dan > -=] Mike [=- > From sacadmin Wed Jun 7 10:12:43 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57HCh0k007747 for ; Wed, 7 Jun 2006 10:12:43 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k57HCgsw010770 for ; Wed, 7 Jun 2006 10:12:43 -0700 (PDT) Received: from d1-emea-04.sun.com ([192.18.2.114]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k57HCaM3023570 for ; Wed, 7 Jun 2006 18:12:37 +0100 (BST) Received: from conversion-daemon.d1-emea-04.sun.com by d1-emea-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0I00C011K7UP00@d1-emea-04.sun.com> (original mail from dme@sun.com) for psarc@sac.sfbay.sun.com; Wed, 07 Jun 2006 18:12:36 +0100 (BST) Received: from [10.0.1.7] ([84.9.60.139]) by d1-emea-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0I00KU72H01970@d1-emea-04.sun.com>; Wed, 07 Jun 2006 18:12:36 +0100 (BST) Date: Wed, 07 Jun 2006 18:12:34 +0100 From: David Edmondson Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <44870779.1070108@sun.com> Sender: David.Edmondson@sun.com To: Mike Ditto Cc: psarc , clearview-iteam Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> Status: RO Content-Length: 435 >> It's not just a display problem, it's also a filter problem: I >> should be >> able to use the interface name that shows up in ifconfig -a and >> get packets >> only for that link, but "snoop -d bge0 port 80" will also pick up >> packets >> from bge1000, which I don't want to see because IP doesn't see >> them either. If you care particularly about what IP is seeing, shouldn't you be using -I rather than -d? dme. From sacadmin Wed Jun 7 10:49:49 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57Hnm9v009124 for ; Wed, 7 Jun 2006 10:49:48 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k57HnmOK022397; Wed, 7 Jun 2006 13:49:48 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k57HnltB022394; Wed, 7 Jun 2006 13:49:48 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17543.4539.927224.502543@triplex.East.Sun.COM> Date: Wed, 7 Jun 2006 13:49:47 -0400 To: David Edmondson Cc: Mike Ditto , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 649 > >> It's not just a display problem, it's also a filter problem: I > >> should be > >> able to use the interface name that shows up in ifconfig -a and > >> get packets > >> only for that link, but "snoop -d bge0 port 80" will also pick up > >> packets > >> from bge1000, which I don't want to see because IP doesn't see > >> them either. > > If you care particularly about what IP is seeing, shouldn't you be > using -I rather than -d? Since we have not yet ARC'd -I, I didn't want to drag this in -- but yes, that's one possibility for the future. That said, with -I you will not see link-layer headers at all. -- meem From sacadmin Wed Jun 7 13:28:44 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KSi86016899 for ; Wed, 7 Jun 2006 13:28:44 -0700 (PDT) Received: from [192.9.61.110] (punchin-client-192-9-61-110.SFBay.Sun.COM [192.9.61.110]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KShEO492489; Wed, 7 Jun 2006 13:28:43 -0700 (PDT) Message-ID: <4487369B.3080003@sun.com> Date: Wed, 07 Jun 2006 13:27:07 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Groves CC: James Carlson , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> In-Reply-To: <44870779.1070108@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1568 Dan Groves wrote: > On the VLAN link, we will strip out the VLAN header unless the priority > bits are non-zero. If the priority bits are zero, the user will not see > any extra text. I could modify the proposed behavior change to handle > the non-zero priority bits case. Since here the stream sets the VLAN ID > to zero, we could easily take care of this. My new proposal: > > snoop can display packets in a single-line summary form or > in verbose multi-line forms. In summary form, only the data > pertaining to the highest level protocol is displayed. > Except that if the packet has a VLAN header and its VLAN ID > is non-zero then snoop will show that the packet is VLAN > tagged. That sounds fine. > Your proposal is that, by default, if snoop is attached to the physical > interface that snoop would behave as if the user applied a "not vlan" > expression ("not vlan" means packets whose ethertype is not VLAN or > packets whose ethertype is VLAN and whose VLAN ID is zero, which is what > I think you mean by "not vlan or vlan 0"). If the user wanted to see > all the VLAN tagged packets, then they would use a separate command line > option. > > Am I correct? Yes, but your revised proposal satisfies me too; it prevents the confusion that I'm concerned about (IP packets from other VLANs being displayed by snoop indistinguishably from those actually on the IP SAP) and doesn't display irrelevant VLAN stuff on VLAN links (because the tags aren't there). -=] Mike [=- From sacadmin Wed Jun 7 13:33:09 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KX90w016939 for ; Wed, 7 Jun 2006 13:33:09 -0700 (PDT) Received: from [192.9.61.110] (punchin-client-192-9-61-110.SFBay.Sun.COM [192.9.61.110]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KX81B497778; Wed, 7 Jun 2006 13:33:08 -0700 (PDT) Message-ID: <448737A5.8050800@sun.com> Date: Wed, 07 Jun 2006 13:31:33 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Cathy Zhou , Erik Nordmark , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <447CC090.4030702@sun.com> <447DA187.3050005@sun.com> <447E12F9.4090001@sun.com> <447E77CA.2090500@sun.com> <4480DD3C.3060302@Sun.COM> <17539.12514.966647.736649@gargle.gargle.HOWL> <448613B3.3020909@Sun.COM> <17542.62648.132716.668195@gargle.gargle.HOWL> In-Reply-To: <17542.62648.132716.668195@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 412 James Carlson wrote: >>However, I'm sure we can make do either way, I am just putting my >>concerns out there and I don't have a major objection to the current >>proposal. > > Would it be possible to discuss with the team and come back? I don't think that's necessary; the project team and PSARC seem to be happy with the new spec and I don't see any actual problems worth pursuing further. -=] Mike [=- From sacadmin Wed Jun 7 13:35:38 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KZcru017037 for ; Wed, 7 Jun 2006 13:35:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k57KZcuY029165 for ; Wed, 7 Jun 2006 13:35:38 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k57KZbvn002878 for ; Wed, 7 Jun 2006 14:35:37 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0I00D01BMRB800@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 07 Jun 2006 14:35:37 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0I004VYBVCKRO4@mail-amer.sun.com>; Wed, 07 Jun 2006 14:35:37 -0600 (MDT) Date: Wed, 07 Jun 2006 16:35:44 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <4487369B.3080003@sun.com> Sender: Daniel.Groves@Sun.COM To: Mike Ditto Cc: James Carlson , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <448738A0.1070403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1703 Mike Ditto wrote: > Dan Groves wrote: >> On the VLAN link, we will strip out the VLAN header unless the >> priority bits are non-zero. If the priority bits are zero, the user >> will not see any extra text. I could modify the proposed behavior >> change to handle the non-zero priority bits case. Since here the >> stream sets the VLAN ID to zero, we could easily take care of this. >> My new proposal: >> >> snoop can display packets in a single-line summary form or >> in verbose multi-line forms. In summary form, only the data >> pertaining to the highest level protocol is displayed. >> Except that if the packet has a VLAN header and its VLAN ID >> is non-zero then snoop will show that the packet is VLAN >> tagged. > > That sounds fine. > >> Your proposal is that, by default, if snoop is attached to the >> physical interface that snoop would behave as if the user applied a >> "not vlan" expression ("not vlan" means packets whose ethertype is not >> VLAN or packets whose ethertype is VLAN and whose VLAN ID is zero, >> which is what I think you mean by "not vlan or vlan 0"). If the user >> wanted to see all the VLAN tagged packets, then they would use a >> separate command line option. >> >> Am I correct? > > Yes, but your revised proposal satisfies me too; it prevents the confusion > that I'm concerned about (IP packets from other VLANs being displayed by > snoop indistinguishably from those actually on the IP SAP) and doesn't > display irrelevant VLAN stuff on VLAN links (because the tags aren't > there). > OK then, I'll add the revised proposal to the case. > -=] Mike [=- From sacadmin Wed Jun 7 13:39:36 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57Kdaas017113 for ; Wed, 7 Jun 2006 13:39:36 -0700 (PDT) Received: from [192.9.61.110] (punchin-client-192-9-61-110.SFBay.Sun.COM [192.9.61.110]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57KdaeA508953; Wed, 7 Jun 2006 13:39:36 -0700 (PDT) Message-ID: <44873928.5060107@sun.com> Date: Wed, 07 Jun 2006 13:38:00 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Edmondson CC: psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 434 David Edmondson wrote: > If you care particularly about what IP is seeing, shouldn't you be > using -I rather than -d? In many cases, yes, -I will give exactly the traffic set that is desired and avoid the capture of irrelevant tagged packets that otherwise match the filter. But it's not adequate if I care about link-layer headers or ARP, or want to see some of the other traffic on the link at the same time. -=] Mike [=- From sacadmin Wed Jun 7 14:13:02 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57LD2tg019428 for ; Wed, 7 Jun 2006 14:13:02 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k57LDgKa024466; Wed, 7 Jun 2006 17:13:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k57LDg7O024463; Wed, 7 Jun 2006 17:13:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17543.16772.105666.123178@gargle.gargle.HOWL> Date: Wed, 7 Jun 2006 17:13:40 -0400 From: James Carlson To: Mike Ditto Cc: Dan Groves , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Mike Ditto's message of 7 June 2006 13:27:07 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1290 Mike Ditto writes: > > Your proposal is that, by default, if snoop is attached to the physical > > interface that snoop would behave as if the user applied a "not vlan" > > expression ("not vlan" means packets whose ethertype is not VLAN or > > packets whose ethertype is VLAN and whose VLAN ID is zero, which is what > > I think you mean by "not vlan or vlan 0"). If the user wanted to see > > all the VLAN tagged packets, then they would use a separate command line > > option. > > > > Am I correct? > > Yes, but your revised proposal satisfies me too; it prevents the confusion > that I'm concerned about (IP packets from other VLANs being displayed by > snoop indistinguishably from those actually on the IP SAP) and doesn't > display irrelevant VLAN stuff on VLAN links (because the tags aren't > there). Doesn't that break Bill's request? What must the user do to see what's _really_ on the wire, and is it _ever_ valid for snoop to fail to show you what's on the wire? I'm not sure that your requested change helps here. I rather think it hurts. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jun 7 14:25:06 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57LP61e019757 for ; Wed, 7 Jun 2006 14:25:06 -0700 (PDT) Received: from [192.9.61.110] (punchin-client-192-9-61-110.SFBay.Sun.COM [192.9.61.110]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57LP5eL568958; Wed, 7 Jun 2006 14:25:05 -0700 (PDT) Message-ID: <448743D1.6040404@sun.com> Date: Wed, 07 Jun 2006 14:23:29 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Dan Groves , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> In-Reply-To: <17543.16772.105666.123178@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1195 James Carlson wrote: > Mike Ditto writes: >>Yes, but your revised proposal satisfies me too; it prevents the confusion >>that I'm concerned about (IP packets from other VLANs being displayed by >>snoop indistinguishably from those actually on the IP SAP) and doesn't >>display irrelevant VLAN stuff on VLAN links (because the tags aren't >>there). > > Doesn't that break Bill's request? I don't think so; it seems to eliminate the problem that Bill and I were concerned about. Now, if you snoop the physical link, you see all packets, but packets for other VLANs are clearly marked to avoid confusion. When -v is used, the entire, untampered-with link header is completely displayed. > What must the user do to see what's _really_ on the wire, and is it > _ever_ valid for snoop to fail to show you what's on the wire? Snooping the physical link still gives you every bit that's on the wire, and snoop will show you everything that's appropriate for the selected form, "plus more" - in summary form it will additionally display the VLAN tag in the case that the VLAN tag might (probably does) prevent the packet from having the interpretation that the summary suggests. -=] Mike [=- From sacadmin Thu Jun 8 04:57:59 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58BvxaJ014092 for ; Thu, 8 Jun 2006 04:57:59 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58BweEr025870; Thu, 8 Jun 2006 07:58:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58BweJ5025867; Thu, 8 Jun 2006 07:58:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.4336.327203.2207@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 07:58:40 -0400 From: James Carlson To: Mike Ditto Cc: Dan Groves , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Mike Ditto's message of 7 June 2006 14:23:29 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 998 Mike Ditto writes: > I don't think so; it seems to eliminate the problem that Bill and I were > concerned about. Now, if you snoop the physical link, you see all packets, > but packets for other VLANs are clearly marked to avoid confusion. When > -v is used, the entire, untampered-with link header is completely displayed. I'm confused. I could have sworn that you asked Dan to add an implicit "not vlan" to the default invocation of snoop. And Dan's response seemed to say that this is what he was going to do. This breaks Bill's request, as it makes it impossible to see VLAN traffic by default. The user will have to give a new flag to turn off the implicit "not vlan" statement. Bill's request was to make VLAN traffic distinguishable, not remove it entirely. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 06:43:53 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58DhrWb016066 for ; Thu, 8 Jun 2006 06:43:53 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k58Dhqvr018142 for ; Thu, 8 Jun 2006 06:43:53 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k58DhpXR024637 for ; Thu, 8 Jun 2006 07:43:52 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0J00J01NGEEX00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 08 Jun 2006 07:43:51 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0J00DFTNH2EEO4@mail-amer.sun.com>; Thu, 08 Jun 2006 07:43:51 -0600 (MDT) Date: Thu, 08 Jun 2006 09:43:58 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <17544.4336.327203.2207@gargle.gargle.HOWL> Sender: Daniel.Groves@Sun.COM To: James Carlson Cc: Mike Ditto , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <4488299E.3040300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1922 James Carlson wrote: > Mike Ditto writes: >> I don't think so; it seems to eliminate the problem that Bill and I were >> concerned about. Now, if you snoop the physical link, you see all packets, >> but packets for other VLANs are clearly marked to avoid confusion. When >> -v is used, the entire, untampered-with link header is completely displayed. > > I'm confused. > > I could have sworn that you asked Dan to add an implicit "not vlan" to > the default invocation of snoop. And Dan's response seemed to say > that this is what he was going to do. > > This breaks Bill's request, as it makes it impossible to see VLAN > traffic by default. The user will have to give a new flag to turn off > the implicit "not vlan" statement. > Sorry, I should have been a little clearer in my response to Mike. I am going to revise the snoop man page to state: snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, only the data pertaining to the highest level protocol is displayed. Except that if the packet has a VLAN header and its VLAN ID is non-zero then snoop will show that the packet is VLAN tagged. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed (except for VLAN information under the conditions stated earlier) but can be displayed if either of the verbose options are chosen. I will not add an implicit "not vlan" to the default invocation of snoop. My understanding of Mike's mail (dated 6/07/06 16:27 whose message id is 4487369B.3080003@sun.com) is simply changing the man page to include the text above (and then make snoop do that) is sufficient to address his concerns. > Bill's request was to make VLAN traffic distinguishable, not remove it > entirely. > From sacadmin Thu Jun 8 06:49:12 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58DnCkc016106 for ; Thu, 8 Jun 2006 06:49:12 -0700 (PDT) Received: from [129.157.211.161] (dhcp-gnb07-211-161.France.Sun.COM [129.157.211.161]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58Dn8cS883921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 8 Jun 2006 06:49:10 -0700 (PDT) Message-ID: <44882ACF.3020803@sun.com> Date: Thu, 08 Jun 2006 06:49:03 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> In-Reply-To: <17542.61669.961739.78806@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1322 James Carlson wrote: > Erik Nordmark writes: >> But bge0 means different things with ifconfig and snoop. For ifconfig it >> is "no vlan" (no VLAN header or a VLAN header with tag=0). >> For snoop it means "everything on the wire". > > I don't agree. > > bge0 means the same thing in both cases -- it means the same thing as > an "untagged port" on a switch. You see VLAN tags (with their proper > VLAN SAP values) if there are VLAN packets. If there's IP with plain > old Ethernet DIX headers, you see that too. > > The fact that IP is particularly interested in one SAP value and > doesn't listen to them all shouldn't come as much of a surprise. I brought up a potential concern from a users perspective that might be an approachability issue. I find it concerning that both you and Cathy explain or dismiss this by referring to implementation artifacts like DLPI SAPs and the like. I don't think the users know or care about DLPI SAPs. Can I please speak to somebody who considers the approachability issues the users might be facing? (with tongue firmly planted in cheek) ;-) I have no problem improving the observability of the system by somehow allowing a snoop on bge0 to see packets for all the VLANs. But I remain concerned that if this is the default behavior it might confuse users. Erik From sacadmin Thu Jun 8 07:06:24 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58E6NT9016914 for ; Thu, 8 Jun 2006 07:06:24 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58E76S1026218; Thu, 8 Jun 2006 10:07:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58E76R9026215; Thu, 8 Jun 2006 10:07:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.12041.397991.442908@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 10:07:05 -0400 From: James Carlson To: Erik Nordmark Cc: Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Erik Nordmark's message of 8 June 2006 06:49:03 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3735 Erik Nordmark writes: > James Carlson wrote: > > Erik Nordmark writes: > >> But bge0 means different things with ifconfig and snoop. For ifconfig it > >> is "no vlan" (no VLAN header or a VLAN header with tag=0). > >> For snoop it means "everything on the wire". > > > > I don't agree. > > > > bge0 means the same thing in both cases -- it means the same thing as > > an "untagged port" on a switch. You see VLAN tags (with their proper > > VLAN SAP values) if there are VLAN packets. If there's IP with plain > > old Ethernet DIX headers, you see that too. > > > > The fact that IP is particularly interested in one SAP value and > > doesn't listen to them all shouldn't come as much of a surprise. > > I brought up a potential concern from a users perspective that might be > an approachability issue. > > I find it concerning that both you and Cathy explain or dismiss this by > referring to implementation artifacts like DLPI SAPs and the like. I > don't think the users know or care about DLPI SAPs. I don't think that SAPs (or more accurately Ethertypes) are mere artifacts. Users who do anything with VLANs end up needing to know the difference between "native encapsulations" and "VLAN-tagged packets," and they end up finding out that if something's "VLAN-tagged," then you don't ordinarily see the traffic inside. You must be "on the VLAN" to see it. > Can I please speak to somebody who considers the approachability issues > the users might be facing? (with tongue firmly planted in cheek) ;-) I'm having a hard time ignoring that comment. > I have no problem improving the observability of the system by somehow > allowing a snoop on bge0 to see packets for all the VLANs. > > But I remain concerned that if this is the default behavior it might > confuse users. I do not believe that this is a legitimate concern. The reason I believe this is that the user _must_ deliberately connect his system to a trunk-type port in his network in order to see VLAN tags at all. The default behavior of common switches is to dedicate individual ports to particular VLAN tags -- "untagged mode" -- where the attached systems do _NOT_ see the VLAN tags. You have to do something special to get to the place where you see them at all. If a user is deliberately connected to such a network, I find it very, very strange that the user would end up being "confused" by seeing VLAN traffic. In fact, I think exactly the opposite is true: omitting the VLAN traffic makes the user think (and rightly so!) that snoop lies. Having diagnostic tools that lie to the user is unhelpful. If you're on a trunk port, why would you expect snoop to show you *ONLY* the untagged traffic? In most networks, there is no untagged traffic on trunk ports, so you'd likely see nothing at all, which would be most baffling. Furthermore, if you're on a trunk port, why would you plumb up IP without specifying any sort of VLAN tag, and then be surprised that IP sees only the untagged traffic? There's no other VLAN representation in Solaris (IP isn't in on the game, and that's clear from reading ifconfig(1M)), so why would you end up expecting it to "see" traffic on VLANs as well? Finally, the way it's been defined here happens to be the way it also works on other systems. As an approachability issue, I think it would be *EXTREMELY* confusing if Solaris were oddly different from all other operating systems. We shouldn't be going out of our way to make Solaris be the odd man out on the network. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 07:06:39 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58E6dqe016926 for ; Thu, 8 Jun 2006 07:06:39 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58E7MRc026224; Thu, 8 Jun 2006 10:07:22 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58E7Mmp026221; Thu, 8 Jun 2006 10:07:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.12057.986927.130730@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 10:07:21 -0400 From: James Carlson To: Dan Groves Cc: Mike Ditto , Peter Memishian , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Dan Groves's message of 8 June 2006 09:43:58 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 594 Dan Groves writes: > I will not add an implicit "not vlan" to the default invocation of snoop. > > My understanding of Mike's mail (dated 6/07/06 16:27 whose message id is > 4487369B.3080003@sun.com) is simply changing the man page to include the > text above (and then make snoop do that) is sufficient to address his > concerns. Thanks; that clears it up for me. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 08:17:55 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58FHsMw022839 for ; Thu, 8 Jun 2006 08:17:54 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58FHLcu104149; Thu, 8 Jun 2006 15:17:21 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k58FHLpn104148; Thu, 8 Jun 2006 11:17:21 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: James Carlson Cc: Dan Groves , Mike Ditto , Peter Memishian , Sebastien Roy , psarc , clearview-iteam In-Reply-To: <17544.12057.986927.130730@gargle.gargle.HOWL> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> <17544.12057.986927.130730@gargle.gargle.HOWL> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1149779840.103968.81.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.340 Date: Thu, 08 Jun 2006 11:17:20 -0400 Status: RO Content-Length: 476 On Thu, 2006-06-08 at 10:07, James Carlson wrote: > Dan Groves writes: > > I will not add an implicit "not vlan" to the default invocation of snoop. > > > > My understanding of Mike's mail (dated 6/07/06 16:27 whose message id is > > 4487369B.3080003@sun.com) is simply changing the man page to include the > > text above (and then make snoop do that) is sufficient to address his > > concerns. > > Thanks; that clears it up for me. .. and for me as well. - Bill From sacadmin Thu Jun 8 08:54:36 2006 Received: from albian-mail.SFbay.Sun.COM (albian-mail.SFBay.Sun.COM [10.11.30.12]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58Fsa5g024439 for ; Thu, 8 Jun 2006 08:54:36 -0700 (PDT) Received: from [192.168.100.80] (vpn-129-150-22-140.SFBay.Sun.COM [129.150.22.140]) by albian-mail.SFbay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k58FsY1R010666; Thu, 8 Jun 2006 08:54:34 -0700 (PDT) In-Reply-To: <4488299E.3040300@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> Cc: Sebastien Roy , psarc , clearview-iteam Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: 2006/358 VLAN Observability Enhancement Date: Thu, 8 Jun 2006 08:54:32 -0700 To: Dan Groves X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 1536 On Jun 8, 2006, at 6:43 AM, Dan Groves wrote: > I am going to revise the snoop man page to state: Question: Will this get put into the release notes as well? On Jun 8, 2006, at 7:07 AM, James Carlson wrote: > I do not believe that this is a legitimate concern. The reason I > believe this is that the user _must_ deliberately connect his system > to a trunk-type port in his network in order to see VLAN tags at all. Err, "person who sets up VLAN" == "person who admins box" is not always true. Definitely not true in all of Sun's labs or even in our data centers. While one may have root on my machine to do whatever, the network ports may be setup by someone else. That person is going to be using snoop to debug their traffic and will likely get confused when they see the VLAN traffic. That said, I'd be more comfortable with this going forward so long as: - It doesn't get changed in a patch or an update release of S10. I know this goes against the requested binding, but this change feels pretty significant from a 'surprise' element. - The single line output really needs to have the VLAN identified. - This really needs the 'not vlan' to make this functional for when you do just want that interface's traffic. [I can barely remember my own phone number. I'm not going to remember 'not ethertype 0xabc' or whatever.] But I'm just -interest, so I know my views are mostly meaningless... Procedural Question: Is this still a fast-track given the size of the mail log? ;) From sacadmin Thu Jun 8 09:13:20 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58GDKZ1025832 for ; Thu, 8 Jun 2006 09:13:20 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k58GDJnI028582 for ; Thu, 8 Jun 2006 09:13:19 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k58GDJwM012296 for ; Thu, 8 Jun 2006 10:13:19 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0J00101U1IRY00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 08 Jun 2006 10:13:19 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0J00M7JUE6IGV4@mail-amer.sun.com>; Thu, 08 Jun 2006 10:13:19 -0600 (MDT) Date: Thu, 08 Jun 2006 12:13:26 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> Sender: Daniel.Groves@Sun.COM To: Allen Wittenauer Cc: Sebastien Roy , psarc , clearview-iteam Message-id: <44884CA6.3010702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2477 Allen Wittenauer wrote: > > On Jun 8, 2006, at 6:43 AM, Dan Groves wrote: >> I am going to revise the snoop man page to state: > > Question: > > Will this get put into the release notes as well? > If it's felt to be necessary, then we can arrange it. Originally we hadn't planned on it, but if there's a need for it, we can change and plan for it. > On Jun 8, 2006, at 7:07 AM, James Carlson wrote: > >> I do not believe that this is a legitimate concern. The reason I >> believe this is that the user _must_ deliberately connect his system >> to a trunk-type port in his network in order to see VLAN tags at all. > > Err, "person who sets up VLAN" == "person who admins box" is not > always true. Definitely not true in all of Sun's labs or even in our > data centers. While one may have root on my machine to do whatever, the > network ports may be setup by someone else. That person is going to be > using snoop to debug their traffic and will likely get confused when > they see the VLAN traffic. > > That said, I'd be more comfortable with this going forward so long as: > > - It doesn't get changed in a patch or an update release of > S10. I know this goes against the requested binding, but this change > feels pretty significant from a 'surprise' element. We had asked for the patch binding so that if a customer wants the functionality now, for example in S10, that someone in sustaining could backport the change to an earlier release. We know that customers have asked for the ability to see VLAN traffic, for example see CR 4095699. > - The single line output really needs to have the VLAN > identified. We will do that. I'm going to start the code changes in my workspace today. I've already written a proposed change to the snoop man page which I will incorporate in the case spec. > - This really needs the 'not vlan' to make this functional > for when you do just want that interface's traffic. [I can barely > remember my own phone number. I'm not going to remember 'not ethertype > 0xabc' or whatever.] > Already added to the spec, and I've made the code changes in my workspace. So far they've passed the tests I've thrown at them. > But I'm just -interest, so I know my views are mostly meaningless... > > Procedural Question: > > Is this still a fast-track given the size of the mail log? ;) > > I'll let someone else answer this. From sacadmin Thu Jun 8 09:25:33 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58GPXh8026874 for ; Thu, 8 Jun 2006 09:25:33 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k58GPX8b005449 for ; Thu, 8 Jun 2006 09:25:33 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k58GPX8P023717 for ; Thu, 8 Jun 2006 10:25:33 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0J00H01UL8ZB00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 08 Jun 2006 10:25:32 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0J0095GUYILTR0@mail-amer.sun.com>; Thu, 08 Jun 2006 10:25:31 -0600 (MDT) Date: Thu, 08 Jun 2006 12:24:30 -0400 From: Sebastien Roy Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> Sender: Sebastien.Roy@Sun.COM To: Allen Wittenauer Cc: Dan Groves , psarc , clearview-iteam Message-id: <1149783870.3015.8.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> Status: RO Content-Length: 225 On Thu, 2006-06-08 at 08:54 -0700, Allen Wittenauer wrote: > Procedural Question: > > Is this still a fast-track given the size of the mail log? ;) The case hasn't been derailed, so yes, it's still a fast-track. -Seb From sacadmin Thu Jun 8 10:48:00 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58Hlxga016086 for ; Thu, 8 Jun 2006 10:48:00 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58Hmgsv027008; Thu, 8 Jun 2006 13:48:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58HmgJF027005; Thu, 8 Jun 2006 13:48:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.25338.602684.746761@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 13:48:42 -0400 From: James Carlson To: Sebastien Roy Cc: Allen Wittenauer , Dan Groves , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Sebastien Roy's message of 8 June 2006 12:24:30 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> <1149783870.3015.8.camel@localhost> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 799 Sebastien Roy writes: > On Thu, 2006-06-08 at 08:54 -0700, Allen Wittenauer wrote: > > Procedural Question: > > > > Is this still a fast-track given the size of the mail log? ;) > > The case hasn't been derailed, so yes, it's still a fast-track. That wasn't the question. The question was whether there's just been too much discussion on the case and it would be better off reviewed as a full case. I don't think we're at that point (as it seems we've mostly converged on just one issue), but if it doesn't finish up soon, it'd probably be better off going that way. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 10:49:59 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58Hnw2X019774 for ; Thu, 8 Jun 2006 10:49:58 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58HofGr027014; Thu, 8 Jun 2006 13:50:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58HofYM027011; Thu, 8 Jun 2006 13:50:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.25457.519174.990659@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 13:50:41 -0400 From: James Carlson To: Dan Groves Cc: Allen Wittenauer , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Dan Groves's message of 8 June 2006 12:13:26 References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <17541.57559.106076.337304@gargle.gargle.HOWL> <4485E374.9030104@sun.com> <44860A17.7060105@Sun.COM> <44870779.1070108@sun.com> <4487369B.3080003@sun.com> <17543.16772.105666.123178@gargle.gargle.HOWL> <448743D1.6040404@sun.com> <17544.4336.327203.2207@gargle.gargle.HOWL> <4488299E.3040300@sun.com> <23E9E07B-0C43-4166-A722-837BC2F81BA0@sun.com> <44884CA6.3010702@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 978 Dan Groves writes: > > - It doesn't get changed in a patch or an update release of > > S10. I know this goes against the requested binding, but this change > > feels pretty significant from a 'surprise' element. > > We had asked for the patch binding so that if a customer wants the > functionality now, for example in S10, that someone in sustaining could > backport the change to an earlier release. We know that customers have > asked for the ability to see VLAN traffic, for example see CR 4095699. And, in fact, they're much more surprised that VLANs on the wire are _not_ visible when snooping the wire. I feel that's really more of a defect than a feature because there shouldn't be anything that skulks under snoop's radar. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 11:56:55 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58Iutkw019065 for ; Thu, 8 Jun 2006 11:56:55 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k58IuntN363624; Thu, 8 Jun 2006 11:56:54 -0700 (PDT) Message-Id: <200606081856.k58IuntN363624@jurassic.eng.sun.com> Date: Thu, 8 Jun 2006 08:56:23 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/358 VLAN Observability Enhancement To: Sebastien.Roy@sun.com, james.d.carlson@sun.com Cc: allenw@sun.com, Daniel.Groves@sun.com, psarc@sac.sfbay.sun.com, clearview-iteam@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: upQHJXhqPjJJXjOtNvNCcg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 228 > From: James Carlson ... > I don't think we're at that point (as it seems we've mostly converged > on just one issue), ... Hopefully, that's "converged on **all but** just one issue". 8^) - jek3 From sacadmin Thu Jun 8 11:59:21 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k58IxLsV019195 for ; Thu, 8 Jun 2006 11:59:21 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k58J02oW027864; Thu, 8 Jun 2006 15:00:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k58J01Ln027861; Thu, 8 Jun 2006 15:00:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.29614.868195.445274@gargle.gargle.HOWL> Date: Thu, 8 Jun 2006 14:59:58 -0400 From: James Carlson To: Joseph Kowalski Cc: Sebastien.Roy@sun.com, allenw@sun.com, Daniel.Groves@sun.com, psarc@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/358 VLAN Observability Enhancement In-Reply-To: Joseph Kowalski's message of 8 June 2006 08:56:23 References: <200606081856.k58IuntN363624@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 564 Joseph Kowalski writes: > > > From: James Carlson > ... > > I don't think we're at that point (as it seems we've mostly converged > > on just one issue), ... > > Hopefully, that's "converged on **all but** just one issue". 8^) I was expressing "converged on arguing about one issue," but it's the same thing. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 8 19:14:25 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k592EOXZ004790 for ; Thu, 8 Jun 2006 19:14:24 -0700 (PDT) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k592EIod001489 for ; Fri, 9 Jun 2006 10:14:18 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0K00B01LMK8600@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 09 Jun 2006 10:14:18 +0800 (SGT) Received: from [129.158.219.168] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0K00151M7SHB70@mail-apac.sun.com>; Fri, 09 Jun 2006 10:14:18 +0800 (SGT) Date: Fri, 09 Jun 2006 10:13:49 +0800 From: Darren Reed Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <44882ACF.3020803@sun.com> Sender: Darren.Reed@Sun.COM To: Erik Nordmark Cc: James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Message-id: <4488D95D.3050003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2113 Erik Nordmark wrote: > James Carlson wrote: > >> Erik Nordmark writes: >> >>> But bge0 means different things with ifconfig and snoop. For >>> ifconfig it is "no vlan" (no VLAN header or a VLAN header with tag=0). >>> For snoop it means "everything on the wire". >> >> >> I don't agree. >> >> bge0 means the same thing in both cases -- it means the same thing as >> an "untagged port" on a switch. You see VLAN tags (with their proper >> VLAN SAP values) if there are VLAN packets. If there's IP with plain >> old Ethernet DIX headers, you see that too. > > >> The fact that IP is particularly interested in one SAP value and >> doesn't listen to them all shouldn't come as much of a surprise. > > > I brought up a potential concern from a users perspective that might > be an approachability issue. > > ... > I have no problem improving the observability of the system by somehow > allowing a snoop on bge0 to see packets for all the VLANs. > > But I remain concerned that if this is the default behavior it might > confuse users. The problem here is that we have two names, that are the same, describing different objects/devices in Solaris. One of those is a network interface (physical or virtual) and the other is the protocol head for IP. To the best of my knowledge, this overuse of the same name to refer to two different beasts is common across all Un*x. If ifconfig allowed you to manage bge0 for IPX or Appletalk then there might be less believe that "bge0 == IP only" but with the virtual interface implementation (bge0:1, etc) on Solaris, it further drives home the message that "bge0 is IP". If/when we're able to use "ip0" in place of "bge0" with ifconfig and still do "snoop -d bge0", then it might be more clear that the object referred to by ifconfig isn't the same as the object being referred to by snoop. So as far the proposal goes, it makes sense to me. What we should be looking for is roughly equivalent behaviour between snoop on bge2000 vs bge0 and ifconfig for bge2000 and bge0, not between snoop and ifconfig. Is a new spec likely to be posted any time soon? Darren From sacadmin Thu Jun 8 20:13:58 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k593Dvra006378 for ; Thu, 8 Jun 2006 20:13:57 -0700 (PDT) Received: from fe-apac-03.sun.com (fe-apac-03.sun.com [192.18.19.174] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k593Dp5j000460 for ; Fri, 9 Jun 2006 11:13:51 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0K00G01OQBGG00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 09 Jun 2006 11:13:51 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0K006ZUOZ0QZ35@mail-apac.sun.com>; Fri, 09 Jun 2006 11:13:51 +0800 (SGT) Date: Fri, 09 Jun 2006 11:13:47 +0800 From: Cathy Zhou Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <4488D95D.3050003@sun.com> Sender: Cathy.Zhou@Sun.COM To: Darren Reed Cc: Erik Nordmark , James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Message-id: <4488E76B.5060507@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <4488D95D.3050003@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 229 > Is a new spec likely to be posted any time soon? > You mean the spec with Dan's latest change on the snoop output? We will post the new spec soon with all the updates, once all the concerns get addressed. Thank you - Cathy From sacadmin Fri Jun 9 06:06:35 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k59D6ZkN020254 for ; Fri, 9 Jun 2006 06:06:35 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k59D6ZMI014972 for ; Fri, 9 Jun 2006 06:06:35 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k59D6YT0027183 for ; Fri, 9 Jun 2006 07:06:35 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0L00M01FZ52G00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 09 Jun 2006 07:06:34 -0600 (MDT) Received: from [129.148.19.32] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0L002ONGETG7P0@mail-amer.sun.com>; Fri, 09 Jun 2006 07:06:34 -0600 (MDT) Date: Fri, 09 Jun 2006 09:06:21 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <4488E76B.5060507@sun.com> Sender: Daniel.Groves@Sun.COM To: Cathy Zhou Cc: Darren Reed , Erik Nordmark , James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <4489724D.9040203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <4488D95D.3050003@sun.com> <4488E76B.5060507@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 501 Cathy Zhou wrote: >> Is a new spec likely to be posted any time soon? >> > You mean the spec with Dan's latest change on the snoop output? We will > post the new spec soon with all the updates, once all the concerns get > addressed. > > Thank you > - Cathy I've updated the spec with some man page changes, and as soon as I get a modified snoop with the new output (VLAN information in summary mode) I'll put that in the spec and it'll be ready. I hope to have that done sometime today. Dan From sacadmin Tue Jun 13 19:49:24 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5E2nOgT022868 for ; Tue, 13 Jun 2006 19:49:24 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5E2nNVN015563 for ; Tue, 13 Jun 2006 19:49:23 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5E2nMW4006650 for ; Tue, 13 Jun 2006 20:49:23 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0T00B01X3VGW00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 13 Jun 2006 20:49:22 -0600 (MDT) Received: from strat.East.Sun.COM ([129.148.174.103]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0T00EX4X6ASU3G@mail-amer.sun.com>; Tue, 13 Jun 2006 20:49:22 -0600 (MDT) Date: Tue, 13 Jun 2006 22:49:22 -0400 From: Sebastien Roy Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <1149618829.1915.83.camel@localhost> Sender: Sebastien.Roy@Sun.COM To: psarc Cc: clearview-iteam Message-id: <1150253362.17638.108.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> Status: RO Content-Length: 565 On Tue, 2006-06-06 at 14:33 -0400, Sebastien Roy wrote: > The timer has been restarted and will expire on June 13, 2006. This case's timer expires today, and the project team has provided a final spec that contains snoop man page clarifications and example snoop output, including output showing VLAN tag information in summary mode as requested. The spec is in the materials directory. Last week's discussion seems to have converged on the proposed spec, so unless there is additional input, I'll move this to approved tomorrow after the PSARC meeting. -Seb From sacadmin Wed Jun 14 01:21:31 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5E8LVCQ000753 for ; Wed, 14 Jun 2006 01:21:31 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5E8LOJH833842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Jun 2006 01:21:28 -0700 (PDT) Message-ID: <448FC703.5050407@sun.com> Date: Wed, 14 Jun 2006 01:21:23 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Peter Memishian , Mike Ditto , Bill Sommerfeld , Dan Groves , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> In-Reply-To: <17544.12041.397991.442908@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2985 James Carlson wrote: > I don't think that SAPs (or more accurately Ethertypes) are mere > artifacts. Users who do anything with VLANs end up needing to know > the difference between "native encapsulations" and "VLAN-tagged > packets," and they end up finding out that if something's > "VLAN-tagged," then you don't ordinarily see the traffic inside. You > must be "on the VLAN" to see it. What is an artifact of the protocol is that for VLAN tag=0, there may or may not be a VLAN header. What is an artifact of the implementation is that there is something called DL_PROMISC_SAP, and that there is a 1-1 mapping between the DLPI SAP and the Ethernet type. The previous claimed reasons why the approach would make sense to users relied on both of those sets of artifacts. > I do not believe that this is a legitimate concern. The reason I > believe this is that the user _must_ deliberately connect his system > to a trunk-type port in his network in order to see VLAN tags at all. Agreed. > The default behavior of common switches is to dedicate individual > ports to particular VLAN tags -- "untagged mode" -- where the attached > systems do _NOT_ see the VLAN tags. You have to do something special > to get to the place where you see them at all. Agreed. > If a user is deliberately connected to such a network, I find it very, > very strange that the user would end up being "confused" by seeing > VLAN traffic. In fact, I think exactly the opposite is true: omitting > the VLAN traffic makes the user think (and rightly so!) that snoop > lies. Having diagnostic tools that lie to the user is unhelpful. > > If you're on a trunk port, why would you expect snoop to show you > *ONLY* the untagged traffic? In most networks, there is no untagged > traffic on trunk ports, so you'd likely see nothing at all, which > would be most baffling. Do we know this for sure? I had *one* ifconfig -a output laying around for a customer using VLANs (Vodaphone GSP). I went and looked at it at was surprised to see that they use both untagged and tagged traffic on the same port. (ifconfig shows both ipge3 and ipge57003, etc.) Doesn't give much statistical basis for an argument that this is either uncommon or common. But ... Would such customer's be surprised if the behavior of snoop -d ipge3 changes in a patch? Perhaps the solution is to make the patch/update have a new option to enable this behavior, and leave the surprise to Nevada. > Finally, the way it's been defined here happens to be the way it also > works on other systems. As an approachability issue, I think it would > be *EXTREMELY* confusing if Solaris were oddly different from all > other operating systems. We shouldn't be going out of our way to make > Solaris be the odd man out on the network. Do we know how it works on Windows? If we are concerned about approachability for people coming from other systems, we need to look there and not only at other Unixes and Linux. Erik From sacadmin Wed Jun 14 09:26:32 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5EGQWXv015383 for ; Wed, 14 Jun 2006 09:26:32 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5EGQWSb023367 for ; Wed, 14 Jun 2006 09:26:32 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5EGQW78015656 for ; Wed, 14 Jun 2006 10:26:32 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0U00601YPIKQ00@mail-amer.sun.com> (original mail from Daniel.Groves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 14 Jun 2006 10:26:32 -0600 (MDT) Received: from [129.148.174.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0U00JDYZ06XW40@mail-amer.sun.com>; Wed, 14 Jun 2006 10:26:31 -0600 (MDT) Date: Wed, 14 Jun 2006 12:26:35 -0400 From: Dan Groves Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <448FC703.5050407@sun.com> Sender: Daniel.Groves@Sun.COM To: Erik Nordmark Cc: James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Message-id: <449038BB.6000602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> <448FC703.5050407@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 3256 Erik Nordmark wrote: > James Carlson wrote: > >> If a user is deliberately connected to such a network, I find it very, >> very strange that the user would end up being "confused" by seeing >> VLAN traffic. In fact, I think exactly the opposite is true: omitting >> the VLAN traffic makes the user think (and rightly so!) that snoop >> lies. Having diagnostic tools that lie to the user is unhelpful. >> >> If you're on a trunk port, why would you expect snoop to show you >> *ONLY* the untagged traffic? In most networks, there is no untagged >> traffic on trunk ports, so you'd likely see nothing at all, which >> would be most baffling. > > Do we know this for sure? > I had *one* ifconfig -a output laying around for a customer using VLANs > (Vodaphone GSP). I went and looked at it at was surprised to see that > they use both untagged and tagged traffic on the same port. (ifconfig > shows both ipge3 and ipge57003, etc.) Doesn't give much statistical > basis for an argument that this is either uncommon or common. But ... > > Would such customer's be surprised if the behavior of snoop -d ipge3 > changes in a patch? > > Perhaps the solution is to make the patch/update have a new option to > enable this behavior, and leave the surprise to Nevada. > We asked for the patch binding because there are customers who want the behavior what we have described in the spec (see CRs 4095699, 4722784, 6306794, 6292043, 6425678). We thought it would make life easier for whoever backports the change. We felt it would not be overly risky because if a customer has this configuration, then someone intentionally set it up. As I believe it was Allen pointed out, it is possible that the person who set up the configuration and the person running snoop is not the same person. One would hope that being an intentional configuration, this fact would be documented. If this is still a contentious issue, this case could be approved with a minor release binding. But that would ignore the fact that customers have expressed that the existing behavior is not what they expect, but our proposed behavior is what they expect. >> Finally, the way it's been defined here happens to be the way it also >> works on other systems. As an approachability issue, I think it would >> be *EXTREMELY* confusing if Solaris were oddly different from all >> other operating systems. We shouldn't be going out of our way to make >> Solaris be the odd man out on the network. > > Do we know how it works on Windows? If we are concerned about > approachability for people coming from other systems, we need to look > there and not only at other Unixes and Linux. > While we do not have a Windows machine available for testing, I did a google search on VLAN, Windows, and packet capture. It appears that the behavior the user will see will vary based on the network interface used. The best page of information I found is at the Ethereal Wiki: http://wiki.ethereal.com/CaptureSetup/VLAN#head-81781716144f2855ab0aff2f8b752e95f2562efb The Intel behavior, which I think will be most common in the Windows world given that Dell ships most or all of their machines with Intel NICs, sounds most similar to the Unix behavior. > Erik From sacadmin Wed Jun 14 11:45:16 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5EIjFmA027323 for ; Wed, 14 Jun 2006 11:45:15 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5EIjFOk004282 for ; Wed, 14 Jun 2006 11:45:15 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5EIjF9h026636 for ; Wed, 14 Jun 2006 12:45:15 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0V00H0153D4D00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 14 Jun 2006 12:45:15 -0600 (MDT) Received: from strat.East.Sun.COM ([129.148.174.103]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0V009D45FELTT3@mail-amer.sun.com>; Wed, 14 Jun 2006 12:45:15 -0600 (MDT) Date: Wed, 14 Jun 2006 14:45:13 -0400 From: Sebastien Roy Subject: Re: 2006/358 VLAN Observability Enhancement In-reply-to: <449038BB.6000602@sun.com> Sender: Sebastien.Roy@Sun.COM To: Dan Groves Cc: Erik Nordmark , James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , psarc , clearview-iteam Message-id: <1150310713.19196.15.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> <448FC703.5050407@sun.com> <449038BB.6000602@sun.com> Status: RO Content-Length: 1224 On Wed, 2006-06-14 at 12:26 -0400, Dan Groves wrote: > We asked for the patch binding because there are customers who want the > behavior what we have described in the spec (see CRs 4095699, 4722784, > 6306794, 6292043, 6425678). We thought it would make life easier for > whoever backports the change. We felt it would not be overly risky > because if a customer has this configuration, then someone intentionally > set it up. As I believe it was Allen pointed out, it is possible that > the person who set up the configuration and the person running snoop is > not the same person. One would hope that being an intentional > configuration, this fact would be documented. > > If this is still a contentious issue, this case could be approved with a > minor release binding. But that would ignore the fact that customers > have expressed that the existing behavior is not what they expect, but > our proposed behavior is what they expect. I brought this up at the PSARC meeting today in the hopes of resolving this last issue. PSARC is satisfied with the project team's assertion and reasoning that the case as defined is appropriate for a patch. This case was approved during today's meeting. -Seb From sacadmin Wed Jun 14 14:24:14 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5ELOEDN002627 for ; Wed, 14 Jun 2006 14:24:14 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5ELO6cS871281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Jun 2006 14:24:09 -0700 (PDT) Message-ID: <44907E75.7040600@sun.com> Date: Wed, 14 Jun 2006 14:24:05 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Dan Groves CC: James Carlson , Peter Memishian , Mike Ditto , Bill Sommerfeld , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> <448FC703.5050407@sun.com> <449038BB.6000602@sun.com> In-Reply-To: <449038BB.6000602@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2144 Dan Groves wrote: > We asked for the patch binding because there are customers who want the > behavior what we have described in the spec (see CRs 4095699, 4722784, > 6306794, 6292043, 6425678). We thought it would make life easier for > whoever backports the change. We felt it would not be overly risky > because if a customer has this configuration, then someone intentionally > set it up. As I believe it was Allen pointed out, it is possible that > the person who set up the configuration and the person running snoop is > not the same person. One would hope that being an intentional > configuration, this fact would be documented. > > If this is still a contentious issue, this case could be approved with a > minor release binding. But that would ignore the fact that customers > have expressed that the existing behavior is not what they expect, but > our proposed behavior is what they expect. Just because some customers want a behavioral change in a patch doesn't mean it is wise to inflict such a behavioral change on all the other customers that might unknowingly install the patch (e.g., as part of an update). But one thing to keep in mind is that I think (but I'm not sure) that currently on Solaris there might be different behavior for different NICs. (Can someone verify if this is the case?) If that is the case, then as part of making the behavior uniform, the behavior would change for some. > While we do not have a Windows machine available for testing, I did a > google search on VLAN, Windows, and packet capture. It appears that the > behavior the user will see will vary based on the network interface > used. The best page of information I found is at the Ethereal Wiki: > > http://wiki.ethereal.com/CaptureSetup/VLAN#head-81781716144f2855ab0aff2f8b752e95f2562efb > > > The Intel behavior, which I think will be most common in the Windows > world given that Dell ships most or all of their machines with Intel > NICs, sounds most similar to the Unix behavior. Thanks for the info. But the web page isn't very authoritative (and has the Solaris behavior wrong.) Erik From sacadmin Thu Jun 15 07:24:27 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5FEOQs0028204 for ; Thu, 15 Jun 2006 07:24:27 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5FENfHh103050; Thu, 15 Jun 2006 14:23:41 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k5FENfjV103049; Thu, 15 Jun 2006 10:23:41 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2006/358 VLAN Observability Enhancement From: Bill Sommerfeld To: Erik Nordmark Cc: Dan Groves , James Carlson , Peter Memishian , Mike Ditto , Sebastien Roy , psarc , clearview-iteam In-Reply-To: <44907E75.7040600@sun.com> References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> <448FC703.5050407@sun.com> <449038BB.6000602@sun.com> <44907E75.7040600@sun.com> Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1150381420.102662.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.340 Date: Thu, 15 Jun 2006 10:23:40 -0400 Status: RO Content-Length: 3285 On Wed, 2006-06-14 at 17:24, Erik Nordmark wrote: > Just because some customers want a behavioral change in a patch doesn't > mean it is wise to inflict such a behavioral change on all the other > customers that might unknowingly install the patch (e.g., as part of an > update). However, *in this case*, the judgement of PSARC is that the behavior change proposed by this case is expected, and that the potential benefit to customers who can take advantage of it far exceeds any potential harm to customers who weren't expecting it. > But one thing to keep in mind is that I think (but I'm not sure) that > currently on Solaris there might be different behavior for different > NICs. (Can someone verify if this is the case?) It's definitely the case for eri that, by default, snoop will see 802.1q-tagged packets with a nonzero vlan # snoop -d eri -r -x 0 ... ? -> (multicast) ETHER Type=8100 (Unknown), size = 130 bytes 0: 3333 0000 0009 0800 20e1 3b05 8100 0840 33...... .;....@ 16: 86dd 6000 0000 0048 11ff fe80 0000 0000 ..`....H..~..... 32: 0000 0a00 20ff fee1 3b05 ff02 0000 0000 .... .~.;....... 48: 0000 0000 0000 0000 0009 0209 0209 0048 ...............H 64: ad97 0201 0000 2002 0a08 3903 0002 0000 ...... ...9..... 80: 0000 0000 0000 0000 4001 2002 0a08 3903 ........@. ...9. 96: 0003 0000 0000 0000 0000 0000 4010 2002 ............@. . 112: 0a08 3903 0001 0000 0000 0000 0000 0000 ..9............. 128: 4001 @. ... 0: ffff ffff ffff 0800 20e1 3b05 8100 0840 ........ .;....@ 16: 0800 4500 0084 bab0 4000 0111 4929 0a08 ..E.....@...I).. 32: 3081 0a08 30ff 0208 0208 0070 883d 0201 0...0......p.=.. 48: 0000 0002 0000 0a08 3000 0000 0000 0000 ........0....... 64: 0000 0000 0001 0002 0000 0a08 3080 0000 ............0... 80: 0000 0000 0000 0000 0001 0002 0000 0a08 ................ 96: 3900 0000 0000 0000 0000 0000 0001 0002 9............... 112: 0000 0a08 3980 0000 0000 0000 0000 0000 ....9........... 128: 0001 0002 0000 0000 0000 0000 0000 0000 ................ 144: 0000 0000 0001 This is, of course, the stock version of snoop which doesn't know how to parse the ethertype 8100 format. ethertype is at bytes 12 and 13; the tag is at bytes 14 and 15 and is 0x840 or decimal 2112 (which is the tag we use for one of the other vlans on the switches in our lab in Burlington). The priority bits, in the high order bits of byte 14, are zero. The inner ethertype is at bytes 16 and 17, and the payload starts at byte 18. The first packet contains an IPv6 packet (inner ethertype 86dd) which I believe is sending to the all-routers multicast address; it contains a UDP datagram with source and destination port 521 (hex 209) which is the well-known port for the RIPng routing protocol spoken by in.ripngd. The second contains an IPv4 subnet broadcast of a UDP datagram with source and destination port 520 (which is the well-known port for the RIP routing protocol spoken by in.routed). The behavior on eri is unchanged between s9 and Nevada. - Bill From sacadmin Fri Jun 16 08:48:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5GFmDAX023433 for ; Fri, 16 Jun 2006 08:48:13 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5GFm75O478666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 16 Jun 2006 08:48:11 -0700 (PDT) Message-ID: <4492D2B7.6030500@sun.com> Date: Fri, 16 Jun 2006 08:48:07 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Bill Sommerfeld CC: Dan Groves , James Carlson , Peter Memishian , Mike Ditto , Sebastien Roy , psarc , clearview-iteam Subject: Re: 2006/358 VLAN Observability Enhancement References: <1149001006.1998.7.camel@localhost> <17532.32313.514080.184415@gargle.gargle.HOWL> <447DA09D.1030908@sun.com> <17533.42588.801209.426653@gargle.gargle.HOWL> <1149085993.18601.8.camel@strat.East.Sun.COM> <1149618829.1915.83.camel@localhost> <1149620844.19860.78.camel@thunk> <4485D558.2020008@sun.com> <1149622823.19860.141.camel@thunk> <17541.56540.927450.330298@triplex.East.Sun.COM> <4485E314.90206@sun.com> <17542.14635.557945.483032@triplex.East.Sun.COM> <44868B40.3090703@sun.com> <17542.61669.961739.78806@gargle.gargle.HOWL> <44882ACF.3020803@sun.com> <17544.12041.397991.442908@gargle.gargle.HOWL> <448FC703.5050407@sun.com> <449038BB.6000602@sun.com> <44907E75.7040600@sun.com> <1150381420.102662.24.camel@localhost> In-Reply-To: <1150381420.102662.24.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 700 Bill Sommerfeld wrote: > On Wed, 2006-06-14 at 17:24, Erik Nordmark wrote: >> But one thing to keep in mind is that I think (but I'm not sure) that >> currently on Solaris there might be different behavior for different >> NICs. (Can someone verify if this is the case?) > > It's definitely the case for eri that, by default, snoop will see > 802.1q-tagged packets with a nonzero vlan So in order to make things consistent (e.g, between eri and bge) one of them has to change, thus customers might be surprised. Given that we need to inflict pain on some customers to get consistency, then it makes sense to make Solaris have the same default behavior as other operating systems. Erik