I'm not quite clear from your description on some details, so I'll
start by making some assumptions. You have
[ switch1 ] port X ---- [ PC2 ] ---- port Y [ switch2 ]
| |
[ PC1 ] [ PC3 ]
Both switches are configured with many vlans grouping various ports
on them, and "port X" and "port Y", the two ports going to PC2, are
congfigured for 802.1Q.
The first point would be that PC2 needs to have support for 802.1Q.
You don't mention what OS you're running on PC2. I don't know the
answer for other OSes, but if it were running Linux, I'd hunt down
the 802.1Q support for Linux that's listed in freshmeat, and see
whether it works. For other OSes you'll need to get drivers to
support 802.1Q tagged links.
The second point, once you've got PC2 supporting 802.1Q tagging on
its interfaces, is that it needs to be doing either routing or
bridging. If PC1 and PC3 are on the same logical VLAN on the two
switches, then bridging should suffice; if they're on separate VLANs
then PC2 will need to be routing between VLANs. Linux supports both
routing and bridging, though I've not used its bridging support
myself.
If you want the PC to be applying active controls to the stuff as it
sails past, this can be a sexy way to wire things --- if you can get
all the wonky bits to work right. But if you just want traffic to
flow, and only wired it this way because that seemed convenient, I'd
probably recommend changing to have a hub where PC2 is located, or
better yet eliminate all that and run the 802.1Q direct from switch1
to switch2 with a crossover cable, and then just assign a regular
port to PC2.
Host support for 802.1Q is pretty young yet, you're treading on
moderately new ground.
-Bennett
PGP signature
