Hi Axton, I don't know as much about the protocols and firewalls as I should, but the information that you provided is good for reference.
Now that ICMP is enabled, I can actually get some real numbers: ars00srv is the arserver: traceroute to ars00srv (152.1.?.?), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 ars00srv (152.1.?.?) 0.879 ms 0.824 ms 0.862 ms ping ars00srv PING ars00srv (152.1.?.?) 56(84) bytes of data. 64 bytes from ars00srv (152.1.?.?): icmp_seq=1 ttl=253 time=0.911 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=2 ttl=253 time=0.953 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=3 ttl=253 time=1.21 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=4 ttl=253 time=0.868 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=5 ttl=253 time=0.889 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=6 ttl=253 time=0.966 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=7 ttl=253 time=0.878 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=8 ttl=253 time=0.871 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=9 ttl=253 time=0.898 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=10 ttl=253 time=0.926 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=11 ttl=253 time=0.917 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=12 ttl=253 time=0.926 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=13 ttl=253 time=0.809 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=14 ttl=253 time=0.859 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=15 ttl=253 time=0.883 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=16 ttl=253 time=0.889 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=17 ttl=253 time=1.16 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=18 ttl=253 time=0.833 ms 64 bytes from ars00srv (152.1.?.?): icmp_seq=19 ttl=253 time=1.51 ms ^C --- ars00srv ping statistics --- 19 packets transmitted, 19 received, 0% packet loss, time 18361ms rtt min/avg/max/mdev = 0.809/0.956/1.516/0.166 ms So based on your comments, it looks like we are in pretty good shape. Thanks again for your help. Larry On Tue, Nov 29, 2011 at 11:38 AM, Axton <[email protected]> wrote: > TCP state timeout shouldn't make a big difference; it will just cause > a little more communication to create the state. When a packet comes > from the midtier server to the arserver and a state does not exist on > the firewall, the packet will be dropped; the midtier should then send > a SYN packet, which create a new state, at which point the packet will > be forwarded and an ACK will go back to the midtier server. > > 1 hour is rather short for TCP, but can be justified in high traffic > environments. I use the following on my firewalls, which are the > defaults for the platform I use and is pretty typical for other > platforms. Note that TCP state expirations are valid for 24 hours. > The firewall is smart enough that at a certain point it will start > expiring the states (adaptive) when a certain threshold is reached. > > TIMEOUTS: > tcp.first 120s > tcp.opening 30s > tcp.established 86400s > tcp.closing 900s > tcp.finwait 45s > tcp.closed 90s > tcp.tsdiff 30s > udp.first 60s > udp.single 30s > udp.multiple 60s > icmp.first 20s > icmp.error 10s > other.first 60s > other.single 30s > other.multiple 60s > frag 30s > interval 10s > adaptive.start 18000 states > adaptive.end 36000 states > src.track 0s > > LIMITS: > states hard limit 30000 > src-nodes hard limit 10000 > frags hard limit 5000 > tables hard limit 1000 > table-entries hard limit 200000 > > I would still suggest looking at the latency between the arserver and > the midtier server. If you are getting beyond 20ms it's going to > cause a noticeable impact on performance. Ideally, in a data center > environment, you want to see < 2 ms latency between your servers if > the traffic is routed and < 1 ms if the traffic is not routed > (switched). > > Axton Grams _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
