Статья: "Атрибут BGP local preference" снабыла написана по причине описанной в этой заметке.
Сегодня час потратил на вот такую проблему: у клиента от меня два канала терминируются и с моей и с его стороны на одном роутере отличаются уровнями 1 и 2 (канальным и физическим) - трассы разные. На оба канала собрано по сессии iBGP
Клиент начал жаловаться на невозможность работы в связи с большими потерями. Проверка последней мили проблем не обнаружила, пакеты ICMP по 1500 байт "флудпингом" летят без потерь.
А вот BGP сессии вели себя странно:
- Устанавливалась одна сессия, получала маршруты канал становился в работу
- Начинала устанавливаться вторая сессия при этом трафик шел по каналу с установленной сессией BGP
- Как только устанавливалась вторая сессия, первая отваливалась и клиент получал кратковременный обрыв трафика на то время, пока его роутер переходил на второй канал
- Отвалившаяся сессия поднималась повторно и процесс повторялся
В логах было замечено:
639853 2013/03/13 10:21:37.65 EET WARNING: BGP #2011 vprn85 Peer 39: 192.168.4.2 "VR 39: Group GTU-PE-routers: Peer 192.168.4.2: remote end closed connection" 639852 2013/03/13 10:21:37.55 EET WARNING: BGP #2005 vprn85 Peer 39: 192.168.4.2 "VR 39: Group GTU-PE-routers: Peer 192.168.4.2: sending notification: code
HOLDTIME subcode UNSPECIFIED" 639851 2013/03/13 10:21:37.55 EET WARNING: BGP #2002 vprn85 Peer 39: 192.168.4.2 "VR 39: Group GTU-PE-routers: Peer 192.168.4.2: moved from higher state
ESTABLISHED to lower state IDLE due to event HOLDTIME"
Первой мыслью было что роутер клиента сходит с ума (кстати в итоге так и оказалось но причина была в другом :) ) по причине равнозначности двух каналов по метрике и сбрасывает "лишнюю" сессию. Поэтому я для начала поигрался с local-preference, результата это естественно не дало, а дало повод задуматься: "WTF&! О.о"
Затем приблизительно на пару недель работа ушла в другое русло и стало не до этого, а за эти две недели у меня образовалась cisco 1841, которая была настроена и отвезена к клиенту. Cisco показала себя хорошо, трафик гнала и сессии держала.
А вот клиентским роутером оказался В-link dir825 на котором была собрана Квагга, а для того чтоб малыш справился и не перегружался ему отключили блок WiFi.
Вывод, по какой-то причине D-link не справился с нагрузкой и в момент перегрузки начинал дергать сессии.
Данное оборудование подлежит обязательной сертификации
ОтветитьУдалитьhttp://www.rospromtest.ru/content.php?id=27