From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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.
Fair reason. > 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 I don't do this myself, but you should look at the options available that allow you to control this kind of thing. Distributing traffic out multiple ISPs is something BGP can help with; you may or may not be in the situation that it can be used with your providers. PF's route-to options may help here. Don't know for certain as I don't have the luxury of multiple links. Be sure to check the PF FAQ (http://www.openbsd.org/faq/pf/) and pf.conf(5) manual page for information. DS
