HOW DO I CHECK THE REMOTE BRIDGE PROGRAM ON PC'S
ITEM: RTA000047746
QUESTION:
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 142.146.0.224
Model 360 neqes1r 142.146.41.224
added a static route in smit of:
on model 570
type host
dest. 142.146.41.224
gate. 142.146.0.224
hop 1
mask 255.255.0.0
on model 350
type host
dest. 142.146.0.224
gate. 142.146.41.224
hop 1
mask 255.255.0.0
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
enabled.
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.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
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
this.
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
appear.
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
used.
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
TOKEN RING ARP PROCESSING CODE. IT CONTAINS OLD VALUES
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:
(nnr0r)
__________ TR0 142.146.0.224 MTU=3900 Dataless
| 570 |-------------------------------------
|_____NIS__|----------| 250's
TR1 |
142.146.0.225 |
(nnr1r) |______Remote Max. Frame=2052
MTU=2000 Bridge
Remote_____________
Bridge |
|
|360 MTU=2000
Slave Server(neqes1r)
142.146.41.224
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 (142.146.0.224) as the gateway instead of the tr1
interface (142.146.0.225). 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 142.146.0.225 instead of 142.146.0.224.
---------- ---------- ---------- --------- ---------- ----------
QUESTION: I had already changed the routing of the 360
to use the 142.146.0.225 (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 142.146.0.225 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.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
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
142.146.0.224, 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 142.146.0.225 (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 142.147.41.224. 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 142.147.0.225 tr1 adapter on the
570. I test this by pinging the 570 (and the 360 from the 570), IT
WORKED.
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:
ACROSS ALLO BRIDGE CHECK COMMUNICATIO CVLZM IP IX NIS OCT94 OZNEW
OZNOTPID PC PROG PROGRAM PROGRAMMABLE PROGRAMMER PROGRAMMING REMOTE
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