Судя по конфигу
пакеты, приходящие от клиентов, приходящие на порты связанные с VLANом LOCAL_PPPoE.Lermontova54, должны идти далеко-далеко по default-маршруту через шлюз 172.31.175.129 в управляющем VLANе на DHCP-сервер 172.31.253.178.
Вы осознанно выбрали системный-управляющий VLAN для переноса пользовательского трафика?

Где-то здесь какая-то неоднозначность.

Что такое DHCP-релей, для чего от нужен и как работает.
Нужен он для того, чтобы довести широковещательные пакеты DHCP до сервера.
Область распространения широковещательных пакетов носит название "широковещательный домен" и в практическом смысле совпадает с VLANом и имеет мало общего с понятием "IP-сеть".
Широковещательные пакеты через L2 порт на коммутаторе достигающие L3-интерфейса, указанного в строчке "config dhcp_relay add ipif " обрабатываются (скорее всего, не на аппаратном уровне) сервисом DHCP-релея (L3-коммутатором) на предмет того, что это именно DHCP-сообщение, а не что-то иное, укладываются в unicast пакет с source-адресом DHCP-релея и от уже его имени отправляются указанному DHCP-серверу.

Если широковещательный пакет может достичь DHCP-сервера без участия релея, то релей и не нужен. На DHCP-сервере нужно скофигурировать (в микрософтовской терминологии) "суперсеть" из IP-сетей с нужными Вам пулами адресов этого широковещательного домена. Аналогично - на Linux-FreeBSD-etc.

В любом случае, DHCP-серверу должен быть известны маршруты до всех "его" сетей, и из всех сетей - до DHCP-сервера.

У Вас в широковещательном домене VLANа LOCAL_PPPoE.Lermontova54 могут бегать пакеты сетей 10.0.76.1/24 и 10.128.76.1/24. Вы можете на DHCP-сервере зафиксировать привязки по MAC-адресам и отправлять ответы коммутатору. Необходим ли здесь дополнительно интерфейс DHCPrelay_if и настройки proxy_arp - не скажу

Маршрутизация клиентского трафика осуществляется тут же. Для этого подняты секондори интерфейсы на клиентском влане. Систем интерфейс и праймери на клиентском влане используются только для релея клиентского dhcp. Про неоднозначность: имелось ввиду соседние коммутаторы этого сегмента. И еще раз повторюсь: при данной схеме нет связности между клиентскими и служебными сетями.

Ещё раз повторяю, если НЕТ СВЯЗИ МЕЖДУ DHCP-сервером И КЛИЕНТАМИ, то продление времени аренды не будет происходить.
Клиенты ДОЛЖНЫ иметь доступ к DHCP-серверу, чтобы корректно продлить аренду выданного IP-адреса.

И не надо изобретать никакой ерунды с primary, secondary интерфейсами. Так никто не делает.
Чтобы не нарушать безопасность вашей служебной сети - вынестите для DHCP в отдельную подсеть и настройте маршрутизацию с клиентскими подсетями. Настройте relay на новый IP DHCP-сервака и живите спокойно.

_________________
LiveComm

Хорошо, хорошо. Не волнуйтесь только. И просто примите как факт: работает. Работает уже несколько лет. Если не верите мне, то сами соберите стенд.

Работать, может и работает, только зачем так все усложнять?
Это самое простое и безопасное решение:

К сожалению, понимания как устроена эта сеть у меня так и не сложилось, и с каждым новым комментарием запутываюсь всё больше и больше.Что у Вас скрывается за словами "сеть" и "связность"?
Зачем Вы используете дополнительную, третью, IP-сеть в клиентском VLANе для релея? Чем Вас не устраивают существовавшие до того клиентские сети?
Сколько клиентских сетей в клиентском VLANе у Вас обслуживается DHCP-сервером, и как Вы различаете из какой IP-сети пришёл запрос на выделение адреса?
Соседние коммутаторы - L2?
Какими путями распространяется DHCP-запрос (через соседние коммутаторы?) и какие пути Вы хотите использовать?

Может быть, какую-нибудь картинку нарисуете?

Я уже говорил, что при истечении половины времени лизы, клиент обязан её продлить.
Для этого он отправит ЮНИКАСТ запрос вашему DHCP-серверу, который до него НЕ ДОЙДЕТ, т.к. у вас нет маршрутизации между IP-адресом DHCP-сервера и IP-адресом клиента. Что является некорректным поведением сети.
После истечения 85% времени лизы DHCP-клиент ПОВТОРНО пытается продлить время аренды, отправив соответствующий DHCP-запрос ШИРОКОВЕЩАТЕЛЬНО. Вот тут уже сработает DHCP-relay и вашему клиенту всё таки продлят время аренды.
Но это всё костыли в работе вашей сети, потому что так оно работать не должно.
Правильно сделать так, как я описал выше.

_________________
LiveComm

Затем, чтобы DHCP мог достучаться до дополнительной сети, но не мог достучаться до клиентской для какой-то непонятной "безопасности".
Таким образом обратный пакетик от DHCP-вернется через дополнительный IP-интерфейс и будет переслан клиенту, который после получения IP-адреса никак не сможет увидеть DHCP-сервер.

_________________
LiveComm

О! Спасибо огромное.
Я смутно помнил слова из RFC о том, что DHCP-сервер перед выделением адреса должен проверить, что адрес ещё не распределён - и вопрос видимости клиентской сети от DHCP-сервера мне казался сам собой разумеющимся.