Darren Reed writes:
> Reading 2.4 (Observability Node), it seems like the architecture
> is becoming rather obscure and complicated to achieve a
> somewhat simple goal.
It's actually quite simple in design, and provides several benefits,
so I'm not sure I understand why you're saying this. (One of the
benefits is that I can open that observability node, and use an ioctl
to extract the forwarding table -- which allows the "show-bridge"
command to display the bridge's learned forwarding information.)
What specificially is obscure?
> What other design choices did you consider for achieving this?
> Are there any better ways we might do it if only....?
The other possible design that I considered was this:
Make a bridge the exclusive owner (and primary mac client) of any
links assigned to the bridge. You cannot plumb or otherwise use
those links. (Perhaps, as with aggregations, passive listeners
would be allowed. It's unclear if VNICs configured on the
underlying interfaces would be reasonable or exactly how they'd
behave, as they'd essentially bypass the bridging logic.)
Allow the user to create fake interfaces on "top" of the bridge.
These would allow the user to plumb IP and have it talk on the
bridged network.
Also allow the user to specify that a fake interface is in "port
monitoring" mode, so that the user can run snoop/wireshark and see
the traffic on the bridge.
The benefits of such a design are hard to determine, though I guess
it's simpler to understand at a first glance. Perhaps the most
significant benefit would be that the bridge would be a strict primary
mac client of the underlying interfaces and a mac provider for the top
fake interfaces.
The detractions would be:
- The MAC address assigned to the real interfaces would essentially
go to waste, and the fake ones would need random addresses. The
design I chose allows the real interfaces to be used naturally.
- The fake interfaces on top would be architecturally different from
the real ones underneath (bottom: no user access, top: no external
I/O), meaning that we'd need to support two "types" of interfaces
within the bridging code rather than one.
- As noted, VNICs on the underlying physical interfaces become a
real problem, because as mac clients, they would be in parallel
with the bridging code. If you sent a frame to a MAC destination
that was on the same subnetwork but was reachable through a
different interface, your frame would go out the _wrong_ interface
and simply never reach the destination. With my design, it "just
works."
- The design I chose allows the use of either etherstubs or Rishi's
simlinks to provide fake interfaces, if ever needed.
But since I don't quite know what you're questioning here (or what
alternatives you might have had in mind), I'm not sure how to respond.
Some clues about the underlying concern would be appreciated.
--
James Carlson, Solaris Networking <[email protected]>
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
_______________________________________________
networking-discuss mailing list
[email protected]
