у меня на zalman zm400 exFAT потому что иначе оно не работает, это считается?

В общем тема с iBGP RR оказалась круче чем мост в питере...

1. картинка из СДСМ №3 https://hsto.org/storage3/d8e/ef1/72e/d8eef172ea5a66f7c7336659fd36c90c.gif кое в чём не верна -))).

2. в RFC 4456 заложена возможность драки остроконечников с тупоконечниками. Там не говорится что не надо отражать в клиента его же апдейты. Но и того, что эту бессмыслицу делать надо - тоже нет (раздел 6 Operation).

3. Подсыпал палок в огонь гражданин Абырвалг https://skminhaj.wordpress.com/2016/02/15/bgp-route-reflectors-clusters/ аглицким по белому написав "An iBGP prefix received from a RR-client is advertised to all peers including the RR-client that advertised the prefix."

Тупоконечники читают тексты буквально, интерпретируя как хочется: "отправка префикса в том числе и клиенту, от которого он получен" у них равно "полученный апдейт отрази всем и тому, от кого его получил". Зачем это делать - не ясно. Лично мне ясно, что это нахер (от слова совсем) не надо.

Тем не мнее мост продолжает гореть. На очереди кишки cisco - будет ли там в схеме из двух коробок, одна RR server, адвертайзиться префикс в обратном направлении -)...

да, потому что ntfs-3g не работает с большим размером кластера

там же отдельный атрибут позволяет не принимать собственные отраженные апдейты

так что будет оно или не будет отрефлекчено обратно - пофиг

оно и на нтфс работает :)

речь не про принимать, а про не отсылать

а ну так это древняя история, что в bgp не определено явно, нужно ли отправлять апдейты, которые клиент заведомо не примет

нене, про пофиг никто и не говорит. это в принципе на входе было озвучено. Типа у(н|м)вр и дальше говорить не о чем -). Просто кто-то сказал "давайте разбираться" и всё... случился мост

с одной стороны, нафига тратить калории, если пир не оценит

ага, тем более если там FV...

с другой стороны, нас не особо ебет, оценит он или нет

шифрование что ли, не помню уже

ага, вот и абырвалг говорит что must do it....

в принципе как один из инструментов в пиринговых войнах - хорошая вещь.

если в терминах RFC 2119, то явно не MUST

у них 2 прошивки различные - под фат\екстфат и нтфс
а еще лучше его прошивать "родными" прошивками от iodd

побайтно слать в пир всё обратно на всякий случай - а вдруг он упадёт от этого - мы скажем что у нас был RR -))

я говорю что у абырвалга написано must причём совершенно из пальца. там даже should нет конкретного.

и словить maximum-length limit