Mouse <mouse%Rodents-Montreal.ORG@localhost> writes: > As I was using it in the double-quoted text above, a bridge is much > dumber, on the order of a hub or a media converter, just echoing out > what it receives in. A switch has more smarts - it knows enough about > packet formats to pick out source and destination addresses, learn what > addresses occur on which ports, and avoid sending unicast packets to > pointless ports. It also might speak a few protocols, such as spanning > tree, in its own right. AIUI NetBSD's bridge does L2 reception with CRC, and has tables of what goes where, and can do the spanning tree protocol, plus can store multiple packets in queues -- so it's a switch. After some reading I conclude that bridge refers to early devices that are like switches but don't have the buffering. What you would have used in the 80s :-) >> I agree that "bridge0" being a "network interface" is not entirely >> right. I see it as close enough that using config ioctls is sensible >> and therefore it seems like a software writing optimization, compared >> to creating a first-class switch type. > > I'm not sure. The only parts of the "network interface" abstraction I > see bridges as really using are creation and destruction, naming > (including ifconfig -l), and IFF_UP/~IFF_UP. I'm not sure whether I > think that's justification enough for dragging along the rest of the > network interface baggage - perhaps I just haven't looked closely > enough at the bridge implementation. > > Maybe it would help if bridges rejected all attempts to configure > addresses on them? THat's basically what I meant. Disallow interface-only things. Take the view that ifconfig works on network things, of which there are interfaces and bridges.
Attachment:
signature.asc
Description: PGP signature