nicol@s Опубликовано 3 ноября, 2009 (изменено) · Жалоба Добрый день! Есть проблема... Ядро сети Dlink 3426. К нему подключены роутеры DGS 3612 (абоненты). Ядро соединено с бриджом. Бридж собран с интерфейсами igb0, igb1, igb2: igb0 - смотрит в сеть igb1 - border1 igb2 - border2 Бридж играет роль шейпера (ipfw). К бриджу подключены border1 и border2 Border1: FreeBSD 7.0-STABLE-200807 i386 Border2: FreeBSD 7.2-STABLE-200906 i386 Бридж: FreeBSD 7.2-STABLE-200906 amd64 Трафик делим между 2-мя бордерами. С border2 проблем нет. А на border1 ситуация следующая: пинги через border1 от абонентов и с самого бриджа ping ya.ru PING ya.ru (93.158.134.8): 56 data bytes 64 bytes from 93.158.134.8: icmp_seq=0 ttl=58 time=95.083 ms 64 bytes from 93.158.134.8: icmp_seq=1 ttl=58 time=102.876 ms 64 bytes from 93.158.134.8: icmp_seq=2 ttl=58 time=113.630 ms 64 bytes from 93.158.134.8: icmp_seq=3 ttl=58 time=90.352 ms 64 bytes from 93.158.134.8: icmp_seq=4 ttl=58 time=127.349 ms 64 bytes from 93.158.134.8: icmp_seq=5 ttl=58 time=115.942 ms 64 bytes from 93.158.134.8: icmp_seq=6 ttl=58 time=103.753 ms 64 bytes from 93.158.134.8: icmp_seq=7 ttl=58 time=124.507 ms В то время как пинги с самого border1: ping ya.ru PING ya.ru (213.180.204.8): 56 data bytes 64 bytes from 213.180.204.8: icmp_seq=0 ttl=61 time=3.130 ms 64 bytes from 213.180.204.8: icmp_seq=1 ttl=61 time=2.909 ms 64 bytes from 213.180.204.8: icmp_seq=2 ttl=61 time=3.791 ms 64 bytes from 213.180.204.8: icmp_seq=3 ttl=61 time=2.953 ms 64 bytes from 213.180.204.8: icmp_seq=4 ttl=61 time=3.298 ms 64 bytes from 213.180.204.8: icmp_seq=5 ttl=61 time=3.096 ms на бридже: 1). netstat -w1d -I igb0 input (igb0) output packets errs bytes packets errs bytes colls 32442 0 19375201 29681 0 23220291 0 31894 0 19334182 29124 0 23043942 0 31566 0 18885017 28558 0 22390016 0 31810 0 19200993 28768 0 22270687 0 31879 0 19347245 29145 0 22795440 0 31697 0 18997706 29274 0 22651927 0 32042 0 18963695 29634 0 23508103 0 30674 0 18123997 28432 0 22890282 0 31654 0 18519433 28860 0 22918799 0 31961 0 19145696 29418 0 23238031 0 32056 0 19053994 29723 0 23775215 0 32367 0 18952231 29771 0 23774054 0 2). netstat -w1d -I igb1 input (igb1) output packets errs bytes packets errs bytes colls 21378 0 19903174 21410 0 9866489 0 21444 0 19948761 21752 0 10266869 0 21435 0 19972984 21825 0 10289265 0 21318 0 19748715 21431 0 10238696 0 21606 0 19855988 21467 0 10483023 0 21825 0 19956737 21750 0 10452641 0 21665 0 19805016 21980 0 10711357 0 20937 0 18983521 21357 0 10506764 0 21241 0 19280484 21992 0 10713008 0 21469 0 19652542 21667 0 10391424 0 21235 0 19538130 21524 0 10757572 0 20779 0 18963762 21003 0 10525245 0 20853 0 18854491 21312 0 10559890 0 Те же самые команды с border1: 1). внутренний netstat -w1d -I em1 input (em1) output packets errs bytes packets errs bytes colls 9862 0 8286463 8226 0 4172860 0 10060 0 8603460 7209 0 3184874 0 9290 0 7781648 7709 0 3672720 0 9720 0 8311391 7208 0 3545028 0 10256 0 8669129 8232 0 4678531 0 9509 0 8140150 7715 0 3878637 0 9554 0 8081766 7199 0 3512477 0 9426 0 8046217 7721 0 3867273 0 9795 0 8177803 7721 0 3729722 0 9637 0 8297993 7199 0 3766607 0 9671 0 8275210 7202 0 3510855 0 9451 0 8306122 7196 0 3535604 0 9324 0 8009044 7202 0 3092661 0 9715 0 8265237 7364 0 3575433 0 9908 0 8215978 7499 0 3911766 0 9776 0 8270432 8086 0 4178572 0 2). внешний netstat -w1d -I em0 input (em0) output packets errs bytes packets errs bytes colls 8253 0 4640677 9803 0 8495567 0 7897 0 4878726 10041 0 7322200 0 8368 0 4776220 9832 0 8565609 0 7650 0 4285985 9283 0 7717595 0 7891 0 4352473 9797 0 8134889 0 8606 0 5018218 9657 0 8289548 0 8460 0 4720658 10207 0 8397786 0 7543 0 4085187 9277 0 8059337 0 9376 0 6040976 11500 0 8860064 0 8181 0 4552212 10295 0 8582838 0 8774 0 5079266 10062 0 8494193 0 8193 0 4674008 10295 0 8520010 0 10170 0 7212068 10813 0 8596957 0 8499 0 4936674 10828 0 9090783 0 8416 0 4409607 10297 0 9050824 0 7613 0 3960242 9280 0 8231506 0 На border2 проблем нет. В этой же конфигурации Border1 легко перемылывал 500 МБит. На border1 стоят дрова от яндекса для em. loader.conf: hw.em.rxd="4096" hw.em.txd="4096" /etc/sysctl.conf на border1: net.inet.tcp.recvspace=262144 net.inet.tcp.sendspace=62144 net.inet.udp.recvspace=1048576 kern.ipc.maxsockbuf=4194304 kern.ipc.nmbclusters=262144 net.inet.ip.portrange.first=5700 kern.ipc.somaxconn=65535 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=30 net.inet.ip.intr_queue_maxlen=4096 net.inet.tcp.delayed_ack=0 net.inet.tcp.delacktime=10 net.inet.tcp.newreno=0 net.inet.tcp.msl=2500 net.inet.ip.rtmaxcache=1024 net.inet.raw.recvspace=65536 net.inet.ip.dummynet.hash_size=65536 net.inet.ip.fw.dyn_ack_lifetime=60 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=10 net.inet.ip.fw.dyn_max=16192 net.inet.ip.fastforwarding=1 net.isr.direct=1 net.inet.icmp.drop_redirect=1 dev.em.0.rx_kthreads=4 dev.em.1.rx_kthreads=4 dev.em.2.rx_kthreads=4 Привели параметры sysctl border1 к параметрам, как на border2: kern.ipc.nmbclusters=262144 net.inet.icmp.icmplim=200 Добавил новые параметры: net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.bpf.bufsize=4194304 net.bpf.maxbufsize=8388608 При эом ситуация не изменилась. Вывод команды dmesg: Border2 внешняя: em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 5018002561 em0: Good Packets Xmtd = 5133609771 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 Border1 внешняя: em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 9975 em0: Receive No Buffers = 7099 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 1 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 2639750787 em0: Good Packets Xmtd = 2455117624 em0: TSO Contexts Xmtd = 18 em0: TSO Contexts Failed = 0 Border2 внтуренняя: em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 5189211824 em1: Good Packets Xmtd = 4995412107 em1: TSO Contexts Xmtd = 16447 em1: TSO Contexts Failed = 0 Border1 внутренняя: em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 2469872680 em1: Good Packets Xmtd = 2578357516 em1: TSO Contexts Xmtd = 14174 em1: TSO Contexts Failed = 0 Бридж: внутренняя igb0: Adapter hardware address = 0xffffff00012f0528 igb0: CTRL = 0xc00241 RCTL = 0x801a igb0: Packet buffer = Tx=0k Rx=0k igb0: Flow control watermarks high = 63488 low = 61988 igb0: Queue(0) tdh = 154, tdt = 154 igb0: no descriptors avail event = 0 igb0: TX(0) MSIX IRQ Handled = 26582786007 igb0: TX(0) Packets sent = 69466117227 igb0: Queue(1) tdh = 0, tdt = 0 igb0: no descriptors avail event = 0 igb0: TX(1) MSIX IRQ Handled = 0 igb0: TX(1) Packets sent = 0 igb0: Queue(2) tdh = 0, tdt = 0 igb0: no descriptors avail event = 0 igb0: TX(2) MSIX IRQ Handled = 0 igb0: TX(2) Packets sent = 0 igb0: Queue(3) tdh = 0, tdt = 0 igb0: no descriptors avail event = 0 igb0: TX(3) MSIX IRQ Handled = 0 igb0: TX(3) Packets sent = 0 igb0: Queue(0) rdh = 186, rdt = 185 igb0: RX(0) Packets received = 18340736258 igb0: RX(0) Split Packets = 0 igb0: RX(0) Byte count = 12477314664354 igb0: RX(0) MSIX IRQ Handled = 11343806385 igb0: RX(0) LRO Queued= 0 igb0: RX(0) LRO Flushed= 0 igb0: Queue(1) rdh = 150, rdt = 149 igb0: RX(1) Packets received = 18360157016 igb0: RX(1) Split Packets = 0 igb0: RX(1) Byte count = 12474408387147 igb0: RX(1) MSIX IRQ Handled = 11362784395 igb0: RX(1) LRO Queued= 0 igb0: RX(1) LRO Flushed= 0 igb0: Queue(2) rdh = 142, rdt = 140 igb0: RX(2) Packets received = 18122235444 igb0: RX(2) Split Packets = 0 igb0: RX(2) Byte count = 12331139081653 igb0: RX(2) MSIX IRQ Handled = 11268633644 igb0: RX(2) LRO Queued= 0 igb0: RX(2) LRO Flushed= 0 igb0: Queue(3) rdh = 95, rdt = 94 igb0: RX(3) Packets received = 18379433903 igb0: RX(3) Split Packets = 0 igb0: RX(3) Byte count = 12407828772109 igb0: RX(3) MSIX IRQ Handled = 11387935869 igb0: RX(3) LRO Queued= 0 igb0: RX(3) LRO Flushed= 0 igb0: LINK MSIX IRQ Handled = 5 igb0: Mbuf defrag failed = 0 igb0: Std mbuf header failed = 0 igb0: Std mbuf packet failed = 0 igb0: Driver dropped packets = 0 igb0: Driver tx dma failure in xmit = 0 border1 igb1: Adapter hardware address = 0xffffff000451a528 igb1: CTRL = 0x18c00241 RCTL = 0x801a igb1: Packet buffer = Tx=0k Rx=0k igb1: Flow control watermarks high = 63488 low = 61988 igb1: Queue(0) tdh = 150, tdt = 151 igb1: no descriptors avail event = 1 igb1: TX(0) MSIX IRQ Handled = 9053729033 igb1: TX(0) Packets sent = 15117561092 igb1: Queue(1) tdh = 0, tdt = 0 igb1: no descriptors avail event = 0 igb1: TX(1) MSIX IRQ Handled = 0 igb1: TX(1) Packets sent = 0 igb1: Queue(2) tdh = 0, tdt = 0 igb1: no descriptors avail event = 0 igb1: TX(2) MSIX IRQ Handled = 0 igb1: TX(2) Packets sent = 0 igb1: Queue(3) tdh = 0, tdt = 0 igb1: no descriptors avail event = 0 igb1: TX(3) MSIX IRQ Handled = 0 igb1: TX(3) Packets sent = 0 igb1: Queue(0) rdh = 253, rdt = 251 igb1: RX(0) Packets received = 3887801598 igb1: RX(0) Split Packets = 0 igb1: RX(0) Byte count = 3419307814950 igb1: RX(0) MSIX IRQ Handled = 2880414195 igb1: RX(0) LRO Queued= 0 igb1: RX(0) LRO Flushed= 0 igb1: Queue(1) rdh = 119, rdt = 118 igb1: RX(1) Packets received = 3908297847 igb1: RX(1) Split Packets = 0 igb1: RX(1) Byte count = 3460826092933 igb1: RX(1) MSIX IRQ Handled = 2888114773 igb1: RX(1) LRO Queued= 0 igb1: RX(1) LRO Flushed= 0 igb1: Queue(2) rdh = 152, rdt = 151 igb1: RX(2) Packets received = 3922202264 igb1: RX(2) Split Packets = 0 igb1: RX(2) Byte count = 3503326896463 igb1: RX(2) MSIX IRQ Handled = 2886529770 igb1: RX(2) LRO Queued= 0 igb1: RX(2) LRO Flushed= 0 igb1: Queue(3) rdh = 92, rdt = 91 igb1: RX(3) Packets received = 3887004765 igb1: RX(3) Split Packets = 0 igb1: RX(3) Byte count = 3441233186193 igb1: RX(3) MSIX IRQ Handled = 2879712428 igb1: RX(3) LRO Queued= 0 igb1: RX(3) LRO Flushed= 0 igb1: LINK MSIX IRQ Handled = 10 igb1: Mbuf defrag failed = 0 igb1: Std mbuf header failed = 0 igb1: Std mbuf packet failed = 0 igb1: Driver dropped packets = 0 igb1: Driver tx dma failure in xmit = 0 Border2: igb2: Adapter hardware address = 0xffffff0004575528 igb2: CTRL = 0x18c00241 RCTL = 0x801a igb2: Packet buffer = Tx=0k Rx=0k igb2: Flow control watermarks high = 63488 low = 61988 igb2: Queue(0) tdh = 74, tdt = 74 igb2: no descriptors avail event = 3117 igb2: TX(0) MSIX IRQ Handled = 22305812305 igb2: TX(0) Packets sent = 57738555533 igb2: Queue(1) tdh = 0, tdt = 0 igb2: no descriptors avail event = 0 igb2: TX(1) MSIX IRQ Handled = 0 igb2: TX(1) Packets sent = 0 igb2: Queue(2) tdh = 0, tdt = 0 igb2: no descriptors avail event = 0 igb2: TX(2) MSIX IRQ Handled = 0 igb2: TX(2) Packets sent = 0 igb2: Queue(3) tdh = 0, tdt = 0 igb2: no descriptors avail event = 0 igb2: TX(3) MSIX IRQ Handled = 0 igb2: TX(3) Packets sent = 0 igb2: Queue(0) rdh = 246, rdt = 245 igb2: RX(0) Packets received = 13727912438 igb2: RX(0) Split Packets = 0 igb2: RX(0) Byte count = 10677902707967 igb2: RX(0) MSIX IRQ Handled = 8730210616 igb2: RX(0) LRO Queued= 0 igb2: RX(0) LRO Flushed= 0 igb2: Queue(1) rdh = 51, rdt = 50 igb2: RX(1) Packets received = 13676394291 igb2: RX(1) Split Packets = 0 igb2: RX(1) Byte count = 10622417591526 igb2: RX(1) MSIX IRQ Handled = 8706454649 igb2: RX(1) LRO Queued= 0 igb2: RX(1) LRO Flushed= 0 igb2: Queue(2) rdh = 194, rdt = 193 igb2: RX(2) Packets received = 13687518658 igb2: RX(2) Split Packets = 0 igb2: RX(2) Byte count = 10608204213317 igb2: RX(2) MSIX IRQ Handled = 8716002420 igb2: RX(2) LRO Queued= 0 igb2: RX(2) LRO Flushed= 0 igb2: Queue(3) rdh = 131, rdt = 130 igb2: RX(3) Packets received = 13660077699 igb2: RX(3) Split Packets = 0 igb2: RX(3) Byte count = 10588060857368 igb2: RX(3) MSIX IRQ Handled = 8692141405 igb2: RX(3) LRO Queued= 0 igb2: RX(3) LRO Flushed= 0 igb2: LINK MSIX IRQ Handled = 32 igb2: Mbuf defrag failed = 0 igb2: Std mbuf header failed = 0 igb2: Std mbuf packet failed = 0 igb2: Driver dropped packets = 0 Поменяли патч-корд между бриджом и border1. Ничего не изменилось :( Изменено 3 ноября, 2009 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 3 ноября, 2009 · Жалоба Первый раз пинговался 93.158.134.8, во второй - 213.180.204.8 :/ Попробовать отключить polling и TSO. И сколько установлен kern.hz? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 3 ноября, 2009 · Жалоба А чем/как вы делите трафик между бордерами и как осуществляется шейпирование при этом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 3 ноября, 2009 (изменено) · Жалоба Первый раз пинговался 93.158.134.8, во второй - 213.180.204.8 :/Попробовать отключить polling и TSO. И сколько установлен kern.hz? На бридже hz=2000, на border1=1000. Polling и не было никогда. TSO не отключено - ведь раньше то все работало... Сделали: sysctl -w dev.em.0.rx_int_delay=600 sysctl -w dev.em.0.tx_int_delay=600 sysctl -w dev.em.1.tx_int_delay=600 [sysctl -w dev.em.1.rx_int_delay=600 sysctl -w dev.em.0.rx_abs_int_delay=1000 sysctl -w dev.em.0.tx_abs_int_delay=1000 sysctl -w dev.em.1.tx_abs_int_delay=1000 sysctl -w dev.em.1.rx_abs_int_delay=1000 net.inet.ip.intr_queue_maxlen: 4096 до 100 + от абонента до внутреннего интерфейса гейта, внешнего интерфейса пинги нормальные. Вывод netstat -z -s | grep dropped 1 embryonic connection dropped 2 connections dropped by rexmit timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 4 connections dropped by keepalive 1 dropped 443 dropped due to no socket 0 dropped due to full socket buffers 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 2295 output packets dropped due to no bufs, etc. Изменено 3 ноября, 2009 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
madint Опубликовано 3 ноября, 2009 (изменено) · Жалоба попробуйте добавить в sysctl.conf dev.igb.0.enable_lro=0 dev.igb.1.enable_lro=0 dev.igb.2.enable_lro=0 Изменено 3 ноября, 2009 пользователем madint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 3 ноября, 2009 · Жалоба А чем/как вы делите трафик между бордерами и как осуществляется шейпирование при этом? Трафик делим PBRами на L3 свитчах. Шейпим через ipfw Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaLblsH Опубликовано 3 ноября, 2009 · Жалоба попробуйте добавить в sysctl.conf dev.igb.0.enable_lro=0 dev.igb.1.enable_lro=0 dev.igb.2.enable_lro=0 Не нашли такого параметра :( Максимально похожий : dev.igb.0.enable_aim: 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
madint Опубликовано 3 ноября, 2009 (изменено) · Жалоба по моему там runlevel нужен, так что работает только при загрузке из sysctl.conf вот оригинал http://lists.freebsd.org/pipermail/freebsd...une/015983.html правда там про форвардинг а не бриджинг, но большой разницы не вижу, имхо Изменено 3 ноября, 2009 пользователем madint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 3 ноября, 2009 · Жалоба Вспоминайте что делали до того, как началась проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 3 ноября, 2009 · Жалоба Выберите хост во внешней сети пророученной через border1, пропишите для него правила allow прямые и обратные в начале ipfw. И проверьте с клиентского компа есть ли задержка. Одновременно с клиентского компа пингайте внутренний интерфейс border1, и tcpdump'ом смотрите прохождение пакетов по всей трассе. Я так понимаю, что внешний ip border1 имеет src address в другом блоке от клиентских ip ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 3 ноября, 2009 (изменено) · Жалоба Выберите хост во внешней сети пророученной через border1, пропишите для него правила allow прямые и обратные в начале ipfw. И проверьте с клиентского компа есть ли задержка. Одновременно с клиентского компа пингайте внутренний интерфейс border1, и tcpdump'ом смотрите прохождение пакетов по всей трассе. Правила сделали. Внутренний интерфейс пингуется нормально, а хост с задержками. Я так понимаю, что внешний ip border1 имеет src address в другом блоке от клиентских ip ?Да, правильно понимаете. Пробовали натить абонентов через IP внешнего интерфейса - все равно такая же картина. Из того, что делали: только добавили второй border и в бридже добавили сетевуху, в которую воткнули второй border Изменено 3 ноября, 2009 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 3 ноября, 2009 · Жалоба Правила сделали. Внутренний интерфейс пингуется нормально, а хост с задержками. Теперь пингуйте первый хоп от border1 у аплинка. Да, правильно понимаете. Пробовали натить абонентов через IP внешнего интерфейса - все равно такая же картина. Из того, что делали: только добавили второй border и в бридже добавили сетевуху, в которую воткнули второй border Что говорит traceroute ? Да, правильно понимаете. Пробовали натить абонентов через IP внешнего интерфейса - все равно такая же картина. Из того, что делали: только добавили второй border и в бридже добавили сетевуху, в которую воткнули второй border Что с роутингом ? BGP ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 3 ноября, 2009 (изменено) · Жалоба Первый хоп после border1 от клиента пингуется отлично. Трассировка от клиента traceroute ya.ru traceroute to ya.ru (77.88.21.8), 30 hops max, 60 byte packets 1 10.1.2.254 (10.1.2.254) 1.788 ms 2.686 ms 3.561 ms 2 внутр. IP_border1 (внутр. IP_border1) 0.427 ms 0.492 ms 0.574 ms 3 IP_провайдера (IP_провайдера) 2.895 ms 1.872 ms 1.983 ms 4 msk-m9-gw1-bb0.artcoms.net (80.244.224.161) 3.010 ms 3.927 ms 3.779 ms 5 ix1-m10.yandex.net (193.232.246.93) 4.988 ms 4.976 ms 4.937 ms 6 hummer-vlan602.yandex.net (77.88.16.124) 4.740 ms 4.676 ms 4.627 ms 7 ya.ru (77.88.21.8) 32.203 ms 5.848 ms 72.736 ms Трассировка с border1 traceroute 77.88.21.8 traceroute to 77.88.21.8 (77.88.21.8), 64 hops max, 40 byte packets 1 IP_провайдера (IP_провайдера) 2.410 ms 1.710 ms 2.083 ms 2 msk-m9-gw1-bb0.artcoms.net (80.244.224.161) 2.280 ms 3.082 ms 3.584 ms 3 ix1-m10.yandex.net (193.232.246.93) 3.296 ms 3.272 ms 3.968 ms 4 hummer-vlan602.yandex.net (77.88.16.124) 4.309 ms 4.162 ms 4.484 ms 5 ya.ru (77.88.21.8) 5.252 ms 4.376 ms 4.941 ms Да, BGP . Мы анонсируем свою сеть провайдеру и получаем от него dafault_router Изменено 3 ноября, 2009 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 3 ноября, 2009 · Жалоба Подозреваю, что нужно разбираться с роутингом. На первой трассе видно что бридж и роутер пропускают пакеты нормально в обе стороны и всплесков нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 3 ноября, 2009 (изменено) · Жалоба Подозреваю, что нужно разбираться с роутингом. На первой трассе видно что бридж и роутер пропускают пакеты нормально в обе стороны и всплесков нет.Пинговали снаружи - картина такая же: адрес прова пингуется отлично, а наши (незашейпенные, но за бинатом и бриджем) так же как и изнутри, с задержками.Вот трассировка до абонента снаружи: 1 3 ms 1 ms 1 ms 188.124.232.1 2 * * * Превышен интервал ожидания для запроса 3 * * * Превышен интервал ожидания для запроса 4 3 ms 2 ms 2 ms m9-gw2-port-channel10-12.msk.anders.ru [81.91.177.81] 5 4 ms 4 ms 3 ms m9-gw4-te4-1.msk.anders.ru [81.91.177.250] 6 15 ms 24 ms 5 ms 89.20.133.137 7 4 ms 3 ms 4 ms 89.20.133.94 8 * * * Превышен интервал ожидания для запроса 9 21ms 12 ms 8 ms IP_абонента 10 9 ms 8 ms 10 ms IP_абонента 11 7 ms 7 ms 7 ms IP_абонента А вот трассировка до IP_border1 (IP прова) снаружи: 1 1 ms 1 ms <1 ms 188.124.232.1 2 * * * Превышен интервал ожидания для запроса 3 * * 2 ms khim-rs1-gi1-0-5.msk.anders.ru [81.91.178.69] 4 3 ms 3 ms 3 ms m9-gw2-port-channel10-12.msk.anders.ru [81.91.177.81] 5 3 ms 3 ms 4 ms msk-ix-m9-1.artcoms.net [193.232.244.141] 6 3 ms 3 ms 3 ms msk-rti-gw2-bb0.artcoms.net [80.244.224.163] 7 5 ms 5 ms 5 ms IP_border1 Изменено 3 ноября, 2009 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 3 ноября, 2009 · Жалоба Эти два трейса не показатель, обратите внимание что там трафик бегает по разным каналам. Как уже было сказано - с роутингом надо разбираться, с бгп в частности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 3 ноября, 2009 · Жалоба Эти два трейса не показатель, обратите внимание что там трафик бегает по разным каналам.Как уже было сказано - с роутингом надо разбираться, с бгп в частности. а что с ним ещё может быть, если принимается только дефолт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 3 ноября, 2009 · Жалоба Эти два трейса не показатель, обратите внимание что там трафик бегает по разным каналам.Как уже было сказано - с роутингом надо разбираться, с бгп в частности. а что с ним ещё может быть, если принимается только дефолт? Не совпадает прямой и обратный роутинг для разных блоков адресов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 3 ноября, 2009 (изменено) · Жалоба Не совпадает прямой и обратный роутинг для разных блоков адресов.Так анонсируется один блок адресов. Весь трафик возвращается через тот же бордер, через который вышел.Да - туда и обратно трассировка идёт разными путями, но как это может вносить такие задержки во время прохождения пакетов? Плюс это всё как-то зависит от потока - задержки начинаются при приближении входящего трафика к 160 Мегабит/с. При небольших значениях трафика - задержек нет. Изменено 3 ноября, 2009 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 4 ноября, 2009 · Жалоба net.inet.ip.intr_queue_maxlen=4096 уменьшить до 100 net.inet.ip.dummynet.hash_size=65536 уменьшить до 1024 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 4 ноября, 2009 · Жалоба А как у вас в этой двухбордерной конструкции реализован нат? Как этот нат на двух бордерах синхронизируется, учитывая что трафик может вылетать с бордера 1 а прилетать в бордер 2 и наоборот? Не тут ли случем собака порылась? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 4 ноября, 2009 · Жалоба net.inet.ip.intr_queue_maxlen=4096 уменьшить до 100 net.inet.ip.dummynet.hash_size=65536 уменьшить до 1024 Думаете дело в шейпере?Так в это же время он через igb0-igb2 в сторону border2 шейпит без проблем 400-500 Мегабит/с. + мы выводили ip источника и назначения из dummynet запихивая их в самый верх правил. Завтра попробую. А заодно проверю вообще без бриджа в этом направлении. А как у вас в этой двухбордерной конструкции реализован нат? Как этот нат на двух бордерах синхронизируется, учитывая что трафик может вылетать с бордера 1 а прилетать в бордер 2 и наоборот? Не тут ли случем собака порылась?Каждый анонсит свою сеть, поэтому всё, что вышло через 1, через него и возвращается.При отказе одного из каналов эта сеть анонсится через второй, а скрипт подменяет pbr на свичах. по моему там runlevel нужен, так что работает только при загрузке из sysctl.confвот оригинал http://lists.freebsd.org/pipermail/freebsd...une/015983.html правда там про форвардинг а не бриджинг, но большой разницы не вижу, имхо lro тоже завтра попробуем отключить.хотя тоже не думаю, что дело в этом, т.к. через igb0-igb2 летит поток гораздо больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 4 ноября, 2009 · Жалоба Там еще какой-то глюк был в igb(4) который лечился выклучением txcsum/rxcsum. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 4 ноября, 2009 · Жалоба Там еще какой-то глюк был в igb(4) который лечился выклучением txcsum/rxcsum.Спасибо - буду смотреть/пробовать. Результаты завтра выложу. Есть ещё мысль разнести - сделать в одном системнике bridge0=igb0+igb1 и bridge1=igb2+igb3 - может, так виднее будет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 5 ноября, 2009 · Жалоба kapa, а как вы будете обьединять в бридже две сетевухи в одну? Вопрос без подвоха, правда интересует - бриджи я ещё никогда не делал, поэтому и интересуюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...