> On Jun 2, 2019, at 3:50 AM, James Bensley <[email protected]> > wrote: > > > I recently upgraded from eXR 6.5.2 to 6.5.3 and pushed the files using > SCP to the router from a jump box, which was on the same LAN as the > management interface on the RSP. It was copying at 100Mbps (the speed > of the OOB switch) so I think in eXR these issues are more or less > fixed.
I don’t believe you have enough data to conclude that. When copying data from longer distances away (eg: global network with centralized file server/images) I previously saw bad behavior, but when the latency was low it worked well. This is what led me down the path to determine what was going on with the XR TCP stack. I suggest capturing a PCAP and figuring out if it’s doing SACK or window scaling with appropriate sized buffers. Even from bash/run on eXR you may also want to check this out. This led to an effort to internally anycast resources as it was a problem that was easier solved that way as Cisco was afraid to fix the TCP stack, and got even more worried when we saw issues with their SACK implementation and reported the details. (It was doing an ACK of the wrong number of bytes, which caused drama with super strict stateful firewalls that tried to be too smart for their own good). Also beware TCP disconnects as they don’t do TCP keepalives by default so any session that drops in the middle of a transfer would cause it to act like a file transfer is ongoing even though TCP was dead). - Jared _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
