motorhunter Опубликовано 27 января, 2014 · Жалоба Доброго времени суток! Ситуация такая - имеем AS, PI и стык с одним аплинком по BGP. Аплинку анонсируем свои сети, принимаем дефолт. При этом у нашей AS в RIPE DB прописаны такие строки (лишнее вырезано): aut-num: ASXXXX import: from ASYYYY action pref=20; accept ANY export: to ASYYYY announce ASXXXX ASXXXX - наша автономная система, ASYYYY - аплинк. Стоит задача переключиться на другого аплинка (при этом старый стык убрать). У него, естественно другая AS. Должен ли я прописать соответствующие строки import/export для автономной системы нового аплинка в RIPE DB (и убрать текущие)? Или же и без этого стык заработает? Проверяется ли как-то соответствие реальных анонсов BGP на стыках операторов с указанными в RIPE DB? Кто это делает, каков механизм? Поясните, пожалуйста, хотя бы в двух словах, или подскажите, где об этом можно почитать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 27 января, 2014 · Жалоба Вот из-за таких моментов иногда и хочется бить морду ((( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
motorhunter Опубликовано 27 января, 2014 · Жалоба pppoetest, будьте любезны, объяснитесь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 27 января, 2014 · Жалоба motorhunter у нового аплинка нужно прописать. у старого можно не удалять. но лучше попросить удалить - для порядка очень многие проверяют Вот из-за таких моментов иногда и хочется бить морду ((( кому и за что? нормальный вопрос был задан Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 27 января, 2014 · Жалоба Работать будет, но прописать нужно. Иначе pppoetest... Некоторые строят фильтры автоматически на основе данных ripe, почти все смотрят в ripe для понимаю что и как. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 27 января, 2014 · Жалоба По хорошему надо прописать. А можно и болт покласть, я знаю ни один случай когда клиент живет годами со всякой чушью в import/export и никто не помер. Хотя да, не по канону! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 27 января, 2014 · Жалоба Доброго времени суток! Ситуация такая - имеем AS, PI и стык с одним аплинком по BGP. Аплинку анонсируем свои сети, принимаем дефолт. При этом у нашей AS в RIPE DB прописаны такие строки (лишнее вырезано): aut-num: ASXXXX import: from ASYYYY action pref=20; accept ANY export: to ASYYYY announce ASXXXX ASXXXX - наша автономная система, ASYYYY - аплинк. Стоит задача переключиться на другого аплинка (при этом старый стык убрать). У него, естественно другая AS. Должен ли я прописать соответствующие строки import/export для автономной системы нового аплинка в RIPE DB (и убрать текущие)? Или же и без этого стык заработает? Проверяется ли как-то соответствие реальных анонсов BGP на стыках операторов с указанными в RIPE DB? Кто это делает, каков механизм? Поясните, пожалуйста, хотя бы в двух словах, или подскажите, где об этом можно почитать. Описание aut-num можно заполнить для порядка, а можно забить, оно ни на что не влияет. Гораздо важнее, чтобы новый аплинк добавил вашу AS в свой AS-SET, чтобы ваши анонсы не фильтровались на более высоких уровнях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 27 января, 2014 · Жалоба База RIPE используется СПРАВОЧНО. Т.е. теоретически должно работать даже если в route прописать левую AS. Но - большинство операторов для собственной защиты специальными программками строят по базе RIPE фильтры - т.е. принимают только те анонсы, которые соответствуют БД. Это защищает от таких ситуаций, как анонсирование одним из пиром чужих сетей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 27 января, 2014 · Жалоба Описание aut-num можно заполнить для порядка, а можно забить, оно ни на что не влияет. Гораздо важнее, чтобы новый аплинк добавил вашу AS в свой AS-SET, чтобы ваши анонсы не фильтровались на более высоких уровнях. +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nwton Опубликовано 27 января, 2014 · Жалоба Наиболее спокойный вариант: 1) у себя в aut-num: ASXXXX добавить новые import/export 2) попросить новый аплинк прописать в aut-num и as-set который он анонсирует вашу AS 3) проконтролировать, что все записалось 4) поднять стык с новым аплинком 5) погасить стык со старым аплинком 6) удалить из своей автономки упоминание о старом аплинке pppoetest, будьте вежливы. Все таки в России почти каждый оператор является LIR, но не у всех хватает квалификации. Нормально спросили - нормально и ответить надо, а то ведь motorhunter мог ничего и не делать. Скорее всего даже бы заработало, т.к. аплинк бы все настроил у себя, но это было бы полностью неправильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
motorhunter Опубликовано 27 января, 2014 · Жалоба Описание автономной системы заполнено корректно (AS создавал LIR, сами мы LIRом не являемся), я просто вырезал ненужную информацию (о чем честно написал). Спасибо за ответы. Конечно, переключения ещё не было, именно для того, чтобы сделать правильно, и был задан вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MrNv Опубликовано 28 января, 2014 · Жалоба Да да, есть такие нигодяи которые не подчищают за собой, потом заходишь на https://www.robtex.com/ смотришь свою AS'ку а там всякие левые пиры отображаются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 29 января, 2014 · Жалоба Направьте плз на правильный путь. Так имеем в БД RIPE Object inetnum примерно след. ввида: inetnum: 10.0.0.0 - 10.0.15.255 Стало необходимость(в целях оптимальной маршрутизации и нагрузки каналов) дробить сеть на префикси /24. При создания нового Object-а inetnum к примеру: inetnum: 10.0.0.0 - 10.0.0.255 получаю ошибку: ***Error: inetnum parent has incorrect status: ASSIGNED PA Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 29 января, 2014 · Жалоба А нафига вам inetnum-ы дробить? Дробите route например. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 29 января, 2014 · Жалоба А нафига вам inetnum-ы дробить? Дробите route например. route давно благополучно дробил на префиксы /24. Но некоторые спецы сказали что не везде маршрутизация будет правильно работать, по их словам объекты inetnum должны совпадать с route! Сейчас у меня два inetnum по /21, и 15 route объектов по /24, ну и + /20 суммарный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 29 января, 2014 · Жалоба Что за спецы такие? inetnum выделяется блоком на одного пользователя. route могут быть хоть /30, другое дело что меньше /24 зафильтруют сразу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 29 января, 2014 · Жалоба Что за спецы такие? inetnum выделяется блоком на одного пользователя. route могут быть хоть /30, другое дело что меньше /24 зафильтруют сразу. т.е. правильно ли я понял, что достаточно прописать объект роут к примеру: route: 10.0.0.0/24 origin: AS1111 и маршрутизация в интернет будет правильно работать для префикса 10.0.0.0/24? и крупные вышестоящие апстримы(которые сторят свои фильтры по БД RIPE) меня(10.0.0.0/24) пропустят? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 29 января, 2014 · Жалоба flamaster не только. нужно ещё чтоб аплинки добавили вашу AS в свои as-set Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 29 января, 2014 · Жалоба Да, апстримы как правило строят фильтры по объектам route, ну и связность по БД ripe должна присутствовать (наличие в as-set апстрима). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 30 января, 2014 · Жалоба Да, апстримы как правило строят фильтры по объектам route, ну и связность по БД ripe должна присутствовать (наличие в as-set апстрима). естественно as-set мой добавлен в as-set провайдера и так до вверха... Большое вам спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 30 января, 2014 · Жалоба pppoetest, будьте любезны, объяснитесь. похоже парниша не знает что такое BGP но не отписаться в топике не может. посему такая реакция. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nwton Опубликовано 10 февраля, 2014 · Жалоба route давно благополучно дробил на префиксы /24. Но некоторые спецы сказали что не везде маршрутизация будет правильно работать, по их словам объекты inetnum должны совпадать с route! Неправильные спецы, т.к. inetnum вообще никак не связан с CIDR, поэтому легко можно выделить для разных клиентов inetnum: 10.0.0.0-10.0.0.12 - для одного, 10.0.0.13-10.0.0.17 для другого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...