m1h

Бывают локальные стажировки. Вендоры или внутренний персонал проводят всякие мастерклассы. Обучение тоже есть, часто оно оплачивается вендором в рамках тендера. Но есть и исключения - можно активно тискать HRов и вписывать себя в план по обучению, но за это вроде как потом надо будет отрабатывать (насколько я знаю у многих так) Официально разглашать ЗП нельзя. Но у нас ЗП примерно равна или даже чуть выше чем аналогичные позиции по рынку (по моим личным наблюдениям) P.S. Ну и по сути топика: В МФ направление IT отделено от сетевой инфраструктуры, типа разные департаменты.

Да, давно руки чесались проверить один сценарий с VPNv4-RR. В общем и целом впечатления положительные.

Приветсвую господа Возможно есть люди которые не в курсе, но которым данный софт окажется полезным. Оборудование Huawei нынче довольно распростаненное, посему иметь под рукой инструмент для обучения и проверки всяческих сценариев довольно удобно. Китайцы, таки, написали свой эмулятор (...ну или открыли то что давно написали, не знаю...) Собсвенно, вот... Huawei Enterprise Network Simulation Platform Ссылка на скачивание P.S. как по мне, так для начала очень даже не плохая софтина. P.P.S если данный раздел форума не подходит, прошу модераторов перенести, либо удалить.

survivor А ликинг вы зачем используете? Почему нельзя с агрегации пустить трафик b2c абонентов в отдельных вланах, а трафик который на БРАС идти не должен, в других.[quote name='NikAlexAn' [timestamp='1355307480' post=785334] А разве нельзя обойтись без VRF-ов на ASR-е в данном случае? Так vrf'ы у ТС не на ASR а на 6509 которая Core-Switch...

А чего "некрасивого" в этой схеме? Получается что мы делим корневой свич на два виртуальных форвардинг плэйна. При наличии денег, можно и реально разделить на две железки: через одну БРАС будет видет агрегаторы, через другую интернет в лице бордера. vrf-lite это просто разделение устройства на непересекающиеся контрол и форвардинг плэйны, без организации L3VPN на множестве устройств.

Не берусь ручаться за точность перевода, но IMHO ISG не может пересылать DHCP запросы в случае когда между ISG[bRAS] и устройством клиента есть (ещё один) DHCP пересыльщик работающий на 3-м уровне. Вот в качестве такого ещё одного релея у ТС будет выступать свич агрегации. По всей видимости ISG не ожидает чо к нему придет DHCP запрос в unicast виде, а после релея он именно в unicast и распространяется +добавляются дополнительные поля типа giaddr. С DHCP релей у циски вообще все порой очень странно. Я пытался сделать на интерфейсе 2 хелпер адреса, для физического резервирования DHCP серверов. Но в этом случае запросы вообще переставали релеиться. Ничего по этому поводу нагуглить не удалось, а поддержки на ASRы мне не купили...

Брасы ничего не знают про VRFы. По одной ноге ои получают дефолт из интернета (от бордера), по другой ноге они получают сети клиентов от агрегации. На агрегации кроме b2c клиентов есть ещё что-то? Что должно ходить мимо браса сразу в бордер?

Я пробовал настраивать так: посылать CircuitID в качестве username, а сессия поднимается по unclassified IP. Судя по трейсу в сторону радиуса уходил пустой username. (Делал на IOS-XE) Upd: вот цитата в доке ISG DHCP Restrictions ISG cannot relay DHCP requests when a Layer 3 DHCP relay agent is between the ISG device and subscriber devices.

Я не совсем понимаю как у вас все построено. 1) Почему нельзя прогнать трафик с агрегации до БРАСов по L2? Вланом или через mpls vll 2) Если нужно чтобы на 6509 трафик клиентов не мог напрямую ходить в аплинк, сделайте vrf-lite. Я не понимаю зачем вы хотите распространять vrf по всей сети. У нас примерно так ходит трафик абонентов через платформу тарификации. На ядрёном свиче 2 vrf, в первом он[свич] отдает дефолт клиентам, в другом получает его от бордера. В качестве igp - OSPF. Платформа включена двумя ногами в оба vrf.

Мы не стали парится и выдаем RFC1918 адреса статически. Единственное что мне пришло тогда в голову, это писать свой dhcp сервер и привязывать его к биллингу. Но это выливалось в масштабнейшее переписывание биллинга и от идеи сразу же отказались.

По всей видимости нет... Я не нашел такого. Кроме всего прочего, в policy-map type traffic нельзя делать 2 non-default класса.

в class-map более четко определить... т.е. у вас будет два сервиса, в один попадут только ingress, в другой только egress пакеты

У нас маркетоиды однажды придумали подписки на определенные тематики (новости, соцсети, спорт, эротика etc.) на основе URL Т.е. трафик в сторону таких "тематических" урлов тарифицировался бы отдельным образом. Прислали мне три листа урлов мелким почерком, кои я несколько часов забивал. Насколько знаю, идея в коммерцию не пошла... ЗЫЖ речь про мобильный трафик

... в курсе. По результатам закрытия emergency кейса, сами хуавейцы сказали что на этих коробках >8k (на один инстанс) маршрутов держать не стоит, хотя подробностей уже не помню.

Поддержу предыдущего оратора, L3 на s9300 лучше не пробовать (это не маршрутизатор) У нас оно в свое время выступало в качестве MPLS PE, после того как в vpn одного клиента прилетело >12k маршрутов железка начала вести себя мало объяснимо (стали отваливаться l2vc) Был ещё глюк с ospf, на control plane все визуально в норме, но трафик через vlan не идет. По кейсу нам так ничего и не ответили (это правда единичный случай, но очень неприятный) Собственно у нас они используются больше как core-L2 свичи + (все-таки) L3 агрегация с VRRP на двух разнесенных коробках.