Re: Multiroute question

2012-09-23 Thread Paul Schenkeveld
On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote:
 Actually, multiple routing tables is the correct solution. I documented it
 here:
 
 http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/
 
 From the post: ... But route-to and reply-to do not trump the default
 routing table for traffic that originates or terminates on the router
 itself. They are useful only for traffic passing through the router. pf can
 only make routing decisions when a packet passes through an interface. It
 can try and set the reply-to interface to be the second WAN connection when
 an inbound SSH connection is made, but neither the SSH daemon nor the
 routing table on the host know or care about the routing preferences of pf.

FWIW, I've many dual-homed machined running perfectly by combining pf
for filtering and ipfw for policy-based routing.

Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first
WAN connection and d.e.f.0/29 the second):

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any

01001 allow carp from any to any
01002 allow pfsync from any to any

01100 allow ip from any to 10.0.0.0/8
01101 allow ip from any to 172.16.0.0/12
01102 allow ip from any to 192.168.0.0/16
01103 allow ip from any to 224.0.0.0/3

01110 allow ip from any to my_internal_public_adressblock_1
0 allow ip from any to my_internal_public_adressblock_2
...

01200 fwd a.b.c.1 ip from a.b.c.0/29 to any
01201 fwd d.e.f.1 ip from d.e.f.0/29 to any

65535 allow ip from any to any

Lines 1100 thru  pass all traffic that should not go out over a
WAN interface, they follow the normal routing table.  I need the lines
011xx because I have multiple public IP address blocks on the inside
and behind tunnels.  Lines 1200 and 1201 forward packets to either WAN
interface depending on the source address.

I also have a default gateway set to my preferred WAN interface for
connections originating from this host where the client does not
explicitly select a source address.

This works both for packets being routed and for packets originating
from the dual homes host itself.

I've been using this since FreeBSD 6 and never felt the need to switch
to multiple routing tables because this fits the purpose and is quite
clean IMO.  It's also not necessary to run multiple server processes
(like sshd, sendmail, httpd) for every routing domain.

With kind regards,

Paul Schenkeveld
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Re: [patch] sysctls for TCP timers

2012-09-23 Thread Andrey Zonov
On 9/20/12 11:35 AM, Eggert, Lars wrote:
 Hi,
 
 On Sep 20, 2012, at 9:25, Andrey Zonov z...@freebsd.org wrote:
 Some of them may be read google's article about tuning TCP parameters
 [1].  I convert most of TCP timers to sysctls [2] and we are using this
 patch for few months.  We tuned net.inet.tcp.rtobase and
 net.inet.tcp.syncache.rexmttime and it gives good results (especially in
 conjunction with cc_htcp(4)).
 
 can you share some measurements that quantify the results?
 

When we set net.inet.tcp.syncache.rexmttime=200 and
net.inet.tcp.syncache.rexmtlimit=7 for our external web service, the
number of duplicated SYN was reduced in four times.

-- 
Andrey Zonov



signature.asc
Description: OpenPGP digital signature


Re: Multiroute question

2012-09-23 Thread Julian Elischer

On 9/23/12 5:20 AM, Paul Schenkeveld wrote:

On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote:

Actually, multiple routing tables is the correct solution. I documented it
here:

http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/

From the post: ... But route-to and reply-to do not trump the default
routing table for traffic that originates or terminates on the router
itself. They are useful only for traffic passing through the router. pf can
only make routing decisions when a packet passes through an interface. It
can try and set the reply-to interface to be the second WAN connection when
an inbound SSH connection is made, but neither the SSH daemon nor the
routing table on the host know or care about the routing preferences of pf.

FWIW, I've many dual-homed machined running perfectly by combining pf
for filtering and ipfw for policy-based routing.

Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first
WAN connection and d.e.f.0/29 the second):

 00100 allow ip from any to any via lo0
 00200 deny ip from any to 127.0.0.0/8
 00300 deny ip from 127.0.0.0/8 to any

 01001 allow carp from any to any
 01002 allow pfsync from any to any

 01100 allow ip from any to 10.0.0.0/8
 01101 allow ip from any to 172.16.0.0/12
 01102 allow ip from any to 192.168.0.0/16
 01103 allow ip from any to 224.0.0.0/3

 01110 allow ip from any to my_internal_public_adressblock_1
 0 allow ip from any to my_internal_public_adressblock_2
 ...

 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any
 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any

 65535 allow ip from any to any

Lines 1100 thru  pass all traffic that should not go out over a
WAN interface, they follow the normal routing table.  I need the lines
011xx because I have multiple public IP address blocks on the inside
and behind tunnels.  Lines 1200 and 1201 forward packets to either WAN
interface depending on the source address.

I also have a default gateway set to my preferred WAN interface for
connections originating from this host where the client does not
explicitly select a source address.

This works both for packets being routed and for packets originating
from the dual homes host itself.

I've been using this since FreeBSD 6 and never felt the need to switch
to multiple routing tables because this fits the purpose and is quite
clean IMO.  It's also not necessary to run multiple server processes
(like sshd, sendmail, httpd) for every routing domain.

Interesting but but seems to me that for this to work you need to make
every host inside dual home, or at least assign each internal machine to
one ISP or the other.

With kind regards,

Paul Schenkeveld
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org