| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 914.1 | Try debug | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Tue Apr 22 1997 14:04 | 18 |
| Not sure if this helps, but the LightStream has debugging capabilities.
You may want to try these commands from the Cisco's console:
Switch> enable
Switch# debug atm ilmi
Switch# debug atm sig-packets
Once you've figured out the probem you need to:
Switch# undebug all
The operation of ILMI has nothing to do with LAN emulation. That is,
you should be able to get ILMI up even though you may not be able to
get LAN emulation going.
Cheers,
>Per
|
| 914.2 | | NPSS::NEWTON | Thomas Newton | Tue Apr 22 1997 14:19 | 7 |
|
> The operation of ILMI has nothing to do with LAN emulation. That is,
> you should be able to get ILMI up even though you may not be able to
> get LAN emulation going.
However, if ILMI is down, the UNI will be declared down, and you probably
will not be able to get either signalling or LAN Emulation to work.
|
| 914.3 | | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Tue Apr 22 1997 22:18 | 15 |
| | However, if ILMI is down, the UNI will be declared down, and you probably
| will not be able to get either signalling or LAN Emulation to work.
Is that something specific to this driver on NT? If I recall, ILMI is
optional even though most vendors implement it. Some of the larger Telco
switches do not have it and you essentially have to resort to manual
address registration on the host. I did not think ILMI down was synonymous
with UNI down.
Some of the switches, like Bay, allow you to configure if ILMI is to be
enabled or disabled. I think the same it true with FORE. Similarily, you
have to resort to manual address registration even in the switch when there
is no ILMI.
>Per
|
| 914.4 | Will forward to customer | NNTPD::"[email protected]" | Youda Kopel | Tue Apr 22 1997 23:19 | 12 |
| Thanks Guys ,
I will forward this to the customer, However is there anything that requires
on our 350L to resolve this issue ???????? Is the Cisco 4700 that provides the
LECS need any configuration changes ???
Again , Many Thanks for your help.
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|
| 914.5 | Customer Reply | NNTPD::"[email protected]" | Youda Kopel | Wed Apr 23 1997 02:21 | 23 |
| Hi There ,
This is the customer reply :
I have done the the comands to look at the ILMI and sent the debug info to
Andrew ( our MCS Guy ). From this report it would seem the ILMI is not
working,
well there was no ILMI traffic coming from the 350l card.
Tonight we are going to shutdown both of our servers and put the second card
in the other server in a PCI slot which works.
It seems that certain cards (which have a bridge on board) do not work on
the last three PCI slots because of the bridge between them.
END..............
Any Comments Guys ??
Cheers ,
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|
| 914.6 | | NPSS::NEWTON | Thomas Newton | Wed Apr 23 1997 12:48 | 15 |
|
Re: .3
-------------------------------------------------------------------------------
UNI 3.0, Section 4, Interim Local Management Specification
4.7.7
The network-side UME shall declare the UNI to be down either due to a physical
layer failure or due to a loss of ILMI connectivity ...
-------------------------------------------------------------------------------
On the other hand, ILMI 4.0 says that loss of ILMI Connectivity, as opposed to
Change of Attachment Point, does not have any effect on signalling.
|
| 914.7 | | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Wed Apr 23 1997 13:08 | 8 |
| | The network-side UME shall declare the UNI to be down either due to a physical
| layer failure or due to a loss of ILMI connectivity ...
But loss of connectivity is not the same as never having had it. This
may be nit picking, but some vendors, like the Nortel Concorde, does not
have ILMI at all. They maintain heartbeat through Q.SAAL.
>Per
|
| 914.8 | | GIDDAY::CHONG | Andrew Chong - Sydney CSC | Thu Apr 24 1997 04:08 | 15 |
| Hello,
I am the CSC person who is workin gon the problem in .0.
The customer has tried another ATMworks 350L interface withe the same problem.
Dubug done from the Cisco Lightstraem and the Cisco 4700 shows that our ATM card
did not send any ILMI trap. To confirm that, he disconnects the cable from the
ATMworks 350L and connect to a Cisco 3000 (with ATM interface) and he could see
ILMI trap from the Cisco and the following ATM address registration.
I would like to set up a test lab here but not sure if I can get the
hardware. In the meantime does anyone have a suggestion on what could be the
problem ?
Regards,
Andrew
|
| 914.9 | More things to try | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Thu Apr 24 1997 13:32 | 22 |
| Hi Andrew --
If you look at port statistics on the 1010 is there any indication that any
data is flowing at all? If I interpret your experiment correctly, what you
did verify was that the port on the 1010 works, not that the 350L works.
Try something like:
Switch> show atm status
See if the interface is even showing as "up". Unfortunately the 1010 does
not have a LOS light on the port, only TX/RX. Is there any indication that
the 1010 is trying to send something (by looking at TX light).
Also, the 1010 should print out a console message when you connect an
adapter to it (sort of like link up). Have you verified that you do not
have the wires crossed? It could be that one fiber is broken. First try
to cross them. If that does not work, reverse the cross and swap fibers
on both sides. If it now claims the link is alive, the TX fiber is likely
busted.
>Per
|
| 914.10 | ILMI Debug | NNTPD::"[email protected]" | Youda Kopel | Mon Apr 28 1997 03:59 | 23 |
| Guys ,
Is there a tool to DEBUG ILMI on our 350L ??? The customer has configmed that
there is no problem with the Fibres !!!! Has tried these with another Cisco
Device.
I read somewhere ( Efficient Networks Inc. ) about the ECM Utility and the
ILMI
Debugging under UNIX called ---> " show ilmi " ecm command. Is there any info
of doing the same under NT V3.51 !!!!!!!!!!!
Is there anything else we can do on the 350L for trouble shooting ???
Also , What is needed as far as ILMI VCI ( 16 ) configuration ????
Please help on this .
Many Thanks ,
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|
| 914.11 | | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Mon Apr 28 1997 11:03 | 10 |
| Hi Youda --
I am not sure if you answered the question I posed: do you see *any* cell
activity from the 350L to the 1010 (on the 1010)? If so, does it appear to
be error free? Even the 1010 will likely try to send TRAPs to the other side
if the physical connection is valid.
Cheers,
>Per
|
| 914.12 | More info from Customer | NNTPD::"[email protected]" | Youda Kopel | Tue Apr 29 1997 23:56 | 222 |
| Dear Per ,
I have been given more info from our customer, Here it is :
>Make sure that both ENDS are using UNI 3.1, I think UNI 3.0 does not
>support ILMI !!!
The following is a copy of the show run on the 1010
>I have forward the comment from the US. Here iti is :
>If you look at port statistics on the 1010 is there any indication that
>any data is flowing at all? If I interpret your experiment correctly, what
>you did verify was that the port on the 1010 works, not that the 350L works.
>
>Try something like:
>
>Switch> show atm status
>
DELM1010#sh run
Building configuration...
Current configuration:
!
version 11.1
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname DELM1010
!
boot system flash bootflash:ls1010-wi-mz_111-6
enable password power
!
atm lecs-address-default 47.0091.8100.0000.0061.7059.4001.0060.3e11.549d.00 1
atm address 47.0091.8100.0000.0061.7059.4001.0061.7059.4001.00
!
interface ATM0/0/0
no keepalive
!
interface ATM0/0/1
no keepalive
!
interface ATM0/0/2
no keepalive
!
interface ATM0/0/3
no keepalive
!
interface ATM0/1/0
no keepalive
!
interface ATM0/1/1
no keepalive
!
interface ATM0/1/2
no keepalive
!
interface ATM0/1/3
no keepalive
!
interface ATM1/0/0
no keepalive
!
interface ATM1/0/1
no keepalive
!
interface ATM1/0/2
no keepalive
!
interface ATM1/0/3
no keepalive
!
interface ATM2/0/0
no ip address
no keepalive
atm maxvp-number 0
lane client ethernet vlan9
!
interface ATM2/0/0.1 multipoint
ip address 147.109.11.130 255.255.255.128
atm maxvp-number 0
lane client ethernet vlan8
!
interface Ethernet2/0/0
ip address 171.68.99.133 255.255.255.192
!
interface ATM3/0/0
no keepalive
!
interface ATM3/0/1
no keepalive
!
interface ATM3/0/2
no keepalive
!
interface ATM3/0/3
no keepalive
!
interface ATM3/1/0
no keepalive
!
interface ATM3/1/1
no keepalive
!
interface ATM3/1/2
no keepalive
!
interface ATM3/1/3
no keepalive
!
no ip classless
!
line con 0
line aux 0
line vty 0 4
password
login
!
end
****************************
>See if the interface is even showing as "up". Unfortunately the 1010
>does not have a LOS light on the port, only TX/RX. Is there any indication
>that the 1010 is trying to send something (by looking at TX light).
>
The lights TX/RX do show activity. I did a status on the interface as shown
below
DELM1010#sh atm int atm0/0/1
Interface: ATM0/0/1 Port-type: oc3suni
IF Status: UP Admin Status: up
Auto-config: enabled AutoCfgState: completed
IF-Side: Network IF-type: UNI
Uni-type: Private Uni-version: V3.0
Max-VPI-bits: 0 Max-VCI-bits: 14
Max-VP: 255 Max-VC: 16383
Svc Upc Intent: pass
ATM Address for Soft VC: 47.0091.8100.0000.0061.7059.4001.4000.0c80.0010.00
Configured virtual links:
PVCLs SoftVCLs SVCLs PVPLs SoftVPLs SVPLs Total-Cfgd Installed-Conns
3 0 0 0 0 0 3 3
Logical ports(VP-tunnels): 0
Input cells: 302999 Output cells: 673518
5 minute input rate: 0 bits/sec, 0 cells/sec
5 minute output rate: 0 bits/sec, 0 cells/sec
Input AAL5 pkts: 212105, Output AAL5 pkts: 441014, AAL5 crc errors: 0
>I am not sure if you answered the question I posed: do you see *any*
>cell activity from the 350L to the 1010 (on the 1010)? If so, does it appear
>to be error free? Even the 1010 will likely try to send TRAPs to the other
>side if the physical connection is valid.
>
The following is a copy of the status of the ilmi on the 1010
DELM1010#sh atm ilmi status
Interface : ATM0/0/0 Interface Type : Private UNI (Network-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled (5 Seconds)
Addr Reg State: UpAndNormal
Peer IP Addr: 147.109.11.126 Peer IF Name: ATM0
Peer MaxVPIbits: 3 Peer MaxVCIbits: 10
Configured Prefix(s) :
47.0091.8100.0000.0061.7059.4001
Registered Address(s) :
47.0091.8100.0000.0061.7059.4001.0060.3e11.549a.00
47.0091.8100.0000.0061.7059.4001.0060.3e11.549b.00
47.0091.8100.0000.0061.7059.4001.0060.3e11.549c.00
47.0091.8100.0000.0061.7059.4001.0060.3e11.549d.00
Interface : ATM0/0/1 Interface Type : Private UNI (Network-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled (5 Seconds)
Addr Reg State: UpAndNormal
Peer IP Addr: 0.0.0.0
Peer MaxVPIbits: 0 Peer MaxVCIbits: 0
Configured Prefix(s) :
47.0091.8100.0000.0061.7059.4001
Interface : ATM0/0/3 Interface Type : Private UNI (Network-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled (5 Seconds)
Addr Reg State: UpAndNormal
Peer IP Addr: 0.0.0.0
Peer MaxVPIbits: 8 Peer MaxVCIbits: 14
Configured Prefix(s) :
47.0091.8100.0000.0061.7059.4001
Registered Address(s) :
47.0091.8100.0000.0061.7059.4001.0080.240b.9318.00
Interface : ATM2/0/0 Interface Type : Local
Configured Prefix(s) :
47.0091.8100.0000.0061.7059.4001
Registered Address(s) :
47.0091.8100.0000.0061.7059.4001.0060.7059.4002.01
Local End-System Registered Address(s) :
47.0091.8100.0000.0061.7059.4001.0060.7059.4002.01
DELM1010#sh atm iisp prefix
Codes: P - installing Protocol (S - Static, R - Routing control),
T - Type (I - Internal prefix, E - Exterior prefix )
P T Port St Prefix
- --- ------------ -- ---------------------------------------------------
S I ATM0/0/0 UP 47.0091.8100.0000.0061.7059.4001.0060.3e11.549a/152
S I ATM0/0/0 UP 47.0091.8100.0000.0061.7059.4001.0060.3e11.549b/152
S I ATM0/0/0 UP 47.0091.8100.0000.0061.7059.4001.0060.3e11.549c/152
S I ATM0/0/0 UP 47.0091.8100.0000.0061.7059.4001.0060.3e11.549d/152
S I ATM2/0/0 UP 47.0091.8100.0000.0061.7059.4001.0060.7059.4002/152
S I ATM2/0/0 UP 47.0091.8100.0000.0061.7059.4001.0061.7059.4001/152
S I ATM0/0/3 UP 47.0091.8100.0000.0061.7059.4001.0080.240b.9318/152
S I ATM2/0/0 UP 47.0091.8100.0000.0061.7059.4001.4000.0c/128
END.......
I hope this help you Per ,
Cheers ,
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|
| 914.13 | Evidence points to 350L host | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Wed Apr 30 1997 12:00 | 32 |
| Hi Youda --
By looking at your logs there appears to be nothing wrong with the
interfaces. As a matter of fact, even ILMI is running! However,
there are no NSAPs registered on that port.
| Interface : ATM0/0/1 Interface Type : Private UNI (Network-side)
| ILMI VCC : (0, 16) ILMI Keepalive : Enabled (5 Seconds)
| Addr Reg State: UpAndNormal
| Peer IP Addr: 0.0.0.0
| Peer MaxVPIbits: 0 Peer MaxVCIbits: 0
| Configured Prefix(s) :
| 47.0091.8100.0000.0061.7059.4001
How about this. Ask customer to try:
Switch> show atm vc traffic
It should show the TX and RX cell count for the various
VCs, including 0,16 on that one adapter where you are seeing
the problem. Not sure, but I imagine that these counters
are reset if you disconnect the fiber from that port and put
it back in again (perhaps you need to leave it out for 30s).
What this will tell us is if there is even ANYTHING coming
back on that VC from the 350L.
I am starting to wonder if there is not something fundamentally
wrong on the 350L host. Anyone from 350L able to chime in here?
Cheers,
>Per
|
| 914.14 | trap is sent but fail to register addr | GIDDAY::CHONG | Andrew Chong - Sydney CSC | Thu May 01 1997 09:38 | 113 |
| Per,
By the way just for your information. This problem has been IPMT.
The case number is CFS.50800.
The customer did some more trace from th 1010 switch and found
the ILMI trap from the 350L ( it's connected to ATM0/0/1 ) but the
registration time out :
DELM1010#
ILMI: Validating address 47.0091.8100.0000.0061.7059.4001.0080.240b.9310.00
ILMI: Address considered validated (ATM0/0/3)
ILMI: Address added : 47.0091.8100.0000.0061.7059.4001.0080.240b.9310.00
(ATM0/0/3)
ILMI: Service Registry. Using variable octetstring type to parse service
category
ILMI: Service Registry. Using variable octetstring type to parse service
category
ILMI: Validating address 47.0091.8100.0000.0061.7059.4001.0080.240b.9310.00
ILMI: Client Validation not required
ILMI: Address Deleted :47.0091.8100.0000.0061.7059.4001.0080.240b.9310.00
(ATM0/0/3)
ILMI: Validating address 47.0091.8100.0000.0061.7059.4001.0080.240b.b350.00
ILMI: Address considered validated (ATM0/0/2)
ILMI: Address added : 47.0091.8100.0000.0061.7059.4001.0080.240b.b350.00
(ATM0/0/2)
ILMI: Service Registry. Using variable octetstring type to parse service
category
ILMI: Service Registry. Using variable octetstring type to parse service
category
ILMI: Validating address 47.0091.8100.0000.0061.7059.4001.0080.240b.b350.00
ILMI: Client Validation not required
ILMI: Address Deleted :47.0091.8100.0000.0061.7059.4001.0080.240b.b350.00
(ATM0/0/2)
ILMI: Trap Received (ATM0/0/1) <=====****** trap from 350L
ILMI: Sending Per-Switch prefix
ILMI: Registering prefix with end-system 47.0091.8100.0000.0061.7059.4001
ILMI: Service Registry. Using variable octetstring type to parse service
category
ILMI: Retrying on (ATM0/0/1)
ILMI: Retrying on (ATM0/0/1)
ILMI: Retrying on (ATM0/0/1)
ILMI: Retry expired on (ATM0/0/1) <======***** ends here
DELM1010#
.
.
.
DELM1010#disconnect 350l
?Invalid connection name
DELM1010#
%LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0/0/1, changed state to down
%LINK-5-CHANGED: Interface ATM0/0/1, changed state to going down
ILMI: Received Interface Down. Shutting down ILMI (ATM0/0/1)
%LINK-3-UPDOWN: Interface ATM0/0/1, changed state to down
%LINK-3-UPDOWN: Interface ATM0/0/1, changed state to up
ILMI: Received Interface Up (ATM0/0/1)
Registering New port ATM0/0/1
ILMI: Querying peer device type. (ATM0/0/1)
ILMI : (ATM0/0/1) From Restarting To ilmiIntfAwaitDeviceType
<ilmi_query_peerdevtype>
%LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0/0/1, changed state to up
ILMI: Response Received and Matched (ATM0/0/1)
ILMI: Errored response <No Error> on Intf (ATM0/0/1)
ILMI Function Type was ilmiReqOther
ILMI: Response Received and Matched (ATM0/0/1)
ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
ilmiPeerUniVersionInfo
ILMI: The Maximum # of VPI Bits (ATM0/0/1) is 0
ILMI: The Maximum # of VCI Bits (ATM0/0/1) is 0
ILMI: Querying peer device type. (ATM0/0/1)
ILMI : (ATM0/0/1) From ilmiIntfDeviceTypeComplete To ilmiIntfAwaitPortType
<ilmi_initiate_portquery>
ILMI: Response Received and Matched (ATM0/0/1)
ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
ilmiPortTypeQuery
ILMI: Peer does not support UNI Type and Version. Setting default
ILMI: Assigning default device type (ATM0/0/1)
ILMI: My Device type is set to Node (ATM0/0/1)
ILMI: Auto Port determination enabled
ILMI: For Interface (ATM0/0/1)
ILMI: Port Information Complete :
ILMI: Local Information :Device Type = ilmiDeviceTypeNode Port Type =
ilmiPrivateUNINetworkSide
ILMI: Peer Information :Device Type = ilmiDeviceTypeUser Port Type =
ilmiUniTypePrivateMaxVpiBits = 0 MaxVciBits = 0
ILMI: KeepAlive disabled
ILMI : (ATM0/0/1) From ilmiIntfAwaitPortType To ilmiIntfPortTypeComplete <ilmi_find_peerPort>
Restarting Interface (ATM0/0/1)
ILMI : (ATM0/0/1) From ilmiIntfPortTypeComplete To AwaitRestartAck
<ilmi_process_intfRestart>
ILMI: Response Received and Matched (ATM0/0/1)
ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
ilmiAddressTableCheck
ILMI: Response Received and Matched (ATM0/0/1)
ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
ilmiPeerMgmtInfo
ILMI : (ATM0/0/1) From AwaitRestartAck To UpAndNormal <ilmi_process_response>
ILMI: Sending Per-Switch prefix
ILMI: Registering prefix with end-system 47.0091.8100.0000.0061.7059.4001
ILMI: Retrying on (ATM0/0/1)
ILMI: Retrying on (ATM0/0/1)
ILMI: Retrying on (ATM0/0/1)
ILMI: Retry expired on (ATM0/0/1)
==============================
We are also getting the customer to trace the activity of the 350L
from the Prioris using ATMMON utility. Will post the results here when I
get it.
Regards.
Andrew
|
| 914.15 | Caution: I am now speculating :-) | SMURF::PSH | Per Hamnqvist, UNIX/ATM | Thu May 01 1997 10:54 | 32 |
| Hi Andrew --
|ILMI : (ATM0/0/1) From ilmiIntfPortTypeComplete To AwaitRestartAck
| <ilmi_process_intfRestart>
|ILMI: Response Received and Matched (ATM0/0/1)
|ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
| ilmiAddressTableCheck
|ILMI: Response Received and Matched (ATM0/0/1)
|ILMI: Errored response <No Such Name> Intf (ATM0/0/1) Function Type =
| ilmiPeerMgmtInfo
I may be wrong on this one, but if I recall from my own debug of ILMI code
against the 1010 the two error responses actually come about when the Cisco
asks for properties in the ATM MIB that are not part of the UNI3.1 standard
MIB. I guess they may be ILMI 4.0 elemenets. At least UNIX *responds* with
negative on query of thise. The significant thing is RESPONDS. It would
appear as if the 350L is in fact communicating with the 1010 and is indeed
responding.
|ILMI : (ATM0/0/1) From AwaitRestartAck To UpAndNormal <ilmi_process_response>
|ILMI: Sending Per-Switch prefix
|ILMI: Registering prefix with end-system 47.0091.8100.0000.0061.7059.4001
|ILMI: Retrying on (ATM0/0/1)
|ILMI: Retrying on (ATM0/0/1)
|ILMI: Retrying on (ATM0/0/1)
|ILMI: Retry expired on (ATM0/0/1)
This leads me to think that the 350L is not even responding to the SET. Not
even bouncing it. Perhaps it is hanging, waiting for other event internal to
the 350L driver like a lock?
>Per
|
| 914.16 | He "thought" he was using V2.2 driver !!! | GIDDAY::CHONG | Andrew Chong - Sydney CSC | Thu May 01 1997 23:05 | 12 |
| Per,
Thanks for your support so far. I was talking to the customer this
morning and asked him to use ATNMMON utility . He could not find it in his
driver kit. The outcome of that was that we found out that he was actually using
V2.0 driver and NOT V2.2 as he thought he was !!!.
After he copied the V2.2 driver from the web site it works from NT V4.0.
He would like to know if V2.2 is supported on V3.51 NT .
Regards,
Andrew
|
| 914.17 | More info on WIN NT V4.0 | NNTPD::"[email protected]" | Youda Kopel | Fri May 02 1997 04:37 | 31 |
| Guys ,
This was in the DECATM.HLP file with the V2.2 kit. Here it is :
Adapter Software Installation/Configuration Procedure
After you have installed the ATM adapter hardware, you will use the
"Add Adapter" button on the Network Settings display to create one or more
LAN Emulation Clients or 1483 PVCs. From these configuration screensyou can
also configure parameters specific to the adapter port.
System Requirements:
>> 32 MB RAM
>> 1 MB available disk space
>> An Intel 486 processor or better
>> Windows NT v3.51 or later
Note: You must be logged on to Windows NT as the system administrator to
execute this procedure.
Is that correct to assume that V2.2 will support NT 4.0 ??? I know that we
have
not tested this as yet.........
Cheers ,
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|
| 914.18 | More info on WIN NT V4.0 | NNTPD::"[email protected]" | Youda Kopel | Fri May 02 1997 04:38 | 31 |
| Guys ,
This was in the DECATM.HLP file with the V2.2 kit. Here it is :
Adapter Software Installation/Configuration Procedure
After you have installed the ATM adapter hardware, you will use the
"Add Adapter" button on the Network Settings display to create one or more
LAN Emulation Clients or 1483 PVCs. From these configuration screensyou can
also configure parameters specific to the adapter port.
System Requirements:
>> 32 MB RAM
>> 1 MB available disk space
>> An Intel 486 processor or better
>> Windows NT v3.51 or later
Note: You must be logged on to Windows NT as the system administrator to
execute this procedure.
Is that correct to assume that V2.2 will support NT 4.0 ??? I know that we
have
not tested this as yet.........
Cheers ,
Youda Kopel ,
NPB Melb / Aust.
[Posted by WWW Notes gateway]
|