From: Henry Dziewa (henryd31@xxxxxxxx)
Date: Sun Feb 25 2001 - 14:49:26 GMT-3
Thanks to everyone who responded to my question.
I don't have remote access to that network and can't really
try anything as of right now.
Anyway, Chuck, the problem here is that I don't even have to go to any
Novell servers, I get errors already on router to router basis, serial
interface to serial interface. Don't have to go any further than that
where the problems begin.
Nigel, your suggestion is obviously reasonable. The only problem
is that the local telco (Verizon) doesn't give much sh** about a
small company like my client and they don't want to send techs
to these locations and test with T-Berd equipment. However, they
tested (they say) to the loops to both CSU's and couldn't find
anything wrong. But, thanks for the advice on setting up the tunnel
between the sites. Didn't think of that myself, will have to give
it a try...
Thanks again group ! You're the best !
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Scott Morris
Sent: Sunday, February 25, 2001 7:18 AM
To: 'Chuck Larrieu'; 'Nigel Taylor'; 'Henry Dziewa';
ccielab@groupstudy.com
Subject: RE: IPX Troubleshooting
Ya know... Sad as it may be, that was one of the original reasons for
extending BGP into MBGP (multiprotocol BGP)... People actually believed
there was going to be an IPX internet!
Granted, now it's used more for multicast, and eventually for IPv6, but
still... Scary stuff.... :)
All I would have to say is, "Ewwwwww".
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Chuck Larrieu
Sent: Sunday, February 25, 2001 12:36 AM
To: Nigel Taylor; 'Henry Dziewa'; ccielab@groupstudy.com
Subject: RE: IPX Troubleshooting
Guys, I was actually thinking about this as an exercise in testing one's
knowledge of IP and IPX. I think it came about when I was pondering earlier
questions about IPX addressing that someone posed.
Consider the problem: the great minds of the world wake up one morning and
realize that IP is part of an alien conspiracy to undermine earth and
enslave its inhabitants. Unless the world moves to IPX ASAP, we will become
fish food for the inhabitants of Grand Gamma Scorpio. Within 1 year, the
entire internet MUST be converted to IPX.
Now then, what would have to be done? I.e what does IP do that IPX does not?
What does IPX do that IP does not? What would need to be done to ipx to
deliver all of the necessities of IP? What could be ignored? What about
addressing space? Summarization? Routing tables? Routing protocols?
Filtering?
It should be obvious that I have either been studying too hard or haven't
been studying hard enough. :->
Chuck
-----Original Message-----
From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
Sent: Saturday, February 24, 2001 7:27 PM
To: Chuck Larrieu; 'Henry Dziewa'; ccielab@groupstudy.com
Subject: Re: IPX Troubleshooting
Henry,
I'm sure there is a more reasonable explanation as to why your
experiencing this problem. In most cases although pings/extended pings and
values like the "crc" and "reliability" are great ways to detect a bad line
when it comes to the physical layer, there's nothing like a good "BERT"
test. The fact that your CSU/DSU is able to sync up end-to-end is a good
indication that overall circuit(T1) is good. I would suggest using a bert
tester end-to-end (r1<-->r2) and as well have the telco put up a couple
loop(s) to either side of the circuit to check and recheck all of your
configurations(timing, framing..etc.). Quite possibly maybe even testing
out a tunnel configuration for IPX over IP and see if you experience the
same problems.
HTH
Nigel.
P.S I thought Novell was a "native IP" product now... :-> The word
"legacy" sure says it all, doesn't it...!
----- Original Message -----
From: Chuck Larrieu <chuck@cl.cncdsl.com>
To: 'Henry Dziewa' <henryd31@home.com>; <ccielab@groupstudy.com>
Sent: Saturday, February 24, 2001 9:42 PM
Subject: RE: IPX Troubleshooting
> Since this is for your client, we of course expect a cut of your revenue
for
> this ;->
>
> What version Novel NOS? what is the frame type you are running? I vaguely
> recall issues with raw versus 802.2 frames.
>
> On the Novell servers, are your nics configured correctly - both on the
> hardware side and the NLM side. Again, I vaguely recall issues.
>
> Also, do your client stacks allow for enough SPX sockets? Once again, I
> vaguely recall issues.
>
> As a general caveat, there can be a number of things with Novell, at least
> in the 3.12 and 4.1 and 4.11 world I knew, that might result in packet
loss.
>
> Or it could be that you just need more bandwidth. Moving from 384k to full
> T1 solved a lot of problems I used to have. ;->
>
> Chuck
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Scott Morris
> Sent: Saturday, February 24, 2001 5:29 PM
> To: 'Henry Dziewa'; ccielab@groupstudy.com
> Subject: RE: IPX Troubleshooting
>
> Try an extended IPX ping and choose the option "sweep sizes".
>
> Without understanding any of the specifics of your configuration, off the
> top of my head, one important thing to note would be MTU sizes...
Remember
> that IPX can NOT be fragmented. This means if you have an IPX packet on
one
> side (LAN?) of your network that's too big, then your router tries to put
it
> out the other side (WAN?) with a smaller MTU. If a packet is too big it
> won't work.
>
> Other things like RIP updates, EIGRP, SAP, etc. will work fine, because
> they're set as a small packet specifically for this reason.
>
> Anyway, something worth looking into since everything else seems to work
> just fine. Check your MTU's, and use the extended ping to sweep sizes and
> see what works and what doesn't.
>
> Hope this helps!
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Henry Dziewa
> Sent: Saturday, February 24, 2001 8:01 PM
> To: ccielab@groupstudy.com
> Subject: IPX Troubleshooting
>
>
> Hello group,
>
> Here is a problem I've been faced with. I have very simple
> network for a small client. The config is like this, r1 connects
> to r2 over dedicated T1. 6 DS0's of this T1 are split at the CSU/DSU
> and go to a "PBX", so I'm left with 18 DS0's for data.
> There is IP and IPX involved. There are Novell servers on each of these
> two sites. Routing protocol is EIGRP for IP, EIGRP IPX on the WAN, and
> obviously IPX RIP on the LAN. The problem is that I loose IPX packets
> going thru the WAN link. I tested all over the place, I was placing loops
> everywhere possible on either side. I worked with Telco, they don't see
> any errors on the line. The strangest thing is that with IP there is no
> problem at all. Only when using extened IPX pings, even between the
> Serial interfaces, I keep on loosing packets. The problem to the
> end stations is that the Novell mapped drives are very slow, the documents
> being opened are hanging the systems, and more of such nightmares :(
>
> I even tried testing with different routers and still no go. It would seem
> that I have a problem with the Telco. However, like I said, there is no
> problem
> with IP traffic at all !!! I don't get any errors on the interfaces, the
> only errors
> that come up sometimes are CRC's - yes I verified/played with the timing
as
> well - when I do extended IPX pings but not when I do IP extended pings.
> With loopbacks, everything works great until I go out to the Telco,
> once the line is crossed to the telco, I get the errors - but again only
> with IPX.
>
> Any ideas to this problem would be appreciated..
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:00 GMT-3