это дает tcpdump

Цитата

02:30:02.603089 219.153.10.188.3285 > 82.207.97.81.squid: S [tcp sum ok] 3476574701:3476574701(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 2, id 40383, len 48) 02:30:02.603096 219.153.10.188.3285 > 82.207.97.81.squid: S [tcp sum ok] 3476574701:3476574701(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [ttl 1] (id 40383, len 48) 02:30:02.603194 219.153.10.188.3916 > 82.207.97.86.squid: S [tcp sum ok] 3037512334:3037512334(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 4, id 40388, len 48) 02:30:02.603200 219.153.10.188.3916 > 82.207.97.86.squid: S [tcp sum ok] 3037512334:3037512334(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 3, id 40388, len 48) 02:30:02.603308 219.153.10.188.3928 > 82.207.97.87.squid: S [tcp sum ok] 1375162645:1375162645(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 4, id 40389, len 48) 02:30:02.603314 219.153.10.188.3928 > 82.207.97.87.squid: S [tcp sum ok] 1375162645:1375162645(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 3, id 40389, len 48)

еще дает вот такое

Цитата

02:36:02.861573 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:04.482941 snap 0:0:c:20:4 0:e:84:ae:b6:d6 > 1:0:c:cc:cc:cc snap ui/C len=35 02:36:04.869499 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:06.877416 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:08.885373 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:10.893261 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15

подскажите что это такое, и как с ним бороться, ведь провайдером я так понимаю оно считаеться

Сквид поднят 7

нет, не поднят

Первое- это китайцы тебя сканируют. (Задолбали уже, в том году какой-то идиот искал серваки с открытым доступом на рута).
Второе - это вот. Иными словами хрень всяческая из сетки провайдера.
Как пров трафик считает? На Layer2 или на Layer3?

Step

Файрвольчиком обрезать все лишнее

TwiSteR, проблема не в том, проблема в том что этот трафик считаеться провайдерам а это 2 гб за месяц
Добавлено @ 10:38

Цитата(DENNN @ 11.7.2005, 08:52)

Как пров трафик считает? На Layer2 или на Layer3?

DENNN, я ж всетаки больше програмист, я эту фигню первый раз вижу... вообще не понимаю что к чему
Добавлено @ 10:39
не, китайцев конечно я тоже отследил, уроды на все системные логины пытались подобрать пароль пока я их сканить не стал, после этого попустило

Цитата(Step @ 11.7.2005, 10:37)

я эту фигню первый раз вижу... вообще не понимаю что к чему

Спроси у прова, как он считает трафик и чем - это вполне законный вопрос. Конкретнее интересует считает ли он байты, образуемые ip пакетами, или же он считает все что идет на канальном уровне. Если ip, то за все сканы, спам и прочее тебе придется платить (что естественно). Если он считает на канальном (на втором уровне) все что валиться к тебе на интерфейс, то вот эта хрень:

Цитата

02:36:02.861573 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:04.482941 snap 0:0:c:20:4 0:e:84:ae:b6:d6 > 1:0:c:cc:cc:cc snap ui/C len=35 02:36:04.869499 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:06.877416 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:08.885373 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15 02:36:10.893261 802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15

будет также посчитанна за трафик. Читай договор с провайдером. Если укзанно, что внутрисетевые ресурсы не тарифицируются, либо, утрируя, что оплата идет только за тот трафик, который пришел с интерента, то в этом случае вся эта служебная хрень должна быть исключена из расчета. Как - пусть об этом болит голова у прова. Ему придется либо считать иначе, либо оградить тебя от работы всяческих сетевых устройств по протоколам типа SPanningTree, широковещательных запросов (они к тебе тоже приходят или нет?) и т.п. Как он это сделает - его проблемы (хотя возможно там такой зоопарк, что они просто "забъют").
Добавлено @ 11:07
В догонку. Каков процент "лишнего" трафика от общего объема за месяц?

Это сообщение отредактировал(а) DENNN - 11.7.2005, 11:06

прошлый месяц
1.3Г полезный 14Гб левый

в этом месяце 25 % левого
Добавлено @ 14:07

Цитата(DENNN @ 11.7.2005, 11:05)

02:36:04.482941 snap 0:0:c:20:4 0:e:84:ae:b6:d6 > 1:0:c:cc:cc:cc snap ui/C len=35

а это че за хрень

Цитата(Step @ 11.7.2005, 14:05)

02:36:04.482941 snap 0:0:c:20:4 0:e:84:ae:b6:d6 > 1:0:c:cc:cc:cc snap ui/C len=35 а это че за хрень

Честно говоря не знаю нужно смотреть, но думаю, что дело большей частью не в ней.

Цитата(Step @ 11.7.2005, 14:05)

прошлый месяц 1.3Г полезный 14Гб левый

Очень похоже что считаются вот те самые ethernet-пакеты, которые твой tcpdump расшифровал как

Цитата

802.1d config 800b.00:0e:84:ae:b6:c0.8016 root 800b.00:0e:84:ae:b6:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15

Они могут идти только из общего сегмента между тобой и провайдером (если ты конечо с этого интерфейса статистику снимал, а не ошибся ). Если все эти предположения верны, то выходит, что твой пров считает на Layer2, например просто снимает статистику через SNMP со своего интерфейса. Прикинь, как часто они приходят к тебе на интерфейс, посчитай, сколько это в месяц - должна грубо получиться та самая цифра. Если нет - нужно копать дальше.
Приведи, пожалуйста, схему как ты подключен к прову. Подробно, какая сетевушка у тебя, если оптика, то какие конвертеры на обоих концах, что у прова в твою сторону трафик выдает и в каком месте этой топологии он считает трафик. Какая маска сети? есть ли в этом же сегменте другие потребители трафика? Проверь, также, попадают ли к тебе на внешний интерфейс широковещательные пакеты или arp запросы других хостов.
Короче расскажи как же ты трафик интернетовский потребляешь.

то что знаю


пров -> витая -> комутатор-> витая-> медиа конвертор-> оптика->медиокнвертор-> витая->сетевуха планет, с нее и снимаю

195,5,50,58 карта
195,5,50,57 шлюз
маска 30 бит

комутатор? какие функции выполняет? М.б. ты хотел сказать свитч или хаб?

свитч, просто нужен что бы дойти до медиоконвертора

стоит длинк

Тогда нужно разбираться с провайдером у кого что в действительности считается, только предварительно все еще раз проверить: вынуть из сетевух все кабеля и запустить tcpdump, посмотреть есть ли трафик особенно ethernet и др. не IP протоколы), затем вотнуть кабель прова и опять смотреть что за трафик пошел. Если после этого опять будет все нормально, то воткнуть кабель своей сетки - если видишь что вот "понеслось", то ищи проблемы у себя (50/50 либо в твоей сетке что-то, либо ты на свое водоплавающее животное "докучи" что-то не то наставил).
Какие сетевые службы у тебя запущенны?
Добавлено @ 09:19
Тут в голову пришло: если связь плохая или свитч глюкает, то железо прова потерянные пакеты будет пересылать еще раз. В итоге со стороны прова к тебе ушедших пакетов будет больше, чем с твоей стороны пришедших.

DENNN, обижаешь.... все сделал все отключал, как только прова подключаю так и п. наступает... из моей сетки этого нету однозначно...

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

ok.
Договор c провом есть или только устные договренности?
Короче, тряси прова - пусть это будет и его проблемой тоже. Дальше тебе на месте виднее