Richard wrote: > > providers : > > telstra1 1 1 main ppp0 track,balance eth2,eth3 > telstra2 2 2 main ppp1 track,balance eth2,eth3 > telstra3 3 3 main ppp2 track,balance eth2,eth3 > > I get an error with the eth2,eth3 at the end, I am not quite sure what they > do. >
That's like saying "I had a problem when I walked down Post Street yesterday; what should I do?" If you have an unresolvable problem with "shorewall [re]start", we need a trace. See http://www.shorewall.net/support.htm#Guidelines As to "I'm not quite sure what they do"... Having read the LARTC, you hopefully understand the concepts of packet marking, multiple routing tables and routing rules that select a routing table based on the packet mark. If you don't, any explanation that I give you will be pretty meaningless. Shorewall has this silly idea that when a response packet is received from the Internet, the routing of that packet should be governed by the same routing table that was used to route the original outgoing request. In retrospect, that may be a warped notion but it is what Shorewall implements. When you define a 'provider' in /etc/shorewall/providers, you are actually defining a routing table. So that means that any routing table (e.g., provider) that you define must be capable of routing response packets for any outgoing request packet that can be sent using that routing table. That requires that routes from any host that could have sent a request out of each provider have a route in that provider's routing table. Still with me? All routes in the main table (or whatever table is mentioned in the DUPLICATE column) have an associated interface. The way that Shorewall builds the provider-specific routing tables is to copy entries from the table specified in the DUPLICATE column. The COPY column specifies the interfaces whose entries in the DUPLICATE table will be copied to the provider-specific table. In other words, it names the interfaces which could provide requests that could be routed out through the provider. Make sense? As I have hinted, I think that I probably got it wrong -- but it is what we have currently so until 3.4, we must live with it. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
