"Одноногий" DHCP relay - работоспособно?

[azhur]

Есть нестандартная ситуация: один особенный vlan в сети, который терминируется на отдельном устройстве, не умеющем dhcp relay. DHCP сервер есть, и он находится за этим "неумехой".

Нужно как-то всё-таки сделать DHCP для этого vlan-а через этот DHCP сервер (принципиально, что нужно именно через него, и он находится в другой "юрисдикции", через другие части моей сети недоступен).

Возникла вот такая идея: этот vlan проходит транзитом через один L3-свитч от Циско, что если на нем сделать отдельный vrf, в котором сделать единственный SVI для этого vlan-а, на котором и настроить DHCP relay, плюс единственный дефолтный маршрут, ведущий через этот же интерфейс к не умеющему релей шлюзу.

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

Жизнеспособна ли такая схема хотя бы в теории, может у кого-то были попытки реализовать что-то подобное?

 

[jffulcrum]

ЕМНИП можно даже без VRF, через лупбек и его включение в VLAN как ip unnumbered, если ваша Cisco такое умеет.

[azhur]

В 11.05.2022 в 16:55, jffulcrum сказал:

через лупбек и его включение в VLAN как ip unnumbered

А без ВРФ разве удастся сделать другую-отдельную маршрутизацию для этого интерфейса?

[jffulcrum]

Там на loopback повесить ip и сделать статический маршрут до DHCP сервера. Клиент шлет DHCP бродскаст, DHCP relay на Cisco его ловит и через лупбек пересылает до DHCP сервера, возвращает ответ сервера. А там клиент уже с полученным IP сам ходит по L2 куда надо в пределах VLAN. Естественно PBR ограничить доступ к маршруту.

[sirmax]

1 час назад, jffulcrum сказал:

Там на loopback повесить ip и сделать статический маршрут до DHCP сервера. Клиент шлет DHCP бродскаст, DHCP relay на Cisco его ловит и через лупбек пересылает до DHCP сервера, возвращает ответ сервера. А там клиент уже с полученным IP сам ходит по L2 куда надо в пределах VLAN. Естественно PBR ограничить доступ к маршруту.

с VRF проще чем с PBR по моему
в смысле очевиднее конфиг, что ли

[jffulcrum]

Смотря какая железка, включение VRF по ресурсам дороже

[sirmax]

17 часов назад, jffulcrum сказал:

Смотря какая железка, включение VRF по ресурсам дороже

12 лет назад я крепко вступил в гавно с PBR что даже записку на память себе написал
https://noname.com.ua/mediawiki/index.php/Catalyst_PBR
 

 

[jffulcrum]

В 12.05.2022 в 11:55, sirmax сказал:

https://noname.com.ua/mediawiki/index.php/Catalyst_PBR

Увы, не прочитаю, ибо наши Интернеты взаимно анально огородились. Но на новых Cisco включение VRF немедленно создает проблемы с TCAM, и они, бывает что посерьезнее проблем с PBR.

[azhur]

В 11.05.2022 в 20:35, jffulcrum сказал:

Смотря какая железка, включение VRF по ресурсам дороже

Основной вариант по железке на которой это пробовать сделать -  C9500-48Y4C. Для него актуально?

[jffulcrum]

@azhur Для VRF на этой железке нужен пакет лицензий Network Advantage Package. TCAM там тоже есть, и, вполне вероятно, придется изучать templates and limits.

[sirmax]

7 часов назад, jffulcrum сказал:

Увы, не прочитаю, ибо наши Интернеты взаимно анально огородились. Но на новых Cisco включение VRF немедленно создает проблемы с TCAM, и они, бывает что посерьезнее проблем с PBR.

В этом вопросе наши страны друг друга стоят =(

Суть вопроса что на каталисте то ли  3560 то ли 3550 (я уж забыл за давностью лет)
 

route-map PBR permit 10
 match ip address PBR_ACL
 set ip next-hop 172.16.1.1

 
Так вот в PBR_ACL нельзя было писать deny
и вместо
 

ip access-list extended PBR_ACL
 deny   ip any 192.168.0.0 0.0.255.255
 deny   ip any 172.16.0.0 0.15.255.255
 deny   ip any 10.0.0.0 0.255.255.255
 deny   ip host 193.33.хх.хх 10.0.0.0 0.255.255.255
 deny   ip host 193.33.хх.хх 10.0.0.0 0.255.255.255
 permit ip host any any

пришлось написать что то вроде (ACL длинный лишнее выкинуто, суть его "весь интернет кроме ..."
 

ip access-list extended PBR_ACL
 permit ip any 0.0.0.0 7.255.255.255
 permit ip any 8.0.0.0 1.255.255.255
 permit ip any 11.0.0.0 0.255.255.255
...
 permit ip any 192.192.0.0 0.63.255.255
 deny   ip any host 193.33.xx.xx
 deny   ip any host 193.33.xx.xx
 permit ip any 193.0.0.0 0.255.255.255
...

 

так как deny отрабатывлись на процессоре (и росли счетчики что явно указывало на процессор)
с очевидно нехорошим результатом

С тех пор я как-то осторожно к PBR отношусь )
 

[snark]

В 12.05.2022 в 20:29, sirmax сказал:

в PBR_ACL нельзя писать deny так как deny отрабатывались на процессоре

Для 3550 это официальное заявленное поведение. Ссылку на доку с ходу не нашел, но тут сказано:

 

Цитата

High CPU utilization due to the IP input process The IP input process takes care of process-switching IP packets. If the IP input process uses unusually high CPU resources, the router is process-switching a lot of IP traffic.

This can happen when you use Policy Based Routing (PBR) with deny statements in its ACL. Traffic hitting these deny statements is forwarded in the software. This is not scalable because the Catalyst 3550 Switch forwards the packets by using the hardware.

На 49хх и 6500 я ничего подобного 3550 не видел и deny нормально в железе отрабатывается

[sirmax]

В 14.05.2022 в 14:20, snark сказал:

Для 3550 это официальное заявленное поведение. Ссылку на доку с ходу не нашел, но тут сказано:

 

 

Документацию же читают только в 2 случаях - "нехрен делать" или "все уже сломано"
Конечно же я прощелкал клювом этот момент - но вот  прошли годы а я помню свое мягко говоря удивление когда я докопался 
У нас тогда был зоопарк - 3550-12G, 3560G, 3750 и ME3600 по моему
и на каком из них была беда я вот не могу вспомнить ( 
точно не на 4900M  -  там мы уже VRF делали

Кстати что-то пропали совсем ME серия что то про них совсем ничего не слышно, а 3550 до сих пор актуально )

[UglyAdmin]

В 15.05.2022 в 15:03, sirmax сказал:

Кстати что-то пропали совсем ME серия

В ethernet сильно косячный свитч, в MPLS нормальный.