Xref: utzoo comp.protocols.misc:216 comp.protocols.iso:26 Path: utzoo!mnetor!uunet!munnari!mulga!ditmela!george From: george@ditmela.oz (George michaelson) Newsgroups: comp.protocols.misc,comp.protocols.iso Subject: AUSTPAC/TRANSPAC internetwork problems: have you seen this? Message-ID: <284@ditmela.oz> Date: 1 Feb 88 05:11:59 GMT Organization: CSIRO Division of Information Technology Lines: 95 We have discovered a problem with our local X25 switch being used with AUSTPAC/OTC/{other x25 network} which you may be interested in. this problem may be seen by anyone who is on a TRANSPAC-like X25 network being called from any other X25 network eg IPSS in the UK. it is caused by differences in the use & interpretation of X.121 addresses at each DTE, and propagated by X25 gateway and network provider behaviour. PROBLEM: Calls in to local host using subaddress routing are accepted but clear at once, possibly with error code 05 a7. Remote host may not see call connecting but local host does. -further problem: diagnostic a7 is referred to international provider and/or remote DTE ie no human readable form available locally to decode the problem! SEE WITH: smartnet 3000 series X25 switch and possibly any similar box doing sub-address routing from one X25 DCE to several hosts. Any host receiving calls off the address with no subaddress will function normally. any routing ignoring sub-address may function normally. WHAT HAPPENS: The call request packet when received by the local X25 provider has the LOCAL DTE stripped out, leaving the subaddress part only. This is perceived as a feature on certain nets. The switch then routes the CR packet to the correct host using its tables. The host accepts the call. The switch sends back a Connect Accept packet *WITH THE LOCAL SUBADDRESS IN IT BUT NOT THE FULL LOCAL DTE* as received from the local provider. The local provider does NOT re-insert the local DTE but passes this packet transparently to the gateway, which also passes direct to the remote X25 network. The remote network and/or DTE checks the CC packet, finds a DTE which (a) does not match the called address (b) does not conform to *its* idea of X.121 address format, and clears the call 05 (network congestion or other problem) a7 (DTE incorrect length) WHO IS TO BLAME? Well... clearly the switch could do better, but you can argue that if the network provider strips addresses on incoming calls they should be replaced in all packets going out during the connect phase. In our case we are using a box with little support and little configuration for this area. You should look carefully at any product & make sure you have full control over all fields of all packets if possible. FIX: (1) get a switch which you can tailor enough to specify ALL fields in ALL packets and write a valid address into your CC packet before sending. (2) discuss this feature with your network provider they *may* be able to switch it off, or insert full DTE into all connect-phase packets instead of leaving the CC alone. (3) use other routing mechanisms as a temporary bridge: PID or cudf can be used with DTE minus subaddress to select several hosts, if the hosts support this option: (the crucial one of ours claims to but the kernel crashes in this mode- the option is thus not available) I suspect this problem may be being seen by many people but ignored. At our site calls to some hosts worked ok, due to the default routing on no subaddress creating a CC with no arguments, which was accepted by everyone. Local tests fail to cause the problem, even loop-back through international gateway may fail to show problem, only a genuine call in from some remote net which also checks the DTE on all connect phase packets will cause rejection. Thanks to OTC and PSS engineers who helped track down this problem for us. (at time of writing we don't yet have fix working locally, there may not *be* a fix!) George Michaelson. -- ACSnet: G.Michaelson@ditmela.oz.au Postal: 55 Barry St, Carlton, Vic 3053 Phone: (03) 347 8644 Fax: (03) 347 8987