azhur Опубликовано 11 мая, 2022 · Жалоба Есть нестандартная ситуация: один особенный vlan в сети, который терминируется на отдельном устройстве, не умеющем dhcp relay. DHCP сервер есть, и он находится за этим "неумехой". Нужно как-то всё-таки сделать DHCP для этого vlan-а через этот DHCP сервер (принципиально, что нужно именно через него, и он находится в другой "юрисдикции", через другие части моей сети недоступен). Возникла вот такая идея: этот vlan проходит транзитом через один L3-свитч от Циско, что если на нем сделать отдельный vrf, в котором сделать единственный SVI для этого vlan-а, на котором и настроить DHCP relay, плюс единственный дефолтный маршрут, ведущий через этот же интерфейс к не умеющему релей шлюзу. В такой схеме DHCP-запрос в теории релеится далее через тот же интерфейс, через который был получен первоначальный запрос. Жизнеспособна ли такая схема хотя бы в теории, может у кого-то были попытки реализовать что-то подобное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 11 мая, 2022 · Жалоба ЕМНИП можно даже без VRF, через лупбек и его включение в VLAN как ip unnumbered, если ваша Cisco такое умеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 11 мая, 2022 · Жалоба В 11.05.2022 в 16:55, jffulcrum сказал: через лупбек и его включение в VLAN как ip unnumbered А без ВРФ разве удастся сделать другую-отдельную маршрутизацию для этого интерфейса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 11 мая, 2022 · Жалоба Там на loopback повесить ip и сделать статический маршрут до DHCP сервера. Клиент шлет DHCP бродскаст, DHCP relay на Cisco его ловит и через лупбек пересылает до DHCP сервера, возвращает ответ сервера. А там клиент уже с полученным IP сам ходит по L2 куда надо в пределах VLAN. Естественно PBR ограничить доступ к маршруту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 11 мая, 2022 · Жалоба 1 час назад, jffulcrum сказал: Там на loopback повесить ip и сделать статический маршрут до DHCP сервера. Клиент шлет DHCP бродскаст, DHCP relay на Cisco его ловит и через лупбек пересылает до DHCP сервера, возвращает ответ сервера. А там клиент уже с полученным IP сам ходит по L2 куда надо в пределах VLAN. Естественно PBR ограничить доступ к маршруту. с VRF проще чем с PBR по моему в смысле очевиднее конфиг, что ли Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 11 мая, 2022 · Жалоба Смотря какая железка, включение VRF по ресурсам дороже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 12 мая, 2022 · Жалоба 17 часов назад, jffulcrum сказал: Смотря какая железка, включение VRF по ресурсам дороже 12 лет назад я крепко вступил в гавно с PBR что даже записку на память себе написал https://noname.com.ua/mediawiki/index.php/Catalyst_PBR Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 мая, 2022 · Жалоба В 12.05.2022 в 11:55, sirmax сказал: https://noname.com.ua/mediawiki/index.php/Catalyst_PBR Увы, не прочитаю, ибо наши Интернеты взаимно анально огородились. Но на новых Cisco включение VRF немедленно создает проблемы с TCAM, и они, бывает что посерьезнее проблем с PBR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 12 мая, 2022 · Жалоба В 11.05.2022 в 20:35, jffulcrum сказал: Смотря какая железка, включение VRF по ресурсам дороже Основной вариант по железке на которой это пробовать сделать - C9500-48Y4C. Для него актуально? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 мая, 2022 · Жалоба @azhur Для VRF на этой железке нужен пакет лицензий Network Advantage Package. TCAM там тоже есть, и, вполне вероятно, придется изучать templates and limits. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 12 мая, 2022 · Жалоба 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 отношусь ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 14 мая, 2022 · Жалоба В 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 нормально в железе отрабатывается Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 15 мая, 2022 · Жалоба В 14.05.2022 в 14:20, snark сказал: Для 3550 это официальное заявленное поведение. Ссылку на доку с ходу не нашел, но тут сказано: Документацию же читают только в 2 случаях - "нехрен делать" или "все уже сломано" Конечно же я прощелкал клювом этот момент - но вот прошли годы а я помню свое мягко говоря удивление когда я докопался У нас тогда был зоопарк - 3550-12G, 3560G, 3750 и ME3600 по моему и на каком из них была беда я вот не могу вспомнить ( точно не на 4900M - там мы уже VRF делали Кстати что-то пропали совсем ME серия что то про них совсем ничего не слышно, а 3550 до сих пор актуально ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 15 мая, 2022 · Жалоба В 15.05.2022 в 15:03, sirmax сказал: Кстати что-то пропали совсем ME серия В ethernet сильно косячный свитч, в MPLS нормальный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...