traceroute between two datamovers

I will never understand why it's visible on some, and not on others.

Do this to enable server_tcpdump:

$ ln -s /nas/bin/server_mgr /nas/sbin/server_tcpdump

The syntax for the command is as follows:

$ /nas/sbin/server_tcpdump
 
usage: server_tcpdump { movername | ALL } 
-start device -w outfile
{ -host host_ip } { -s snaplen }
| -stop device
| -display

The device is the interface on the data mover you wish to capture the traffic from.
The outfile is the name of the file the capture file will be written to, it must be a file on a filesystem mounted on the data mover the capture is run from. So either a file must be created using an existing filesystem, or a temporary filesystem can be created to hold the capture file.
The host can be specified by IP address only; name resolution will not be used.
The snaplen is the amount of packet payload data in (decimal) bytes to capture, (used to limit the amount of data captured, the default capture size is 96 bytes).

sorry, there is no server_traceroute - only server_ping and server_netstat -r

If you have a minute it would be usefull if you could fill out a product enhancement request (PER) through Powerlink for this

We do have a server_tcpdump facility though...you might be able to take a network trace and analyze that for issues. You could do that on both sides and check anything within the LANs on each side. Perhaps it's an issue before it even leaves the site.

Thanks Rainer. Will do.

Bill,

I dont have tcpdump on mine. is it because of the version I have?

$ server_version ALL
server_2 : Product: EMC Celerra File Server Version: T5.5.30.504

i already put in an RFE for this ...i am suspecting will get it around 2012.

the more customers ask for it the better are the chances for it being delivered

actually - if you have a support expert onsite or dialed in there is a way to run a ttcp network bandwidth test between two data movers

Rainer
P.S.: so dont forget to ask for server_ttcp through a PER :_)

Thanks Bill. That works.

Rainer, I guess this is what you meant.
$.server_config server_2 -v "ttcp transmit=source_ip buflen=8192 nbuf=5120"

$ .server_config server_2 -v "ttcp receive buflen=8192 nbuf=5120"
server_2 : commands processed: 1
command(s) succeeded
output is complete

1217875668: ADMIN: 4: Command succeeded: ttcp receive buflen=8192 nbuf=5120

$ server_log server_2 |grep ttcp

One of the support guys gave me that. It gives the actual transfer rates.

Message was edited by:
atemc

yes, so what were the results ?

remember that its also a good idea to run it in both directions - there are network problems that can cause asymmetrical performance
you can also specify the window size to better match what you are using with Replicator

Here is the log on source node:

ttcp-t: buflen=8192 nbuf=5120 port=5001 tcp -> ::ffff:Destination_IP
ttcp-t: connect to ::ffff:Destination_IP
ttcp-t: 41943040 bytes in 122 real seconds = 342585 Bytes/sec +++
ttcp-t: 5120 I/O calls, sec/call = 0, calls/sec = 41
ttcp-r: buflen=8192 nbuf=5120 port=5001 tcp
ttcp-r: accept from ::ffff:Destination_IP
ttcp-r: 41943040 bytes in 8 real seconds = 5176874 Bytes/sec +++
ttcp-r: 29223 I/O calls, sec/call = 0, calls/sec = 3606

Pushing transfer rate is much lower than receiving from the destination node. At this point it seems it is a network issues but their point seems to make sense because it is the same pipe/route being used for both directions.