Jump to content

Recommended Posts

Posted

Здравствуйте.

PPPoE интерфейс на микротике после пере подключения получает от провайдера белый динамический ip а иногда серый.

Так вот, при получении белого, сервис IP Cloud нормально получает доменное имя, а сером соответственно нет.

Подскажите как заставить PPPoE пере подключатся до получения белого ip что бы Cloud получил доменное имя?

Posted (edited)

daff , создайте для PPPoE-клиента отдельный PPP-профиль. В свойствах профиля есть скрипты "on-up" и "on-down". В эти скрипты передается назначенный IP-адрес в виде переменной $local-address MikroTik wiki
Анализируйте содержимое переменной, и по условию переключайте интерфейс enable/disable. Либо вызывайте из этого скрипта общий системный скрипт переподключения.

Edited by nkusnetsov
Posted

Кстати да, можно попробовать без скриптов, отследить у какого сервера он получает белый, а у какого серый и в свойствах указать сервер белых IP.

2017-09-18_13-05-57.png

2017-09-18_13-06-28.png

Posted (edited)
35 минут назад, nkusnetsov сказал:

777BLOODER777 , это если сервера разные и у них сконфигурирован разный AC Name. В случае, если bras один с разными пулами - спасет только скрипт.

Согласен, забыл нюанс дописать.

 

Edited by 777BLOODER777
Posted
2 часа назад, nkusnetsov сказал:

Анализируйте содержимое переменной, и по условию переключайте интерфейс enable/disable. Либо вызывайте из этого скрипта общий системный скрипт переподключения.

Благодарю но в скриптах совсем не силен )

Буду пробовать вариант  777BLOODER777 

Так как действительно у провайдера два bras.

21 минуту назад, DRiVen сказал:

из какого(их) диапазона(ов) серые адреса выдаются?

10.х.х.х и 172.х.х.х

Posted
/ppp profile add name=pppoe on-up="
:global newIP [/ip address get [find interface="pppoe-out1"] address];

:if ($newIP in 10.0.0.0/8 || 172.16.0.0/12) do={

/interface pppoe-client disable pppoe-out1
:delay 5
/interface pppoe-client enable pppoe-out1
}"

Профиль указать в рррое-соединении.

Posted

Всем благодарствую !

Буду пробовать оба варианта.

Я так понимаю скрипт надежнее

и в случае если появится еще один пул серых адресов то его можно будет добавить в этот скрипт так :

($newIP in 10.0.0.0/8 || 172.16.0.0/12 || X.X.X.X/X)

где х.х.х.х/х это новый пул.

Posted
Только что, nkusnetsov сказал:

777BLOODER777 , там не все серые указаны. Есть еще официально подсеть 100.64.0.0/10 и другие диапазоны .  Хз на что еще хватит фантазии оператора смешивающего пулы.

Ну это уже извращенцем надо быть чтоб такие подсети впаривать =))

Posted
4 минуты назад, nkusnetsov сказал:

извращенцы из Ростелекома

Вот вы лихой какой шашкомахатель. Пулы смешивают не из желания, а от необходимости, когда, к примеру, на крупном сегменте белых уже не хватает, RIPE ничего не дает, а подключать надо. Вы как себе представляете одномоментно вынести несколько сотен тысяч подключений за NAT? Пул BRASов в соответствии со стратегией резервирования строится, а не адресного разделения.

Posted (edited)
7 часов назад, DRiVen сказал:

Вот вы лихой какой шашкомахатель. Пулы смешивают не из желания, а от необходимости, когда, к примеру, на крупном сегменте белых уже не хватает, RIPE ничего не дает, а подключать надо. Вы как себе представляете одномоментно вынести несколько сотен тысяч подключений за NAT? Пул BRASов в соответствии со стратегией резервирования строится, а не адресного разделения.

Это от великой жадности, когда мега-манагеры набирают абонентскую базу не подкрепив ресурсами - каналами, адресной ёмкостью, оборудованием. Такие игры с абонентами в повезло/неповезло вполне в духе эффективного менеджмента и ими обескровленного инженерно-технического состава.
Лихим манагерам ростелекома - вечная слава.

Edited by nkusnetsov
Posted

Насчет эффективного менеджмента и обескровленного ИТР не спорю, но это касается, к сожалению, не только РТК, а вообще всех крупных ISP. Что насчет игр - тип выдаваемого подключению адреса никак не регламентируется, по договору предоставляется доступ в публичную сеть, а каким образом это реализовано - технологические особенности конкретного сегмента сети провайдера. Все крупные ISP из-за нехватки адресов абонентов за NAT выносят. Считаете что лучше всех без исключения в серый диапазон отправить?

Posted
1 час назад, nkusnetsov сказал:

Это от великой жадности

Жадность тут не причем.

100.64.0.0/10 для NAT это гораздо правильнее, чем 10.0.0.0/8 или 172.16.0.0/12.

И значительной доле абонентов совершенно без разницы, будет у него публичный IP или NAT.

Posted (edited)

Жадность манагеров приводит к нездоровым игрушкам типа рулетки "что выпадет белое или серое". "Кому-то повезёт, кому-то не повезет", вместо четко закрепленных условий подключения.
Выдавали бы уж всем серые адреса. Нафига лотерею-то устраивать и людей с толку сбивать? Всё равно выданным таким образом "белым"(если повезло) адресом без "костылей" пользоваться нельзя. Смысл его теряется. 

Edited by nkusnetsov
Posted
2 часа назад, nkusnetsov сказал:

Всё равно выданным таким образом "белым"(если повезло) адресом без "костылей" пользоваться нельзя.

Поясните о чем речь. Выдаваемые РТК белые адреса честные (маршрутизируемые), скрипт нужен только для его (адреса) получения и то далеко не всегда, попадание в серую зону происходит, в основном, при переподключении в ЧНН.

Posted (edited)

Поясняю еще раз. В ситуации, когда заранее неизвестно какой "белый" или "серый" адрес будет выдан, вообще нет смысла выдавать "белые" адреса.
1) Абоненту, которому важно иметь именно "белый", маршрутизируемый адрес такая лотерея вредит. Порой усложняет настройку и отладку.

2) Абоненту, которому НЕ важно маршрутизируемый у него адрес или НЕТ, вполне сойдет и "серый". Значит, это тупой перерасход "белых" адресов.

Это почти как продавать телефоны, у которых с вероятностью N% не будет работать входящая связь. Кому-то повезёт, кому-то нет.
Вместо чётких технический условий подключения - сомнительная лотерея.

Edited by nkusnetsov
Posted
56 минут назад, nkusnetsov сказал:

Вместо чётких технический условий подключения - сомнительная лотерея.

Мир устроен сложнее, чем думают некоторые.

Posted (edited)

Здравствуйте.

В общем, скрипт работает, но вышла такая забавная ситуация :)

:global newIP [/ip address get [find interface="PPPoE"] address];

:if ($newIP in 10.0.0.0/8 || 172.16.0.0/12) do={

/interface pppoe-client disable PPPoE

:delay 5

/interface pppoe-client enable PPPoE

}

Судя по всему PPPoE пере подключился и тут частично отработал скрипт а именно его часть

(/interface pppoe-client disable PPPoE)

А после этой строки идет (  :delay 5 )

Так вот в эти 5 секунд отключился свет :)

И интерфейс PPPoE после включения света остался выключен.

Подскажите правильно ли будет сделать так ?

 

В секцию UP поместить скрипт :

:global newIP [/ip address get [find interface="PPPoE"] address];

:if ($newIP in 10.0.0.0/8 || 172.16.0.0/12) do={

/interface pppoe-client disable PPPoE

}

А в секцию DOWN :

:delay 5

/interface pppoe-client enable PPPoE

Edited by daff
Posted
6 минут назад, alibek сказал:

Правильно будет включить его вручную и поставить ИБП.

Дело в том что это устройство находится далеко

И включать его в ручную после возникновения такой ситуации проблематично.

 

Вопрос о ИБП уже рассматривается

но хотелось бы избежать таких казусов :)

Posted

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

Скрипт нужно вешать не на DOWN, а на загрузку устройства. Либо использовать SAFE MODE.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...