From: Chuck Church (cchurch@xxxxxxxxxxxx)
Date: Mon Jan 15 2001 - 16:13:48 GMT-3
I think another benefit of using IPXWAN is that it works like IP unnumbered,
you don't waste a network segment number on the wan connection itself.
Although you do need to assign an IPX internal net number to both sides of
the IPXWAN segment. So if you were using RIP, you end up with the same
number of routes because all the remotes now have an additional, internal
number. But if you had intended to run NLSP the whole time, you end up
saving some routes. As usual, there's a lot of different ways to do it.
Chuck Church
CCNP, CCDP, MCNE, MCSE
Sr. Network Engineer
Magnacom Technologies
140 N. Rt. 303
Valley Cottage, NY 10989
845-267-4000 x218
-----Original Message-----
From: Connary, Julie Ann [mailto:jconnary@cisco.com]
Sent: Monday, January 15, 2001 9:42 AM
To: Troy Rader
Cc: ccielab@groupstudy.com
Subject: Re: NLSP/IPXWAN IPX Questions concerning Fatkid 330
I thought that the main reason to use IPXWAN is to allow the two ends to
correctly determine the delay
of the link in stead of defaulting it to 6 ticks.
But looking in the manual it says:
The Cisco IOS software supports the IPXWAN protocol, as defined in RFC
1634. IPXWAN allows a router that is running IPX routing to connect via a
serial link
to another router, possibly from another manufacturer, that is also routing
IPX and using IPXWAN.
IPXWAN is a connection start-up protocol. Once a link has been established,
IPXWAN incurs little or no overhead.
You can use the IPXWAN protocol over PPP. You can also use it over HDLC;
however, the devices at both ends of the serial link must be Cisco routers.
To configure IPXWAN, use the following commands in interface configuration
mode on a serial interface:
Step
Command
Purpose
1 .
no ipx network
Ensure
that you have not configured an IPX network number on
the
interface.
2 .
encapsulation ppp
Enable
PPP.
3 .
ipx ipxwan [local-node {network-number | unnumbered}
local-server-name retry-interval retry-limit]
Enable
IPXWAN.
4 .
ipx ipxwan error [reset | resume | shutdown]
Optionally,
define how to handle IPXWAN when a serial link
fails.
5 .
ipx ipxwan static
Optionally,
enable static routing with IPXWAN. Note that the
remote
site must also use static routing.
From the RFC:
This document describes how Novell IPX operates over various WAN
media. Specifically, it describes the common "IPX WAN" protocol
Novell uses to exchange necessary router to router information prior
to exchanging standard IPX routing information and traffic over WAN
datalinks. This document supercedes RFC 1362 and RFC 1551. The
changes from RFC 1551 are to correct a problem in the wording when an
RFC 1362 router talks to an RFC 1551 router and to allow numbers to
be specified in a Router Name.
This document describes how Novell IPX operates over various WAN
media. It is strongly motivated by a desire for IPX to treat ALL wide
area links in the same manner. Sections 3 and 4 describe this common
"IPX WAN" protocol.
The IPX WAN protocol operation begins immediately after link
establishment. While IPX is a connectionless datagram protocol, WANs
are often connection-oriented. Different WANs have different methods
of link establishment. The subsections of section 1 of this document
describe what link establishment means to IPX for different media.
They also describe other WAN-media-dependent aspects of IPX
operation, such as protocol identification, frame encapsulation, and
link tear down.
Then it describes over ppp, x.25 and frame-relay or ATM
...
After the underlying data link connection is established as described
in the preceding media dependant description, the IPXWAN protocol is
activated to exchange identities and determine certain operational
charactaristics of the link.
There are two steps in the IPXWAN operation:
- Negotiating master/slave role and choice of routing protocol.
The master/slave roles persist for the IPXWAN exchanges only;
- Information exchange of final router configuration.
After these steps are concluded, transmission of IPX routing packets
begins - using the routing protocol negotiated - as well as
transmission of IPX data traffic.
3.1 The Initial Negotiation
The first exchange of packets decides the master/slave roles and the
routing protocol to be used on the link and gauges the link delay for
the routing metrics. The initial negotiation is the same for all
protocols.
After link establishment, both sides of the link send Timer Request
packets and start a timer waiting for a Timer Response. These Timer
Requests are sent every 20 seconds until a response is received or a
descision is made that the remote node is not responding. This could
be after a predefined time (min. 60 seconds) or a number of retries
(e.g., 16).
Reading through the rest - I don't really understand why you would need
this except to set the delay correctly.
Julie Ann
At 12:14 PM 1/14/2001 -0600, Troy Rader wrote:
>First, hi to the group. I am new here. Been lurking, waiting for the
>email letting me know I am ready to participate. Test date is Feb 17-18 in
>RTP.
>
>Sandy, I finished this same lab about an hour ago. My thoughts are:
>
>1. I wouldn't be surprised if Cisco expects us to know defaults for
>various Novell versions. With Appletalk, and others, off the test, I don't
>mind jamming some IPX details in my head. I noticed he didn't seem to
>specify encapsulation in any of the examples. My thought was that we
>needed to specify 'ipx network 404040 encap sap' on r4 e0 and r2 e0,
>although my IPX experience is now the sum of having done this lab.
>
>2. My nlsp worked fine on hdlc also. I don't have an answer. Perhaps
>someone else will provide the reason on this one.
>
>3. I did the same thing. Got it working without IPXWAN, then add it
>later. Seemed to work both ways. Just re-affirming what you said, but like
>you, waiting for someone to post the reason here.
>
>Troy
>
>
>
>On Sun, 14 Jan 2001, Sandy Turnage wrote:
>
> > I am working thru IPX Routing Lab 330
> > (http://www.fatkid.com/html/challenges.html) from fatkid.com and I have
> > a couple of questions:
> >
> > (1) In the hints section (2a) it states that Netware 3.12 servers
> > default to Novell's 802.3 encapsulation (novell-ether) and Netware 4.0
> > and above use 802.2 (sap). It's been a while since I setup a Netware
> > 3.12 server but I was pretty sure it defaulted to 802.2. (I agree with
> > the Netware 4.0 and above) This doesn't really matter *unless* they do
> > something like this in the lab. I would hope that cisco would specify
> > the desired frame type in the lab rather than expect one to know the
> > Netware defaults per version.
> >
> > (2) Again in the hints section (3c) it states that "NLSP cannot be sent
> > out out on HDLC encapsulated IPX serial connections". My NLSP seems to
> > work fine on my HDLC interfaces. Caslow says (pg 514) that "NLSP cannot
> > be configured on loopback interfaces or physical Frame-Relay interfaces.
> >
> > Also, it cannot be configured on frame-relay multipoint interfaces". He
> > doesn't mention HDLC. Should NLSP work across HDLC ?
> >
> > (3) Hints sections (3c) again, "NLSP requires IPXWAN on serial
> > circuits". Again, my NLSP seems to work fine without IPXWAN on the
> > serial circuits. I intend to reconfigure with IPXWAN on them but it
> > doesn't seem to be *required*.
> >
> > Am I missing something here?
> >
> > TIA,
> > ST
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:30 GMT-3