In our case, we followed the setup championed in various novell TIDs.

It was fairly easy to assess the outcome of the stereotypical trade-off in
this case.

1. when we attempted to browse an nds tree via slp and access files via
ncp/tcp, it was many times faster than similar activities performed when
the stack choice was forced to IPX., so we felt no need to turn to UDP for
the purposes of maintaining lower overhead during a given session.
2. we had enough issues with data integrity that using a
connection-oriented transport provided some small measure of relief from
those who would blame all digital computing problems on the
network/internetwork.

YMMV.

I sent the packet in question because it was part of the only netware trace
file on my work pc that was saved in a format etherpeek 4.0 could handle
(thereby ensuring that the process of posting lasted under 2 minutes); I
used etherpeek because that's the only decent way I know of to print out
both the decode & hex for a given packet (any alternative suggestions would
be greatly appreciated).

However, that capture only contained keepalives generated during the course
of a VPN session.

Since you're comfortable with the ncp header format, I've found more
enlightening captures & filtered for netware traffic, so i'll clean them up
& send them directly.









Priscilla Oppenheimer  on 11/13/2001 02:06:22 PM
To:   "[EMAIL PROTECTED]" ,
      [EMAIL PROTECTED]
cc:
Subject:  NetWare Core Protocol over TCP


I am interested to know how many people use NetWare Core Protocol (NCP)
over TCP. Like Howard, I didn't think this was the normal way of handling a
migration from IPX to IP, although it certainly makes sense.

So, a survey: can people on the list let us know if they use this?

Note: I'm not criticizing Kevin, just gathering information.

Regarding PEP, I did some research too. I couldn't find any proof that the
transport-like part of NCP was based on PEP, which I thought disappeared,
but it does make sense. The service provided by PEP is essentially the same
as the service that NCP provides in its "integrated transport" level, to
use Howard's great terminology.

I would love to get a Sniffer trace of NCP over TCP. I have a rather old
version of Sniffer but a brand new version of EtherPeek. Also I know NCP
really well so I might recognize some stuff even if the decoder doesn't.
The packet you sent before is just the TCP SYN. Do you have something later
in the session with some NCP data? Could you send me (not the list) an
attachment of a cleaned up trace file? I'll acknowledge you in my new
book!  ;-) THANKS.

Priscilla

At 12:26 AM 11/13/01, [EMAIL PROTECTED] wrote:
>5.0 with an unmanageably large number of service pack applications.
>
>I believe the NWIP encapsulation as a preferred means of exchanging
packets
>idea was buried with version 4. NW 5 servers may be installed with support
>for either or both protocol stacks.
>
>There exist various modules centering around the acronym cmd which
>allegedly facilitate hybrid environments slated to migrate to ip only.
It's
>possible that servers thus configured encapsulate ipx within ip, but I'm
>far too undermotivated to ascertain the validity of that guess.
>
>I suppose that Novell has been fairly successful at obscuring the original
>meaning of PEP: many hits on general web searches turn up some documents
on
>programmatically generating & sending ipx packets in the name of
fine-tuing
>network diagnostic tools such as DOOM. Seaching Novell leads you to
>conclude that it refers to their Professional Education Program.
>
>
>
>
>
>"Howard C. Berkowitz" @groupstudy.com on 11/12/2001 06:22:40
>PM
>
>Please respond to "Howard C. Berkowitz"
>
>Sent by:  [EMAIL PROTECTED]
>
>To:   [EMAIL PROTECTED]
>cc:    (bcc: Kevin Cullimore)
>Subject:  RE: What frame format used by TCP/IP? [7:25924]
>
>
> >In contrast to the IPX-based implementation described below, packet
> >captures seem to reveal that NCP DOES rely on a transport layer when
using
> >IP as a network layer mechanism.
>
>What version of NetWare?  It's my understanding that 5.x is native
>TCP/IP with encapsulated IPX available for backwards compatibility.
>
>Incidentally, older IPX-based NCP had an integrated transport
>function, not SPX but something called PEP.
>
> >
> >   Flags:        0x00
> >   Status:       0x00
> >   Packet Length:66
> >   Timestamp:    19:09:38.677828 03/12/2001
> >Ethernet Header
> >   Destination:  00:90:7F:0F:0B:D5
> >   Source:       00:10:A4:F5:5A:66
> >   Protocol Type:0x0800  IP
> >IP Header - Internet Protocol Datagram
> >   Version:              4
> >   Header Length:        5  (20  bytes)
> >   Precedence:           0
> >   Type of Service:      %0000
> >   Unused:               %0
> >   Total Length:         48
> >   Identifier:           14671
> >   Fragmentation Flags:  %010  Do Not Fragment
> >   Fragment Offset:      0  (0  bytes)
> >   Time To Live:         128
> >   IP Type:              0x06  TCP
> >   Header Checksum:      0xF3B3
> >   Source IP Address:    210.225.86.53
> >   Dest. IP Address:     xxx.xxx.xxx.x  xxx.xx.xxxxxx.xxx
> >   No Internet Datagram Options
> >TCP - Transport Control Protocol
> >   Source Port:      2583
> >   Destination Port: 524  NCP
> >   Sequence Number:  1273813107
> >   Ack Number:       0
> >   Offset:           7
> >   Reserved:         %000000
> >   Code:             %000010
> >             Synch Sequence
> >   Window:           16384
> >   Checksum:         0x44D7
> >   Urgent Pointer:   0
> >   TCP Options:
> >     Option Type:    2  Maximum Segment Size
> >         Length:     4
> >         MSS:        1460
> >     Option Type:    1  No Operation
> >     Option Type:    1  No Operation
> >     Option Type:    4
> >         Length:     2
> >         Opt Value:
> >   TCP Data Area:    No more data.
> >Frame Check Sequence:  0x04007C00
> >
> >


________________________

Priscilla Oppenheimer
http://www.priscilla.com





================================================================
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
================================================================




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=26142&t=26142
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to