danila_ Опубликовано 22 августа, 2023 · Жалоба Приветствую! Прошу помощи в следующем вопросе: Имеем несколько десятков 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 держать включенным только одну сессию, что чревато. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
craftsman Опубликовано 22 августа, 2023 · Жалоба 3 часа назад, danila_ сказал: Проблематика: при активной только одной BGP сессии на всех OLT всё работает ок (без деления трафика, само собой), а при поднятии второй сессии на одних OLT всё так же ок, на других же начинает бешеным темпом расти счётчик "Total number of target-unknown reply packets", из-за чего DHCP пакеты от сервера дропаются. На корректно работающих OLT счётчик равен нулю. То есть ответный юникаст трафик от DHCP идет маршрутом через другой пир, и потому дропается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 22 августа, 2023 · Жалоба Сейчас собираю стенд, чтоб проверить, через какой интерфейс ответы идут Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 23 августа, 2023 · Жалоба 23 часа назад, craftsman сказал: То есть ответный юникаст трафик от DHCP идет маршрутом через другой пир, и потому дропается? Всё верно, в проблемных ситуациях трафик DHCP идёт асимметрично - запросы идут к одному пиру, ответы от сервера идут от другого пира. В этой ситуации OLT ожидает ответа с того интерфейса, на который шлёт запросы, и ответы с другого линка дропает. И такое поведение наблюдается только с DHCP пакетами, трафик клиентский пропускает без проблем; правда, он не обрабатывается, в отличие от DHCP. Есть ли возможность настроить OLT таким образом, чтоб ответы принимались независимо от входящего и исходящего интерфейсов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
craftsman Опубликовано 23 августа, 2023 · Жалоба @danila_ предполагаю что дело не в OLT, а в логике работы сети. Дискавер идет бродкастом, а DHCP сервер должен ответить юникастом в правильный интерфейс, через соответствующий BGP пир. А этого и не происходит. Или марщруты, или еще чего?! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 23 августа, 2023 (изменено) · Жалоба 32 минуты назад, craftsman сказал: Дискавер идет бродкастом Используется релей, на сервер идёт юникаст. 32 минуты назад, craftsman сказал: DHCP сервер должен ответить юникастом в правильный интерфейс У DHCP сервера есть дефолт, который смотрит в нужный VRF. Этот же VRF на транспорте присутствует и в него смотрят оба влана на разных железках транспорта, на которых бегают BGP сессии. Изменено 23 августа, 2023 пользователем danila_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 23 августа, 2023 · Жалоба Схема включения следующая: Скрытый текст Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
craftsman Опубликовано 23 августа, 2023 (изменено) · Жалоба 31 минуту назад, danila_ сказал: Используется релей, на сервер идёт юникаст. Тада нам нужно смотреть на релей. Почему он шлет пакет не в тот интерфейс, с которого пришел бродкаст. А. У нас OLT релеит?! Изменено 23 августа, 2023 пользователем craftsman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 23 августа, 2023 (изменено) · Жалоба 2 минуты назад, craftsman сказал: У нас OLT релеит?! Ага, именно; OLT выступает в роли релея. И именно OLT дропает ответы от сервера Изменено 23 августа, 2023 пользователем danila_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
craftsman Опубликовано 23 августа, 2023 · Жалоба @danila_ и я понимаю OLT, я бы тоже дропал, раз они приходят не оттуда. Так, еще раз: 5 часов назад, danila_ сказал: в проблемных ситуациях трафик DHCP идёт асимметрично - запросы идут к одному пиру, ответы от сервера идут от другого пира. В этой ситуации OLT ожидает ответа с того интерфейса, на который шлёт запросы, и ответы с другого линка дропает. то есть, трафик уже на OLT приходит неверно! Вот эту ситауцию и нужно исправлять. Где, по пути от DHCP, трафик сворачивает не в ту дырку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 23 августа, 2023 · Жалоба 28 минут назад, craftsman сказал: я бы тоже дропал, раз они приходят не оттуда Траблы с роутингом копаю, но также хочу понять, есть ли возможность отключить на OLT сопоставление интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
craftsman Опубликовано 23 августа, 2023 · Жалоба 3 минуты назад, danila_ сказал: Траблы с роутингом копаю, но также хочу понять, есть ли возможность отключить на OLT сопоставление интерфейсов. по OLT не подскажу, давно уже их демонтировали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila_ Опубликовано 29 августа, 2023 · Жалоба Проблема решена изменением роутинга. В процессе обнаружилось, что приходящие DHCP пакеты, которые OLT дропает, приходят с изменённым XID в заголовке. В стенде буду дальше копать, кто по пути меняет XID. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
