nfs across a system router.. eeek problems - NFS

This is a discussion on nfs across a system router.. eeek problems - NFS ; Greetings. I'm having a slight issue with some NFS file transfers. Configuration is like this: MACHINEA --> CISCO3600 --> SWITCH --> MACHINEB I also have a configuration like this: MACHINEA --> SWITCH (same one as abonve) --> MACHINEB On the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: nfs across a system router.. eeek problems

  1. nfs across a system router.. eeek problems

    Greetings.

    I'm having a slight issue with some NFS file transfers.

    Configuration is like this:

    MACHINEA --> CISCO3600 --> SWITCH --> MACHINEB

    I also have a configuration like this:

    MACHINEA --> SWITCH (same one as abonve) --> MACHINEB

    On the second configuration my NFS works fine.. however in the first
    configuration it will start to work fine and then after running for
    maybe 25 minutes (it's used for backups on some linux server) it will
    just die with messages:

    NFS server at xxx.xxx.xxx.xxx is not responding.
    Retrying: OK
    NFS server at xxx.xxx.xxx.xxx is not responding.
    Retrying: OK
    NFS server at xxx.xxx.xxx.xxx is not responding.
    Retrying: OK
    NFS server at xxx.xxx.xxx.xxx is not responding.
    Retrying: OK

    And the backup will die.

    Router configs for the two interfaces look like:

    interface FastEthernet0/0
    description Interconnect with 3024 Dell Primary Switch for the 63.174
    block
    ip address 63.174.xxx.xxx 255.255.255.0
    no ip redirects
    no ip unreachables
    duplex auto
    speed auto
    arp timeout 1800


    and

    interface FastEthernet1/1
    description Wireless / Highspeed Interface
    ip address 65.173.xxx.xxx 255.255.255.0
    no ip redirects
    no ip unreachables
    duplex auto
    speed auto
    arp timeout 1800

    Does anyone have any ideas why this would be happening?

    ~ Matt

  2. Re: nfs across a system router.. eeek problems

    Matt wrote:

    > Greetings.
    >
    > I'm having a slight issue with some NFS file transfers.
    >
    > Configuration is like this:
    >
    > MACHINEA --> CISCO3600 --> SWITCH --> MACHINEB
    >
    > I also have a configuration like this:
    >
    > MACHINEA --> SWITCH (same one as abonve) --> MACHINEB

    (snip)

    > NFS server at xxx.xxx.xxx.xxx is not responding.
    > Retrying: OK


    (snip)

    First, try NFS/TCP which should adjust to the delay better
    than UDP. Otherwise, try increasing the retransmission
    timeout values.

    -- glen


  3. Re: nfs across a system router.. eeek problems

    Matt wrote in message news:...
    > Greetings.
    >
    > I'm having a slight issue with some NFS file transfers.
    >
    > Configuration is like this:
    >
    > MACHINEA --> CISCO3600 --> SWITCH --> MACHINEB
    >
    > I also have a configuration like this:
    >
    > MACHINEA --> SWITCH (same one as abonve) --> MACHINEB
    >
    > On the second configuration my NFS works fine.. however in the first
    > configuration it will start to work fine and then after running for
    > maybe 25 minutes (it's used for backups on some linux server) it will
    > just die with messages:
    >
    > NFS server at xxx.xxx.xxx.xxx is not responding.
    > Retrying: OK
    > NFS server at xxx.xxx.xxx.xxx is not responding.
    > Retrying: OK
    > NFS server at xxx.xxx.xxx.xxx is not responding.
    > Retrying: OK
    > NFS server at xxx.xxx.xxx.xxx is not responding.
    > Retrying: OK
    >
    > And the backup will die.


    Why does the backup die? If you are mounting with "soft",
    please don't. Backups are too important to trust with "soft"
    mounts.

    > Does anyone have any ideas why this would be happening?


    As Glen says, NFS/TCP is your friend.

    If you are seeing this problem with TCP, since the difference
    is the router, one thing to look at is whether the MTU on the router
    is different than that of the client and server. If so, you could
    getting hit by a black hole router that fragments TCP segments,
    which normally should be sized to the smallest MTU on the route.
    Packet traces on the segments from client to router and
    router to server will help.

    If you are seeing this problem with UDP, try TCP. If you can't
    or for some reason won't use TCP, then I'd look out for dropped
    fragments due to the router. netstat -s on the client and server
    should display relevant statistics.

    Another possibility, which is independent of TCP vs. UDP is
    checksum errors caused by the router corrupting packets. netstat -s
    will help here.

+ Reply to Thread