Перейти до

Большая разница в pps на входе и выходе pc-роутера freebsd

DemonS

Автор: DemonS,
в Для людей

 Share Подписчики 2

Рекомендованные сообщения

DemonS

DemonS 0

Опубликовано:
Опубликовано:

Доброго времени суток!

 

Имеется такой роутер :

На нем freebsd-9.0-release, ipfw dummynet + ipfw nat.

Проблема в том, что при почти одинаковом трафике, pps на входе (vlan20, живет на igb1) в два раза больше pps на выходе (igb0):

 


[qwe@nas1 trafshow]# netstat -I vlan20 -h 1
input (vlan20) output
packets errs idrops bytes packets errs bytes colls
13k 0 0 5.6M 12k 0 2.8M 0
13k 0 0 5.0M 13k 0 3.1M 0
14k 0 0 4.8M 13k 0 2.8M 0
13k 0 0 5.0M 12k 0 2.9M 0
14k 0 0 6.1M 13k 0 2.8M 0

 

[qwe@nas1 trafshow]# netstat -I igb0 -h 1
input (igb0) output
packets errs idrops bytes packets errs bytes colls
3.7k 0 0 2.0M 4.9k 0 5.2M 0
3.9k 0 0 2.1M 4.8k 0 4.9M 0
3.9k 0 0 2.0M 4.7k 0 4.6M 0
4.1k 0 0 2.1M 5.2k 0 5.5M 0
4.1k 0 0 2.2M 5.4k 0 5.8M 0

 

Помогите, пожалуйста, разобраться почему так происходит. Предоставлю любую необходимую информацию. Спасибо.

Ссылка на сообщение
Поделиться на других сайтах
pavlabor

pavlabor 1 914

Опубліковано:
Опубліковано:

На внешнем у тебя чистый трафик,

а на внутреннем - брадкаст, мультикаст, ДНС запросы, просто вирусы флудят в сторону дефаулта, и шлют в белый свет как в копеечку вагон запросов которые умирают на луббеке, фаерволе.

 

trafshow, tcpdump - поможет.

Ссылка на сообщение
Поделиться на других сайтах
DemonS

DemonS 0

Опубліковано:
  • Автор
Опубліковано:

На внешнем у тебя чистый трафик,

а на внутреннем - брадкаст, мультикаст, ДНС запросы, просто вирусы флудят в сторону дефаулта, и шлют в белый свет как в копеечку вагон запросов которые умирают на луббеке, фаерволе.

 

trafshow, tcpdump - поможет.

Тогда, по идее, на внешнем у меня должно быть меньше ппс, чем на внутреннем. А у меня наоборот. Мистика. На втором НАСе, где у меня нет ната, потоки и ппс на внутреннем и внешнем интерфейсах примерно одинаковы. Поэтому я и думаю, может ли быть такое из-за ната?

Ссылка на сообщение
Поделиться на других сайтах
pavlabor

pavlabor 1 914

Опубліковано:
Опубліковано:

Тогда или тебя досят с мира,

или читай эту статью http://local.com.ua/...бят-провайдеры/

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

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

И проверь счетчики на входе и выходе, ппс... короче нет дыма без огня, трафик тоже должен быть.

Ссылка на сообщение
Поделиться на других сайтах
Гайджин

Гайджин 574

Опубліковано:
Опубліковано:

Тогда, по идее, на внешнем у меня должно быть меньше ппс, чем на внутреннем. А у меня наоборот. Мистика. На втором НАСе, где у меня нет ната, потоки и ппс на внутреннем и внешнем интерфейсах примерно одинаковы. Поэтому я и думаю, может ли быть такое из-за ната?

Может. Нат трансляция уже закончилась, а из Интернета еще продолжают прилетать какие то обломки.

Так же такое может быть из за ошибок в маршрутизации - выглядит примерно так: аплинк маршрутизирует на Вас блок адресов (допустим 72.73.0.0/23), а Вы используете его не весь (допустим 72.73.0.0/24), при этом в сторону аплинка у вас дефолт роут. Вот и получается что если к Вам из Интернета прилетит что то направленное на 72.73.1.0/24, то будет оно между Вашим сервером и вышестоящим маршрутизатором крутиться до полной выработки TTL-я.

 

p.s. Я такое видел у одних ребят - вышестоящим маршрутизатором был L3 коммутатор. Эх и как же ему было плохо процом в такой ситуации.

Ссылка на сообщение
Поделиться на других сайтах
DemonS

DemonS 0

Опубліковано:
  • Автор
Опубліковано:

или читай эту статью http://local.com.ua/...бят-провайдеры/

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

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

И проверь счетчики на входе и выходе, ппс... короче нет дыма без огня, трафик тоже должен быть.

Убирал шейпинг вообще . ситуация не изменилась. Стало быть торент не причем.

 

Может. Нат трансляция уже закончилась, а из Интернета еще продолжают прилетать какие то обломки.

Так же такое может быть из за ошибок в маршрутизации - выглядит примерно так: аплинк маршрутизирует на Вас блок адресов (допустим 72.73.0.0/23), а Вы используете его не весь (допустим 72.73.0.0/24), при этом в сторону аплинка у вас дефолт роут. Вот и получается что если к Вам из Интернета прилетит что то направленное на 72.73.1.0/24, то будет оно между Вашим сервером и вышестоящим маршрутизатором крутиться до полной выработки TTL-я.

p.s. Я такое видел у одних ребят - вышестоящим маршрутизатором был L3 коммутатор. Эх и как же ему было плохо процом в такой ситуации.

Да, Вы правы. сетка /23, я заюзал нижнюю_часть/24. Чтобы исключить, брожение пакетов, я на бордере завернул все неиспользуемые ИП в роуты 'unreachable'. Теперь пакеты. которые нельзя доставить - просто отбрасываются. Не повлияло никак на разницу ппс.

 

tcpdump -i vlan20 'proto ICMP'

 

15:19:03.232927 IP 172.16.20.2 > 92.241.251.240: ICMP time exceeded in-transit, length 60
15:19:03.233373 IP 172.16.20.2 > 178.46.84.23: ICMP time exceeded in-transit, length 56
15:19:03.238624 IP 172.16.20.2 > 2.61.66.145: ICMP time exceeded in-transit, length 36
15:19:03.243137 IP 172.16.20.2 > 78.132.210.83: ICMP time exceeded in-transit, length 56
15:19:03.243260 IP 172.16.20.2 > 46.200.78.43: ICMP time exceeded in-transit, length 60
15:19:03.243266 IP 172.16.20.2 > 2.97.218.146: ICMP time exceeded in-transit, length 60
15:19:03.248228 IP 172.16.20.2 > 95.139.144.87: ICMP time exceeded in-transit, length 56
15:19:03.249133 IP 172.16.20.2 > 195.8.36.251: ICMP time exceeded in-transit, length 60
15:19:03.249552 IP 172.16.20.2 > 83.149.48.52: ICMP time exceeded in-transit, length 56
15:19:03.250809 IP 172.16.20.2 > 213.110.199.114: ICMP time exceeded in-transit, length 56
15:19:03.253428 IP 172.16.20.2 > 88.0.173.213: ICMP time exceeded in-transit, length 36
15:19:03.264478 IP 172.16.20.2 > 188.234.246.203: ICMP time exceeded in-transit, length 56
15:19:03.276825 IP 172.16.20.2 > 95.37.190.90: ICMP time exceeded in-transit, length 36
15:19:03.277343 IP 172.16.20.2 > 178.169.93.179: ICMP time exceeded in-transit, length 60
15:19:03.285562 IP 172.16.20.2 > 81.66.202.254: ICMP host 194.247.16.8 unreachable, length 36
15:19:03.294277 IP 172.16.20.2 > 109.200.159.195: ICMP time exceeded in-transit, length 60
15:19:03.296286 IP 172.16.20.2 > 93.116.232.26: ICMP time exceeded in-transit, length 60
15:19:03.296940 IP 172.16.20.2 > 109.165.58.5: ICMP time exceeded in-transit, length 56
15:19:03.296944 IP 172.16.20.2 > 91.239.143.230: ICMP time exceeded in-transit, length 36
15:19:03.300351 IP 172.16.20.2 > 159.224.188.213: ICMP time exceeded in-transit, length 60
15:19:03.304447 IP 172.16.20.2 > 91.189.166.88: ICMP time exceeded in-transit, length 56

 

Поясню конфигурацию интерфейсов и правила файервола. Может в них собака порылась.

 

 

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
ether 90:e2:ba:2d:f5:d8
inet 10.10.1.1 netmask 0xffff0000 broadcast 10.10.255.255
inet 194.247.18.1 netmask 0xffffff00 broadcast 194.247.18.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
ether 90:e2:ba:2d:f5:d9
inet6 fe80::92e2:baff:fe2d:f5d9%igb1 prefixlen 64 scopeid 0x2
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
vlan20: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 90:e2:ba:2d:f5:d9
inet 172.16.20.2 netmask 0xffffff00 broadcast 172.16.20.255
inet6 fe80::92e2:baff:fe2d:f5d9%vlan20 prefixlen 64 scopeid 0x10
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 20 parent interface: igb1

 

и файервол

таблица 122 - список моих сетей, серые и белые.
00001 allow ip from any to any via lo0
00090 allow ip from any to any via vlan21 // to dell route
00100 skipto 1000 ip from any to any via igb0 // local
00100 skipto 10000 ip from any to any via vlan20 // external
01000 allow ip from table(122) to table(122)
01010 allow icmp from any to any
02024 pipe 25 ip from table(123) to table(7) out // ????????-20?
......
02107 pipe 108 ip from table(27) to any in // special-4096-4096
09999 skipto 65534 ip from any to any
10020 allow ip from any to 194.247.18.0/24 in
11020 nat tablearg ip from any to table(126) in // нат 1:1
11030 nat tablearg ip from table(127) to any out // нат 1:1
11040 nat 10000 ip from any to any
65534 deny log logamount 10000 ip from any to any
65535 allow ip from any to any

ipfw nat 10000 config ip 194.247.19.100 log same_ports unreg_only

 

Надеюсь, эта информация пригодится.

Ссылка на сообщение
Поделиться на других сайтах
Melanxolik

Melanxolik 63

Опубліковано:
Опубліковано:

Хз. сейчас отошел от этой темы, но поигрался бы с count и посмотрел что творится на интерфейсах по счетчикам, потом перемещал бы правила, может у Вас пакеты попадают в кольцо, еще важно понять что там у Вас с one pass

Ссылка на сообщение
Поделиться на других сайтах
greyshadow

greyshadow 22

Опубліковано:
Опубліковано:

tcpdump -i vlan20 'proto ICMP'

 

 

15:19:03.232927 IP 172.16.20.2 > 92.241.251.240: ICMP time exceeded in-transit, length 60
15:19:03.233373 IP 172.16.20.2 > 178.46.84.23: ICMP time exceeded in-transit, length 56
15:19:03.238624 IP 172.16.20.2 > 2.61.66.145: ICMP time exceeded in-transit, length 36
15:19:03.243137 IP 172.16.20.2 > 78.132.210.83: ICMP time exceeded in-transit, length 56
15:19:03.243260 IP 172.16.20.2 > 46.200.78.43: ICMP time exceeded in-transit, length 60
15:19:03.243266 IP 172.16.20.2 > 2.97.218.146: ICMP time exceeded in-transit, length 60
15:19:03.248228 IP 172.16.20.2 > 95.139.144.87: ICMP time exceeded in-transit, length 56
15:19:03.249133 IP 172.16.20.2 > 195.8.36.251: ICMP time exceeded in-transit, length 60
15:19:03.249552 IP 172.16.20.2 > 83.149.48.52: ICMP time exceeded in-transit, length 56
15:19:03.250809 IP 172.16.20.2 > 213.110.199.114: ICMP time exceeded in-transit, length 56
15:19:03.253428 IP 172.16.20.2 > 88.0.173.213: ICMP time exceeded in-transit, length 36
15:19:03.264478 IP 172.16.20.2 > 188.234.246.203: ICMP time exceeded in-transit, length 56
15:19:03.276825 IP 172.16.20.2 > 95.37.190.90: ICMP time exceeded in-transit, length 36
15:19:03.277343 IP 172.16.20.2 > 178.169.93.179: ICMP time exceeded in-transit, length 60
15:19:03.285562 IP 172.16.20.2 > 81.66.202.254: ICMP host 194.247.16.8 unreachable, length 36
15:19:03.294277 IP 172.16.20.2 > 109.200.159.195: ICMP time exceeded in-transit, length 60
15:19:03.296286 IP 172.16.20.2 > 93.116.232.26: ICMP time exceeded in-transit, length 60
15:19:03.296940 IP 172.16.20.2 > 109.165.58.5: ICMP time exceeded in-transit, length 56
15:19:03.296944 IP 172.16.20.2 > 91.239.143.230: ICMP time exceeded in-transit, length 36
15:19:03.300351 IP 172.16.20.2 > 159.224.188.213: ICMP time exceeded in-transit, length 60
15:19:03.304447 IP 172.16.20.2 > 91.189.166.88: ICMP time exceeded in-transit, length 56

 

 

 

Ну так вот вам и ответ - пакеты "бродят" по кольцу между вами и провом пока ttl не истечет, если у вас за 0.07 секунды 21 пакет "умер", примерно столько же по теории вероятностей "умерло" на стороне прова (уже 42 пакета) и как минимум каждый пакет 15 раз туда-сюда слетал, итого

 

42*15/0.07 примерно 9000 пакетов в секунду (расчет очень грубый) но какраз это и есть те "лишние" пакеты на вход и исход , у вас 13k - 3.7k=9.3k погрешность моих расчетов примерно 4% - отличный результат, вот вам и обьяснение :)

Ссылка на сообщение
Поделиться на других сайтах
DemonS

DemonS 0

Опубліковано:
  • Автор
Опубліковано:

Хз. сейчас отошел от этой темы, но поигрался бы с count и посмотрел что творится на интерфейсах по счетчикам, потом перемещал бы правила, может у Вас пакеты попадают в кольцо, еще важно понять что там у Вас с one pass

one pass = 1
Ссылка на сообщение
Поделиться на других сайтах
Гайджин

Гайджин 574

Опубліковано:
Опубліковано:

Ну так вот вам и ответ - пакеты "бродят" по кольцу между вами и провом пока ttl не истечет, если у вас за 0.07 секунды 21 пакет "умер", примерно столько же по теории вероятностей "умерло" на стороне прова (уже 42 пакета) и как минимум каждый пакет 15 раз туда-сюда слетал, итого

42*15/0.07 примерно 9000 пакетов в секунду (расчет очень грубый) но какраз это и есть те "лишние" пакеты на вход и исход , у вас 13k - 3.7k=9.3k погрешность моих расчетов примерно 4% - отличный результат, вот вам и обьяснение :)

Не факт - это может быть куча трассировщиков.

Ссылка на сообщение
Поделиться на других сайтах
DemonS

DemonS 0

Опубліковано:
  • Автор
Опубліковано:

Меня смущает еще один момент.

 

15:19:03.296940 IP 172.16.20.2 > 109.165.58.5: ICMP time exceeded in-transit, length 56

15:19:03.296944 IP 172.16.20.2 > 91.239.143.230: ICMP time exceeded in-transit, length 36

15:19:03.300351 IP 172.16.20.2 > 159.224.188.213: ICMP time exceeded in-transit, length 60

15:19:03.304447 IP 172.16.20.2 > 91.189.166.88: ICMP time exceeded in-transit, length 56

А именно то, что адрес 172.16.20.2 не попал в нат. Согласно правила 11040, он должен бы занатиться.

Ссылка на сообщение
Поделиться на других сайтах
DemonS

DemonS 0

Опубліковано:
  • Автор
Опубліковано:

Так, косяк найден. Топикстартер - нуб и опозорился(с). :facepalm:

 

Гайджин и greyshadow Вы оба правы и помогли найти верное направление поиска.

Проблема заключалась в конфиге ната. В строчке 

ipfw nat 10000 config ip 194.247.19.100 log same_ports unreg_only

отсутствовала опция deny_in.

Согласно мана, эта опция выполняет отбрасывание пакетов, для которых нет соответствия в таблице сессий ната. Поскольку битва была за каждое правило файервола, то эта опция была убрана с целью принять все пакеты, ведь по идее, левых пакетов, с неверным адресом назначения не должно прийти никогда. Ну поскольку нагрузка была небольшая, то это нигде не вылезло. а на разницу ппс внимание обратили сравнительно недавно.

Большое спасибо! :)

 

 

 

P.S. Напишите в личку, как тут "+" в репутацию добавить. Похоже, не хватает у меня рейтинга для выставления репутаций

Ссылка на сообщение
Поделиться на других сайтах
greyshadow

greyshadow 22

Опубліковано:
Опубліковано:

Ну так вот вам и ответ - пакеты "бродят" по кольцу между вами и провом пока ttl не истечет, если у вас за 0.07 секунды 21 пакет "умер", примерно столько же по теории вероятностей "умерло" на стороне прова (уже 42 пакета) и как минимум каждый пакет 15 раз туда-сюда слетал, итого

42*15/0.07 примерно 9000 пакетов в секунду (расчет очень грубый) но какраз это и есть те "лишние" пакеты на вход и исход , у вас 13k - 3.7k=9.3k погрешность моих расчетов примерно 4% - отличный результат, вот вам и обьяснение :)

Не факт - это может быть куча трассировщиков.

 

в случайные 0.07 секунды 21 трейс с разных сторон света? согласитесь маловероятно ;)

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Share
Подписчики 2
Перейти до переліку тем

  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • a_n_h
      freebsd 11.xx для NAS-а лучше последующих версий
      Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Inna13
      Продам MikroTik, Ubiquiti
      Від Inna13
      Наша компанія має стаж роботи понад 15 років. У нас є дві форми оплати з ПДВ та ФОП, гарантія на товар. Займаємось продажем різного Wi-Fi обладнання: роутери, точки доступу, WI-FI антени. 
    • tarantul13
      Juniper MX-5t UPGRADE MX80
      Від tarantul13
      Продається маршрутизатор Juniper MX80 зі всіма ліцензіями. Працював в датацентрі. Замінився на інше обладнання. Все робоче - перевірено.
      Додаткові питання - пишіть. Можливо по перерахунку.
    • mac
      Помилка feesharvester
      Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • BALTAR
      Продам Mikrotik RB3011UiAS-RM
      Від BALTAR
      Продам Mikrotik RB3011UiAS-RM, новий, купувався під проєкт, але не зрослось. 
      Ціеа 5500 грн
×
×
  • Створити нове...