There is a number of rules you are not allowed to break
(otherwise your bridge will do).
A port can only be a member of one bridge.
A bridge knows nothing about routes.
A bridge knows nothing about higher protocols than ARP.
That's the reason why it can bridge any possible protocol
possibly running on your Ethernet.
No matter how many ports you have in your logical bridge,
it's covered by only one logical interface
As soon as a port (e.g. a NIC) is added to a bridge you have no
more direct control about it.
| Warning |
If one of the points mentioned above is not clear to you now,
don't continue reading.
Read the documents listed in Appendix B
first.
|
If you ever tried to ping an unmanaged switch, you will know that
it doesn't work, because you don't have a IP-address for it.
To switch datagrams it doesn't need one.
The other thing is if you want to manage the switch.
It's too much strain, to take a dumb terminal, walk to the
place you installed it (normally a dark, dusty and warm
room, with a lot of green and red Christmas lights), to connect the
terminal and to change the settings.
What you want is remote management, usually by SNMP, telnet, rlogin
or (best) ssh.
For all this services you will need a IP.
That's the exception to the transparency.
The new code allows you without any problem to assign a IP address to
the virtual interface formed by the bridge-instance you will create
in Section 6.2.
All NIC's (or other interfaces) in your bridge will happily listen and
respond to datagrams destined to this IP.
All other data will not interfere with the bridge.
The bridge just acts like a switch.
Take our 
