Topic: Сингулярность или коллапс IPV4-интернета? (Read 2858 times)
пока провайдеры не очень то шевелятся
Зачем мне вас пугать? Видел я ваши фотографии. Не впечатляют.
А зря, 14 лет назад, когда это снималось, это тоже было совсем совсем не плохо. 
Feed поток обмена, а BGP full feed==BGP full-view.
И в лучших традициях Блеза де Монлюка продолжать дискутировать с вами не вижу смысла и не испытываю желания.
Да с вами то всё понятно, можете и дальше сравнивать апельсины с ящиками для них и быть упёртым бараном. С цитатками как всегда, куда вы в философию лезете, букварь то не изучили: http://en.wikipedia.org/wiki/Border_Gateway_Protocol И в лучших традициях Блеза де Монлюка продолжать дискутировать с вами не вижу смысла и не испытываю желания.
Так, предостережение другим, чтобы не выглядели глупо.
BGP table full feed - это поток обмена между серверами GBP для устаканивая полной маршрутизации, которая full-view и будет результирующей суммарной таблицей. Памяти для feed надо меньше, так как на разных маршрутизаторах уже есть своя текущая таблица BGP, а обмен идёт только разностью. Можно сказать, что суммарный поток со всех маршрутизаторов и будет full-view, но это сильное упрощение, так как с накладными расходами всё равно будет больше и смысла для конкретной точки эта сумма не имеет, разве что для анализа взрывообразного увеличения трафика для перестройки таблиц при аварии на крупном узле.
Зачем мне вас пугать? Видел я ваши фотографии. Не впечатляют.
Feed поток обмена, а BGP full feed==BGP full-view. И в лучших традициях Блеза де Монлюка продолжать дискутировать с вами не вижу смысла и не испытываю желания.
Feed поток обмена, а BGP full feed==BGP full-view. И в лучших традициях Блеза де Монлюка продолжать дискутировать с вами не вижу смысла и не испытываю желания.
Да. Я уже более 20 лет этой темой не владею... И именно "не владея темой", мне удалось начиная года этак с 1993 поучаствовать в разработке, внедрении и последующем сопровождении 7 сетевых проектов entherprise уровня, стоимость каждого из которых начиналась с суммы с 6 нулями.
А "Feed" не стоит вырывать из контекста, потому что это именно специализированный термин, обозначающий тот самый "BGP full-view". Вам же, как "владеющему темой" специалисту, следует срочно восполнить пробелы в своих знаниях профессиональной терминологии сетевых протоколов.
Тю, нашли чем испугать. А "Feed" не стоит вырывать из контекста, потому что это именно специализированный термин, обозначающий тот самый "BGP full-view". Вам же, как "владеющему темой" специалисту, следует срочно восполнить пробелы в своих знаниях профессиональной терминологии сетевых протоколов.
Вам фотографию выслать меня возле HP Superdome2 1.7M$? Вот вчера поднимал это на 256 Итаниумах упавшее, ибо кондиционер весь из себя промышленный, не выдержавший 35 градусов за окном. Как Кубинские терминалы, не работающие в жару и советские - в холод. Ещё не известно, кто чего на сколько нулей внедрял, не стоит так опрометчиво мериться пипиcьками. Ладно, оно поднялось, я сегодня добрый, в сторону лирику. Feed - это просто поток обмена BGP между серверами при перестроении маршрутизации. Понятно? Так что идите и не позорьтесь.
Да. Я уже более 20 лет этой темой не владею... И именно "не владея темой", мне удалось начиная года этак с 1993 поучаствовать в разработке, внедрении и последующем сопровождении 7 сетевых проектов entherprise уровня, стоимость каждого из которых начиналась с суммы с 6 нулями.
А "Feed" не стоит вырывать из контекста, потому что это именно специализированный термин, обозначающий тот самый "BGP full-view". Вам же, как "владеющему темой" специалисту, следует срочно восполнить пробелы в своих знаниях профессиональной терминологии сетевых протоколов.
А "Feed" не стоит вырывать из контекста, потому что это именно специализированный термин, обозначающий тот самый "BGP full-view". Вам же, как "владеющему темой" специалисту, следует срочно восполнить пробелы в своих знаниях профессиональной терминологии сетевых протоколов.
И на будущее: не стоит мне объяснять, о чём именно я писал в своих собственных сообщениях. Я по-любому и изначально знаю это лучше вас.
Так и выражать свои мысли надо яснее. Для этого общение и служит, чтобы донести мысль, выслушать оппонента, возможно вплоть до полного разворота в убеждениях, если факты подтвердят ложность ваших мыслепредставлений. Видит Бог, я не хотел заострять, думал сами разберётесь, однако вот как факт: одно только Ваше "Feed" вставляемое сюда совершенно ни к месту, доказывает, что вы вообще не владеете темой.
А как же тогда с этим:
Или вы от этих слов уже отказываетесь ?
P.S. И на будущее: не стоит мне объяснять, о чём именно я писал в своих собственных сообщениях. Я по-любому и изначально знаю это лучше вас. Если мы не понимаем друг-друга это всего лишь досадная, но малозначимая деталь, которая ни на йоту не меняет сути проблемы.
Последний раз: в полном - увеличится, но у тех у кого с памятью на полный есть проблемы, при переходе на IPv6 появится шанс не очень от этого страдать.
?Или вы от этих слов уже отказываетесь ?
P.S. И на будущее: не стоит мне объяснять, о чём именно я писал в своих собственных сообщениях. Я по-любому и изначально знаю это лучше вас. Если мы не понимаем друг-друга это всего лишь досадная, но малозначимая деталь, которая ни на йоту не меняет сути проблемы.
о том же самом я вам и твержу изначально уже в 4 посте ...
В том то и дело, что вовсе не о том. Дробление и таблицы у вас уменьшаются. А на самом деле - дробить будут больше и таблица увеличится. Полный BGB только разрастётся, от количества желающих и от увеличения накладных расходов на IPv6. Так что ещё надо сильно посчитать где вообще видят выигрыш. Замена на современные железки даст возможность держать полный IPv4, но а вот полный IPv6 - ещё бабушка надвое сказала. Стоит только перейти на IPv6 и, бездумно как сейчас раскидываются "бесконечными" адресами, ещё попьёт кровушки. Не совсем по теме, но о "забыли про овраги": http://habrahabr.ru/post/233153/
Возможно для вас это и "типичненько" ...
Полный (он же BGP full-view, он же BGP Feed ...) об этом и идёт разговор с самого начала (с моего первого поста). И
о том же самом я вам и твержу изначально уже в 4 посте ...
Полный (он же BGP full-view, он же BGP Feed ...) об этом и идёт разговор с самого начала (с моего первого поста). И
но у тех у кого с памятью на полный есть проблемы, при переходе на IPv6 появится шанс не очень от этого страдать
о том же самом я вам и твержу изначально уже в 4 посте ...
Так речь и идёт про полный .
Как типичненько, возражать не читая о чём пишут. Последний раз: в полном - увеличится, но у тех у кого с памятью на полный есть проблемы, при переходе на IPv6 появится шанс не очень от этого страдать.
Так речь и идёт про полный ... Отсюда и проблема. А ещё в IPv6 не будет classless маршрутов (поскольку они станут не нужны).
В том то и дело, что:
В полном - безусловно. И не стоит забывать, что для IPv6 памяти на это уйдёт еще больше 192.168.20.16/28
192.168.0.0/16
When the address 192.168.20.19 needs to be looked up, both entries in the routing table "match". That is, both entries contain the looked up address. In this case, the longest prefix of the candidate routes is 192.168.20.16/28, since its subnet mask (/28) is higher than the other entry's mask (/16), making the route more specific.
Таким образом для всех маршрутов "порезанных" подсетей нужно держать записи в BGP Feed.192.168.0.0/16
When the address 192.168.20.19 needs to be looked up, both entries in the routing table "match". That is, both entries contain the looked up address. In this case, the longest prefix of the candidate routes is 192.168.20.16/28, since its subnet mask (/28) is higher than the other entry's mask (/16), making the route more specific.
В том то и дело, что:
192.168.20.16/28
192.168.0.0/16
When the address 192.168.20.19 needs to be looked up, both entries in the routing table "match". That is, both entries contain the looked up address. In this case, the longest prefix of the candidate routes is 192.168.20.16/28, since its subnet mask (/28) is higher than the other entry's mask (/16), making the route more specific.
Таким образом для всех маршрутов "порезанных" подсетей нужно держать записи в BGP Feed. 192.168.0.0/16
When the address 192.168.20.19 needs to be looked up, both entries in the routing table "match". That is, both entries contain the looked up address. In this case, the longest prefix of the candidate routes is 192.168.20.16/28, since its subnet mask (/28) is higher than the other entry's mask (/16), making the route more specific.
В IPv6 /64 это умолчание,а не обязательное правило.
Увеличение количества записей в таблицах BGP Feed обусловлено необходимостью дробления адресного пространства IPv4 на мелкие подсети (не классические сети С/24, а classless C/>24) вследствие дефицита адресации. Переход на IPv6 исключит проблему дефицита адресации в сетях IPv4 и позволит избавиться от дробления подсетей, что приведёт к уменьшению размера вышеуказанных таблиц. Стимулирующим фактором является необходимость замены устаревшего оборудования, на котором в настоящее время наблюдаются проблемы. С заменой устаревшего магистрального оборудования автоматически будут устранены и факторы, сдерживающие внедрение IPv6 (отсутствие поддержки ввиду наличия аппаратных ограничений оборудования).
Да не, количество дробления не уменьшится, а только увеличится. Купить AS для IPv6 в 5 раз дешевле, чем в IPv4, так что количество маршрутов только увеличится. Тут другой фактор, сейчас у каждого провайдера просто много разных сетей, а когда будут пилить одну большую, то можно спокойно резать префикс тем, у кого памяти мало для full BGP, при этом всё продолжит вполне работать. Увеличение количества записей в таблицах BGP Feed обусловлено необходимостью дробления адресного пространства IPv4 на мелкие подсети (не классические сети С/24, а classless C/>24) вследствие дефицита адресации. Переход на IPv6 исключит проблему дефицита адресации в сетях IPv4 и позволит избавиться от дробления подсетей, что приведёт к уменьшению размера вышеуказанных таблиц. Стимулирующим фактором является необходимость замены устаревшего оборудования, на котором в настоящее время наблюдаются проблемы. С заменой устаревшего магистрального оборудования автоматически будут устранены и факторы, сдерживающие внедрение IPv6 (отсутствие поддержки ввиду наличия аппаратных ограничений оборудования).
В IPv6 /64 это умолчание,а не обязательное правило.
Увеличение количества записей в таблицах BGP Feed обусловлено необходимостью дробления адресного пространства IPv4 на мелкие подсети (не классические сети С/24, а classless C/>24) вследствие дефицита адресации. Переход на IPv6 исключит проблему дефицита адресации в сетях IPv4 и позволит избавиться от дробления подсетей, что приведёт к уменьшению размера вышеуказанных таблиц. Стимулирующим фактором является необходимость замены устаревшего оборудования, на котором в настоящее время наблюдаются проблемы. С заменой устаревшего магистрального оборудования автоматически будут устранены и факторы, сдерживающие внедрение IPv6 (отсутствие поддержки ввиду наличия аппаратных ограничений оборудования).
Увеличение количества записей в таблицах BGP Feed обусловлено необходимостью дробления адресного пространства IPv4 на мелкие подсети (не классические сети С/24, а classless C/>24) вследствие дефицита адресации. Переход на IPv6 исключит проблему дефицита адресации в сетях IPv4 и позволит избавиться от дробления подсетей, что приведёт к уменьшению размера вышеуказанных таблиц. Стимулирующим фактором является необходимость замены устаревшего оборудования, на котором в настоящее время наблюдаются проблемы. С заменой устаревшего магистрального оборудования автоматически будут устранены и факторы, сдерживающие внедрение IPv6 (отсутствие поддержки ввиду наличия аппаратных ограничений оборудования).
Не очень верится, что IPv6 уменьшит количество маршрутов. Это сейчас пытаются оптимизировать и уложиться в существующие сети. А то как бы не наоборот, ведь каждый узел IPv6 сети будет сам сетью аж /64.
Jump to: