Перейти до

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


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

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

 

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

На нем 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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

или читай эту статью 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

 

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

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

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

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

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% - отличный результат, вот вам и обьяснение :)

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

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

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

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

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

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

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

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

 

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, он должен бы занатиться.

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

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

 

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

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

ipfw nat 10000 config ip 194.247.19.100 log same_ports unreg_only

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

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

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

 

 

 

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

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

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

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

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

 

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

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від GekaPeka
      Ruijie Reyee RG-RAP2200 новая, цена 3600 грн
    • Від tkachik
      Продам
      БУ Tl-wr740n.
      Стан на 4. 
      Роутери прошиті російськомовною прошивкою.
      ціна роутера без бп - 230 грн
      З бп - 260 грн
      Є знижка на опт
    • Від GekaPeka
      MikroTik PowerBox Pro (RB960PGS-PB), новый, в упаковке. Цена: 2800 грн.
    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
×
×
  • Створити нове...