Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) NAT and Ascend


  On Fri, 24 Apr 1998 14:31:42 -0400 (EDT) 
   Steve Camas <stevec@liii.com wrote:
  
   Hello,
   
   Anyone have any idea what 'data lost' means?
  
  Its not important. The first 3 lines are the important ones.
  
   
   172.16.25.23:3491:119:0x6-22:52:17 = 4436
   172.16.25.23:3492:119:0x6-22:52:19 = 4435
   172.16.25.23:3493:119:0x6-22:52:23 = 4434
   172.16.25.23:3494:119:0x6-22:52:25 = 4433
   172.16.25.23:3495:119:0x6-22:52:29 = 4432
   172.16.25.23:3496:119:0x6-22:52:32 = 4431
   172.16.25.23:3497:119:0x6-22:52:36 = 4430
   172.16.25.23:3498:119:0x6-22:52:39 = 4429
   172.16.25.23:3499:119:0x6-22:52:52 = 4428
   172.16.25.23:3062:119:0x6-22:52:52 = 4427
   
   ----- data lost -----
    
   
   
   Does anyone know the specifics of TR2928? I am told that TR2928 is the TR
   that covers NAT problems my customers are having.
  
  What is TR2928. What you look like to be experiencing is the same as 
  our problems with NAT on P-130 and P-220's:
  
  ------------------------------------------------------------------
  COLT Internet Supplier Fault Log
  
  COLT Internet Supplier: Ascend Communications Inc.
  Date of problem occurance: 10/12/97
  Current Supplier Support Satisfaction: Low
  Engineer: Adam Chappell <adamc@COLT.NET
  Problem: NAT translation buffer consumed over time
  Platform: Pipeline 220 and Pipeline 130 
  Software: ea.p22-6.0.4e5, ea.p22-6.0b4, b.p13-5.1Ap4, b.p13-5.1Ap9 
  Status: Unresolved 
  Description:
  
  On all software experienced so far, NAT has caused problems when
  in use by more than a handful of workstations on the LAN. Detailed
  diagnosis on test equipment has been performed with the following
  conclusions.
  
  The static NAT maps configurable via the pipeline interface seem
  to work consistently and be fairly reliable. The dynamic NAT maps
  that are created for most outgoing traffic are different. The NAT
  software builds a mapping between the IP address and TCP port in
  use on the LAN and the public NAT FR address and a free TCP port
  on the router.
  
  The problem seems to be that the router can hold a maximum of 500
  entries in the translation table at any one time, which would
  probably be more than satisfactory for a network of even upto fifty
  users. However, it seems to fail to ever delete the mappings that
  are created when the associated connections close.
  
  An example: a user browses the web and typically Internet Explorer
  or Netscape will open upto four TCP streams to the remote host.
  When the user is goes idle, the browser will close these TCP streams.
  The router keeps the mapping for these TCP streams in place. The
  user browses the web again and the browser re-opens connections to
  the web server. The router adds four more entries to the NAT table
  and so the list grows.
  
  192.168.1.14:1141:25:0x6-23:57:21 = 2933
  192.168.1.14:1142:110:0x6-23:57:24 = 2932
  192.168.1.14:1143:25:0x6-23:57:39 = 2931
  192.168.1.14:1144:110:0x6-23:57:43 = 2930
  A snapshot of a NAT table showing idle TCP mappings 
  
  Associated with each NAT translation entry is a time to live field.
  For TCP streams, this is typcially set to 24 hours. When the time
  to live associated with the mapping expires the mapping is then
  available for reuse. This means that even a modest browsing session
  on the web will result in the NAT translation table filling up in
  a short time with TCP connections that need another 23 hours to
  expire.
  
  An exception to the expiry time is mappings for DNS traffic, which
  only seem to last for one minute. In recent (post 6.0) software
  versions, Ascend seem to have reduced the time to live associated
  with port 80 traffic to ten minutes. This may have masked the
  problem slightly, but it still exists. And it is just as bad if
  the user base all have browsers configured to use a proxy server
  on a port other than port 80.
  
  192.168.1.200:1249:80:0x6-0:09:11 = 2929
  192.168.1.200:1250:80:0x6-0:09:11 = 2928
  192.168.1.200:1251:80:0x6-0:09:12 = 2927
  Reduced TTLs for port 80 web traffic 
  
  --------------------------------------------------------------------------------
  Suggested Fix:
  
  In order to fix this: the NAT software should detect the closing
  of TCP streams (the RST or the FIN packet sent from either side)
  and delete the corresponding entry from the table. This would mean
  that the only maps in the NAT table that are forced to wait for
  expiry are idle connections present perhaps because a machine has
  crashed. UDP sessions are probably more difficult since there is
  no obvious indication that the session has finished. Perhaps the
  time to live field should be a user configurable parameter for
  these cases. In any case, the number of NAT entries should be
  larger.
  --------------------------------------------------------------------------------
  
   I have posted a few times about TR2928 and my posting seems to be going to
   /dev/null... Nobody is saying anything...
  
  A rucurring problem for Ascend at the moment. We have tested other vendors
  NAT solutions and they seem to support a minimum of 10000 NAT translations.
  
  6.0.4 is as broked as every other NAT release.
  
  Regards,
  Neil.
  --
  Neil J. McRae. Alive and Kicking.     
  neil@DOMINO.ORG    NetBSD-1.3 released! ftp://ftp.uk.netbsd.org/pub/NetBSD
  
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>