Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

BGP: Запрет принятия и обработки входящих Community, BGP Notification Update Error

Раздел: BGP
Добрый день, коллеги! Вчера столкнулись со следующей интересной проблемой.
Мы - ISP, c 2 Uplink. Вчера на графиках утилизации канала заметили резкое проседание со стороны одного из аплинков.
Иду на BRASS смотрю
#sh bgp summary
и вижу, что количество маршрутов, вместо традиционных для Full View > 600К, всего 200К и время BGP сессии менее одной минуты.
Наблюдаю дальше, вижу, что время сессии доходит до 01-30 sec, количество маршрутов около 566K как вдруг - Closed!
Далее вижу в логах информацию

Jul 14 20:15:45: [0130]: %BGP-6-INFO: DOWN - Notification sent
Jul 14 20:15:45: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=10729

Вспоминаю курс ROUTE, включаю debug bgp neighbor message для данного соседа и вижу:

Jul 14 20:26:12: [0130]: %BGP-7-SESSION: state changed from Established to Closing
Jul 14 20:26:12: [0130]: %BGP-6-INFO: DOWN - Notification sent
Jul 14 20:26:12: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=11109
Jul 14 20:26:12: [0130]: %BGP-7-MESSAGE: keepalive restart 87.229.186.73 now=3805935 expiry=3865935 spoke=38
Jul 14 20:26:12: [0130]: %BGP-7-SESSION: tate Closing, scheduled for reset due to BGP init, flag 1, already in closeQ 0
Jul 14 20:26:18: [0130]: %BGP-7-SESSION: completed reset for afindex 0
Jul 14 20:26:18: [0130]: %BGP-7-SESSION: state changed from Closing to Idle

Не сильно информативно, но за что зацепиться в принципе есть, а именно за строчку: NOTIFICATION: 3/5 (update: attribute length error)
Получается, что-то из присылаемых Update от магистрала определенно не нравится нашему роутеру и он закрывает bgp сессию.
Решаюсь на отчаянный шаг и пробую сделать debug bgp neighbor update in, после чего вижу много-много-много строк, среди которых улавливаю:

Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv UPDATE - Prefix 194.XXX.1XX.0/24 byte-cnt 4 mask len 24
Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv UPDATE, 3540 bytes
Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv too many community -- 3500 bytes
Jul 14 21:22:49: [0130]: %BGP-6-INFO: DOWN - Notification sent
Jul 14 21:22:49: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=10791

Ага, вот и виновник ситуации. Иду на LG данного Магистрала смотрю эту сеть и вижу, что с точки зрения LG данная сеть, доступна через 2 пиров, один best с небольшим количеством community, другой не best с очень большим количеством community, причем, что забавно, community ему туда добавляет другой магистрал (который, кстати является у нас вторым Uplink-ом), и эта тонна community видна в нашем Brass через второго нормально работающего Uplink, ну а проблемный Uplink к этой тонне добавляет еще 3 своих community и.... Видимо, наша железка отказывается это адекватно воспринимать.

Обращение в поддержку проблемного Uplink-а пока результатов не дало, сессия продолжает флапать. Я пробовал фильтровать этот префикс в Route-Map и вешать его на пира, пробовал снимать входящие community опять-же Route-Map-ом, результата никакого.

Полагаю, тут либо нашему Uplink у себя через Route-Map фильтровать и срезать community для данного префикса, либо просто в нашу сторону делать:
no send community, т.к. мы по факту у себя их Community никак не обрабатываем.

Коллеги, кто сталкивался с подобным, и может подскажет какие-то варианты решения проблемы с нашей стороны? Я, к сожалению их пока не нашел.
Тэги темы:

Комментарии

  • feo_sobolev написал:

    Добрый день, коллеги! Вчера столкнулись со следующей интересной проблемой.
    Мы - ISP, c 2 Uplink. Вчера на графиках утилизации канала заметили резкое проседание со стороны одного из аплинков.
    Иду на BRASS смотрю
    #sh bgp summary
    и вижу, что количество маршрутов, вместо традиционных для Full View > 600К, всего 200К и время BGP сессии менее одной минуты.
    Наблюдаю дальше, вижу, что время сессии доходит до 01-30 sec, количество маршрутов около 566K как вдруг - Closed!
    Далее вижу в логах информацию

    Jul 14 20:15:45: [0130]: %BGP-6-INFO: DOWN - Notification sent
    Jul 14 20:15:45: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=10729

    Вспоминаю курс ROUTE, включаю debug bgp neighbor message для данного соседа и вижу:

    Jul 14 20:26:12: [0130]: %BGP-7-SESSION: state changed from Established to Closing
    Jul 14 20:26:12: [0130]: %BGP-6-INFO: DOWN - Notification sent
    Jul 14 20:26:12: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=11109
    Jul 14 20:26:12: [0130]: %BGP-7-MESSAGE: keepalive restart 87.229.186.73 now=3805935 expiry=3865935 spoke=38
    Jul 14 20:26:12: [0130]: %BGP-7-SESSION: tate Closing, scheduled for reset due to BGP init, flag 1, already in closeQ 0
    Jul 14 20:26:18: [0130]: %BGP-7-SESSION: completed reset for afindex 0
    Jul 14 20:26:18: [0130]: %BGP-7-SESSION: state changed from Closing to Idle

    Не сильно информативно, но за что зацепиться в принципе есть, а именно за строчку: NOTIFICATION: 3/5 (update: attribute length error)
    Получается, что-то из присылаемых Update от магистрала определенно не нравится нашему роутеру и он закрывает bgp сессию.
    Решаюсь на отчаянный шаг и пробую сделать debug bgp neighbor update in, после чего вижу много-много-много строк, среди которых улавливаю:

    Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv UPDATE - Prefix 194.XXX.1XX.0/24 byte-cnt 4 mask len 24
    Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv UPDATE, 3540 bytes
    Jul 14 21:22:49: [0130]: %BGP-7-UPDATE: rcv too many community -- 3500 bytes
    Jul 14 21:22:49: [0130]: %BGP-6-INFO: DOWN - Notification sent
    Jul 14 21:22:49: [0130]: %BGP-6-INFO: send NOTIFICATION: 3/5 (update: attribute length error) with 3504 byte data. mxReadMs=10791

    Ага, вот и виновник ситуации. Иду на LG данного Магистрала смотрю эту сеть и вижу, что с точки зрения LG данная сеть, доступна через 2 пиров, один best с небольшим количеством community, другой не best с очень большим количеством community, причем, что забавно, community ему туда добавляет другой магистрал (который, кстати является у нас вторым Uplink-ом), и эта тонна community видна в нашем Brass через второго нормально работающего Uplink, ну а проблемный Uplink к этой тонне добавляет еще 3 своих community и.... Видимо, наша железка отказывается это адекватно воспринимать.

    Обращение в поддержку проблемного Uplink-а пока результатов не дало, сессия продолжает флапать. Я пробовал фильтровать этот префикс в Route-Map и вешать его на пира, пробовал снимать входящие community опять-же Route-Map-ом, результата никакого.

    Полагаю, тут либо нашему Uplink у себя через Route-Map фильтровать и срезать community для данного префикса, либо просто в нашу сторону делать:
    no send community, т.к. мы по факту у себя их Community никак не обрабатываем.

    Коллеги, кто сталкивался с подобным, и может подскажет какие-то варианты решения проблемы с нашей стороны? Я, к сожалению их пока не нашел.

    У джуна это так: http://www.juniper.net/documentation/en_US/junos15.1/topics/example/policy-community-remove.html
    Может у циски можно что-то подобное?
  • glazgoo написал:


    У джуна это так: http://www.juniper.net/documentation/en_US/junos15.1/topics/example/policy-community-remove.html
    Может у циски можно что-то подобное?

    Пикантности добавляет тот факт, что и у нас не Cisco.
    У нас стоит Ericsson SE100.
    Но, cli и принцип работы у него, с Cisco ну очень схож :)

  • Пробежался по мануалу Джуна, насколько я понял, это аналог Route-Map, в Cisco/Ericsson так-же можно вешать Route-Map на присылаемые от соседа префиксы (где сосед шлет Community) и этим Route-Map эти Community снимать, или удалять.
    Однако, суть проблемы в том, что, Update с большим количеством community попадает на роутер, после чего, роутер принимает решение - закрыть сессию, из-за длинного атрибута.
    Более того, даже если поставить на этого соседа Route-Map в котором мы полностью запрещаем прием любых префиксов от соседа. То есть, не добавляем в таблицу BGP ничего, сосед все-равно будет слать нам Update со своей таблицы, и пришлет нам этот префикс с "тучей community" и наш роутер порвет с ним сессию.
  • В общем, со слов тех.поддержки Uplink злые Болгары, прислали префикс с анонсом более 1000 community.
    Таким образом, наш Ericsson от этого дела уходил в диссонанс. По словам специалистов Uplink-а, другие операторы находящиеся с нами в одном bgp-group подобных пробелм не испытывали (используют Cisco и Juniper). Вероятно проблема с Ericssona, хотя тут смотря как смотреть и как судить :)
    Очень похоже, что вендор делает у себя, нечто вроде software-inbound-configuration по дефолту. Как у Cisco, правда ничего подобного в конфигурации не нашел и как отключить тоже не нашел.
    Сейчас, проблема решилась тем, что OrigIn AS перестали анонсить префиксы.
    Хотя, другой Uplink с этой AS commuity отфильтровывал.
Войдите или Зарегистрируйтесь чтобы комментировать.