Hoax Posted October 23, 2013 Posted October 23, 2013 Добрый вечер. Если позволите, несколько вопросов на избитую тему. Администрирую небольшой провайдер. Доступ IPoE, vlan на дом, ip unnumbered. Терминация на cat 3560. Маршруты на 3560 растут, упирают TCAM'ы, стопка 3560 множится. Xотим переползти на чтото более серьезное, и в качестве замены рассматриваем 6500. sup720-3B или BLX Если я перепишу конфиг с 3560 interface Vlan43 ip unnumbered Loopback1 ip policy route-map shaper-g route-map shaper-g permit 10 match ip address 107 set ip next-hop x.x.x.x для sup720 interface Vlan43 ip unnumbered Loopback1 ip policy route-map shaper-g route-map shaper-g permit 10 match ip address 107 set ip default next-hop x.x.x.x будет оно работать? будет ли оно работать хардварно? или в MSFC3 для которого насколько я понимаю The MSFC3 can support forwarding rates up to 500Kpps И еще вопрос. Нужно ли для работы BGP, OSPF, etc приобретать лицензии? Вставить ник Quote
config Posted October 23, 2013 Posted October 23, 2013 По поводу tcam, его можно переспределить например в пользу рутинга, конечно в ущерб Mac таблицы. Но можно. Pbr вообще плохая затея, рекомендую искать другие пути решения. По поводу поддержки pbr аппаратно - вроде здесь написано. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/layer3.html Лицензий не надо, нужен соответствующий софт. И потом, чем заниматься терминацией на каталисте, и тем более стоит вопрос покупки, купите брас! Вставить ник Quote
Hoax Posted October 23, 2013 Author Posted October 23, 2013 По поводу tcam, его можно переспределить например в пользу рутинга, конечно в ущерб Mac таблицы. Но можно. Pbr вообще плохая затея, рекомендую искать другие пути решения. По поводу поддержки pbr аппаратно - вроде здесь написано. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/layer3.html Лицензий не надо, нужен соответствующий софт. И потом, чем заниматься терминацией на каталисте, и тем более стоит вопрос покупки, купите брас! Спасибо за ссылку. Насколько понимаю это The Policy Feature Card (PFC) and any Distributed Feature Cards (DFCs) provide hardware support for policy-based routing (PBR) for route-map sequences that use the match ip address, set ip next-hop, and ip default next-hop PBR keywords. значит что будет работать хадварно? DFC на линейных картах надо для этого устанавливать? PBR на 3560 проблем не вызывал. Упираемся только в TCAM'ы SDM уже выбран в сторону роутинга. Брас рассматриваем, но хочется простого пути, с минимальными переделками. Вставить ник Quote
DVM-Avgoor Posted October 23, 2013 Posted October 23, 2013 для sup720 interface Vlan43 ip unnumbered Loopback1 ip policy route-map shaper-g route-map shaper-g permit 10 match ip address 107 set ip default next-hop x.x.x.x будет оно работать? будет ли оно работать хардварно? или в MSFC3 для которого насколько я понимаю имеем sup32(pfc3b) + 6500, 12 ip policy route-map на разных интерфейсах SVI, все с set ip default next-hop, все работает в железе PFC. Карт с DFC нет. Но если у вас будет ХХХХ вланов и каждый аннамберед с PBR, то... Тут ткам конечно большой, но не резиновый. Может архитектуру решения поменять? :) Плюс насколько я помню это все не дружит с DHCP Snooping. Т.е. на аннамберед вланах точно не работает ACL и снупинг вместе (а снупинг мне нужен для опт82). Лицензии не нужны, нужно софт нормальный найти просто. Вставить ник Quote
Hoax Posted October 23, 2013 Author Posted October 23, 2013 (edited) для sup720 interface Vlan43 ip unnumbered Loopback1 ip policy route-map shaper-g route-map shaper-g permit 10 match ip address 107 set ip default next-hop x.x.x.x будет оно работать? будет ли оно работать хардварно? или в MSFC3 для которого насколько я понимаю имеем sup32(pfc3b) + 6500, 12 ip policy route-map на разных интерфейсах SVI, все с set ip default next-hop, все работает в железе PFC. Карт с DFC нет. Но если у вас будет ХХХХ вланов и каждый аннамберед с PBR, то... Тут ткам конечно большой, но не резиновый. Может архитектуру решения поменять? :) Плюс насколько я помню это все не дружит с DHCP Snooping. Т.е. на аннамберед вланах точно не работает ACL и снупинг вместе (а снупинг мне нужен для опт82). Лицензии не нужны, нужно софт нормальный найти просто. Я немножко строчек вырезал из конфига. На самом деле конфиг SVI выглядить у нас на 3560 так ip unnumbered Loopback1 ip access-group 104 in ip access-group 104 out ip helper-address x.x.x.x ip policy route-map shaper-g ip helper-address указывает на DHCP сервер. снупинг работает, по крайней мере на 3560. У нас тоже opt82. От unnumbered'а отказываться проблематично. У нас очень мало внешников, поэтому весь диапазон размазан одной сеткой по всем кошкам, в результате имеем тучу /32 которые съедают TCAM'ы. Понимаем что кривость, но сейчас решить это не можем. Другой вопрос. Из 720-3B получается 720-3BXL заменой MSFC? Edited October 23, 2013 by Hoax Вставить ник Quote
NikAlexAn Posted October 24, 2013 Posted October 24, 2013 А для чего: ip access-group 104 и ip policy route-map shaper-g ? Не проще ли использовать VRF и обычные ip route 0.0.0.0 ? У нас 720-3B и vlan на пользователя - работает. Но вот кушает она прилично. Вставить ник Quote
DVM-Avgoor Posted October 24, 2013 Posted October 24, 2013 (edited) Я немножко строчек вырезал из конфига. На самом деле конфиг SVI выглядить у нас на 3560 так ip unnumbered Loopback1 ip access-group 104 in ip access-group 104 out ip helper-address x.x.x.x ip policy route-map shaper-g ip helper-address указывает на DHCP сервер. снупинг работает, по крайней мере на 3560. У нас тоже opt82. От unnumbered'а отказываться проблематично. У нас очень мало внешников, поэтому весь диапазон размазан одной сеткой по всем кошкам, в результате имеем тучу /32 которые съедают TCAM'ы. Понимаем что кривость, но сейчас решить это не можем. Я 3560 в руках не держал, но скажу за 49хх и 65хх серии: 1. Если вы используете на одном интерфейсе и PBR и ip access-group in то у вас в ткаме будет дикая каша (правила не суммируются) и как итог - он переполняется нелинейно. Так делать нельзя! Оставьте только OUT правила и PBR. (у меня 2к ацлей и 12 пбр, если их включать вместе на in на интерфейсах ткаму сразу хана) Может быть на 3560 магия и работает там по-другому, но за 65ую я вас предупредил. 2. На 65ой не работает одновременно PBR, ACL-IN, DHCP Snooping на одном аннамберед влане, надо будет выбрать что-то одно. ACL-OUT там вообще вроде не работает, так что вариант такой - надо избавляться от PBR. В сторону VRF-lite или другого сегментирования. Но PBR на каждом интерфейсе это не архитектура, это фигня какая-то :) Другой вопрос. Из 720-3B получается 720-3BXL заменой MSFC? Нет, заменой PFC-3B на PFC-3BXL. Но зачем? SUP720-3BXL вытянет фулвью bgp спокойно, но в целях терминации вланов... хз, мне кажется там как и на всех остальных супах после 2000 SVI начнутся проблемы. Edited October 24, 2013 by DVM-Avgoor Вставить ник Quote
Дятел Posted October 24, 2013 Posted October 24, 2013 у нас на сап32 по 4К SVI, проблем нет. Вставить ник Quote
DVM-Avgoor Posted October 24, 2013 Posted October 24, 2013 у нас на сап32 по 4К SVI, проблем нет. DHCP Snooping используется? Вставить ник Quote
Дятел Posted October 24, 2013 Posted October 24, 2013 На том, где используется - 2К. Нас ждут впереди грабли? Вставить ник Quote
DVM-Avgoor Posted October 24, 2013 Posted October 24, 2013 (edited) На том, где используется - 2К. Нас ждут впереди грабли? Где-то в доках пробегало, что дхцп-снупинг заявлен на 2к записей. Я этот порог не перешагивал еще на 65ой Возможно там за гранью все отлично, может он и 4к записей может без внешней базы. Я просто не решился на риск :) Edited October 24, 2013 by DVM-Avgoor Вставить ник Quote
DVM-Avgoor Posted October 24, 2013 Posted October 24, 2013 ссылка на доку есть? Озаботился этим вопросом и не смог найти. Возможно это были доки по релизам до 12.2SX, не уверен, давно дело было. Сейчас там написано •The DHCP snooping database stores at least 8,000 bindings. Но snooping database это же внешний файл вроде? А про bindings table сейчас ничего нет. Значит ошибаюсь, и эта цифра как и 512 в ранних иосах на каталистах уже не актуальна :) Вставить ник Quote
Hoax Posted October 25, 2013 Author Posted October 25, 2013 А для чего: ip access-group 104 и ip policy route-map shaper-g ? Не проще ли использовать VRF и обычные ip route 0.0.0.0 ? У нас 720-3B и vlan на пользователя - работает. Но вот кушает она прилично. заблокированным и неизвестный MAC'ам выдается IP из определенного диапазона. В 104 ACL'ке им ограничен доступ. На все терминируемые SVI вешается одна и таже ACL 104. Роутмапом распределяется нагрузка между шейперами. Вставить ник Quote
NikAlexAn Posted October 25, 2013 Posted October 25, 2013 (edited) заблокированным и неизвестный MAC'ам выдается IP из определенного диапазона. В 104 ACL'ке им ограничен доступ. На все терминируемые SVI вешается одна и таже ACL 104. Роутмапом распределяется нагрузка между шейперами. Посмотрите в сторону vlan filter. Насчёт распределения нагрузки - про VRF тут уже упоминали. Edited October 25, 2013 by NikAlexAn Вставить ник Quote
Skylaer Posted October 29, 2013 Posted October 29, 2013 заблокированным и неизвестный MAC'ам выдается IP из определенного диапазона. В 104 ACL'ке им ограничен доступ. На все терминируемые SVI вешается одна и таже ACL 104. Роутмапом распределяется нагрузка между шейперами. Мы тоже так делали, а потом перенесли блокировку на сервисы, которые абонентам неположены :) Ну и нат для этих блоков отключен. И усе, только внутри сети. Вставить ник Quote
DVM-Avgoor Posted October 29, 2013 Posted October 29, 2013 65ая умеет VACL. Это удобно модно и молодежно :) Надо только учитывать, что VACL матчит оба направления трафика. А PBR, в принципе, на unnumbered интерфейс повешать-то не проблема, но расход ткама...? VRF решает вопросы, только для его максимально удобного использования надо в врф делать сразу все. Иначе потом костыли и лейкопластырь будете прикладывать к шеститоннику, чтобы сливать маршруты GRT<->VRF. Вставить ник Quote
Hoax Posted October 29, 2013 Author Posted October 29, 2013 65ая умеет VACL. Это удобно модно и молодежно :) Надо только учитывать, что VACL матчит оба направления трафика. А PBR, в принципе, на unnumbered интерфейс повешать-то не проблема, но расход ткама...? VRF решает вопросы, только для его максимально удобного использования надо в врф делать сразу все. Иначе потом костыли и лейкопластырь будете прикладывать к шеститоннику, чтобы сливать маршруты GRT<->VRF. А через vrf лишнего расхода tcam'ов не будет? В каждый vrf насколько я понимаю придется заливать маршруты которые должны быть доступны всем вланам? Как красиво отдать каждому влану свой дефолт и общие маршруты используя vrf? Вставить ник Quote
DVM-Avgoor Posted October 29, 2013 Posted October 29, 2013 (edited) А через vrf лишнего расхода tcam'ов не будет? В каждый vrf насколько я понимаю придется заливать маршруты которые должны быть доступны всем вланам? Как красиво отдать каждому влану свой дефолт и общие маршруты используя vrf? У вас для каждого влана свой дефолт? Для всех ХХХХ вланов? Ну это "пичаль". А если у вас всего 2-3 дефолта, то держать одинаковые таблицы в врф не проблема. Просто заносите интерфейсы в нужный врф и все. Конечно все зависит от ситуации... Если вы планируете в каждом врфе иметь 100к роутов + дефолт, это будет слегка накладно. Тогда все же к пбр лучше. Edited October 29, 2013 by DVM-Avgoor Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.