iostream

Добрый день! Насколько я пониманию работу 4500 платформы с dot1q, то в такой конфигурации работать будет следующее: Порты 1/4 и 1/5 принимают тегированный трафик, на SVI же может уходить только "нетегированный" (cisco снимает тег с фрейма, перед тем как подавать его на SVI) Поэтому они и не будут работать в конфигурации private-vlan trunk + SVI на любой из вланов в транке. Но функционал private vlan они обеспечивать будут - собственно это по вашему описанию мы и видим у Вас. Выхода два - SVI "уходит" на другую железку, но тогда теряется суть Private Vlan, либо подаете трафик, которому нужен SVI в виде native. Ну и третий вариант - искать еще какое-то обходное решение - VACL все должен работать с IP-трафиком. Обновите IOS - может не хватает каких=то features, хотя у меня VACL работал "из коробки" с IP ( но у меня была ME4924:))

Все правильно писали - надо бы Selective Q-in-Q делать, да 3550 такое не умеют. Поэтому на существующем может быть только IP Unnumbered. Еще не забывайте, что все это Вам с биллингом состыковать надо ;) Вообще странно - как сеть все еще работает если "циска при 100 vlan" падает? Какой-то непорядок, явно:)

Вам только одна дорога - в Cisco TAC :) *Mar 17 15:18:28.925: %CPPHA-3-CDMDONE: F0: cpp_ha: CPP 0 microcode crashdump creation completed Берите это и прикладывайте к кейсу. А что там - проблема с роммоном и поддержкой hot/standby, или с конфигурацией, или баг IOS - только они Вам и скажут. А здесь, к сожалению, не околачиваются Cisco TAC спецы :) Странно, что никто этого Вам еще не сказал)

Я не эксперт в процессорах, но мое ИМХО на роль шейпера/бордера ( он же у вас BRAS, как я понимаю) надо ставить какую-нибудь железку, которая может практически хардварно это делать все, а не через проц гонять. То что Вы описываете сейчас (наращивать количество ядер или частоту), мне видится как не очень гибкое и масштабируемое решение. А сколько у Вас трафика в ЧНН?

А у вас какая версия? Насколько стабильно работает? Работает стабильно (PPPoE). NAT глючит иногда, но в целом все ок и без крашей.

Обновитесь до 03.13.04 и думаю проблемы Вас покинут. Багов приводящих к крашам ASR ну очень много. Думаю поэтому стоит пойти легим путем и обновиться. Тем более все равно раз в месяц железку ребутаете. А так конечно правильно было бы создать кейс в ТАС, но я думаю они первым делом попросят вывод sh tech и дамп краша, а вторым делом - попросят обновиться ;)))

Вообщем "эпопея" у меня продолжается :-) При честном CGN с NetFlow v9 ASR1k отдает всего два IP адреса, что логично (Inside Local & Outside Local). Но мне все мало и уже нужно по требованиям безопасности - 3 IP адреса в логировании трансляции (Inside Local & Insdie Global + Outside Global). Я так понял, что при CGN нормально "слогировать" все 3 IP адреса в трансляции можно только при использовании Syslog. Вопрос - кто-нибудь пользуется Syslog для записи трансляций CGN ? Если да - то как оно? Много места жрет на сервере? Как сказывается на производительности ASR1k и сервера?) Или все пользуются NetFlow в связке с CGN и как-то по-другому логируют связку "внешний" IP - "внутренний" IP с возможностью однозначной трактовки ответа на вопрос: Кто посещал сайт X с IP-адресом "внешним" во время Y ? И вообще такая "трактовка" нужна при обращении ФСБ? Обязан ли провайдер логировать все трансляции NAT или достаточно будет дать "пачку" абонентов, которые находились с одним и тем же "внешним" IP, в определенный момент времени? Я просто не нашел единого регламента, как обрабатываются эти запросы от ФСБ провайдером....

Мне кажется уже когда будет 5к абонентов за NAT - BRAS захочет "отдохнуть" )) Хотя может и ошибаюсь.. Но дебажить NAT для логирования трансляций это хардкор ИМХО :)

Да, то что циска собирает по этой команде. Но ведь, судя по представленной конфигурации, в netflow идет весь трафик - и который за NAT, и который без NAT. Так? Не секрет, что NetFlow и NAT - ресурсоемкие операции, поэтому я хотел бы их разнести по разным железкам: - Обычный Netflow мне кажется целесообразным сделать на Border'е (нашем PE роутере) - через него идет весь поток трафика ( который "натился" и "без ната"). - "ip nat translation logging" с помощью Netflow v9 сделать на BRAS, которые и занимаются CGN c PAP и BPA (на этих BRAS, так же терминируются обычные клиенты - без NAT). Если брать простой NetFlow для всех IP потоков, как Вы описали выше - будет "писаться" весь трафик (с NAT и без NAT). К этому же потеряется преимущество Block Port Allocation, который, как я понял, в случае "ip nat translation logging" снижает объем записываемых данных в значительное количество раз ( до 200, а может и больше - в зависимости от количества трансляций NAT на клиента) P.S: Netams насколько я понял не opensource решение и стоит денег. А денег нет) Нужно opensource :)

tehmeh прав - я именно логирование NAT трансляций имею ввиду. Статья хорошая - я её уже видел. Со стороны сети настроить для меня это труда не составляет (настройка сенсора элементарна). Но я не очень хорошо разбираюсь в остальной части NetFlow (настройка коллектора и т.д) - ни разу этого не делал и, соответственно, запара в этом. Самый главный вопрос для меня в этой статье - в конце : "Остаётся лишь научить коллектор понимать такие flow-потоки". И он не раскрыт :)) Как настроить коллектор и научить его понимать эти потоки - я не смог ничего найти..(

Это же простой Netflow "всего"? Я думал, что именно для NAT идет отдельный поток Netflow.. Или я ошибаюсь?

NAT реализован на Cisco ASR

Всем доброго времени суток! Возникла острая необходимость изучить и настроить логирование NAT. Если тема уже была и обсуждалась - прошу извинить - не нашел. В интернете тоже мало на эту тему дельного, поэтому решил спросить у коллег. Если ткнете носом в материалы для изучения (как настраивается и т.д) буду премного благодарен! :) Кто чем пользуется для логирования трансляций NAT? через что идет "поток" логирования - netflow? Сколько места выделять на сервере для логов? Нужен ли отдельный сервер? Какую систему ставить под сервер логирования (какие утилиты/пакеты/зависимости ставить)? Как логировать трансляции CGN - ведь там нет Outside global адресов в трансляции (и что делать тогда при запросе из ФСБ)? Вообщем вопросов у меня очень много - потому что я никогда не сталкивался с этим. Но буду очень рад научиться этому, поэтому прошу помощи!:)

Крышу может сносить от неправильных настроек, либо от проблем с потерями BPDU. Если у Вас на микротике вся топология соединяется в два Routed порта - то не стоит бояться - шторма не будет. Но тогда у вас проблема с L3 - ведь настроить одну подсеть на два Routed порта одного L3 устройства, насколько я знаю, нельзя)).

Ну 12 IOS вообще древний-древний.. У нас используется 15.0(2)SG9 - но по PBR не подскажу - этой фичей на агрегаторе не пользуемся...