Перейти до

Предоставление провайдерами чего-то вроде анонимного BGP, OSPF


Рекомендованные сообщения

поддержу этот холивар :)

 

В принципе с тем что ipv6 грядет и проблема количества адресов не будет такой острой, проблема останется одна это количество маршрутов.

 

С другой стороны, если будет всё как пологается, с анонсами сетей с обоих сторон - при условии что абоненты будут подключены к двум и более провайдерам одновременно (я ж так понимаю, что только ради этого вся затея?) - то провайдеры получат ещё и некислую возможность резервирования через соседние сети посредством как раз таки домашних роутеров через которые они пересекаются %)

 

А если вернутся к реальности - увы и ах, абонентские линки 100 мегабитные, сохо железо не готово к такому повороту в принципе и врятле в ближайшие лет 20 приблизится к этому (иначе какого хрена железные роутеры в которые влетез 1 и больше FV стоят так много?).

Ну а так, с футуристической точки зрения, полностью распределенная сеть смотреть очень интересно %)

 

Ещё бы мплс сюда приплести..... :D :D :D

Ага... каждый абонент получит as и блок адресов. :)
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 53
  • Створено
  • Остання відповідь

Top Posters In This Topic

 

 

Ага... каждый абонент получит as и блок адресов.
 

Вполне себе, только вот сколько там для IPv6 минимальный блок для анонсов?

Если можно анонсить \64 - то всё в шеколаде :D

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

 

Ага... каждый абонент получит as и блок адресов.

 

Вполне себе, только вот сколько там для IPv6 минимальный блок для анонсов?

Если можно анонсить \64 - то всё в шеколаде :D

 

RIPE повесится от наплыва желающих :)
Ссылка на сообщение
Поделиться на других сайтах

 

Ага... каждый абонент получит as и блок адресов.

 

Вполне себе, только вот сколько там для IPv6 минимальный блок для анонсов?

Если можно анонсить \64 - то всё в шеколаде :D

 

вроде /48 пытаются раздавать и планируют сделать мировую таблицу маршрутизации меньше чем у ipv4
Ссылка на сообщение
Поделиться на других сайтах

ну я знаю про практику \32-\48, просто решил уточнить, у них как в голове чего-нибудь перевернется, так и пойдут менять стандарты... :)

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

чем это Вам это поможет?

Всегда актуальным автоматическим выбором оптимального маршрута. В инете маршрутизация поменялась - и я обновлённую информацию в течении нескольких минут получил в машинопонятном виде. Відредаговано bsdadm
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Ой горе .. оспф и поляма роутов.

Не надо передёргивать. OSPF для собственных сетей провайдера и его соседей. Чтоб хотя бы на самого провайдера через его канал ходить. Без заглядывания на сайт и набивания таблицы руками.

 

З.Ы.: А вообще мне непонятно, что в этой теме делают те, у кого она вызывает смех? Предотвращают внедрение конкурентами путём давления на эмоции?

 

Целевая аудитория данной услуги?

Гики и юрики, не имеющие своей автономной системы и лишних денег для эксклюзивных услуг. Відредаговано bsdadm
Ссылка на сообщение
Поделиться на других сайтах

 

чем это Вам это поможет?

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

Несколько минут на то что бы BGP осознало падение сессии и в конечном итоге повернуло все что есть во вторую ногу. Или 500-600 мс на осознание того что связность оборвалась и нужно удавить соответсвющий дефолтный статик роут.

Вы что выбрали бы? - я второе. Ибо проще, быстрее и менее ресурсоемко.

 

При этом в обоих случаях один хрен инициированные сетевые взаимодействия оборвутся - НАТ все изуродует.

 

По этому я и говорю, что предлагаемая Вами услуга обладает херовым качеством и практически никому не нужна.

Відредаговано Гайджин
Ссылка на сообщение
Поделиться на других сайтах

Гики и юрики, не имеющие своей автономной системы и лишних денег для эксклюзивных услуг.

Юрики, не имеющие лишних денег, но имеющие дурных админов обязаны пострадать.

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

Відредаговано Гайджин
Ссылка на сообщение
Поделиться на других сайтах

Я вот не пойму смысл идеи, ну как клиент может управлять маршрутизацией к своему IP ? Да никак .  

Со стороны роутера провайдера  конфиг получится из серии "можноповесится", потому-что клиенту НУЖНО чего-то анонсить  что бы управлять маршрутизацией от провайдера к себе ,  если брать оспф линк стейт  протокол (bfd  косяк ?? ) попробуйте на нем редистрибьюдить  пол ляма маршрутов  ! 

 

ТС  я вам открою секрет идея подобная вашей уже работает, реализована на BGP + RR  интерфейсы ip unnumbered и этот сервис не может быть бесплатным, так он требует дополнительных затрат на старте  и поддержке .  

Відредаговано Ajar
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Ajar, Вы невнимательно читали тему. Со стороны роутера провайдера конфиг будет из серии три строчки на все 100500 клиентов, потому, что клиенту НЕ нужно ничего анонсить. И более того, он может быть совсем даже не на роутере, а на соседней системе (route server), в т. ч. виртуальной, через которую транзитный трафик ходить вообще не будет. Например на лукинг глассе.

Гайджин, я хочу использовать каналы не по холодной схеме (рабочий плюс резервный), а по горячей (рабочий плюс рабочий с автоматическим переключением и бескостыльным выбором кратчайшего маршрута). Деление инета на что-то типа 0/1 и 128/1 это плохая реализация горячей схемы. И разница между минутами и милисекундами тут не важна. Если понадобится, для неё будет своё решение. Я уже понял, что Вы этим пользоваться не хотите. Не пользуйтесь. Предоставлять тоже не хотите. Не предоставляйте. Не надо только убеждать меня, что мне не надо хотеть того, что я хочу, и других операторов, что им не надо реализовывать того, что я предлагаю.

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

 

 

Не надо только убеждать меня, что мне не надо хотеть того, что я хочу, и других операторов, что им не надо реализовывать того, что я предлагаю.

Так реализовывайте кто вам не дает. Только смысл этой канители без AS и своего пула адресов нулевой и даже вредный местами

Поясняю, вы смотрите к примеру кино онлайн или в игру играете и тут бац!  путь через другой нат стал короче))) 

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

Ajar, Вы невнимательно читали тему. Со стороны роутера провайдера конфиг будет из серии три строчки на все 100500 клиентов, потому, что клиенту НЕ нужно ничего анонсить.

Я ВАС внимательно читал. Вы просто не понимаете механизмы воздействия протокола bgp   на входящий  и исходящий трафик.  Как ВЫ повлияете (средствами протоколов маршрутизации) на прохождения пакетов от чужой  AS  на ваш IP ?  

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

смотрите к примеру кино онлайн или в игру играете и тут бац! путь через другой нат стал короче

Во первых это довольно редкое явление. Во вторых пакеты установленных сессий продолжат идти по длинному маршруту. По короткому пойдут только новые. Ну а в третьих я не утверждал, что это решение всех проблем. Теперь попробуйте привести пример удобного использования статических маршрутов когда через один из каналов становится недоступна какая-то неизвестная заранее АС?

Я ВАС внимательно читал. Вы просто не понимаете механизмы воздействия протокола bgp на входящий и исходящий трафик.

Вам показалось. Видимо потому, что Вы не поняли сути предлагаемого.

Как ВЫ повлияете (средствами протоколов маршрутизации) на прохождения пакетов от чужой AS на ваш IP ?

Я не собираюсь на это влиять. Для этого надо регить свою АС и большой блок адресов, который будет проходить через префикслисты магистральных маршрутизаторов. Статика и анонс своих адресов это две противоположных крайности. Я предлагаю промежуточное решение - только получать и на этой основе ходить в разные АС с разных адресов. От чужой АС пакеты на мой адрес будут идти по тому маршруту, по которому адрес анонсирован соответствующим провайдером в составе адресного блока. Но если у меня два адреса от разных провайдеров, то маршруты с этих адресов на произвольную АС может отличаться друг от друга. И если на пути маршрутизации не ставились костыли, то маршрут будет симметричным. Это то-же самое, что статические маршруты на 0/1 и 128/1 через разные каналы, только с учётом кратчайшего пути до каждого отдельно взятого /23. И меняющиеся одновременно с изменениями в реальной маршрутизации, а не раз в году руками после трассировки на 100500 разных адресов. Відредаговано bsdadm
Ссылка на сообщение
Поделиться на других сайтах

 

смотрите к примеру кино онлайн или в игру играете и тут бац! путь через другой нат стал короче

Во первых это довольно редкое явление. Во вторых пакеты установленных сессий продолжат идти по длинному маршруту. По короткому пойдут только новые. Ну а в третьих я не утверждал, что это решение всех проблем. Теперь попробуйте привести пример удобного использования статических маршрутов когда через один из каналов становится недоступна какая-то неизвестная заранее АС?

 

Довольно редкое явление изменения длинны пути ?

Видимо вы шото не дочитали про BGP. С какого это перепуга пакеты установленных соединений должны  идти по длинному маршруту?

А что за неизвестная заранее АС к которой пропал маршрут? бред не пишите откровенный

Вся тема из разряда "хочется странного"

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Довольно редкое явление изменения длинны пути ?

Да. Я после настройки анонсов обычно бгп не трогаю. А Вы наверное каждый вечер число препендов меняете?

Видимо вы шото не дочитали про BGP.

Судя по предыдущей реплике недочитали скорее Вы.

С какого это перепуга пакеты установленных соединений должны идти по длинному маршруту?

Перепуг называется роуте кешем, коннекшен трекингом, стейтфулом и прочими словами в зависимости от ОС и используемых технологий и к протоколу маршрутизации никакого отношения не имеет.

А что за неизвестная заранее АС к которой пропал маршрут?

Это та, на которую не было отдельного маршрута и отдельного мониторинга. Например через канал А сделан статический маршрут на 0/1. Мониторится 8.8.8.8. Отваливается 38.4.5.0/хх. 8.8.8.8 продолжает быть доступен и оснований для внесения изменений в таблицу маршрутизации нет. Или наоборот, отваливается только 8.8.8.8 и весь 0/1 переписывается на канал Б, хотя в этом не было необходимости. Я уже понял, что Вы критикуете не пытаясь вникать в суть критикуемого. Т. е. троллите.

бред не пишите откровенный

Вся тема из разряда "хочется странного"

Спасибо, Ваша позиция ясна. Прошу Вас больше в этой теме не флеймить. И так уже три страницы из пустого в порожнее. Тем, кого это заинтересует, прочитать всё будет трудно. Конструктива от Вас я здесь ни разу не увидел.

ТС уверен что путь с меньшим количество AS-PATH более скоростной ?

Это что-то меняет или просто оправдание чтобы не делать? Відредаговано bsdadm
Ссылка на сообщение
Поделиться на других сайтах
Это что-то меняет или просто оправдание чтобы не делать?

Тут вопрос скорее в том зачем это делать ?

Вот я к примеру юзер,я могу настроить BGP и многое другое,у меня 10 аплинков, зачем мне все это без АС и своего пула?

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

 

Это что-то меняет или просто оправдание чтобы не делать?

Тут вопрос скорее в том зачем это делать ?

Вот я к примеру юзер,я могу настроить BGP и многое другое,у меня 10 аплинков, зачем мне все это без АС и своего пула?

 

из 10х500000  маршрутов выбирать лучшие 

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

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...