waspagv

Итого, после многих экспериментов удалось установить следующее. Нужно определить dhcp ipv6 сервер без пула: dhcp ipv6 profile PPPoE_Server server ! interface subscriber-pppoe profile PPPoE_Server ! Радиус должен передавать атрибут Delegated-IPv6-Prefix. И тогда dhcp-севрер без дополнительных настроек транслирует префикс клиенту. Одно неудобство: этот префикс не анонсируется по ospfv3 граничному маршрутизатору. Но тут выкрутились статическим роутингом.

Мы собираемся использовать ASR9k вместо имеющихся ASR1k. Какое-то время они будут работать параллельно для плавного перехода. Нужные атрибуты все заведены и без проблем выдаются брасами ASR1k клиентам. А вот у ASR9k с IOS XR идеология немного другая, поэтому 1-в-1 конфиг не переносится. В качестве билинга у нас Гидра. Еще раз уточню, что мы решили все проблемы, кроме одной. Префикс IPv6 не делегируется роутерам клиентов. Если у клиента не роутер, а Windows, то она этот префикс получает и IPv6-адрес себе назначает. Роутер же запрашивает префикс по DHCP. Брас ASR1k ему выдает благодаря тому, что сам выступает в роли DHCP-сервера (конфиг выше). А ASR9k в роли DHCP этого не может, потому что я не умею объяснить ему вынимать этот префикс из радиуса. Рассматриваю вариант создания standalone dhcp-сервера на базе freeradius, а ASR9k сделать dhcp relay. Но как-то длинно. Может, есть короче путь, который я не вижу.

Приветствую, коллеги! Ситуация: клиенты подключатся по pppoe. Желающие используют dual-stack и ipv6. В текущей конфигурации на ASR1k для делегирования ipv6-префикса используется следующая схема. В виртуальном шаблоне указан dhcp-сервер: interface Virtual-Template10 ipv6 dhcp server PPPoE-Radius ... Пул определен так, чтобы префикс получать от RADIUS-сервера: ipv6 dhcp pool PPPoE-Radius prefix-delegation aaa method-list IPv6_PPPoE lifetime 7200 300 dns-server 2001:4860:4860::8844 dns-server 2001:4860:4860::8888 а обращение к радиусу такое: aaa authorization configuration IPv6_PPPoE group HydRadius На роутере клиента включается опция получения префикса для делегирования по dhcpv6. Все работает. Теперь тот же функционал нужно перенести на ASR9k с IOS XR 6.4.2. Создан динамический профиль: dynamic-template type ppp PPPoE ppp authentication chap keepalive 60 3 ppp ipcp dns 1.1.1.1 8.8.8.8 vrf main ipv4 unnumbered Loopback1 ipv6 nd ra-interval 180 120 ipv6 nd ra-lifetime 3000 ipv6 nd managed-config-flag ipv6 enable политика policy-map type control subscriber PPPoE event session-start match-first class type control subscriber PPP do-until-failure 10 activate dynamic-template PPPoE ! ! event session-activate match-first class type control subscriber PPP do-until-failure 10 authenticate aaa list Hydra ! ! end-policy-map Политика присоединена к интерфейсу interface Bundle-Ether10.3000 ipv4 point-to-point ipv4 unnumbered Loopback50 ipv6 enable service-policy type control subscriber PPPoE pppoe enable bba-group group1 encapsulation ambiguous dot1q 3000 second-dot1q 2022-2999 ! pppoe bba-group group1 service selection disable ! Непонятным осталось одно: как настроить dhcp-сервер или релей, чтобы не изменяя ничего на стороне клиентов делегировать им префикс по протоколу DHCPv6. Префикс по-прежнему выдает радиус в атрибуте Delegated-IPv6-Prefix. Команды aaa authorization configuration в IOS XR нет. Прошу помощи.

До сессии дело даже не дошло. Я уже исправил этот косяк, теперь так: interface Bundle-Ether19.3333 vrf main ipv4 point-to-point ipv4 unnumbered Loopback50 arp learning disable ipsubscriber ipv4 l2-connected initiator dhcp ! encapsulation ambiguous dot1q 3333 second-dot1q 1405-1420 ! Поведение совершенно аналогично описанному: на ambiguous VLAN не работает с той же отладкой.

Проверил вариант с сервером DHCP вместо прокси. Совершенно аналогичная ошибка. Что-то у меня не так, по сравнению с теми, у которых получилось. Не могу понять, что именно.

Добрый день! Впервые пробуем ASR 9006 в качестве BNG. Настраиваю подключение по технологии IPoE. Пока не касался создания сессий, авторизации и пр. Нужно выдать клиенту адрес со стороннего DHCP-сервера. Не работает с Ambiguous VLAN interface. По порядку. DHCP Proxy настроен так: dhcp ipv4 vrf main proxy profile IPoE_DHCP profile IPoE_DHCP proxy helper-address vrf main 192.168.2.228 giaddr 192.168.2.55 lease proxy client-lease-time 300 broadcast-flag policy unicast-always relay information policy keep relay information option allow-untrusted ! interface Bundle-Ether19.3333 proxy profile IPoE_DHCP ! Сабинтерфейс: interface Bundle-Ether19.3333 vrf main ipv4 address 10.0.1.3 255.255.255.0 arp learning disable ipsubscriber ipv4 l2-connected initiator dhcp initiator unclassified-source ! encapsulation ambiguous dot1q 3333 second-dot1q 1405-1420 При поступлении DHCP-пакета DISCOVER от клиента вижу в отладке RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP1955: FSM called for chaddr 201a.0676.00ff with event PACKET_DISCOVER state INIT RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP1903: Process packet event in INIT state called for chaddr 201a.0676.00ff RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP1955: FSM called for chaddr 201a.0676.00ff with event DPM_SUCCESS state INIT_DPM_WAIT RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP2739: Dropping DISCOVER for 201a.0676.00ff received on ambiguous VLAN interface for standalone proxy RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP3647: FSM call returned error for chaddr_string: 201a.0676.00ff, msg_type:1, mode: 4, event: 27 RP/0/RSP0/CPU0:Mar 17 19:45:01.696 SAMST: dhcpd[1097]: DHCPD PROXY: TP1665: Proxy process client request packet failed for chaddr 201a.0676.00ff Ключевое здесь, как мне кажется, вот это: Dropping DISCOVER for 201a.0676.00ff received on ambiguous VLAN interface for standalone proxy Если исключить на интерфейсе всякое ambiguous, записать так encapsulation dot1q 3333 second-dot1q 1420 то DHCP-запрос прекрасно транслируется на сервер, клиент получает адрес. На данном форуме нашел сходную ситуацию, где ambiguous не мешал: Но там сервер был локальным. Собственно, в чем тут проблема?

Да, получилось. Проблема была не в логике, а в физике. На стенде сигнал на ONU был около -14 dBm. Стоило только понизить его до -19, как модуль заработал.

Вопрос по протоколам pvst и rstp. Для построения колец на коммутаторах SNR мы используем протокол rstp. А чтобы защититься от клиентов применяем фильтр: mac-access-list extended PVST deny any-source-mac host-destination-mac 01-00-0c-cc-cc-cd exit обычно в таком варианте Interface Ethernet1/0/1 spanning-tree portfast bpdufilter switchport mode trunk switchport trunk allowed vlan 10;12;35 mac access-group PVST in ! Если порт не граничный, и portfast там не допустим, то при такой настройке Interface Ethernet1/0/1 spanning-tree mst 0 cost 2000 switchport mode trunk switchport trunk allowed vlan 10;12;35 mac access-group PVST in ! будет ли корректно работать STP? Т.е. не помещается ли mac access-group PVST in обмену BPDU и построению дерева?

Обновились. Не помогло. Конфиг довел до gpon profile onu-vlan vlan79 id 3 gpon-profile vlan mode trunk gpon-profile vlan pvid 79 0 gpon-profile vlan trunk vlan-allowed 79 ! interface GPON0/1 gpon pre-config-template vlan79 bind-onuid 1-128 gpon bind-onutype onutype-default-hgu precedence 127 gpon bind-onutype onutype-default precedence 128 gpon bind-onu sn 4444313882185E4E 1 gpon bind-onu sn 454C545862153FB0 2 switchport trunk vlan-allowed 79 switchport trunk vlan-untagged none switchport mode trunk switchport protected 1 storm-control broadcast threshold 5 storm-control multicast threshold 5 storm-control unicast threshold 5 ! interface GPON0/1:2 gpon onu tcont-virtual-port-bind-profile tvbind-default gpon onu tcont 1 alloc-id 257 gpon onu uni 1 vlan-profile vlan79 ! Состояние модуля все равно offline: Switch#sh gpon onu-information Interface GPON0/1 has bound 2 ONUs: IntfName VendorID EquipmentID SN LOID Status Config Status Active Time -------------- --------- ------------ ---------------- ------------------------ -------- ------------- ------------------- GPON0/1:1 DD18 N/A 4444313882185E4E N/A off-line N/A N/A GPON0/1:2 ELTX N/A 454C545862153FB0 N/A off-line N/A N/A В в логах постоянный упал/отжался: Jun 16 14:34:24 %LINEPROTO-5-UPDOWN: Line protocol on Interface GPON0/1, changed state to down Jun 16 14:34:24 %LINE-5-UPDOWN: Line on Interface GPON0/1, changed state to down Jun 16 14:34:24 %GPON-ONULOS: ONU 454C545862153FB0 is offline on GPON0/1:2. Jun 16 14:34:24 %LINEPROTO-5-UPDOWN: Line protocol on Interface GPON0/1, changed state to up Jun 16 14:34:24 %LINE-5-UPDOWN: Line on Interface GPON0/1, changed state to up Jun 16 14:34:24 %GPON-ONUACTIVATE: ONU 454C545862153FB0 is activated on GPON0/1:2. Jun 16 14:34:24 %GPON-ONUDISCOVER: ONU 454C545862153FB0 is discovered on GPON0/1:2.

@Aleksey Sonkin не сохранил тот протокол, а повторить не смог, действительно, получается как надо. Предполагаю, что не послал команду exit после add s-vid 511.

Без него новый class в политику не добавляется, а заменяет старый.

После нескольких попыток сумел добиться такого с помощью insert-before: policy-map RTS-tran class client-service-1 add s-vid 511 exit class client-service-2 add s-vid 511 exit ! Пошел проверять.

Например, я сделаю так: class-map client-service-1 match vlan 7 33 35 90 1000 1106 1110 1438 ! class-map client-service-2 match vlan 1122 3335 3410 ! Как в таком случае будет выглядеть policy-map? В данный момент так: policy-map RTS-tran class client-service add s-vid 511 exit !

Создание class-map Имеем SNR-S300X-24FQ. На нем реализуем механизм qinq с помощью class-map и policy-map. Класс определяется следующим образом: class-map client-service match vlan 7 33 35 90 1000 1106 1110 1438 ! т.е. перечисляются виланы клиента, которые нужно завернуть во второй тэг. Заметил, что после match vlan можно указать не более 8 виланов, либо один range. А как быть, если у клиента более 8 виланов, и они не образуют непрерывной последовательности "от и до"?

Самую противную часть проблемы я решил - мак-таблица теперь заполняется. Постоянные HASH_COLLISION, конечно, тоже плохо, но на производительность они не влияют. Итак, все дело в частом изменении топологии STP. А она происходила от недобросовестного клиента, который в некоторый момент стал бомбить коммутатор пакетами PVST типа Root Change. Ну, у него Cisco 3750 стояла, он сам не понял, как это работает. Дошло до такого: Izhevsk20# sh spanning-tree detail | i ieee|occur|Exec|from Number of topology changes 3533 last change occurred 0:00:26 ago from Ethernet1/43 Каждый такой topology change приводил к MAC Learning Disabled, затем к MAC Learning Enabled, и не успевала таблица заполниться на половину, как приходил новый topology change, и всё сначала. А раз таблица коммутации не заполнена, то трафик дублировался во все порты. Процессор же грузился постоянным построением таблицы с нуля.