Коллеги, подскажите катализатор для нокеров LuckyNet, который поможет решить проблему до обеда завтра (суббота). Во вторник попросили LuckyNet сменить connected-сеть на ip-номера из пула Лаков (до этого линк работал на наших). Вчера сделали, но есть трабл. Сеть выдали из блока 193.124.50.0/24, который входит в блок 193.124.0.0/15 (RELCOM-AS). В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется. #show ip bgp 193.124.50.0 BGP routing table entry for 193.124.0.0/15, version 782348 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 12530 3216 20485 2118 <skip> Origin incomplete, localpref 100, valid, external, best Community: 210764776 210764780 210764884 821168282 821196137 1342516737 В Лаки о проблеме сообщил. Но предыдущий опыт общения и скорость реакции не сулит разрешение проблемы до указанного времени. HELP! a@gw071kv:~$whois 193.124.50.0/24 % Information related to '193.124.50.0/24AS3254' route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT source: RIPE # Filtered % Information related to '193.124.0.0/15AS2118' route: 193.124.0.0/15 descr: EUnet/RELCOM descr: Russia, Moscow origin: AS2118 remarks: removed cross-mnt: AS2118-MNT mnt-by: AS2118-MNT mnt-lower: AS2118-MNT mnt-routes: AS2118-MNT source: RIPE # Filtered
Нужно подключаться на интерфейсный адрес маршрутизатора.
# traceroute 193.124.50.98
Type escape sequence to abort.
Tracing the route to 193.124.50.98
1 * * * 10 msec 0 msec 0 msec
2 158.250.242.189 10 msec 0 msec 0 msec
3 158.250.229.97 10 msec 10 msec 10 msec
4 158.250.234.1 10 msec 10 msec 10 msec
5 158.250.245.46 0 msec 10 msec 0 msec
6 193.232.244.33 10 msec 10 msec 10 msec
7 * * *
8 * * *
9 * * *
10 193.232.244.33 !H * *
24 июля 2009 г. 22:38 пользователь Roman Emelyanov
Hi,
А в чем проблема-то?
-- R:Em
Fri, Jul 24, 2009 at 22:23:30, unrealbox wrote about "[uanog] Выдали адреса из 193.124.50.0/24":
подскажите катализатор для нокеров LuckyNet, который поможет решить проблему до обеда завтра (суббота). Во вторник попросили LuckyNet сменить connected-сеть на ip-номера из пула Лаков (до этого линк работал на наших).
А зачем было это изменение? Чем на своих не сиделось?
Вчера сделали, но есть трабл. Сеть выдали из блока 193.124.50.0/24, который входит в блок 193.124.0.0/15 (RELCOM-AS).
Нет. route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT changed: hostmaster@lucky.net 19950816 source: RIPE Вы сами же это привели и после этого говорите, что Relcom. Нелогично.
В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется.
Это намеренно не анонсируется. (причину уже не помню) -netch-
On Fri, Jul 24, 2009 at 10:23:30PM +0300, Andrey Kozlov wrote:
Коллеги,
подскажите катализатор для нокеров LuckyNet, который поможет решить проблему до обеда завтра (суббота).
Во вторник попросили LuckyNet сменить connected-сеть на ip-номера из пула Лаков (до этого линк работал на наших). Вчера сделали, но есть трабл. Сеть выдали из блока 193.124.50.0/24, который входит в блок 193.124.0.0/15 (RELCOM-AS).
Входить-то она входит, вот только выдана она была Дядюшке AY еще в те времена, когда в Релкомовском договоре не было пункта о "возврате адресного пространства". Соответственно, после отключения Lucky от Relcom'а (году этак в 1996'ом или 97'ом) эта сеть отдана не была, о чем и RIPE говорит: route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT source: RIPE # Filtered
В глобальной таблице, естественно, garbage зафильтрован.
Это не garbage, это вполне нормальная сеть со вполне нормальным route-object'ом. И если бы она анонсировалась - была бы видна по всему миру...
В UA-IX оно тоже не анонсируется.
И не будет анонсироваться. По крайней мере до смены политики, написанной еще Gene & Goo: "connected-сети для bgp-peer'ов и клиентов, подключенных по BGP выдаются из отдельной /24, которая за пределы Lucky.Net не анонсируется". Причиной стало, afair, "не совсем корректное" (чтобы не сказать больше) поведение одного из пиров, который повесил NAT на интерфейсный адрес и пользовал интернет нашару...
#show ip bgp 193.124.50.0 BGP routing table entry for 193.124.0.0/15, version 782348 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 12530 3216 20485 2118 <skip> Origin incomplete, localpref 100, valid, external, best Community: 210764776 210764780 210764884 821168282 821196137 1342516737
В Лаки о проблеме сообщил. Но предыдущий опыт общения и скорость реакции не сулит разрешение проблемы до указанного времени.
Это не бага, это фича (c). Если вам нужно цепляться к своему раутеру снаружи - пропишите на каком-нибудь loopback'е адрес из своего блока и цепляйтесь к нему...
HELP!
a@gw071kv:~$whois 193.124.50.0/24
% Information related to '193.124.50.0/24AS3254' route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT source: RIPE # Filtered
% Information related to '193.124.0.0/15AS2118'
route: 193.124.0.0/15 descr: EUnet/RELCOM descr: Russia, Moscow origin: AS2118 remarks: removed cross-mnt: AS2118-MNT mnt-by: AS2118-MNT mnt-lower: AS2118-MNT mnt-routes: AS2118-MNT source: RIPE # Filtered
On Sat, Jul 25, 2009 at 11:46:43AM +0400, Alexandre Snarskii wrote:
On Fri, Jul 24, 2009 at 10:23:30PM +0300, Andrey Kozlov wrote:
Входить-то она входит, вот только выдана она была Дядюшке AY еще в те времена, когда в Релкомовском договоре не было пункта о "возврате адресного пространства". Соответственно, после отключения Lucky от Relcom'а (году этак в 1996'ом или 97'ом) эта сеть отдана не была, о чем и RIPE говорит:
Хм, ваще-то релком пинал всех (нас с 193.124.54.0/24 и 193.124.48.0/24) на предмет оплаты... Из граблей с релкомами - когда-то их /15 попал в RBL какой-то - пришлось писать про "еще в те времена, когда..." и открещиваться от релкома.
за пределы Lucky.Net не анонсируется". Причиной стало, afair, "не совсем корректное" (чтобы не сказать больше) поведение одного из пиров, который повесил NAT на интерфейсный адрес и пользовал интернет нашару...
чего просто не взять было 10/8 или чего ещё...? -- Best regards, Paul Arakelyan.
Добрый день! On Sat, Jul 25, 2009 at 01:34:21AM +0300, Valentin Nechayev wrote:
route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT changed: hostmaster@lucky.net 19950816 source: RIPE
В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется.
Это намеренно не анонсируется. (причину уже не помню)
Нарушаете однако: 2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes -- Dmitry Kiselev
On Mon, Jul 27, 2009 at 10:03:53AM +0300, Dmitry Kiselev writes: DK> On Sat, Jul 25, 2009 at 01:34:21AM +0300, Valentin Nechayev wrote:
route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT changed: hostmaster@lucky.net 19950816 source: RIPE
В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется.
Это намеренно не анонсируется. (причину уже не помню)
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов. DK> Нарушаете однако: DK> 2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS DK> т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes Давай не будем ориентироваться на явно нелепые пункты договора UA-IX. ;) Иначе получается как совке: законы написаны так, чтобы посадить можно было любого. Найди 10 отличий: # bgpq3 -P AS25229 no ip prefix-list NN ip prefix-list NN permit 77.120.0.0/14 ip prefix-list NN permit 77.120.0.0/16 ip prefix-list NN permit 77.120.0.0/20 ip prefix-list NN permit 77.120.60.0/22 ip prefix-list NN permit 77.120.96.0/19 ip prefix-list NN permit 77.120.96.0/20 ip prefix-list NN permit 77.120.112.0/20 ip prefix-list NN permit 77.120.112.0/22 ip prefix-list NN permit 77.120.240.0/20 ip prefix-list NN permit 77.120.240.0/22 ip prefix-list NN permit 77.120.248.0/21 ip prefix-list NN permit 77.121.0.0/16 ip prefix-list NN permit 77.122.0.0/16 ip prefix-list NN permit 77.123.0.0/16 ip prefix-list NN permit 82.144.192.0/19 ip prefix-list NN permit 82.144.192.0/22 ip prefix-list NN permit 82.144.192.0/24 ip prefix-list NN permit 82.144.193.0/24 ip prefix-list NN permit 82.144.194.0/24 ip prefix-list NN permit 82.144.195.0/24 ip prefix-list NN permit 82.144.208.0/20 ip prefix-list NN permit 82.144.220.0/22 ip prefix-list NN permit 93.72.0.0/13 ip prefix-list NN permit 93.72.0.0/16 ip prefix-list NN permit 93.73.0.0/16 ip prefix-list NN permit 93.74.0.0/16 ip prefix-list NN permit 93.75.0.0/16 ip prefix-list NN permit 93.76.0.0/16 ip prefix-list NN permit 93.77.0.0/16 ip prefix-list NN permit 93.78.0.0/16 ip prefix-list NN permit 93.79.0.0/16 ip prefix-list NN permit 193.202.110.0/24 numbat#sh ip bgp nei 195.35.65.1 routes | inc 25229 i * 77.120.0.0/20 195.35.65.220 350 400 0 15645 25229 i * 77.120.60.0/22 195.35.65.220 350 400 0 15645 25229 i * 77.120.96.0/19 195.35.65.220 350 400 0 15645 25229 i * 77.120.240.0/22 195.35.65.220 350 400 0 15645 25229 i * 77.120.248.0/21 195.35.65.220 350 400 0 15645 25229 i * 77.122.0.0/16 195.35.65.220 350 400 0 15645 25229 i * 77.123.0.0/16 195.35.65.220 350 400 0 15645 25229 i * 82.144.192.0/19 195.35.65.220 350 400 0 15645 25229 i * 93.72.0.0/16 195.35.65.220 350 400 0 15645 25229 i * 93.72.0.0/13 195.35.65.220 350 400 0 15645 25229 i * 193.202.110.0 195.35.65.220 350 400 0 15645 25229 i numbat# -- Паша.
Добрый день! On Mon, Jul 27, 2009 at 10:32:16AM +0300, Pavel Gulchouck wrote:
route: 193.124.50.0/24 descr: SITA-NET origin: AS3254 mnt-by: AS3254-MNT changed: hostmaster@lucky.net 19950816 source: RIPE
В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется.
Это намеренно не анонсируется. (причину уже не помню)
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
Если эти все моменты описаны в договоре или каком-то другом регулирующем документе, то конечно да и саппорт должен был сослаться на это при обращении кастомера. Но если этого нет, то кастомер вправе расчитывать на получение услуги без подобных ограничений. А то опять какой-то AOL получается. IMHO.
DK> Нарушаете однако:
DK> 2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS
DK> т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes
Давай не будем ориентироваться на явно нелепые пункты договора UA-IX. ;)
Если договор не устраивает вы можете его не подписывать (разорвать) или попытаться внести в него изменения. Хочешь развалить UA-IX? Давно пора. Но не здесь и не сейчас.
Иначе получается как совке: законы написаны так, чтобы посадить можно было любого. Найди 10 отличий:
# bgpq3 -P AS25229
..skip..
numbat#sh ip bgp nei 195.35.65.1 routes | inc 25229 i
..skip.. А ты подними вопрос в staff@ и получишь объяснения почему именно так и почему это ничего не нарушает ;) -- Dmitry Kiselev
On Mon, Jul 27, 2009 at 11:00:53AM +0300, Dmitry Kiselev writes:
В UA-IX оно тоже не анонсируется.
Это намеренно не анонсируется. (причину уже не помню)
DK>> Нарушаете однако: DK>> 2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS
DK>> т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes [...]
# bgpq3 -P AS25229
DK> ..skip.. DK>
numbat#sh ip bgp nei 195.35.65.1 routes | inc 25229 i
DK> ..skip.. DK> А ты подними вопрос в staff@ и получишь объяснения почему именно так и DK> почему это ничего не нарушает ;) Ты поднял вопрос о нарушении Лаками договора здесь. Давай тогда ты здесь и объяснишь, почему отсутствие анонса Лаков, прописанного в RIPE, по твоему мнению является нарушением договора с UA-IX, а отсутствие прописанных в RIPE анонсов Воли - не нарушает. Cчитаешь ли ты, что Участник обязан отдавать на RS _всю_ таблицу маршрутизации своей AS, и, если да, то почему, а если нет - почему ты считаешь, что именно сетку с интерфейсными адресами обязан? Мне это интересно. Было бы с твоей точки зрения нарушение договора, если бы не было route object на эту интерфейсную сетку (а был только network object)? Кстати, на сайте ua-ix висит "Разъяснение к п 2.9", где сказано, что пункт 2.9 следует понимать как: "Участник обязан фактически принимать и отправлять трафик в соответствии с анонсами, принятыми от RS UA-IX". Очевидно, отсутствие анонса интерфейсной сети от Лаков эту трактовку не нарушает. Хотя я и совсем не понимаю, как я могу "фактически принимать трафик в соответствии с анонсами, принятыми от RS UA-IX". Это ведь тоже абсурд. Например, принимаю я анонсы Яндекса от RS UA-IX, а трафик от Яндекса принимаю не от UA-IX, а через свой российский линк - и этим я нарушаю договор? Смешно. Я не имею цели развалить UA-IX. Но я считаю, что в таком виде, в котором он сейчас есть, он жить не может. Например, если клиент A нашего клиента B подключился к UA-IX, по договору я обязан роутить его на UA-IX, а не на своего клиента B, ведь у меня с A явной договорённости нет. Выхода два: либо менять договор, приближая его к европейским точкам обмена, т.е. убирая из него обязательства участников по роутингу и аннонсированию, либо закрывать глаза на повальное игнорирование участниками требований договора. Сейчас происходит второе, т.е. игнорирование. Например, есть точки обмена, в которых тоже прописано, что приоритет полученных оттуда анонсов должен быть максимальным. И ничего - многие участвуют одновременно и в UA-IX, и в этих IX, не смущаясь несовместимостью условий договоров. :) Примеров много. Вот ещё: "Участнику запрещается анонсировать сеть, выделенную для обеспечения работы UA-IX (195.35.65.0/24). Сеть 195.35.65.0/24 предназначена исключительно для пиринга RS с маршрутизаторами". А зачем тогда эта сеть вообще отдаётся по BGP участникам? И почему look.ix.net.ua расположен в непредназначенной для этого сети? Как думаешь, многие ли участники анонсируют эту сеть своим клиентам? А если ориентироваться на то, что написано в RIPE? ;-) -- Паша.
On Sun, Jul 26, 2009 at 09:07:57PM +0300, Paul Arakelyan wrote:
On Sat, Jul 25, 2009 at 11:46:43AM +0400, Alexandre Snarskii wrote:
On Fri, Jul 24, 2009 at 10:23:30PM +0300, Andrey Kozlov wrote:
Входить-то она входит, вот только выдана она была Дядюшке AY еще в те времена, когда в Релкомовском договоре не было пункта о "возврате адресного пространства". Соответственно, после отключения Lucky от Relcom'а (году этак в 1996'ом или 97'ом) эта сеть отдана не была, о чем и RIPE говорит:
Хм, ваще-то релком пинал всех (нас с 193.124.54.0/24 и 193.124.48.0/24) на предмет оплаты...
Ну так это был уже второй вариант договора, который был и у Лаков, которые, в результате, сети, полученные от релкома, честно вернули. А в договоре с sita-net этого пункта не было, вот сеть и подвисла ;)
Из граблей с релкомами - когда-то их /15 попал в RBL какой-то - пришлось писать про "еще в те времена, когда..." и открещиваться от релкома.
за пределы Lucky.Net не анонсируется". Причиной стало, afair, "не совсем корректное" (чтобы не сказать больше) поведение одного из пиров, который повесил NAT на интерфейсный адрес и пользовал интернет нашару...
чего просто не взять было 10/8 или чего ещё...?
Почитай nanog, вопрос "почему не стоит использовать private address space на публичных линках" там обсуждается примерно раз в год ;)
Pavel Gulchouck wrote:
В глобальной таблице, естественно, garbage зафильтрован. В UA-IX оно тоже не анонсируется. Это намеренно не анонсируется. (причину уже не помню)
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
Услышал хоть одну причину не роутить интерфейсные IP. Но причина все равно несерьезная. Или вы хотите сказать, что dialup/broadband/и т.п. клиенты с реальными IP предстваляют большую опасность чем маршрутизаторы BGP-peer'ов? -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
Mon, Jul 27, 2009 at 10:03:53, dmitry wrote about "Re: [uanog] Выдали адреса из 193.124.50.0/24":
Это намеренно не анонсируется. (причину уже не помню) Нарушаете однако:
Что именно? Откуда цитата? Чего участник?
2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes
10/8 тоже обязан отдавать? -netch-
Alexandre Snarskii wrote:
В UA-IX оно тоже не анонсируется.
И не будет анонсироваться. По крайней мере до смены политики, написанной еще Gene & Goo: "connected-сети для bgp-peer'ов и клиентов, подключенных по BGP выдаются из отдельной /24, которая за пределы Lucky.Net не анонсируется". Причиной стало, afair, "не совсем корректное" (чтобы не сказать больше) поведение одного из пиров, который повесил NAT на интерфейсный адрес и пользовал интернет нашару...
А как связан NAT на интерфейсном адресе с интернетом нашару? Он ставил себе чужой интерфейсный адрес? Или там были проблемы с биллингом/шейпингом? -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
Добрый день! On Mon, Jul 27, 2009 at 12:20:50PM +0300, Valentin Nechayev wrote:
Это намеренно не анонсируется. (причину уже не помню) Нарушаете однако:
Что именно?
Договор между ДП "Украинская сеть обмена трафиком" и, простите не знаю вашего юр.лица подписавшего этот договор, но раз вы участник этой самой сети, то договра вами подписан.
Откуда цитата?
Из договора.
Чего участник?
см.выше
2.9. Участник обязан отдавать на RS таблицы маршрутизации своей AS т.е. все, что имеет origin AS3254 вы обязаны отдавать на RSes
10/8 тоже обязан отдавать?
Согластно договора - да. Если конечно соответствующий route object присутствует в RIPE DB и имеет в поле origin ASN участника. В силу ряда причин, такой объект не может быть создан, соответсвенно, договор не нарушается. -- Dmitry Kiselev
Mon, Jul 27, 2009 at 12:32:14, dmitry wrote about "Re: [uanog] Выдали адреса из 193.124.50.0/24":
Это намеренно не анонсируется. (причину уже не помню) Нарушаете однако: Что именно? Договор между ДП "Украинская сеть обмена трафиком" и, простите не знаю вашего юр.лица подписавшего этот договор, но раз вы участник этой самой сети, то договра вами подписан.
Как старший программист Massive Solutions Inc., заявляю, что данная организация не имеет ни AS, ни своего блока адресов, и не имеет договора с указанным ДП, в котором был бы возможен такой пункт. Хотя, если данное ДП будет заинтересовано в услугах по High Performance Computing (ну там кластерок построить на сотню терафлопс), я с удовольствием передам предложение нашим вождям. Если же речь была про LuckyNet, то 1) слово "нарушаете" по отношению ко мне некорректно 2) Паша уже всё объяснил.
10/8 тоже обязан отдавать? Согластно договора - да. Если конечно соответствующий route object присутствует в RIPE DB и имеет в поле origin ASN участника. В силу ряда причин, такой объект не может быть создан, соответсвенно, договор не нарушается.
В route object можно и про сарай с дровами написать, но если нет фактического анонса, то он не должен учитываться. -netch-
On Mon, Jul 27, 2009 at 12:20:46PM +0300, Vladimir Garnick writes:
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
VG> Услышал хоть одну причину не роутить интерфейсные IP. Но причина все VG> равно несерьезная. Или вы хотите сказать, что dialup/broadband/и т.п. VG> клиенты с реальными IP предстваляют большую опасность чем маршрутизаторы VG> BGP-peer'ов? Конечно, от dialup/broadband и т.п. спама и прочей нечисти больше. Но дело в том, что в случае dialup/broadband и т.п. сеть специально выделена для пользователей, для этой сети работает abuse team. А интерфейсные адреса - они не выделены для пользователей, это внутренняя сетка ISP. И в случае спама из этой сети отфильтрован может быть весь ISP. Прецеденты, когда из-за активности с интерфейсного IP в blacklist занесли наши MX-ы, уже были (а единственная связь - email в network object, из которого шёл спам). Другая возможная причина: разная роутинговая политика собственных сетей и сетей клиента. Например, клиент может покупать только доступ к UA-IX, а интерфейсный адрес будет при этом виден со всего мира. А какие есть причины роутить трафик на интерфейсные IP, если на интерфейс взяты IP апстрима? Это ведь не IP клиента. Хочет - роутит, не хочет - не роутит. Только для того, чтобы клиент имел доступ извне к своему роутеру в случае проблем с BGP? По договору обычно апстрим обязан предоставлять сервис для клиентских сетей, интерфейсные к ним не относятся. -- Паша.
Pavel Gulchouck wrote:
On Mon, Jul 27, 2009 at 12:20:46PM +0300, Vladimir Garnick writes:
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
VG> Услышал хоть одну причину не роутить интерфейсные IP. Но причина все VG> равно несерьезная. Или вы хотите сказать, что dialup/broadband/и т.п. VG> клиенты с реальными IP предстваляют большую опасность чем маршрутизаторы VG> BGP-peer'ов?
Конечно, от dialup/broadband и т.п. спама и прочей нечисти больше. Но дело в том, что в случае dialup/broadband и т.п. сеть специально выделена для пользователей, для этой сети работает abuse team. А интерфейсные адреса - они не выделены для пользователей, это внутренняя сетка ISP. И в случае спама из этой сети отфильтрован может быть весь ISP. Прецеденты, когда из-за активности с интерфейсного IP в blacklist занесли наши MX-ы, уже были (а единственная связь - email в network object, из которого шёл спам).
Другая возможная причина: разная роутинговая политика собственных сетей и сетей клиента. Например, клиент может покупать только доступ к UA-IX, а интерфейсный адрес будет при этом виден со всего мира.
А какие есть причины роутить трафик на интерфейсные IP, если на интерфейс взяты IP апстрима? Это ведь не IP клиента. Хочет - роутит, не хочет - не роутит. Только для того, чтобы клиент имел доступ извне к своему роутеру в случае проблем с BGP? По договору обычно апстрим обязан предоставлять сервис для клиентских сетей, интерфейсные к ним не относятся.
Хотелось бы услышать четкое определение термина "интерфейсный IP". -- With best regards, Gregory Edigarov
Pavel Gulchouck wrote:
On Mon, Jul 27, 2009 at 12:20:46PM +0300, Vladimir Garnick writes:
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
VG> Услышал хоть одну причину не роутить интерфейсные IP. Но причина все VG> равно несерьезная. Или вы хотите сказать, что dialup/broadband/и т.п. VG> клиенты с реальными IP предстваляют большую опасность чем маршрутизаторы VG> BGP-peer'ов?
Конечно, от dialup/broadband и т.п. спама и прочей нечисти больше. Но дело в том, что в случае dialup/broadband и т.п. сеть специально выделена для пользователей, для этой сети работает abuse team. А интерфейсные адреса - они не выделены для пользователей, это внутренняя сетка ISP.
А в чем принципиальная разница для внешнего наблюдателя между сеткой для пользователей и сеткой для интерфейсных адресов? В полях netname/descr inetnum-object'а? А кто мешает написать там правильные слова? И рассказать abuse team, что у нас есть еще и такая сетка.
И в случае спама из этой сети отфильтрован может быть весь ISP. Прецеденты, когда из-за активности с интерфейсного IP в blacklist занесли наши MX-ы, уже были (а единственная связь - email в network object, из которого шёл спам).
Невменяемые bl будут фильтровать по любому чиху.
Другая возможная причина: разная роутинговая политика собственных сетей и сетей клиента. Например, клиент может покупать только доступ к UA-IX, а интерфейсный адрес будет при этом виден со всего мира.
Это не аргумент. Для интерфейсных адресов таких клиентов можно выделить, например, отдельную сетку, которая анонсируется только в UA-IX. Хотя и этот способ кривой. Если трафик клиента не контролируется, то что помешает ему зароутить свой исходящий трафик в мир с уже своих (а не интерфейсных) IP через такое подключение? И пользоваться халявным исходящим каналом. Для предотвращения этого, лучше, метить весь трафик разными dscp на входе в сеть ISP (от апстримов, клиентов, пиров, UA-IX'а) и ставить соответветствующие фильтры на выходе.
А какие есть причины роутить трафик на интерфейсные IP, если на интерфейс взяты IP апстрима? Это ведь не IP клиента. Хочет - роутит, не хочет - не роутит. Только для того, чтобы клиент имел доступ извне к своему роутеру в случае проблем с BGP? По договору обычно апстрим обязан предоставлять сервис для клиентских сетей, интерфейсные к ним не относятся.
Кроме как для доступа в случае проблем интерфейсные IP можно использовать для разных видом мониторинга, например. Или тот же NAT иногда удобен при таком подключении. Да и вообще, нарушение IP-связности периодически добавляет головной боли. Один UA-IX чего стоит. Не нужно добавлять дополнительных проблем, тем более они ничего комплексно не решают. -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
Pavel Gulchouck wrote:
Я не имею цели развалить UA-IX. Но я считаю, что в таком виде, в котором он сейчас есть, он жить не может. Например, если клиент A нашего клиента B подключился к UA-IX, по договору я обязан роутить его на UA-IX, а не на своего клиента B, ведь у меня с A явной договорённости нет.
Да, именно так и нужно делать. Именно для этого, насколько я понимаю, и создано это правило. Чтобы отправляя трафик по префиксу полученому из UA-IX'а быть уверенным, что обратный трафик вернется через UA-IX или другими договоренными путями (через прямых пиров), а не через внешний канал, например.
Выхода два: либо менять договор, приближая его к европейским точкам обмена, т.е. убирая из него обязательства участников по роутингу и аннонсированию, либо закрывать глаза на повальное игнорирование участниками требований договора. Сейчас происходит второе, т.е. игнорирование. Например, есть точки обмена, в которых тоже прописано, что приоритет полученных оттуда анонсов должен быть максимальным. И ничего - многие участвуют одновременно и в UA-IX, и в этих IX, не смущаясь несовместимостью условий договоров. :)
Участие в других IX косвенно попадает под определение "явной договоренности между участниками". Хотя формально вероятно нарушение и есть, но оно обычно никому не мешает. Поэтому никто и не протестует.
Примеров много. Вот ещё: "Участнику запрещается анонсировать сеть, выделенную для обеспечения работы UA-IX (195.35.65.0/24). Сеть 195.35.65.0/24 предназначена исключительно для пиринга RS с маршрутизаторами". А зачем тогда эта сеть вообще отдаётся по BGP участникам?
Тут не совсем понятно, куда именно запрещается анонсировать. Я понимаю это правило (в том числе из разъяснения) так, что запрещается анонсировать в мир. А анонсируется участникам, чтобы, по этому префиксу видному в мире легко и быстро обнаруживать, что кто-то реанонсировал префиксы из UA-IX в мир. Если я понимаю неправильно, то да, многие нарушают это правило. Прямо сейчас вижу анонсы этой сети в меня от некоторых участников.
И почему look.ix.net.ua расположен в непредназначенной для этого сети? Как думаешь, многие ли участники анонсируют эту сеть своим клиентам? А если ориентироваться на то, что написано в RIPE? ;-)
А в какой сети должен быть расположен look.ix.net.ua? -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
On Mon, Jul 27, 2009 at 05:18:06PM +0300, Vladimir Garnick writes: VG> Pavel Gulchouck wrote:
Я не имею цели развалить UA-IX. Но я считаю, что в таком виде, в котором он сейчас есть, он жить не может. Например, если клиент A нашего клиента B подключился к UA-IX, по договору я обязан роутить его на UA-IX, а не на своего клиента B, ведь у меня с A явной договорённости нет.
VG> Да, именно так и нужно делать. Именно для этого, насколько я понимаю, и VG> создано это правило. Чтобы отправляя трафик по префиксу полученому из VG> UA-IX'а быть уверенным, что обратный трафик вернется через UA-IX или VG> другими договоренными путями (через прямых пиров), а не через внешний VG> канал, например. Вы не поняли. Куда я должен маршрутизировать трафик _из мира_ на автономку A, подключенную через моего клиента B, если A к тому же включен в UA-IX? Клиент A роутит трафик в мир на своего апстрима B и далее на меня. Чтобы роутинг был симметричен (да и вообще по логике вещей), я должен роутить трафик из мира на A через B. Но тем самым я нарушаю договор с UA-IX. Если же, в соответствии с требованиями договора, я отроучу трафик для A на UA-IX, появится асимметрия (и это будет не главная неприятность). Одна из многих неувязочек, вызванных мягко говоря странными требованиями договора UA-IX к участникам в плане роутинга и аннонсирования.
Выхода два: либо менять договор, приближая его к европейским точкам обмена, т.е. убирая из него обязательства участников по роутингу и аннонсированию, либо закрывать глаза на повальное игнорирование участниками требований договора. Сейчас происходит второе, т.е. игнорирование. Например, есть точки обмена, в которых тоже прописано, что приоритет полученных оттуда анонсов должен быть максимальным. И ничего - многие участвуют одновременно и в UA-IX, и в этих IX, не смущаясь несовместимостью условий договоров. :)
VG> Участие в других IX косвенно попадает под определение "явной VG> договоренности между участниками". Хотя формально вероятно нарушение и VG> есть, но оно обычно никому не мешает. Поэтому никто и не протестует. Я о том и говорю, что формальные нарушения договора, которые никому не мешают, встречаются сплошь и рядом. Я не считаю такую ситуацию полностью здоровой. Мне бы казалось правильным убрать те требования договора, которые всё равно не выполняются. -- Паша.
On Mon, Jul 27, 2009 at 04:39:30PM +0300, Vladimir Garnick writes: VG> Pavel Gulchouck wrote:
On Mon, Jul 27, 2009 at 12:20:46PM +0300, Vladimir Garnick writes:
Вообще, насколько я понимаю, интерфейсные адреса обычно используются только для bgp-взаимодействия и ни для чего другого. Основная причина - abuse. Это ведь не делегированные (assigned) адреса, и попадать в blacklist им ни к чему. Можно их закрывать через acl, можно - снятием анонсов.
VG>> Услышал хоть одну причину не роутить интерфейсные IP. Но причина все VG>> равно несерьезная. Или вы хотите сказать, что dialup/broadband/и т.п. VG>> клиенты с реальными IP предстваляют большую опасность чем маршрутизаторы VG>> BGP-peer'ов?
Конечно, от dialup/broadband и т.п. спама и прочей нечисти больше. Но дело в том, что в случае dialup/broadband и т.п. сеть специально выделена для пользователей, для этой сети работает abuse team. А интерфейсные адреса - они не выделены для пользователей, это внутренняя сетка ISP.
VG> А в чем принципиальная разница для внешнего наблюдателя между сеткой для VG> пользователей и сеткой для интерфейсных адресов? В полях netname/descr VG> inetnum-object'а? Именно. Разница в том, кто отвечает за трафик с этих адресов. Чтобы жалобы попадали по назначению. VG> А кто мешает написать там правильные слова? "Написать правильные слова" - это делегировать клиенту /30. Это возможно - пусть клиент напишет заявку на эту сеть, тогда её ему отдадим. Будет честный assignment, со своим network object. Но мы ведь не этот случай рассматриваем, а вариант, когда у клиента уже есть свои адреса, которых ему достаточно, и которые он анонсирует по BGP? Вот пусть эти свои сети и использует. А интерфейсные адреса входят в чужой assignment, поэтому их использовать негоже. Интерфейсные адреса - чисто техническое понятие, вызванное используемой технологией (ethernet). При подключении по другой технологии их может не быть. [...]
Другая возможная причина: разная роутинговая политика собственных сетей и сетей клиента. Например, клиент может покупать только доступ к UA-IX, а интерфейсный адрес будет при этом виден со всего мира.
VG> Это не аргумент. Для интерфейсных адресов таких клиентов можно выделить, VG> например, отдельную сетку, которая анонсируется только в UA-IX. Хотя и VG> этот способ кривой. Если трафик клиента не контролируется, то что VG> помешает ему зароутить свой исходящий трафик в мир с уже своих (а не VG> интерфейсных) IP через такое подключение? И пользоваться халявным VG> исходящим каналом. Это разные задачи, и методы их решения тоже разные. VG> Для предотвращения этого, лучше, метить весь трафик разными dscp на VG> входе в сеть ISP (от апстримов, клиентов, пиров, UA-IX'а) и ставить VG> соответветствующие фильтры на выходе. Имеете возможность применить это решение на своей сети. Хотя я бы не советовал. :) Как минимум, Ваши клиенты могут использовать dscp в своих целях, и не будут рады тому, что Вы внесёте изменения в заголовки их пакетов. Но это не единственная неприятность. Вместо того, чтобы маркировать dscp, лучше использовать для разных случаев разные route tables.
А какие есть причины роутить трафик на интерфейсные IP, если на интерфейс взяты IP апстрима? Это ведь не IP клиента. Хочет - роутит, не хочет - не роутит. Только для того, чтобы клиент имел доступ извне к своему роутеру в случае проблем с BGP? По договору обычно апстрим обязан предоставлять сервис для клиентских сетей, интерфейсные к ним не относятся.
VG> Кроме как для доступа в случае проблем интерфейсные IP можно VG> использовать для разных видом мониторинга, например. Или тот же NAT VG> иногда удобен при таком подключении. Да и вообще, нарушение IP-связности VG> периодически добавляет головной боли. Один UA-IX чего стоит. Не нужно VG> добавлять дополнительных проблем, тем более они ничего комплексно не решают. Каждый в своей сети может поступать так, как ему кажется правильным. Кто-то может вообще отказаться от использования acl, потому что они добавляют головной боли. Мы фильтруем трафик от интерфейсных IP в редких случаях (обычно только после получения первой жалобы на abuse). Мы можем тут обсуждать, как поступать лучше и удобнее. Но тема-то началась с возмущения, что не дают работать с чужих адресов. А это уже странно, т.к. никто не обещал. Кстати, а как UA-IX нарушает связность? -- Паша.
participants (9)
-
Alexandre Snarskii -
Andrey Kozlov -
Dmitry Kiselev -
Gregory Edigarov -
Paul Arakelyan -
Pavel Gulchouck -
Roman Emelyanov -
Valentin Nechayev -
Vladimir Garnick