On 7/24/2014 10:26 PM, Roland Dobbins wrote:
On Jul 25, 2014, at 9:13 AM, Larry Sheldon
wrote:
One other possibility--traffic not routed by most direct,
fire-wall-free route, but being detoured through a firewall.
Or a transparent layer-2 firewall that's in-line somewhere in the
path . . .
On Jul 25, 2014, at 9:13 AM, Larry Sheldon wrote:
> One other possibility--traffic not routed by most direct, fire-wall-free
> route, but being detoured through a firewall.
Or a transparent layer-2 firewall that's in-line somewhere in the path . . .
---
[Sorry about the null reply.]
On 7/24/2014 11:51 AM, Zach Hill wrote:
Also just to reiterate I would lean more heavily on something fishing in
the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp
window scaling properly, however it's only for Server A that is seeing
this. Server
On 7/24/2014 11:51 AM, Zach Hill wrote:
Also just to reiterate I would lean more heavily on something fishing in
the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp
window scaling properly, however it's only for Server A that is seeing
this. Server A is able to properly TCP win
I don't have root access to that server but I should be able to get it then
get some tcpdumps.
On Thu, Jul 24, 2014 at 3:18 PM, Matthew Petach
wrote:
>
>
>
> On Thu, Jul 24, 2014 at 12:13 PM, Zach Hill wrote:
>
>> All are from SPAN ports at each end. So for the second round of packet
>> captur
On Thu, Jul 24, 2014 at 12:13 PM, Zach Hill wrote:
> All are from SPAN ports at each end. So for the second round of packet
> captures Site 1 is from a SPAN port off the NIC of Server A. Site 2 is from
> a SPAN port off the NIC of the MPLS router.
>
> The first round of packet captures are only f
All are from SPAN ports at each end. So for the second round of packet
captures Site 1 is from a SPAN port off the NIC of Server A. Site 2 is from
a SPAN port off the NIC of the MPLS router.
The first round of packet captures are only from the SPAN port off the MPLS
router at Site 2.
On Thu, Jul
On Thu, 24 Jul 2014 14:33:56 -0400, Zach Hill said:
> First is the SYN from Server A to Server B http://i.imgur.com/E5cu4ev.png
Was this captured with tcpdump on Server A on its way out, or on Server B
on its way in, or at some other point using a span port? The answer matters
if we're suspectin
*First round of packet captures*
Here are the snippets from a packet capture.
First is the SYN from Server A to Server B http://i.imgur.com/E5cu4ev.png Here
is the SYN from Server B backhttp://i.imgur.com/RRSAl8G.png
Second test from Server C to Server B: First is the SYN from Server C to
Server
On Thu, Jul 24, 2014 at 9:51 AM, Zach Hill wrote:
> Also just to reiterate I would lean more heavily on something fishy in
> the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp
> window scaling properly, however it's only for Server A that is seeing
> this. Server A is able to
Also just to reiterate I would lean more heavily on something fishing in
the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp
window scaling properly, however it's only for Server A that is seeing
this. Server A is able to properly TCP window scale for any local traffic.
On Thu,
Hi Machael,
Let me setup another packet capture at each side to see if the initial
packets are being modified at all.
Thanks,
On Thu, Jul 24, 2014 at 12:39 PM, Michael Brown
wrote:
> On 14-07-24 12:30 PM, Zach Hill wrote:
> > Hi Tony. No firewall in the way.
> >
> > Physical flow is as below.
On 14-07-24 12:30 PM, Zach Hill wrote:
> Hi Tony. No firewall in the way.
>
> Physical flow is as below.
>
> Server A -> Nexus 7k -> 3845 router -> Sprint MPLS -> 3845 router -> Cisco
> 3750x stack -> Server B
>
I blame the cloud.
Dump the actual packets as they leave Server A and arrive at Server
On 14-07-24 12:25 PM, Tony Finch wrote:
> Zach Hill wrote:
>
>> What's interesting is this is only affecting a single server and only
>> when traffic is going over the WAN circuit. Testing from Server A to any
>> server on it's network shows it is negotiating window scaling just fine.
> Check your
Hi Tony. No firewall in the way.
Physical flow is as below.
Server A -> Nexus 7k -> 3845 router -> Sprint MPLS -> 3845 router -> Cisco
3750x stack -> Server B
On Thu, Jul 24, 2014 at 12:25 PM, Tony Finch wrote:
> Zach Hill wrote:
>
> > What's interesting is this is only affecting a single se
Zach Hill wrote:
> What's interesting is this is only affecting a single server and only
> when traffic is going over the WAN circuit. Testing from Server A to any
> server on it's network shows it is negotiating window scaling just fine.
Check your firewall isn't buggering about with TCP option
Hello,
I know this isn't precisely on topic but I'm having an issue that I could
use some assistance with.
I'm currently seeing a very interesting issue for a single server. File
transfers from Server A to Server B are relatively slow and not using up
much of the circuit. Upon further inspectio
17 matches
Mail list logo
