2-3%% потерь - это дофига - надо бы лечить On Thu, Oct 13, 2005 at 04:11:33PM +0300, Pavel Gulchouck wrote: PG> Hi! PG> On Thu, Oct 13, 2005 at 04:49:01PM +0400, Alexandre Snarskii writes: PG> >> У меня bgp затыкается, идеи кончились - может, кто посоветует, PG> >> куда смотреть. PG> >> PG> >> Ситуация такая. PG> >> Есть канал, 10M. На одной стороне 75-я кошка, на другой - писишка PG> >> с кваггой. При попытке поднять bgp анонсы проходят очень туго, PG> >> сессия через некоторое время затыкается, и принимающая сторона PG> >> (писишка) через три минуты дропает ее по таймауту. Украинские PG> >> префиксы раза с пятого минут за 10 пролазят, fullview - никак. PG> >> При этом "rsh cisco75 sh mem" пролетает без проблем - тоже tcp, PG> >> между теми же девайсами. На пингах тоже потерь нет. После того, PG> >> как кое-как пролезли украинские анонсы, никаких нареканий к PG> >> качеству канала у клиентов нет. PG> AS> Пинг "полноразмерным" пакетом с don't fragment битом проходит ? PG> AS> На них потерь нет ? PG> Проходит. PG> Не то, чтобы совсем без потерь, но жизни bgp это настолько мешать PG> AFAIU не должно: PG> root@mig28:~>time ping -D -s 1472 -c 1000 -f 213.133.160.97 PG> PING 213.133.160.97 (213.133.160.97): 1472 data bytes PG> ............................. PG> --- 213.133.160.97 ping statistics --- PG> 1000 packets transmitted, 973 packets received, 2% packet loss PG> round-trip min/avg/max/stddev = 15.891/16.658/21.755/0.547 ms PG> real 0m2.957s PG> user 0m0.006s PG> sys 0m0.052s PG> Или 3% потерь могут так сказываться? PG> Интересно, что при пинге со стороны кошки ситуация иная: PG> Mabuka#ping 213.133.160.98 si 1500 re 1000 PG> Type escape sequence to abort. PG> Sending 1000, 1500-byte ICMP Echos to 213.133.160.98, timeout is 2 seconds: PG> [...] PG> !!!!!!!!!!!!!!!!!!!! PG> Success rate is 99 percent (999/1000), round-trip min/avg/max = 12/16/108 ms PG> Из-за чего может быть такая разница в показаниях при пинге одного PG> и того же канала с разных его сторон разными устройствами? PG> Это не результат одного замера, такие результаты стабильны. PG> >> Замена канала на другой ситуацию исправляет - между теми же PG> >> устройствами на другом vlan-е (и на другой физике) с теми же PG> >> настройками fullview вливается без проблем. PG> >> Замена кошки на писишку ситуацию тоже исправляет - между двумя PG> >> писишками fullview пролетает на ура. Замена 75-й кошки на 72-ю PG> >> ситуацию не исправляет. Пробовал уменьшить на интерфейсе mtu PG> >> до 1472 - ничего не меняется, bgp все равно затыкается. Пробовал PG> >> прописать traffic-shape для bgp на 128K - тоже улучшений нет. PG> >> Собрал tcpdump заткнувшейся сессии с обеих сторон. Дампы совпадают, PG> >> потерь и перестановки пакетов нет. PG> >> PG> >> Куда копать? PG> >> Если на другом канале работает, логично предположить, что у этого PG> >> канала есть какой-то недостаток - но какой, как его сформулировать PG> >> тому, кто предоставил канал? Или как заставить кошку работать на PG> >> этом канале? PG> AS> Чую, что проблемы с MTU, но обосновать не могу... :) PG> Установка "ip mtu 512" ситуацию не лечит. :( PG> AS> Кстати, а ospf на этом же канале работает ? PG> Не пробовал - это разные города и разные AS. PG> Btw, замена писишки на кошку ситуацию не исправляет, т.е. bgp между PG> двумя кошками тоже жить не хочет. -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Дама с @ =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message