Community support list for Wireshark ()

Andrea | 14 Jul 2012 19:11

Spanning tree can slow the network?

Hello guys,
I've captured network traffic from some customer's LAN for monitor 
behaviour of slow applications, in all cases I've found spanning tree 
packets that slow the transactions, like this:

     Spanning-tree-(for-bridge)  STP  Cost=4  port=0x8003

every time there is a spanning tree packet follow after a pause of time 
(about 1 sec.)  before arrives other data packets, this behaviour I've 
seen either in LAN with many switches and in LAN when switch was only one.

How it is possible? I don't have configure spanning tree on switches. 
Can this be a normal behaviour ?

Thanks
Andrew
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Patrick Preuss | 14 Jul 2012 19:21

Re: Spanning tree can slow the network?

Hi Andrea,

Spanning Tree is normal in switched networks, Bridges must send them.

A Problem can be recalculation and reordetring of the tree.

If you what to read more about this you can read "interconnections" from radia perlmann.

Hth

Cheers

Patrick

Am Samstag, 14. Juli 2012 schrieb Andrea :

Hello guys,
I've captured network traffic from some customer's LAN for monitor behaviour of slow applications, in all cases I've found spanning tree packets that slow the transactions, like this:

Spanning-tree-(for-bridge) STP Cost=4 port=0x8003

every time there is a spanning tree packet follow after a pause of time (about 1 sec.) before arrives other data packets, this behaviour I've seen either in LAN with many switches and in LAN when switch was only one.

How it is possible? I don't have configure spanning tree on switches. Can this be a normal behaviour ?

Thanks
Andrew
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users <at> wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Andrea | 14 Jul 2012 19:41

Re: Spanning tree can slow the network?

Thanks Patrick

But I don't understand why this pause occurs always on this sequence:

716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 > microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00    STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port = 0x8003
718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP segment of a reassembled PDU]
719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79    HTTP/1.1 100 Continue

More than one second to receive another packet from the server (192.168.1.2) , I think this cannot be normal behaviour.
How do I know if is normal or if it is possible optimize it?

Hi Andrea,

Spanning Tree is normal in switched networks, Bridges must send them.

A Problem can be recalculation and reordetring of the tree.

If you what to read more about this you can read "interconnections" from radia perlmann.

Hth

Cheers

Patrick

Am Samstag, 14. Juli 2012 schrieb Andrea :
Hello guys,
I've captured network traffic from some customer's LAN for monitor behaviour of slow applications, in all cases I've found spanning tree packets that slow the transactions, like this:

Spanning-tree-(for-bridge) STP Cost=4 port=0x8003

every time there is a spanning tree packet follow after a pause of time (about 1 sec.) before arrives other data packets, this behaviour I've seen either in LAN with many switches and in LAN when switch was only one.

How it is possible? I don't have configure spanning tree on switches. Can this be a normal behaviour ?

Thanks
Andrew
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Patrick Preuss | 14 Jul 2012 19:58

Re: Spanning tree can slow the network?

You can trace on both end to See how well packets are placed time ( Maybe ntp) is Importand. So You can see where your packets are Late.

Is this only this server?

Maybe you have a problem there? Time bewegen packets go to and come from The server.

Try to get tcp Open sequence. Most of this programms are in memory and you get neary The Network performance. Capture this on both ends best with tabs they have less impact on The enviroment.

Patrick

Am Samstag, 14. Juli 2012 schrieb Andrea :

Thanks Patrick

But I don't understand why this pause occurs always on this sequence:

716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 > microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00    STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port = 0x8003
718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP segment of a reassembled PDU]
719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79    HTTP/1.1 100 Continue

More than one second to receive another packet from the server (192.168.1.2) , I think this cannot be normal behaviour.
How do I know if is normal or if it is possible optimize it?

Hi Andrea,

Spanning Tree is normal in switched networks, Bridges must send them.

A Problem can be recalculation and reordetring of the tree.

If you what to read more about this you can read "interconnections" from radia perlmann.

Hth

Cheers

Patrick

Am Samstag, 14. Juli 2012 schrieb Andrea :
Hello guys,
I've captured network traffic from some customer's LAN for monitor behaviour of slow applications, in all cases I've found spanning tree packets that slow the transactions, like this:

Spanning-tree-(for-bridge) STP Cost=4 port=0x8003

every time there is a spanning tree packet follow after a pause of time (about 1 sec.) before arrives other data packets, this behaviour I've seen either in LAN with many switches and in LAN when switch was only one.

How it is possible? I don't have configure spanning tree on switches. Can this be a normal behaviour ?

Thanks
Andrew
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request <at> wireshark.org?subject=unsubscribe

___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Jim Aragon | 14 Jul 2012 21:27

Re: Spanning tree can slow the network?

At 10:41 AM 7/14/2012, you wrote:

But I don't understand why this pause occurs always on this sequence:

716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 > microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00    STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port = 0x8003
718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP segment of a reassembled PDU]
719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79    HTTP/1.1 100 Continue

More than one second to receive another packet from the server (192.168.1.2) , I think this cannot be normal behaviour.

It would be easier for us to possibly analyze what's going on if you'd post an actual capture file somewhere (perhaps www.cloudshark.org) instead of a partial text listing. Try to capture the start of the conversation so that the TCP three-way handshake is present in the trace file. If necessary, remove any confidential information from the trace file. Include the full STP frames.

Jim

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Jim Aragon | 15 Jul 2012 06:21

Re: Spanning tree can slow the network?

At 10:41 AM 7/14/2012, Andrea wrote:

> Hello Jim, here is my first cut of tracefile:
>
> http://www.cloudshark.org/captures/4b8cf621d044
> It contains conversation from when I first start application,
> and on row 717 there is first spanning tree.

Ok, let's take a look at this data.

There are 8 STP frames in this trace file: Numbers 1, 2, 57, 61, 258, 717, 776, and 6254.

You said there was about a one-second delay between an STP and the next packet from the server (192.168.1.2). So let's look only at STP frames and TCP packets FROM the server. Our display filter is "(tcp && ip.src==192.168.1.2) || stp". The time delays between each STP frame and the next TCP packet from 192.168.1.2 are:

After frame 1: No traffic, and our application hasn't started yet.
After frame 2: 0.504272 seconds, but when we see frame 2, our application hasn't started yet, so we don't count this.
After frame 57: No traffic between the STPs in 57 and 61.
After frame 61: 1.557721 seconds
After frame 258: 0.054305 seconds
After frame 717: 0.690998
After frame 776: 0.059590 seconds
After frame 6254: 0.000001

The average of these delay values is 0.472523 seconds. Yes, we have one value that's over a second and a half, but we've got three values that are under 0.06 seconds.

I don't see a consistent one-second delay. In fact, this looks pretty normal to me. I think you're just seeing the normal variation of network traffic. Sometimes there are pauses in the communications for various reasons, but they are unrelated to STP.

Jim

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

James Howard Young | 15 Jul 2012 09:14

Re: Spanning tree can slow the network?

On 7/14/12 1:41 PM, "Andrea" <an.celli@...> wrote:
>But I don't understand why this pause occurs always on this sequence:
>
>716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 >
>microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
>717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00
>   STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45  Cost = 0  Port =
>0x8003
>718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP
>segment of a reassembled PDU]
>719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79
>HTTP/1.1 100 Continue
>
>
>
>More than one second toreceive another packet from the server
>(192.168.1.2) , I think this cannot be normal behaviour.
>
>How
>do I know if is normal orif it is possible optimize it?

And On 7/15/12 12:21 AM, "Jim Aragon" <Jim@...> wrote:

>At 10:41 AM 7/14/2012, Andrea wrote:
>
>> Hello Jim, here is my first cut of tracefile:
>>
>> http://www.cloudshark.org/captures/4b8cf621d044
> <http://www.cloudshark.org/captures/4b8cf621d044>> It contains
>conversation from when I first start application,
>> and on row 717 there is first spanning tree.
>
>Ok, let's take a look at this data.
>
>There are 8 STP frames in this trace file: Numbers 1, 2, 57, 61, 258,
>717, 776, and 6254.
>

<snip>

Andrea,

I doubt the spanning tree packets have anything to do with your
stall.

If you apply a display filter for just the Spanning tree packets
(stp) you will see that a spanning tree packet is sent every two
seconds (+/-).  This is a typical rate that one might see stp
packets sent by a device.  (FWIW: All your spanning tree packets
are sourced from the device on your network with mac address
00:10:f3:1e:63:47.  If you had multiple devices sending STP
packets your would have a less obvious stp packet rate unless
and until you start filtering by source mac address and stp.)

With the stp display filter in place you can easily see the
metronome like rate of the stp packets if you switch the default
time column to "Seconds since previously displayed packet" or
better yet add a "Delta Time Displayed" column adjacent to the
default "Time (format as specified)" column.

Your trace appears to have been captured on the host with mac address
3c:d9:2b:6e:7e:84 (which also happens to have ipv4 address of
192.168.1.12).  We can make this assumption because the TCP packets
that are sourced from 192.168.1.12 have "bad" CRC values while TCP
packets from other hosts have "good" CRC values.  In spite of seeing
"bad" CRC values it should be obvious that these packets are part of
a successful and ongoing TCP dialogs with the host at 192.168.1.2.
Having a trace file with "bad" CRC values for TCP packets sourced
from one specific host is consistent with a trace file that was
captured on a machine with checksum offloading enabled.  Wireshark's
packet capture mechanism (libpcap/winpcap) is implemented in the
system's OS and will not see the final ip checksum fixups applied
to the outgoing packets by the nic card before the packet is put on
the wire.  

Let's assume that the spanning tree packets are not related to
your problem and exclude them from the trace.  Apply a display
filter of "!stp".

With the stp packets out of the way you appear to be concerned with
the 1.976671 second pause between frames 716 and 718.

Frame 716 is simply a TCP ACK packet sent by 192.168.1.12 to 192.168.1.2.
Frame 718 is a HTTP POST sent by 192.168.1.12 to 192.168.1.2.

I think that the delay you see between packets 716 and 718 is simply
the host processing time it took host 192.168.1.12 (the machine that
the sniffer was running on) to generate the HTTP POST packet sent
in packet 718.

Hope this helps,

Jim Y.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Andrea | 15 Jul 2012 11:24

Re: Spanning tree can slow the network?

Il 15/07/2012 09:14, James Howard Young ha scritto:
> I think that the delay you see between packets 716 and 718 is simply
> the host processing time it took host 192.168.1.12 (the machine that
> the sniffer was running on) to generate the HTTP POST packet sent
> in packet 718.
>
> Hope this helps,

Thanks  all guys for good answers,  so I see that STP is not the problem 
in my case and these delay second due to host processing time (client).

But I don't know why this application take too many time to start (about 
25 seconds), please take a look on this second trace (another cusotmer 
LAN with the same app starts):
http://www.cloudshark.org/captures/e95c1068086f

from packets 680 to 701 has been nearly 2 seconds meanwhile there are 
many multicast packets, can this a contribute to cause this delay?

And in the same case (and same trace file but beacuse is too big I've 
split the file), I've seen many TDS protocol  (SQL transaction) with 
malformed packets:
http://www.cloudshark.org/captures/2c90ee59e7fa

take a look at packets 80 , 156, 213, 245, 251, 275, 297, 307 , etc..

what do you think of this?

Andrew
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Patrick Marc Preuss | 15 Jul 2012 13:37

Re: Spanning tree can slow the network?

Hi Andrea

have you a running installation of this application ? 
What are the differences in the installation, network environment, running protocols (IPv4, IPv6), DNS
Resulution and so on? 

Are Parts installed on the fileserver ? You have some questions for ERP App to the file server. 

Can you match packets to events on the Client? 

Packtets to login screen, Packets to Part of the UI, Packets to Full UI and so on. 

When is the application slow ? Startup, During runtime, Special Querys?  

You don't have much multicast in the network. 

Cheers 

Patrick

Am 15.07.2012 um 11:24 schrieb Andrea:

> Il 15/07/2012 09:14, James Howard Young ha scritto:
>> I think that the delay you see between packets 716 and 718 is simply
>> the host processing time it took host 192.168.1.12 (the machine that
>> the sniffer was running on) to generate the HTTP POST packet sent
>> in packet 718.
>> 
>> Hope this helps,
> 
> Thanks  all guys for good answers,  so I see that STP is not the problem in my case and these delay second due to
host processing time (client).
> 
> But I don't know why this application take too many time to start (about 25 seconds), please take a look on
this second trace (another cusotmer LAN with the same app starts):
> http://www.cloudshark.org/captures/e95c1068086f
> 
> from packets 680 to 701 has been nearly 2 seconds meanwhile there are many multicast packets, can this a
contribute to cause this delay?

This is not many multicast this is some multicast. This are IPv6 host telling the world some information.
 This is no problem  

> 
> And in the same case (and same trace file but beacuse is too big I've split the file), I've seen many TDS
protocol  (SQL transaction) with malformed packets:
> http://www.cloudshark.org/captures/2c90ee59e7fa
> 
> take a look at packets 80 , 156, 213, 245, 251, 275, 297, 307 , etc..
> 
> what do you think of this?
> 
> Andrew
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@...>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>            mailto:wireshark-users-request@...?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Jim Aragon | 15 Jul 2012 19:12

Re: Spanning tree can slow the network?

At 02:24 AM 7/15/2012, Andrea wrote:

>But I don't know why this application take too many time to start (about
>25 seconds), please take a look on this second trace (another cusotmer
>LAN with the same app starts):
> http://www.cloudshark.org/captures/e95c1068086f

Does the application always take a long time to start, or only in certain environments?

Jim

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

James Howard Young | 16 Jul 2012 04:39

Re: Spanning tree can slow the network?

Hello Andrew,

On 7/15/12 5:24 AM, "Andrea" <an.celli@...> wrote:
>Thanks  all guys for good answers,  so I see that STP is not the problem
>in my case and these delay second due to host processing time (client).
>
>But I don't know why this application take too many time to start (about
>25 seconds), please take a look on this second trace (another cusotmer
>LAN with the same app starts):
>http://www.cloudshark.org/captures/e95c1068086f
>
>from packets 680 to 701 has been nearly 2 seconds meanwhile there are
>many multicast packets, can this a contribute to cause this delay?
>

In your case2.pcapng trace file you again have a device sending
stp packets every two seconds (this time the device with mac
address 00:14:7c:2c:08:38).   And like in your original trace these
stp packets have nothing to do with your delays.

This trace appears to have been taken on host with mac address
2c:27:d7:1f:a6:85 (ipv4 address 192.168.70.40).  We can make this
assumption because all of the ip header checksum errors are
associated with this one host (192.168.70.40), this is consistent
with header checksum offloading.

Disregarding the non-tcp packets you noted a delay between packets
680 and 701.   But these two packets belong to two different TCP
conversations.  

The delay that is perhaps more important is the one between frame
680 and frame 705 of 1.678714 seconds which are two packets from
the same conversation.  And similar to the first trace you posted
you will see that frame 680 is a TCP ACK sent by 192.168.70.40
(after a delay of about 0.2 seconds from the previous packet) and
that frame 705, the next frame in that conversation is also and
egress packet from the 192.168.70.40.  This again looks like client
side processing delay.

Frame 701 is a part of a different TCP conversation.  The previous
frame from this conversation was 445 which was a TCP ack followed
2.096514 seconds later by frame 701, an http POST.

The biggest tcp conversation delay I saw was 4.347130 seconds
between frame 67 and 98 which again follows the same pattern in
that both packets are egress packets from 192.168.70.40 on one
particular conversation.

>And in the same case (and same trace file but because is too big I've
>split the file), I've seen many TDS protocol  (SQL transaction) with
>malformed packets:
>http://www.cloudshark.org/captures/2c90ee59e7fa
>
>take a look at packets 80 , 156, 213, 245, 251, 275, 297, 307 , etc..
>
>what do you think of this?
>
>Andrew

Cloudshark is flagging these packest as "[Malformed Packet: TDS]".
But my copy of Wireshark reports the same "malformed" packets as:

> "[Expert Info (Warn/Reassemble): Unreassembled Packet (Exception
>occurred)]"

My Wireshark is a development version 1.9.0-SVN-43660 (SVN Rev 43660 from
/trunk) which I recently downloaded from Wireshark's development build
folder.

These same messages exist in your other trace files for some of the TDS
packets and also for some of the SMB packets.  I suspect this is simply
a parsing/dissecting issue due to unexpected/unknown TDS and SMB dialects
and/or extensions.  I doubt Wireshark's inability to fully parse these
packets is indicating that you have found the root cause of your delay
issues.

Unfortunately I haven't seen any smoking gun in your traces that indicates
you have a network issue that is causing your delays.  Virtually all the
client requests are answered by the server virtually immediately.  But
others with more TDS and/or SMB experience may have a different opinion.

Best regards,

Jim Y.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Andrea | 16 Jul 2012 22:42

Re: Spanning tree can slow the network?

Il 16/07/2012 04:39, James Howard Young ha scritto:
> The biggest tcp conversation delay I saw was 4.347130 seconds between 
> frame 67 and 98 which again follows the same pattern in that both 
> packets are egress packets from 192.168.70.40 on one particular 
> conversation.

I'm glad thatyou don't find any issue on my trace file, however I don't 
able to know why there is a delay of 4.34 sec. for a client/server 
conversation when client is new pc with windows 7 and there isn't any 
applications opens (only wireshark and my app)

I see that TDS packets malformed can due dissector protocol, is strange 
because I've try to change it to big-endian as follow this article:
http://ask.wireshark.org/questions/3475/tds-malformed-packet

but it show me always malformed packets..

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Andrea | 15 Jul 2012 01:10

Re: Spanning tree can slow the network?

Hello Jim, here is my first cut of tracefile:

http://www.cloudshark.org/captures/4b8cf621d044

It contains conversation from when I start application, and on row 717 there is first spanning tree .
I hope in your supporta

Thanks
Andrew

Jim Aragon <Jim <at> agdatasystems.com> ha scritto:

At 10:41 AM 7/14/2012, you wrote:

But I don't understand why this pause occurs always on this sequence:

716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 > microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00    STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port = 0x8003
718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP segment of a reassembled PDU]
719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79    HTTP/1.1 100 Continue

More than one second to receive another packet from the server (192.168.1.2) , I think this cannot be normal behaviour.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Alex Lindberg | 15 Jul 2012 02:59

Re: Spanning tree can slow the network?

Perhaps I missed it, but how are these packets captured? Port mirroring/spanning may have different packets than an inline probe or wireshark running on the host machine.

Also if wireshark is running on a Windows host there have been issues with packets containing 802.1q (vlan) data.

Alex Lindberg

Andrea <an.celli <at> tiscali.it> wrote:

Hello Jim, here is my first cut of tracefile:

http://www.cloudshark.org/captures/4b8cf621d044

It contains conversation from when I start application, and on row 717 there is first spanning tree .
I hope in your supporta

Thanks
Andrew

Jim Aragon <Jim <at> agdatasystems.com> ha scritto:

At 10:41 AM 7/14/2012, you wrote:

But I don't understand why this pause occurs always on this sequence:

716    8.713191000    192.168.1.12    192.168.1.2    TCP    54    50014 > microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
717    9.999665000    NexcomIn_1e:63:47    Spanning-tree-(for-bridges)_00    STP    60    Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port = 0x8003
718    10.689862000    192.168.1.12    192.168.1.2    TCP    362    [TCP segment of a reassembled PDU]
719    10.690663000    192.168.1.2    192.168.1.12    HTTP    79    HTTP/1.1 100 Continue

More than one second to receive another packet from the server (192.168.1.2) , I think this cannot be normal behaviour.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

headers

Patrick Preuss | 14 Jul 2012 19:34

Re: Spanning tree can slow the network?

Hi Andrea,

Spanning Tree is normal in switched networks, Bridges must send them.

A Problem can be recalculation and reordetring of the tree.

If you what to read more about this you can read "interconnections" from radia perlmann.

Hth

Cheers

Patrick

Am Samstag, 14. Juli 2012 schrieb Andrea :

Hello guys,
I've captured network traffic from some customer's LAN for monitor behaviour of slow applications, in all cases I've found spanning tree packets that slow the transactions, like this:

Spanning-tree-(for-bridge) STP Cost=4 port=0x8003

every time there is a spanning tree packet follow after a pause of time (about 1 sec.) before arrives other data packets, this behaviour I've seen either in LAN with many switches and in LAN when switch was only one.

How it is possible? I don't have configure spanning tree on switches. Can this be a normal behaviour ?

Thanks
Andrew
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users <at> wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe