shuu01

Используем accel как pptp терминатор. И в последнее время наблюдаю странную картину. Звонит клиент с жалобой на отсутствие услуги. Смотрю на accel - интерфейс pptp для этого клиента есть. Смотрю у клиента на роутере - pptp соединение есть. Смотрю tcpdump'ом pptp интерфейс на accel - вижу только LCP пакеты. Смотрю дампом на ether - вижу GRE пакеты от клиента. Смотрю дампом на роутере клиента - вижу от него исходящий траффик. То есть PPTP соединение есть как на сервере так и на клиенте, и GRE даже доходит до сервера, но в pptp интерфейсе на сервере тишина. Как такое может быть? accel-pppd последняя версия с гита #uname -a Linux ppp01 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux #sudo iptables-save *mangle :PREROUTING ACCEPT [61715518991:41142435994737] :INPUT ACCEPT [17704277474:5092668441437] :FORWARD ACCEPT [43999349463:36042937353214] :OUTPUT ACCEPT [26846838987:31981635242788] :POSTROUTING ACCEPT [70845782151:68024411057323] -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu COMMIT *filter :INPUT ACCEPT [17704277478:5092668441787] :FORWARD ACCEPT [43998940265:36042775725953] :OUTPUT ACCEPT [26846838995:31981635252078] -A FORWARD -p udp -m udp --sport 67:68 --dport 67:68 -j REJECT --reject-with icmp-port-unreachable COMMIT #sudo ethtool -i eth3 driver: igb version: 5.3.5.12 firmware-version: 1.63, 0x80000ee4 bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no #sudo ethtool -g eth3 Ring parameters for eth3: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 2048 RX Mini: 0 RX Jumbo: 0 TX: 2048 #sudo ethtool -k eth3 Features for eth3: rx-checksumming: off tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off udp-fragmentation-offload: off [fixed] generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] busy-poll: off [fixed]

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

в ванильном тоже есть

в 9 дебе (ядро 4.9) этот патчик для xt_TCPMSS уже присутствует. Обновился до 9.

Вечером снова появились клиенты, у которых не открываются сайты. Пришлось вернуть правило tcp mss обратно

Этот что ли?

myth А в чем проблема с этим правилом? Везде в мануалах наоборот, рекомендуют его добавлять.

ipoe нет, только pptp

поставил на одном сервере мту1492 на бонде и убрал правило. Посмотрю за динамикой

Без этого правила у некоторых клиентов сайты не открывались. Правда, это было до того, как я gso, tso отключил на карте.

Собрал последнюю версию с гита под дебианом 8 на двух серверах для pptp . Столкнулся с проблемой, что сервера становятся недоступны по сети примерно раз в неделю в случайном порядке. Не отвечают на icmp. В логах пусто. На мониторе BUG: soft lockup - CPU stuck. Hyperthreading выключен. Виртуализация выключена. grub_cmdline_linux="hoht intel_idle.max_cstate=0 processor.max_cstate=1 pcie_aspm=off acpi=off noapic" #uname -a Linux ppp01 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux #free -h total used free shared buffers cached Mem: 7,7G 1,4G 6,3G 17M 143M 759M -/+ buffers/cache: 483M 7,2G Swap: 9,4G 0B 9,4G #lspci | grep Ethernet 01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 04:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 04:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 04:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) #cat /etc/debian_version 8.9 #cat /etc/accel-ppp.conf #lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 2 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 26 Model name: Intel(R) Xeon(R) CPU E5530 @ 2.40GHz Stepping: 5 CPU MHz: 2400.027 BogoMIPS: 4800.32 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-7 #cat /proc/interrupts #cat /etc/network/interfaces auto bond0 iface bond0 inet manual #mtu 9000 bond-mode 802.3ad slaves eth2 eth3 bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-xmit-hash-policy layer2+3 post-up /sbin/ethtool -K eth2 tso off gso off gro off tx off rx off rxvlan off txvlan off post-up /sbin/ethtool -G eth2 rx 2048 tx 2048 post-up /sbin/ethtool -K eth3 tso off gso off gro off tx off rx off rxvlan off txvlan off post-up /sbin/ethtool -G eth3 rx 2048 tx 2048 auto bond0.200 iface bond0.200 inet static address 10.20.10.10 netmask 255.255.255.0 vlan-raw-device bond0 auto bond1 iface bond1 inet manual #mtu 9000 bond-mode 802.3ad slaves eth4 eth5 bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-xmit-hash-policy layer2+3 post-up /sbin/ethtool -K eth4 tso off gso off gro off tx off rx off rxvlan off txvlan off post-up /sbin/ethtool -G eth4 rx 2048 tx 2048 post-up /sbin/ethtool -K eth5 tso off gso off gro off tx off rx off rxvlan off txvlan off post-up /sbin/ethtool -G eth5 rx 2048 tx 2048 auto bond1.100 iface bond1.100 inet static address 10.10.10.10 netmask 255.255.255.0 vlan-raw-device bond1 #sudo iptables-save *filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A FORWARD -p udp -m udp --sport 67:68 --dport 67:68 -j REJECT --reject-with icmp-port-unreachable COMMIT *mangle :PREROUTING ACCEPT :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu COMMIT #cat /etc/initramfs-tools/modules igb InterruptThrottleRate=3,3,3,3,3,3 RSS=8,8,8,8,8,8 QueuePairs=1,1,1,1,1,1 #sudo ethtool -i eth3 driver: igb version: 5.3.5.12 firmware-version: 1.63, 0x80000ee4 bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no #sudo ethtool -g eth3 Ring parameters for eth3: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 2048 RX Mini: 0 RX Jumbo: 0 TX: 2048 #sudo ethtool -k eth3 Features for eth3: rx-checksumming: off tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off udp-fragmentation-offload: off [fixed] generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] busy-poll: off [fixed]

Собрал LAG между snr-2990g и d-link DGS-3120-24TC. Два порта с одной стороны и два с другой. d-link на абонентов, snr в аплинк. На d-link алгоритм load-balance src-ip. На snr алгоритм load-balance dst-ip. На данный момент наблюдаю ситуацию: d-link все пакеты с одним src-ip отправляет в один конкретный порт, с другим - в другой. snr же пакеты c конкретным dst-ip шлет то в один, то в другой, то в оба порта сразу. Тот же самый LAG между двумя длинками работает адекватно указанным настройкам. snr-2990g: vlan 1-3;951;4095 Interface Ethernet1/0/8 description Shaper_2 switchport mode trunk switchport trunk allowed vlan 2-3;951 switchport trunk native vlan 4095 port-group 3 mode active lacp port-priority 10 loopback-detection specified-vlan 2-3;951 loopback-detection control block Interface Ethernet1/0/11 description Shaper_1 switchport mode trunk switchport trunk allowed vlan 2-3;951 switchport trunk native vlan 4095 port-group 3 mode active loopback-detection specified-vlan 2-3;951 loopback-detection control block Interface Port-Channel3 load-balance dst-ip SNR-S2990G-48TX#show port-group 3 detail Flags: A -- LACP_Activity, B -- LACP_timeout, C -- Aggregation, D -- Synchronization, E -- Collecting, F -- Distributing, G -- Defaulted, H -- Expired Port-group number: 3, Mode: active, Load-balance: dst-ip Port-group detail information: System ID: 0x0064,f8-f0-82-75-d9-d6 Local: Port Status Priority Oper-Key Flag ----------------------------------------------------------- Ethernet1/0/8 Selected 10 3 {ACDEF} Ethernet1/0/11 Selected 32768 3 {ACDEF} Remote: Actor Partner Priority Oper-Key SystemID Flag -------------------------------------------------------------------------------- Ethernet1/0/8 8 1 14 0x0001,c8-be-19-ca-62-60 {ABCDEF} Ethernet1/0/11 14 1 14 0x0001,c8-be-19-ca-62-60 {ABCDEF} d-link dgs-3120: # LACP config link_aggregation algorithm ip_source create link_aggregation group_id 1 type lacp config link_aggregation group_id 1 master_port 1:14 ports 1:8,1:14 state enable config link_aggregation group_id 1 trap disable config lacp_port 1:8,1:14 mode active # VLAN enable pvid auto_assign config vlan default delete 1:1-1:24 config vlan default advertisement enable create vlan 2 tag 2 config vlan 2 add tagged 1:8,1:14 config vlan 2 add untagged 1:2 advertisement disable create vlan 3 tag 3 config vlan 3 add tagged 1:8,1:14 config vlan 3 add untagged 1:21 advertisement disable create vlan 951 tag 951 config vlan 951 add tagged 1:8,1:14 config vlan 951 add untagged 1:20 advertisement disable config port_vlan 1:1,1:3-1:19,1:22-1:24 gvrp_state disable ingress_checking enable acceptable_frame admit_all pvid 1 DGS-3120-24TC:admin#show link_aggregation Command: show link_aggregation Link Aggregation Algorithm = IP-Source Group ID : 1 Type : LACP Master Port : 1:14 Member Port : 1:8,1:14 Active Port : 1:8,1:14 Status : Enabled Flooding Port : 1:8 Trap : Disabled Total Entries : 1

ТС уже решил проблему добавлением дефолтных вланов на микротиках в бридж. Сейчас LACP активны оба порта, в случае отключения одного, траффик в течении 5 секунд перекидывается на соседний порт.

Поправлюсь: mikrotik bridge пропускает lacpdu пакеты, если в бридже находятся не вланы, а именно порты. Как я понимаю, lacpdu ходят в дефолтном влане

Mikrotik bridge действительно не пропускает LACPDU пакеты

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

Собираю на стенде следующую схему: Порты 4 и 5 на микротиках в бридже. Порты 1 и 2 на длинках в LACP транке. Конфиги на длинках следующие: первый: config vlan default delete 1-26 create vlan 300 tag 300 config vlan 300 add tagged 1-2 config link_aggregation algorithm ip_source_dest create link_aggregation group_id 1 type lacp config link_aggregation group_id 1 master_port 1 ports 1-2 state enable config link_aggregation group_id 1 trap enable config lacp_port 1-26 mode passive второй: config vlan default delete 1-26 create vlan 300 tag 300 config vlan 300 add tagged 1-2 config link_aggregation algorithm ip_source_dest create link_aggregation group_id 1 type lacp config link_aggregation group_id 1 master_port 1:1 ports 1:1-1:2 state enable config link_aggregation group_id 1 trap enable config lacp_port 1:1-1:2 mode active config lacp_port 1:3-1:24 mode passive Хочется, чтобы оба порта в транке были активными. В данный момент при таком подключении активным выбирается только один порт в транке: DGS-3120-24TC:admin#show link_aggregation Command: show link_aggregation Link Aggregation Algorithm = IP-Source-Dest Group ID : 1 Type : LACP Master Port : 1:1 Member Port : 1:1-1:2 Active Port : 1:1 Status : Enabled Flooding Port : 1:1 Trap : Enabled Total Entries : 1 Если соединить длинки напрямую медью без микротиков в разрыве, оба порта в состоянии active: DGS-3120-24TC:admin#show link_aggregation Command: show link_aggregation Link Aggregation Algorithm = IP-Source-Dest Group ID : 1 Type : LACP Master Port : 1:1 Member Port : 1:1-1:2 Active Port : 1:1-1:2 Status : Enabled Flooding Port : 1:1 Trap : Enabled Total Entries : 1

Помогло обновление прошивки с 6.19 на 6.35

Все очереди по маске /32, меньших масок нет, более приоритетных очередей нет.

Стоит четырехядерный intel 2400 Mhz, 1Gb пямяти, 6.19 routeros. Используем его только для шейпинга в simple queue. Около 1600 очередей без parent. add max-limit=128k/128k name=unl12061_ priority=2/2 queue=PCQ_src/PCQ_dest target=10.210.4.37/32 Недавно обнаружили интересную особенность. Если взять какую либо очередь, например с номером 1500 и перетащить ее вниз на номер 1600 в винбоксе, в нее перестает попадать траффик с указанным таргетом. Соответственно данный ip перестает шейпиться и ходит через шейпер без ограничений. Если эту запись перетащить повыше, на номер 1516, траффик снова начинает попадать в очередь. Если опустить чуть ниже, снова ходит без ограничений и в очередь не попадает. Для каждой отдельной записи такое волшебное место в списке индивидуально. Сталкивался ли кто-нибудь с подобным загадочным поведением simple queue?

Доброго времени суток. Есть небольшой вопрос по маршрутизации. На схеме обрисовал примерную конфигурацию. Каждая AS - это один роутер. AS100 от AS101 получает только дефолт и отдает свои сети. AS101 получает два дефолта от AS102 и AS103 и так же отдает свои сети. Только в AS103 сети отдаются с препендом, а дефолту от AS102 назначается больший вес, чтобы трафик шел по одному и тому же маршруту в центр и обратно. Сейчас траффик от сетей из AS100 идет так: AS100-AS101-AS102-центр траффик от сетей из AS101 идет так: AS101-AS102-центр Задача состоит в том, чтобы траффик от сетей AS100 до центра шел по маршруту AS100-AS101-AS103-центр, а от AS101 по маршруту AS101-AS102-центр. При этом желательно не использовать маркировки траффика, только на маршрутизации. Также нежелательно использовать bgp multihop и бриджи. То есть нужно дать понять устройству в AS101, что для сетей, полученных от AS100 дефолт должен показывать на AS103, а для всего остального на AS102. Пока изучаю vrf, но не могу до конца понять, поможет ли он в данной ситуации.

кольцо крутить на портах свитча или прямо на микротик-шейперах на бридже?

Схема следующая: В шейпере вланы бриджуются. В данный момент резервирование производится скриптом, который физически вырубает порт на верхнем свитче. Возможно ли сделать vrrp интерфейс в сторону верхнего свитча, повесить на него вланы, забриджевать их и резервировать при помощи priority?

80 килопакетов в пике.

core#ping 10.10.2.40 r 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 10.10.2.40, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/1/4 ms