Их передаёт dhcpv6 клиент(он же и скрипт дёргает), получает он их от dhcpv6 сервера, если сервер не отдаёт DNS ничего не происходит. Там уже можно вынести из условия получения dns, эт затычка была когда клиент дёргал скрипт даже если ему вообще ничего от сервера "не перепало". Это поведение в клиенте я пофиксил, а в скрипте перенести вызов забыл.

 

Впечатление такое что этот функционал всё ещё в процессе разработки.

 

Именно так, и за отсутствием у меня доступа к v6 сети кроме как через 6to4 процесс идёт весьма медленно.

 

Как бы есть вопросы:

1) Где в WEB-морде можно увидеть статус по IPv6 адресам на интерфейсах?

 

Увы в web нет ничего касаемо статусов v6 и даже страница конфигурации куцая, управление фаерволом и прочее предстоит ещё рисовать. Надеюсь на следующей итерации у меня будет вебер(узнаем после 12го). В туду для вебера статусы и прочее для v6 где-то месте на 7мом.

 

И почему собственно доменные настройки влияют на запуск сервисов IPv6?

DNS может использоваться и из IPv4 настроек ведь.

 

Там и так закостылено на тему юзать гуглоднсы 6е(если ничего не прилетело) иначе в зависимости от версии вантуза оно то может то не може v6 адреса через v4 сервер разрешать, то само лезет вообще не пойми куда. DNSы в любом случае нужно отдавать клиенту через dhcpv6 иначе виндузятнеги взвоют.

 

Так что если есть желание давайте разбираться постепенно и опять таки отдельной темой, по шагам формировать логику под вас (операторов) что бы не гадать. Для меня так же v6 в диковинку поэтому тоже приходиться на ходу разбираться.

 

В любом случае разбираться придется, функционал весьма интересен и спрос на него очень скоро начнет расти в геометрической прогрессии.

У меня доступ как раз таки есть к стенду на основе провайдерского оборудования Ericsson SmartEdge/SSR, которое кстати успешно продает НАГ.

Кроме того параллельно собрали в сети аналогчный стенд с radvd и DHCPv6 сервером на FreeBSD.

 

Копался дальше в скриптах, похоже что дело не доходит и до /etc/scripts/dhcp6c-script

переменные PREFIX SUBNET и т.п. вроде как передаются только их преднастроенных в WEB-ке адресов. Пока других вариантов не нашел.

 

Для начала поищу как поймать в дебаг все параметры передаваемые от DHCPv6 сервера к dhcp6c. И далее по цепочке скриптов буду дебажить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) dhcp6c висит в процессах? Если висит прибить его и скомандовать dhcp6c eth2.2 -Df и посмотреть получает оно вообще что-то от сервера.

2) префиксы для конфигурации radvd/dhcp в зависимости от режима и прочего либо беруться из рожи, либо читаются с LAN ифэйса на которых их конфигурит dhcp6c получая данные с сервера, либо считаются в скрипте для туннелей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Кроме того параллельно собрали в сети аналогчный стенд с radvd и DHCPv6 сервером на FreeBSD.

Эт единственное что мне доступно на коленке только не под фрёй ессно =)

 

В любом случае разбираться придется, функционал весьма интересен и спрос на него очень скоро начнет расти в геометрической прогрессии.

Неа. Мне лично оно особо не нужно, пока платят - разбираюсь, закончиться контракт через менее чем неделю и из приоритетов оно выпадет в самый конец. И вернётся назад только после оплаты и возможного продления контракта и если таки предоставят вебера ибо накопилось. Эт так чисто для информации. До 12го я в полном вашем распоряжении, потом делаю срез и всё это уезжает на фабрику.

 

Да собрал 2.8.4 крайне желательно обновиться если с v6 крутите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже что ничего не получает dhcp6c. Но причины могут быть и в самом стенде, файерволы и т.п. - надо проверять всё это...

сделал дебаг путем правки стартового скрипта чтобы писало в -лог файл

там вот только такое

Apr/08/2015 22:43:35: dhcp6_reset_timer: reset a timer on eth2.2, state=SOLICIT, timeo=12, retrans=125784
Apr/08/2015 22:45:40: copy_option: set client ID (len 14)
Apr/08/2015 22:45:40: copyout_option: set identity association
Apr/08/2015 22:45:40: copy_option: set rapid commit (len 0)
Apr/08/2015 22:45:40: copy_option: set elapsed time (len 2)
Apr/08/2015 22:45:40: copy_option: set option request (len 2)
Apr/08/2015 22:45:40: copyout_option: set IA_PD
Apr/08/2015 22:45:40: client6_send: send solicit to ff02::1:2
Apr/08/2015 22:45:40: dhcp6_reset_timer: reset a timer on eth2.2, state=SOLICIT, timeo=13, retrans=110148
Apr/08/2015 22:47:31: copy_option: set client ID (len 14)
Apr/08/2015 22:47:31: copyout_option: set identity association
Apr/08/2015 22:47:31: copy_option: set rapid commit (len 0)
Apr/08/2015 22:47:31: copy_option: set elapsed time (len 2)
Apr/08/2015 22:47:31: copy_option: set option request (len 2)
Apr/08/2015 22:47:31: copyout_option: set IA_PD
Apr/08/2015 22:47:31: client6_send: send solicit to ff02::1:2
Apr/08/2015 22:47:31: dhcp6_reset_timer: reset a timer on eth2.2, state=SOLICIT, timeo=14, retrans=126516
Apr/08/2015 22:49:37: copy_option: set client ID (len 14)
Apr/08/2015 22:49:37: copyout_option: set identity association
Apr/08/2015 22:49:37: copy_option: set rapid commit (len 0)
Apr/08/2015 22:49:37: copy_option: set elapsed time (len 2)
Apr/08/2015 22:49:37: copy_option: set option request (len 2)
Apr/08/2015 22:49:37: copyout_option: set IA_PD
Apr/08/2015 22:49:37: client6_send: send solicit to ff02::1:2
Apr/08/2015 22:49:37: dhcp6_reset_timer: reset a timer on eth2.2, state=SOLICIT, timeo=15, retrans=118080
Apr/08/2015 22:51:36: copy_option: set client ID (len 14)
Apr/08/2015 22:51:36: copyout_option: set identity association
Apr/08/2015 22:51:36: copy_option: set rapid commit (len 0)
Apr/08/2015 22:51:36: copy_option: set elapsed time (len 2)
Apr/08/2015 22:51:36: copy_option: set option request (len 2)
Apr/08/2015 22:51:36: copyout_option: set IA_PD
Apr/08/2015 22:51:36: client6_send: send solicit to ff02::1:2

 

либо читаются с LAN ифэйса на которых их конфигурит dhcp6c получая данные с сервера

dhcp6c вешает делегируемый префикс на интерфейс из конфига?

можете показать как это выглядит через команду 'ip'?

 

Пока обновлю прошивку...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не вижу у вас ответа от сервера, т.е. вообще никакого, запрос есть ответа нет. Нет строки client6_recv: receive reply. Т.е. либо сервер тупо не отвечает либо ХЗ. Надо на стороне сервера смотреть.

Разберётесь с этим моментом увидите сразу как это всё выглядит. У меня сейчас нет возможности показать как это выглядит ибо нет доступа к сети с v6 dualstack. Но у вас проблема задолго до этого лезет. У вас ответа от сервера тупо нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Проблема оказалась в коммутаторе SNR-S2960-48G :)

видимо мультикаст IPv6 на нем зарезался!!!

Позже поищу более подробно причину - либо прошивку обновить, либо какие-то настройки дополнительные нужны - хз.

 

Переключил стенд на D-Link DES-3200-28 и IPv6 адреса были получены. Тестирую далее...

 

В настоящий момент всё так же не хватает информации в вебке о полученных IPv6 адресах и PD

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

tux-tm обновите SNR-S2960-48G на последнюю прошивку http://data.nag.ru/SNR%20Switches/Firmware/S2960-48G_6.2.141.24.zip.

На ней проблем с ipv6 быть не должно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В настоящий момент всё так же не хватает информации в вебке о полученных IPv6 адресах и PD

 

Я вроде выше чётко написал при каких условиях оно там может появиться. В последнии 3 дня я ясно этим заниматься не буду, надо хвосты по сделанному подбить для начала. Так что ssh в руки.

 

Переключил стенд на D-Link DES-3200-28 и IPv6 адреса были получены. Тестирую далее...

Проблемы с MLD Snooping ? Не обольщайтесь, насколько слышу стоны то там то там этим через раз(в т.ч. зависимости от версии софта) болеют все железяки в т.ч. озвученный длинк.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

tux-tm обновите SNR-S2960-48G на последнюю прошивку http://data.nag.ru/SNR%20Switches/Firmware/S2960-48G_6.2.141.24.zip.

На ней проблем с ipv6 быть не должно.

Спасибо, попробую. Сейчас прошивка действительно древняя.

Test-SNR#sh ver
 SNR-S2960-48G Device, Compiled on Jan 06 10:04:51 2013
 SoftWare Version 6.2.139.142
 BootRom Version 4.12.1
 HardWare Version R01

 

Болячки есть у всех, это верно. Главное чтобы не хардварные.

Иногда упаришься пока подходящую прошивку подберешь. Иногда не факт что она будет свежей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В настоящий момент всё так же не хватает информации в вебке о полученных IPv6 адресах и PD

 

Я вроде выше чётко написал при каких условиях оно там может появиться. В последнии 3 дня я ясно этим заниматься не буду, надо хвосты по сделанному подбить для начала. Так что ssh в руки.

У меня лично к Вам никаких претензий нет. Напротив я благодарен за то что Вы всегда оперативно отвечаете по теме и по-возможности внедряете нужные вещи, как например возможность сброса МАС кнопкой или доработку конфига xupnpd.

 

Но как потребитель продукта я просто озвучиваю явный недостаток по информативности. Причем это должно быть интересно знать в первую очередь НАГ-у.

А как у вас с НАГом обстоят взаимоотношения - понятия не имею.

 

Своим "хомячкам" увы не могу советовать смотреть статус IPv6 через ssh. Следовательно недоработка в интерфейсе со временем постепеннно ляжет дополнительной нагрузкой на нашу техподдержку, или потребует более глубокой кастомизации WEB-интерфейса своими силами.

 

В остальном к роутеру на данный момент никаких серьезных претензий нет - вполне приличный девайс.

Но поскольку тестирование продолжается и вскоре начнем широкомасштабное внедрение, возможно возникнут ещё вопросы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

tux-tm обновите SNR-S2960-48G на последнюю прошивку http://data.nag.ru/SNR%20Switches/Firmware/S2960-48G_6.2.141.24.zip.

На ней проблем с ipv6 быть не должно.

Немного оффтоп, но всё-же напишу.

Просто обновления прошивки недостаточно, да и не факт что вообще сыграло роль.

 

А вот команды нужны. Заработало после добавления

 

на всю коробку

savi enable
savi ipv6 dhcp-slaac enable

 

На транках

Interface Ethernet0/0/52
 ipv6 dhcp snooping trust
 ipv6 nd snooping trust

 

Там ещё есть вариации, но это уже совсем оффтоп.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Причем это должно быть интересно знать в первую очередь НАГ-у.

 

Я так же в самом начале озвучивал куда адресовать хотелки по плюшкам, по ним будет формироваться в т.ч. ТЗ веберу. Мне лично хватает гемора с железом и низким уровнем, хотелось бы уйти вообще от веба ибо с 7612 полный завал.

 

Это я к чему? А к тому что мне вот тут грить что нет таких-то статусов к примеру не имеет смысла, я и сам в курсе, и проблем с вебом много больше чем статусы v6. Я вылизал в вебе то что так или иначе нужно в 99% случаев, дальше надо садиться и только вебом несколько месяцев и заниматься переделывая пошагово. А слово web тут условно весьма на самом деле. Придётся тесно работая с вебером переделывать и часть инита, и работу с nvram доделывать и т.д. Сейчас я стараюсь по минимуму вносить какие-то правки в рожу что бы не наплодить костылей которые потом придётся кому-то разгребать. Да и не вебер я, потому это будет всё зело долго и далеко не прямо.

 

В любом случае это опять таки не повод мешать всё в одну кучу.

 

А взаимоотношения простые. Как в старой рекламе: "он будет твой - пока ты абонент". =)

 

P.S. Есть таки претензии по вебу - создаешь тему аля "недочёты web интерфейса", появиться вебер и будет вами в этой теме заниматься.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Замечу что на сабжевом CPE нормально заработает IPv6 только при состоявшемся SLAAC-диалоге и получении адреса роутера через RA (что собственно и логично).

В процессе тестирования коммутаторов, поневоле столкнулся с вариантом когда SLAAC не работает, но работает DHCPv6.

Ради интереса потестировал вариант когда провайдер не отдает IPv6 через SLAAC, а отдает только PD и DNS через DHCPv6.

В этом случае через сабжевый CPE на LAN-портах IPv6 адреса из PD прекрасно раздаются, но на CPE будет отсутствовать дефолтный роут по IPv6 и связи в Интернет не будет.

А если зайти на CPE и вручную прописать роут через LinkLocal-адрес провайдерского шлюза (его конечно нужно знать) - связь прекрасно работает.

 

Не говорю что так делать правильно (роутеры в IPv6 сами себя должны объявлять через RA), но встречал упоминание провайдеров именно с такой схемой выдачи IPv6 - только выдача PD и DNS. В итоге IPv6 у них работает только через CPE , хотя там скорее всего используется PPPoE-подключение.

Изменено пользователем tux-tm

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Единственная вкусность на мой взгляд в ipv6 (ну кроме дикого количества доступных ip) это возможность прозрачной автоконфигурации. А для этого RA обязателен. Вариант конфигурить руками тоже есть, вот только тогда грить о массовом применении такой схемы НЕЛЬЗЯ.

 

Любители ppp based туннелей (не зависимо на каком уровне они ходят) на доступе в 2015г должны сдохнуть в муках ибо костыли. Однако я уже говорил при каких условиях может появиться тот или иной вариант костыля в wive.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Любители ppp based туннелей (не зависимо на каком уровне они ходят) на доступе в 2015г должны сдохнуть в муках ибо костыли

Несмотря на то что я работаю у ISP который везде предоставляет IPoE, взгляд со стороны техподдержки провайдера иной:

PPPoE - самое однозначное соединение т.к. у него все преимущества высокоскоростного Интернет и все преимущества по однозначно актуальному состоянию подключения. В своё время именно PPPoE стремительно вытеснил модемный PPP, а не IPoE(DHCP).

Напротив IPoE (DHCPv4 прежде всего)- состояние соединения самое неоднозначное, т.е. никогда невозможно утверждать что у абонента сессия живая, разве что только в момент подтверждения старта аренды адреса или подтверждения продления аренды. Между этими состояниями - неизвестность. Более-менее юзабельный вариант IPoE - это влан на абонента и далее в ядро двойное тэгирование вланов до BRAS-а. Вланы при этом все становятся изолированными и уникальными т.е. выполняют функцию туннеля.

Даже способ держать влан на весь коммутатор и инжектить DHCP Opt82 является жутким костылем т.к. тоже порождает кучу проблем, начиная с неоднозначной работы этого механизма инжекта опции на коммутаторе.

 

Кроме прочей "простоты реализации" в DHCP не предусмотрен механизм когда сервер забирает IP до окончания аренды адреса. В ситуации когда активно используются динамически выдаваемые IP - это порождает трудности. Приходится либо укорачивать время аренды, либо городить огород вокруг этого.

В IPv6 адресов тьма и это не актуально видимо по этой причине так же не предусмотрели отзыв сервером от клиента адреса IPv6. Ведь можно просто закрыть сессию и "забить" на выданный адрес пока аренда не "протухнет".

 

При безлимитных ТП и наличию IP-адресов у провайдера хотя бы равном кол-ву абонентов IPoE-соединение выигрывает по набору сервисов (возможность использовать мультикаст без двойного подключения) и по простоте подключения со стороны абонента.

А вот когда IP-адресов гораздо меньше чем абонентов и динамически выдаваемые IP являются суровой необходимостью - на высоте именно PPP(oX) т.к. сессии и выданные IP четко разложены по полочкам и разрыв сессии всегда можно делать с любой стороны о чем почти сразу же узнает другая сторона. Вот только с массовым внедрением WiFi-роутеров абоненты не отключаются почти никогда и выдаваемая динамика почти статична...

 

Так же не стоит забывать о ещё одном важном преимуществе PPPoE для внедрения IPv6 - IPv6 внутри PPPoE не потребует НИКАКОЙ модернизации оборудования провайдера, кроме головного. А в ситуации IPoE (FTTB) потребуется как минимум найти подходящую прошивку на тысячи! коммутаторов, а в большинстве случаев скорее всего придется просто заменить бОльшую часть из них из-за невозможности модернизации. Кроме того надо будет подружить с IPv6 и выдачу абонентам мультикаста по технологиям MVR, ISM и т.п.

Вот здесь поверьте "ещё поле непаханное", производители в основной своей массе IPv6 поддержку везде пишут как маркетинговый плюс, но реалии зачастую весьма плачевны. Далеко ходить не нужно - тот же ранее упоминаемый SNR коммутатор с последней версией прошивки после конфигурирования поддержки IPv6 поимел проблемы с мультикастом IPv4.

 

Так что я бы не ставил крест на туннелях как минимум до тех пор пока IPv6 не будет предоставляться повсеместно и его трафик не станет хоть сколь-нибудь значимым.

Следующие 2-3 года ИМХО будут весьма напряженными в плане перехода на 6-ю версию IP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

PPPOE как и PPTP/L2TP это инкапсуляция одного напрямую невпихуемого в другое невпихуемое особенно с v6 где MTU может быть много больше максимального MTU в PPPOE. Это сразу ставит крест на всех ваших однозначностях.

 

PPPoE стремительно вытеснил модемный PPP

 

Он никуда его не вытеснял, как был этот самый модемный ppp внутри pptp/l2tp/pppoe так и остался со всеми "прелестями", только link level между двумя ppp организовали нахлобучкой сверху через инкап в ethernet/gre/udp. В итоге поимели море сэкиса на ровном месте. Посмотрите реализацию этого бутерброда из pppd+плагинов+яерных модулей. Этот вырвиглазный монстр где работу по инкапу пришлось унести в ядро иначе производительности хоть сколько-то приемлемой добиться не удавалось который до сих пор то там то там подпирают костыликами... Нет уж, спасибо. На доступе они не упёрлись, особенно если речь идёт о v6.

 

Так что должны сдохнуть - закономерный вывод который сделает любой разработчик столкнувшийся с тем что там внутри этого цирка с конями.

 

За последние несколько лет всех до кого дотянулся перетащил лично на ТТК (с их IPOE) именно потому что сэкис с привязками мака и всякими PPTP/L2TP/PPTP с зависшими сэссиями и звонками в ТП что бы пнули брас, разрывы сэссий по расписанию или по откровенно непонятным причинам со стороны оператора откровенно забадали.

 

Крест на эти костыли никто не ставит, но и рассматривать варианты запихать в них ещё и v6 я лично не собираюсь. Будет заказ, будет стенд, будет оплата - будем посмотреть.

 

Опус простите не читал, мне достаточно ограничения описанного выше, не говоря уже о иных далеко не очевидных проблемах. Желание оператора переложить свои проблемы на абонентское железо вылезет гемором оператору же (эффект бумеранга).

 

Далеко ходить не нужно - тот же ранее упоминаемый SNR коммутатор с последней версией прошивки после конфигурирования поддержки IPv6 поимел проблемы с мультикастом IPv4.

Пинайте вендора, мне об этом рассказывать не нужно. Я не покупаю железо пока не буду уверен что оно удовлетворяет моим хотелкам и не имеет критичных для меня багов, ну или как минимум должен быть шанс это поправить самостоятельно. Хоть NAG хоть не NAG.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

P.S. Вопросы на ближайшее время решили, можно ехать дальше, в т.ч. v6 over pppoе если предоставите стенд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

P.S. Вопросы на ближайшее время решили, можно ехать дальше, в т.ч. v6 over pppoе если предоставите стенд.

Могу завтра Вам сделать удаленный доступ на LAN-интерфейс CPE путем проброса портов к SSH.

Подключение PPPoE c IPv6 уже протестировал на роутере с OpenWRT к тестовому BRAS-у.

Полагаю такого стенда будет достаточно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандартный стенд это консоль на UART к ПК с Linux с minicom+tftp сервером что бы доступ у меня был к железке всегда даже если я по запаре залью не ту прошивку, т.е. что бы легко смог поднять из бута по tftp и что бы доспут к консоли у меня был независимо от состояния соединения и доступности роутера вообще по сети.

 

Завтра точно не надо, к концу следующей недели можно будет подумать. Пока занят более критичными вещами.

 

Подключение PPPoE c IPv6 уже протестировал на роутере с OpenWRT к тестовому BRAS-у.

 

Ни о чём не говорит от слова совсем. И более того даже не интересно как оно там.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандартный стенд это консоль на UART к ПК с Linux с minicom+tftp сервером что бы доступ у меня был к железке всегда даже если я по запаре залью не ту прошивку, т.е. что бы легко смог поднять из бута по tftp и что бы доспут к консоли у меня был независимо от состояния соединения и доступности роутера вообще по сети.

 

Завтра точно не надо, к концу следующей недели можно будет подумать. Пока занят более критичными вещами.

С 27-го апреля я буду недоступен до конца майских выхов.

В данный момент не могу сделать "консоль на UART к ПК с Linux", тупо нет такого ПК под рукой да и роутер не очень хочется курочить...

После отпуска попытаюсь организовать стенд по вашим запросам.

 

Подключение PPPoE c IPv6 уже протестировал на роутере с OpenWRT к тестовому BRAS-у.

 

Ни о чём не говорит от слова совсем. И более того даже не интересно как оно там.

 

Это я к тому что тестовый BRAS (как часть стенда) настроен и готов для раздачи IPv6 через PPPoE.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ок, мне точно такая схема не горит, так что времени вагон. Да, опубликовал 2.9.1 кроме прочего причесал местами код dhcpv6 проверьте на всякий на предмет регрессий, на коленке всё ок, да и вроде не правил ничего такого что могло бы что-то сломать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В общем начал переделывать логику и решил сразу добавить режим ipv6 over PPPOE/PPTP/L2TP. В общем-то сделал, на коленке вроде работает. Могу заслать тестовый имидж. Пока в рожу не выносил т.е. что бы включить надо сказать nvram_set vpnDGWSIX on. Позже вытащим в рожу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ОК, завтра на работе протестирую

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да проверьте так же на IPOE нет ли регрессии в плане ipv6, а то я только на коленке имею возможность тестить нативные схемы. Сейчас в общем-то сделал так что запустить DHCP+RA очень и очень просто через любой доступный в системе интерфейс, т.е. логику унифицировал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ПЛЗ проверьте 3.0.1 как на IPOE так и на PPPOE (для PPPOE после настройки туннеля в разделе ipv6 нужно включить галку что аплинк v6 у нас в VPN, задавать переменную руками не нужно).

 

Кроме прочего в код HW_NAT добавлен воркэраунд гарантирующий что данные после выборки из памяти при FOE Size=80 не будут запорчены (как выяснилось оно актуально не только для 7621) т.е. как раз в случае работы с ipv6.

 

У себя отгонял несколько суток на всех доступных устройствах, даже на 203ей ревизии проблема с ipv6 (FOE Size=80) ушла.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0