пятница, 5 апреля 2013 г.

Флап BGP сессий на двух параллельных каналах.


Статья: "Атрибут BGP local preference" снабыла написана по причине описанной в этой заметке.

Сегодня час потратил на вот такую проблему: у клиента от меня два канала терминируются и с моей и с его стороны на одном роутере отличаются уровнями 1 и 2 (канальным и физическим) - трассы разные. На оба канала собрано по сессии iBGP



Клиент начал жаловаться на невозможность работы в связи с большими потерями. Проверка последней мили проблем не обнаружила, пакеты ICMP по 1500 байт "флудпингом" летят без потерь.


А вот BGP сессии вели себя странно:
  • Устанавливалась одна сессия, получала маршруты канал становился в работу
  • Начинала устанавливаться вторая сессия при этом трафик шел по каналу с установленной сессией 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 не справился с нагрузкой и в момент перегрузки начинал дергать сессии.

Комментариев нет:

Отправить комментарий