БТК и частните автономни системи

Темата е дискутирана и преди, но има малко развитие, разбира се в лоша посока.

Добрата практика по поддръжане на интернет услуги, в това число маршрутизацията и поставянето на правилни AS етикети върху маршрутите в BGP, винаги е била някаква непонятна материя за техническия екип на БТК. Във Великата компания очевидно понятие си нямат как точно се организира ПРАВИЛНАТА доставка на интернет свързаност и правилното обявяване на маршрути в BGP.

Разбира се, майсторството в сътрудничеството с ГДБОП, налагането на цензура над потребителите, предлагането на небивали като ценообразуване услуги, предлагане на ограничаващи потребителя услуги и т.н., са по-важни практики за БТК от каквито и да са други практики, които обществото на технически ангажираните с Интернет лица е определило като добри. От птичи поглед се вижда, че щом съм разбрал тези неща, не съм клиент на БТК и няма и да бъда.

Но да преминем на техническата плоскост и да покажем как интернет цензурата и братското сътрудническо с ГДБОП, не водят дори до минимално натрупване на знания.

Показвам ви данни, който намерих върху публично достъпния "Looking glass" инструмент на Софийкия Университет "Св. Климент Охридски":

sh ip bgp 62.73.68.0/24

BGP routing table entry for 62.73.68.0/24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  62.44.96.1 62.44.96.7 62.44.127.11 62.44.127.15 62.44.127.19
  6802 8866 64540
    194.141.252.21 from 194.141.252.21 (194.141.252.13)
      Origin IGP, localpref 100, valid, external
      Community: 5421:50
      Last update: Fri Mar 30 12:09:43 2007

  8866
    213.16.50.193 from 213.16.50.193 (212.39.70.66)
      Origin IGP, localpref 100, valid, external, best
      Community: 5421:50
      Last update: Tue Mar 27 17:18:01 2007

Първият път, който виждате с AS вектор "6802 8866 64540", е пътя до 62.73.68.0/24 през Академичната мрежа. Вторият път е директен път до 62.73.68.0/24 през напречна връзка с БТК. Открийте разликите, както се казва. Оказва се, че един и същи префикс, в случая 62.73.68.0/24, се обявява като домуващ в две автономни системи - AS8866 и AS64540.

Някои хора сега биха казали "е добре, филтрирайте всички префикси, отбелязани за домуващи в автономни системи за частно ползване и всичко ще се оправи". Това е много прибързана реакция. Сега ще покажа защо. Да тръгне по пътя до префикса 62.73.68.0/24 през Академичната мрежа (AS6802). Ще използваме "Looking glass" инструмента на Академичната мрежа, публично достъпен на адрес http://netmon.acad.bg/lg:

Router: IPP-BAS-Sofia Border-1
Command: show ip bgp 62.73.68.0/24


BGP routing table entry for 62.73.68.0/24, version 2001264
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Multipath: eBGP iBGP
  Advertised to update-groups:
     3          8          9          10         11        
  34771 5408 20965 3356 6453 8866
    195.251.4.45 from 195.251.4.45 (195.251.4.45)
      Origin IGP, localpref 90, weight 90, valid, external
      Community: 5408:4001
  20965 3356 6453 8866
    62.40.114.19 from 62.40.114.19 (62.40.114.19)
      Origin IGP, localpref 100, weight 100, valid, external
      Community: 20965:3356
  6802 8262 8866
    194.12.255.49 from 194.12.255.49 (85.14.0.11)
      Origin IGP, localpref 200, weight 200, valid, external
      Community: 6802:200
  8866 64540
    212.39.66.133 from 212.39.66.133 (212.39.70.87)
      Origin IGP, localpref 200, weight 200, valid, external, best
      Community: 6802:200

Какво би станало, ако поставим филтър за отхвърляне на префикси от AS64540. Много просто. Най-късия път, който е напречната връзка между Академичната мрежа и БТК, ще се окаже "липсващ" и връзката ще трябва да премине през пътя "6802 8262 8866". Следователно изходящият поток до 62.73.68.0/24 вместо по напречната връзка с БТК, ще преминава по по-дълъг път "Еволинк --> БТК".

Т.е. сами виждате, че филтрите в този случай не помагат. Тук думата си казва лошата практика на БТК, която е пословична и се развива с времето във все по-лоша посока.

Преди да заврша тази бележка ще кажа, че БТК много обичат тази AS64540. Показвам:

quagga> sh ip bgp regexp _8866 (6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]| \
 65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])_

BGP table version is 0, local router ID is 213.16.50.203
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  62.73.68.0/24    194.141.252.21                         0 6802 8866 64540 i
*  62.73.71.0/24    194.141.252.21                         0 6802 8866 64540 i
*  90.154.234.0/23  194.141.252.21                         0 6802 8866 64540 i
*  90.154.234.0/24  194.141.252.21                         0 6802 8866 64540 i
*  90.154.235.0/24  194.141.252.21                         0 6802 8866 64540 i
*  213.91.152.0     194.141.252.21                         0 6802 8866 65400 i

Total number of prefixes 6

За БТК RFC1930 е отдавна мъртво, но не е единственото мъртво за тях нещо.

Пак за BGP и БТК

БТК предоставят по договор на разни организации, локален канал за свързаност. Чудесно! Нали идеята на Интернет е точно свързаност във всички посоки. Кратък поглед върху маршрутната таблица, касаеща направленията завършващи в AS8866 обаче, шокира доста.

Общо се пропагандират 233 префикса. Показвам ги на две части, едните оповестени изначално чрез iBGP (Origin iBGP), а другите чрез някакъв друг протокол, различен от BGP (най-често OSPF), но после "напъхани" в BGP (Origin incomplete).

Origin iBGP:

*> 62.73.68.0/24    213.16.50.193                          0 8866 i
*> 62.73.71.0/24    213.16.50.193                          0 8866 i
*> 77.85.0.0/16     213.16.50.193                          0 8866 i
*> 82.137.108.0/24  213.16.50.193                          0 8866 i
*> 82.137.124.0/22  213.16.50.193                          0 8866 i
*> 83.228.0.0/17    213.16.50.193                          0 8866 i
*> 83.228.0.0/18    213.16.50.193                          0 8866 i
*> 83.228.0.0/20    213.16.50.193                          0 8866 i
*> 83.228.16.0/24   213.16.50.193                          0 8866 i
*> 83.228.24.0/22   213.16.50.193                          0 8866 i
*> 83.228.44.0/22   213.16.50.193                          0 8866 i
*> 83.228.55.0/24   213.16.50.193                          0 8866 i
*> 83.228.57.0/24   213.16.50.193                          0 8866 i
*> 83.228.59.0/24   213.16.50.193                          0 8866 i
*> 83.228.61.0/24   213.16.50.193                          0 8866 i
*> 83.228.62.0/24   213.16.50.193                          0 8866 i
*> 83.228.63.0/24   213.16.50.193                          0 8866 i
*> 83.228.64.0/24   213.16.50.193                          0 8866 i
*> 83.228.66.0/24   213.16.50.193                          0 8866 i
*> 83.228.69.0/24   213.16.50.193                          0 8866 i
*> 83.228.71.0/24   213.16.50.193                          0 8866 i
*> 83.228.96.0/22   213.16.50.193                          0 8866 i
*> 83.228.100.0/22  213.16.50.193                          0 8866 i
*> 83.228.100.0/24  213.16.50.193                          0 8866 i
*> 83.228.101.0/24  213.16.50.193                          0 8866 i
*> 83.228.103.0/24  213.16.50.193                          0 8866 i
*> 83.228.108.0/24  213.16.50.193                          0 8866 i
*> 83.228.123.0/24  213.16.50.193                          0 8866 i
*> 83.228.124.0/24  213.16.50.193                          0 8866 i
*> 83.228.125.0/24  213.16.50.193                          0 8866 i
*> 83.228.127.0/24  213.16.50.193                          0 8866 i
*> 87.126.0.0/16    213.16.50.193                          0 8866 i
*> 87.126.0.0/17    213.16.50.193                          0 8866 i
*> 87.126.128.0/18  213.16.50.193                          0 8866 i
*> 87.126.192.0/18  213.16.50.193                          0 8866 i
*> 90.154.128.0/17  213.16.50.193                          0 8866 i
*> 90.154.234.0/23  213.16.50.193                          0 8866 i
*> 90.154.234.0/24  213.16.50.193                          0 8866 i
*> 90.154.235.0/24  213.16.50.193                          0 8866 i
*> 193.22.103.0     213.16.50.193                          0 8866 i
*> 194.8.53.0       213.16.50.193                          0 8866 i
*> 195.177.218.0    213.16.50.193                          0 8866 i
*> 195.177.219.0    213.16.50.193                          0 8866 i
*> 195.177.248.0/23 213.16.50.193                          0 8866 i
*> 212.39.64.0/19   213.16.50.193                          0 8866 i
*> 212.39.64.0      213.16.50.193                          0 8866 i
*> 212.39.65.0      213.16.50.193                          0 8866 i
*> 212.39.66.0      213.16.50.193                          0 8866 i
*> 212.39.68.0      213.16.50.193                          0 8866 i
*> 212.39.70.0      213.16.50.193                          0 8866 i
*> 212.39.71.0      213.16.50.193                          0 8866 i
*> 212.39.73.0      213.16.50.193                          0 8866 i
*> 212.39.74.0      213.16.50.193                          0 8866 i
*> 212.39.75.0      213.16.50.193                          0 8866 i
*> 212.39.76.0      213.16.50.193                          0 8866 i
*> 212.39.77.0      213.16.50.193                          0 8866 i
*> 212.39.78.0      213.16.50.193                          0 8866 i
*> 212.39.79.0      213.16.50.193                          0 8866 i
*> 212.39.81.0      213.16.50.193                          0 8866 i
*> 212.39.82.0      213.16.50.193                          0 8866 i
*> 212.39.83.0      213.16.50.193                          0 8866 i
*> 212.39.84.0      213.16.50.193                          0 8866 i
*> 212.39.85.0      213.16.50.193                          0 8866 i
*> 212.39.86.0      213.16.50.193                          0 8866 i
*> 212.39.90.0      213.16.50.193                          0 8866 i
*> 212.39.91.0      213.16.50.193                          0 8866 i
*> 212.39.94.0      213.16.50.193                          0 8866 i
*> 213.16.32.0/19   213.16.50.193                          0 8866 i
*> 213.16.32.0      213.16.50.193                          0 8866 i
*> 213.16.33.0      213.16.50.193                          0 8866 i
*> 213.16.34.0      213.16.50.193                          0 8866 i
*> 213.16.35.0      213.16.50.193                          0 8866 i
*> 213.16.36.0      213.16.50.193                          0 8866 i
*> 213.16.37.0      213.16.50.193                          0 8866 i
*> 213.16.38.0      213.16.50.193                          0 8866 i
*> 213.16.39.0      213.16.50.193                          0 8866 i
*> 213.16.40.0      213.16.50.193                          0 8866 i
*> 213.16.42.0      213.16.50.193                          0 8866 i
*> 213.16.45.0      213.16.50.193                          0 8866 i
*> 213.16.46.0      213.16.50.193                          0 8866 i
*> 213.16.50.0      213.16.50.193                          0 8866 i
*> 213.16.55.0      213.16.50.193                          0 8866 i
*> 213.16.57.0      213.16.50.193                          0 8866 i
*> 213.16.58.0      213.16.50.193                          0 8866 i
*> 213.16.59.0      213.16.50.193                          0 8866 i
*> 213.16.62.0      213.16.50.193                          0 8866 i
*> 213.16.63.0      213.16.50.193                          0 8866 i
*> 213.91.128.0/17  213.16.50.193                          0 8866 i
*> 213.91.128.0     213.16.50.193                          0 8866 i
*> 213.91.129.0     213.16.50.193                          0 8866 i
*> 213.91.134.0     213.16.50.193                          0 8866 i
*> 213.91.135.0     213.16.50.193                          0 8866 i
*> 213.91.136.0/23  213.16.50.193                          0 8866 i
*> 213.91.140.0     213.16.50.193                          0 8866 i
*> 213.91.141.0     213.16.50.193                          0 8866 i
*> 213.91.152.0     213.16.50.193                          0 8866 i
*> 213.91.156.0     213.16.50.193                          0 8866 i
*> 213.91.157.0     213.16.50.193                          0 8866 i
*> 213.91.161.0     213.16.50.193                          0 8866 i
*> 213.91.162.0     213.16.50.193                          0 8866 i
*> 213.91.165.0     213.16.50.193                          0 8866 i
*> 213.91.166.0     213.16.50.193                          0 8866 i
*> 213.91.168.0     213.16.50.193                          0 8866 i
*> 213.91.170.0     213.16.50.193                          0 8866 i
*> 213.91.171.0     213.16.50.193                          0 8866 i
*> 213.91.173.0     213.16.50.193                          0 8866 i
*> 213.91.176.0     213.16.50.193                          0 8866 i
*> 213.91.182.0     213.16.50.193                          0 8866 i
*> 213.91.185.0     213.16.50.193                          0 8866 i
*> 213.91.195.0     213.16.50.193                          0 8866 i
*> 213.91.202.0     213.16.50.193                          0 8866 i
*> 213.91.204.0     213.16.50.193                          0 8866 i
*> 213.91.206.0     213.16.50.193                          0 8866 i
*> 213.91.207.0     213.16.50.193                          0 8866 i
*> 213.91.209.0     213.16.50.193                          0 8866 i
*> 213.91.210.0     213.16.50.193                          0 8866 i
*> 213.91.211.0     213.16.50.193                          0 8866 i
*> 213.91.216.0     213.16.50.193                          0 8866 i
*> 213.91.217.0     213.16.50.193                          0 8866 i
*> 213.91.218.0     213.16.50.193                          0 8866 i
*> 213.91.235.0     213.16.50.193                          0 8866 i
*> 213.91.238.0     213.16.50.193                          0 8866 i

Общо 122 префикса

Origin incomplete:

*> 77.85.64.0/21    213.16.50.193                          0 8866 ?
*> 77.85.168.0/23   213.16.50.193                          0 8866 ?
*> 83.228.17.0/24   213.16.50.193                          0 8866 ?
*> 83.228.18.0/23   213.16.50.193                          0 8866 ?
*> 83.228.20.0/22   213.16.50.193                          0 8866 ?
*> 83.228.28.0/22   213.16.50.193                          0 8866 ?
*> 83.228.32.0/22   213.16.50.193                          0 8866 ?
*> 83.228.36.0/22   213.16.50.193                          0 8866 ?
*> 83.228.40.0/22   213.16.50.193                          0 8866 ?
*> 83.228.48.0/22   213.16.50.193                          0 8866 ?
*> 83.228.52.0/24   213.16.50.193                          0 8866 ?
*> 83.228.53.0/24   213.16.50.193                          0 8866 ?
*> 83.228.54.0/24   213.16.50.193                          0 8866 ?
*> 83.228.56.0/24   213.16.50.193                          0 8866 ?
*> 83.228.58.0/24   213.16.50.193                          0 8866 ?
*> 83.228.60.0/24   213.16.50.193                          0 8866 ?
*> 83.228.65.0/24   213.16.50.193                          0 8866 ?
*> 83.228.68.0/24   213.16.50.193                          0 8866 ?
*> 83.228.99.0/24   213.16.50.193                          0 8866 ?
*> 87.126.32.0/21   213.16.50.193                          0 8866 ?
*> 87.126.40.0/23   213.16.50.193                          0 8866 ?
*> 87.126.42.0/23   213.16.50.193                          0 8866 ?
*> 87.126.44.0/24   213.16.50.193                          0 8866 ?
*> 87.126.45.0/24   213.16.50.193                          0 8866 ?
*> 87.126.46.0/24   213.16.50.193                          0 8866 ?
*> 87.126.47.0/24   213.16.50.193                          0 8866 ?
*> 87.126.48.0/21   213.16.50.193                          0 8866 ?
*> 87.126.56.0/21   213.16.50.193                          0 8866 ?
*> 87.126.64.0/24   213.16.50.193                          0 8866 ?
*> 87.126.65.0/24   213.16.50.193                          0 8866 ?
*> 87.126.66.0/23   213.16.50.193                          0 8866 ?
*> 87.126.68.0/24   213.16.50.193                          0 8866 ?
*> 87.126.69.0/24   213.16.50.193                          0 8866 ?
*> 87.126.70.0/24   213.16.50.193                          0 8866 ?
*> 87.126.71.0/24   213.16.50.193                          0 8866 ?
*> 87.126.72.0/22   213.16.50.193                          0 8866 ?
*> 87.126.76.0/22   213.16.50.193                          0 8866 ?
*> 87.126.80.0/21   213.16.50.193                          0 8866 ?
*> 87.126.88.0/21   213.16.50.193                          0 8866 ?
*> 87.126.96.0/22   213.16.50.193                          0 8866 ?
*> 87.126.100.0/22  213.16.50.193                          0 8866 ?
*> 87.126.104.0/22  213.16.50.193                          0 8866 ?
*> 87.126.108.0/22  213.16.50.193                          0 8866 ?
*> 87.126.120.0/22  213.16.50.193                          0 8866 ?
*> 87.126.125.0/24  213.16.50.193                          0 8866 ?
*> 87.126.128.0/22  213.16.50.193                          0 8866 ?
*> 87.126.132.0/24  213.16.50.193                          0 8866 ?
*> 87.126.133.0/24  213.16.50.193                          0 8866 ?
*> 87.126.134.0/24  213.16.50.193                          0 8866 ?
*> 87.126.136.0/22  213.16.50.193                          0 8866 ?
*> 87.126.141.0/24  213.16.50.193                          0 8866 ?
*> 87.126.143.0/24  213.16.50.193                          0 8866 ?
*> 87.126.144.0/22  213.16.50.193                          0 8866 ?
*> 87.126.148.0/23  213.16.50.193                          0 8866 ?
*> 87.126.152.0/22  213.16.50.193                          0 8866 ?
*> 87.126.157.0/24  213.16.50.193                          0 8866 ?
*> 87.126.159.0/24  213.16.50.193                          0 8866 ?
*> 87.126.160.0/22  213.16.50.193                          0 8866 ?
*> 87.126.164.0/24  213.16.50.193                          0 8866 ?
*> 87.126.165.0/24  213.16.50.193                          0 8866 ?
*> 87.126.166.0/24  213.16.50.193                          0 8866 ?
*> 87.126.167.0/24  213.16.50.193                          0 8866 ?
*> 87.126.168.0/23  213.16.50.193                          0 8866 ?
*> 87.126.176.0/23  213.16.50.193                          0 8866 ?
*> 87.126.180.0/23  213.16.50.193                          0 8866 ?
*> 87.126.182.0/24  213.16.50.193                          0 8866 ?
*> 87.126.183.0/24  213.16.50.193                          0 8866 ?
*> 87.126.186.0/23  213.16.50.193                          0 8866 ?
*> 87.126.189.0/24  213.16.50.193                          0 8866 ?
*> 87.126.190.0/24  213.16.50.193                          0 8866 ?
*> 87.126.191.0/24  213.16.50.193                          0 8866 ?
*> 87.126.192.0/22  213.16.50.193                          0 8866 ?
*> 87.126.196.0/22  213.16.50.193                          0 8866 ?
*> 87.126.200.0/22  213.16.50.193                          0 8866 ?
*> 87.126.204.0/23  213.16.50.193                          0 8866 ?
*> 87.126.206.0/24  213.16.50.193                          0 8866 ?
*> 87.126.207.0/24  213.16.50.193                          0 8866 ?
*> 87.126.211.0/24  213.16.50.193                          0 8866 ?
*> 87.126.212.0/23  213.16.50.193                          0 8866 ?
*> 87.126.214.0/23  213.16.50.193                          0 8866 ?
*> 87.126.216.0/23  213.16.50.193                          0 8866 ?
*> 87.126.218.0/23  213.16.50.193                          0 8866 ?
*> 87.126.220.0/23  213.16.50.193                          0 8866 ?
*> 87.126.222.0/24  213.16.50.193                          0 8866 ?
*> 87.126.223.0/24  213.16.50.193                          0 8866 ?
*> 87.126.224.0/22  213.16.50.193                          0 8866 ?
*> 87.126.228.0/23  213.16.50.193                          0 8866 ?
*> 87.126.230.0/24  213.16.50.193                          0 8866 ?
*> 87.126.232.0/23  213.16.50.193                          0 8866 ?
*> 87.126.234.0/23  213.16.50.193                          0 8866 ?
*> 87.126.237.0/24  213.16.50.193                          0 8866 ?
*> 87.126.241.0/24  213.16.50.193                          0 8866 ?
*> 87.126.242.0/24  213.16.50.193                          0 8866 ?
*> 87.126.243.0/24  213.16.50.193                          0 8866 ?
*> 87.126.244.0/22  213.16.50.193                          0 8866 ?
*> 87.126.248.0/22  213.16.50.193                          0 8866 ?
*> 87.126.252.0/22  213.16.50.193                          0 8866 ?
*> 90.154.144.0/21  213.16.50.193                          0 8866 ?
*> 90.154.160.0/21  213.16.50.193                          0 8866 ?
*> 90.154.168.0/21  213.16.50.193                          0 8866 ?
*> 90.154.176.0/21  213.16.50.193                          0 8866 ?
*> 90.154.184.0/22  213.16.50.193                          0 8866 ?
*> 90.154.188.0/22  213.16.50.193                          0 8866 ?
*> 90.154.192.0/19  213.16.50.193                          0 8866 ?
*> 213.91.193.0     213.16.50.193                          0 8866 ?
*> 213.91.194.0     213.16.50.193                          0 8866 ?
*> 213.91.205.0     213.16.50.193                          0 8866 ?
*> 213.91.219.0     213.16.50.193                          0 8866 ?
*> 213.91.230.0     213.16.50.193                          0 8866 ?
*> 213.91.240.0/22  213.16.50.193                          0 8866 ?
*> 213.91.246.0/23  213.16.50.193                          0 8866 ?

Общо 111 префикса класифицирани с "origin incomplete".

Данните са в сила към 13:24 часа на 29 февруари 2007г.

От друга страна AS8866 е регистрирала 183 маршрутни ("route") обекта в RIPE DB. Т.е. това би следвало да е списъка с префикси, които ще бъдат излъчвани под маската на AS8866. Показвам обектите от RIPE DB:

213.91.128.0/17
213.91.248.0/22
213.91.240.0/22
213.91.244.0/22
213.91.246.0/24
213.91.245.0/24
213.91.238.0/24
213.91.237.0/24
213.91.235.0/24
213.91.216.0/24
213.91.217.0/24
213.91.218.0/24
213.91.219.0/24
213.91.211.0/24
213.91.204.0/24
213.91.205.0/24
213.91.206.0/24
213.91.207.0/24
213.91.202.0/24
213.91.194.0/24
213.91.190.0/24
213.91.188.0/23
213.91.186.0/24
213.91.187.0/24
213.91.185.0/24
213.91.176.0/24
213.91.177.0/24
213.91.174.0/24
213.91.173.0/24
213.91.171.0/24
213.91.168.0/24
213.91.166.0/24
213.91.162.0/24
213.91.161.0/24
213.91.158.0/24
213.91.156.0/24
213.91.157.0/24
213.91.142.0/24
213.91.140.0/24
213.91.141.0/24
213.91.138.0/24
213.91.139.0/24
213.91.136.0/23
213.91.134.0/24
213.91.135.0/24
213.91.132.0/24
213.91.128.0/24
213.91.129.0/24
213.91.130.0/24
213.91.131.0/24
213.16.32.0/19
213.16.60.0/24
213.16.61.0/24
213.16.62.0/24
213.16.63.0/24
213.16.58.0/24
213.16.59.0/24
213.16.57.0/24
213.16.54.0/24
213.16.55.0/24
213.16.52.0/24
213.16.50.0/24
213.16.49.0/24
213.16.46.0/24
213.16.44.0/24
213.16.45.0/24
213.16.42.0/24
213.16.40.0/24
213.16.41.0/24
213.16.38.0/24
213.16.39.0/24
213.16.37.0/24
213.16.32.0/24
213.16.33.0/24
213.16.34.0/24
213.16.35.0/24
212.39.64.0/19
212.39.95.0/24
212.39.92.0/24
212.39.93.0/24
212.39.90.0/24
212.39.89.0/24
212.39.84.0/24
212.39.85.0/24
212.39.86.0/24
212.39.87.0/24
212.39.82.0/24
212.39.83.0/24
212.39.81.0/24
212.39.72.0/24
212.39.73.0/24
212.39.74.0/24
212.39.75.0/24
212.39.76.0/24
212.39.77.0/24
212.39.78.0/24
212.39.79.0/24
212.39.68.0/24
212.39.69.0/24
212.39.70.0/24
212.39.71.0/24
212.39.66.0/24
212.39.64.0/24
212.39.65.0/24
195.234.236.0/22
195.177.248.0/23
195.177.218.0/23
195.177.218.0/24
195.177.219.0/24
195.137.252.0/24
195.137.253.0/24
194.8.53.0/24
193.22.103.0/24
90.154.128.0/17
87.126.0.0/16
87.126.128.0/18
87.126.192.0/18
87.126.0.0/17
87.126.125.0/24
87.126.116.0/23
87.126.108.0/23
87.126.106.0/24
87.126.103.0/24
87.126.100.0/24
87.126.96.0/22
87.126.88.0/22
87.126.80.0/22
87.126.72.0/22
87.126.75.0/24
87.126.71.0/24
87.126.56.0/22
87.126.55.0/24
87.126.40.0/22
87.126.42.0/24
87.126.40.0/24
87.126.41.0/24
87.126.32.0/21
83.228.0.0/17
83.228.126.0/24
83.228.127.0/24
83.228.124.0/24
83.228.120.0/24
83.228.116.0/22
83.228.108.0/24
83.228.100.0/22
83.228.103.0/24
83.228.100.0/24
83.228.101.0/24
83.228.99.0/24
83.228.97.0/24
83.228.92.0/24
83.228.90.0/23
83.228.88.0/24
83.228.89.0/24
83.228.86.0/24
83.228.87.0/24
83.228.85.0/24
83.228.75.0/24
83.228.68.0/24
83.228.69.0/24
83.228.67.0/24
83.228.65.0/24
83.228.0.0/18
83.228.60.0/24
83.228.58.0/24
83.228.56.0/24
83.228.54.0/24
83.228.52.0/24
83.228.48.0/22
83.228.32.0/22
83.228.36.0/22
83.228.40.0/22
83.228.44.0/22
83.228.24.0/22
83.228.28.0/22
83.228.20.0/22
83.228.16.0/24
83.228.17.0/24
83.228.18.0/24
83.228.19.0/24
83.228.0.0/20
77.85.0.0/16
62.73.80.0/24

Повечето хора биха смятали така. Е добре, те имат декларирани 183 евентуално излъчваеми префикса, значи излъчват само 40 в повече. Това обаче е неправилна сметка, защото много от декларираните обекти не се излъчват (няма нищо лошо в това), но за сметка на това се излъчват недекларирани обекти.

Следните маршрутни обекти не се излъчват като префикси (общо 48 броя):

213.91.248.0/22
213.91.244.0/22
213.91.246.0/24
213.91.245.0/24
213.91.188.0/23
213.91.174.0/24
213.91.138.0/24
213.91.139.0/24
213.91.130.0/24
213.91.131.0/24
213.16.60.0/24
213.16.61.0/24
213.16.54.0/24
213.16.52.0/24
212.39.95.0/24
212.39.92.0/24
212.39.93.0/24
212.39.89.0/24
212.39.87.0/24
212.39.72.0/24
212.39.69.0/24
195.177.218.0/23
87.126.116.0/23
87.126.108.0/23
87.126.106.0/24
87.126.103.0/24
87.126.100.0/24
87.126.75.0/24
87.126.56.0/22
87.126.55.0/24
87.126.40.0/22
87.126.42.0/24
87.126.40.0/24
87.126.41.0/24
83.228.126.0/24
83.228.120.0/24
83.228.116.0/22
83.228.97.0/24
83.228.92.0/24
83.228.88.0/24
83.228.89.0/24
83.228.86.0/24
83.228.87.0/24
83.228.85.0/24
83.228.75.0/24
83.228.67.0/24
83.228.18.0/24
83.228.19.0/24

Нека да отбележим, че съгласно добрата практика, която RIPE държи да се спазва и на основа която транзитните доставчици градят филтри за достъп до машрути в BGP сесиите си, трябва по BGP сесиите да се излъчват само и единствено префикси, които са регистрирани като маршрутни обекти. Комичното в цялата ситуация е, че БТК не знае това. Огромният брой префикси със статус "origin incomplete" е също показател за някои не до там добри неща, които се правят в БТК.

Как БТК изпълнява договор за свързаност към Интернет

По-долу ще видите как БТК изпълнват договора си за доставка на интернет свързаност към Софийския Университет "Св. Климент Охридски". Проблемът описан по-долу вече продължава седмица и това не е единственият проблем с услугата, предоставяна от БТК. Ректорът на СУ, проф. Боян Биолчев, вместо да заплашва администратори с уволнение, да вземе да преразгледа договорите с разни доставчици, на които СУ плаща пари без да получава нужната услуга. Може би трябва да започне направо с търга за доставка, на който БТК печелят с 37% по-ниска цена, в сравнение с втория в класацията и юристите на СУ нямат смелост да отстранят БТК от този търг, въпреки очевиден дъмпинг.

А сега за главния проблем.

Информация за наличните сесии върху граничния маршрутизатор на БТК, получена от "Looking glass" инструмента на БТК, публично достъпен на адрес http://www.btc-net.bg/lg1/lg.pl

08:46:10 часа на 29 март 2007

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
212.39.66.18    4  8860   58046 2616377 44123190    0    0 2w4d            2
212.39.66.66    4  8795   58069   58045 44123210    0    0 2w6d           17
212.39.66.162   4 29080       0       0        0    0    0 never    Idle (Admin)
212.39.66.242   4 21337   58047  932249 44123188    0    0 3w0d            1
212.39.70.68    4  8866  257970 2333831 44123210    0    0 5w5d          197
212.39.70.69    4  8866  257745 2308980 44123210    0    0 5w5d          196
212.39.70.84    4  8866 3365390 2290073 44123210    1    0 5w5d       212470
212.39.70.118   4  8866  114985  418153 44123210    0    0 5w5d        11006
212.39.70.119   4  8866 1392224  418153 44123210    0    0 5w5d       211399
212.39.70.137   4  8866   59079   58047 44123210    0    0 5w5d          260
212.39.70.141   4  8866   59158   58047 44123210    0    0 5w5d          258
212.39.91.131   4  8866   45216  895074        0    0    0 1w1d     Idle (Admin)
212.39.91.132   4  8866   45220  895056        0    0    0 1w1d     Idle (Admin)
212.39.91.133   4  8866   43780  864276        0    0    0 1w2d     Idle (Admin)
212.39.91.134   4  8866   43845  866041        0    0    0 1w2d     Idle (Admin)
212.39.91.139   4  8866   45218  895028        0    0    0 1w1d     Idle (Admin)
212.39.91.140   4  8866   45230  887624        0    0    0 1w1d     Idle (Admin)
212.39.91.141   4  8866   43780  864209        0    0    0 1w2d     Idle (Admin)
212.39.91.142   4  8866   43855  858602        0    0    0 1w2d     Idle (Admin)
212.124.78.100  4 29122   58037  364252 44123188    0    0 5d05h           3
213.16.32.46    4 29662   57985 3001237 44123190    0    0 2w0d            2
213.16.32.90    4 12795   58065   58083 44123188    0    0 6d22h           2
213.16.32.194   4 12962       0       0        0    0    0 never    Idle (Admin)
213.16.50.2     4 34653   58043 2573797 44123190    0    0 3w0d            1
213.16.50.246   4  9070   40652 1017934        0    0    0 3w5d     Active
213.16.50.254   4  9070   19421  922588        0    0    0 3w5d     Active
213.91.162.218  4 31534   58046 2658929 44123190    0    0 3w0d            1
213.91.166.222  4 29366  152394   58048 44123188    0    0 3w0d            1
213.91.204.122  4 13236   58075   58057 44123188    0    0 1w4d            3
213.91.204.123  4 13236   57011   56999 44123188    1    0 1w4d            4
213.91.204.124  4 13236   58049   58058 44123188    0    0 6d14h           1
213.91.204.125  4 13236   58047   58044 44123188    0    0 3w0d            8
213.91.235.126  4 34340   58044   58045 44123210    0    0 3w0d            3
213.91.235.150  4 31440   58065 2672066 44123190    0    0 2w2d            3

Забележете двете сесии от по 211000 префикса - те отчитат свързаността на БТК към Интернет. Другите сесии са сесии отразяващи локална свързаност и те не са интересни за нашето разглеждане.

Странно защо таблицата, която БТК подават към един от техните клиенти и която трябва да отразява по договор свързаността към интернет, е с 1/4 по-малка от тази, която БТК получава. По-долу виждате изглед от таблицата, налична върху граничния маршрутизатор на Софийския Университет "Св. Климент Охридски", която е получена от публично достъпния за целта "Looking glass" инструмент, наличен на адрес http://lg.uni-sofia.bg

08:46:10 часа на 29 март 2007

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
62.44.96.1      4   112    2371  129817        0    0    0 1d15h28m        1
62.44.96.7      4   112    2371  129805        0    0    0 1d15h28m        1
62.44.96.162    4 20657    2380    2373        0    0    0 1d15h28m       31
62.44.96.163    4  8262    2489    2373        0    0    0 1d15h28m      339
62.44.96.165    4 12814    2371    2373        0    0    0 1d15h28m        7
62.44.96.166    4  9070    5022    4741        0    0    0 1d15h28m      715
62.44.96.168    4 12867    2392    2373        0    0    0 1d15h28m       96
62.44.96.250    4  8717    5191    4741        0    0    0 1d15h28m      625
62.44.96.254    4  3245    2374    2373        0    0    0 1d15h28m       74
62.44.109.32    4  5421    2370    2413        0    0    0 1d15h12m        0
62.44.127.11    4  5421    2380  134331        0    0    0 1d15h28m       10
62.44.127.15    4  5421    2370  134397        0    0    0 1d15h28m        2
62.44.127.19    4  5421    2380  134241        0    0    0 1d15h26m        4
194.141.252.21  4  6802   96006    2373        0    0    0 1d15h28m   214203
212.7.193.65    4  9184    2374    2373        0    0    0 1d15h28m        6
212.72.192.221  4  9127    2454    2373        0    0    0 1d15h28m      149
213.16.50.193   4  8866    3206    2373        0    0    0 1d15h28m     2640
213.16.50.201   4  8866  159830    2307        0    0    0 1d14h21m   149131
217.9.225.2     4 13124    2692    2373        0    0    0 1d15h28m      473

Тук граничният маршрутизатор на БТК, през който се изпълнява договора за доставка на интернет свързаност към СУ, е с адрес 213.16.50.201. Забележете броят префикси, които се доставят (около 150000). Сравнете това количество с префиксите, които БТК получават и тези, които СУ получава по линия на свързаността си към НИМ и оттам към GEANT2. Граничният маршрутизатор към НИМ е с IP адрес 194.141.252.21. Въпросът е къде се губят близо 50 000 префикса? Поглед върху конфигурацията на граничния маршрутизатор на СУ показва, че няма филтър за входящите префикси по сесията с граничния маршрутизатор на БТК.

Ето един пример за липсващ префикс, който БТК получават, но не анонсират към СУ. Могат да бъдат намерени и други такива. Става дума за префикса 62.42.0.0/16. Той се получава от БТК от техните доставчици и наистина, ако се провери за неговото наличие чрез "Looking glass" инструмента на БТК, се вижда, че този префикс се получава и е наличен:

BGP routing table entry for 62.42.0.0/16, version 42537980
Bestpath Modifiers: always-compare-med, deterministic-med
Paths: (3 available, best #2)
Multipath: iBGP
  Advertised to update-groups:
     2          3          6          7          11         12         13        
     16        
  3549 1273 1273 6739, (Received from a RR-client)
    67.17.193.65 (metric 11) from 212.39.70.118 (212.39.70.118)
      Origin IGP, metric 2503, localpref 100, valid, internal
      Community: 1:8866 3549:8866
  6453 1273 6739, (Received from a RR-client)
    80.231.78.13 (metric 11) from 212.39.70.119 (212.39.70.119)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 1:8866 6453:8866
  6453 1273 6739
    80.231.78.13 (metric 11) from 212.39.70.84 (212.39.70.84)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 1:8866 6453:8866
      Originator: 212.39.70.119, Cluster list: 212.39.70.84

В същото време, ако се опитаме да проверим за наличието на префикса върху граничния маршрутизатор на СУ, получаваме резултат, според който той се достъпва само през НИМ (GEANT2):

BGP routing table entry for 62.42.0.0/16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  62.44.96.1 62.44.96.7 62.44.127.11 62.44.127.15 62.44.127.19
  6802 20965 3356 1273 6739
    194.141.252.21 from 194.141.252.21 (194.141.252.13)
      Origin IGP, localpref 100, valid, external, best
      Community: 5421:60
      Last update: Tue Mar 27 17:18:41 2007

За да няма съмнения за спекулации, показвам и префикс, който е достъпен и през двата доставчика на СУ - 62.2.0.0/16:

BGP routing table entry for 62.2.0.0/16
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  62.44.96.1 62.44.96.7 62.44.127.11 62.44.127.15 62.44.127.19
  8866 8400 1299 6830 8404
    213.16.50.201 from 213.16.50.201 (212.39.70.84)
      Origin IGP, localpref 100, valid, external
      Last update: Wed Mar 28 10:44:27 2007

  6802 20965 1299 6830 8404
    194.141.252.21 from 194.141.252.21 (194.141.252.13)
      Origin IGP, localpref 100, valid, external, best
      Community: 5421:60
      Last update: Tue Mar 27 17:18:25 2007

Аз лично няма да правя коментари.

Сбогом БТК

От днес нямам домашен телефон към БТК. Не искам да плащам за никаква услуга на компания, която ще ми цензурира достъпа до Интернет (утре и достъпа до телефонни номера по избор на някое неграмотно ченге). Също така и за в бъдеще, аз няма да използвам услугите на БТК. Пет пари не давам за никакви извинения. Компания, която кляка пред исканията на някакво необразовано ченге, не може да ми доставя никаква услуга и точка по въпроса! Компания, която няма двама юристи на кръст, които да видят, че искането е полицейски произвол, за мен не може да има никакъв авторитет. Преди се бях сблъскал с техническите им кадри, които са технически полуграмотни, а сега вече се сблъсках и с тъпо ръководство. Дотук!

Сбогом БТК!

Пътни записки

Пиша това някъде между Промахонас и Серес. Тъмно е навън и няма какво да се гледа. Добре, че роуминга работи и имам и GPRS.

Искам специално да благодаря на DJNone (кодовото име на един много голям техно маняк :) от МТел, който ми даде за тези дни лаптоп и ми преотстъпи служебната си GPRS връзка. Затова и не казвам името му, да не вземат после МТел да му дърпат ушите. DJNone ще е и човекът, с който ще поемем през юли към "Love Parade". Лаптопът си го оборудвах с Red Hat Enterprise Linux 4. Пуснах си и IPsec (EAP only/IP-IP tunnel/NAT Traversal) през GPRS до домашния компютър с молитви да не спира тока в нас:) Срам или не, признавам си, че с IrDA нямах никакъв опит и едвам си конфигурирах инфрачервената връзка между лаптопа и GSM апарата.

* * *

Искам да изразя стрхотното си възмущение от поведението на БТК, Нетиссат и Орбител, които единствени от доставчиците на интернет свързаност, не защитиха клиентите си от цензурата на ГДБОП. Тези доставчици няма да видят от мен нито един лев и не само това. В ролята си на консултант, аз ще работя срещу тях. Злопаметен съм и не забравям! Първата ми работа щом се прибера е да прекратя договора за доставка на телефония от БТК, който ползвам у дома и достъпа към "CityConnect" услугата на Нетиссат на един мой роднина-студент, който заплащам аз. Вече имам IP телефон към един български доставчик на IP телефония и ще работя само и единствено с него. Дори нещата с филтрацията да утихнат, аз няма нито за един момент да спра да работя срещу интереса на доставчиците-цензори. Не забравям!

Изключително неприятно впечатление ми направиха Нетиссат. Такава излагация аз не съм виждал скоро. Нетиссат си позволиха да направят измама в системата за имена в Интернет (DNS). Върху своите сървъри за имена pns.netissat.bg и sns.netissat.bg, те бяха дефинирали зоната на домейна arenabg.com, с което поднасяха на потребителите си изкривена и лъжлива информация за системата за имена в Интернет (точното име е измама). При това обявяваха информацията към DNS клиентите като "достоверна" ("authoritative"), с "AA" бит в пакета с отговора на заявката, което е погазване на всякакви принципи за неутралност, добра практика и какво ли още не. Това е намеса в системата за имена в Интернет, нейното предефиниране без съответната за това оторизация, което представлява фалшификация без всякакви уговорки!

Да напомня на някои самозабравили се доставчици, че те са длъжни да действат на принципа на неутралността и че подмяната на информация в Интернет е нарушение на техническите параметри на достъпа до глобалната мрежа, неотменим компонент, от която е системата за имена - DNS. Моля, заинтересованите клиенти на Нетиссат да се обърнат към регистъра на gTLD COM и ICANN и да внесат оплакване по случая и да искат тези субекти да вземат отношение по случая.

Искам да изкажа възхищението си от Нели Огнянова за заетата публична позиция и да я поздравя за нея. Срамно е, че други хора, които уж по принцип защитавали правата на гражданите, си траеха и се правеха на ощипани и трябваше да ги ритат за каквато й да е официална реакция от тяхна реакция. Като несменяемият шеф на "Идиотско общество", например. За разлика от останалите, аз знам защо е това гузно поведение и един ден ще напиша доста по темата.

За пореден път се видя, че "експертът" на ГДБОП (експерт по какво е този неинтелигентен човечец?) Явор Колев е служител не на Държавата, а на частни интереси - бияч по поръчка. Надявам се някои хора, които преди залитаха по добро отношение към него, да са разбрали що за копой е този човек и че е техен враг. Този човек си позволи да иницира цензура срещу Интернет и това го превърна автоматично във враг на всички интернет потребители у нас. Следователно обществото на свободните хора е длъжно да работи против този човек. Това е въпрос на опазване на свободата. Моята свобода не може да се ограничава от икономически интереси, все едно чии са те и от хора с никакъв интелект, които са станали ченгета, само защото са нямали дарбата да станат нещо повече и поради това са се озлобили срещу всички нормални хора.

* * *

След като се излекувам и се прибера в България, следват доста интересни проекти. Единият проект е свързан с LIR обучение на едни млади хора, обучението им по основи на протоколи и алгоритми, информационна сигурност и системна администрация и интеграция. Основен момент в обучението им ще бъде как да крият информация си, не само с криптография, а и с различен набор евристични методи (евристичния метод се описва шеговито с "умен съм бил - сетил съм се"). В електронното общество достъпът до лична или служебна информация става все по-важен от гледна точка на достъп до нея от неоторизирани лица. Все едно дали става за криминалния контингент, журналисти или репресивни органи.

БТК и цензурата

Покрай RHEL5 и задълбочаваща се язва, която сигурно скоро, ако не се лекува ще премине в перитонит, нещо почнаха да ми убягват разни неща. Но днес видях нещо, което лично мен ме шокира.

От снощи (поправете ме, ако не съм прав), БТК обявява в BGP сесиите към клиентите си маршрута 72.36.224.0/19, но не дава проходимост към един от адресите в него, а именно 72.36.255.202. Оказва се, че това е IP адреса на сървъра www.arenabg.com. Общо взето пълни порнографии. Разбира се, ще посъветвам организацията, в която работя да прекрати договора си с БТК. Заповед на ГДБОП не може да се тълкува като формажорно обстоятелство и да се изисква договора да продължи (друг е въпроса, че няма съдебно решение за целта). Това е предефиниране на услугата и тя не трябва да се нарича "пълен достъп до Интернет", а "частичен или цензуриран достъп до Интернет". За нея следва да се подпише нов договор, който може и да не се подпише, ако клиентът не желае това.

БТК прави това без да е предупредила клиентите си въпреки, че според договорите с клиентите си е длъжна да го направи. Няма да говоря, че това е въвеждане на цензура и със сигурност няма съдебно решение, на основата на което това да продължи.

Съвсем скоро заминвам в чужбина и може би ще претърпя операция, но жив или мъртъв ще следя нещата в България и ще се опитам да разбера дали този път доставчиците ще отреагират единно или не. Сигурно милиционера Явор Колев ще е много радостен да ме види умрял на операционната маса, но мисля да му спестя това удоволствие.

Не купувайте "интелектуален продукт"

След последните акции на ГДБОП и изказвания на тези, дето им дават премиални, следва всеки съзнателен гражданин да направи следното:


1. Да спре да купува т.нар. "интелектуален продукт" и да спре и да го ползва. След като собствениците му ограничават свободата ви, значи от тях няма никаква нужда и те следва да загинат чрез фалит.

2. Да спре да ходи на кино и да ползва видеотеки (на кино не съм ходил от 2 години, от видеотеки вече съм отписан). Парите спестени от това могат да отидат за подпомагане на нещо полезно.

3. Да не питае никакво уважение към властта в тази страна, защото тя изпълнява фирмени поръчки, вместо да защитава гражданите си, които плащат данъци, и да не й оказва никаква помощ. Уважение към полицейска държава, която не зачита законите дето е приела, не може да има.

4. Да препятства по всякакъв начин действията на тези, които ограничават свободите.

На мизерниците - мизерия!

Други размисли около IX и съществуването му в наши условия

Това е продължение на бележката със заглавие "Що е то IX и има ли почва у нас", породена от поредните глупости на лицето Димитър Ганчев.

Да се абстрахираме, че аз не познавам БОЛ и некоректното им поведение спрямо останалите субекти в българския интернет. Приемаме, че аз съм някой, който иска да подкрепи идеята за IX. Неясни за мен са следните моменти, които всъщност касаят и устава на подобно сдружение. Ще ги поставям като въпроси и ще си отговарям на база нещата, които знам към момента. Забележете, че никъде допу не споменавам име на субект.

1. Ще се извършва ли транзит през участниците в IX или не?

Това е важен момент. Нека обясним нещата по-подробно. Какво означава транзит? Както бях обяснил преди това, в IX са свързани субекти, които разполагат със свое собствено адресно пространство, обединено в автономна система. Общото правило е, че ако в IX членуват N доставчика, в него има N+1 (поне) гранични маршрутизатора - N+1 - вия е този на IX, който е рефлектора. Граничният маршрутизатор е този, който стои на "границата" на две автономни системи (малко опростено, но нагледно обяснение). Идваме до най-простия случай, при който участниците в IX анонсират към "route reflector" сървъра само мрежите в състава на своята автономна система. Това е случай, в който няма транзит, защото никой не обявява през себе си маршрути, които са в други автономни системи, несвързани с IX и така през никой участник не преминава индиректна свързана до други мрежи, които не са под неговото управление и следователно не са в неговата автономна система. Транзит има в случаите, в които някои участници обявят достъпен през себе си даден (един или повече от един) маршрут(а) за автономна система, несвързана в IX. Така той разрешава на останалите участници да достъпват през него анонсираните недиректно свързани с IX мрежа. Транзит има и в другата посока - даден участник в IX излъчва към недиректно свързани с IX участници маршрутите от BGP таблицата на IX.

Въпросът е кога и как е възможен и оправдан подобрен транзит. За да си отговорим, да си представим следната ситуация. В един IX по принцип има N локални участника. Ако всички излъчат пълната си BGP таблица (отразяваща пълната им свързаност, към момента близо 214000 префикса), BGP рефлекторния сървър ще подава на всички участници най-добър маршрут (доколкото всички в IX са равни, изчислението ще става на база дължина на AS пътя), пресметнат на база M (M<=N) BGP сесии на участници. При избор на най-добър път по горната схема, обикновено се избира най-късия път, но това на значи, че канала за достъп през него е най-бърз. Освен това как един участник в IX ще има стимул да пусне всички през своя канал за достъп до Интернет, който обикновено е скъпо вложение? Точно тук всичко влиза в разрез с аналогията, правена с IX в Европа, особено с лондонския LINX, който е и най-големия "пункт" за обмяна на трафик в Интернет. В LINX членуват такива субекти, за които се достига по-голяма за тях локална дълбочината (изчислена в маршрути през автономни системи) за повечето направления, достъпни през тях. Причината е, че повечето участници в LINX са транзитни доставчици по дефиниция. Освен това колкото повече стават такива членове, толкова повече маршрутите се разпределят равномерно през тях и не се получава претоварване по направление през един от тях. От друга страна там има участници, които са доставчици на съдържание, което транзитните доставчици търсят (например Telehouse, който управлява мрежите на най-големите европейски хостинг центрове). Едни особени членове са академичните мрежи, на които по дефиниция се дава пълен достъп, за да ги стимулират да обучават кадри, които след това да ползват развитието на Мрежата.

У нас трудно може да се говори за транзит в смисъла на пълен транзит на интернет трафик. Причината е, че у нас интернет свързаността идва от няколко места и нямаме такава връзка до Интернет, която да разпределени равномерно най-добрите маршрути равномерно между всички (няма топологични фактори за това). Един изход е транзитните доставчици (доколкото у нас ги има), да се закачат в някакъв наш IX и да продават от там трафик на другите участници. Много неясна е схемата, по-която това ще става. Ако ще се използва пак BGP рефлекторен сървър, това значи, че един от тези доставчици ще бъде използван приоритетно, защото ще подава по-къси маршрути и това ще ощети останалите, през които тези маршрути за по-дълги (или пък ще ощети този, който подава по-къси маршрути, защото ще препълни канала му за свързаност).

Всичко това говори, че у нас няма условия за глобален транзит. Възможно е да има локален, касаещ само клиентите на субектите, които биха участвали в един IX. Дори и там е трудно да се постигне някакъв баланс. Тук отново се опира до проблеми с финансовото обезпечение на каналите, през които транзита се предлага.


2. Къде ще се намира възела на предполагаемия IX?

У нас не са много сградите, които да предложат помещение, в което да се помести подобен възел. Трябва тази сграда да е особено надеждна при земетресение, наводнение, пожар, та дори и слънчева активност (не може да се позволи магнитна бъря причинена от слънчевия вятър да индуцира ток по платките в устройствата и те за "забият"). Няма да говорим за това, че до помещението трябва да има строго регламентиран достъп, поддържани параметри на средата (температура, влажност на въздуха, радиационен фон) и т.н. Веднага изниква административния въпрос "а в чия сграда ще се намира този възел". Т.е. пак трябва да се намери някакво условие за неутралност. Не може това помещение да е в сграда на доставчик на свързаност, който по някое време да реши да изгони оттам съоръженията на IX-а, което да унищожи на практика свързаността. Преместването на съоръженията на IX означава промяна на трасетата за пренос, което много от участниците не могат да си позволят финансово, ако са свързани с "тъмни" оптични влакна, а и опира до възможност (колко са помещенията, отговарящи на горните критерии, които са на места лесни за свързване). Нужно е IX да разполага и с адвокати, които правно да оформят отношенията между организацията и този, който предоставя помещението. Едва ли IX ще може да събере толкова пари, че да закупи своя сграда, в която да помещава апаратурата и комуникационния си възел. А трябва да се мисли и за резервен възел и т.н. Това са огромни разходи, особено за град с такава лоша инфраструктура като София.


3. Как ще се регулират задълженията на участниците?

Всеки IX има правилник, съгласно който всеки доставчик има права и задължения. Кой обаче ще следи как един участник изпълнява технологично задълженията си? Например, как ще се следи, че той не органичава скоростта през себе си за друг участник, който се явява конкурент на пазара? Как ще се следи, че участникът излъчва своята BGP таблица, отразяваща наистина свързаността му? Как ще се следи дали най-късият подаван път е през канал с най-висока скорост? Как ще се следи качеството на предлаганата свързаност през участника (времезакъснения на пакетите, загуби на пакети, дупликация на пакети, девиация на времезакъснението)? Как ще се гарантира, че някой няма да продава през IX интернет свързаност през BGP сесии, които не преминават през рефлекторния сървър (BGP сесии между два доставчика)?


4. Как ще се намерят лица за техническа поддръжка и кои ще са те?

Добре, да приемем, че "route reflector" сървъра може да се реализира с маршрутизиращ софтуер Quagga или Xorp (в краен случай GateD), под операционна система Linux. Вярно, тук ще трябва скъпа и надеждна машина, на която да домува така описаната система. Да предположим, че тя се закупи. Под Linux може да работи почти всеки системен администратор. Да конфигурират Quagga могат доста хора, за жалост не може това да се каже за Xorp, а още по-малко за GateD, но да кажем, че изборът на Quagga в случая ще даде възможността лесно да се намират кадри за поддръжката. Оттам нататък са нужни много качествени L2 комутатори. Забравете за Cisco. Тук ще са нужни комутатори на Foundry. Това са доста скъпи комутатори, от най-висок клас, но за сметка на това изключително производителни и надеждни. Въпросът е обаче кой у нас има опит с такива комутатори? Друг вариант са комутатори на Nortel. Положението с тях е като с тези на Foundry - няма кадри с опит, които да ги обслужват. Да предположим, че се мине на компромис и се изберат комутатори Exteme Networks. Може и да се намерят хора, които да ги поддържат и конфигурират, но това е на база на хипотезата, че тези хора искат да се ангажират с това и имат дългогодишен опит, а няма такава гаранция, че те ще поискат или че ще имат опита за целта. Нещата опират и до финанси (заплати главно) и до намиране на хора с опит, които да са доволни от заплатите. Не може един IX да си позволи хора без никакъв стаж да управляват услугата срещу мижава сума за заплата.

Що е то IX и има ли почва у нас

Понеже комсомолецът Димитър Ганчев започва с нова манипулация, се опитах да обясня на хората какво е IX и има ли то почва у нас. По молба на Пейо го публикувам като бележка тук. Оригиналната дискусия е в клубовете на Dir.bg.

***

Комсомолецът Димитър Ганчев отново се опитва да пробутва уж революционни идеи. Добре е обаче хората да са просветени, за да не може да ги лъже. Обикновено всички решения в "обществена полза" прокламирани от комсомолеца Ганчев са само в негова полза и тази на другаря Марковски.

Няма да говоря какво е ISOC.bg и как то се използва за целите на червения дует Марковски-Ганчев. Да не споменавам "надпартийния" DNS базиран черен списък, организиран от ISOC.bg и управляван именно от другаря комсомолец Ганчев, който странно защо съдържа записи на адреси и цели домейни на хора, които просто не са приятни на другарския червен дует (пример е домейна NOVE.bg, само защото Атанас Бъчваров си е позволил да отговори на явен SPAM от страна на другарчето Вени Марковски). После идете, че ползвайте "актуалните" и "обществено ориентирани" услуги на комсомолците, които нямат никакъв регламент (но винаги имат финансова изгода и политически основи).

Няма да обяснявам как БОЛ е фирма, която храни повече политици, отколкото инженери и се опитва да седне на всяка софра и да взима всяка инициатива, а вместо технически оперативки се провеждат коктейли с политици. Мога да ви говоря с факти за техническата некомпетентност в БОЛ с часове, все едно дали от това на комсомолеца Ганчев му се скофтва и без това перманентното темерутско настроение или не. За SIX няма да дискутирам, защото е писано в Интернет, особено по блогове и т.н. Ще говоря само какво е IX (другарят Ганчев не е в час с това, трябва да знаете, но той не е в час по принцип с маршрутизацията, BGP, топологии на мрежи и т.н.). За MAN също не са му ясни нещата. Прави впечатление, че на страницата на БОЛ не се прави разлика между "мегабити в секунда" и "мегабайти в секунда", а описанието върху страницата на БОЛ на това какво е MAN разсмива вече с месеци доста доставчици у нас (някои дори доставчици на БОЛ). Със сигурност Ганчев много ще опъва да има точка за обмен на свободен трафик, но странно защо ще се окаже, че е добре този обмен да става през MAN средата на БОЛ. Тези неща са до болка познати на повечето доставчици, те знаят кои са БОЛ и инициативата на комсомолците ще остане само тук.


Понеже комсомолецът Ганчев се опитва да ви замъглява очите с глупости и страхотно изкривява нещата, нека опишем какво е "Internet Exchange - IX", как работи и има ли почва у нас.

IX е звездовидна мрежова топология за обмен на трафик между субекти, като целта е да се реализират следните технологични условия:

- разстоянието, измерено в път през автономни системи, между два доставчика да не включва междинно автономната система на IX (това е условие за най-къс път през IX и по-долу ще се обясни защо винаги в този път влиза не автономната система на IX);
- връзката между кои и да е два субекта в IX да е на основа минимален служебен трафик, т.е. идеалния случай е, когато субектите са свързани в един общ етернет сегмент без използване на MPLS и изобщо L2 VPN (дори без използване на STP, защото всички направления в L2 са равновероятни и няма нужда от разклонено йерархично дърво), а така също без използване на 802.1q капсулация (VLAN);
- да не се извършва маршрутизация в самата мрежа (нали е на IX (това изисква всички участници в IX да са в рамките на един мрежови сегмент);
- всички маршрутизатори в сегмента на IX да обменят маршрути с централен BGP сървър, който е в ролята на "route reflector" и всички маршрутизатори да са "route reflector" клиенти;
- скоростта на порта на всеки участник да не е по-малка от минимално зададената, която е условие за членство.

Сега някои обяснения от техническо естество. IX функционира благодарение на BGP4 и работата му в iBGP режим като "route reflector". Как работи тази схема? Организацията, която управлява IX, алокира "ASSIGNED PA" (ако е LIR) или "ASSIGNED PI" (ако не е LIR, а краен потребител на адресите) статусно адресно пространство в един блок и от това адресно пространство раздава адреси за граничните маршрутизатори на участниците в IX. Ако трябва да има IPv6 сегмент, IX трябва да е задължително LIR, за да получи сегмент със статус "ASSIGNED PA" (в IPv6 все още няма статус "ASSIGNED PI", но се работи към единен документ по въпроса). Адресното пространство е в рамките на автономна система, управлявана от огранизацията, представляваща IX. Всички адреси в IX, предназначени за граничните маршрутизатори на членовете на IX задължитено са в една мрежа (така се избягва маршрутизация, базирана на NEXTHOP в автономната система на IX). Това можете да си го представите примерно така:

10.0.0.0/16 - адресен сегмент за IX

10.0.0.1/16 - участник No.1
10.0.0.2/16 - участник No.2
10.0.0.3/16 - участник No.3
...
10.0.0.XYZ/16 - участник No.XYZ
10.0.255.254/16 - route reflector

Забележете, че така няма нужда в средата на IX да има маршрутизатор - всички гранични маршрутизатори на участниците комуникират директно помежду си и натоварването на мрежовите устройства става само по направление на обмена между съответните участници (докато, ако се използваше маршрутизатор в IX, това би довело до огромен товар в централна точка). Друга важна особеност е, че общото натоварване на апаратурата в IX не е силно линейна или нелинейна нарастваща функция на обменяния трафик, доколкото обмена е винаги директен (примерно между два порта на суич).

Сега идваме на темата BGP. Повечето хора у нас са свикнали да мислят, че за да има обмен между две автономни системи, то межу граничните маршрутизатори на тези две автономни системи трябва да има BGP сесии. Експонирайте сега тази схема в IX. Ако се спазва тази логика, би следвало при влизането на всеки нов член, граничните маршрутизатори на членовете на IX да изграждат по една BGP сесия с граничния маршрутизатор на новия член. Това е сериозен технически недостатък и позволява злоупотреби (примерно един доставчик филтрира сесията към друг, с цел да не му даде достъп до свои ресурси и да му иска заплащане за достъп). Именно затова се изгражда "route reflector". Какъв е смисъла на този рефлектор? Всеки участник в IX изгражда по една BGP сесия с един централен BGP сървър (не е нужно той да е маршрутизатор, ще разберете защо след това) и излъчва към него достъпните през себе си маршрути. BGP сървърът формира т.нар. "full mesh" от всички излъчени маршрути. Този "full mesh" се отразява (след налагането на дефинираните в BGP подборни правила за най-добър път) в пълната маршрутната таблица в IX. Тази таблица се излъчва към граничните маршрутизатори на всички клиенти. Така всеки участник има нуждата от една BGP сесия до "route reflector" сървъра и това е всичко необходимо. Ще се запитате "добре, но как тогава става маршрутизацията, след като "route reflector" сървъра не маршрутизира". Всичко е много просто и се крие в основите на рефлекторната схема. По-горе бях споменал, че се използва iBGP. При iBGP участващите маршрутизатори са в една автономна система - тази на IX. Представете си сега, че граничния маршрутизатор на участник 1 има адрес 10.0.0.1 и излъчи през себе си маршрут 192.168.0.0/24. Този маршрут попада в рефлектора. След това рефлекторът го излъчва към другите участници (рефлектор клиентите). Ако той се получи от участник 2, чиито адрес на граничен маршрутизатор е 10.0.0.2, ще е във вида:

192.168.0.0./24 nexthop via 10.0.0.1

Забележете, че nexthop не е през рефлекторния сървър, а през клиента, който е излъчил маршрута. Това се получава именно заради използването на iBGP (обмен между маршрутизатори в една AS). Така пакетите към 192.168.0.0/24 ще минават директно към излъчилия ги участник и рефлекторния сървър няма да маршрутизира нито един от тях. Именно тази принципна схема намалява много натоварването.

Сами виждате, че за да работи IX се иска един сървър (възможно е да са два, ако се изисква резервираност и първия не използва клъстер) и много много добър хардуер за комутаторите (суичовете). Също така всеки участник да си осигури за своя сметка свързаността до средата на IX (MAN, "тъмно влакно", етернет среда).



Сега от техническата идея отиваме в малко по-различна плоскост на поглед върху нещата и трябва да си отговорим на въпроса какъв субект трябва да е организацията, която ще представлява IX. Очевидно това трябва да е организация, която ще работи неутрално, в обща полза на своите членове. И без да ви подсказвам се сещате, че това не може да е интернет доставчик. Особено БОЛ не могат да са инициатори на такова нещо, нито негови управители, защото са показали, че от тях нищо не може да се очаква. Спомените от SIX са живи, номерата на комсомолското дуо Ганчев-Марковски от периода след SIX също са познати на всички и никой от големите доставчици няма да се хване на тяхното хоро (аз съм сигурен поне за два - Спектър и БТК - да опита Ганчев да ги покани и да види до какъв крах ще постигне). Повечето доставчици вярват в момента единствено на неутралността на академичната мрежа или на университетската мрежа на СУ и биха приели там да бъде изграден възела на IX. Даже имаше начални разговори на тази тема, които аз охладих още преди 2 години, особено след едно обсъждане с Делян Делчев. Ще се опитам да го изложа по-долу.

България е полицейска държава (почва за това има поради постсоциалистическия характер на населението, което е свикнало милицията да го млати и мародерства, а не да го защитава, въпреки че за населението плаща данъци, за да храни милицията). Една централна точка, през която преминава свързаността между доставчиците е една идеална възможност за цензуриране на трафика и особено за неговото подслушване (при това доста евтино реализируема). Да не говорим какво извиване на ръце могат да правят милиционерите от ГДБОП в полза на алчни холивудски снимачки и бездарни певци под прикритието "пиратството ограбва" (какво можеш да му вземеш на един гол човек:)). В момента MAN средата и директния обмен между доставчиците на база локална свързаност "всеки към всеки" е изключително трудна за контрол от страна на репресивните органи и почти невъзможна за подслушване и последващ анализ на трафика. За това особено допринася и асиметрията на каналите, обусловена от BGP. В момента мрежовата топология в българското интернет пространство е максимално затрудняваща контрола върху локалния Интернет от страна на репресивните органи и това е една от най-добрите черти на развитието на това пространство. Ганчев не може да спре репресивните органи.

Именно затова смятам, че IX в България няма място, поне на този етап. Комсомолецът Ганчев не може да даде никакви издържани аргументи да има IX. Не е вярно, че IX ще прекрати извиването на ръце. Причината е, че дори да има IX, големите доставчици членуващи в него ще наложат непосилни за малките участници квоти за трафик (които малките да са длъжни да дадат). Ако те не могат да направят това, просто няма да членуват в IX, защото нямат сметка. Ако този IX няма подкрепа на големите в този бизнес, той трябва да се състави от малки доставчици, през които преминава сравнително малък трафик и които имат по-слаба техническа поддръжка, не разбират много от проблемите и взимането на всяко едно решение в IX ще е съпътствно със скандали, дребнави сметки и т.н.

Т.е. не се лъжете, а мислете. България не е Великобритания, София не е Лондон и LINX не може да има.

Молба

Моля, ако някой по някое време забележи, че най-долу на всяка бележка в този дневник липсва лиценза за разпространението и употребата на публикуваната информацията, да ме уведоми чрез коментар. Поставил съм бележка за лиценза още от юни 2006, след като Васил Колев направи забележка, че няма такъв. Възможно е поради погрешна интерпретация и "бъг" в софтуера на Blogspot (трансфериран към Google), да се е получило така, че само аз като редактор да си виждам бележката за лиценза.

В момента полето с лиценза е описано чрез вмъкване на чист HTML в шаблона и не би трябвало да има проблеми при визуализирането му. Ако някой все пак забележи липсата на лиценз, да ми пише веднага!

Преоблякъл се Илия

Linux-bg.org отдавна се е превърнал в един деградивен жълт портал, от който ползата е никаква. Очаква се закупуването му от някой жълт вестник и на Албена Вулева ще бъде поверена рубриката "сигнално жълт Линукс". В него простотията надделя тотално над полезното съдържание.

Понеже от време на време трябва да се раздвижва интереса към жълтия портал, се предлагат различни атрактивни теми. Заглавията им звучат отвратително, но както за всеки влак си има пътници, така и за всеки портал си има посетители. Скоро очаквайте да прочете там призиви "легализирайте некрофилията" и т.н.

От известно време там вилнее един особено напорист технически инвалид с името Илия Базлянков. На него принадлежи извращението за домуване на коренов сървър за имена в LAN доставчик, което се нарежда по значимост някъде до изравянето на трупа на Чарли Чаплин. Идеята "всеки LAN с коренов сървър за имена" според мен има голямо бъдеще у нас, като се има предвид постоянното обедняване откъм знания в тази държава. Няма да е далеч мига, в който всеки LAN доставчик ще има не само свои коренови сървъри за имена, но и собствен интернет, защото примерно не му харесва как IANA раздават имена и мрежи. Оправдание винаги има - на такива идеи се ръкопляскало в арабските страни, Китай и Русия. Прегръщането на пещерен антиамериканизъм говори за жалък обществен статус, лошо образование, липса на разбиране за истинските причини за някои неща и най-вече наличие на желание за самоограничаване.

Доколкото Вени Марковски получи инвестиция от люксембургски инвестиционен фонд, който е световно неизвестен, реши да се позанимае малко с бизнес и мераците да става регисър на TLD bg умряха. Всъщност и хората в ICANN знаеха кой е Вени, та щеше да му е леко трудно да прокара идеите си. Както се казва и на тях им омръзна, както и на тези в RIPE им беше омръзнал преди години. Знайно е, че и много смях не е на хубаво - писва накрая. Та отиде си Вени и ето, дойде нов герой със желания за самоизява. Този герой е рицарят на LAN базираните коренови сървъри за имена, убиецът на хегемонията на IANA/ICANN над системата за имена в Интернет, Илия Базлянков. Бидейки автор на инициативната "точка.бг", трябва да се каже, че това му начинание тръгна от един абсолютен пубертетски афект, който изживя във форума на linux-bg.org, където му бе показано, че DNS е още далеч за него. Знанията му по DNS може да са под критично задължителните за допускане до разговор на тема DNS, но това не го спира да атакува Регистър.БГ. Разбира се, за по-силна аргументация (DNS може да не учи, но номерата на Вени вече е научил), инициативата се представя както анонсирана от организацията Tilix - производител на една небивала по своята оригиналност и поддръжка дистрибуция, детайли от страницата както ще видите по-долу.

Като администратор в проекта OpenFMI, реших да не публикувам впечатления от поддържането на този проект върху сървърите във ФМИ, но сълзи напират в очите ми само като се сетя какви неща съм виждал точно покрай този проект.

Та реших аз да видя що за организация е това Tilix и какви гениални мозъци е приютила. Първо започнах от регистрацията на домейна tilix.org. Викам си, е като човек иска да атакува цял TLD регистър, поне трябва да е запознат с основната дейност на този регистър - поддръжката на DNS услугата за домейн от първо или по-долно ниво. Очаквах да видя мега умна регистрация, връх на таланта и тържество на бързата и бистра мисъл. Вместо това доста се посмях и не само аз. Хората там бъркат понятия като организация и име на лице за административни и технически контакти, например (информацията е от whois услугата на TLD ORG):

...
Registrant Name:Ilij Bazlijkov
Registrant Organization:Ilia Bazlijkov
...
Admin Name:Emil  Terziev
Admin Organization:Ilia Bazlijkov
...
Tech Name:Emil  Terziev
Tech Organization:Emil  Terziev
...

За описанието на един и същи адрес няма да говорим. За 10 години практика съм виждал какви ли не изпълнения, но това е изключително неграмотно и говори, че хората дето са го пратили, не знаят как се регистрира домейн.

Делегирането на домейна tilix.org обаче спира дъха ми. Делегирането е извършено по една хипер любима схема, широко разпространен в България като семкопродаването:

$ dig -t ns tilix.org
...
;; ANSWER SECTION:
tilix.org.              49121   IN      NS      ns11.icndns.net.
tilix.org.              49121   IN      NS      ns12.icndns.net.

;; ADDITIONAL SECTION:
ns11.icndns.net.        53272   IN      A       80.72.85.2
ns12.icndns.net.        53272   IN      A       80.72.85.3
...

Да имаш претенции да атакуваш регистър и да не знаеш, че най-елементарното правило при делегирането на един домейн е, че сървърите за имена трябва да са в различни мрежи, ко