danila_ Posted August 22, 2023 · Report post Приветствую! Прошу помощи в следующем вопросе: Имеем несколько десятков Huawei MA5608T, работающих по BGP. Клиенты получают адреса по DHCP через релей на OLT (+option 82), где настроен следующий профиль: Скрытый текст #display vlan service-profile profile-id 4 Profile ID: 4 Profile Name: DIST_OLTH --------------------------------------------------------------------- Parameter Committed Not Committed --------------------------------------------------------------------- Forwarding mode NotConfig - Anti-macspoofing NotConfig - Anti-ipspoofing enable - PPPoE MAC mode NotConfig - BPDU tunnel NotConfig - RIP tunnel NotConfig - VTP-CDP tunnel NotConfig - DHCP mode layer-3 standard - DHCP proxy enable - DHCP option82 enable - PITP enable - Broadcast packet policy NotConfig - Unknown multicast packet policy NotConfig - Unknown unicast packet policy NotConfig - User-bridging disable - IPoE VMAC NotConfig - PPPoE VMAC NotConfig - PPPoA VMAC NotConfig - Mismatch IGMP packet policy discard - VMAC aging mode MAC-learning - OSPF tunnel enable - Layer-3 protocol tunnel enable - MAC-address learning fabric enable - DHCPv6 mode NotConfig - DHCPv6 option enable - PPPoA MAC mode NotConfig - Anti-IPv6spoofing enable - IPv6 DAD proxy disable - Bind route and ND disable - NS-reply function disable - ARP-reply function disable - DHCP relay-interface relay-agent NotConfig - Unknown multicast policy fabric forward - RIPng tunnel disable - ARP-unicast function disable - ARP-unicast unknown-policy forward - NS-unicast function disable - NS-unicast unknown-policy forward - IGMP user max VLAN tag number unaware - Router-Redirect reverse enable - MAC-authen DHCP trigger enable - MAC-authen DHCPv6 trigger enable - Arp-detect max-user-count enable - --------------------------------------------------------------------- Binding VLAN list : 1018 --------------------------------------------------------------------- На OLT подняты по две BGP сессии с железками транспорта. На транспорте нисходящий трафик делится на две части (по подсетям) и трафик к клиентам в одних подсетях идёт через один BGP линк, к другим подсетям - через второй. Проблематика: при активной только одной BGP сессии на всех OLT всё работает ок (без деления трафика, само собой), а при поднятии второй сессии на одних OLT всё так же ок, на других же начинает бешеным темпом расти счётчик "Total number of target-unknown reply packets", из-за чего DHCP пакеты от сервера дропаются. На корректно работающих OLT счётчик равен нулю. Скрытый текст #display dhcp l3 statistics ----------------Display layer-3 DHCP statistics---------------- Total number of DHCP DISCOVER : 48061 Total number of DHCP OFFER : 5444 Total number of DHCP REQUEST : 7221 Total number of DHCP DECLINE : 0 Total number of DHCP ACK : 2712 Total number of DHCP NAK : 0 Total number of DHCP RELEASE : 1 Total number of DHCP INFORM : 26 Total number of DHCP FORCERENEW : 0 Total number of proxy DHCP ACK send : 1613 Total number of proxy DHCP RELEASE send : 256 Total number of MAC address conflict DHCP packets : 0 Total number of target-unknown reply packets : 6140 Total packets with untrusted option82 : 0 Total packets exceed the maximum size after appending option82 : 0 Total packets exceed the maximum option82 size after appending option82 : 0 Total number of User DHCPDISCOVER/DHCPREQUEST Giaddr is not '0' packets : 0 Транспорт анонсирует в сторону OLT только дефолт, на OLT выставлены BGP preferred-value в сторону пиров. При этом, если один пир отключен, а на работающем preferred-value выставлен больший, то при включении второй сессии NH не меняется, трафик от OLT идёт тем же маршрутом, а с адресами беда начинается. Конфиг OLT, за исключением адресов, идентичен, настройки на транспорте одинаковы для всех OLT. Снифер показал, что при работе как одного, так и двух сессий DHCP пакеты до OLT приходят корректно, состав пакетов идентичен. Прошивка на всех OLT MA5600V800R018C10, Patch SPH207. Однажды на одной OLT это вылечилось ребутом, на остальных прблемных всё стабильно нехорошо. Собсна, вопрос: как победить эту бяку? Сталкивался кто-либо с подобной проблемой? Необходима корректная работа при обеих включенных сессиях (а позже их станет больше), а сейчас приходится на проблемных OLT держать включенным только одну сессию, что чревато. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
craftsman Posted August 22, 2023 · Report post 3 часа назад, danila_ сказал: Проблематика: при активной только одной BGP сессии на всех OLT всё работает ок (без деления трафика, само собой), а при поднятии второй сессии на одних OLT всё так же ок, на других же начинает бешеным темпом расти счётчик "Total number of target-unknown reply packets", из-за чего DHCP пакеты от сервера дропаются. На корректно работающих OLT счётчик равен нулю. То есть ответный юникаст трафик от DHCP идет маршрутом через другой пир, и потому дропается? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 22, 2023 · Report post Сейчас собираю стенд, чтоб проверить, через какой интерфейс ответы идут Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 23, 2023 · Report post 23 часа назад, craftsman сказал: То есть ответный юникаст трафик от DHCP идет маршрутом через другой пир, и потому дропается? Всё верно, в проблемных ситуациях трафик DHCP идёт асимметрично - запросы идут к одному пиру, ответы от сервера идут от другого пира. В этой ситуации OLT ожидает ответа с того интерфейса, на который шлёт запросы, и ответы с другого линка дропает. И такое поведение наблюдается только с DHCP пакетами, трафик клиентский пропускает без проблем; правда, он не обрабатывается, в отличие от DHCP. Есть ли возможность настроить OLT таким образом, чтоб ответы принимались независимо от входящего и исходящего интерфейсов? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
craftsman Posted August 23, 2023 · Report post @danila_ предполагаю что дело не в OLT, а в логике работы сети. Дискавер идет бродкастом, а DHCP сервер должен ответить юникастом в правильный интерфейс, через соответствующий BGP пир. А этого и не происходит. Или марщруты, или еще чего?! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 23, 2023 (edited) · Report post 32 минуты назад, craftsman сказал: Дискавер идет бродкастом Используется релей, на сервер идёт юникаст. 32 минуты назад, craftsman сказал: DHCP сервер должен ответить юникастом в правильный интерфейс У DHCP сервера есть дефолт, который смотрит в нужный VRF. Этот же VRF на транспорте присутствует и в него смотрят оба влана на разных железках транспорта, на которых бегают BGP сессии. Edited August 23, 2023 by danila_ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 23, 2023 · Report post Схема включения следующая: Скрытый текст Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
craftsman Posted August 23, 2023 (edited) · Report post 31 минуту назад, danila_ сказал: Используется релей, на сервер идёт юникаст. Тада нам нужно смотреть на релей. Почему он шлет пакет не в тот интерфейс, с которого пришел бродкаст. А. У нас OLT релеит?! Edited August 23, 2023 by craftsman Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 23, 2023 (edited) · Report post 2 минуты назад, craftsman сказал: У нас OLT релеит?! Ага, именно; OLT выступает в роли релея. И именно OLT дропает ответы от сервера Edited August 23, 2023 by danila_ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
craftsman Posted August 23, 2023 · Report post @danila_ и я понимаю OLT, я бы тоже дропал, раз они приходят не оттуда. Так, еще раз: 5 часов назад, danila_ сказал: в проблемных ситуациях трафик DHCP идёт асимметрично - запросы идут к одному пиру, ответы от сервера идут от другого пира. В этой ситуации OLT ожидает ответа с того интерфейса, на который шлёт запросы, и ответы с другого линка дропает. то есть, трафик уже на OLT приходит неверно! Вот эту ситауцию и нужно исправлять. Где, по пути от DHCP, трафик сворачивает не в ту дырку? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 23, 2023 · Report post 28 минут назад, craftsman сказал: я бы тоже дропал, раз они приходят не оттуда Траблы с роутингом копаю, но также хочу понять, есть ли возможность отключить на OLT сопоставление интерфейсов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
craftsman Posted August 23, 2023 · Report post 3 минуты назад, danila_ сказал: Траблы с роутингом копаю, но также хочу понять, есть ли возможность отключить на OLT сопоставление интерфейсов. по OLT не подскажу, давно уже их демонтировали. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
danila_ Posted August 29, 2023 · Report post Проблема решена изменением роутинга. В процессе обнаружилось, что приходящие DHCP пакеты, которые OLT дропает, приходят с изменённым XID в заголовке. В стенде буду дальше копать, кто по пути меняет XID. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
