Уважаемые All /// Помогите разобраться с проблемой
дело в том что я что то не понимаю что происходит с трафиком а точнее
имеются различия с чтением трафика логом Squida и чтения трафика провайдером .... и разность наблюдается почти в 2 раза ..Вчера по логу прошло 102 Мб а провайдер говорит 214 .... из за чего такое может быть
Может что я не так настроил ? Спасибо заранее
Те же самые грабли.
На сервере стоит Squid. Анализирую логи Squida - пользователей внутренней сети и логи внешнего интерфейса созданные Iptraf. По Iptraf результат получается ВСЕГДА больше того который по логам squid взят с оригинального источника ( не из кэша ).Кто-нибудь кто разбирался, может дать совет - почему и где искать?
>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранееcквид http и ftp прокси, Все остальные протоколы через него не идут, в частности почта SMTP и всё остальное , а почта приличный трафик дает, особенно подписки на subscribe.ru и другие аналогичные сайты
>cквид http и ftp прокси, Все остальные протоколы через него не идут,
>в частности почта SMTP и всё остальное , а почта приличный
>трафик дает, особенно подписки на subscribe.ru и другие аналогичные сайты
... и DNS и даже подтверждение доставки IP пакета при передаче запроса удаленному черверу.
>>cквид http и ftp прокси, Все остальные протоколы через него не идут,
>>в частности почта SMTP и всё остальное , а почта приличный
>>трафик дает, особенно подписки на subscribe.ru и другие аналогичные сайты
>... и DNS и даже подтверждение доставки IP пакета при передаче запроса
>удаленному черверу.Извините, что немного запоздал к обсуждению :) Просто у меня точно такая же трабла! Тпафик - только HTTP, а превышения статистики провайдера перед статистикой моего сквида - в два раза! Сомневаюсь, чтобы DNS и прочее увеличивали траф вдвое...
Скорее всего, проблема в том, что SQUID учитывает размер полученных файлов, а провайдер - объем пакетов, из которых собираются файлы. В пакетах есть служебные поля и пакеты могут повторяться. Если провайдер учитывает исходящий и входящий траффик, то превышение на 20-30 процентов при хорошем канале неизбежно. Траффик могут поднять UDP и ARP пакеты и даже PING. DNS дает очень незначительное увеличение траффика. Траффик может поднять ICQ, mirc и просто отключение юзером прокси нв настройках броузера. Честность провайдера можно проверить ifconfig, но обычно они не идут на явный обман.
Доброе время суток.Можно я присоединюсь со своей проблемой? У меня не стоит сквид, по логам которого я мог бы считать трафик. Работает iptables+ipac-ng. Насколько мне известно, ипак считает пакеты все, по которым у него прописаны настройки. Но вот, что интересно - всё равно теряется несколько мегабайт. То есть, если у меня на роутере ипак показывает, что в выходные почтовый сервер сделал трафика в сумме всего-то на 20 мег, а у прова все 25-30.
Почему такое может быть? Ведь мимо iptables мышь не проскочит.wbr, Angel Keeper. http://www.triza.ru
>Можно я присоединюсь со своей проблемой? У меня не стоит сквид, по
>логам которого я мог бы считать трафик. Работает iptables+ipac-ng. Насколько мне
>известно, ипак считает пакеты все, по которым у него прописаны настройки.
>Но вот, что интересно - всё равно теряется несколько мегабайт. То
>есть, если у меня на роутере ипак показывает, что в выходные
>почтовый сервер сделал трафика в сумме всего-то на 20 мег, а
>у прова все 25-30.
>Почему такое может быть? Ведь мимо iptables мышь не проскочит.Я вот тоже внесу свои пять копеек.
Просто стало интересно. Нужно проконтроллировать что там у вас творится на выходных интерфейсах смотрящих на ваших пров_ов.
Включите мониторинг и логгинг на цисках, запустите tcpdum на выходных интерфесах, предварительно отключив маршрутизато от вашей сети и/или остановите все сервисы - увидите много интересного.У меня значит маршрутизатор на фришке, ether. интерфейс смотрящий в инет, подключается к POP прова через модемы-бриджи также с ether. интерфесами, далее в Catalist прова. На этом свитче прова также сидят другие клиенты с бриджами. Шоб мы клиенты не контачили друг-с другом так сказать локально на свитче, на последнем подняты VLAN, 802.1d, для всех клиентов этого свитча, затем транкинг 802.1Q, оттуда с транк порта свитча на маршрутизацию и в инет. Так вот !!! Останавливаю все !!! сервисы на моем фришке-маршрутизаторе, которые могут создать трафик, запускаю tcpdump -i MyOutIf и вижу:
00:36:32.213157 802.1Q vlan#1 P7 1:0:c:cc:cc:cc > 0:b:46:f0:c8:c1 sap aa ui/C
>>> Unknown IPX Data: (35 bytes)
[000] xx xx xx xx xx xx xx xx xx xx xx xx xx xx ..myprov.domain....
[010] 05 03 00 03 00 05 A5 00 04 00 0A 00 0B 46 F0 C8 ........ .....F..
[020] C1 00 00 ...
len=35
000f 617a 6461 7461 2e6e 6574 0000 0200
0503 0003 0005 a500 0400 0a00 0b46 f0c8
c100 00
00:36:32.213971 802.1Q vlan#1 P7 1:0:c:0:0:0 > 0:b:46:f0:c8:c1 sap aa ui/C
>>> Unknown IPX Data: (65 bytes)
[000] 00 01 00 0C CC CC CC 00 0B 46 F0 C8 C1 00 2C AA ........ .F....,.
[010] xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx myprov.domain
[020] 74 61 2E 6E 65 74 00 00 02 00 05 03 00 03 00 05 .. ........
[030] A5 00 04 00 0A 00 0B 46 F0 C8 C1 00 00 08 05 FA .......F ........
[040] 96 .
len=65
0001 000c cccc cc00 0b46 f0c8 c100 2caa
aa03 0000 0c20 0401 0001 000f 617a 6461
7461 2e6e 6574 0000 0200 0503 0003 0005
a500 0400 0a00 0b46 f0c8 c100 0008 05fa
96
00:36:32.286579 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:34.294588 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:36.302562 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:38.310555 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:40.318541 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:42.326540 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:44.334510 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:46.342528 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:48.350545 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:50.358474 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:52.366478 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:54.374455 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:56.382448 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:36:58.390436 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:37:00.398417 802.1d config 800a.00:0b:46:f0:c8:c0.8001 root 800a.00:0b:46:f0:c8:c0 pathcost 0 age 0 max 20 hello 2 fdelay 15
00:37:02.223866
CDP v2, ttl=180s
DevID 'catalyst9'
Addr (1): IPv4 10.111.111.10
PortID 'FastEthernet0/1'
CAP 0x28
[!cdp]
И так далее - по кругу.
Для подсчета трафика использую ipa, вышеуказанная ботва накручивает мне
45 килобайт за 5 минут.
Вот.
Если ваш юзер качал файло скажем в 100 метров, а на 40 метрах скачки передумал, то в логах сквида вы этого не увидите, а провайдер накинет вам эти 40 метров
>Если ваш юзер качал файло скажем в 100 метров, а на 40
>метрах скачки передумал, то в логах сквида вы этого не увидите,
>а провайдер накинет вам эти 40 метров
Увидит (40 метров )
>Я вот тоже внесу свои пять копеек.
>Просто стало интересно. Нужно проконтроллировать что там у вас творится на выходных
>интерфейсах смотрящих на ваших пров_ов.
>Включите мониторинг и логгинг на цисках, запустите tcpdum на выходных интерфесах, предварительно
>отключив маршрутизато от вашей сети и/или остановите все сервисы - увидите
>много интересного.
>
>У меня значит маршрутизатор на фришке, ether. интерфейс смотрящий в инет, подключается
>к POP прова через модемы-бриджи также с ether. интерфесами, далее в
>Catalist прова. На этом свитче прова также сидят другие клиенты
>с бриджами. Шоб мы клиенты не контачили друг-с другом так сказать
>локально на свитче, на последнем подняты VLAN, 802.1d, для всех клиентов
>этого свитча, затем транкинг 802.1Q, оттуда с транк порта свитча на
>маршрутизацию и в инет. Так вот !!! Останавливаю все !!! сервисы
>на моем фришке-маршрутизаторе, которые могут создать трафик, запускаю tcpdump -i MyOutIf
>и вижу:
>00:36:32.213157 802.1Q vlan#1 P7 1:0:c:cc:cc:cc > 0:b:46:f0:c8:c1 sap aa ui/C[skip]
>И так далее - по кругу.
>Для подсчета трафика использую ipa, вышеуказанная ботва накручивает мне
>45 килобайт за 5 минут.
>Вот.Попроси его на вашем порту зарубить CDP, autonegotiate trunk, keepalive,
пакеты spanning-tree.Это будет так:
interface FastEthernet0/9
description Client
switchport access vlan 10
switchport mode access
no keepalive
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enableИ все будет пучком ;-)
Доброе время суток всем.
Мне повезло больше, чем автору вопроса.
Проблема прямо противоположная. У меня логи сквида говорят, что за январь мы выкачали 4ГБ, а провайдер говорит - 2,8ГБ.
Это, конечно, приятно, но начальство хочет контролировать эти цифры в течении месяца.
Может кто-нибудь прояснит в чем дело?У меня FreeBSD 4.4, Squid 2.4.Stable7, анализирую SARG'ом 1.2.2.1
>Доброе время суток всем.
>Мне повезло больше, чем автору вопроса.
>Проблема прямо противоположная. У меня логи сквида говорят, что за январь мы
>выкачали 4ГБ, а провайдер говорит - 2,8ГБ.
>Это, конечно, приятно, но начальство хочет контролировать эти цифры в течении месяца.
>
>Может кто-нибудь прояснит в чем дело?
>
>У меня FreeBSD 4.4, Squid 2.4.Stable7, анализирую SARG'ом 1.2.2.1А кэш у сквида большой? САРГ, если не обшибся, смотрит access.log, в который пишется инфа, которую клиент получил от сквида(!), а не то, что реально стянуто с нета.
Друг, работая у провайдера, говорил: у них в, свою очередь, тоже проксится весь канал, что дает выигрыш порой до 50%, а вот этот выигрыш уже благополучно сжирают халявные почтовые ящики диалапщиков, которые лежат у провайдера и входят в пакет услуг :))
>>Доброе время суток всем.
>>Мне повезло больше, чем автору вопроса.
>>Проблема прямо противоположная. У меня логи сквида говорят, что за январь мы
>>выкачали 4ГБ, а провайдер говорит - 2,8ГБ.
>>Это, конечно, приятно, но начальство хочет контролировать эти цифры в течении месяца.
>>
>>Может кто-нибудь прояснит в чем дело?
>>
>>У меня FreeBSD 4.4, Squid 2.4.Stable7, анализирую SARG'ом 1.2.2.1
>
>А кэш у сквида большой? САРГ, если не обшибся, смотрит access.log, в
>который пишется инфа, которую клиент получил от сквида(!), а не то,
>что реально стянуто с нета.
>
>Друг, работая у провайдера, говорил: у них в, свою очередь, тоже проксится
>весь канал, что дает выигрыш порой до 50%, а вот этот
>выигрыш уже благополучно сжирают халявные почтовые ящики диалапщиков, которые лежат у
>провайдера и входят в пакет услуг :))Спасибо, про кэш я не подумал, не дошел пока до того уровня.
Позвольте внести свою лепту в интересную дисскуссию.Меня всегда удивляло, как народ считает трафик iptables и ему подобными инструментами (а еще хуже - Squid!)
А как же коллизии, множественные перезапросы, ошибки выравнивания и CRC и т.п. Плюс заголовки фрагментированных пакетов. Процентов 30 - 50 реального трафика до уровня IP просто не доходит. О каком ICMP или DNS может идти речь? Провайдер считает трафик на физическом уровне, пакеты на интерфейсе маршрутизатора!
>Ведь мимо iptables мышь не проскочит.
Только до iptables нужно еще добраться.
>Позвольте внести свою лепту в интересную дисскуссию.
>
>Меня всегда удивляло, как народ считает трафик iptables и ему подобными инструментами
>(а еще хуже - Squid!)
>
>А как же коллизии, множественные перезапросы, ошибки выравнивания и CRC и т.п.
>Плюс заголовки фрагментированных пакетов. Процентов 30 - 50 реального трафика до
>уровня IP просто не доходит. О каком ICMP или DNS
>может идти речь? Провайдер считает трафик на физическом уровне, пакеты на
>интерфейсе маршрутизатора!
>
>>Ведь мимо iptables мышь не проскочит.
>Только до iptables нужно еще добраться.Тогда вопрос, как на компе считать на физическом уровне?
имхо-ты считаешь ip, а он(пров) - пакеты на интерфейс.
>имхо-ты считаешь ip, а он(пров) - пакеты на интерфейс.Добрый день.
Это был ответ на мой вопрос? В принципе возможно... я как-то не догадался попробовать сделать snat на интерфейс, а не на ip. Спасибо, за толчок на мысль.
wbr, Angel Keeper. http://www.triza.ru
>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранееУ меня беда токого же плана :Строится МРТГ по порту свича - по статистики сквид говорит эфективность ~10% а по МРТГ 2-3 а то и вообще в минус. DNS трафик я пустил по другому интерфейсу и , короче кроме http & ftp ничего не летает .Долго я енто наблюдал и потом выяснилось что какие-то козла стваят большие файлы на докачку.Например лежит файл(пример из жизни) 120Мб докачка прервалась на 40Мб он начинает докачивать но сквид начинеет его по новой тянуть так вот я обнаружил что ентот файл пытались стянуть порядка 300 раз и практически всегда где-то на 40 метрах енто обрывалось считаем 300*(120-40)получаем порядка 24 Гб трафика . Слава яйцам что на трафик посрать но картинку МРТГ подпортили и я еще замечаю что у меня входящий трафик на проксю больше исходящего именно по ночам т.е. явно ставят на докачку.КТО ЗНАЕТ КАК С ЕНТОМИ ДОКАЧИВАЛКАМИ БОРОТСЯ?
У меня беда токого же плана :Строится МРТГ по порту свича - по статистики сквид говорит эфективность ~10% а по МРТГ 2-3 а то и вообще в минус. DNS трафик я пустил по другому интерфейсу и , короче кроме http & ftp ничего не летает .Долго я енто наблюдал и потом выяснилось что какие-то козла стваят большие файлы на докачку.Например лежит файл(пример из жизни) 120Мб докачка прервалась на 40Мб он начинает докачивать но сквид начинеет его по новой тянуть так вот я обнаружил что ентот файл пытались стянуть порядка 300 раз и практически всегда где-то на 40 метрах енто обрывалось считаем 300*(120-40)получаем порядка 24 Гб трафика . Слава яйцам что на трафик посрать но картинку МРТГ подпортили и я еще замечаю что у меня входящий трафик на проксю больше исходящего именно по ночам т.е. явно ставят на докачку.КТО ЗНАЕТ КАК С ЕНТОМИ ДОКАЧИВАЛКАМИ БОРОТСЯ?>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранее
Дело не обязательно будет в squid'е.Любой пакет пришедший к вам на интерфейс и отброшенный вашим firewall не будет учтен у вас, но будет учтен у вашего провайдера, т.к. реально он загружает канал.
Если юный хакер решил послать вагон пакетиков на 22-й порт, а у вас он загрыт, то ...
+ то, что было указано выше: сквид указывает размер пришедших данных не включая заголовки пакетов. Не только TCP/IP, но HTTP.
Т.е. различия будут всегда.
Добрый день.Сюда же можно смело приплюсовать потерянный трафик, плюс пересылки пакетов повторно и т.д. У нас, например, радиоканал, так трафик фактический и реальный расходятся процентов на 20.
wbr, Angel Keeper. http://www.triza.ru
>Добрый день.
>
>Сюда же можно смело приплюсовать потерянный трафик, плюс пересылки пакетов повторно и
>т.д. У нас, например, радиоканал, так трафик фактический и реальный расходятся
>процентов на 20.
>
>wbr, Angel Keeper. http://www.triza.ruДавайте тогда еще про инкапсуляцию и капсуляцию IP в ethernet & ATM !!!
Я знаю что никаких дроповых пакетов у меня нет и по статистики фильтра я вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю вопрос КАК БОРОТСЯ С ДОКАЧИЛОВКАМИ
>фильтра я вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю
>вопрос КАК БОРОТСЯ С ДОКАЧИЛОВКАМИможно попробовать через acl ... browser ...
т.е. дать доступ только разрешенным браузерам,
но в многих докачивалках эта строка настраивается, так что это поможет только от совсем запущенных юзверей
>фильтра я вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю
>вопрос КАК БОРОТСЯ С ДОКАЧИЛОВКАМИустановить "рабочее время" прокси, например с 19 ч. она не обслуживает клиентов, вариаций много.
полезна еще фишка DELAY POOLS
>>Добрый день.
>>
>>Сюда же можно смело приплюсовать потерянный трафик, плюс пересылки пакетов повторно и
>>т.д. У нас, например, радиоканал, так трафик фактический и реальный расходятся
>>процентов на 20.
>>
>>wbr, Angel Keeper. http://www.triza.ru
>
>Давайте тогда еще про инкапсуляцию и капсуляцию IP в ethernet & ATM
>!!!А зачем? просто можно использовать прогу, к-я может и на IP уровне работать, и на физическом (по выбору). NeTraMet, к примеру.
>Я знаю что никаких дроповых пакетов у меня нет и по статистики
>фильтра я вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю
>вопрос КАК БОРОТСЯ С ДОКАЧИЛОВКАМИИМХО никак. Либо ставить докачку сквиду при разрыве со стороны клиента, либо просто резать такие докачки via delay pools (ну это ради траффика; начисто отбивает охоту качать что-нить бааааааааааааааааальшое, разве что по-необходимости)
>>Я знаю что никаких дроповых пакетов у меня нет и по статистики
>>фильтра я вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю
>>вопрос КАК БОРОТСЯ С ДОКАЧИЛОВКАМИ
>
>ИМХО никак. Либо ставить докачку сквиду при разрыве со стороны клиента, либо
>просто резать такие докачки via delay pools (ну это ради траффика;
>начисто отбивает охоту качать что-нить бааааааааааааааааальшое, разве что по-необходимости)Докачка -- это фича сквида. То есть если клиент послал запрос, сквид начал принимать для него данные, а затем клиенту надоело ждать и он закрыл браузер, -- то сквид может попытаться докачать файл и положить его в кэш. По умолчанию он делает это, если файл скачан уже на 95%.
РЕГУЛИРУЕТСЯ это опциями quick_abort_xxx (их 3 штуки).Чтобы клиент не ждал слишком долго, можно заставить сквид начинать передавать полученные данные еще до того, как завершится докачка. Это, если не ошибаюсь -- range_offset_limit.
D любом случае, даже если докачку отключить, то, что было скачано, но не отдано клиенту -- непроизводительные потери.
PS Только что стукнуло: если поставить отдачу клиентучерез полкилобайта полученного, то практически все будет фиксироваться в логах. Но я этого не проверял.
>Чтобы клиент не ждал слишком долго, можно заставить сквид начинать передавать полученные
>данные еще до того, как завершится докачка. Это, если не ошибаюсь
>-- range_offset_limit.Нет, это не тот параметр. По-моему, сувид всегда сначала закачивает, а потом отдает. Если кто знает, как это изменить (только точно знает :)) - сообщите, буду крайне признателен :)
>
>D любом случае, даже если докачку отключить, то, что было скачано, но
>не отдано клиенту -- непроизводительные потери.
>а как тогда такое может быть? - сложно представить...
>PS Только что стукнуло: если поставить отдачу клиентучерез полкилобайта полученного, то практически
>все будет фиксироваться в логах. Но я этого не проверял.А почему именно полкила? не 100? не 1? не 0, наконец? и, опять таки - КАК поставить....
>
>>Чтобы клиент не ждал слишком долго, можно заставить сквид начинать передавать полученные
>>данные еще до того, как завершится докачка. Это, если не ошибаюсь
>>-- range_offset_limit.
>
>Нет, это не тот параметр. По-моему, сувид всегда сначала закачивает, а потом
>отдает.
Да, что-то я лажанулся.
>Любой пакет пришедший к вам на интерфейс и отброшенный вашим firewall не
>будет учтен у вас, но будет учтен у вашего провайдера, т.к.
>реально он загружает канал.Ок, с этим согласен. Тогда скажите, чем же считать трафик, чтоб моя статистика совпадала со статистикой провайдера? Насколько объективна инфа, выдаваемая файрволлом(#ipfw show)?
Считаю трафик с помощью ipfw counters,cisco cache-flow и cisco
ip-accounting(одновременно). На объемах ~50-70Gb расхождение 0.7-0.8%
Так что - или вы или провайдер считают неправильно.Считать по логу
squid-это летать по пачке беломора...Должна быть точка раздела
ответственности и считать надо в этой точке. Кстати-если у вас есть статический роут на провайдера, то при пропадании канала начинается пинг-понг, один пакет может посчитаться до TTL раз...
> знаю что никаких дроповых пакетов у меня нет и по статистики фильтра я >вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю вопрос КАК >БОРОТСЯ С ДОКАЧИЛОВКАМИОграничь размер кэшируемых файлов в Squid.
Тоже самое наблюдаю на выделенки у провайдера вставленной в свич. На фрю валится огромная помойка с соседей.
>> знаю что никаких дроповых пакетов у меня нет и по статистики фильтра я >вижу что никакие хакеры не долбятся мне в фильтр!!!Повторяю вопрос КАК >БОРОТСЯ С ДОКАЧИЛОВКАМИ
>
>Ограничь размер кэшируемых файлов в Squid.
>Тоже самое наблюдаю на выделенки у провайдера вставленной в свич. На фрю
>валится огромная помойка с соседей.Видимо, это новый стандарт (?) разводки клиентов :)
Я полмесяца с провом разбирался, почему на роутер валятся левые пакеты, причем настолько левые, что даже по страшно подумать.... - как может пакет с dstip, скажем, 82.14.х.х прийти на карточку с адресом 213.х.х.х ????
Самое интересное, что когда в течение пары дней пособоирали ВСЕ падающие пакеты и посумировали, то ровно наш траффик и вышел (а так было превышение в два раза). Долго ходили с этим к прову, откуда жестко посылали ("у нас все циски считают, они никогда не ошибаются"), однако вскоре пакетов поубавилось :)))))
>
>>Любой пакет пришедший к вам на интерфейс и отброшенный вашим firewall не
>>будет учтен у вас, но будет учтен у вашего провайдера, т.к.
>>реально он загружает канал.
>
>Ок, с этим согласен. Тогда скажите, чем же считать трафик, чтоб моя
>статистика совпадала со статистикой провайдера? Насколько объективна инфа, выдаваемая файрволлом(#ipfw show)?
>Я считаю Netramet'ом. Расхождение с провом (он с цисок берет) - 3-5%.
Через accounting замороченно больно, плюс описанные потери (хотя они должны учитываться в deny. Но, скажем, на компе с двумя карточками deny all from any to any не шибко информативна :)))
>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранееУ меня таже проблема... Правда у меня не Squid, а iptables+ipcad+UTM. Расхождение с провайдером идет и иногда доходит до 50-70%. Пытался разбираться с ними, так они понесли лабуду по поводу настроек моей цыски. Якобы у меня на цыске запрещены некоторые протоколы, порты и адреса внутренней сети, а у провайдера все пакеты для этих объектов считаются. Вот блин и здрасьте. Пытаешься защитить сеть, а оказывается нарываешься на неприятности! Начальство спрашивает с меня за якобы сворованный трафик! Блин!
И еще такую фишку наблюдаю постоянно. У некоторых клиентов трафик посчитанный через провайдера больше, чем у меня на биллинге. А у некоторых наоборот, меньше. А в сумме получается тютелька в тютелку. Биллинг не врет, заперепроверялся уже! Похоже опять провайдер?
И еще, одна штучка-дрючка-заморочка у провайдеров есть. Сам свидетель. Если вы являетесь мелким провайдером, всех клиентов цепляйте на фиктивные адреса и во внешний мир пускайте только через трансляцию!!! Ваш провайдер может по реальному апи-адресу вычислить жирного клиента и будет тормозить прохождение пакетов этого клиента. И когда после очередного скандала с вами из-за низкой скорости к клиенту прийдет представитель вашего провайдера и навешает ему лапши на уши, клиент отдастся с потрохами!!! Это реально!!!
>>Уважаемые All /// Помогите разобраться с проблемой
>>дело в том что я что то не понимаю что происходит с
>>трафиком а точнее
>>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>>102 Мб а провайдер говорит 214 .... из за чего такое
>>может быть
>>Может что я не так настроил ? Спасибо заранее
>
>У меня таже проблема... Правда у меня не Squid, а iptables+ipcad+UTM. Расхождение
>с провайдером идет и иногда доходит до 50-70%. Пытался разбираться с
>ними, так они понесли лабуду по поводу настроек моей цыски. Якобы
>у меня на цыске запрещены некоторые протоколы, порты и адреса внутренней
>сети, а у провайдера все пакеты для этих объектов считаются. Вот
>блин и здрасьте. Пытаешься защитить сеть, а оказывается нарываешься на неприятности!
>Начальство спрашивает с меня за якобы сворованный трафик! Блин!Для большинства провов это - нормальное поведение (к моему большому сожалению).
Лично я так ушел от одних людей (где сетку обслуживал) в другое место - задолбался объяснять саму возможность разночтений. Руководство почему-то больше верило прову и считало его непрегрешиом-неприкасаемым (смешно и грустно).
>И еще такую фишку наблюдаю постоянно. У некоторых клиентов трафик посчитанный через
>провайдера больше, чем у меня на биллинге. А у некоторых наоборот,
>меньше. А в сумме получается тютелька в тютелку. Биллинг не врет,
>заперепроверялся уже! Похоже опять провайдер?1. Как считаешь траффик?
2. Клиенты за НАТом или с реальными адресами?
3. Может всякое дермо в подсетку сыпаться (причин масса - глючный роутинг пакетов у прова, спам пакетов в сетку/атака, кривые настройки компа(ов) клиентов).
4. Пров может глючит/нае..вать, перетасовывая данные. Сам столкнулся; скачивал, положим, 10 Метроа, отрубая ВСЕХ на время ротации логов прова. А потом смотрел те логи... получалось, я скаал примерно 3, а остальные 8 (!!!!) раскидывались по выделеной мне подсетке. Вот тут вам и накрутка, и компроментация чужого биллинга, и все чисто (поди докажи, что эти клиенты не работали в этот интервал времени).
>И еще, одна штучка-дрючка-заморочка у провайдеров есть. Сам свидетель. Если вы являетесь
>мелким провайдером, всех клиентов цепляйте на фиктивные адреса и во внешний
>мир пускайте только через трансляцию!!! Ваш провайдер может по реальному апи-адресу
>вычислить жирного клиента и будет тормозить прохождение пакетов этого клиента. И
>когда после очередного скандала с вами из-за низкой скорости к клиенту
>прийдет представитель вашего провайдера и навешает ему лапши на уши, клиент
>отдастся с потрохами!!! Это реально!!!Абсолютно реально.
Предположим я ваш вышестоящий,лежащий/другое провайдер. Мне идет на вашу
сеть хрень.брень.тут.там/28 инет трафик,как полезный так и бесполезный-
сканы,ваша почта, что лежит у меня,а вы ее не забираете,flood,
sql worms и так далее.Если я этот трафик вам не учитываю, а также например
фильтрую-я попадаю на деньги.Если учитываю-вы. Какую схему выберет провайдер? Невозможно выделить того же флюдера или еще что-то,что захочет вас залить трафиком.Можно только искать и блокировать его источник.
А у нас ,например один из провайдеров(не будем показывать пальцем)
работает до 17:00 причем в полпятого уже на работе никого нет :)
Юзайте NAT ,вообщем. если провайдер дает...
У нас 80% подключений за NAT'ом.
>Предположим я ваш вышестоящий,лежащий/другое провайдер. Мне идет на вашу
>сеть хрень.брень.тут.там/28 инет трафик,как полезный так и бесполезный-
>сканы,ваша почта, что лежит у меня,а вы ее не забираете,flood,
>sql worms и так далее.Если я этот трафик вам не учитываю, а
>также например
>фильтрую-я попадаю на деньги.Если учитываю-вы. Какую схему выберет провайдер? Невозможно выделить того
>же флюдера или еще что-то,что захочет вас залить трафиком.Можно только искать
>и блокировать его источник.Это понятно, и абсолютно ясно, как пров работать будет. Я понимаю, что все, что сыпется в мою подсеткку - то мое, хочу я этого или нет :)
Но, пардон, какое отношение к подстеку, скажем, 123.123.123.0/254 имеют пакеты с destIP, скажем, 80.123.ххх.ххх? Правильно, никакого. А они сыпятся! Причем доподлинно, известно, что эта подсеть распределена меж другимим клиентами этого прова. И вот, при такой безбожно кривой маршрутизации мне пытаются доказать, что никто никого не обманывает и все пашет зашибись. А мне как-то не хочется (пардон, не хотелось :)) огребать пакеты со всех сетей этого прова....>А у нас ,например один из провайдеров(не будем показывать пальцем)
>работает до 17:00 причем в полпятого уже на работе никого нет :)
>
>Юзайте NAT ,вообщем. если провайдер дает...
>У нас 80% подключений за NAT'ом.А нас - тоже :)
Если пров захочет накрутить кому-то трафф он это сделает и тут нифига
не докажешь :( Особливо если он монополист и других провов реально рядом
нет. Нам однажды на канал 128к накрутили так, что едва за 100 процентов
пропускной способности не вылезли. Увлеклись :) И что с этим делать? Судится? Давайте в суде померяемся нетраметами, у кого круче? И заодно лицензию там какую нить на оборудование/софт статистику считающее предъявим. И т.п. Оно у Вас есть? А без этих бумажек ничего не докажете, т.к. судья шарит в нетраметах как свинья в апельсинах по определению.
И вовсе не обязательно маршрутизацию корежить и левый трафф тебе
в подсетку заворачивать. Достаточно просто твой реальный трафф два или даже три раза посчитать или "забыть" из лога нетрамета дельты вырезать :) И усе, попали вы на бабки. Если админ у прова трафф своровал и ему надо отчитаться то что он сделает? Правильно - раскидает его по клиентам на выделенах сидящих. И фиг что докажешь - только прова менять, если есть. То не факт что честнее будет.ЗЫ Вааще все связисты любят дурить народ - пример с обычным телефоном - провели мне телефон и что-то накосячили, что межгород полгода вааще не считался. Халява ! Потом видимо косяк выправили и... думаете они этот
левый межгород за полгода забыли? Щас! На следующий месяц в аккурат влепили по всем имеющимся междугородным звонкам. Ну и естесно
накрутили время так, как будто я сутками на телефоне висел. За полгода как раз и раскидали. Судиться? Опять же нереально - телефоны то все мои, родственники и т.п.
>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранееесть такая штука, как 7 уровней по OSI/ISO. Так вот, даже
по этому простому признаку сравнивать рез-ты учета squid'а
и "считалок" сетевого уровня это примерно как кабель питания
монитора в разъем сетевой карты пытаться засунуть и ожидать,
что будет работать "как надо".../poige
--
http://www.morning.ru/~poige/
ндаааааааааааа
ребята ........
не знаю как вы считаете
пример (только что в свою статистику глянул):
если считать по логам сквида 1060
если по логам ipcad (эмуляция ip accounting на серваке) 1117
разница есть конечно ....
но не такая огромная как вы говорите :)
(причем показатели ipcad сходятся с провайдровскими
показатели от цисок с ip accounting)
далее
тут шел разговор на тему
человек начала качать файло на 100 Метров
и прекратил на 40 => дескать в логах сквида не будет об этом
ничего
это абсолютно не правильно!!!
там будет что-то типа 41-42 метра :) (примерно)
вот ......
а разница между двумя цифрами приведенными выше
из-за dns,ssh,служебных запросов прокси и т,п,
>Уважаемые All /// Помогите разобраться с проблемой
>дело в том что я что то не понимаю что происходит с
>трафиком а точнее
>имеются различия с чтением трафика логом Squida и чтения трафика провайдером ....
>и разность наблюдается почти в 2 раза ..Вчера по логу прошло
>102 Мб а провайдер говорит 214 .... из за чего такое
>может быть
>Может что я не так настроил ? Спасибо заранееДелай проще... смотри на вопрос шире:
1) Берешь любой язык пограммирования который неного знаешь2) в иптаблесах настраиваешь действия LOG для всех(!) пакетов, т.е. даже для тех которые были сброшены, не докачаны и т.д.
3) анализируешь потом прогой самописаной системный журнал: /var/log/kernel/info (ну это у меня так у тебя может быть по другому) ну скажем раз в 5 минут... и кидаешь это все в базу на MySQL или еще какую-нибудь...
4) можно даже разделить это все по портам и типам протоколов, и кидать в соответствующие столбцы таблички... хоть для всей сети, хоть для каждого ип адреса... можешь табличку в начале месяца обнулять, а можешь начинать новую, дабы статистика сохранялась...
5) конечно кажется все страшным а на самом деле реализуется за пару дней... я например писал на PHP - там с базами работать удобнее....А теперь статистика: расхождение по трафику между мной и провайдером 0,02% за полгода!!!