That looks good. On Nov 29, 2011 1:15 PM, "L G Robinson" <[email protected]> wrote:
> ** > 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 > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
