| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
I have a major problem with a customer's network. The active gear consists of
15 900 hubs, each with at least 1 900EF and as much as 1 900EF and 3 PE 900's.
The 900EF's are connected to 900TM's in the backplane. Each of the 15 hubs is
connected to a SAS port (FGL 4) on a GIGAswitch. No loops between Ethernets
and/or FDDI's. Just a very simple flat network.
In trying to trace down NFS and TELNET timeouts, we have come across some
"leaking" packets. Below is a trace from a PACKETprobe connected to an unused
port on a 900EF. In theory you should only see multicast and broadcast packets
on a switch port that has a PACKETprobe as its only device, no other devices
including PC's.
There appears to be portions of conversations between systems that appear to be
only using unicast addressing but still coming thru the 900EF. Interestingly
it seems to be just the conversation in one direction, while the return packets
are being filtered. The traffic between 2 systems will leak for awhile, stop
and then a leak will start between 2 other systems, as shown below. I have
included both IP and MAC traces.
NETscout Protocol Decode Output
Packets from the file: H15S8.DAT
-----Decoding frame no: 1 ----
Frame ID Arrival Time Size Source Node Dest Node Status
-------------------------------------------------------------------------------
* 6 Feb 27 21:52:17.680 0064 142.104.98.102 142.104.98.126 DoD TCP
* 7 Feb 27 21:52:17.750 0064 142.104.98.102 142.104.98.126 DoD TCP
8 Feb 27 21:52:19.690 0064 142.104.98.84 142.104.98.60 DoD TCP
9 Feb 27 21:52:19.830 0260 142.104.123.65 224.0.1.2 DoD UDP
10 Feb 27 21:52:20.420 0064 142.104.98.83 142.104.98.74 DoD TCP
11 Feb 27 21:52:22.040 0178 142.104.109.84 142.104.109.83 SUNRPC
12 Feb 27 21:52:22.820 0260 142.104.123.65 224.0.1.2 DoD UDP
* 13 Feb 27 21:52:26.210 0064 142.104.116.4 142.104.120.148 DoD TCP
* 14 Feb 27 21:52:26.310 0064 142.104.116.4 142.104.120.148 DoD TCP
19 Feb 27 21:52:28.820 0260 142.104.123.65 224.0.1.2 DoD UDP
* 20 Feb 27 21:52:29.030 0064 142.104.113.160 142.104.113.162 DoD TCP
* 21 Feb 27 21:52:29.030 0064 142.104.113.160 142.104.113.162 DoD TCP
* 22 Feb 27 21:52:29.030 0070 142.104.113.160 142.104.113.162 DoD TCP
* 23 Feb 27 21:52:29.030 0106 142.104.113.160 142.104.113.162 DoD TCP
* 24 Feb 27 21:52:29.030 0064 142.104.113.160 142.104.113.162 DoD TCP
* 25 Feb 27 21:52:29.060 1082 142.104.113.160 142.104.113.162 DoD TCP
* 26 Feb 27 21:52:29.060 1082 142.104.113.160 142.104.113.162 DoD TCP
* 27 Feb 27 21:52:29.060 0114 142.104.113.160 142.104.113.162 DoD TCP
* 28 Feb 27 21:52:29.060 0214 142.104.113.160 142.104.113.162 DoD TCP
* 29 Feb 27 21:52:29.070 0082 142.104.113.160 142.104.113.162 DoD TCP
* 30 Feb 27 21:52:29.070 0070 142.104.113.160 142.104.113.162 DoD TCP
* 31 Feb 27 21:52:29.070 0064 142.104.113.160 142.104.113.162 DoD TCP
* 32 Feb 27 21:52:29.070 0064 142.104.113.160 142.104.113.162 DoD TCP
33 Feb 27 21:52:35.520 0064 129.105.109.1 142.104.104.36 DoD TCP
34 Feb 27 21:52:36.580 0064 142.104.116.4 142.104.120.172 DoD UDP
* 36 Feb 27 21:52:37.520 0070 142.104.98.100 142.104.123.67 DoD UDP
* 37 Feb 27 21:52:37.540 0106 142.104.98.100 142.104.123.67 DoD UDP
* 38 Feb 27 21:52:37.540 0070 142.104.98.100 142.104.123.67 DoD UDP
* 39 Feb 27 21:52:37.550 0142 142.104.98.100 142.104.123.67 DoD UDP
* 40 Feb 27 21:52:37.550 0098 142.104.98.100 142.104.123.67 DoD UDP
* 41 Feb 27 21:52:37.560 0078 142.104.98.100 142.104.123.67 DoD UDP
50 Feb 27 21:52:41.040 0064 142.104.100.103 142.104.102.11 DoD TCP
51 Feb 27 21:52:43.820 0259 142.104.123.65 224.0.1.2 DoD UDP
* 52 Feb 27 21:52:44.780 0064 142.104.98.85 142.104.98.129 DoD TCP
* 53 Feb 27 21:52:44.900 0064 142.104.98.85 142.104.98.129 DoD TCP
NETscout Protocol Decode Output
Packets from the file: H15S8.DAT
Frame ID Arrival Time Size Source Node Dest Node Status
-------------------------------------------------------------------------------
* 6 Feb 27 21:52:17.680 0064 Sun 75fea8 HP b2ed79 DoD TCP
* 7 Feb 27 21:52:17.750 0064 Sun 75fea8 HP b2ed79 DoD TCP
8 Feb 27 21:52:19.690 0064 Sun 1064f0 0000a710d437 DoD TCP
9 Feb 27 21:52:19.830 0260 SilicG08fda3 01005e000102 DoD UDP
10 Feb 27 21:52:20.420 0064 Sun 10652e 0000a710d33e DoD TCP
11 Feb 27 21:52:22.040 0178 Sun 7382f4 00400b40c98c SUNRPC
12 Feb 27 21:52:22.820 0260 SilicG08fda3 01005e000102 DoD UDP
* 13 Feb 27 21:52:26.210 0064 Sun 0377d8 0000a7105f4f DoD TCP
* 14 Feb 27 21:52:26.310 0064 Sun 0377d8 0000a7105f4f DoD TCP
19 Feb 27 21:52:28.820 0260 SilicG08fda3 01005e000102 DoD UDP
* 20 Feb 27 21:52:29.030 0064 Sun 2375ab 0000a700f299 DoD TCP
* 21 Feb 27 21:52:29.030 0064 Sun 2375ab 0000a700f299 DoD TCP
* 22 Feb 27 21:52:29.030 0070 Sun 2375ab 0000a700f299 DoD TCP
* 23 Feb 27 21:52:29.030 0106 Sun 2375ab 0000a700f299 DoD TCP
* 24 Feb 27 21:52:29.030 0064 Sun 2375ab 0000a700f299 DoD TCP
* 25 Feb 27 21:52:29.060 1082 Sun 2375ab 0000a700f299 DoD TCP
* 26 Feb 27 21:52:29.060 1082 Sun 2375ab 0000a700f299 DoD TCP
* 27 Feb 27 21:52:29.060 0114 Sun 2375ab 0000a700f299 DoD TCP
* 28 Feb 27 21:52:29.060 0214 Sun 2375ab 0000a700f299 DoD TCP
* 29 Feb 27 21:52:29.070 0082 Sun 2375ab 0000a700f299 DoD TCP
* 30 Feb 27 21:52:29.070 0070 Sun 2375ab 0000a700f299 DoD TCP
* 31 Feb 27 21:52:29.070 0064 Sun 2375ab 0000a700f299 DoD TCP
* 32 Feb 27 21:52:29.070 0064 Sun 2375ab 0000a700f299 DoD TCP
33 Feb 27 21:52:35.520 0064 ACC 210900 080007f74c9a DoD TCP
34 Feb 27 21:52:36.580 0064 Sun 0377d8 0000a711a126 DoD UDP
36 Feb 27 21:52:37.520 0070 0080f1005291 SilicG0633ab DoD UDP
37 Feb 27 21:52:37.540 0106 0080f1005291 SilicG0633ab DoD UDP
38 Feb 27 21:52:37.540 0070 0080f1005291 SilicG0633ab DoD UDP
39 Feb 27 21:52:37.550 0142 0080f1005291 SilicG0633ab DoD UDP
40 Feb 27 21:52:37.550 0098 0080f1005291 SilicG0633ab DoD UDP
41 Feb 27 21:52:37.560 0078 0080f1005291 SilicG0633ab DoD UDP
* 50 Feb 27 21:52:41.040 0064 Sun 0e11e5 0000a712f625 DoD TCP
* 51 Feb 27 21:52:43.820 0259 SilicG08fda3 01005e000102 DoD UDP
52 Feb 27 21:52:44.780 0064 Sun 75d3a3 HP b2edbc DoD TCP
53 Feb 27 21:52:44.900 0064 Sun 75d3a3 HP b2edbc DoD TCP
Below is a trace from a UNIX system on shared Ethernet. The station trapped
packets from several systems that were on diferent hubs on the other side
of the GIGAswitch. Again, only packets in one direction were leaking thru
the 900EF's and the GIGAswitch.
Anyone have any ideas why apparently unicast packets are leaking thru the
switches? If these packets aren't unicast then what are they?
I can understand a packet or maybe 2 getting thru until the switches learn
the address, espacially after aging out followed by an ARP. But 8 to 14 seems
like too many. If this happens with too many packets leaking it may be enough
to cause certain segments to saturate and cause timeouts. Afterall, they
have 80+ ENET segments and probably 300-400 systems at least SPARC 10 or better.
dave
09:42:24.761442 START
09:42:24.761442 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.769966 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.776695 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.782877 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.789458 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.795858 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.802930 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.809182 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.815918 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.822170 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.829335 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.835978 mayne.csc.661 > moresby.csc.834: udp 32
09:42:24.868988 mayne.csc.661 > moresby.csc.1053: udp 24
09:42:24.877664 mayne.csc.661 > moresby.csc.836: udp 40
09:42:24.913784 gulf.csc.nfs > moresby.csc.556dbacd: reply ok 128
09:42:24.916566 gulf.csc.nfs > moresby.csc.556dbace: reply ok 96
09:42:24.921579 gulf.csc.nfs > moresby.csc.556dbacf: reply ok 128
09:42:24.923956 gulf.csc.nfs > moresby.csc.556dbad0: reply ok 96
09:42:25.491782 gulf.csc.nfs > moresby.csc.556dbad1: reply ok 128
09:42:25.496417 gulf.csc.nfs > moresby.csc.556dbad2: reply ok 96
09:42:25.502632 gulf.csc.nfs > moresby.csc.556dbad3: reply ok 128
09:42:25.505362 gulf.csc.nfs > moresby.csc.556dbad4: reply ok 96
09:42:25.647620 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.653980 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.662154 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.671134 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.680906 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.690899 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.697693 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.703819 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.710502 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.716716 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.723399 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.729648 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.736543 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.742776 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.772690 mayne.csc.661 > moresby.csc.1053: udp 24
09:42:25.780100 mayne.csc.661 > moresby.csc.836: udp 40
09:42:25.811028 gulf.csc.nfs > moresby.csc.556dbad5: reply ok 128
09:42:25.814099 gulf.csc.nfs > moresby.csc.556dbad6: reply ok 96
09:42:25.818743 gulf.csc.nfs > moresby.csc.556dbad7: reply ok 128
09:42:25.820875 gulf.csc.nfs > moresby.csc.556dbad8: reply ok 96
09:42:25.967022 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.973309 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.980046 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.986641 mayne.csc.661 > moresby.csc.834: udp 32
09:42:25.993778 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.000087 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.006837 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.013044 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.019819 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.026367 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.033093 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.039356 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.046280 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.053913 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.082433 mayne.csc.661 > moresby.csc.1053: udp 24
09:42:26.089516 mayne.csc.661 > moresby.csc.836: udp 40
09:42:26.136740 gulf.csc.nfs > moresby.csc.556dbad9: reply ok 128
09:42:26.139358 gulf.csc.nfs > moresby.csc.556dbada: reply ok 96
09:42:26.144265 gulf.csc.nfs > moresby.csc.556dbadb: reply ok 128
09:42:26.148285 gulf.csc.nfs > moresby.csc.556dbadc: reply ok 96
09:42:26.275325 mayne.csc.661 > moresby.csc.834: udp 32
09:42:26.281571 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.565880 chatham.csc.nfs > moresby.csc.556dbb08: reply ok 28
09:42:28.590806 mayne.csc.661 > moresby.csc.1053: udp 24
09:42:28.599895 mayne.csc.661 > moresby.csc.836: udp 40
09:42:28.637416 gulf.csc.nfs > moresby.csc.556dbb09: reply ok 128
09:42:28.640230 gulf.csc.nfs > moresby.csc.556dbb0a: reply ok 96
09:42:28.651076 mayne.csc.661 > moresby.csc.2897: udp 108
09:42:28.657081 mayne.csc.661 > moresby.csc.2897: udp 96
09:42:28.660182 gulf.csc.nfs > moresby.csc.556dbb0b: reply ok 128
09:42:28.664671 gulf.csc.nfs > moresby.csc.556dbb0c: reply ok 96
09:42:28.805067 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.811312 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.818138 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.824340 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.831191 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.837539 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.845037 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.851289 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.858097 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.864293 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.870969 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.877088 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.883847 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.890083 mayne.csc.661 > moresby.csc.834: udp 32
09:42:28.918499 mayne.csc.661 > moresby.csc.1053: udp 24
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3314.1 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Thu Feb 29 1996 10:25 | 35 | |
It is normal to see a certain amount of unicast traffic being
flooded due to unknown destination addresses.
If you see a *lot* of unknown destination flooding, then it's worth
investigating.
Here are a couple of reasons for unknown DA flooding:
Most bridge/switch devices flood when their forwarding table fills
up.
Some protocols do not send frames in acknowledgement of received
frames. If they don't send out any other frames within the aging
interval, the address will get aged out.
There are two aging timers which are used in Digital products, the
normal aging timer and the short aging timer. The short aging timer is
used when the topology change flag is set. The normal aging timer is
two minutes and the short aging timer is 30 seconds (by default).
I have often found frames destined for non-existent addresses -
systems which once existed, but were shut down, removed, etc. You'd
expect this traffic to die out quickly, but you'd be surprised how
brain dead some systems are. You most often find these where people
have manually added an ARP entry...
...there is the remote chance that a DA can be corrupted by bad
hardware in such a way as to escape the CRC check, but this is
unlikely.
Most likely those systems are being aged out on the GIGAswitch/FDDI
system - have you checked the forwarding database to see what is going
on?
MDL
| |||||
| 3314.2 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Thu Feb 29 1996 10:28 | 5 | |
P.S. note for example that quiescent LAT servers stand a very good
chance of aging out during topology changes. I believe the default
service announcement time for LAT is on the order of 45 seconds, so
there's a reasonably good chance that they will age out during a topology
change if no other traffic is present.
| |||||