Darren Reed writes:
> James Carlson wrote:
> > ...
> > djr-02 Given djr-01 and the integration of crossbow to provide MAC
> > layer
> > classification and resource controls, is it possible to leverage
> > crossbow to protect the system from abuse refered to in (1)(a)?
> > If not immediately, is there scope for this as a future project?
> >
> > Reply: Crossbow currently identifies flows in MAC clients, such as
> > VNICs. It doesn't work down at the IEEE 802.1 level where
> > bridging takes place.
>
> So it isn't possible to use Crossbow's interfaces to
> put STP packets into a separate rx/tx ring pair or to
> otherwise use crossbow to partition rx/tx rings up for
> preferential treatment of specific ethernet addresses
> on either side of a bridge? And thus if we can do that,
> then it seems to me like we should be able to specify
> what sort of bandwidth allocation/guarantees those
> rings get...
>
> Or is this RFE material?
You could certainly do that if you wanted to provide some Crossbow
protection to the STP traffic itself. That won't do much to repair
things if an L2 loop is inadvertently introduced, but it might
possibly lessen the likelihood of one happening.
I thought you were talking more about the data path fault than the
control path one. In the data path, I don't think there's much that
can be done if a live L2 loop exists due to control path failure.
(I'm not sure if it makes sense for us to define static flows or
resources to use "automatically" when STP is present. Perhaps that's
something that can be included in the documentation instead -- a
section on using Crossbow to protect the control path if desired.)
> > djr-03 From bridge-spec.txt, (2.1), the requirement to use individual
> > network links to observe packets being sent does not fit with
> > what I would expect as a user. Needing to sniff the individual
> > network connections seems somewhat onerous (a snoop per link
> > in the bridge is required) and presupposes that the "user" knows
> > which interface they need to look on for the packet(s) they're
> > trying to observe.
[...]
> The distinction I'm keen to make is observing received packets
> vs sent packets.
There's no real distinction here.
> This is the paragraph that I'm referring to:
>
> "To see the packets transmitted and received on a particular link
> (after the bridging process is complete), snoop on the individual
> links rather than the bridge observability node."
>
> What I'm not sure about is whether "handled by the bridge" in the
> other paragraphs in this section refers to packets that are both
> sent and received, just received, or something else.
Both. I'll update this section to make it clearer.
> This, in
> concert with promiscuous mode being required with snoop to get
> sent packets with DLPI, has me asking for this to be more clear,
> especially considering this sentence:
>
> "The packets delivered will represent the data received by the bridge."
This means "received in any fashion" -- through downward calls
(transmits made by MAC clients) or by upward calls (packets received
by drivers).
> I think this section needs to make it clear whether snoop or the
> observability devices will present:
> 1) traffic that is received by the bridge
> 2) traffic that is transmitted by the bridge (both STP + data)
> 3) traffic that is accepted/forwarded by the bridge
>
> i.e. if I'm snoop'ing bridge0 and a packet comes in bge0 and
> the bridge sends it out bge1, will I see it once with snoop or
> twice or...?
You should see it once.
If you snoop on the bridge observability node, you see a copy of each
packet that goes through the bridge code. That includes:
- All packets received by the driver for any link assigned to the
bridge, as long as the link itself is in "forwarding" state.
(Ports disabled by STP are as though they don't exist in terms of
the data path for the bridge.)
- All packets transmitted by a MAC client on any link assigned to
the bridge, as long as the link itself is in "forwarding" state.
- Since STP is itself just a plain old DLPI user, you will see the
STP packets on all of the enabled ports when snooping the bridge
observability node. (We could filter these away if desired, as
they're not bridge data path items, but there didn't seem to be a
need to do this.)
If you snoop on a link, you see what's transmitted or received on that
one link, as far as the MAC and higher layers are concerned, and
without regard to the bridge forwarding state. Again, as STP is just
a DLPI user, that means you'll see the STP packets for a given port,
even if the port is disabled by STP. (I need to make that part much
clearer.)
The operation of the observability node on the bridge (with the
possible exception of the STP messages) is intended to be just like a
mirroring port on a regular bridge. The difference between this and
having a real mirroring port is that it's a virtual interface that's
established dynamically, so it has no overhead when not in use.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
