ITEM: RTA000047746

I have a customer that has a model 570 server running as an NIS master          
and dataless 250's on a toekn ring network.  I recently added a new             
model 360 at a remote site over a 56Kb line using IBM PS's using the            
remote bridge program v 2.0.  I have NIS tokenring at the main site             
just fine, but cannot get the remote system to connect.  In fact,               
I can't even get the remote system to respond to a ping command.  I             
know that the server is OK, the dataless machines are working fine.             
The remote system is pinging other machines at the remote site just             
fine.  I just can't get the TCP/IP traffic to go across the bridges.            
(Of course, if a ping won't work the NIS stuff is NEVER going to work.)         
I have set up a static route from smit on both of the systems to see            
if that would help.  Following are the addresses and route setup info.          
System            hostname              ip address                             
Model 570         nnr0r                                  
Model 360         neqes1r                               
added a static route in smit of:                                                
on model 570                                                                    
type           host                                                             
hop            1                                                                
on model 350                                                                    
type       host                                                                 
hop        1                                                                   
Is there anything I can check on the bridges to see if there is anything        
not set correctly? (I don't know the bridge program very well)                  
Further info. that you need is that all machines are at AIX 3.2.5, and          
the customer support people are good on their PC's on the network but           
don't like (or understand) the RS/6000's on the ring.  Therefore I              
don't get much help from them to diagnose the problems.                         
---------- ---------- ---------- --------- ---------- ----------                
A:  There are three things that I can think of that could cause this            
to happen.  They are as follows:                                                
     1. If, on the RS/6000, source route bridging is disabled it would         
         stop traffic from crossing the bridge.                                 
     2. If, on the bridge, single route broadcast is disabled the IP            
         traffic could be effected.  This parameter in the bridge               
         configuration can either be set to Automatic or Manual and             
     3. The third is congestion, which is probably the case.  We have           
         first hand experience that when the bridge is showing congestion       
         the TCP/IP traffic is the first protocol to take the hit.  If          
         you are getting congestion or lost packets you can boost the           
         line speed or set up filters on the bridge to try and reduce           
         unwanted traffic from getting onto the slow 56Kbps link.               
---------- ---------- ---------- --------- ---------- ----------               
I want to give you some answers to your questions.                              
1. How do I check to see if source route bridging is setup on the               
RS/6000?  I have not intentionally set this up.  Is there a goos write          
up on how to set it up?                                                         
2.I have checked the bridges.  They do have single route broadcast              
enabled and set to automatic.  Hopefully that helps the diagnosis of            
3.I do know that we have problems with conjestion on the network.  They         
have been needing help with their bridges for quite some time.  I have          
been fighting this problem all along.  They know how to take the                
defaults but nothing much beyond that.                                          
---------- ---------- ---------- --------- ---------- ----------                
A:  3. Probably the best thing that you could do to reduce bridge               
        congestion would be to add filters or write your own filters to         
        reduce the amount of traffic that crosses the bridge.  The              
        filter s that you use will depend on your network and what              
        protocols you use.  Information on bridge filters can be found          
        in the bridge users guide and the ASKQ database.                        
---------- ---------- ---------- --------- ---------- ----------                
A: Source routing for the RISC System/6000's Token-Ring interface               
   is indicated with the ALLCAST flag.  For example, if you type                
   the command 'ifconfig tr0', output similar to the following will             
   tr0: flags=8063                    
   The ALLCAST flag indicates that source routing is turned 'on'.               
   If the ALLCAST flag does not appear, then source routing is not              
   To change whether source routing is used, you need to change the             
   following field in SMIT under the network interface screen within            
   the TCP/IP setup (smit chinet).                                              
   Confine BROADCAST to LOCAL Token-Ring?                                       
   When this field is set to 'yes' source routing is NOT used and the           
   ALLCAST flag does not appear from the ifconfig command output.               
   When this field is set to 'no' source routing is used and the ALLCAST        
   flag does appear from the ifconfig command output.  Source route can        
   be also be set by using the following command:                               
        ifconfig tr# allcast.                                                   
   The problems you are encountering may also be caused by an                   
   incorrectly set MTU size on the RISC System/6000.  When bridges              
   are used, in general, the MTU size for the token-ring interface              
   should be set to no larger than 1492.  However, if source routing            
   bridges are used then the MTU size will need to be changed to 1462.          
   It appears that your difficulty stems from a limitation of source            
   routing bridges that affects the token-ring packet size.  This               
   problem occurs if a RISC System/6000 is a participant in the network.        
   Referring to HONE ASKQ Item IX20603:                                        
         MANY FIELD SE'S ARE HAVING TO SET THE MTU (on the RISC                 
         System 6000) TO 1462.  THIS IS DUE TO A BUG THE AIX                    
         FOR SOME TOKEN RING CONSTANTS THAT HAVE CHANGED                        
         (THE SPEC CHANGED).                                                    
   Setting the MTU size on the RISC System 6000 to 1462 should                  
   solve the problem.  It is not necessary to change the MTU                    
   size on the other machines from 1492 to 1462, their MTU sizes                
   should remain at 1492.                                                       
   You can change the MTU size by using the smit fastpath                       
   'smit chiftr'.                                                               
   If changing the MTU size and ensuring that source routing is turned          
   on does not solve the problem you are encountering, please reopen            
   this item.                                                                   
---------- ---------- ---------- --------- ---------- ----------                
QUESTION: I need to tell you a problem that I                                   
have.  We were having a lot of trouble with the customers local network         
losing packets.  I used a lecture from the 1994 AIX specialists update          
called Shadow chasers.  It had suggestions for aix servers and diskless/        
dataless clients attached.  The main change that was suggested was to           
change the MTU size to 3900.  This would not be very effecient for              
telnet but would be better for NFS traffic (which the dataless terminals        
require).  Their local bridges were set to a packet size of 4xxx.               
(I don't recall the actual amount.  It was documented in the bridge             
installation manual).  After changing the MTU size, the dataless terms.        
performed much better with "acceptable" response.  If I reduce that MTU         
to 1462, I may bring my local dataless terminals back to a crawl (40            
minute login for example).  Can you elaborate on the filters for an             
alternate route of attack?                                                      
---------- ---------- ---------- --------- ---------- ----------                
A:  You can use filter programs on the bridge to limit traffic that can         
cross a bridge.  in your case you want to limit traffic to reduce               
congestion.  For example, you can use a filter program to permit only           
certain adapter addresses (like the new 360) to send frames across the          
bridge to a particular system (your 570 server).                                
    The NetBIOS filter will prevent proliferation of NetBIOS frames from        
crossing a bridge from one LAN to another.  If you have NetBIOS on one          
LAN and do not want any or just want certain users to be able to cross         
the bridge, this filter would help.                                             
    The Address filter will forward or discard all frames that contain          
source and destination addresses within a range.  An example of the use         
of this filter is described in the first paragraph.                             
    The SAP filter will filter all frames that contain source and               
destination addresses within a specified range.  Some examples are              
X'02' for the LLC sublayer management individual SAP or like CM/2 (SNA)         
which is X'04'.                                                                 
    The SNAP filter first checks frames for the LSAP header 'AA AA 03' in       
the DSAP, SSAP, and Control fields.  If found, the EtherType field of the       
SNAP header is checked for a match with the type specified in the filter.       
    You can also write your own filters.  Please be aware that all of the       
filters mentioned above are fully documented in the Bridge User's Guide         
and specific information on how to allow TCP/IP, IPX, NetBIOS, and SNA          
traffic to flow and how to prevent the flow of these protocols is in the        
ASKQ database.  You can use search words of 'FILTER and BRIDGE'.                
---------- ---------- ---------- --------- ---------- ----------                
QUESTION:  I have a feeling my problem may                                      
stem from my MTU size after talking to one of our bridge "gurus".  Let          
me bring you up to date.  I have the MTU size on both RS/6000's set to          
3900 ( per Shadow Chasers lecture from AIX Spec. Update) and the                
frame size set at 2052 on the remote bridges.  My bridge guy pointed out        
that I need to try to reduce those MTU sizes down to 2000 and then retry        
the connection.  My question is as follows.  My 570 server has 2 Token          
Ring adapters on it.  Can I change the MTU size on the second adapter,         
then get my NIS maps to be "pushed" out to the slave server from that           
second adapter (the name of the second adapter is nnr1r, the first              
adapter was nnr0r from above)?  See the layout below to help clarify            
this installation:                                                              
  __________ TR0   MTU=3900         Dataless                      
 | 570      |-------------------------------------                              
 |_____NIS__|----------|                          250's                         
             TR1       |                                                         |                                                        
       (nnr1r)         |______Remote   Max. Frame=2052                          
       MTU=2000               Bridge                                            
                              Bridge             |                             
                                                 |360   MTU=2000                
                                                  Slave Server(neqes1r)         
So, if nnr0r is the Master NIS Server, will the 570 push the NIS maps           
out over the nnr1r (TR1) Adapter to the slave out at the remote site?           
Hopefully, by changing the MTU size to 2000 that will allow my TCP/IP           
to make connection, next is the NIS question.  I know this is complex           
but I have quite a network here.                                                
---------- ---------- ---------- --------- ---------- ----------                
A:  Your bridge guy is correct you should try and reduce the MTU size           
so the IP frames will be passed.  As far as whether the 6000 will "push"        
the NIS information through, I do not know.  I will transfer this back         
to the 6000 group for their comments.                                           
---------- ---------- ---------- --------- ---------- ----------                
A: The answer to your question is yes.  You can change the MTU size             
   on the second adapter and then get your NIS maps to be "pushed"              
   out to the slave server from that second adapter.  The only change           
   that the MTU size will make on NIS is the speed of the NIS traffic.          
---------- ---------- ---------- --------- ---------- ----------                
A: I was looking over your item again and may have found the reason why         
   you have not been able to ping.  Piecing together your first and last        
   inquiries I have noticed that the static route going from the 570 to         
   the 360 may be incorrect.  As listed, the route to the 360 is using          
   the tr0 interface ( as the gateway instead of the tr1          
   interface (  If this is true, the packets are going          
   out the wrong interface.  In the same way, the route on the 360 must         
   have a destination of instead of                
---------- ---------- ---------- --------- ---------- ----------                
QUESTION:  I had already changed the routing of the 360                         
to use the (TR1) adapter.  It worked, twice¢  I then tryed        
to telnet and got to the 360 and was able to log in.  Then just 15-20           
minutes later the connection was no longer established.  I can not ping         
or telnet.  The only thing that was done on the 360 was to try to get           
NIS to start up in a slave server mode.  It failed with a message that          
the 360 was not able to bind to the address.  My question         
now is:  Can I change my host file on the 570 to make both adapters             
use the same host name?  This way, when the 360 comes across, it finds          
the ypbind running under the correct hostname.  For you further enjoy-          
ment, we can ping the 360 from a PS/2 running TCP/IP for OS/2.  The 570        
can not ping the 360¢¢  I am really getting frustrated.  I also noticed         
that the 570 is running the base daemons for DCE (Special offering from         
CCS in Austin).  Could DCE be causing me some unexplainable results?            
We are not using DCE, CICS/6000, or DB2/6000 yet.  How can I shut DCE           
off.  I have already commented out their rc files, but they still               
start up at IPL.  By the way, I am doing this in a billable mode and            
need to get some measurable results soon.                                       
---------- ---------- ---------- --------- ---------- ----------                
A: For the time being, I recommend trying to bind to the server using           
   the 'ypset' command.  This command will be necessary to bind to              
   a server that is 1 hop or more away.                                         
   It is not possible to change your host file on the 570 to make both         
   adapters use the same host name.  However, I don't believe that              
   this will be necessary.  I far as I know, I don't believe that DCE           
   should be causing any problems either.                                       
---------- ---------- ---------- --------- ---------- ----------                
I wanted to respond back that we got this to work with the following            
changes and procedures.  Please archive this for future reference.              
Buried in an ASKQ item, I found one answer to a 2 adapter question that         
said 2 adapters with the same network address (not host portion) was            
a violation of TCP/IP.  Given this opinion, I elected to go about               
changing the tr1 interface back to 142.147.  The problem of having 2            
adapters with the same network address, is that routing across the              
remote bridge and trying to force the traffic across one specific              
adapter turned out to be a nightmare¢  A ping request would come in one         
adapter and leave on the other.  This caused a miriad of problems. (This        
was verifyed by using an iptrace.)                                              
I had to get the dataless workstations (D.L.w.s.) to recognize only one         
of the adapters first.  I set a static route to the host address of    , then re-booted the machines.  I stopped each machine at          
the boot menu.  All I did was reverify that the station address and the         
boot server address were correct.  Once booted, I did a netstat -rn             
and fouen NO entry for (tr1).                                     
Next, I modified the tr1 interface using smit inet.  After changing the         
interface, I modified the /etc/hosts file to reflect the new tr1 address        
and then changed the remote 360 address to  I rebuilt           
my NIS maps.                                                                    
I had the remote sys. adm. get on the 360 and remove any static routes          
that were hanging around.  Did sh tcp.clean, smit inet, changed the             
interface address, modified the /etc/hosts file, then did rc.tcpip.             
Next I had the sys. adm. go into smit tcpip and setup a static route            
to the 142.146 network through the tr1 adapter on the             
570.  I test this by pinging the 570 (and the 360 from the 570), IT             
I then got real gutsy, and had the sys. adm. setup the domainname, and          
then start up the machine as a slave server.  The maps transfered just          
as expected and I am up and running.                                            
I want to stress that the condition of having 2 adapters using the same         
network portion of the TCP/IP address can work in some circumstances,           
but can cause a real problem when routing is crucial.  If requests in          
one adapter then out through another is no problem, BREAK A LEG¢  But           
if this causes routing problems, get rid of it¢  You can always set up          
a route and then start routed if you need it.                                   
---------- ---------- ---------- --------- ---------- ----------                
This item was created from library item Q670298      CVLZM                      
Additional search words:                                                        

WWQA: ITEM: RTA000047746 ITEM: RTA000047746
Dated: 04/1996 Category: RISCTCP
This HTML file was generated 99/06/24~12:43:18
Comments or suggestions? Contact us