Посмотри ошибки на интерфейсах. На котором начинают появляться - на аксесном порту, в который втыкается комп, или на аплинке?

вот два аксесных интерфейса:
FastEthernet0/8 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001b.2b00.288a (bia 001b.2b00.288a)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7000 bits/sec, 11 packets/sec
5 minute output rate 115000 bits/sec, 22 packets/sec
171217599 packets input, 2613776584 bytes, 0 no buffer
Received 65594 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2543 multicast, 0 pause input
0 input packets with dribble condition detected
224923851 packets output, 1840045685 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

FastEthernet0/7 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001b.2b00.2889 (bia 001b.2b00.2889)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 3000 bits/sec, 4 packets/sec
146068851 packets input, 4145904852 bytes, 0 no buffer
Received 2319151 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2769 multicast, 0 pause input
0 input packets with dribble condition detected
316043728 packets output, 4133397441 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
а вот аплинк:
GigabitEthernet0/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 001b.2b00.2881 (bia 001b.2b00.2881)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 4201000 bits/sec, 2105 packets/sec
5 minute output rate 23000 bits/sec, 17 packets/sec
2611292156 packets input, 4246839128 bytes, 0 no buffer
Received 4284722102 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2765396539 multicast, 0 pause input
0 input packets with dribble condition detected
2037521710 packets output, 3376785348 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Получается, битых пакетов там нет. Неужто в сетевухе или кабеле дело?

на 2 компах сразу?может что-то еще?

А хз, тогда смотри на всей трассе до самого сенсора наличие ошибок по CRC, если считаешь, что свич у тебя не обращает внимание на несовпадение контрольной суммы пакета, а только сниффер вычисляет проблему, IME за компанию делает вид, что так и есть.

Вон на каждом аксессном порту у тебя, как минимум, одна ошибка есть, но не по CRC.
Попробуй опять законнектиться с сенсором и глянь, количество ошибок будет расти или нет.

На f0/7 какое то чумовое количество броадкастов. МНе чудится или их там в 2 раза больше вообще полученных пакетов?

А свич вообще живой? Там САМ не перегружен? Чего sh proc cpu his кажет?

Кстати, верно замечено. Там что, сетка /8?

IME установлен на Windows XP SP3

вывод команды show processes cpu history:

22222
6666666666666666666666666666666000006666655555555555555555
100
90
80
70
60
50
40
30
20 *****
10 **********************************************************
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5

CPU% per second (last 60 seconds)


2
0667676677676776776766667767766776677666767766676676676767
100
90
80
70
60
50
40
30
20 *
10 ##########################################################
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5

CPU% per minute (last 60 minutes)
* = maximum CPU% # = average CPU%


4
985
100
90
80
70
60
50 *
40 *
30 *
20 *
10 ###
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0

CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%

но его сегодня перезагружали.

сетка там /24

С загрузкой ничего интересного.

и всё же откуда берутся броадкасты?

ХР - честная? Или "с рынка"?

XP не честная

вот смотрю на wireshark. там очень много пакетов протокола hsrp на мультикастовый адрес 224.0.0.2. может как-то с этим связанно?

По поводу checksum.
По выводу весь трафик от хостовой машины на https IPSа.
На многих ОС есть такая функция, как checksum offloading,а именно:
когда пакет уходит из ядра ОС на asic сетевой карты, его chksum равен 0. Сетевая карта внутри своего asicа все нулевые поля сама заполняет. Это позволяет избавить ЦПУ от ненужных вычеслений. Wireshark dumpit трафик до того, как он попадает на asic ( для исходящих пакет ) - поэтому ругается на chksum. Проверить можно:
если во всех пакетах chksum нулевой - то у вас скорее всего именно по этому wireshark ругается

ну и если dumpit не на той же машине трафик, то проблем с chksum быть недолжно

нет, там не нулевая контрольная сумма почти везде:

почитав в инете увидел что 0 - рекомендация, но не MUST. Те могут и рандом значения вставлять.
Гарантированно можно проверить дампя транзитный трафик ( eg SPAN на свитче )

ты же писал:


откуда видно, бродкасты и мультикасты считаются по-разному. На аплинке, наверное, и видно пакеты HSRP, потому что мультикастов там море. А как-то VLAN'ами сетка структурирована?

Hando, там проблема как раз в приходящем со стороны сенсора ACK'е.

да вот нефакт.
Вывод Wireshark
source 10.21.26.148 ( слева адрес ) dest 10.17.8.142 с порта 15103 в сторону 443
мы видем syn от клиента. не видем syn/ack от ips. видем ack от клиента

те в той картинке вообще нет пакетов от IPS. Может там фильтр какой нить стоял.

посыпаю голову пеплом. Точно, не заметил.
Похоже, bibl2008 поставил фильтр по dst ip

Виновник торжества, дай полностью сессии в студию.

не знаю в чем на самом деле была проблема, но после переустановки винды все нормально работает.

а снифер все равно показывает много битых пакетов

решил я свою проблему с невозможностью добавить сенсор в IME...сниффинг показал, что траффик уходит через корпоративную проксю..каким образом IME находил его - уму непостижимо..во всяком случае наши спецы уверяли, что wpad тут ни при чем..обходное решение: добавление адреса сенсора в список разрешенных адресов на проксе..претензия к цысковским разработчикам высказана..офф.саппорт признал объективность доводов и пообщела в последующих версиях сделать в IME явные настройки работы через прокси..

Я о походах через проксю в этой теме уже писал:
viewtopic.php?p=1601#p1601
А если у тебя пришлось настраивать в браузере, то значит, Ява юзает настройки браузера.

мне настривать ничего не пришлось, поскольку мало того, что в браузере отключена прокся и ява работает direct connection, так еще и с пользовательской учётки снята соответствующая политика..может быть следовало поправить файлик wpad, но решили не трогать его, а тупо прописать сенсор на проксе..вопрос в том, откуда IME всасывал адрес прокси..локально в системе подхватить точно не мог..остается wpad..но тут опять же странно, как он работал с ним раньше..

Раньше - это до перехода на 7ю версию?

нет..это начиная именно с 7 версии..т.е. изначально семерка в существующей корпоративной сети прекрасно работала, а в один прекрасный момент нагнулась..