From: Nigel Taylor (nigel_taylor@xxxxxxxxxxx)
Date: Sun Feb 25 2001 - 16:03:11 GMT-3
Henry,
I was thinking about it and this thought came into my head.
Verizon should perform the "zero" test when they did the loop-testing..
This test gives a sure indication that the line(T1) is good for data. Also
since we use verizon as well normally they have devices at their Demarc
called smart-jacks. I know a couple of time when I tested out a couple of
our lines I had to disconnect the CSU/DSU connection from the smart
jack(demarc) so they could reset the circuit properly. Also they should be
more than willing to send you a loop so you can see if the CSU/DSU's on
either side sees the uni-directional loop to each end of the circuit.
I know the service they give sucks.. but if you really bother them they'll
have to do something to assist. I mean you're paying for the line
up/down... Remind them that you're the customer.
HTH
Nigel..
----- Original Message -----
From: Henry Dziewa <henryd31@home.com>
To: Scott Morris <smorris@mentortech.com>; 'Chuck Larrieu'
<chuck@cl.cncdsl.com>; 'Nigel Taylor' <nigel_taylor@hotmail.com>;
<ccielab@groupstudy.com>
Sent: Sunday, February 25, 2001 12:49 PM
Subject: RE: IPX Troubleshooting
>
> 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