3550 drops IPX connection.

Discussion in 'Cisco' started by Andy Lawson, Apr 23, 2004.

  1. It's been a few years since we were on an IPX network but......

    1) If I remember correctly an IPX router or server that sees a rip/sap
    advertisement coming into an interface with it's own MAC address as the
    source address will drop the advertisement and (I think) not learn any
    more rip/sap from that interface. One time we had two adjacent routers
    with the same mac address in their 'ipx routing ........' commands.
    Those two wouldn't talk IPX to each other. Could the redundancies that
    you have make the NW servers think that they see themselves out their
    own interface? They'd stop learning from that interface then - and if
    they only have one.........

    2) If you 'display networks' at 3 minute intervals do any of the network
    hop/tick counts increase with time? If so you have a routing loop
    somewhere. When they get to 16 they get dropped from the routing table.

    3) Interaction between NLSP & the 6.x servers and IPX? We had servers at
    two sites learn about each other via NWIP/NLSP and IPX/RIP/SAP. They'd
    each re-advertise everything via the other protocol but with a hop count
    of +1. Eventually the hop count would get to 16 & the server(s) would
    dissapear.

    4) How about monitoring rip/sap with the nearest IPX router. I'm
    assuming that your WAN/MAN routers are IPX'd? Are any routes in 'hold down'?

    As you can tell I'm thinking it is IPX routing related.

    300 stations is not too large. We ran 2000 or so IPX routes to 400 or so
    sites a few years ago.

    --Mike
     
    Michael Janke, Apr 27, 2004
    #21
    1. Advertisements

  2. Andy Lawson

    Hansang Bae Guest

    [snip]
    If hardcoding did not work, set both sides to Auto. You definitely have
    a) a cable longer than allowed or (more likely) b) duplex mismatch
    despite what your NIC is telling you. Sometimes, setting the duplex
    settings in inetcfg is not enough. You have to use the vendor supplied
    programs.


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Apr 27, 2004
    #22
    1. Advertisements

  3. Andy Lawson

    Hansang Bae Guest

    Better to just use E_II for everything and be done with it. But of
    course that will take some work and is neither here nor there.

    Be careful about those printers. Lot of them will auto detect frames
    and may cause issues for other clients.


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Apr 27, 2004
    #23
  4. Andy Lawson

    Hansang Bae Guest

    Have you done a bug scrub on CCO for any and all IPX related bugs?

    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Apr 27, 2004
    #24
  5. Andy Lawson

    Andy Lawson Guest

    Sorry - no can do. The policy here forbids it.....
    Not sure I agree, but there we go.

    I appreciate all the help and advice I've received, and I don't want to
    close this issue down yet - but I have received instruction from on high!
     
    Andy Lawson, Apr 27, 2004
    #25
  6. Andy Lawson

    Sam Wilson Guest

    Our experience is that our Novell servers (I don't have h/w and NIC
    details I'm afraid) only work well at 100HD. Setting them to, or
    allowing them to negotiate, 100FD leads to dropped packets and degraded
    performance. We're talking about reasonably old servers, of the order
    of a couple of years and older, running NW4 and NW5. I don't think we
    have any NW6 boxes - the policy has changed and all new kit runs
    Windows. Switching kit is mostly 3Com with some connections to Cisco
    core 6500 series boxes.

    Sam
     
    Sam Wilson, Apr 27, 2004
    #26
  7. Andy Lawson

    mh Guest

    From your Etherreal trace:

    1. Do you see that server advertising its IPX RIP routes ; probably
    should be just two - the internal network number and the external
    witha hop count of 0 and should be sent with a broadcast MAC address

    2. Ddo you see RIP routes from the other servers being received in the
    Ethereal trace? This is quite important because if you see them then
    it would indicatevthat for some reason your server is going deaf to
    RIP updates. IPX RIP updates are transmitted every 60 seconds by
    default. They would normally be sent to a MAC broddcast address and
    an IPX broadcast network address.

    3. When you do a IPX router reset, I would expect the server to sned
    out an IPX route request to a braodcast address. The response maybe
    UNICAST back to the requesting server.

    If your server accepts IPX RIP responses but does not accept IPX RIP
    braodcast, that may be a important clue...


    If you dont see RIP routes being received then that may indicate a
    switch issue.


    Are you going to post your switch config?
     
    mh, Apr 27, 2004
    #27
  8. Andy Lawson

    Hansang Bae Guest

    This was true when switches had issues with buffering and had stupid
    mechanisms for flow control.
    Some older nics simply could not auto negotiate. Worse it, it will not
    auto-negotiate if certain length cables are used. Today, they seem to
    be fine (for end users using auto-negotiate)
    Oop ack. I hate 3Com NICs in servers. Bad experiences all around. Too
    bad too....3c501s, 503s and 505's were fine. Starting with 509's and
    905s, they went down the tube.

    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Apr 28, 2004
    #28
  9. Andy Lawson

    Andy Lawson Guest

    Hello Andrey!
    Yes to all. The current speed/duplex mismatch issues probably arose when
    we were experimenting with different settings. I reluctant to fix this
    in case something else arises and I connot control the situation. At the
    moment I can at least get most of the functionality I need. If I change
    anything I could destroy that!
    The layer 2 physical ethernet connection is fine.
    We performed some further testing today (we have called in outside
    consultancy and needed to prove the fault).

    I set up continual IP and IPX pings to the server, and tripped the fault
    by disabling and renabling the port (FA0/9) on which the server (SL1) is
    connected (so it became the most recently connected IPX device). I saw a
    brief drop in both pings because the port was disabled.

    At this point I opened an RCONSOLE session to SL1.

    Sure enough, a few minutes later IPX ping stopped responding and my
    RCONSOLE session went dead. IP ping showed no dropped packets.

    I left IPX ping running, and then tripped the fault back to the other
    server (SL5) by disabling and renabling the port it is connected to
    (FA0/21). A few minutes later my IPX ping started receiving responses
    again. IP ping received continuous responses througout the test.

    The fact that no IP pings were lost (apart from when the port was
    disabled) indicates the fault is not caused by a drop in the layer 2
    connectivity between switch and server.

    We're still completely bamboozled, but at least the consultant now
    believes me!
     
    Andy Lawson, Apr 28, 2004
    #29
  10. Andy Lawson

    Sam Wilson Guest

    Possibly, but the constant factor was the server, with a whole range of
    switches. May have been NIC issues - see below.
    Indeed, but the problem was not with the negotiation, it was when the
    link ended up configured at 100FD no matter how that was arrived at.
    "*Switching kit* is mostly 3Com". I don't remember what the server
    NICs were, but they may well have been 3C90-somethings. We have also
    had Intel NICs which (I believe) perform better but I don't know if
    they fixed the 100FD/HD problems referred to above.

    I have to say I'm one of the guys who manage the switches and routers
    not one of the guys who manage the servers.

    Sam
     
    Sam Wilson, Apr 28, 2004
    #30
  11. :Oop ack. I hate 3Com NICs in servers. Bad experiences all around. Too
    :bad too....3c501s, 503s and 505's were fine. Starting with 509's and
    :905s, they went down the tube.

    I could be wrong, but I seem to recall the 503B's also had significant
    problems, and there was some other reason not to use 503A's [which
    might have been simply something like that they stopped selling them ;-) ]
    so for the 503's you always want to be sure you have a 503C or later.
    I also seem to recall hearing of a fault in 503Cs that wouldn't affect
    all that many people (mostly servers with multiple IPs on the NIC
    maybe it was), which lead to the 503D model being put out.

    I am going entirely on memory here, and working with PC NICs is not
    something I do very often, so the above should not be trusted...
    but "nasty fault with 503B" has lodged itself into my mind.
     
    Walter Roberson, Apr 28, 2004
    #31
  12. Andy Lawson

    Hansang Bae Guest

    Earlier switches and NICs had issues running at FD. From bad flow
    control mechanism (artificially long PAUSE) etc.

    Modern gear has addressed this.

    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Apr 29, 2004
    #32
  13. Andy Lawson

    Andy Lawson Guest

    Weeeeelllll.
    Touch wood - we seem to have fixed it.

    We replaced the switch with one with the same config, but a slightly
    updated IOS. The dud switch was running;

    IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(13)EA1a, RELEASE
    SOFTWARE (fc1)

    The new one is;

    IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(12c)EA1, RELEASE
    SOFTWARE (fc1)

    I know the version actually goes down, apparently this does not mean
    it's a less recent version of the software - bizarre.

    Before I swapped it out, I opened a TRACK ON screen at the servers. The
    server without a IPX routing table was not receiving any SAPs. The
    others were.

    I still don't understand how a switch, which knows nothing about IPX can
    actually filter the protocol out altogether. Unless it decided the
    packets were bogus and dropped them. But why only to that one port?

    Anyway. It works.

    Thanks for everyone's input and help. I understand our consultant is
    gonna raise a TAC case with Cisco, so maybe we'll get an answer at some
    time.

    Doubt it tho :)
     
    Andy Lawson, Apr 30, 2004
    #33
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.