Spruell, Darren-Perot wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Tim Pushor wrote:
Steve Glaus wrote:
Ok, I gotcha, trunk just looked like a ready mad solution
for what I
was trying to do... Could you tell me WHY it's not able to be used
for that and what it is for?
I've gone the pf route before to but it seems to add a lot of
complexity to my ruleset
trunk(4) is mainly used to provide redundancy or performance
enhancement on the same network. I was using it to provide switch
redundancy by putting one cable in one switch, one in the
other, and
the switches connected together. If I lose a switch, it
keeps chugging
along.
Alright. Just so I understand.. COULD it be used to do what
I'm trying to do? When you trunk two network interfaces
together, are they adressless? Do the devices on the switch
address the IP of the pseudo trunk interface?
Trunk(4) provides link redundancy. Say you had a NIC on a box cabled into a
switch. That switch port dies, your box falls off the network. Introduce
trunk, now you have two NICs in your box, cabled to two switch ports. One
port dies (or one NIC); you have a redundant link to the switch and your box
stays online.
Read the manual and you'll find it has other uses as well (e.g. thoughput
aggregation traditionally) but what you described is really not what it
would be. Your word was "routing", which is certainly not what it does
(higher in the stack than trunk(4).)
DS
Ok. I think I understand. The trunk interface really has no idea how to
route anything. It just sees packets (like any other interaface?). But
couldn't one then use routed to route packets coming in over the trunk
interface to anywhere else? I'm probably just revealing my ignorance here.
I'm really just harping on this to further my understanding. Feel free
to ignore or respond as you wish. I've given up on the idea of using
trunk for this paraticular application and am gonna go back to pf
Thanks for all the help
