[Картуччо]

Да, прикольный плагинчик, спасибо.

У меня отобразил 4&6 со странички на интранетовском сервере v4, на которой вставлена через ссылку картинка с другого интернетовского сервера с v6.

 

Либо он в 7.1 не работает, либо я тупой. Ничего он мне не показывает.

Насчет 7.1 не знаю, у меня ночная сборка версия 10.

[GFORGX]

Кто-нибудь в курсе, каков статус вот этого:

 

http://www.ietf.org/rfc/rfc5006.txt

 

?

[rm_]

GFORGX

obsoleted by 6106, см. также http://version6.ru/rdnss-ra

[GFORGX]

Спасибо. Как я понимаю, кроме radvd линуксового нигде не поддерживается... Не использовать же линуксы в качестве v6 customer-facing роутеров :)

 

Думается сделать для хомячков как-то так: http://www.genmay.com/showthread.php?t=831551

Кто-нибудь подобную схему пробовал с other-config-flag? У чувака в предпоследнем сообщении сработало на W7, а как на других системах, кто-нибудь пробовал? WXP, Network Manager? Негде сейчас DHCPv6 поднять, к сожалению, чтобы попробовать.

[GFORGX]

Ещё мысли вслух: допустим, есть сеть, в качестве PE которой - Summit-ы x480, а в ядре - C7600. У саммитов - ограничение в 512 IPIF, поэтому Vlan-per-user сделать не получится. Окей, вешаем на каждый домовой VLAN по одной /64, на доступе у нас DES-3528, там можно включить ND Snooping. Адреса выдаём RA, висящими на саммитах, по вышеописанной в ссылке схеме с other-config-flag, DNS-ы клиенты получают у DHCPv6. Далее, аккаунтинг. Нужно как-то связать полученные по RA адреса с учётными записями в биллинг. Тут - только пионерские костыли в голову приходят - лезть раз в n-ное время по SNMP на свитчи, дёргать таблицу ND Snooping и, собственно, создавать записи в БД, по которым будет расталкиваться NetFlow. Дополнительные клиентские адреса - можно продавать как дополнительную услугу, или в провайдерский L2 домен расширением лимита ND Snooping (а таких клиентов будет большинство) или статик-роутингом на клиентскую CPE (тут в качестве клиентов видятся только корпораты, видимо), ежели та умеет IPv6. Критику в студию... :)

[none7]

Дополнительные клиентские адреса - можно продавать как дополнительную услугу, или в провайдерский L2 домен расширением лимита ND Snooping (а таких клиентов будет большинство) или статик-роутингом на клиентскую CPE (тут в качестве клиентов видятся только корпораты, видимо)

Дополнительные адреса могут быть получены клиентами через клиентский свитч(много ли таких клиентов?) или префиксом через DHCPv6-PD. Роутеры и винды расшаривающие доступ в сеть, создают свой L3-сегмент, соответственно будут просить DHCPv6-PD.

 

лезть раз в n-ное время по SNMP на свитчи, дёргать таблицу ND Snooping

А SNMP TRAP на обновление таблицы ND Snooping'а нельзя настроить? Если нет, то нужно просить у Dlink добавить в прошивку такую возможность, это было бы наилучшим костылём.

 

Кто-нибудь подобную схему пробовал с other-config-flag? У чувака в предпоследнем сообщении сработало на W7, а как на других системах, кто-нибудь пробовал? WXP, Network Manager? Негде сейчас DHCPv6 поднять, к сожалению, чтобы попробовать.

 

WXP DNSv6 вообще не умеет, по крайней мере без установки спец.дополнений. Тестировал Ubuntu 10.04, работает только rdnss и то, с ужасными глюками, в частности если сбросить настройки IPv6, то придётся ждать следующего широковещательного RA пакета, так как никаких дополнительных запросов она не делает, даже при down/up интерфейса. Остаётся надеяться, что в новых версиях починили.

[GFORGX]

А SNMP TRAP на обновление таблицы ND Snooping'а нельзя настроить? Если нет, то нужно просить у Dlink добавить в прошивку такую возможность, это было бы наилучшим костылём.

Согласен, будет идеально. Возможно уже есть, но трапы не используем как-то исторически. Нужно будет на форуме D-Link уточнить :)

 

WXP DNSv6 вообще не умеет, по крайней мере без установки спец.дополнений. Тестировал Ubuntu 10.04, работает только rdnss и то, с ужасными глюками, в частности если сбросить настройки IPv6, то придётся ждать следующего широковещательного RA пакета, так как никаких дополнительных запросов она не делает, даже при down/up интерфейса. Остаётся надеяться, что в новых версиях починили.

WXP - хрен с ней, как бы, думается мне, пора уже закопать давно. По поводу Ubuntu - это в случае использования Network Manager? Думаю, так или иначе нужно будет делать маленький интервал расылки RA. А вообще - в случае с Network Manager, думаю, скорее всего будут решены проблемы, FOSS ведь.

[none7]

По поводу Ubuntu - это в случае использования Network Manager?

Да.

[s.lobanov]

WXP - хрен с ней, как бы, думается мне, пора уже закопать давно. По поводу Ubuntu - это в случае использования Network Manager? Думаю, так или иначе нужно будет делать маленький интервал расылки RA. А вообще - в случае с Network Manager, думаю, скорее всего будут решены проблемы, FOSS ведь.

 

Да на все десктоп-линуксы меньше просто забить ибо <1% абонентов, а winxp ещё живёт и её явно более 1%

[GFORGX]

Да на все десктоп-линуксы меньше просто забить ибо <1% абонентов, а winxp ещё живёт и её явно более 1%

Ну и будут они себе сидеть на v4, пожалуйста :) Захотят v6 самостоятельно - обновятся. А когда это будет вынуждено чем-либо, к тому времени уж явно на семёрку или что поновее перейдут.

[GFORGX]

Согласен, будет идеально. Возможно уже есть, но трапы не используем как-то исторически. Нужно будет на форуме D-Link уточнить :)

А вот хрен там - натравил на ноутбук, запустил tcpdump и ничего кроме link up/link down трапов не увидел... Как я понимаю, трапы там используются аналогично логам - только для "нарушающих записей". Вывод - костыли будут забористые, как я в начале и писал :) Т. е., по умолчанию на абонентских портах висит ACL, запрещающий "нормальный" v6-трафик, кроме ND/RA/DHCPv6, потом, когда система service activation увидит изменение таблицы ND Snooping методом периодического тыкания, - выдёргивать айпи-адреса, создавать привязки в БД и разрешающие именно только эти адреса (а их количество будет определяться настройкой max entries) ACL на свитче. Эх :( Кстати, хз, есть ли точно данные по ND Snooping в таблице SNMP, нужно глядеть, это же не v4, который можно в исходном виде в OID засунуть...

[GFORGX]

Всё становится ещё менее радужным - на саммитах нельзя повешать v6-префикс на subvlan при использовании VLAN Aggregation (а-ля unnumbered в Cisco). Итого, остаётся лишь забыть про прозрачное v6 для всех пользователей...

Изменено 28 октября, 2011 пользователем GFORGX

[rus-p]

Вы пришли к хорошему выводу, на мой взгляд.

Либо нормальный брас и воздушки под землю с ежемесячным платежом и пытаемся не упасть, либо 6RD и тоже пытаемся не упасть от остального )

Давайте точить 6RD вместе )

[rm_]

Получают в6 адрес 16% юзеров (владельцы вин7, ХР не умеет получать в6 по пптп)

Трафик - меньше 2%

Т.е. если бы получили адрес 100% юзеров, трафик был бы уже 12-13%.

А к тому времени когда это произойдёт, и гораздо больше.

Чем больше v6-юзеров - тем больше v6-трафика в торрентах. Да и сервисы с добавлением доступности по v6 на месте не стоят.

Изменено 28 октября, 2011 пользователем rm_

[GFORGX]

Вы пришли к хорошему выводу, на мой взгляд.

Либо нормальный брас и воздушки под землю с ежемесячным платежом и пытаемся не упасть, либо 6RD и тоже пытаемся не упасть от остального )

Давайте точить 6RD вместе )

Не-а, склоняюсь таки к нормальным BRAS-ам ;) Хочется дать v6 всем, нормальный, с Vlan-per-user, без костылей на доступе. Благо, по средствам возможность есть.

[rus-p]

Да мне тоже на работе приходится брас толкать, 6RD это для души.

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

[GFORGX]

Да мне тоже на работе приходится брас толкать, 6RD это для души.

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

Ничерта не понял - что за сессии вы имеете ввиду, и почему они проседают?

[Ivan_83]

У кого vlan-per-customer и фряха на пути уже давно мог заюзать ng_vlan + ng_car + какой то скрипт, таким образом юзер получит общее ограничение скорости, не важно в4, в6 или всё вместе юзать будет.

 

Я в свободное время пишу netgraph ноду, которая будет каждый отдельный мак или блочить или заворачивать на отдельный хук, где можно разместить ng_car, короче аналог linux isg только на L2 и под фряху.

 

Пока считает стату по макам, включая vid в котором он.

 

ngctl msg re0:lower getsesstbl

Rec'd response "getsesstbl" (4) from "[4]:":

Args: { total_count=4 sess_entryes=[ {

enaddr=ff:ff:ff:ff:ff:ff lifetime=191 idle=74 stat={ upperOctets=56 upperPackets=2 } } {

enaddr=00:1b:21:4f:f5:b3 lifetime=318 idle=8 stat={ upperOctets=6755 upperPackets=95 lowerOctets=3439 lowerPackets=56 } } {

enaddr=00:1a:4d:56:e8:a6 lifetime=51 idle=51 stat={ lowerOctets=229 lowerPackets=1 } } {

enaddr=6c:f0:49:75:38:e3 vid=10 lifetime=318 stat={ upperOctets=34040 upperPackets=471 lowerOctets=29508 lowerPackets=339 } } ] }

 

 

 

[netime]

а есть тупо клиент PPPOEv6 и PPTPv6 для XP?

[Deac]

а есть тупо клиент PPPOEv6 и PPTPv6 для XP?

Есть, но пока - только за деньги:

http://www.cfos.de/ru/cfos-ipv6-link/documentation.htm

[GFORGX]

Ещё раз привет :)

 

В процессе включения v6 на XMPP-сервере, вопрос прикладного характера: как при помощи ipfw заставить FreeBSD пропускать RA?

 

При вот таких вот правилах в rc.firewall, касающихся v6:

...
ipfw add 100 pass ipv6-icmp from any to me6
...
ipfw add 200 pass ipv6 from me6 to any keep-state
...
ipfw add 500 pass ipv6 from 2001:XXXX:XXXX:XXXX::/64 to me6 6667
...
ipfw add 600 allow ipv6 from any to me6 3784,5222,5269,5347
...

 

не срабатывает SLAAC. Без них - OK, добавляю 10 allow ipv6 from any to any - тоже цепляет.

 

UPD.: разобрался самостоятельно, RA шлётся на мультикаст-адрес, поэтому с "allow ipv6-icmp from any to me6" не срабатывает, сделал "allow ipv6-icmp from any to any" - полёт нормальный :)

Изменено 30 октября, 2011 пользователем GFORGX

[GFORGX]

Итого, краткий отчёт о проделанном за последние пару недель в качестве хобби :)

 

Создал недели 2 назад простой (без BGP) туннель с HE.net, поднял на бордере (GNU/Linux), попинговал и потрейсил - чудесно, работает. Протащил статикой через два роутера (на стыках пока что использовал приватные /64, поскольку не сразу увидел, что HE.net даёт ещё и /48 ;)) до себя выданную HE.net /64 routed-сетку, повешал на SVI NOC-а, проверил - чудесно, трейсится и пингуется.

 

Вчера дошли руки поднять BGP6 - тут получилось не без костылей: на Linux-бордере в качестве BGP-демона используется BIRD, работа с двумя стэками в нём организована крайне оригинально, при запуске в статусе BGP-сессии до 76-ой циски ругался на то, что нету слущающего сокета. Глянул netstat - действительно, BGP висит только на 0.0.0.0:179. В логах ругался на то, что:

 

Oct 30 00:43:46 Core-2 bird6: sk_open: bind: Address already in use
Oct 30 00:43:46 Core-2 bird6: BGP: Unable to open listening socket

 

Погуглил, всего один результат [1] с такой проблемой в разных смотрелках мейллистов, так и не решённый. Сначала попробовал забиндить BGP в BIRD6 на v6-only с помощью "listen bgp address 0:0:0:0:0:0:0:0 port 179;", не помогло, всё так же ругалось на запуске. В итоге сделал "listen bgp address 0:0:0:0:0:0:0:0 port 1179;", сессия поднялась, минус вижу один - сессия в данном случае должна быть обязательно инициированной со стороны линукс-роутера, чтобы она могла подняться. Если по какой-то причине сессия упадёт, циска будет пытаться её восстановить, а BIRD не будет пытаться ничего делать, - ничего не взлетит :)

 

Итого, от статики избавились. Дефолт на туннельброкера отдал в IGP прописыванием на бордере "route ::0/0 via "he-ipv6";" для протокола static.

 

Далее, захотелось поднять v6 на веб-сервере с разными официальными страничками, форумами, etc. Там nginx и apache-и расположенные на разных хостах и на локалхосте в том числе. RA веб-сервер чудесно получил (отдал на интерфейс роутера одну /64 и routed-блока /48, выданного HE.net) и адрес на сетёвку повешал, апач (висящий на нестандартном порту) по v6 откликнулся, а nginx - судя по netstat, его даже не слушал. Обновил из репозиториев (Debian), нашёл, как заставить его слушать оба стэка [2], всё заработало. Пришлось приделать костыль к IPB3 [3], ибо тот про v6 ничего не знает и ругался на "невозможно опрелелить Ваш IP-адрес". Ну и продублировал большую часть iptables.conf в ip6tables.conf, из отличий - ipv6-icmp вместо icmp. В BIND после недолго чтения ссылок из гугла научился дописывать AAAA и PTR-ы для ip6.arpa.

 

Про Jabber. IPv6-стэк на FreeBSD чудесно поднялся после ipv6_enable="YES" в rc.conf и исправления rc.firewall (см. выше). Далее - облом, в качестве XMPP-сервера используется Prosody, а там поддержка v6 только экспериментальная и в транке. Ничего, допилят и обновлюсь. Пока что - в портах стабильная версия и там IPv6 нету (тем не менее, обновил :)), а транк собираться отказался, особо не вникал.

 

[1] http://comments.gmane.org/gmane.network.bird.user/1231

[2] http://kovyrin.net/2010/01/16/enabling-ipv6-support-in-nginx/

[3] http://webcache.googleusercontent.com/search?q=cache:MDmXhfHGgI8J:www.forumscriptz.org/ipb-articles-tutorials/5980-invision-power-board-ipv6-dirty-hack.html+ipb3+ipv6&hl=kk&client=ubuntu&gl=kz&strip=1

 

Пруф:

 

[bird_of_Luck]

Вчера дошли руки поднять BGP6 - тут получилось не без костылей: на Linux-бордере в качестве BGP-демона используется BIRD, работа с двумя стэками в нём организована крайне оригинально, при запуске в статусе BGP-сессии до 76-ой циски ругался на то, что нету слущающего сокета. Глянул netstat - действительно, BGP висит только на 0.0.0.0:179. В логах ругался на то, что:

 

Oct 30 00:43:46 Core-2 bird6: sk_open: bind: Address already in use
Oct 30 00:43:46 Core-2 bird6: BGP: Unable to open listening socket

bird 1.2.5 немного, гм, устарел. Обновитесь на 1.3.4 и у Вас все будет хорошо. listen на v6 сокете пофиксили в конце 2010 года, как раз после 1.2.5

[Deac]

Это тоже починили?

 

Попробовал 1.3.1, неделю проработало без падений.
Но вылезла другая проблема:
-- после пропадания аплинка(перезагрузка оборудования провайдером) BGP не поднимается. :(

В логе выглядит так:
18:50:58 <RMT> UpLink1: Received: Hold timer expired
18:12:15 <RMT> UpLink1: Received: Hold timer expired
18:16:55 <WARN> BGP: Unexpected connect from unknown address x.x.x.1 (port 54603)
18:21:43 <WARN> BGP: Unexpected connect from unknown address x.x.x.1 (port 52067)

[bird_of_Luck]

Это тоже починили?

 

Попробовал 1.3.1, неделю проработало без падений.
Но вылезла другая проблема:
-- после пропадания аплинка(перезагрузка оборудования провайдером) BGP не поднимается. :(

В логе выглядит так:
18:50:58 <RMT> UpLink1: Received: Hold timer expired
18:12:15 <RMT> UpLink1: Received: Hold timer expired
18:16:55 <WARN> BGP: Unexpected connect from unknown address x.x.x.1 (port 54603)
18:21:43 <WARN> BGP: Unexpected connect from unknown address x.x.x.1 (port 52067)

Здесь не очень много информации о том, что произошло. Может быть у провайдера source-address поменялся, или еще что-то похожее.

 

Но вообще проблем с BGP быть не должно - это как бы основное направление bird.

Я в ряде мест сижу еще на 1.3.1 с локальными патчами на тему config includes и multiple fibs - все хорошо, никаких нареканий, в том числе и при пропадаении физики.

Но а вообще сейчас имеет смысл ставить последний релиз, там достаточно много интересного со времен 1.3.1 появилось