Sat Nov 14, 2020 12:40 am
@anav: bridge (the switch-like entity) is pretty much transparent on ethernet level, so when an ethernet frame (optionally VLAN-tagged) enters bridge, it will exit through another port unaltered.
The bridge interface is functionality-wise identical to other interfaces members of bridge. So if bridge interface can carry multiple VLANs (you have mastered this part already, haven't you?), then other ports (including ether ports) can as well. And this ability has nothing to do with bridge (the switch-like entity), it's inherent to being interface passing ethernet frames - optionally prepended with tiny 4 bytes long 802.1q header.
When it comes to ROS ability to communicate with particular VLAN, the key is vlan (pseudo) interface which can be thought of as a tiny pipe which sifts frames carrying 802.1q header with particular value of VLAN ID on one end and delivers those frames with 802.1q header stripped. In the reverse direction this pipe takes frames, adds 802.1q header with VLAN ID set to (same) particular value and emits the frame on the other hand. Both ends are handling ethernet frames. Which means that "tagged" end of the pipe has to be attached (or anchored) to some interface handling ethernet frames. It can either be physical ethernet interface or bridge interface. It can't be bridge switch-like entity!
Then IP addresses: device can have any number of IP addresses set on same interface. The prerequisite is that it knows to answer ARP whohas queries for those IP addresses with own MAC address. Which then is used by other devices to deliver packets. Next device has to know how to deal with packets with some particular dst-address. On normal network devices there will be some services bound to some (or all) of those IP addresses.
Similar process happens when interface has arp=proxy-arp set. In this case device answers ARP whohas queries with own MAC address even for IP addresses belonging to other devices if device in question knows how to forward packets to real receivers (usually from own MAC table, either static or dybamic).
Similar process (delivery of packets with "alien" dst-address to device in question) happens if device in question is a gateway ... in this case other devices will sene ARP whohas queries for gateway's IP address and gateway will answer with own MAC address. Other devices will deliver packets to router's MAC address and router then forwards packets according to routing rules for IP dst-address set in packets. This is similar to proxy-arp case, the difference is only in IP address used in ARP whohas queries sent by LAN devices (in gateway case LAN devices know that they are directly communicating with gateway while in proxy-arp case LAN devices think they're communicating directly to end device).