buckethead

Ничего себе не отличается! С ISG всё работает автоматически с биллинга, как и должно быть. ISG хотя бы на port-channel может клиенту скорость по-сервисно ограничивать на asr1k без проблем, а вашей схеме я даже не знаю, как вы это делать будите, если lag соберёте. Там, кстати, есть Dynamic VRF selection, можно попробовать определённый VRF в биллинге прописать и прикрутить какую-нибудь бизнес-логику.

Там надо колхозить сложно, я бы не стал связываться. class-map type traffic match-any L4R match access-group input name WebRedirectIn match access-group output name WebRedirectOut ! class-map type traffic match-any OpenGarden match access-group output name OpenGardenOut match access-group input name OpenGardenIn ! policy-map type service L4R class type traffic L4R redirect to group Enclosure ! class type traffic default in-out drop ! ! policy-map type service OpenGarden class type traffic OpenGarden police input 5000000 937500 1875000 police output 5000000 937500 1875000 ! class type traffic default in-out drop ! ! На отдельном железе у нас он, но прикрутить не вижу проблем.

На радиус прилетает то, что в политике настроите, у меня nas-port-id прилетает, из которого RADIUS регулярками достаёт пару S-TAG/C-TAG. interface Port-channel1.3761002 encapsulation dot1Q 376 second-dot1q 1002 vrf forwarding vrf-customer-x ip address 100.127.13.1 255.255.255.0 ip helper-address 192.168.100.88 no ip redirects no ip unreachables no ip proxy-arp ip mtu 1500 ip verify unicast source reachable-via rx service-policy type control StaticCustomers ip subscriber interface end policy-map type control StaticCustomers class type control Unauth event timed-policy-expiry 1 service disconnect ! class type control always event session-start 1 authorize aaa password cisco identifier nas-port 3 set-timer Unauth 3 ! class type control always event session-restart 1 authorize aaa password cisco identifier nas-port 3 set-timer Unauth 3 ! class type control always event access-reject 1 service-policy type service name OpenGarden 2 service-policy type service name L4R 3 set-timer Unauth 3 ! !

Ничто не мешает interface session упаковать в VRF. Я так и делаю, например. А бенефитов относительно колхоза гораздо больше.

Чего-то я не очень понимаю, чем весь этот колхоз отличается от interface session в ISG?

У нас проблема с pptp и `nat inside`-интерфейсами сохраняется даже с отключенными alg полностью. На апстрим ноде перед asr сделали pbr, который трафик для паблик адресов уводит на nh, для которого нет ip nat inside на asr.

Вообще никаких проблем с сормовичем и тегами.

ASR1000 -- это серия маршрутизаторов, надо смотреть, какие ESP/RP там, чтобы сравнивать с MX полноценно.

Можно сделать по принципу -- какой первый BRAS ответит DISCOVER абоненту. Но тут одна тонкость есть: Access-Request будут слать оба BRAS, надо чтобы RADIUS/биллинг умели как-то с этим жить.

L3VPN клауды можно промежуточным L2 пайпом срастить :D

Да, понимаю о чем вы говорите. Но на данном этапе это не нужно. Еще вопрос по доп адресам у клиентов. Когда нужно доп адрес клиента (который секондари или совсем смаршрутизированная подсеть) "пристегнуть" к той же сессии, которая инициирована первичным адресом. Чтобы скорость делилась на подключение клиента, а не отдельная политика на каждую подсеть. Это возможно как-то сделать? Если совсем красиво делать, то для сессии RADIUS должен возвращать Framed-Route атрибуты, которые в железке будут выглядеть, как маршруты на основной IP-адрес сессии. Скорость будет на всех одна, можно вместо flat rate задавать ограничение посервисно. Можно использовать interface session и задать выделенный кусок сети для неё. Бенефиты всё те же. Есть совсем грязный хак -- использовать interface session и ip unnumbered на loopback-интерфейс, как вы это, скорее всего, делали по классической схеме unnumbered on SVI. Здесь есть одно жирное "но": на каждый loopback можно установить лишь одну interface session, что как бы сводит все потуги на нет. Но тут ребята, если поискать, нашли способ не прописывать unnumbered непосредственно на интерфейсе, но передавать его в качестве параметра из RADIUS, говорят, получилось добиться поведения 1-в-1, как если бы терминировали абонентов на какой-нибудь 6500.

У вас есть какие-то замечания? Открывайте тикет. Если оборудование работает исправно и удовлетворяет вашим требованиям, зачем его обновлять?

А должна быть вчерашняя что ли?

Да, конечно же зависит от веса контракта. Я писал в основном про b2c, мелких b2b. Где-то и в PE можно подключить, а кому-то и PE придётся ставить кучерявый, если сервис попросят особый. На тех же микротиках можно вполне сносно MPLS access делать.

У вас между PE и клиентом скорее всего будет самый обыкновенный L2. Коммутаторы приходят в тупую преагрегацию, она делает QinQ, который отдаётся в PE, в качестве PE для таких задач вполне подойдёт какой-нибудь коммутатор с поддержкой MPLS, они не стоят пол-ляма. Оттуда VPWS в кору до браса.

Как уже здесь прозвучало: MPLS всё доступнее и доступнее, на вендоре на букву M я бы опорную сеть, конечно, не строил, но b2b сектор с псевдопроводом в центр они закроют на ура. Плюс тут у большей половины "счастливчиков" на половине сети всякие 6500/7600, какие-то сервисы с использованием MPLS можно и на них закрыть даже на обычных 720-х.

Почему нет? Я вот в коре внедрил, магистрали пока чистое L2, но со временем подниму в VPWS/VPLS, сделаю L3+FRR. А в коре на 3.5 железках я сервисы раскидал в VRF/L3VPN, публичные хомяки сразу на бордеры в один хоп, для приватников через ядро VRF к NAT-ферме. Можно, конечно, как раньше -- PBR или вообще с костылями типа VRF-lite, но зачем, если железо адекватно умеет MPLS?

Конечно, резать всё лишнее нужно на границе сети, чтобы это не гуляло бесполезно по вашей сети.

У вас VLAN на что? На абонента? Proxy-arp не даст ходить трафику клиентов в одной сети, но разных VLAN, если VLAN общий -- резать надо на доступе. В сторону этого интерфейса скорее всего валит мультикастом этот срач, вот и счётчики растут.

После BRAS да, схему желательно l2-connected, чтобы весь трафик через BRAS ходил

Берёте оптические сплиттеры 50x50, главное -- длину волны учтите. Делите волокна, берёте коммутатор для агрегации получившихся линков (скорее всего 10-ки будут), плотность портов потребуется вдвое большая, думаю, тут объяснять не надо. Каждый входящий порт заворачиваете в свой VLAN, на этом VLAN отключаете learining. В сторону СОРМа собираете LAG, отдаёте туда все эти VLAN пачкой, tagged/untagged -- не важно. Весь профиль трафика unidirectional. Всё работает как часы. Нам хватает вот этой дряни SNR-S2970-12X.

Работает прекрасно, ничего не крэшится, интерфейсы не отваливаются. Есть, конечно, свои нюансы, где можно споткнуться, но примитивно пронатить умеет.

А что означает фраза "как обычно это циски"? На ASR честный full duplex заявлен для всех ESP (на чистом раутинге, конечно же), будет там 5G честных в каких угодно пропорциях в вопросе "исходящий-входящий". Фраза означает, что это маркетинговая цифра, как это всегда было у циски. Я не знаю, как еще можно пояснить по другому. Циска говорит 5 гбит, а ты должен понимать, что это пять в одну сторону, или 3 в одну и 2 в другую. У человека 2.5 всегда сейчас, я так понимаю это что-то около 1 туда 2.5 обратно, ему втыкать ESP5 вообще не вариант. Это не маркетинговая цифра, вы получите при двух 10G интерфейсах на ESP5 спокойно 4G на вход на один интерфейс, 1G на вход на другой и любые другие комбинации в рамках 5G. Это пройденный нами этап на ESP5, ESP10, ESP40, ESP100.

А что означает фраза "как обычно это циски"? На ASR честный full duplex заявлен для всех ESP (на чистом раутинге, конечно же), будет там 5G честных в каких угодно пропорциях в вопросе "исходящий-входящий".

СКАТ научился в qinq?